From nobody Sun Jan 4 13:32:27 2015 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 944D71A010A; Sun, 4 Jan 2015 13:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 RCESKutSQMes; Sun, 4 Jan 2015 13:32:25 -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 268C91A0092; Sun, 4 Jan 2015 13:32:24 -0800 (PST) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t04LWN1Q028874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 4 Jan 2015 21:32:24 GMT (envelope-from joelja@bogus.com) Message-ID: <54A9B162.1040407@bogus.com> Date: Sun, 04 Jan 2015 13:32:18 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: "dhcwg@ietf.org" , "opsawg@ietf.org" Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LugQhArCa0Sha7bgIL59QKHqSqhNxeTrD" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/WKSD52Dm6XxSSRtQSVoodaqgugQ Subject: [OPSAWG] AD sponsoring - draft-wkumari-dhc-capport-07 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, 04 Jan 2015 21:32:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LugQhArCa0Sha7bgIL59QKHqSqhNxeTrD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks, After some dicussion last year, I have agreed to sponsor draft-wkumari-dhc-capport (https://tools.ietf.org/html/draft-wkumari-dhc-capport-07). what I'm looking for feeback on right now is feedback from potential implementors, either of client implementations of captive portal detection or captive portals as to: * Whether or not this represents a reasonable optimization, * Have we gotten the security considerations right? * Would you use it if there was general consensus to the approach. Thanks joel --LugQhArCa0Sha7bgIL59QKHqSqhNxeTrD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlSpsWIACgkQ8AA1q7Z/VrJl4gCfeX7OVUvJYvHSArn4OtxdYamv IhAAn0GgRNOs5UlFPoYVZNR6XZi3K8Mg =CNMe -----END PGP SIGNATURE----- --LugQhArCa0Sha7bgIL59QKHqSqhNxeTrD-- From nobody Wed Jan 7 14:18:21 2015 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 8A65A1A1B84 for ; Wed, 7 Jan 2015 14:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 Ugpmp2ppnPQn for ; Wed, 7 Jan 2015 14:18:18 -0800 (PST) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0751A1B7E for ; Wed, 7 Jan 2015 14:18:14 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w61so1984099wes.21 for ; Wed, 07 Jan 2015 14:18:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=3r4PReVQY7+Smscf4K2S8JhXwkHCAJDgCY2feiZkqYE=; b=VKCDwqtVE4Q4nJaChWbDglkMq6yRArx8F9AY5F/ZKf3HLjEMAJfoENR+0WA7xQqTgM U9vvLoHIuWVisBK7f7wM0bCPbl2Ip9R7sC+CjlJfo1h1iDQCRHu8i15Fl5Sk+W4aMy6+ T0Lkf3cFbVHLSTdCOorTNH3zuZshDy/P43P83UXtCtNy6EsYiSCu7D5XIpH5e1B3rqnu mCLxlznRdFsvEPfSmcworfcvXtzp/FLSfPjLaeibVKeC78zqxNZhx57mHtvaeIQrJVL7 tccUoCU+dTJgrIcXm5D605PreqE4oaGOm7BhOm3Pprgr3OuBjsqAEGvLU7DeCAs+6xOK igqA== X-Gm-Message-State: ALoCoQl4UMmbDCxNejcceKB8d4nyCViviHvUuFgRP4VbhF95cLDbZwxOYYSdqqkykrK3oZM+HYyI MIME-Version: 1.0 X-Received: by 10.180.73.178 with SMTP id m18mr52150808wiv.65.1420669092401; Wed, 07 Jan 2015 14:18:12 -0800 (PST) Received: by 10.194.64.37 with HTTP; Wed, 7 Jan 2015 14:18:12 -0800 (PST) Date: Wed, 7 Jan 2015 17:18:12 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-opsawg-operators-ietf@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/c4SkJI4L4iwc5IBWbAseku57sGM Subject: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 07 Jan 2015 22:18:19 -0000 Dear OpsAWG, This starts a Call for Adoption for draft-opsawg-operators-ietf. The draft is available here: https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ Please review this draft to see if you think it is suitable for adoption by OpsAWG, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends Wed 21-Jan-2015. In addition, to satisfy RFC 6702 ("Promoting Compliance with Intellectual Property Rights (IPR)"): If you are personally aware of any IPR that applies to draft-opsawg-operators-ietf, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as OpsAWG WG co-chair) -- 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 From nobody Wed Jan 7 14:52:32 2015 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 C11A81A7028 for ; Wed, 7 Jan 2015 14:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 eLh3e2Y54V4T for ; Wed, 7 Jan 2015 14:52:28 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0681E1A7021 for ; Wed, 7 Jan 2015 14:52:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 790EC6F7; Wed, 7 Jan 2015 23:52:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Z1iwnDi8pu1X; Wed, 7 Jan 2015 23:52:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 7 Jan 2015 23:52:24 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECE392002C; Wed, 7 Jan 2015 23:52:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id H3KwFZV8hlH3; Wed, 7 Jan 2015 23:52:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0B9220017; Wed, 7 Jan 2015 23:52:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5DC4030515B4; Wed, 7 Jan 2015 23:52:23 +0100 (CET) Date: Wed, 7 Jan 2015 23:52:23 +0100 From: Juergen Schoenwaelder To: Warren Kumari Message-ID: <20150107225223.GA14477@elstar.local> Mail-Followup-To: Warren Kumari , "opsawg@ietf.org" , draft-opsawg-operators-ietf@tools.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/3KAEH_M96NQzGAXmNx5FiPiGVZI Cc: "opsawg@ietf.org" , draft-opsawg-operators-ietf@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 22:52:31 -0000 On Wed, Jan 07, 2015 at 05:18:12PM -0500, Warren Kumari wrote: > Dear OpsAWG, > > This starts a Call for Adoption for draft-opsawg-operators-ietf. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ > The I-D reports results from a survey. It is not a technical specification that a working group can work on. My recommendation would be to change the title to be more specific that this document is a survey report and then to submit this document as an individual submission to the RFC editor for publication. I do not see that a WG process can add value to the survey report. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 7 15:12:09 2015 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 BD2711A7026 for ; Wed, 7 Jan 2015 15:11:42 -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 XLEsJedC8Dh0 for ; Wed, 7 Jan 2015 15:11:40 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE031A1EF9 for ; Wed, 7 Jan 2015 15:10:32 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id p6so1654372qcv.37 for ; Wed, 07 Jan 2015 15:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yyr7nQGF5u7kluq1V4ZQIxGeq1SmsoQt/9HhsBqU2O8=; b=Hq13/O82Uo0orQhlKz9DHKDX3QqnvWY6iZB/8V3gOrkvuM2788q2XNrQV/KHKKVCRm mk+WbVPnPuHAn7xMbpIooNxzLyMtjREENLTrYgxzrQHiZ0iXwCUfUauMn0rX0YjUb+zx UsxHyblAK4A3+RNN4fc4OjPXc++H3FOat5Gm3KXDQ9FZ5A5zgOVq8FQkUe+Vv1x+eQJy 2uZnt4id0inZfV26QNTdZWW+T5GGRAxvZT4bSOQ4bg7kG8K9FzZHZJcVBBwkXKuzbo4K Eh8eKMEcS/5/h4gn2vpkr9zmKxeCX1lpHF8gm9xQU5TZKBLx5vcV+h8uVGbd28ssEE0a x7Zg== X-Received: by 10.224.73.135 with SMTP id q7mr9438657qaj.6.1420672231235; Wed, 07 Jan 2015 15:10:31 -0800 (PST) Received: from still.local ([50.127.155.45]) by mx.google.com with ESMTPSA id l8sm2412814qad.43.2015.01.07.15.10.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jan 2015 15:10:30 -0800 (PST) Message-ID: <54ADBCE7.3090009@gmail.com> Date: Wed, 07 Jan 2015 18:10:31 -0500 From: Tim Wicinski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0a2 MIME-Version: 1.0 To: opsawg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/tvyMcCbMk4mHA8U7PBVnto4BS8M Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 07 Jan 2015 23:11:44 -0000 I support adoption and will promise to review and contribute feedback. This is good work, and support this outreach efforts tim (yet another operator) On 1/7/15 5:18 PM, Warren Kumari wrote: > Dear OpsAWG, > > This starts a Call for Adoption for draft-opsawg-operators-ietf. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ > > Please review this draft to see if you think it is suitable for > adoption by OpsAWG, > and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends Wed 21-Jan-2015. > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > If you are personally aware of any IPR that applies to > draft-opsawg-operators-ietf, has this IPR been disclosed in compliance > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > details.) > > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) > > From nobody Wed Jan 7 15:14:00 2015 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 0BFDE1A7001 for ; Wed, 7 Jan 2015 15:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AIh9QLsRcK3t for ; Wed, 7 Jan 2015 15:13:35 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::628]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A1D1A7026 for ; Wed, 7 Jan 2015 15:13:35 -0800 (PST) Received: from SN2PR0601MB719.namprd06.prod.outlook.com (25.160.14.152) by SN2PR0601MB717.namprd06.prod.outlook.com (25.160.14.150) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 23:13:11 +0000 Received: from SN2PR0601MB719.namprd06.prod.outlook.com ([25.160.14.152]) by SN2PR0601MB719.namprd06.prod.outlook.com ([25.160.14.152]) with mapi id 15.01.0049.002; Wed, 7 Jan 2015 23:13:10 +0000 From: Chris Grundemann To: Juergen Schoenwaelder , "Warren Kumari" Thread-Topic: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf Thread-Index: AQHQKsfbXCqKhG9MSk2PnEtMUHx6k5y1Q6OA//+QcwA= Date: Wed, 7 Jan 2015 23:13:10 +0000 Message-ID: References: <20150107225223.GA14477@elstar.local> In-Reply-To: <20150107225223.GA14477@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.14.10.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=grundemann@isoc.org; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:SN2PR0601MB717; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0601MB717; x-forefront-prvs: 044968D9E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(189002)(199003)(24454002)(377454003)(51704005)(106356001)(106116001)(21056001)(105586002)(99286002)(31966008)(101416001)(107046002)(86362001)(54356999)(76176999)(4396001)(92566001)(50986999)(36756003)(2656002)(64706001)(122556002)(120916001)(20776003)(87936001)(40100003)(66066001)(99396003)(19580395003)(19580405001)(46102003)(230783001)(2950100001)(77156002)(15975445007)(62966003)(2900100001)(102836002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR0601MB717; H:SN2PR0601MB719.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <6BA8D40B55CA6B4087D3DAA3467F42AC@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2015 23:13:10.5974 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0601MB717 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ZrY7TjVHN6EtSpc9lq4F0YgmR_M Cc: "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 07 Jan 2015 23:13:43 -0000 On 1/7/15, 3:52 PM, "Juergen Schoenwaelder" wrote: >On Wed, Jan 07, 2015 at 05:18:12PM -0500, Warren Kumari wrote: >> Dear OpsAWG, >>=20 >> This starts a Call for Adoption for draft-opsawg-operators-ietf. >>=20 >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ >> > >The I-D reports results from a survey. It is not a technical >specification that a working group can work on. The work intended is to further analyze the results and the situation they describe to identify additional solutions that may be actionable. These potential actions may come from the IETF, the Operator communities around the world, or possibly the ISOC. Simply reporting that we have found a set of problems is only part of the goal for this document. From the abstract: "The primary purpose of doing this is to start a conversation which we hope will lead to increases in the level of operational input and feedback to the IETF standards making process." >My recommendation would be to change the title to be more specific >that this document is a survey report and then to submit this document >as an individual submission to the RFC editor for publication. I do >not see that a WG process can add value to the survey report. We, the authors, considered that path (and had several ADs offer to sponsor the I-D as well). We believe however that this is absolutly one type of work the OpsAWG should take on: Building the intellectual capital of the IETF by making it easier and more likely for implementors (read: operators) to participate. Cheers, ~Chris From nobody Wed Jan 7 15:53:58 2015 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 6656C1A8715 for ; Wed, 7 Jan 2015 15:53: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 luyo_mmDN7bf for ; Wed, 7 Jan 2015 15:53:48 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A2A1A8706 for ; Wed, 7 Jan 2015 15:53:47 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id v10so7564392pde.12 for ; Wed, 07 Jan 2015 15:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EOQxCufdM0xtuVAOk+C/KmKnd5mMU3UsxGjH9imHokc=; b=PLbsGxMWCU+QWe6+8Y09fnU0kA4zt1nhU45enchHNeQhRa0IuOcxuD3uALml4d7YEO MJqTf458Dc41D/MmfUk3HGPAHj3ZpvjnUrMH04kwK0GB6zQRDOmRwYvaWR7xA1iq+sb4 GKpT6GgyQXNsYv1+onzvPIE/XXPBMyyqot83oXmqGLX3iIGtjiSp6dPmpqdXirHM/pu2 cUWzJmWQG0gOXbav2zx4utoDyCJVTrdNwkHbHF4+9iJDfQeaBlFTsfwhBOQ/NVVQX4Ws nzWClF/zcozbKve6oARxu/ZFI0n/EYQM1b9Jl7YWR54sOJDzCpan0M1KhkiaP0ew2Iib cKoQ== X-Received: by 10.68.57.167 with SMTP id j7mr9970025pbq.160.1420674827083; Wed, 07 Jan 2015 15:53:47 -0800 (PST) Received: from ?IPv6:2406:e007:7a6a:1:28cc:dc4c:9703:6781? ([2406:e007:7a6a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id os10sm2630297pbb.33.2015.01.07.15.53.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jan 2015 15:53:45 -0800 (PST) Message-ID: <54ADC71E.2030408@gmail.com> Date: Thu, 08 Jan 2015 12:54:06 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Chris Grundemann , Juergen Schoenwaelder , Warren Kumari References: <20150107225223.GA14477@elstar.local> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/BYFWN3kzSR9VjW34HE8IYV18GcQ Cc: "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 07 Jan 2015 23:53:52 -0000 On 08/01/2015 12:13, Chris Grundemann wrote: > On 1/7/15, 3:52 PM, "Juergen Schoenwaelder" > wrote: > >> On Wed, Jan 07, 2015 at 05:18:12PM -0500, Warren Kumari wrote: >>> Dear OpsAWG, >>> >>> This starts a Call for Adoption for draft-opsawg-operators-ietf. >>> >>> The draft is available here: >>> https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ >>> >> >> The I-D reports results from a survey. It is not a technical >> specification that a working group can work on. > > The work intended is to further analyze the results and the situation they > describe to identify additional solutions that may be actionable. These > potential actions may come from the IETF, the Operator communities around > the world, or possibly the ISOC. > > Simply reporting that we have found a set of problems is only part of the > goal for this document. From the abstract: > > "The primary purpose of doing this is to start a conversation which we > hope will lead to increases in the level of operational input and feedback > to the IETF standards making process." > >> My recommendation would be to change the title to be more specific >> that this document is a survey report and then to submit this document >> as an individual submission to the RFC editor for publication. I do >> not see that a WG process can add value to the survey report. > > We, the authors, considered that path (and had several ADs offer to > sponsor the I-D as well). We believe however that this is absolutly one > type of work the OpsAWG should take on: Building the intellectual capital > of the IETF by making it easier and more likely for implementors (read: > operators) to participate. I agree. This is of very fundamental importance to the IETF and should not be relegated to the Independent stream. I could imagine it being handled by the General AD and we should encourage cross-area participation (because, after all, the problem of operators not being listened to is probably worse in all other areas). But as a home for the draft, OPSAWG seems best. Brian From nobody Wed Jan 7 23:26:34 2015 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 060DB1A6EE7 for ; Wed, 7 Jan 2015 23:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 C7LgUC--hUR1 for ; Wed, 7 Jan 2015 23:26:26 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFCD1A19E3 for ; Wed, 7 Jan 2015 23:26:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C5B759F6; Thu, 8 Jan 2015 08:26:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WG7kVU9AFvlf; Thu, 8 Jan 2015 08:26:04 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 8 Jan 2015 08:26:23 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D57212002C; Thu, 8 Jan 2015 08:26:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hu43ELGHKUVw; Thu, 8 Jan 2015 08:26:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 895A320017; Thu, 8 Jan 2015 08:26:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4CE6D30517BE; Thu, 8 Jan 2015 08:26:24 +0100 (CET) Date: Thu, 8 Jan 2015 08:26:23 +0100 From: Juergen Schoenwaelder To: Chris Grundemann Message-ID: <20150108072623.GB15231@elstar.local> Mail-Followup-To: Chris Grundemann , Warren Kumari , "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" References: <20150107225223.GA14477@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/c_0lFz8OfmpUnGDUlEO6q5W3nMA Cc: "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 07:26:29 -0000 On Wed, Jan 07, 2015 at 11:13:10PM +0000, Chris Grundemann wrote: > On 1/7/15, 3:52 PM, "Juergen Schoenwaelder" > wrote: > > >On Wed, Jan 07, 2015 at 05:18:12PM -0500, Warren Kumari wrote: > >> Dear OpsAWG, > >> > >> This starts a Call for Adoption for draft-opsawg-operators-ietf. > >> > >> The draft is available here: > >> https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ > >> > > > >The I-D reports results from a survey. It is not a technical > >specification that a working group can work on. > > The work intended is to further analyze the results and the situation they > describe to identify additional solutions that may be actionable. These > potential actions may come from the IETF, the Operator communities around > the world, or possibly the ISOC. > > Simply reporting that we have found a set of problems is only part of the > goal for this document. From the abstract: > > "The primary purpose of doing this is to start a conversation which we > hope will lead to increases in the level of operational input and feedback > to the IETF standards making process." > > >My recommendation would be to change the title to be more specific > >that this document is a survey report and then to submit this document > >as an individual submission to the RFC editor for publication. I do > >not see that a WG process can add value to the survey report. > > We, the authors, considered that path (and had several ADs offer to > sponsor the I-D as well). We believe however that this is absolutly one > type of work the OpsAWG should take on: Building the intellectual capital > of the IETF by making it easier and more likely for implementors (read: > operators) to participate. > The survey report is one thing, possible actions to change the situation are another thing. I prefer to not mix those two together. For example, how do we determine that "making it easier and more likely for implementors (read: operators) to participate" has been achieved? I am not saying this discussion is not worthwhile, do not get me wrong on that. But I do not think that making this document a WG document is useful. My preference still is to publish the survey via the individual stream and discuss any possible actions to change the situation separately. OPSAWG should allocate time for this discussion, I do not think the survery report has to become an OPSAWG working group item for having this discussion. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jan 8 10:51:04 2015 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 A2ED61A008F for ; Thu, 8 Jan 2015 10:51:00 -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 av0V4tR93ty8 for ; Thu, 8 Jan 2015 10:50:58 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC361A0086 for ; Thu, 8 Jan 2015 10:50:58 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so13418643pab.4 for ; Thu, 08 Jan 2015 10:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IOq6LEkYaM+CuMOLKwnHGp/Ms9Pkx2iJTlxaYygxAoA=; b=Z9DsDCUp2bQymX3lKZStwLv7KK2w+iCnDxHmozqHkiuvIRAxWykIlb0M1UrnvfS4BM pOsziAt5BW7oNR60QtPz12chfh0uj3ewrGKmDTW+6BBK525ciR6butjA+8qMsPDmKNc0 hLeqatVgPw99W+X/UdUM+9at3gHFxo6PJeJWtboamfWkobZvG80n0sakzs375kKPLpSN +TqC+SGQhKLwVZzQ0Sb617I9bdJHJLhJ1D3/GcDn/vLPyv5YXD1lgSwgXPiz7SfA4zJ5 j+f+rTIo3e0UvgBQDH7j9m/aV2ZZHzwHOxU63e5MJ3YBxEHgC6dSMveqs/4yFX2uKUvq E7BQ== X-Received: by 10.67.11.16 with SMTP id ee16mr16972443pad.128.1420743057871; Thu, 08 Jan 2015 10:50:57 -0800 (PST) Received: from ?IPv6:2406:e007:4640:1:28cc:dc4c:9703:6781? ([2406:e007:4640:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id a6sm5044464pbu.64.2015.01.08.10.50.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jan 2015 10:50:56 -0800 (PST) Message-ID: <54AED1A4.1010402@gmail.com> Date: Fri, 09 Jan 2015 07:51:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <20150107225223.GA14477@elstar.local> <20150108072623.GB15231@elstar.local> In-Reply-To: <20150108072623.GB15231@elstar.local> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 08 Jan 2015 18:51:00 -0000 Juergen, On 08/01/2015 20:26, Juergen Schoenwaelder wrote: > On Wed, Jan 07, 2015 at 11:13:10PM +0000, Chris Grundemann wrote: >> On 1/7/15, 3:52 PM, "Juergen Schoenwaelder" >> wrote: ... >>> My recommendation would be to change the title to be more specific >>> that this document is a survey report and then to submit this document >>> as an individual submission to the RFC editor for publication... ... > ... My preference still is to publish the survey > via the individual stream... Please can you clarify whether your proposal is that the draft should be handled as an individual non-WG IETF Stream document sponsored by an AD, or as an Independent Stream submission to the RFC Editor. Comparing your two statements above, I don't know which you mean. Regards Brian From nobody Thu Jan 8 11:43:03 2015 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 7FD1A1A90AB for ; Thu, 8 Jan 2015 11:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 jLzQL5DkUP9h for ; Thu, 8 Jan 2015 11:42:59 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0271A90AA for ; Thu, 8 Jan 2015 11:42:59 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 853C8753; Thu, 8 Jan 2015 20:42:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ArwULyIhrL6r; Thu, 8 Jan 2015 20:42:53 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 8 Jan 2015 20:42:56 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C78882002C; Thu, 8 Jan 2015 20:42:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3PpTu6Mu9XhZ; Thu, 8 Jan 2015 20:42:56 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B707320017; Thu, 8 Jan 2015 20:42:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 69BCA30539D1; Thu, 8 Jan 2015 20:42:57 +0100 (CET) Date: Thu, 8 Jan 2015 20:42:56 +0100 From: Juergen Schoenwaelder To: Brian E Carpenter Message-ID: <20150108194256.GA18464@elstar.local> Mail-Followup-To: Brian E Carpenter , "opsawg@ietf.org" References: <20150107225223.GA14477@elstar.local> <20150108072623.GB15231@elstar.local> <54AED1A4.1010402@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54AED1A4.1010402@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 19:43:01 -0000 On Fri, Jan 09, 2015 at 07:51:16AM +1300, Brian E Carpenter wrote: > Juergen, > > On 08/01/2015 20:26, Juergen Schoenwaelder wrote: > > On Wed, Jan 07, 2015 at 11:13:10PM +0000, Chris Grundemann wrote: > >> On 1/7/15, 3:52 PM, "Juergen Schoenwaelder" > >> wrote: > ... > >>> My recommendation would be to change the title to be more specific > >>> that this document is a survey report and then to submit this document > >>> as an individual submission to the RFC editor for publication... > ... > > ... My preference still is to publish the survey > > via the individual stream... > > Please can you clarify whether your proposal is that the draft should > be handled as an individual non-WG IETF Stream document sponsored > by an AD, or as an Independent Stream submission to the RFC Editor. > Comparing your two statements above, I don't know which you mean. > I have not thought much about it but I perhaps an Independent Stream submission is most appropriate. It actually remains somewhat unclear to me _who_ conducted the survey (that is which organization was doing the work) and what the precise involvement of the Internet Society was. (Perhaps the Internet Society did this itself, but I just can't tell from reading the document.) There is also not much information (or I did not find it) about the methodology, i.e., how operators were selected / approached and the questionaire itself. But that does not matter for the question how to publish the result. If my understanding is correct that the IETF was not directly involved in this survey, I assume an Independent Stream submission may be a reasonable approach. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jan 8 12:00:35 2015 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 DC9EF1A9151 for ; Thu, 8 Jan 2015 12:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 w-_Rp5S2IC3T for ; Thu, 8 Jan 2015 12:00:29 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C611ACD66 for ; Thu, 8 Jan 2015 12:00:24 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so5610208wiw.3 for ; Thu, 08 Jan 2015 12:00:22 -0800 (PST) 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:content-type; bh=yCabQMHXGM8GQcewHyjF+9oT2SJMthl9WvWkpZg9Dxc=; b=BWYqLRQvb0qaMg0f0dTdEgvZf0dRjoQVO4AT2CXDMBkMX/hI8pdIfzIsDomvwUyeJV LyoboIX40uf+fOF5q+WgA33b4ygve+1MuFhHJRuow4jDb5zQqIjutU+PDGDTebWzj6Gl 1Oaipst+4CRuEtl3zxC60qciGl4KNV20Y/0hwcNj7Na0XvmvIKqUya1MwwZ8ybivRePB LHUR2Xwo7g8BfPddsU4WDm9eiIWqxquAB1PjqXUhDI/bOeD6bgqsgWiB7D0MXbK/na/c y9ThELRVEmmgUkdpP4BcSfzgmCL/15NCB8Xip+mO5FvoPiRua4NbtQ6r1eV5tJniKPck 9jnA== X-Gm-Message-State: ALoCoQkSRZRz1idqxbZ2ZhPHJTg/EZnS4Ong0OWI1EqrgKRmh2WOabGgfpUsx3px3Do66Vh5eQZu MIME-Version: 1.0 X-Received: by 10.194.91.234 with SMTP id ch10mr23808693wjb.114.1420747222852; Thu, 08 Jan 2015 12:00:22 -0800 (PST) Received: by 10.194.64.37 with HTTP; Thu, 8 Jan 2015 12:00:22 -0800 (PST) In-Reply-To: <20150108072623.GB15231@elstar.local> References: <20150107225223.GA14477@elstar.local> <20150108072623.GB15231@elstar.local> Date: Thu, 8 Jan 2015 15:00:22 -0500 Message-ID: From: Warren Kumari To: Juergen Schoenwaelder , Chris Grundemann , Warren Kumari , "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 08 Jan 2015 20:00:33 -0000 On Thu, Jan 8, 2015 at 2:26 AM, Juergen Schoenwaelder wrote: > On Wed, Jan 07, 2015 at 11:13:10PM +0000, Chris Grundemann wrote: >> On 1/7/15, 3:52 PM, "Juergen Schoenwaelder" >> wrote: >> >> >On Wed, Jan 07, 2015 at 05:18:12PM -0500, Warren Kumari wrote: >> >> Dear OpsAWG, >> >> >> >> This starts a Call for Adoption for draft-opsawg-operators-ietf. >> >> >> >> The draft is available here: >> >> https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ >> >> >> > >> >The I-D reports results from a survey. It is not a technical >> >specification that a working group can work on. >> >> The work intended is to further analyze the results and the situation they >> describe to identify additional solutions that may be actionable. These >> potential actions may come from the IETF, the Operator communities around >> the world, or possibly the ISOC. >> >> Simply reporting that we have found a set of problems is only part of the >> goal for this document. From the abstract: >> >> "The primary purpose of doing this is to start a conversation which we >> hope will lead to increases in the level of operational input and feedback >> to the IETF standards making process." >> >> >My recommendation would be to change the title to be more specific >> >that this document is a survey report and then to submit this document >> >as an individual submission to the RFC editor for publication. I do >> >not see that a WG process can add value to the survey report. >> >> We, the authors, considered that path (and had several ADs offer to >> sponsor the I-D as well). We believe however that this is absolutly one >> type of work the OpsAWG should take on: Building the intellectual capital >> of the IETF by making it easier and more likely for implementors (read: >> operators) to participate. >> > > The survey report is one thing, possible actions to change the > situation are another thing. I prefer to not mix those two together. > For example, how do we determine that "making it easier and more > likely for implementors (read: operators) to participate" has been > achieved? I am not saying this discussion is not worthwhile, do not > get me wrong on that. But I do not think that making this document a > WG document is useful. My preference still is to publish the survey > via the individual stream and discuss any possible actions to change > the situation separately. OPSAWG should allocate time for this > discussion, I do not think the survery report has to become an OPSAWG > working group item for having this discussion. ... and I thought we should adopt this, have a very short discussion on the results, and then quickly move to WGLC and publish it. Having survey results (which show a number of issues, some obvious and some surprising) as an OpsAWG document makes it clear that this is something that we (the IETF and OpsAWG in particular) are actually paying attention to, and are going to try and address. The survey results look kinda like a problem statement, and having it published by OpsAWG gives it a good home, and helps make it clear where discussions on the "solutions" are welcome. Concerns about the lack of operator input are not new - there have been rumblings about it for a long, long time; making it clear that we are actually taking this seriously, and are trying to address the issue is important. IMO, Independent Submissions does not give that impression - for various reasons people have the idea that IS is a stream for non-IETF documents, or things that someone somewhere thought were vaguely interesting, and the IETF didn't care enough about to squash or champion. Much of this is not a technical argument, but rather a touchy feely, marketing argument... W > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- 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 From nobody Fri Jan 9 09:15:15 2015 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 29D5A1A8A3D for ; Fri, 9 Jan 2015 09:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 85-rw1vVxcEA for ; Fri, 9 Jan 2015 09:15:12 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5997E1A87C9 for ; Fri, 9 Jan 2015 09:15:03 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so9257941wgh.8 for ; Fri, 09 Jan 2015 09:15:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=dt9k3tudr/i15ux6FA9MdXZkOLSk1lJypXbSBqkkPnE=; b=ZarZNXn4lK0Q0p2GrAsQmume/qRwfh40Q5YrIqudenFiNWYU/k40UXDeoDaGHUdto4 Iakb5XPDIMYZfFtX+kZNdkh4pqqLqGn5J6M9PyDldSMshLHzNnRVSKqvHwmyV2i5g+F6 51YdVVokf4+wQeXTDYZcVfyRE7UDEtNL2Qm/VCNpdzP3xC/1ghjNkH5inZFtGcPIHWMO PncFy67IehA5APS5C6d+gmVOllWyk0AGloIi84vQnALqxkXJseaD+vMcnfKz5oWtYhQO O4H41m3kdtCTDvoFY1zZvcoUSJsVAam0zm46+aJx+vzsYIwmDybMXnacRxl4HAH4VsbS XHWA== X-Gm-Message-State: ALoCoQmc538BQqt1NnSlNa2PIn+I4Jzlg1EVlN6fOKFr1F/eZ2/F1kst+ZObdPuVc1ZBcYfk8CzY MIME-Version: 1.0 X-Received: by 10.194.91.234 with SMTP id ch10mr1603104wjb.114.1420823702054; Fri, 09 Jan 2015 09:15:02 -0800 (PST) Received: by 10.194.64.37 with HTTP; Fri, 9 Jan 2015 09:15:02 -0800 (PST) Date: Fri, 9 Jan 2015 12:15:02 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 09 Jan 2015 17:15:14 -0000 Dear OpsAWG WG, The authors of draft-ietf-opsawg-vmm-mib have indicated that they believe that the document is ready, and have asked for Working Group Last Call. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. This WGLC ends Fri 23-Jan-2015. In addition, to satisfy RFC 6702 ("Promoting Compliance with Intellectual Property Rights (IPR)"): Are you personally aware of any IPR that applies to draft-ietf-opsawg-vmm-mib? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as OpsAWG WG co-chair) -- 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 From nobody Sat Jan 10 02:05:16 2015 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 9993B1A9073 for ; Sat, 10 Jan 2015 02:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 xjsr6DyCf7-O for ; Sat, 10 Jan 2015 02:05:09 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.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 C634C1A9061 for ; Sat, 10 Jan 2015 02:05:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Y9sui-0000IU-Mw; Sat, 10 Jan 2015 10:05:00 +0000 Date: Sat, 10 Jan 2015 11:05:01 +0100 Message-ID: From: Randy Bush To: Juergen Schoenwaelder In-Reply-To: <20150107225223.GA14477@elstar.local> References: <20150107225223.GA14477@elstar.local> 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" , draft-opsawg-operators-ietf@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 10 Jan 2015 10:05:11 -0000 > The I-D reports results from a survey. It is not a technical > specification that a working group can work on. > > My recommendation would be to change the title to be more specific > that this document is a survey report and then to submit this document > as an individual submission to the RFC editor for publication. I do > not see that a WG process can add value to the survey report. yep From nobody Sat Jan 10 17:00:46 2015 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 7D26B1A1AA6 for ; Sat, 10 Jan 2015 17:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 1q7xTq-FYzMP for ; Sat, 10 Jan 2015 17:00:41 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392441A1A98 for ; Sat, 10 Jan 2015 17:00:41 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so13887520wgh.8 for ; Sat, 10 Jan 2015 17:00:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=q3urvl1v8eHqUSECOuJS9PWKHQs5GmjRhMJhB8j99oc=; b=EB+VDwotLQWixg+7VT1RsCl7M6w4WJUCL4UgxFF83LWXjxnMJ1vjLLsUTC+4w0OKfn RjAIEk5AtJg2aLCWxcFXQhNst/VZ1nEiAIgwqxlHUV4zOvwZPaJ7Xz7I1BhuE5zvbHKX 519/QQXlhqH3P8oabPA3C2OG0l047/tS4mbJBIkpRyNEjUnOpRgmU0gFWj+zOzzPpUGs E2BfIpUnx3aHrA579yJnbeC9yYug1tW9y2vNUQ4jntVvaEmn9mmQvtpKWnlqNxgqrKsN iQWZLr4AyUx1R0fg3Th7OsPxc9OC+BCRk2+OBwBajZo4ixjynGHuQeL79P5lcnWw6mq+ 5RPA== X-Gm-Message-State: ALoCoQnCu53PHcGhssljwK/b1pO3SIukEHeRqASf5FXq46Sl5dOF0Ord9YaKGjaxJJ0iSl/suLMD MIME-Version: 1.0 X-Received: by 10.194.63.169 with SMTP id h9mr12488061wjs.23.1420938039766; Sat, 10 Jan 2015 17:00:39 -0800 (PST) Received: by 10.194.64.37 with HTTP; Sat, 10 Jan 2015 17:00:39 -0800 (PST) Date: Sat, 10 Jan 2015 20:00:39 -0500 Message-ID: From: Warren Kumari To: joel jaeggli Content-Type: multipart/alternative; boundary=047d7ba97a861bce20050c55eb8e Archived-At: Cc: "dhcwg@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] AD sponsoring - draft-wkumari-dhc-capport-07 - kills kittens. 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, 11 Jan 2015 01:00:45 -0000 --047d7ba97a861bce20050c55eb8e Content-Type: text/plain; charset=UTF-8 Note: This draft kills kittens... Y'all should probably read it to find out: A: why and B: if I just made that up... W On Sunday, January 4, 2015, joel jaeggli wrote: > Folks, > > After some dicussion last year, I have agreed to sponsor > draft-wkumari-dhc-capport > (https://tools.ietf.org/html/draft-wkumari-dhc-capport-07). what I'm > looking for feeback on right now is feedback from potential > implementors, either of client implementations of captive portal > detection or captive portals as to: > > * Whether or not this represents a reasonable optimization, > > * Have we gotten the security considerations right? > > * Would you use it if there was general consensus to the approach. > > Thanks > joel > > > > -- 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 --047d7ba97a861bce20050c55eb8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Note: This draft kills kittens...

Y'all should proba= bly read it to find out:
A: why and=C2=A0
B: if I just = made that up...

W

On Sunday, J= anuary 4, 2015, joel jaeggli <joelja= @bogus.com> wrote:
Folks,

After some dicussion last year, I have agreed to sponsor
draft-wkumari-dhc-capport
(https://tools.ietf.org/html/draft-wkumari-dhc-capport-07).= what I'm
looking for feeback on right now is feedback from potential
implementors, either of client implementations of captive portal
detection or captive portals as to:

* Whether or not this represents a reasonable optimization,

* Have we gotten the security considerations right?

* Would you use it if there was general consensus to the approach.

Thanks
joel





--
I don't think the execution is releva= nt when it was obviously a bad idea in the first place.
This is like put= ting rabid weasels in your pants, and later expressing regret at having cho= sen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0= ---maf
--047d7ba97a861bce20050c55eb8e-- From nobody Sun Jan 11 13:43:12 2015 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 DF8F91A1A86; Sun, 11 Jan 2015 13:43: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 JpS5j2qH8EMh; Sun, 11 Jan 2015 13:43:07 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342211A0BE8; Sun, 11 Jan 2015 13:43:07 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar1so22703655iec.2; Sun, 11 Jan 2015 13:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Q1N5OHbrTShtX+mE2uZyVoCyYUSt7Ub32Si8JLCEPFE=; b=EfExv3bjpSM907gAxrAWaUDefltrUdmxoJQ2kC4kkDeaJf8Blck5Ke9tbBlAEo4sWL lQgbvhItsXIx1ucH/perEeHxLqmS/+wpKlTD2DA1ymr8yXs9XJ1x7mBlFwlxkKl6/Vj9 C/TggX6mwNLCTi+Y0nXfM+u9r0F1UEHLDBmwggC6eLLDoqGAmaoC10evJkgoBnFOYph8 R90JRTOpaAFoNT+ky4OrYAqmT0eWw8Yf5Ydp6ua4I2u592hp2PfDUPG6t3TE+bqrcCXw feBzBhJWPXyHtdFZoPSxU7LFt5Gm1ckUFyYwUTyh0XqI5O7Pe8BFtT6Hz8IyjNXubX4c MFGA== X-Received: by 10.50.36.103 with SMTP id p7mr12472278igj.20.1421012586349; Sun, 11 Jan 2015 13:43:06 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-8-163.tor.primus.ca. [173.206.8.163]) by mx.google.com with ESMTPSA id qj3sm3128668igc.17.2015.01.11.13.43.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jan 2015 13:43:06 -0800 (PST) Message-ID: <54B2EE69.7020807@gmail.com> Date: Sun, 11 Jan 2015 16:43:05 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] NAT MIB scope 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, 11 Jan 2015 21:43:09 -0000 Given present policies regarding the respective roles of SNMP and Yang, is it reasonable to say that the only configuration data that should be present in the NAT MIB is data directly relating to the control or interpretation of the remaining contents (i.e., the notifications, state information, and statistics)? I can see a Yang module for NAT configuration in my possible future. Tom Taylor From nobody Mon Jan 12 05:48:56 2015 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 237A81A90EC for ; Mon, 12 Jan 2015 05:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WMZLCextQ-yd for ; Mon, 12 Jan 2015 05:48:48 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B093B1A90E8 for ; Mon, 12 Jan 2015 05:48:47 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id hs14so24111272lab.8 for ; Mon, 12 Jan 2015 05:48:46 -0800 (PST) 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=NwjcPZTIX/9z32n4Pv0hXlFfe+XWVSvedfQ6Mgk2LWc=; b=g4kIvChs5rGED6cD5Hmiwixg2skwDz3UZziTTYKRMs7rdRXMynG9hIXW3feedOwl3h i1iPNu/mQCybQ6s4De5xYnY3MENklTwLf7nrMdeHiZS3y9Hom8AgX4MkRYYqtv85oVq4 no9+5+V7xnhPBay/9z80jwiOtdx9zrs65dFwYEM2pC2QHU8GInEGdqeyI/M4exsuZp1a 0hUrppzvCxsncU7+3wrTJT/QWowMKsazDK5evXvZnQe5iZ/oO3MsvQwBQ+qRE8GfgpTk xsijmJShA+Wr+A0aYZN1GLkOKVVbVEzaAMFLX8Y1TK4wybiVQErKAPaIn1IpOVa3Ih9s 6h8Q== X-Gm-Message-State: ALoCoQnpLF/BWLmhr8fGeTuCi5rqqTmAry4w2XGUWhQcoF+jQmAFhV0FxObW3YLooPGarXagccQn MIME-Version: 1.0 X-Received: by 10.152.19.7 with SMTP id a7mr36298616lae.16.1421070526043; Mon, 12 Jan 2015 05:48:46 -0800 (PST) Received: by 10.25.84.145 with HTTP; Mon, 12 Jan 2015 05:48:46 -0800 (PST) In-Reply-To: <54B2EE69.7020807@gmail.com> References: <54B2EE69.7020807@gmail.com> Date: Mon, 12 Jan 2015 08:48:46 -0500 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=089e01494268e7efbe050c74c337 Archived-At: Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] [BEHAVE] NAT MIB scope 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, 12 Jan 2015 13:48:50 -0000 --089e01494268e7efbe050c74c337 Content-Type: text/plain; charset=UTF-8 Since the beginning I've always said that configuring the NAT with SNMP was out of scope. The problem I see is not related to SNMP vs Yang, even though Yang might be a much better choice. The problem is that NAT implementations vary very much and their configuration even more so. It might be hard to find common functionality worth standardizing. Simon On Sun, Jan 11, 2015 at 4:43 PM, Tom Taylor wrote: > Given present policies regarding the respective roles of SNMP and Yang, is > it reasonable to say that the only configuration data that should be > present in the NAT MIB is data directly relating to the control or > interpretation of the remaining contents (i.e., the notifications, state > information, and statistics)? > > I can see a Yang module for NAT configuration in my possible future. > > Tom Taylor > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --089e01494268e7efbe050c74c337 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since the beginning I've always said that configuring = the NAT with SNMP was out of scope.

The problem I see is= not related to SNMP vs Yang, even though Yang might be a much better choic= e. The problem is that NAT implementations vary very much and their configu= ration even more so. It might be hard to find common functionality worth st= andardizing.

Simon

On Sun, Jan 11, 2015 at 4:43 PM, Tom = Taylor <tom.taylor.stds@gmail.com> wrote:
Given present policies regarding the respective rol= es of SNMP and Yang, is it reasonable to say that the only configuration da= ta that should be present in the NAT MIB is data directly relating to the c= ontrol or interpretation of the remaining contents (i.e., the notifications= , state information, and statistics)?

I can see a Yang module for NAT configuration in my possible future.

Tom Taylor

_______________________________________________
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

--089e01494268e7efbe050c74c337-- From nobody Mon Jan 12 09:06:23 2015 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 5E35E1AC3EE for ; Mon, 12 Jan 2015 09:06:15 -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 EZJBt6aODFIA; Mon, 12 Jan 2015 09:06:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AB51ACD0B; Mon, 12 Jan 2015 09:06:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-use-cases.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112170610.15678.69871.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 09:06:10 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: 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: Mon, 12 Jan 2015 17:06:17 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Mon Jan 12 09:06:53 2015 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 B927B1ACD14 for ; Mon, 12 Jan 2015 09: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 D5qH0NcbeX0N; Mon, 12 Jan 2015 09:06:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 478421AC3E0; Mon, 12 Jan 2015 09:06:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112170617.15678.70488.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 09:06:17 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: 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: Mon, 12 Jan 2015 17:06:43 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ From nobody Wed Jan 14 00:09:02 2015 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 2EE471ACE47; Wed, 14 Jan 2015 00:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 WkIxdi2WV3OX; Wed, 14 Jan 2015 00:08:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D891ACE6F; Wed, 14 Jan 2015 00:08:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114080828.7009.85143.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 00:08:28 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [OPSAWG] Last Call Expired: 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, 14 Jan 2015 08:08:50 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Wed Jan 14 00:09:11 2015 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 C48951A9067; Wed, 14 Jan 2015 00:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 h_grN_Wf9Tx7; Wed, 14 Jan 2015 00:08:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 617DB1A8F40; Wed, 14 Jan 2015 00:08:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-use-cases.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114080829.7009.92608.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 00:08:29 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [OPSAWG] Last Call Expired: 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, 14 Jan 2015 08:08:58 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Wed Jan 14 14:10:56 2015 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 690DB1ACDF5 for ; Wed, 14 Jan 2015 14:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 R7yPaivSriWx for ; Wed, 14 Jan 2015 14:10:43 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A746F1ACD91 for ; Wed, 14 Jan 2015 14:10:42 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so11360868wes.10 for ; Wed, 14 Jan 2015 14:10:41 -0800 (PST) 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:content-type; bh=RWSZ4b1jSprxINo9yXf2ImGYvEfnDPsdaAqSV8l1Lno=; b=I8s9irXnnpRXHaO1I6GQTMeHbPYMX3O8JmBjqTgBP5ltBrtj0rsLKI1TMdBBsmZDwp PcUIsa02YHz1FGGTMOnA5uAOxIQsl1dDspY940k480l7WG8J3t0Jl6xIRHsfHWvwkIP1 abUGUYchHMyaIJNJhCtXzH/eeqYmKKeAlReIPX7Z03zbxN3Xug8UJCyFjH9l40Hbzt/u wij7e1gnLFTA/NpMZlrwL+GL3oWPSaDRQMYv5nJIGo/jI0041Ry4nl81bRRFkhMlmq9I ZmFNdxLqL2CURO+ee37uMJfF+LaNQNR6/SeS94D5irNAeCicWOidOHTPzHqGREqsm3PO Y2GQ== X-Gm-Message-State: ALoCoQlOmXXI/gA8NYrdFiBFd92sojhage2ZdChJetSkajYwONNB8E/N2HdJhexPiFA1SWP1IBy4 MIME-Version: 1.0 X-Received: by 10.180.91.36 with SMTP id cb4mr53251573wib.30.1421273441390; Wed, 14 Jan 2015 14:10:41 -0800 (PST) Received: by 10.194.78.77 with HTTP; Wed, 14 Jan 2015 14:10:41 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 17:10:41 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 14 Jan 2015 22:10:45 -0000 Just a reminder that this closes in a week... W On Wed, Jan 7, 2015 at 5:18 PM, Warren Kumari wrote: > Dear OpsAWG, > > This starts a Call for Adoption for draft-opsawg-operators-ietf. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ > > Please review this draft to see if you think it is suitable for > adoption by OpsAWG, > and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends Wed 21-Jan-2015. > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > If you are personally aware of any IPR that applies to > draft-opsawg-operators-ietf, has this IPR been disclosed in compliance > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > details.) > > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) > > > -- > 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 -- 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 From nobody Wed Jan 14 14:34:25 2015 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 4A9421ACEA3 for ; Wed, 14 Jan 2015 14:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DRyYj9LItcW1 for ; Wed, 14 Jan 2015 14:34:19 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9581ACEA4 for ; Wed, 14 Jan 2015 14:34:18 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0EMYGkh017872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2015 17:34:17 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t0EMYGkh017872 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1421274857; bh=BVTOQPEOznNoCVCO/Jaki0gNUWQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=WqRBewok95w4Pvc1EHquIHc9gbVREJIoG5RoGyvi2OMJc7cF8m1qFkUg9dIHQNCn5 5RSFFgcX92162yaIP1mB+5+0sEmSkxDO1l3E7qUB/PSCZmLMH+F92uzGb9guLNVnGQ BUyX+bhu9mNklE4b8Jpk0H3c+ttCu6vFJT0A8VSw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t0EMYGkh017872 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 14 Jan 2015 17:32:26 -0500 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0EMY6od031670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Jan 2015 17:34:06 -0500 Received: from MXHUB101.corp.emc.com (10.253.50.15) by mxhub28.corp.emc.com (10.254.110.184) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 14 Jan 2015 17:34:06 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB101.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 17:34:05 -0500 From: "Black, David" To: Warren Kumari , "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf Thread-Index: AQHQKsfdvQz/lZehfUuwJ6WO9r0McZy1l3SAgAAFzwCAAInOgIAA0qkAgAlCThA= Date: Wed, 14 Jan 2015 22:34:04 +0000 Message-ID: References: <20150107225223.GA14477@elstar.local> <20150108072623.GB15231@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.54.65] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public, GIS Solicitation Archived-At: Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 14 Jan 2015 22:34:23 -0000 Warren wrote: > ... and I thought we should adopt this, have a very short discussion > on the results, and then quickly move to WGLC and publish it. Having > survey results (which show a number of issues, some obvious and some > surprising) as an OpsAWG document makes it clear that this is > something that we (the IETF and OpsAWG in particular) are actually > paying attention to, and are going to try and address. >=20 > The survey results look kinda like a problem statement, and having it > published by OpsAWG gives it a good home, and helps make it clear > where discussions on the "solutions" are welcome. Hmm - I would support adoption if the WG chairs intend to make this draft actually look like a problem statement, not just kinda. This could be done, by planning to add a small amount of material summarizing the problem at the end of the draft ... where Section 5 is already effectively a placeholder awaiting addition of that sort of material. I have a hard time supporting draft adoption for the sole purpose of rubber-stamping the draft with the WG's imprimatur, with effectively no work on the draft occurring in the WG. Thanks, --David (who has two drafts with operator co-authors) > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari > Sent: Thursday, January 08, 2015 3:00 PM > To: Juergen Schoenwaelder; Chris Grundemann; Warren Kumari; opsawg@ietf.o= rg; > draft-opsawg-operators-ietf@tools.ietf.org > Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf >=20 > On Thu, Jan 8, 2015 at 2:26 AM, Juergen Schoenwaelder > wrote: > > On Wed, Jan 07, 2015 at 11:13:10PM +0000, Chris Grundemann wrote: > >> On 1/7/15, 3:52 PM, "Juergen Schoenwaelder" > >> wrote: > >> > >> >On Wed, Jan 07, 2015 at 05:18:12PM -0500, Warren Kumari wrote: > >> >> Dear OpsAWG, > >> >> > >> >> This starts a Call for Adoption for draft-opsawg-operators-ietf. > >> >> > >> >> The draft is available here: > >> >> https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ > >> >> > >> > > >> >The I-D reports results from a survey. It is not a technical > >> >specification that a working group can work on. > >> > >> The work intended is to further analyze the results and the situation = they > >> describe to identify additional solutions that may be actionable. Thes= e > >> potential actions may come from the IETF, the Operator communities aro= und > >> the world, or possibly the ISOC. > >> > >> Simply reporting that we have found a set of problems is only part of = the > >> goal for this document. From the abstract: > >> > >> "The primary purpose of doing this is to start a conversation which we > >> hope will lead to increases in the level of operational input and feed= back > >> to the IETF standards making process." > >> > >> >My recommendation would be to change the title to be more specific > >> >that this document is a survey report and then to submit this documen= t > >> >as an individual submission to the RFC editor for publication. I do > >> >not see that a WG process can add value to the survey report. > >> > >> We, the authors, considered that path (and had several ADs offer to > >> sponsor the I-D as well). We believe however that this is absolutly on= e > >> type of work the OpsAWG should take on: Building the intellectual capi= tal > >> of the IETF by making it easier and more likely for implementors (read= : > >> operators) to participate. > >> > > > > The survey report is one thing, possible actions to change the > > situation are another thing. I prefer to not mix those two together. > > For example, how do we determine that "making it easier and more > > likely for implementors (read: operators) to participate" has been > > achieved? I am not saying this discussion is not worthwhile, do not > > get me wrong on that. But I do not think that making this document a > > WG document is useful. My preference still is to publish the survey > > via the individual stream and discuss any possible actions to change > > the situation separately. OPSAWG should allocate time for this > > discussion, I do not think the survery report has to become an OPSAWG > > working group item for having this discussion. >=20 > ... and I thought we should adopt this, have a very short discussion > on the results, and then quickly move to WGLC and publish it. Having > survey results (which show a number of issues, some obvious and some > surprising) as an OpsAWG document makes it clear that this is > something that we (the IETF and OpsAWG in particular) are actually > paying attention to, and are going to try and address. >=20 > The survey results look kinda like a problem statement, and having it > published by OpsAWG gives it a good home, and helps make it clear > where discussions on the "solutions" are welcome. Concerns about the > lack of operator input are not new - there have been rumblings about > it for a long, long time; making it clear that we are actually taking > this seriously, and are trying to address the issue is important. IMO, > Independent Submissions does not give that impression - for various > reasons people have the idea that IS is a stream for non-IETF > documents, or things that someone somewhere thought were vaguely > interesting, and the IETF didn't care enough about to squash or > champion. >=20 >=20 > Much of this is not a technical argument, but rather a touchy feely, > marketing argument... > W >=20 >=20 >=20 >=20 > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 >=20 >=20 >=20 > -- > 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 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Jan 14 14:44:25 2015 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 921581ACEDC; Wed, 14 Jan 2015 14:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 9qcIfOkL9kZy; Wed, 14 Jan 2015 14:44:03 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1252E1ACEC9; Wed, 14 Jan 2015 14:44:03 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3F0CE180448; Wed, 14 Jan 2015 14:43:14 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150114224314.3F0CE180448@rfc-editor.org> Date: Wed, 14 Jan 2015 14:43:14 -0800 (PST) Archived-At: Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 7424 on Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks 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, 14 Jan 2015 22:44:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7424 Title: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks Author: R. Krishnan, L. Yong, A. Ghanwani, N. So, B. Khasnabish Status: Informational Stream: IETF Date: January 2015 Mailbox: ramkri123@gmail.com, lucy.yong@huawei.com, anoop@alumni.duke.edu, ningso@yahoo.com, vumip1@gmail.com Pages: 29 Characters: 60733 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-large-flow-load-balancing-15.txt URL: https://www.rfc-editor.org/info/rfc7424 Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jan 14 16:01:09 2015 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 51C271AD0AB for ; Wed, 14 Jan 2015 16:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gS1AEAi8dPtd for ; Wed, 14 Jan 2015 16:01:04 -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 0011C1AD0A2 for ; Wed, 14 Jan 2015 16:01:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOB04216; Thu, 15 Jan 2015 00:01:00 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 Jan 2015 00:00:58 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Wed, 14 Jan 2015 16:00:53 -0800 From: Linda Dunbar To: "Black, David" , Warren Kumari , "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf Thread-Index: AQHQKsfddwDvm3pADU62KQKsPUrJsJy1l3SAgAAFzwCAAInOgIAA0qkAgAlCThCAABoa4A== Date: Thu, 15 Jan 2015 00:00:53 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645E91358@dfweml701-chm> References: <20150107225223.GA14477@elstar.local> <20150108072623.GB15231@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 15 Jan 2015 00:01:07 -0000 Agree with what David said. As of the now the "survey questions and answers= " described in the draft doesn't have any tangible actions/impacts.=20 Linda -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Black, David Sent: Wednesday, January 14, 2015 4:34 PM To: Warren Kumari; opsawg@ietf.org; draft-opsawg-operators-ietf@tools.ietf.= org Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf Warren wrote: > ... and I thought we should adopt this, have a very short discussion=20 > on the results, and then quickly move to WGLC and publish it. Having=20 > survey results (which show a number of issues, some obvious and some > surprising) as an OpsAWG document makes it clear that this is=20 > something that we (the IETF and OpsAWG in particular) are actually=20 > paying attention to, and are going to try and address. >=20 > The survey results look kinda like a problem statement, and having it=20 > published by OpsAWG gives it a good home, and helps make it clear=20 > where discussions on the "solutions" are welcome. Hmm - I would support adoption if the WG chairs intend to make this draft a= ctually look like a problem statement, not just kinda. This could be done,= by planning to add a small amount of material summarizing the problem at t= he end of the draft ... where Section 5 is already effectively a placeholde= r awaiting addition of that sort of material. I have a hard time supporting draft adoption for the sole purpose of rubber= -stamping the draft with the WG's imprimatur, with effectively no work on t= he draft occurring in the WG. Thanks, --David (who has two drafts with operator co-authors) > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren=20 > Kumari > Sent: Thursday, January 08, 2015 3:00 PM > To: Juergen Schoenwaelder; Chris Grundemann; Warren Kumari;=20 > opsawg@ietf.org; draft-opsawg-operators-ietf@tools.ietf.org > Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf >=20 > On Thu, Jan 8, 2015 at 2:26 AM, Juergen Schoenwaelder=20 > wrote: > > On Wed, Jan 07, 2015 at 11:13:10PM +0000, Chris Grundemann wrote: > >> On 1/7/15, 3:52 PM, "Juergen Schoenwaelder" > >> wrote: > >> > >> >On Wed, Jan 07, 2015 at 05:18:12PM -0500, Warren Kumari wrote: > >> >> Dear OpsAWG, > >> >> > >> >> This starts a Call for Adoption for draft-opsawg-operators-ietf. > >> >> > >> >> The draft is available here: > >> >> https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ > >> >> > >> > > >> >The I-D reports results from a survey. It is not a technical=20 > >> >specification that a working group can work on. > >> > >> The work intended is to further analyze the results and the=20 > >> situation they describe to identify additional solutions that may=20 > >> be actionable. These potential actions may come from the IETF, the=20 > >> Operator communities around the world, or possibly the ISOC. > >> > >> Simply reporting that we have found a set of problems is only part=20 > >> of the goal for this document. From the abstract: > >> > >> "The primary purpose of doing this is to start a conversation which=20 > >> we hope will lead to increases in the level of operational input=20 > >> and feedback to the IETF standards making process." > >> > >> >My recommendation would be to change the title to be more specific=20 > >> >that this document is a survey report and then to submit this=20 > >> >document as an individual submission to the RFC editor for=20 > >> >publication. I do not see that a WG process can add value to the surv= ey report. > >> > >> We, the authors, considered that path (and had several ADs offer to=20 > >> sponsor the I-D as well). We believe however that this is absolutly=20 > >> one type of work the OpsAWG should take on: Building the=20 > >> intellectual capital of the IETF by making it easier and more likely f= or implementors (read: > >> operators) to participate. > >> > > > > The survey report is one thing, possible actions to change the=20 > > situation are another thing. I prefer to not mix those two together. > > For example, how do we determine that "making it easier and more=20 > > likely for implementors (read: operators) to participate" has been=20 > > achieved? I am not saying this discussion is not worthwhile, do not=20 > > get me wrong on that. But I do not think that making this document a=20 > > WG document is useful. My preference still is to publish the survey=20 > > via the individual stream and discuss any possible actions to change=20 > > the situation separately. OPSAWG should allocate time for this=20 > > discussion, I do not think the survery report has to become an=20 > > OPSAWG working group item for having this discussion. >=20 > ... and I thought we should adopt this, have a very short discussion=20 > on the results, and then quickly move to WGLC and publish it. Having=20 > survey results (which show a number of issues, some obvious and some > surprising) as an OpsAWG document makes it clear that this is=20 > something that we (the IETF and OpsAWG in particular) are actually=20 > paying attention to, and are going to try and address. >=20 > The survey results look kinda like a problem statement, and having it=20 > published by OpsAWG gives it a good home, and helps make it clear=20 > where discussions on the "solutions" are welcome. Concerns about the=20 > lack of operator input are not new - there have been rumblings about=20 > it for a long, long time; making it clear that we are actually taking=20 > this seriously, and are trying to address the issue is important. IMO,=20 > Independent Submissions does not give that impression - for various=20 > reasons people have the idea that IS is a stream for non-IETF=20 > documents, or things that someone somewhere thought were vaguely=20 > interesting, and the IETF didn't care enough about to squash or=20 > champion. >=20 >=20 > Much of this is not a technical argument, but rather a touchy feely,=20 > marketing argument... > W >=20 >=20 >=20 >=20 > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 >=20 >=20 >=20 > -- > I don't think the execution is relevant when it was obviously a bad=20 > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing=20 > regret at having chosen those particular rabid weasels and that pair=20 > of pants. > ---maf >=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 Thu Jan 15 02:19:15 2015 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 644441B2BD4 for ; Thu, 15 Jan 2015 02:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 mNLsLLaCCh9e for ; Thu, 15 Jan 2015 02:19:11 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBAF1B2BCE for ; Thu, 15 Jan 2015 02:19:11 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id BF64F1A00A0; Thu, 15 Jan 2015 11:18:59 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 46S1v8ShyY5U; Thu, 15 Jan 2015 11:18:58 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 2EB521A009A; Thu, 15 Jan 2015 11:18:58 +0100 (CET) Received: from [172.16.40.201] (172.16.40.201) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 15 Jan 2015 11:19:06 +0100 Message-ID: <54B79418.2080709@secunet.com> Date: Thu, 15 Jan 2015 11:19:04 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: , References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> In-Reply-To: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.40.201] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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: Thu, 15 Jan 2015 10:19:13 -0000 Warren, Scott, just one comment was received on the new draft (from David). Shall I revise the document accordingly and resubmit so that we can go for LC? Johannes internet-drafts@ietf.org schrieb am 12.12.2014 um 23:30: > > 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 : HMAC-SHA-2 Authentication Protocols in USM for SNMP > Authors : Johannes Merkle > Manfred Lochter > Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt > Pages : 13 > Date : 2014-12-12 > > Abstract: > This memo specifies new HMAC-SHA-2 authentication protocols for the > User-based Security Model (USM) for SNMPv3 defined in RFC 3414. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-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/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > From nobody Fri Jan 16 13:21:16 2015 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 F13D31B2C58 for ; Fri, 16 Jan 2015 13:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 n65KhIlv-iJU for ; Fri, 16 Jan 2015 13:21:12 -0800 (PST) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040221B2C56 for ; Fri, 16 Jan 2015 13:21:12 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id w62so22336062wes.11 for ; Fri, 16 Jan 2015 13:21:10 -0800 (PST) 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=n54VU4La3fEB3PaY/Sa3xARwUUUv0QJooKxj3A4Ja3c=; b=JuLaK99EaFy6rX0teXMHy7ghh2ajgGPibQCYM+Xl0l+mQymQO3BsC1NPABD2+2jjVh 0DkiYDY2YQ4QPozBgpXGai8gQO0oxACQ5hpEFDvUf3zhtdfbpxc6HpTKO3IawnIFLAW9 MOOb1BDYR8Q1ymwt5uj8pwygeyms0gqqfG7sc24DrPy33uNscXMsZuOscKt3xWj72xbA itRmgIJDZvpPhSScR1tunvp63+NPokUXWlUPZi0TmMBdaJUGEsfc3znlC4sv1hNniV9g o2Ecr9CuW4hFV5CSc2+xJYaOv7ZXcbTKStRDEJUhXUx/dtnmTbeytFl5dQpVNhYHJOYM pqow== X-Gm-Message-State: ALoCoQmVfqgaH52J0uL8zpXbuNaVR3p9B1f8fFXwJqm13ZqHvMPYwUop0AVMjHp7Y33hD5oSx6DZ MIME-Version: 1.0 X-Received: by 10.180.21.225 with SMTP id y1mr9956167wie.42.1421443270747; Fri, 16 Jan 2015 13:21:10 -0800 (PST) Received: by 10.194.78.77 with HTTP; Fri, 16 Jan 2015 13:21:10 -0800 (PST) In-Reply-To: <54B79418.2080709@secunet.com> References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> Date: Fri, 16 Jan 2015 16:21:10 -0500 Message-ID: From: Warren Kumari To: Johannes Merkle Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" , Scott Bradner Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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, 16 Jan 2015 21:21:14 -0000 Yup, please revise the document to address David's comment. There was a fair bit of discussion around this document before it was adopted, and so it did get a fair bit of review then, but some more would be even better... We could get that at LC, but getting that before WGLC would be nicer -- so, can some folk please volunteer to review? If we don't get any volunteers in the next week or two we'll force the issue by going to LC... so, y'all can read it now, or you can read it later. Now would be better :-) W On Thu, Jan 15, 2015 at 5:19 AM, Johannes Merkle wrote: > Warren, Scott, > > just one comment was received on the new draft (from David). Shall I revise the document accordingly and resubmit so > that we can go for LC? > > Johannes > > > internet-drafts@ietf.org schrieb am 12.12.2014 um 23:30: >> >> 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 : HMAC-SHA-2 Authentication Protocols in USM for SNMP >> Authors : Johannes Merkle >> Manfred Lochter >> Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt >> Pages : 13 >> Date : 2014-12-12 >> >> Abstract: >> This memo specifies new HMAC-SHA-2 authentication protocols for the >> User-based Security Model (USM) for SNMPv3 defined in RFC 3414. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-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/ >> >> _______________________________________________ >> 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 From nobody Sun Jan 18 00:23:22 2015 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 440E01ACEC6; Sun, 18 Jan 2015 00:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YToQs_iZotT1; Sun, 18 Jan 2015 00:23:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BBE1ACEC4; Sun, 18 Jan 2015 00:23:08 -0800 (PST) Received: from [192.168.2.105] ([79.246.26.186]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQR3s-1YKLHp1LH2-00TiOk; Sun, 18 Jan 2015 09:23:05 +0100 Message-ID: <54BB6D67.6010509@gmx.net> Date: Sun, 18 Jan 2015 09:23:03 +0100 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lime@ietf.org, OPSAWG@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QcyDAZFSqoju872xTdyeg4dy4BFig/VXqBuwQDwGI+ssuT7Efyo 1b7cdKgDr8lVz59qGDvnMy57RDEArfiJv2RTwblz9U4TcSzIONCguroFy6jCvHABYcoIjyl 5T2Gkz18tniTyJh8F5dympUHVfhHIo0Wzr/+/5vhw4uwU3VsYOiFI0ahm0uPeh2NqM1iFP1 LGpxi+bCb/BhJsHBkVlew== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [OPSAWG] Internet Draft: Standardized Parameterization of Intrusion Detection Entities 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, 18 Jan 2015 08:23:16 -0000 Dear Community, Efficiency of Intrusion Detection Systems (IDS) depends on their configuration and coverage of services. The coverage depends on used IDS with currently vendor-specific configurations. In case of usage of multiple systems the operations could become complex. Individual Communication between management interface and the IDS entities results that current multi-vendor IDS architectures do not interact with each other. They are independent coexistent. The Internet Draft defines data formats and exchange procedures to standardize parametrization information exchange into intrusion detection and response systems from a Manager to an Analyzer. The created Intrusion Detection Parametrization Exchange Format (IDPEF) is intended to be a standard data format to parametrize IDS. The development of this open standardized format and the Intrusion Detection Message Exchange Format (IDMEF) will be enable in combination interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal IDS implementation. The most obvious place to implement IDPEF is in the data channel between a Manager and an Analyzer of an IDS within this data channel where the Manager sends the configuration parameters to the Analyzers. But there are other places where the IDPEF can be useful: - Combination of specialized IDS like application-IDS with server-IDS, WLAN-IDS and network-IDS to one functional interacting meta-IDS. - Management of different IDS vendors with one central management interface. - Interaction of different IDS by using IDPEF and IDMEF. - Parametrization backups and restore of parametrized IDS entities. - For a communication between a Manager and a Manager in a multi-stage management architecture. I am happy to invite you to give me feedback, suggestions, notations, hints, recommendations, etc. to improve the Internet Draft. The initial version of the Internet Draft could be found at: http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt Kind regards, B.-C. Boesch From nobody Sun Jan 18 19:57:36 2015 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 CAF501AD0B1; Sun, 18 Jan 2015 19:57:33 -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 5kWSfU_snfYA; Sun, 18 Jan 2015 19:57:29 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001: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 C0A9C1AD0AD; Sun, 18 Jan 2015 19:57:28 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so4560129igk.1; Sun, 18 Jan 2015 19:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZVEM48L1r3kgZx7gnUfqhi/KjORcXJY1lLHgfImzBHM=; b=WIRwwabymsffDNvi03HHj7QM0x2+4vltP016lBOAe6gou/tEcWRL2xfUtrONegIu6B ErsterzmoaKxiOrrIFyfT7eu4MQSQHo9ieJSt+Ud2o1sneFbcXYZS25nRVukxBmTfjse HLzQehiQpXuw079VbUHTG2/DpxVi5rgbnONP5zj1V/JGoR91rNeoBPzOiE7XBNEGvSCf JJ088+/2/g0E9r6Kz9NW4Su6WPRl9uyvzwgNcbw9BF9u4BEUbVLWAFCbZenxkDiDPEeC 0kQR3bZCbmzjVe1XQHC7BW8Uauhp+vOEhpEXhAvrpmdiSP5A1cLWTsZqGy38RpMKAjdc fFlg== X-Received: by 10.50.107.7 with SMTP id gy7mr16899690igb.49.1421639847941; Sun, 18 Jan 2015 19:57:27 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-8-163.tor.primus.ca. [173.206.8.163]) by mx.google.com with ESMTPSA id i37sm4803076iod.6.2015.01.18.19.57.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jan 2015 19:57:27 -0800 (PST) Message-ID: <54BC8093.7030104@gmail.com> Date: Sun, 18 Jan 2015 22:57:07 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" , David Harrington , Spencer Dawkins References: <20150119034503.15593.74413.idtracker@ietfa.amsl.com> In-Reply-To: <20150119034503.15593.74413.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150119034503.15593.74413.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] Fwd: New Version Notification for draft-perrault-behave-natv2-mib-00.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: Mon, 19 Jan 2015 03:57:34 -0000 Several months' work, almost done. A couple of sections need work, as indicated in the document, but there's lots to review including the complete MIB module definition. This is a major rewrite from the draft-ietf-behave-nat-11 version of NAT MIB. Reworking was needed to address all the issues outstanding against that document. I suppose the next step is to send out a series of messages walking through all the changes from draft-ietf-behave-nat-11 and how they respond to the open issues. I look forward to any comments on the new document. Tom Taylor -------- Forwarded Message -------- Subject: New Version Notification for draft-perrault-behave-natv2-mib-00.txt Date: Sun, 18 Jan 2015 19:45:03 -0800 From: internet-drafts@ietf.org .... A new version of I-D, draft-perrault-behave-natv2-mib-00.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Name: draft-perrault-behave-natv2-mib Revision: 00 Title: Definitions of Managed Objects for Network Address Translators (NAT) Document date: 2015-01-18 Group: Individual Submission Pages: 80 URL: http://www.ietf.org/internet-drafts/draft-perrault-behave-natv2-mib-00.txt Status: https://datatracker.ietf.org/doc/draft-perrault-behave-natv2-mib/ Htmlized: http://tools.ietf.org/html/draft-perrault-behave-natv2-mib-00 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function. The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document. A companion document deprecates all objects in NAT- MIB. NATV2-MIB can be used for monitoring of NAT instances on a device capable of NAT function. Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN). 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 Mon Jan 19 02:05:30 2015 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 07DD71B29D0; Mon, 19 Jan 2015 02:05:26 -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 FSsGdDvEQWpM; Mon, 19 Jan 2015 02:05:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E34921B29C2; Mon, 19 Jan 2015 02:05:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119100524.1672.96560.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 02:05:24 -0800 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-coman-use-cases-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: Mon, 19 Jan 2015 10:05:26 -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 Working Group of the IETF. Title : Management of Networks with Constrained Devices: Use Cases Authors : Mehmet Ersue Dan Romascanu Juergen Schoenwaelder Anuj Sehgal Filename : draft-ietf-opsawg-coman-use-cases-04.txt Pages : 29 Date : 2015-01-19 Abstract: This document discusses use cases concerning the management of networks, where constrained devices are involved. A problem statement, deployment options and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-coman-use-cases-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 Mon Jan 19 02:05:32 2015 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 338951B29D0 for ; Mon, 19 Jan 2015 02:05:27 -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 dXBO51L8ogfV; Mon, 19 Jan 2015 02:05:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6AB1B29C8; Mon, 19 Jan 2015 02:05:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-use-cases.all@tools.ietf.org, opsawg-chairs@tools.ietf.org, joelja@bogus.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119100525.1672.60689.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 02:05:25 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-ietf-opsawg-coman-use-cases-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: Mon, 19 Jan 2015 10:05:27 -0000 A new version (-04) has been submitted for draft-ietf-opsawg-coman-use-cases: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-coman-use-cases-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-coman-use-cases-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. IETF Secretariat. From nobody Mon Jan 19 03:43:25 2015 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 270941B2A35; Mon, 19 Jan 2015 03:43: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 iHgt-4gUgqPL; Mon, 19 Jan 2015 03:43:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CC41B2A18; Mon, 19 Jan 2015 03:43:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119114319.17648.60823.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 03:43:19 -0800 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-01.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: Mon, 19 Jan 2015 11:43:21 -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 Working Group of the IETF. Title : HMAC-SHA-2 Authentication Protocols in USM for SNMP Authors : Johannes Merkle Manfred Lochter Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-01.txt Pages : 13 Date : 2015-01-19 Abstract: This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-01 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 Mon Jan 19 03:43:27 2015 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 5FE8E1B2A18 for ; Mon, 19 Jan 2015 03:43:22 -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 5gIH0xr3qDnu; Mon, 19 Jan 2015 03:43:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7B11B2A29; Mon, 19 Jan 2015 03:43:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: opsawg@ietf.org, draft-ietf-opsawg-hmac-sha-2-usm-snmp.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119114320.17648.69814.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 03:43:20 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-ietf-opsawg-hmac-sha-2-usm-snmp-01.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: Mon, 19 Jan 2015 11:43:22 -0000 A new version (-01) has been submitted for draft-ietf-opsawg-hmac-sha-2-usm-snmp: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-hmac-sha-2-usm-snmp-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-01 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. IETF Secretariat. From nobody Mon Jan 19 05:02:08 2015 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 59BD91B2A57; Mon, 19 Jan 2015 05:02: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 VAsU1NMXAGUE; Mon, 19 Jan 2015 05:02:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F911B2A66; Mon, 19 Jan 2015 05:01:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119130157.6974.72444.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 05:01:57 -0800 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-coman-probstate-reqs-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: Mon, 19 Jan 2015 13:02:05 -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 Working Group of the IETF. Title : Management of Networks with Constrained Devices: Problem Statement and Requirements Authors : Mehmet Ersue Dan Romascanu Juergen Schoenwaelder Ulrich Herberg Filename : draft-ietf-opsawg-coman-probstate-reqs-04.txt Pages : 46 Date : 2015-01-19 Abstract: This document provides a problem statement, deployment and management topology options as well as potential requirements for the management of networks where constrained devices are involved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-coman-probstate-reqs-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 Mon Jan 19 05:02:11 2015 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 6C3831B2A5A for ; Mon, 19 Jan 2015 05:02:06 -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 Mf6GcoOQmrLh; Mon, 19 Jan 2015 05:02:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC7F1B2A6A; Mon, 19 Jan 2015 05:01:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@tools.ietf.org, opsawg-chairs@tools.ietf.org, joelja@bogus.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119130157.6974.209.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 05:01:57 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-ietf-opsawg-coman-probstate-reqs-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: Mon, 19 Jan 2015 13:02:06 -0000 A new version (-04) has been submitted for draft-ietf-opsawg-coman-probstate-reqs: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-coman-probstate-reqs-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-coman-probstate-reqs-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. IETF Secretariat. From nobody Tue Jan 20 04:34:15 2015 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 7B3E11B2A32 for ; Tue, 20 Jan 2015 04:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 alNOCW-NKkKp for ; Tue, 20 Jan 2015 04:34:09 -0800 (PST) Received: from postfix.arnes.si (kanin.arnes.si [193.2.1.87]) by ietfa.amsl.com (Postfix) with ESMTP id 346BD1B2A1A for ; Tue, 20 Jan 2015 04:34:09 -0800 (PST) Received: from avs5-arnes.arnes.si (avs5.arnes.si [193.2.1.126]) by postfix.arnes.si (Postfix) with ESMTP id 0389A148027 for ; Tue, 20 Jan 2015 13:34:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arnes.si; h= content-transfer-encoding:content-type:content-type:subject :subject:mime-version:user-agent:organization:from:from:date :date:message-id:received:received:received; s=primus; t= 1421757247; x=1424349248; bh=n6AyXvT0ruRL+7kJMLpJsEF8C/KXumNy79/ yeNO3RHY=; b=BN78yeLqgPLqrs2k3ioXi7EOXJMjxFYZzhMSWHyyAJu8T4bfO5h mbSZqRBECaow4up638S9LNcJ66A4CqwW5ZP0fdRvpZDnJtqBVh/h5TMnAfcqfbFe WNtSyjUtHXbQHxJLyujeONvxXBQK7qNcSWKobVJnJ5y7HV94n3jMkVA4= X-Virus-Scanned: amavisd-new at arnes.si Received: from postfix.arnes.si ([193.2.1.87]) by avs5-arnes.arnes.si (avs5.arnes.si [193.2.1.126]) (amavisd-new, port 10030) with ESMTP id NU8vdNDzflTA for ; Tue, 20 Jan 2015 13:34:07 +0100 (CET) Received: from skala.arnes.si (skala.arnes.si [193.2.1.54]) by postfix.arnes.si (Postfix) with ESMTP id DECE1148003 for ; Tue, 20 Jan 2015 13:34:07 +0100 (CET) Received: from [212.235.168.13] (rok.lemez.arnes.si [212.235.168.13]) by skala.arnes.si (Postfix) with ESMTP id D18F6A40ADA for ; Tue, 20 Jan 2015 13:34:07 +0100 (CET) Message-ID: <54BE4B3F.6050607@arnes.si> Date: Tue, 20 Jan 2015 13:34:07 +0100 From: =?UTF-8?B?Um9rIFBhcGXFvg==?= Organization: ARNES User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [OPSAWG] EAP metadata. YANG to XML and JSON, but which to pick? 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, 20 Jan 2015 12:34:11 -0000 Hello! Arnes (http://www.arnes.si) is developing a Windows EAP plugin wireless supplicant for 802.1x and we are very interested in standardised EAP metadata: https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01 The draft-specification definitions are in YANG and we can derive both XML and JSON format files. Which end format is it better to use: XML or JSON? Supporting (consuming) both would be a duplicate effort we are not going to implement. My personal preference is always JSON over XML. -- regards, Rok Papež. From nobody Tue Jan 20 04:55:31 2015 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 383F81B2DA4 for ; Tue, 20 Jan 2015 04:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 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_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-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 9f6HYL0-oeay for ; Tue, 20 Jan 2015 04:55:26 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B581B2A37 for ; Tue, 20 Jan 2015 04:55:26 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 75CA613F744; Tue, 20 Jan 2015 13:55:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421758524; bh=sKckQLQn3pbWclmHXcvnabmrAzV2q9na8l9LP8SwoRE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gmSFt6/um8GdJMV1vbmxTmrx9vyrVEVhFQztkmN14fCRLCMfudEFjhJQbkwGv35PN ODHv/972W888YzURHMxjz2UUSNAH+Db3kpl4CQt3azRRdq9PSLU//fpdSqwGZOn5fM upmKWjWWH5yuzOWLftQTGP9nYH2rggBFzBnTi74E= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <54BE4B3F.6050607@arnes.si> Date: Tue, 20 Jan 2015 13:55:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9020AFCA-9EC1-4F69-BAA4-10B71FF7EED7@nic.cz> References: <54BE4B3F.6050607@arnes.si> To: =?utf-8?Q?Rok_Pape=C5=BE?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] EAP metadata. YANG to XML and JSON, but which to pick? 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, 20 Jan 2015 12:55:28 -0000 Hi Rok, > On 20 Jan 2015, at 13:34, Rok Pape=C5=BE wrote: >=20 > Hello! >=20 > Arnes (http://www.arnes.si) is developing a Windows EAP plugin = wireless > supplicant for 802.1x and we are very interested in standardised EAP > metadata: > https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01 >=20 > The draft-specification definitions are in YANG and we can derive both > XML and JSON format files. Which end format is it better to use: XML = or > JSON? >=20 > Supporting (consuming) both would be a duplicate effort we are not = going > to implement. My personal preference is always JSON over XML. Tough luck, if you want to use RESTCONF: =E2=80=9CA [RESTCONF] server = MUST support XML encoding and MAY support JSON encoding." = (draft-ietf-netconf-restconf-03). See also this juicy thread in the = NETCONF mailing list: http://www.ietf.org/mail-archive/web/netconf/current/msg09218.html If you don=E2=80=99t plan to use RESTCONF, then choose whichever = encoding suits you better. Lada >=20 > --=20 > regards, > Rok Pape=C5=BE. >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 20 05:40:30 2015 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 26DA51AD1C3 for ; Tue, 20 Jan 2015 05:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 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_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 UQSyGW_YS_Or for ; Tue, 20 Jan 2015 05:40:26 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2CB1B2A18 for ; Tue, 20 Jan 2015 05:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7934; q=dns/txt; s=iport; t=1421761226; x=1422970826; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vGK5ZmmVUU0Uaofj06NDrJvy3D/hPCgO2afaO+FjZN0=; b=bkSbq8eebWTFyNAYaxdtIB8KSM1SjECxXTV9gCno/3rWfwUE4Y0f9EnY dyALClsavoZLaD7omwNPFp7eDIqrTTlKMG7xmhSSvXrI0h9iEC25MtnFp XRRs26PnwWk4M13RjuMewpFOq/uO/JqHiWd6aFDRNUFVZKdU1l3tmrPb8 U=; X-IronPort-AV: E=Sophos;i="5.09,434,1418083200"; d="scan'208";a="319145716" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 20 Jan 2015 13:40:24 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0KDeNIo013381; Tue, 20 Jan 2015 13:40:23 GMT Message-ID: <54BE5AC1.9050901@cisco.com> Date: Tue, 20 Jan 2015 14:40:17 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Scott O. Bradner" References: <54943ED5.6050506@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "opsawg@ietf.org" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship 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, 20 Jan 2015 13:40:29 -0000 Dear draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information authors, Can you please a draft version according to Sri's plan below. Regards, Benoit > wfm > >> On Dec 19, 2014, at 10:05 AM, Benoit Claise wrote: >> >> On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote: >>> Hi Benoit, >>> >>>> Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel with the information elements for CAPWAP (not the others one). >>> The above draft defines number of encapsulation modes and that list includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. Each of those tunnel types can be activated with a set of tunnel parameters. These parameters include source IP, destination IP, sport, dport, GRE key ..etc. To most part this is about identifying a common set of parameters, providing definition for those parameters and grouping the relevant one's for each of the encapsulation modes. Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not radically different from the others and the above common parameter set is sufficient for these modes. To create a tunnel with GRE with IPv4 transport is not any different from GRE with IPv6 transport, or for that matter for IP-in-IP mode. >>> >>> It is to be noted there are no proposed changes to any of these encapsulation modes, or to the control protocols activating those encap modes. Its mostly about activating a tunnel state with a set of parameters. If at all, CAPWAP data plane may be bit complex and even L2TP as its unclear if the control protocol has semantics for the L2TP peers to separate control and data plane. If not, it requires changes to the L2TP protocol. So, its easier to keep CAPWAP + GRE/IP-in-IP modes in the main spec as the work has a well defined scope. >> If it works for the WG, it works for me. Any objections anybody? >> That would imply a new draft and a new consensus call. >> >> Regards, Benoit >>> So, my suggestion is to allow draft-ietf-opsawg-capwap-alt-tunnel to also support GRE/IP-in-IP modes and have draft-xue focus exclusively on L2TP extensions and move it on a fast track. IMO, this is a reasonably split. I'm also happy to provide the text for the above encap modes and ensure the changes do not delay the publication. >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> >>> >>> From: "Benoit Claise (bclaise)" >>> Date: Monday, December 1, 2014 7:37 AM >>> To: "Rajesh Pazhyannur (rpazhyan)" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" >>> Cc: "opsawg@ietf.org" >>> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship >>> >>> Hi Rajesh, >>> >>> I'm concerned that: >>> - draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution >>> - draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from draft-xue-opsawg-capwap-alt-tunnel-information, an individual draft. >>> - draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different tunnel types, and required expertise from many different group. This might take some time... >>> >>> Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel with the information elements for CAPWAP (not the others one). This way, this draft would be a complete solution. >>> And if people wants alternate tunnel types, this would be done in draft-xue-opsawg-capwap-alt-tunnel-information >>> >>> Regards, Benoit >>> >>>> Hello >>>> >>>> I realized there was a typographical error in my response below. >>>> Please see corrections. >>>> >>>> Regards >>>> >>>> Rajesh >>>> From: Rajesh Pazhyannur >>>> Date: Thursday, November 20, 2014 at 12:30 AM >>>> To: "Benoit Claise (bclaise)" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" >>>> Cc: "opsawg@ietf.org" >>>> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>> >>>> Hi Benoit >>>> >>>> But now I wonder: why do we have two different drafts, as opposed to a single one? >>>> >>>> This is a good question. >>>> >>>> [original] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution and needs something like draft-ietf-opsawg-capwap-alt-tunnel to complete the solution. >>>> [corrected statement] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution and needs something like draft-xue-opsawg-capwap-alt-tunnel-information to complete the solution. >>>> >>>> The best answer I have is that we wanted the keep the following two areas separate (and in different drafts) >>>> • Discover and negotiation of alternate tunneling capability. These are independent of specific alternate tunnel method >>>> • [original] Definition of tunnel specific message elements. While draft-ietf-opsawg-capwap-alt-tunnel contains message elements for most of the tunneling methods defined in draft-ietf-opsawg-capwap-alt-tunnel, I had anticipated separate drafts for each tunneling protocol. >>>> [corrected] 2 Definition of tunnel specific message elements. While draft-ietf-opsawg-capwap-alt-tunnel contains message elements for most of the tunneling methods defined in draft-xue-opsawg-capwap-alt-tunnel-information I had anticipated separate drafts for each tunneling protocol. >>>> >>>> Finishing 1. would allow 2. to be completed separately and independently in potentially different drafts (and potentially different groups with relevant expertise). It is somewhat akin (though not identical) to separation between RFC 5415 and RFC 5416 where RFC 5415 is wireless technology independent and RFC 5416 is 802.11 specific. >>>> >>>> Hope the above makes sense. >>>> >>>> Regards >>>> >>>> Rajesh >>>> From: "Benoit Claise (bclaise)" >>>> Date: Wednesday, November 19, 2014 at 11:50 AM >>>> To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" >>>> Cc: "opsawg@ietf.org" >>>> Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>> >>>> Dear CAPWAP authors, >>>> >>>> After the draft-xue-opsawg-capwap-alt-tunnel-information presentation at the last IETF meeting, I've been wondering about the relationship between the two drafts: >>>> - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types >>>> Note:this draft is currently in AD review, so close to be sent to the IESG. >>>> - draft-xue-opsawg-capwap-alt-tunnel-information provides the encoding of the tunnel-specific fields. >>>> >>>> I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel doesn't provide a complete solution without draft-xue-opsawg-capwap-alt-tunnel-information? >>>> >>>> I'm aware of the changes between version 3 and 4 (attached picture and http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-04.txt) >>>> >>>> But now I wonder: why do we have two different drafts, as opposed to a single one? >>>> >>>> Regards, Benoit >>>> >>>> >>> . >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > . > From nobody Tue Jan 20 08:24:51 2015 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 134831B2E67 for ; Tue, 20 Jan 2015 08:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lHXFuOjNoGBH for ; Tue, 20 Jan 2015 08:24:35 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9C09F1B2E5A for ; Tue, 20 Jan 2015 08:24:34 -0800 (PST) Received: from enterpol.snmp.com (enterpol.snmp.com [192.147.142.3]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA05507 for ; Tue, 20 Jan 2015 11:24:33 -0500 (EST) Received: from enterpol (localhost [127.0.0.1]) by enterpol.snmp.com (8.14.4+Sun/8.12.9/snmpclient.mc-990615) with ESMTP id t0KGOXoq010966 for ; Tue, 20 Jan 2015 11:24:33 -0500 (EST) Message-Id: <201501201624.t0KGOXoq010966@enterpol.snmp.com> To: opsawg@ietf.org From: David Reid In-reply-to: Your message of Mon, 19 Jan 2015 03:43:20 -0800. <20150119114320.17648.69814.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 11:24:33 -0500 Sender: reid@snmp.com Archived-At: Subject: Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-hmac-sha-2-usm-snmp-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 16:24:37 -0000 I read the new version of draft-ietf-opsawg-hmac-sha-2-usm-snmp. It addresses all of my comments. I think it is ready for publication. We have implemented it (using OIDs in our private space for now) and would be willing to do interoperability testing if anyone else wants to. -David Reid > > A new version (-01) has been submitted for draft-ietf-opsawg-hmac-sha-2-usm-snmp: > http://www.ietf.org/internet-drafts/draft-ietf-opsawg-hmac-sha-2-usm-snmp-01.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-01 > > 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. > > IETF Secretariat. > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Jan 20 09:03:57 2015 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 1F82A1B2AE1 for ; Tue, 20 Jan 2015 09:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 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_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 We0bQ49kLaBW for ; Tue, 20 Jan 2015 09:03:52 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D2C1B2AAE for ; Tue, 20 Jan 2015 09:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8723; q=dns/txt; s=iport; t=1421773433; x=1422983033; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LPX3S2IQQNnwLGrBmEwRUautAabjLXgBNiK7uoHOPZ8=; b=ABtluuTrXJ/ke1Lgx353KajlZJW5EYmvu4+ttyLpliWXj+7Gl3rlfN0K LD5LHqP3uW6zZjxga5bNSElnY/2qT+DBtD0kVaQR4Ldu/Z4xJ+Ph2hwb5 huXCu6eXiriqctC0dncns65aZuhnd6Y7bS0uJ0DQK7z39GN4kCK1GFS/d Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFABaKvlStJA2I/2dsb2JhbABbgwZSWATED4IbCoUnSgKBJEMBAQEBAX2EDAEBAQQBAQFoAwQHEAIBCBEDAQIBIwsnCx0IAgQBDQUbiBABDdEjAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49GLgUHBoQjBY5Zg0eFUIEUNoJGjhoigjKBPG+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.09,435,1418083200"; d="scan'208";a="388810065" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jan 2015 17:03:39 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0KH3dHT028101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Jan 2015 17:03:39 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.25]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 11:03:39 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: "Benoit Claise (bclaise)" , "Scott O. Bradner" Thread-Topic: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship Thread-Index: AQHQBDIW9jh9SimcRUm69VAcj2zNTZxpDpEAgBCknoCAAaKAgIACpJUAgBmcgoCAAACmAIAyMgWA//+ys4A= Date: Tue, 20 Jan 2015 17:03:38 +0000 Message-ID: References: <54943ED5.6050506@cisco.com> <54BE5AC1.9050901@cisco.com> In-Reply-To: <54BE5AC1.9050901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [171.70.240.47] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship 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, 20 Jan 2015 17:03:55 -0000 Hi Benoit Yes, I am working on it. I will get you a date by the end of the week of when a draft will be ready. Thanks Rajesh On 1/20/15, 5:40 AM, "Benoit Claise (bclaise)" wrote: >Dear draft-ietf-opsawg-capwap-alt-tunnel and >draft-xue-opsawg-capwap-alt-tunnel-information authors, > >Can you please a draft version according to Sri's plan below. > >Regards, Benoit >> wfm >> >>> On Dec 19, 2014, at 10:05 AM, Benoit Claise wrote: >>> >>> On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote: >>>> Hi Benoit, >>>> >>>>> Let me propose a solution: augment >>>>>draft-ietf-opsawg-capwap-alt-tunnel with the information elements for >>>>>CAPWAP (not the others one). >>>> The above draft defines number of encapsulation modes and that list >>>>includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. >>>>Each of those tunnel types can be activated with a set of tunnel >>>>parameters. These parameters include source IP, destination IP, sport, >>>>dport, GRE key ..etc. To most part this is about identifying a common >>>>set of parameters, providing definition for those parameters and >>>>grouping the relevant one's for each of the encapsulation modes. >>>>Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not >>>>radically different from the others and the above common parameter set >>>>is sufficient for these modes. To create a tunnel with GRE with IPv4 >>>>transport is not any different from GRE with IPv6 transport, or for >>>>that matter for IP-in-IP mode. >>>> >>>> It is to be noted there are no proposed changes to any of these >>>>encapsulation modes, or to the control protocols activating those >>>>encap modes. Its mostly about activating a tunnel state with a >>>>set of parameters. If at all, CAPWAP data plane may be bit complex >>>>and even L2TP as its unclear if the control protocol has semantics for >>>>the L2TP peers to separate control and data plane. If not, it requires >>>>changes to the L2TP protocol. So, its easier to keep CAPWAP + >>>>GRE/IP-in-IP modes in the main spec as the work has a well defined >>>>scope. >>> If it works for the WG, it works for me. Any objections anybody? >>> That would imply a new draft and a new consensus call. >>> >>> Regards, Benoit >>>> So, my suggestion is to allow draft-ietf-opsawg-capwap-alt-tunnel to >>>>also support GRE/IP-in-IP modes and have draft-xue focus exclusively >>>>on L2TP extensions and move it on a fast track. IMO, this is a >>>>reasonably split. I'm also happy to provide the text for the above >>>>encap modes and ensure the changes do not delay the publication. >>>> =20 >>>> >>>> Regards >>>> Sri >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: "Benoit Claise (bclaise)" >>>> Date: Monday, December 1, 2014 7:37 AM >>>> To: "Rajesh Pazhyannur (rpazhyan)" , >>>>"draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >>>>, >>>>"draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" >>>> >>>> Cc: "opsawg@ietf.org" >>>> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and >>>>draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>> >>>> Hi Rajesh, >>>> >>>> I'm concerned that: >>>> - draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete >>>>solution >>>> - draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from >>>>draft-xue-opsawg-capwap-alt-tunnel-information, an individual draft. >>>> - draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different >>>>tunnel types, and required expertise from many different group. This >>>>might take some time... >>>> >>>> Let me propose a solution: augment >>>>draft-ietf-opsawg-capwap-alt-tunnel with the information elements for >>>>CAPWAP (not the others one). This way, this draft would be a complete >>>>solution. >>>> And if people wants alternate tunnel types, this would be done in >>>>draft-xue-opsawg-capwap-alt-tunnel-information >>>> >>>> Regards, Benoit >>>> >>>>> Hello >>>>> >>>>> I realized there was a typographical error in my response below. >>>>> Please see corrections. >>>>> >>>>> Regards >>>>> >>>>> Rajesh >>>>> From: Rajesh Pazhyannur >>>>> Date: Thursday, November 20, 2014 at 12:30 AM >>>>> To: "Benoit Claise (bclaise)" , >>>>>"draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >>>>>, >>>>>"draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" >>>>> >>>>> Cc: "opsawg@ietf.org" >>>>> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and >>>>>draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>>> >>>>> Hi Benoit >>>>> >>>>> But now I wonder: why do we have two different drafts, as opposed to >>>>>a single one? >>>>> >>>>> This is a good question. >>>>> >>>>> [original] Yes, you are correct that >>>>>draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete >>>>>solution and needs something like >>>>>draft-ietf-opsawg-capwap-alt-tunnel to complete the solution. >>>>> [corrected statement] Yes, you are correct that >>>>>draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete >>>>>solution and needs something like >>>>>draft-xue-opsawg-capwap-alt-tunnel-information to complete the >>>>>solution. >>>>> >>>>> The best answer I have is that we wanted the keep the following two >>>>>areas separate (and in different drafts) >>>>> =80 Discover and negotiation of alternate tunneling capability. Thes= e >>>>>are independent of specific alternate tunnel method >>>>> =80 [original] Definition of tunnel specific message elements. While >>>>>draft-ietf-opsawg-capwap-alt-tunnel contains message elements for >>>>>most of the tunneling methods defined in >>>>>draft-ietf-opsawg-capwap-alt-tunnel, I had anticipated separate >>>>>drafts for each tunneling protocol. >>>>> [corrected] 2 Definition of tunnel specific message elements. While >>>>>draft-ietf-opsawg-capwap-alt-tunnel contains message elements for >>>>>most of the tunneling methods defined in >>>>>draft-xue-opsawg-capwap-alt-tunnel-information I had anticipated >>>>>separate drafts for each tunneling protocol. >>>>> >>>>> Finishing 1. would allow 2. to be completed separately and >>>>>independently in potentially different drafts (and potentially >>>>>different groups with relevant expertise). It is somewhat akin >>>>>(though not identical) to separation between RFC 5415 and RFC 5416 >>>>>where RFC 5415 is wireless technology independent and RFC 5416 is >>>>>802.11 specific. >>>>> >>>>> Hope the above makes sense. >>>>> >>>>> Regards >>>>> >>>>> Rajesh >>>>> From: "Benoit Claise (bclaise)" >>>>> Date: Wednesday, November 19, 2014 at 11:50 AM >>>>> To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >>>>>, >>>>>"draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" >>>>> >>>>> Cc: "opsawg@ietf.org" >>>>> Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and >>>>>draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>>> >>>>> Dear CAPWAP authors, >>>>> >>>>> After the draft-xue-opsawg-capwap-alt-tunnel-information >>>>>presentation at the last IETF meeting, I've been wondering about the >>>>>relationship between the two drafts: >>>>> - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types >>>>> Note:this draft is currently in AD review, so close to be sent to >>>>>the IESG. >>>>> - draft-xue-opsawg-capwap-alt-tunnel-information provides the >>>>>encoding of the tunnel-specific fields. >>>>> >>>>> I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel >>>>>doesn't provide a complete solution without >>>>>draft-xue-opsawg-capwap-alt-tunnel-information? >>>>> >>>>> I'm aware of the changes between version 3 and 4 (attached picture >>>>>and=20 >>>>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-capwap-alt-tunn= el >>>>>-04.txt) >>>>> >>>>> But now I wonder: why do we have two different drafts, as opposed to >>>>>a single one? >>>>> >>>>> Regards, Benoit >>>>> >>>>> >>>> . >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >> . >> > From nobody Thu Jan 22 15:39:39 2015 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 735C21A0040; Thu, 22 Jan 2015 15:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 zfMjDnYB6uRf; Thu, 22 Jan 2015 15:39:32 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 D73961A0039; Thu, 22 Jan 2015 15:39:32 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id CD865DA0352; Thu, 22 Jan 2015 23:39:32 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BF2D153E08E; Thu, 22 Jan 2015 15:39:32 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 22 Jan 2015 15:39:32 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54A9B162.1040407@bogus.com> Date: Thu, 22 Jan 2015 18:39:22 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> References: <54A9B162.1040407@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "dhcwg@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 22 Jan 2015 23:39:34 -0000 On Jan 4, 2015, at 4:32 PM, joel jaeggli wrote: > After some dicussion last year, I have agreed to sponsor > draft-wkumari-dhc-capport > (https://tools.ietf.org/html/draft-wkumari-dhc-capport-07). what I'm > looking for feeback on right now is feedback from potential > implementors, either of client implementations of captive portal > detection or captive portals as to: >=20 > * Whether or not this represents a reasonable optimization, >=20 > * Have we gotten the security considerations right? >=20 > * Would you use it if there was general consensus to the approach. I haven't seen any responses to this. I don't expect you'll see any "we = would use this responses," and you shouldn't predicate this work on = seeing any. I think the idea is fine, although I think the requirement = that the URI use an address literal is unnecessary. If the implementor = wants to do that, they can, or they can just only answer DNS queries for = the local domain until the user authenticates. They'd have to do that = to support the redirect anyway. I think the document has way too much explanatory text. It's good that = it's there for now so that people can understand the problem that this = draft purports to solve, but it should not be in the final version. = Just explain how to use DHCP and ND to send this option (I think = supporting it in ND is worthwhile, because DHCP isn't really very useful = in an IPv6 hotspot environment). It would be nice to talk about ways to authenticate this, e.g. PKI or = DNSSEC certs. I think you should run it by some people with HTTP fu to make sure that = you haven't missed any obvious gaps, and of course run it by somebody = with HTTP security fu to make sure there aren't any security flaws that = need to be addressed. I would not object to you AD-sponsoring this. It's not in-charter for = DHC, nor for 6man. You should get it reviewed in both places, not just = in DHC. You may find section 5.7 of RFC 7227 useful: it would be good to make = sure that your use of the DHCP URI option format meshes with what RFC = 7227 does. I didn't notice a problem, but didn't look all that = carefully. From nobody Thu Jan 22 21:44:25 2015 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 D13FB1A1A25; Thu, 22 Jan 2015 21:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 LCa4B9xXeBPU; Thu, 22 Jan 2015 21:44:02 -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 9E5FB1A026A; Thu, 22 Jan 2015 21:44:02 -0800 (PST) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t0N5i1cv021406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 Jan 2015 05:44:02 GMT (envelope-from joelja@bogus.com) Message-ID: <54C1DF9A.40404@bogus.com> Date: Thu, 22 Jan 2015 21:43:54 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Ted Lemon References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> In-Reply-To: <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Eb9AaQ5KHU6xdb3t4NGBQkVaj4wGA3eid" Archived-At: Cc: "dhcwg@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 23 Jan 2015 05:44:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Eb9AaQ5KHU6xdb3t4NGBQkVaj4wGA3eid Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/22/15 3:39 PM, Ted Lemon wrote: > On Jan 4, 2015, at 4:32 PM, joel jaeggli wrote: >> After some dicussion last year, I have agreed to sponsor=20 >> draft-wkumari-dhc-capport=20 >> (https://tools.ietf.org/html/draft-wkumari-dhc-capport-07). what >> I'm looking for feeback on right now is feedback from potential=20 >> implementors, either of client implementations of captive portal=20 >> detection or captive portals as to: >>=20 >> * Whether or not this represents a reasonable optimization, >>=20 >> * Have we gotten the security considerations right? >>=20 >> * Would you use it if there was general consensus to the approach. >=20 > I haven't seen any responses to this. I don't expect you'll see any > "we would use this responses," and you shouldn't predicate this work > on seeing any. I think the idea is fine, although I think the > requirement that the URI use an address literal is unnecessary. If > the implementor wants to do that, they can, or they can just only > answer DNS queries for the local domain until the user authenticates. > They'd have to do that to support the redirect anyway. >=20 > I think the document has way too much explanatory text. It's good > that it's there for now so that people can understand the problem > that this draft purports to solve, but it should not be in the final > version. Just explain how to use DHCP and ND to send this option (I > think supporting it in ND is worthwhile, because DHCP isn't really > very useful in an IPv6 hotspot environment). >=20 > It would be nice to talk about ways to authenticate this, e.g. PKI or > DNSSEC certs. >=20 > I think you should run it by some people with HTTP fu to make sure > that you haven't missed any obvious gaps, and of course run it by > somebody with HTTP security fu to make sure there aren't any security > flaws that need to be addressed. >=20 > I would not object to you AD-sponsoring this. It's not in-charter > for DHC, nor for 6man. You should get it reviewed in both places, > not just in DHC. Yeah this is inline with my assumptions, thank you. > You may find section 5.7 of RFC 7227 useful: it would be good to make > sure that your use of the DHCP URI option format meshes with what RFC > 7227 does. I didn't notice a problem, but didn't look all that > carefully. >=20 >=20 --Eb9AaQ5KHU6xdb3t4NGBQkVaj4wGA3eid 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTB35sACgkQ8AA1q7Z/VrLqrgCdEsle3lnMbw8Cc28Bolkoo/th l1MAnR0/4ahwGBx9QQLu4i7TwxW5zp2+ =AOqt -----END PGP SIGNATURE----- --Eb9AaQ5KHU6xdb3t4NGBQkVaj4wGA3eid-- From nobody Thu Jan 22 23:55:17 2015 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 DFE7C1A1A67 for ; Thu, 22 Jan 2015 23:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hsgDzeG3YB8x for ; Thu, 22 Jan 2015 23:55:10 -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 20A2A1A1A3C for ; Thu, 22 Jan 2015 23:55:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRQ66532; Fri, 23 Jan 2015 07:55:07 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 07:55:06 +0000 Received: from SZXEMA505-MBS.china.huawei.com ([169.254.2.179]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 15:54:50 +0800 From: "Fangliang (Leon, ICSL)" To: "t.petch" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt Thread-Index: AQHQC32W/4YTNPshIUWpCeD1WjTltpx25UiggAATbtCAA8U3uIBS7djw Date: Fri, 23 Jan 2015 07:54:50 +0000 Message-ID: <66E79E433DA56A4BBE653AE8767EC2353E1BBF27@szxema505-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> In-Reply-To: <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.6.127] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.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, 23 Jan 2015 07:55:13 -0000 SGkgVG9tIGFuZCBhbGwsDQoNCk5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbCBpcyB1c3VhbGx5 IGF0dGFja2VycycgdGFyZ2V0LiBPbmNlIGF0dGFja2VkLCB0aGUgc2VydmljZSB3aWxsIGJlIHRh bXBlcmVkIGFuZCByZXN1bHQgaW4gc2lnbmlmaWNhbnQgc2VjdXJpdHkgaXNzdWUuIEFzIFNOTVAg aXMgdGhlIHdpZGVseSB1c2VkIG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9yIG5ldHdvcmsgZGV2aWNl IGFuZCBhIGxhcmdlIHByb3BvcnRpb24gb2YgbmV0d29yayBkZXZpY2VzIHN1cHBvcnQgU05NUCwg dGhlIHNlY3VyaXR5IG9mIFNOTVAgaXMgZXNwZWNpYWxseSBpbXBvcnRhbnQuIEFzIGEgcmVzdWx0 IHdlIChJRVRGKSBzaG91bGQgcGF5IG1vcmUgYXR0ZW50aW9uIHRvIFNOTVAgc2VjdXJpdHkgaXNz dWVzLg0KDQpUaGUgc2VjdXJpdHkgZXhwZXJ0IGFzIFN0dWFydCBNY0NsdXJlIGhhdmUgbWVudGlv bmVkIFNOTVAgaW4gaGlzIGZhbW91cyBib29rIGFzICJIQUNLSU5HIEVYUE9TRUQgNzogTkVUV09S SyBTRUNVUklUWSBTRUNSRVRTICYgU09MVVRJT05TIiwgTWNHcmF3LUhpbGwgRWR1Y2F0aW9uLCAy MDEyLCBwcCAzNDg6IENvbmNlaXZlZCBhcyBhIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQgbW9uaXRv cmluZyBzZXJ2aWNlLCB0aGUgU2ltcGxlIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbCAoU05N UCkgaXMgZGVzaWduZWQgdG8gcHJvdmlkZSBpbnRpbWF0ZSBpbmZvcm1hdGlvbiBhYm91dCBuZXR3 b3JrIGRldmljZXMsIHNvZnR3YXJlLCBhbmQgc3lzdGVtcy4gQXMgc3VjaCwgaXQgaXMgYSBmcmVx dWVudCB0YXJnZXQgb2YgYXR0YWNrZXJzLiBJbiBhZGRpdGlvbiwgaXRzIGdlbmVyYWwgbGFjayBv ZiBzdHJvbmcgc2VjdXJpdHkgcHJvdGVjdGlvbnMgaGFzIGdhcm5lcmVkIGl0IHRoZSBjb2xsb3F1 aWFsIG5hbWUgobBTZWN1cml0eSBOb3QgTXkgUHJvYmxlbS6hsQ0KDQpUaGUgY3VycmVudCBLZXkg TG9jYWxpemF0aW9uIEFsZ29yaXRobSBoYXZlIG9idmlvdXMgdnVsbmVyYWJpbGl0eS4gV2UgbmV2 ZXIgc2VlIHN1Y2ggY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG0gZGVmZWN0IGluIG90aGVyIHdpZGVs eSB1c2VkIHByb3RvY29sLiBIYWNrZXIgY29tbXVuaXRpZXMgaGF2ZSBtZW50aW9uZWQgdGhlIGN1 cnJlbnQga2V5IGxvY2FsaXphdGlvbiBtZXRob2QgYXMgYSBsb29waG9sZSwgYW5kIHBsYW4gdG8g ZXhwbG9pdCB0aGUgdnVsbmVyYWJpbGl0eSBvciBwdWJsaXNoIGl0IHRvIENWRS4NCg0KVG8gYWRk IGFuIGV4dHJhIHBhc3N3b3JkIHByb2Nlc3NpbmcgbW9kdWxlIGZvciBTTk1QVjMsIGl0IG5lZWQg YWRkIG1vcmUgcmVzdHJpY3RlZCBjb25kaXRpb24gdGhhbiB0aGUgcmVndWxhciB3YXkuIFdlIGhh dmUgZGlzY3Vzc2VkIGl0IHdpdGggZGVzaWduIHRlYW1zLCBub2JvZHkgYWNjZXB0IHRoaXMgZGVz aWduIHByb3Bvc2FsLCBmb3IgaXQgd2lsbCBpbmR1Y2UgbW9yZSBpbnRlcm9wZXJhYmlsaXR5IHBy b2JsZW1zIGZvciBvdGhlciBwYXNzd29yZCBiYXNlZCBtb2R1bGUuIEJlc2lkZXMsIHRoaXMgaXMg YSBjb2xsaXNpb24gcHJvYmxlbSBpbiBrZXkgbG9jYWxpemF0aW9uIGluIFNOTVAsIGl0IGlzIG5v dCBzdWl0YWJsZSB0byBkZW1hbmQgdGhlIGRldmVsb3BlciB0byBjaGFuZ2UgdGhlIGdlbmVyYWwg bW9kdWxlIHRvIGZpeCB0aGlzIHNwZWNpYWwgcHJvYmxlbSBpbiBTTk1QLg0KDQpJbiBjb25zaWRl cmF0aW9uIG9mIG90aGVyIGFyY2hpdGVjdHVyYWwgdnVsbmVyYWJpbGl0eSwgdGhpcyB2dWxuZXJh YmlsaXR5IGNhbiBiZSBlYXNpbHkgZml4ZWQgYnkgbGl0dGxlIHJldmlzaW9uIGFzIHByb3Bvc2Vk IGJ5IHRoaXMgZHJhZnQgLiBBbnkgY29tbWVudHM/DQoNCg0KUmVnYXJkcywNCkZhbmcgTGlhbmcN Cg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCreivP7IyzogdC5wZXRjaCBbbWFp bHRvOmlldGZjQGJ0Y29ubmVjdC5jb21dIA0Kt6LLzcqxvOQ6IDIwMTTE6jEy1MIxyNUgMTg6MzEN CsrVvP7IyzogWmhhbmdkYWNoZW5nIChEYWNoZW5nKTsgSGVkYW5waW5nIChBbmEpOyBvcHNhd2dA aWV0Zi5vcmcNCrOty806IGRyYWZ0LWR1LW9wc2F3Zy1zbm1wLWtleS1sb2NhbGl6YXRpb25AdG9v bHMuaWV0Zi5vcmcNCtb3zOI6IFJlOiBbT1BTQVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWR1LW9wc2F3Zy1zbm1wLWtleS1sb2NhbGl6YXRpb24tMDAudHh0DQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJaaGFuZ2RhY2hlbmcgKERhY2hlbmcpIiA8 emhhbmdkYWNoZW5nQGh1YXdlaS5jb20+DQpUbzogIkhlZGFucGluZyAoQW5hKSIgPGFuYS5oZWRh bnBpbmdAaHVhd2VpLmNvbT47IDxvcHNhd2dAaWV0Zi5vcmc+DQpDYzogPGRyYWZ0LWR1LW9wc2F3 Zy1zbm1wLWtleS1sb2NhbGl6YXRpb25AdG9vbHMuaWV0Zi5vcmc+DQpTZW50OiBTYXR1cmRheSwg Tm92ZW1iZXIgMjksIDIwMTQgMzo1OSBBTQ0KDQo+IExldCBtZSBoZWxwIGNsYXJpZnkgRGFucGlu ZydzIHBvaW50Lg0KPg0KPiBXZSBmb3VuZCB0aGVyZSB3YXMgYSBwcm9ibGVtIGluIHRoZSBsb2Nh bGl6YXRpb24gYWxnb3JpdGhtLCBidXQgd2UgYXJlDQpub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXNz dWUgaXMgd29ydGh3aGlsZSBmb3IgdXMgdG8gYWRkcmVzcywgb3IgdGhlIGVmZm9ydCBvZiBhZGRy ZXNzaW5nIHRoaXMgaXNzdWUgaXMgb3V0IG9mIHNjb3BlIG9mIHRoZSBTTk1QIHNwZWNpZmljYXRp b24uIFNvLCB3ZSByYWlzZSB0aGlzIHF1ZXN0aW9uIGhlcmUsIGFuZCBob3BlIHRvIGdldCBjb21t ZW50cyBvciBzdWdnZXN0aW9ucy4NCg0KVGhlIG5ldyBhbGdvcml0aG0gdGhhdCB5b3UgcHJvcG9z ZSBzZWVtcyB0byBvZmZlciB2ZXJ5IGxpdHRsZSBpbXByb3ZlbWVudC4gIFlvdSBzdWdnZXN0IHRo YXQgYWZ0ZXIgcmVwbGljYXRpbmcgdGhlIHBhc3N3b3JkLCB5b3UgdGhlbiBhZGQgdGhlIHBhc3N3 b3JkIGxlbmd0aCBpbiB0aGUgbGFzdCBmb3VyIG9jdGV0cyB0byBicmluZyB0aGUgbGVuZ3RoIHVw IHRvIDY0IG9jdGV0LiAgVGhpcyBzZWVtcyB0byBhZGQgdmVyeSBsaXR0bGUgZW50cm9weS4NCg0K QWxzbywgYW4gOCBjaGFyYWN0ZXIgc3RyaW5nLCBjb250YWluaW5nIHVwcGVyIGNhc2UsIGxvd2Vy IGNhc2UsIGRpZ2l0IGFuZCBleHRlbmRlZCBwdW5jdHVhdGlvbiB3b3VsZCBoYXZlIGJlZW4gcmVn YXJkZWQgYXMgdG9vIHdlYWsgbWFueSB5ZWFycyBhZ28gYW5kIHdlIHNob3VsZCBub3QgYmUgZG9j dW1lbnRpbmcgc3VjaCBhbiBhcHByb2FjaCBub3cuDQoNCkFnYWluLCBhbnlvbmUgd2hvIHVzZXMg YSBwYXNzd29yZCBiYXNlZCBzeXN0ZW0gYW5kIGRvZXMgbm90IGhhdmUgYSBleHRyYSBtb2R1bGUg dG8gZW5zdXJlIHRoYXQgcGFzc3dvcmRzIG1lZXQgY3VycmVudCBzdGFuZGFyZHMgZGVzZXJ2ZXMg YWxsIHRoZSBzZWN1cml0eSBicmVhY2hlcyB0aGV5IGdldCENCg0KVG9tIFBldGNoDQoNCj4NCj4g Q2hlZXJzDQo+DQo+IERhY2hlbmcNCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSGVkYW5waW5nDQo+ID4gKEFuYSkNCj4gPiBTZW50OiBTYXR1cmRheSwgTm92ZW1iZXIg MjksIDIwMTQgMTA6NTIgQU0NCj4gPiBUbzogb3BzYXdnQGlldGYub3JnDQo+ID4gQ2M6IGRyYWZ0 LWR1LW9wc2F3Zy1zbm1wLWtleS1sb2NhbGl6YXRpb25AdG9vbHMuaWV0Zi5vcmcNCj4gPiBTdWJq ZWN0OiBbT1BTQVdHXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gPiBkcmFm dC1kdS1vcHNhd2ctc25tcC1rZXktbG9jYWxpemF0aW9uLTAwLnR4dA0KPiA+DQo+ID4gRGVhciBh bGwsDQo+ID4gV2UgZmluZCBhIHNlY3VyaXR5IHByb2JsZW0gaW4gdGhlIGN1cnJlbnQgU05NUCBr ZXkgbG9jYWxpemF0aW9uDQphbGdvcml0aG0sIGJ1dA0KPiA+IHdlIGFyZSBub3Qgc3VyZSB3aGV0 aGVyIElFVEYgaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIGltcHJvdmUgaXQuIFRoZQ0KZHJhZnQgaXMN Cj4gPiBzdWJtaXR0ZWQgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCj4gPg0KPiA+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kdS1vcHNhd2ctc25tcC1rZXktbG9jYWxpemF0aW9u LTAwLnR4dA0KPiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGFucGluZyBI ZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIA0KPiA+IHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBOYW1l OiBkcmFmdC1kdS1vcHNhd2ctc25tcC1rZXktbG9jYWxpemF0aW9uDQo+ID4gUmV2aXNpb246IDAw DQo+ID4gVGl0bGU6IEEgTmV3IEFsZ29yaXRobSBmb3IgU05NUCBLZXkgTG9jYWxpemF0aW9uIERv Y3VtZW50IGRhdGU6IA0KPiA+IDIwMTQtMTEtMjgNCj4gPiBHcm91cDogSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQo+ID4gUGFnZXM6IDQNCj4gPiBVUkw6DQo+ID4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1LW9wc2F3Zy1zbm1wLWtleS1sb2NhbGl6YXRpbw0Kbi0w MC4NCj4gPiB0eHQNCj4gPiBTdGF0dXM6DQo+ID4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWR1LW9wc2F3Zy1zbm1wLWtleS1sb2NhbGl6YXRpb24vDQo+ID4gSHRtbGl6 ZWQ6DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHUtb3BzYXdnLXNubXAt a2V5LWxvY2FsaXphdGlvbi0wMA0KPiA+DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGlz IGRyYWZ0IGRpc2N1c3NlcyBhIHNlY3VyaXR5IGlzc3VlIHdpdGggdGhlIGFsZ29yaXRobSBmb3IN Cj4gPiAgICBnZW5lcmF0aW5nIFNOTVAgbG9jYWxpemVkIGtleXMgYW5kIGludHJvZHVjZSBhIG5l dyBhbGdvcml0aG0gdG8NCj4gPiAgICBhZGRyZXNzIHRoaXMgcHJvYmxlbS4NCj4gPg0KPiA+DQo+ ID4gUmVnYXJkcywNCj4gPiBBbmEgKERhbnBpbmcpDQoNCg== From nobody Fri Jan 23 02:09:55 2015 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 C07EF1A1A25 for ; Fri, 23 Jan 2015 02:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 fk0Xuau4kybe for ; Fri, 23 Jan 2015 02:09:49 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316631A03A2 for ; Fri, 23 Jan 2015 02:09:48 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id AF29B1A00AD; Fri, 23 Jan 2015 11:09:36 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id q_ATkBAd9I2o; Fri, 23 Jan 2015 11:09:35 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 80D201A00AB; Fri, 23 Jan 2015 11:09:35 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 23 Jan 2015 11:09:44 +0100 Message-ID: <54C21DE7.4030700@secunet.com> Date: Fri, 23 Jan 2015 11:09:43 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Fangliang (Leon, ICSL)" , t.petch , "opsawg@ietf.org" References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> <66E79E433DA56A4BBE653AE8767EC2353E1BBF27@szxema505-mbs.china.huawei.com> In-Reply-To: <66E79E433DA56A4BBE653AE8767EC2353E1BBF27@szxema505-mbs.china.huawei.com> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.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, 23 Jan 2015 10:09:52 -0000 Fangliang (Leon, ICSL) schrieb am 23.01.2015 um 08:54: > The current Key Localization Algorithm have obvious vulnerability. We never see such cryptographic algorithm defect in other widely used protocol. Hacker communities have mentioned the current key localization method as a loophole, and plan to exploit the vulnerability or publish it to CVE. To me, your statement seems exaggerating the issue: The problem is simply that passwords A...A consisting of repetitions of an expression A result in the same key as passwords with less repetitions. However, the entropy gained by repetitions is quite low, and if a user chooses the password "bertbert", she cannot expect it much more difficult to guess than if it was "bert". Thus, the fact that the attacker succeeds as soon as he guesses "bert" is just a gradual amplification of an issue that exists outside the cryptographic method. And as others have pointed out, it is common sense that choosing such passwords A...A is poor practice. I don't mean say that the issue is completely irrelevant, but just it is not as severe as your post seems to imply. And given the difficulties involved with a potential change, I doubt that it is worth. That said, I suggest to include a warning into the security considerations of draft-hmac-sha-2-usm-snmp pointing to this issue and recommending (generally) to use sufficiently strong passwords. RFC 3414 already contains such a caveat but repeating it in the new specification might help to draw attention to it. -- Johannes From nobody Fri Jan 23 02:13:05 2015 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 03F101A1B3E for ; Fri, 23 Jan 2015 02:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 9T1SdAmeUHqX for ; Fri, 23 Jan 2015 02:13:00 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047B51A03A2 for ; Fri, 23 Jan 2015 02:13:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CB505FCD; Fri, 23 Jan 2015 11:12:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id G-B1li76dhIY; Fri, 23 Jan 2015 11:12:31 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 Jan 2015 11:12:57 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72F1020036; Fri, 23 Jan 2015 11:12:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8-jYCZvVWISP; Fri, 23 Jan 2015 11:05:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C01EE20035; Fri, 23 Jan 2015 11:12:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 69F0F30E4FDC; Fri, 23 Jan 2015 11:12:52 +0100 (CET) Date: Fri, 23 Jan 2015 11:12:52 +0100 From: Juergen Schoenwaelder To: "Fangliang (Leon, ICSL)" Message-ID: <20150123101252.GA38535@elstar.local> Mail-Followup-To: "Fangliang (Leon, ICSL)" , "t. petch" , "opsawg@ietf.org" , "draft-du-opsawg-snmp-key-localization@tools.ietf.org" References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> <66E79E433DA56A4BBE653AE8767EC2353E1BBF27@szxema505-mbs.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <66E79E433DA56A4BBE653AE8767EC2353E1BBF27@szxema505-mbs.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "opsawg@ietf.org" , "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 10:13:02 -0000 Hi, you still seem to confuse key localization with the optional transform of a password into a (non-localized) key (that is subsequently localized). /js On Fri, Jan 23, 2015 at 07:54:50AM +0000, Fangliang (Leon, ICSL) wrote: > Hi Tom and all, > > Network management protocol is usually attackers' target. Once attacked, the service will be tampered and result in significant security issue. As SNMP is the widely used management protocol for network device and a large proportion of network devices support SNMP, the security of SNMP is especially important. As a result we (IETF) should pay more attention to SNMP security issues. > > The security expert as Stuart McClure have mentioned SNMP in his famous book as "HACKING EXPOSED 7: NETWORK SECURITY SECRETS & SOLUTIONS", McGraw-Hill Education, 2012, pp 348: Conceived as a network management and monitoring service, the Simple Network Management Protocol (SNMP) is designed to provide intimate information about network devices, software, and systems. As such, it is a frequent target of attackers. In addition, its general lack of strong security protections has garnered it the colloquial name “Security Not My Problem.†> > The current Key Localization Algorithm have obvious vulnerability. We never see such cryptographic algorithm defect in other widely used protocol. Hacker communities have mentioned the current key localization method as a loophole, and plan to exploit the vulnerability or publish it to CVE. > > To add an extra password processing module for SNMPV3, it need add more restricted condition than the regular way. We have discussed it with design teams, nobody accept this design proposal, for it will induce more interoperability problems for other password based module. Besides, this is a collision problem in key localization in SNMP, it is not suitable to demand the developer to change the general module to fix this special problem in SNMP. > > In consideration of other architectural vulnerability, this vulnerability can be easily fixed by little revision as proposed by this draft . Any comments? > > > Regards, > Fang Liang > > > > ----- Original Message ----- > å‘件人: t.petch [mailto:ietfc@btconnect.com] > å‘é€æ—¶é—´: 2014å¹´12月1æ—¥ 18:31 > 收件人: Zhangdacheng (Dacheng); Hedanping (Ana); opsawg@ietf.org > 抄é€: draft-du-opsawg-snmp-key-localization@tools.ietf.org > 主题: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt > > ----- Original Message ----- > From: "Zhangdacheng (Dacheng)" > To: "Hedanping (Ana)" ; > Cc: > Sent: Saturday, November 29, 2014 3:59 AM > > > Let me help clarify Danping's point. > > > > We found there was a problem in the localization algorithm, but we are > not sure whether this issue is worthwhile for us to address, or the effort of addressing this issue is out of scope of the SNMP specification. So, we raise this question here, and hope to get comments or suggestions. > > The new algorithm that you propose seems to offer very little improvement. You suggest that after replicating the password, you then add the password length in the last four octets to bring the length up to 64 octet. This seems to add very little entropy. > > Also, an 8 character string, containing upper case, lower case, digit and extended punctuation would have been regarded as too weak many years ago and we should not be documenting such an approach now. > > Again, anyone who uses a password based system and does not have a extra module to ensure that passwords meet current standards deserves all the security breaches they get! > > Tom Petch > > > > > Cheers > > > > Dacheng > > > > > -----Original Message----- > > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Hedanping > > > (Ana) > > > Sent: Saturday, November 29, 2014 10:52 AM > > > To: opsawg@ietf.org > > > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > > > Subject: [OPSAWG] FW: New Version Notification for > > > draft-du-opsawg-snmp-key-localization-00.txt > > > > > > Dear all, > > > We find a security problem in the current SNMP key localization > algorithm, but > > > we are not sure whether IETF is the right place to improve it. The > draft is > > > submitted and comments are appreciated. > > > > > > A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt > > > has been successfully submitted by Danping He and posted to the IETF > > > repository. > > > > > > Name: draft-du-opsawg-snmp-key-localization > > > Revision: 00 > > > Title: A New Algorithm for SNMP Key Localization Document date: > > > 2014-11-28 > > > Group: Individual Submission > > > Pages: 4 > > > URL: > > > > http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localizatio > n-00. > > > txt > > > Status: > > > > https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localization/ > > > Htmlized: > > > http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 > > > > > > > > > Abstract: > > > This draft discusses a security issue with the algorithm for > > > generating SNMP localized keys and introduce a new algorithm to > > > address this problem. > > > > > > > > > Regards, > > > Ana (Danping) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From leon.fang@huawei.com Thu Jan 22 23:26:39 2015 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 43DC51A8F50 for ; Thu, 22 Jan 2015 23:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_15=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 M_GT8aKcT63D for ; Thu, 22 Jan 2015 23:26:36 -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 F3F4E1A1B14 for ; Thu, 22 Jan 2015 23:26:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRQ64130; Fri, 23 Jan 2015 07:26:32 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 07:26:31 +0000 Received: from SZXEMA505-MBS.china.huawei.com ([169.254.2.179]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 15:26:20 +0800 From: "Fangliang (Leon, ICSL)" To: "t.petch" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt Thread-Index: AQHQC32W/4YTNPshIUWpCeD1WjTltpx25UiggAATbtCAA8U3uIBS5j7g Date: Fri, 23 Jan 2015 07:26:19 +0000 Message-ID: <66E79E433DA56A4BBE653AE8767EC2353E1BBEEB@szxema505-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> In-Reply-To: <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.6.127] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Fri, 23 Jan 2015 02:50:14 -0800 Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.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, 23 Jan 2015 07:29:08 -0000 SGkgVG9tIGFuZCBhbGwsDQoNCk5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbCBpcyB1c3VhbGx5 IGF0dGFja2VycycgdGFyZ2V0LiBPbmNlIGF0dGFja2VkLCB0aGUgc2VydmljZSB3aWxsIGJlIHRh bXBlcmVkIGFuZCByZXN1bHQgaW4gc2lnbmlmaWNhbnQgc2VjdXJpdHkgaXNzdWUuIEFzIFNOTVAg aXMgdGhlIHdpZGVseSB1c2VkIG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9yIG5ldHdvcmsgZGV2aWNl IGFuZCBhIGxhcmdlIHByb3BvcnRpb24gb2YgbmV0d29yayBkZXZpY2VzIHN1cHBvcnQgU05NUCwg dGhlIHNlY3VyaXR5IG9mIFNOTVAgaXMgZXNwZWNpYWxseSBpbXBvcnRhbnQuIEFzIGEgcmVzdWx0 IHdlIChJRVRGKSBzaG91bGQgcGF5IG1vcmUgYXR0ZW50aW9uIHRvIFNOTVAgc2VjdXJpdHkgaXNz dWVzLg0KDQpUaGUgc2VjdXJpdHkgZXhwZXJ0IGFzIFN0dWFydCBNY0NsdXJlIGhhdmUgbWVudGlv bmVkIFNOTVAgaW4gaGlzIGZhbW91cyBib29rIGFzICJIQUNLSU5HIEVYUE9TRUQgNzogTkVUV09S SyBTRUNVUklUWSBTRUNSRVRTICYgU09MVVRJT05TIiwgTWNHcmF3LUhpbGwgRWR1Y2F0aW9uLCAy MDEyLCBwcCAzNDg6IENvbmNlaXZlZCBhcyBhIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQgbW9uaXRv cmluZyBzZXJ2aWNlLCB0aGUgU2ltcGxlIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbCAoU05N UCkgaXMgZGVzaWduZWQgdG8gcHJvdmlkZSBpbnRpbWF0ZSBpbmZvcm1hdGlvbiBhYm91dCBuZXR3 b3JrIGRldmljZXMsIHNvZnR3YXJlLCBhbmQgc3lzdGVtcy4gQXMgc3VjaCwgaXQgaXMgYSBmcmVx dWVudCB0YXJnZXQgb2YgYXR0YWNrZXJzLiBJbiBhZGRpdGlvbiwgaXRzIGdlbmVyYWwgbGFjayBv ZiBzdHJvbmcgc2VjdXJpdHkgcHJvdGVjdGlvbnMgaGFzIGdhcm5lcmVkIGl0IHRoZSBjb2xsb3F1 aWFsIG5hbWUgobBTZWN1cml0eSBOb3QgTXkgUHJvYmxlbS6hsQ0KDQpUaGUgY3VycmVudCBLZXkg TG9jYWxpemF0aW9uIEFsZ29yaXRobSBoYXZlIG9idmlvdXMgdnVsbmVyYWJpbGl0eS4gV2UgbmV2 ZXIgc2VlIHN1Y2ggY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG0gZGVmZWN0IGluIG90aGVyIHdpZGVs eSB1c2VkIHByb3RvY29sLiBIYWNrZXIgY29tbXVuaXRpZXMgaGF2ZSBtZW50aW9uZWQgdGhlIGN1 cnJlbnQga2V5IGxvY2FsaXphdGlvbiBtZXRob2QgYXMgYSBsb29waG9sZSwgYW5kIHBsYW4gdG8g ZXhwbG9pdCB0aGUgdnVsbmVyYWJpbGl0eSBvciBwdWJsaXNoIGl0IHRvIENWRS4NCg0KVG8gYWRk IGFuIGV4dHJhIHBhc3N3b3JkIHByb2Nlc3NpbmcgbW9kdWxlIGZvciBTTk1QVjMsIGl0IG5lZWQg YWRkIG1vcmUgcmVzdHJpY3RlZCBjb25kaXRpb24gdGhhbiB0aGUgcmVndWxhciB3YXkuIFdlIGhh dmUgZGlzY3Vzc2VkIGl0IHdpdGggZGVzaWduIHRlYW1zLCBub2JvZHkgYWNjZXB0IHRoaXMgZGVz aWduIHByb3Bvc2FsLCBmb3IgaXQgd2lsbCBpbmR1Y2UgbW9yZSBpbnRlcm9wZXJhYmlsaXR5IHBy b2JsZW1zIGZvciBvdGhlciBwYXNzd29yZCBiYXNlZCBtb2R1bGUuIEJlc2lkZXMsIHRoaXMgaXMg YSBjb2xsaXNpb24gcHJvYmxlbSBpbiBrZXkgbG9jYWxpemF0aW9uIGluIFNOTVAsIGl0IGlzIG5v dCBzdWl0YWJsZSB0byBkZW1hbmQgdGhlIGRldmVsb3BlciB0byBjaGFuZ2UgdGhlIGdlbmVyYWwg bW9kdWxlIHRvIGZpeCB0aGlzIHNwZWNpYWwgcHJvYmxlbSBpbiBTTk1QLg0KDQpJbiBjb25zaWRl cmF0aW9uIG9mIG90aGVyIGFyY2hpdGVjdHVyYWwgdnVsbmVyYWJpbGl0eSwgdGhpcyB2dWxuZXJh YmlsaXR5IGNhbiBiZSBlYXNpbHkgZml4ZWQgYnkgbGl0dGxlIHJldmlzaW9uIGFzIHByb3Bvc2Vk IGJ5IHRoaXMgZHJhZnQgLiBBbnkgY29tbWVudHM/DQoNCg0KUmVnYXJkcywNCkZhbmcgTGlhbmcN Cg0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiB0LnBldGNoIFttYWlsdG86aWV0ZmNA YnRjb25uZWN0LmNvbV0gDQq3osvNyrG85DogMjAxNMTqMTLUwjHI1SAxODozMQ0KytW8/sjLOiBa aGFuZ2RhY2hlbmcgKERhY2hlbmcpOyBIZWRhbnBpbmcgKEFuYSk7IG9wc2F3Z0BpZXRmLm9yZw0K s63LzTogZHJhZnQtZHUtb3BzYXdnLXNubXAta2V5LWxvY2FsaXphdGlvbkB0b29scy5pZXRmLm9y Zw0K1vfM4jogUmU6IFtPUFNBV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt ZHUtb3BzYXdnLXNubXAta2V5LWxvY2FsaXphdGlvbi0wMC50eHQNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KRnJvbTogIlpoYW5nZGFjaGVuZyAoRGFjaGVuZykiIDx6aGFuZ2RhY2hl bmdAaHVhd2VpLmNvbT4NClRvOiAiSGVkYW5waW5nIChBbmEpIiA8YW5hLmhlZGFucGluZ0BodWF3 ZWkuY29tPjsgPG9wc2F3Z0BpZXRmLm9yZz4NCkNjOiA8ZHJhZnQtZHUtb3BzYXdnLXNubXAta2V5 LWxvY2FsaXphdGlvbkB0b29scy5pZXRmLm9yZz4NClNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAy OSwgMjAxNCAzOjU5IEFNDQoNCj4gTGV0IG1lIGhlbHAgY2xhcmlmeSBEYW5waW5nJ3MgcG9pbnQu DQo+DQo+IFdlIGZvdW5kIHRoZXJlIHdhcyBhIHByb2JsZW0gaW4gdGhlIGxvY2FsaXphdGlvbiBh bGdvcml0aG0sIGJ1dCB3ZSBhcmUNCm5vdCBzdXJlIHdoZXRoZXIgdGhpcyBpc3N1ZSBpcyB3b3J0 aHdoaWxlIGZvciB1cyB0byBhZGRyZXNzLCBvciB0aGUgZWZmb3J0IG9mIGFkZHJlc3NpbmcgdGhp cyBpc3N1ZSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIFNOTVAgc3BlY2lmaWNhdGlvbi4gU28sIHdl IHJhaXNlIHRoaXMgcXVlc3Rpb24gaGVyZSwgYW5kIGhvcGUgdG8gZ2V0IGNvbW1lbnRzIG9yIHN1 Z2dlc3Rpb25zLg0KDQpUaGUgbmV3IGFsZ29yaXRobSB0aGF0IHlvdSBwcm9wb3NlIHNlZW1zIHRv IG9mZmVyIHZlcnkgbGl0dGxlIGltcHJvdmVtZW50LiAgWW91IHN1Z2dlc3QgdGhhdCBhZnRlciBy ZXBsaWNhdGluZyB0aGUgcGFzc3dvcmQsIHlvdSB0aGVuIGFkZCB0aGUgcGFzc3dvcmQgbGVuZ3Ro IGluIHRoZSBsYXN0IGZvdXIgb2N0ZXRzIHRvIGJyaW5nIHRoZSBsZW5ndGggdXAgdG8gNjQgb2N0 ZXQuICBUaGlzIHNlZW1zIHRvIGFkZCB2ZXJ5IGxpdHRsZSBlbnRyb3B5Lg0KDQpBbHNvLCBhbiA4 IGNoYXJhY3RlciBzdHJpbmcsIGNvbnRhaW5pbmcgdXBwZXIgY2FzZSwgbG93ZXIgY2FzZSwgZGln aXQgYW5kIGV4dGVuZGVkIHB1bmN0dWF0aW9uIHdvdWxkIGhhdmUgYmVlbiByZWdhcmRlZCBhcyB0 b28gd2VhayBtYW55IHllYXJzIGFnbyBhbmQgd2Ugc2hvdWxkIG5vdCBiZSBkb2N1bWVudGluZyBz dWNoIGFuIGFwcHJvYWNoIG5vdy4NCg0KQWdhaW4sIGFueW9uZSB3aG8gdXNlcyBhIHBhc3N3b3Jk IGJhc2VkIHN5c3RlbSBhbmQgZG9lcyBub3QgaGF2ZSBhIGV4dHJhIG1vZHVsZSB0byBlbnN1cmUg dGhhdCBwYXNzd29yZHMgbWVldCBjdXJyZW50IHN0YW5kYXJkcyBkZXNlcnZlcyBhbGwgdGhlIHNl Y3VyaXR5IGJyZWFjaGVzIHRoZXkgZ2V0IQ0KDQpUb20gUGV0Y2gNCg0KPg0KPiBDaGVlcnMNCj4N Cj4gRGFjaGVuZw0KPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog T1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIZWRh bnBpbmcNCj4gPiAoQW5hKQ0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAyOSwgMjAxNCAx MDo1MiBBTQ0KPiA+IFRvOiBvcHNhd2dAaWV0Zi5vcmcNCj4gPiBDYzogZHJhZnQtZHUtb3BzYXdn LXNubXAta2V5LWxvY2FsaXphdGlvbkB0b29scy5pZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFtPUFNB V0ddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiA+IGRyYWZ0LWR1LW9wc2F3 Zy1zbm1wLWtleS1sb2NhbGl6YXRpb24tMDAudHh0DQo+ID4NCj4gPiBEZWFyIGFsbCwNCj4gPiBX ZSBmaW5kIGEgc2VjdXJpdHkgcHJvYmxlbSBpbiB0aGUgY3VycmVudCBTTk1QIGtleSBsb2NhbGl6 YXRpb24NCmFsZ29yaXRobSwgYnV0DQo+ID4gd2UgYXJlIG5vdCBzdXJlIHdoZXRoZXIgSUVURiBp cyB0aGUgcmlnaHQgcGxhY2UgdG8gaW1wcm92ZSBpdC4gVGhlDQpkcmFmdCBpcw0KPiA+IHN1Ym1p dHRlZCBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWR1LW9wc2F3Zy1zbm1wLWtleS1sb2NhbGl6YXRpb24tMDAudHh0DQo+ ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYW5waW5nIEhlIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgDQo+ID4gcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6IGRyYWZ0LWR1 LW9wc2F3Zy1zbm1wLWtleS1sb2NhbGl6YXRpb24NCj4gPiBSZXZpc2lvbjogMDANCj4gPiBUaXRs ZTogQSBOZXcgQWxnb3JpdGhtIGZvciBTTk1QIEtleSBMb2NhbGl6YXRpb24gRG9jdW1lbnQgZGF0 ZTogDQo+ID4gMjAxNC0xMS0yOA0KPiA+IEdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g PiBQYWdlczogNA0KPiA+IFVSTDoNCj4gPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtZHUtb3BzYXdnLXNubXAta2V5LWxvY2FsaXphdGlvDQpuLTAwLg0KPiA+IHR4 dA0KPiA+IFN0YXR1czoNCj4gPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZHUtb3BzYXdnLXNubXAta2V5LWxvY2FsaXphdGlvbi8NCj4gPiBIdG1saXplZDoNCj4gPiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdS1vcHNhd2ctc25tcC1rZXktbG9jYWxp emF0aW9uLTAwDQo+ID4NCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgIFRoaXMgZHJhZnQgZGlz Y3Vzc2VzIGEgc2VjdXJpdHkgaXNzdWUgd2l0aCB0aGUgYWxnb3JpdGhtIGZvcg0KPiA+ICAgIGdl bmVyYXRpbmcgU05NUCBsb2NhbGl6ZWQga2V5cyBhbmQgaW50cm9kdWNlIGEgbmV3IGFsZ29yaXRo bSB0bw0KPiA+ICAgIGFkZHJlc3MgdGhpcyBwcm9ibGVtLg0KPiA+DQo+ID4NCj4gPiBSZWdhcmRz LA0KPiA+IEFuYSAoRGFucGluZykNCg0K From nobody Fri Jan 23 02:50:27 2015 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 CBFC71A8908; Fri, 23 Jan 2015 02:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 u0N5dc4pghXg; Fri, 23 Jan 2015 02:24:02 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D3A1A1AF6; Fri, 23 Jan 2015 02:24:02 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id E80716161; Fri, 23 Jan 2015 02:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=5Ctk+hfS2uawdv5zIDperLY7jyc=; b=B5VqPZWizOlT88+IxH IVEpGezIfPv5XFqQgI1bYEdX39kA9H6mVTPhLr3FQTEfc10dh3W3vNT8L1YGJkYd gxQ91ebY8qWfrq4bwnu10v62i09Qz7YHkyHwafzGaWb0BuWsdTNHPwlY/KXIzxak vxCAYSRqdImJ+m+oGu4z/UrE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=hQcsz4RGt/qmBi+D8y7ee9E9FSEJsnXaXWNyl+rklah14SjkOWf pHY9OQ8590NpfOJ0I66xEQ5QUomEOHnTYg+5OnR9rZs+QuMwF0MEGVtjiJFRbCov FX1ecEFc2XAvEbDhCrNi1X0PIuKp/mZrwe/SK9516RcWVEth4hzfD88E= Received: from gomlefisk.localdomain (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 716326141; Fri, 23 Jan 2015 02:24:00 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 4ED593D33971; Fri, 23 Jan 2015 11:23:58 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.4\)) From: Ole Troan In-Reply-To: <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> Date: Fri, 23 Jan 2015 11:23:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.2070.4) Archived-At: X-Mailman-Approved-At: Fri, 23 Jan 2015 02:50:15 -0800 Cc: "dhcwg@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 23 Jan 2015 10:24:04 -0000 >> After some dicussion last year, I have agreed to sponsor >> draft-wkumari-dhc-capport >> (https://tools.ietf.org/html/draft-wkumari-dhc-capport-07). what I'm >> looking for feeback on right now is feedback from potential >> implementors, either of client implementations of captive portal >> detection or captive portals as to: >>=20 >> * Whether or not this represents a reasonable optimization, >>=20 >> * Have we gotten the security considerations right? >>=20 >> * Would you use it if there was general consensus to the approach. >=20 > I haven't seen any responses to this. I don't expect you'll see any = "we would use this responses," and you shouldn't predicate this work on = seeing any. I think the idea is fine, although I think the requirement = that the URI use an address literal is unnecessary. If the implementor = wants to do that, they can, or they can just only answer DNS queries for = the local domain until the user authenticates. They'd have to do that = to support the redirect anyway. >=20 > I think the document has way too much explanatory text. It's good = that it's there for now so that people can understand the problem that = this draft purports to solve, but it should not be in the final version. = Just explain how to use DHCP and ND to send this option (I think = supporting it in ND is worthwhile, because DHCP isn't really very useful = in an IPv6 hotspot environment). >=20 > It would be nice to talk about ways to authenticate this, e.g. PKI or = DNSSEC certs. >=20 > I think you should run it by some people with HTTP fu to make sure = that you haven't missed any obvious gaps, and of course run it by = somebody with HTTP security fu to make sure there aren't any security = flaws that need to be addressed. >=20 > I would not object to you AD-sponsoring this. It's not in-charter = for DHC, nor for 6man. You should get it reviewed in both places, not = just in DHC. >=20 > You may find section 5.7 of RFC 7227 useful: it would be good to make = sure that your use of the DHCP URI option format meshes with what RFC = 7227 does. I didn't notice a problem, but didn't look all that = carefully. is this needed when you have 802.11u? does it conflict or should it be integrated with the prefix properties = in http://tools.ietf.org/html/draft-lepape-6man-prefix-metadata-00 what's this proposals relationship with MIF's PVDs? cheers, Ole= From nobody Fri Jan 23 04:22:29 2015 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 1A76E1A90C2 for ; Fri, 23 Jan 2015 04:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] 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 F29cK0v2OPyX for ; Fri, 23 Jan 2015 04:22:21 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 03AF91A90BF for ; Fri, 23 Jan 2015 04:22:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id D205110D8ACD; Fri, 23 Jan 2015 07:23:13 -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 y7np6pFs8jK7; Fri, 23 Jan 2015 07:23:13 -0500 (EST) Received: from newdev.cadm.harvard.edu (newdev.cadm.harvard.edu [128.103.229.199]) by sobco.sobco.com (Postfix) with ESMTPSA id 76EC110D8AC1; Fri, 23 Jan 2015 07:23:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: "Scott O. Bradner" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645E91358@dfweml701-chm> Date: Fri, 23 Jan 2015 07:22:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150107225223.GA14477@elstar.local> <20150108072623.GB15231@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F645E91358@dfweml701-chm> To: "opsawg@ietf.org" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "draft-opsawg-operators-ietf@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 23 Jan 2015 12:22:24 -0000 The WG call for adoption for draft-opsawg-operators-ietf has finished. Not all that many people spoke up on the list and the opinion on = adoption was split among the people who did speak up. If any message emerged it was that WG adoption of the ID, as-is, would = not add=20 much to the value of the ID. David seemed to sum it up best: Hmm - I would support adoption if the WG chairs intend to make this draft actually look like a problem statement, not just kinda. This could be done, by planning to add a small amount of material = summarizing the problem at the end of the draft ... where Section 5 is already effectively a placeholder awaiting addition of that sort of material. I have a hard time supporting draft adoption for the sole purpose of rubber-stamping the draft with the WG's imprimatur, with effectively no work on the draft occurring in the WG. It is the opinion of this chair (Warren having recused himself) that the = ID author=20 should see if he can do what David suggests (add material summarizing = the=20 problem at the end of the draft) and republish as a non-WG ID. The WG = can revisit=20 the question of adoption after that is done. My personal view is that this is useful information (though more details = of the=20 actual research would be helpful (as Juergen commented) and the IETF would benefit from the information being published as an RFC but it = would=20 mostly help if the IETF actually made use of the information in some way = to=20 broaden operator participation - I am not sure how to get there from=20 here (or from the ID). Scott From nobody Fri Jan 23 05:09:10 2015 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 035231A90B5; Fri, 23 Jan 2015 05:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 SLLmz9PkeRZ1; Fri, 23 Jan 2015 05:08:41 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 88B141A90AF; Fri, 23 Jan 2015 05:08:41 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 443CCDA0360; Fri, 23 Jan 2015 13:08:41 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E133953E080; Fri, 23 Jan 2015 05:08:40 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 23 Jan 2015 05:08:40 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Fri, 23 Jan 2015 08:08:35 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> To: Ole Troan X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "dhcwg@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 23 Jan 2015 13:08:43 -0000 On Jan 23, 2015, at 5:23 AM, Ole Troan wrote: > is this needed when you have 802.11u? I've never actually seen an example of 802.11u in the wild. Have you? = What I see in the wild are layer 3 solutions based on spoofing. It = would certainly be worth investigating this question, but I think even = if 802.11u did see wide deployment in large WiFi network scenarios, this = would still be useful for the coffee-shop scenario. > does it conflict or should it be integrated with the prefix properties = inhttp://tools.ietf.org/html/draft-lepape-6man-prefix-metadata-00 It seems orthogonal, but it sounds like you think it's not, so it might = be worth you exploring that a bit more! > what's this proposals relationship with MIF's PVDs? I think it's orthogonal. This doesn't really change what a hotspot = network looks like--it just makes it possible to flag a network as a = hotspot network without any skullduggery. From nobody Fri Jan 23 05:31:48 2015 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 9E8711A90B8 for ; Fri, 23 Jan 2015 05:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.488 X-Spam-Level: * X-Spam-Status: No, score=1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, J_CHICKENPOX_15=0.6, MIME_CHARSET_FARAWAY=2.45, 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 k9B6ej427utP for ; Fri, 23 Jan 2015 05:31:43 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0571A90BA for ; Fri, 23 Jan 2015 05:31:42 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 23 Jan 2015 13:23:07 +0000 Message-ID: <01cb01d0370f$8e533800$4001a8c0@gateway.2wire.net> From: t.petch To: "Fangliang (Leon, ICSL)" , References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> <66E79E433DA56A4BBE653AE8767EC2353E1BBEEB@szxema505-mbs.china.huawei.com> Date: Fri, 23 Jan 2015 13:21:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit 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: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0014.eurprd05.prod.outlook.com (25.160.40.24) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DBXPR07MB064; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB064; X-Forefront-PRVS: 0465429B7F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(51704005)(377424004)(13464003)(377454003)(35774003)(19580395003)(81816999)(76176999)(50986999)(230783001)(81686999)(86362001)(42186005)(551544002)(47136003)(92566002)(46102003)(93886004)(84392001)(19580405001)(62966003)(23696002)(77156002)(61296003)(1556002)(87976001)(48336001)(50226001)(40100003)(561944003)(44736004)(50466002)(14496001)(1720100001)(33646002)(116806002)(122386002)(44716002)(47776003)(62236002)(77096005)(1456003)(15975445007)(2420400003)(66066001)(4470400001)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; MLV:ovr; PTR:InfoNoRecords; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2015 13:23:07.9878 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.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, 23 Jan 2015 13:31:44 -0000 ----- Original Message ----- From: "Fangliang (Leon, ICSL)" To: "t.petch" ; Cc: ; "Hedanping (Ana)" Sent: Friday, January 23, 2015 7:26 AM > Hi Tom and all, > > Network management protocol is usually attackers' target. Once attacked, the service will be tampered and result in significant security issue. As SNMP is the widely used management protocol for network device and a large proportion of network devices support SNMP, the security of SNMP is especially important. As a result we (IETF) should pay more attention to SNMP security issues. > > The security expert as Stuart McClure have mentioned SNMP in his famous book as "HACKING EXPOSED 7: NETWORK SECURITY SECRETS & SOLUTIONS", McGraw-Hill Education, 2012, pp 348: Conceived as a network management and monitoring service, the Simple Network Management Protocol (SNMP) is designed to provide intimate information about network devices, software, and systems. As such, it is a frequent target of attackers. In addition, its general lack of strong security protections has garnered it the colloquial name ¡°Security Not My Problem.¡± > > The current Key Localization Algorithm have obvious vulnerability. We never see such cryptographic algorithm defect in other widely used protocol. Hacker communities have mentioned the current key localization method as a loophole, and plan to exploit the vulnerability or publish it to CVE. > > To add an extra password processing module for SNMPV3, it need add more restricted condition than the regular way. We have discussed it with design teams, nobody accept this design proposal, for it will induce more interoperability problems for other password based module. Besides, this is a collision problem in key localization in SNMP, it is not suitable to demand the developer to change the general module to fix this special problem in SNMP. > > In consideration of other architectural vulnerability, this vulnerability can be easily fixed by little revision as proposed by this draft . Any comments? I think the same comment as last time, that the improvement in security is slight and the cost of doing so significant. And better alternatives are available (e.g. SNMP over TLS, Netconf). Tom Petch > > > Regards, > Fang Liang > > > > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: t.petch [mailto:ietfc@btconnect.com] > ·¢ËÍʱ¼ä: 2014Äê12ÔÂ1ÈÕ 18:31 > ÊÕ¼þÈË: Zhangdacheng (Dacheng); Hedanping (Ana); opsawg@ietf.org > ³­ËÍ: draft-du-opsawg-snmp-key-localization@tools.ietf.org > > ----- Original Message ----- > From: "Zhangdacheng (Dacheng)" > To: "Hedanping (Ana)" ; > Cc: > Sent: Saturday, November 29, 2014 3:59 AM > > > Let me help clarify Danping's point. > > > > We found there was a problem in the localization algorithm, but we are > not sure whether this issue is worthwhile for us to address, or the effort of addressing this issue is out of scope of the SNMP specification. So, we raise this question here, and hope to get comments or suggestions. > > The new algorithm that you propose seems to offer very little improvement. You suggest that after replicating the password, you then add the password length in the last four octets to bring the length up to 64 octet. This seems to add very little entropy. > > Also, an 8 character string, containing upper case, lower case, digit and extended punctuation would have been regarded as too weak many years ago and we should not be documenting such an approach now. > > Again, anyone who uses a password based system and does not have a extra module to ensure that passwords meet current standards deserves all the security breaches they get! > > Tom Petch > > > > > Cheers > > > > Dacheng > > > > > -----Original Message----- > > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Hedanping > > > (Ana) > > > Sent: Saturday, November 29, 2014 10:52 AM > > > To: opsawg@ietf.org > > > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > > > Subject: [OPSAWG] FW: New Version Notification for > > > draft-du-opsawg-snmp-key-localization-00.txt > > > > > > Dear all, > > > We find a security problem in the current SNMP key localization > algorithm, but > > > we are not sure whether IETF is the right place to improve it. The > draft is > > > submitted and comments are appreciated. > > > > > > A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt > > > has been successfully submitted by Danping He and posted to the IETF > > > repository. > > > > > > Name: draft-du-opsawg-snmp-key-localization > > > Revision: 00 > > > Title: A New Algorithm for SNMP Key Localization Document date: > > > 2014-11-28 > > > Group: Individual Submission > > > Pages: 4 > > > URL: > > > > http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localizatio > n-00. > > > txt > > > Status: > > > > https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localization/ > > > Htmlized: > > > http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 > > > > > > Abstract: > > > This draft discusses a security issue with the algorithm for > > > generating SNMP localized keys and introduce a new algorithm to > > > address this problem. > > > > > > Regards, > > > Ana (Danping) > From nobody Fri Jan 23 06:41:27 2015 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 18F791A90C8 for ; Fri, 23 Jan 2015 06:41:22 -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, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 h3JQkwHSKOsO for ; Fri, 23 Jan 2015 06:41:20 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (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 24B701A90D1 for ; Fri, 23 Jan 2015 06:41:20 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id l61so7908710wev.13 for ; Fri, 23 Jan 2015 06:41:18 -0800 (PST) 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=CFQsmfgluvnj+NkhTwXS292uTkGlIiLVk8Bkc3bu4L8=; b=IdhIN2m6OXgQcx9unKseHCXMLvA3FDddVPg7lZUlh1PKAFk9EtUMPtSuDiCo4+YFLW +mbgO8Ho46uD3rxT6wJrYCN1qfn4bzG27SSrqg7IzF1lAXl2iinRTO79O7IASJEAlgZr klDAdcJXmpE2rgnG8+X96jTus9Qy6dmKPvnD/YA/vxHjR/umywcT9dzY6uujfVUz9oAf WQ63gE71EQr6TsPxeOqHzAxZ3/m3E+2JokK+sLVJJYAmR8m4OycosuVJP3k8gqNYqT1Y KEhDd+ByLORxg0BAfK0zcEsjbfxOym4JW5CNnRBcY7Dcx+BOc1xmrZccPVuh+3z4Tf5Q tApA== X-Gm-Message-State: ALoCoQk8PYvgBMurT60gphAAtAyz+TDhRv4V12w55at7PXhGKYqk5En8/jUgbY6ErR0uKxiWcZPo MIME-Version: 1.0 X-Received: by 10.180.105.68 with SMTP id gk4mr4410682wib.30.1422024077514; Fri, 23 Jan 2015 06:41:17 -0800 (PST) Received: by 10.194.78.77 with HTTP; Fri, 23 Jan 2015 06:41:17 -0800 (PST) In-Reply-To: <01cb01d0370f$8e533800$4001a8c0@gateway.2wire.net> References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> <66E79E433DA56A4BBE653AE8767EC2353E1BBEEB@szxema505-mbs.china.huawei.com> <01cb01d0370f$8e533800$4001a8c0@gateway.2wire.net> Date: Fri, 23 Jan 2015 09:41:17 -0500 Message-ID: From: Warren Kumari To: "t.petch" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "opsawg@ietf.org" , draft-du-opsawg-snmp-key-localization@tools.ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.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, 23 Jan 2015 14:41:22 -0000 [ With chair hat ] Yup - this does not seem like a document that the WG is interested in working on. If the authors are concerned about the strength of the key created by the password expansion function, I'd suggest that a blog posting suggesting longer passwords be used would be more useful. W On Fri, Jan 23, 2015 at 8:21 AM, t.petch wrote: > ----- Original Message ----- > From: "Fangliang (Leon, ICSL)" > To: "t.petch" ; > Cc: ; "Hedanping > (Ana)" > Sent: Friday, January 23, 2015 7:26 AM > >> Hi Tom and all, >> >> Network management protocol is usually attackers' target. Once > attacked, the service will be tampered and result in significant > security issue. As SNMP is the widely used management protocol for > network device and a large proportion of network devices support SNMP, > the security of SNMP is especially important. As a result we (IETF) > should pay more attention to SNMP security issues. >> >> The security expert as Stuart McClure have mentioned SNMP in his > famous book as "HACKING EXPOSED 7: NETWORK SECURITY SECRETS & > SOLUTIONS", McGraw-Hill Education, 2012, pp 348: Conceived as a network > management and monitoring service, the Simple Network Management > Protocol (SNMP) is designed to provide intimate information about > network devices, software, and systems. As such, it is a frequent target > of attackers. In addition, its general lack of strong security > protections has garnered it the colloquial name =E2=80=9CSecurity Not My > Problem.=E2=80=9D >> >> The current Key Localization Algorithm have obvious vulnerability. We > never see such cryptographic algorithm defect in other widely used > protocol. Hacker communities have mentioned the current key localization > method as a loophole, and plan to exploit the vulnerability or publish > it to CVE. >> >> To add an extra password processing module for SNMPV3, it need add > more restricted condition than the regular way. We have discussed it > with design teams, nobody accept this design proposal, for it will > induce more interoperability problems for other password based module. > Besides, this is a collision problem in key localization in SNMP, it is > not suitable to demand the developer to change the general module to fix > this special problem in SNMP. >> >> In consideration of other architectural vulnerability, this > vulnerability can be easily fixed by little revision as proposed by this > draft . Any comments? > > I think the same comment as last time, that the improvement in security > is slight and the cost of doing so significant. And better alternatives > are available (e.g. SNMP over TLS, Netconf). > > Tom Petch > >> >> >> Regards, >> Fang Liang >> >> >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: t.petch [mailto:ietfc@btconnect.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B412=E6=9C=881=E6=97=A5= 18:31 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhangdacheng (Dacheng); Hedanping (Ana); op= sawg@ietf.org >> =E6=8A=84=E9=80=81: draft-du-opsawg-snmp-key-localization@tools.ietf.org >> >> ----- Original Message ----- >> From: "Zhangdacheng (Dacheng)" >> To: "Hedanping (Ana)" ; >> Cc: >> Sent: Saturday, November 29, 2014 3:59 AM >> >> > Let me help clarify Danping's point. >> > >> > We found there was a problem in the localization algorithm, but we > are >> not sure whether this issue is worthwhile for us to address, or the > effort of addressing this issue is out of scope of the SNMP > specification. So, we raise this question here, and hope to get comments > or suggestions. >> >> The new algorithm that you propose seems to offer very little > improvement. You suggest that after replicating the password, you then > add the password length in the last four octets to bring the length up > to 64 octet. This seems to add very little entropy. >> >> Also, an 8 character string, containing upper case, lower case, digit > and extended punctuation would have been regarded as too weak many years > ago and we should not be documenting such an approach now. >> >> Again, anyone who uses a password based system and does not have a > extra module to ensure that passwords meet current standards deserves > all the security breaches they get! >> >> Tom Petch >> >> > >> > Cheers >> > >> > Dacheng >> > >> > > -----Original Message----- >> > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of > Hedanping >> > > (Ana) >> > > Sent: Saturday, November 29, 2014 10:52 AM >> > > To: opsawg@ietf.org >> > > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org >> > > Subject: [OPSAWG] FW: New Version Notification for >> > > draft-du-opsawg-snmp-key-localization-00.txt >> > > >> > > Dear all, >> > > We find a security problem in the current SNMP key localization >> algorithm, but >> > > we are not sure whether IETF is the right place to improve it. The >> draft is >> > > submitted and comments are appreciated. >> > > >> > > A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt >> > > has been successfully submitted by Danping He and posted to the > IETF >> > > repository. >> > > >> > > Name: draft-du-opsawg-snmp-key-localization >> > > Revision: 00 >> > > Title: A New Algorithm for SNMP Key Localization Document date: >> > > 2014-11-28 >> > > Group: Individual Submission >> > > Pages: 4 >> > > URL: >> > > >> > http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localizatio >> n-00. >> > > txt >> > > Status: >> > > >> > https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localization/ >> > > Htmlized: >> > > > http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 >> > > >> > > Abstract: >> > > This draft discusses a security issue with the algorithm for >> > > generating SNMP localized keys and introduce a new algorithm to >> > > address this problem. >> > > >> > > Regards, >> > > Ana (Danping) >> > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --=20 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 From nobody Fri Jan 23 07:13:19 2015 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 019DC1A9111 for ; Fri, 23 Jan 2015 07:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 vuHgqe8BuPy4 for ; Fri, 23 Jan 2015 07:13:12 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0086.outbound.protection.outlook.com [65.55.169.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9841A90EB for ; Fri, 23 Jan 2015 07:13:12 -0800 (PST) Received: from SN2PR0601MB719.namprd06.prod.outlook.com (25.160.14.152) by SN2PR0601MB718.namprd06.prod.outlook.com (25.160.14.151) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 23 Jan 2015 15:13:09 +0000 Received: from SN2PR0601MB719.namprd06.prod.outlook.com ([25.160.14.152]) by SN2PR0601MB719.namprd06.prod.outlook.com ([25.160.14.152]) with mapi id 15.01.0059.007; Fri, 23 Jan 2015 15:13:09 +0000 From: Chris Grundemann To: Scott Bradner , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf Thread-Index: AQHQKsfbXCqKhG9MSk2PnEtMUHx6k5y1Q6OA//+QcwCAAP8pgIAA0qkAgAmY7gCAABhCgIANYcmA//+6Z4A= Date: Fri, 23 Jan 2015 15:13:08 +0000 Message-ID: References: <20150107225223.GA14477@elstar.local> <20150108072623.GB15231@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F645E91358@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.14.10.13] authentication-results: sobco.com; dkim=none (message not signed) header.d=none;sobco.com; dmarc=none action=none header.from=isoc.org; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:SN2PR0601MB718; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:SN2PR0601MB718; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(479174004)(24454002)(377454003)(99286002)(230783001)(2501002)(66066001)(106116001)(40100003)(122556002)(87936001)(2656002)(86362001)(2900100001)(2950100001)(102836002)(92566002)(46102003)(19580405001)(93886004)(19580395003)(62966003)(77156002)(54356999)(36756003)(76176999)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR0601MB718; H:SN2PR0601MB719.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2015 15:13:08.8192 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0601MB718 Archived-At: Cc: "draft-opsawg-operators-ietf@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 23 Jan 2015 15:13:16 -0000 On 1/23/15, 5:22 AM, "Scott O. Bradner" wrote: >It is the opinion of this chair (Warren having recused himself) that the >ID author >should see if he can do what David suggests (add material summarizing the >problem at the end of the draft) and republish as a non-WG ID. The WG >can revisit >the question of adoption after that is done. We can and will, although we were very much hoping to do this as more of a community and less as two individuals. Ah well - consensus was not met... > >My personal view is that this is useful information (though more details >of the >actual research would be helpful (as Juergen commented) and the IETF >would benefit from the information being published as an RFC but it would >mostly help if the IETF actually made use of the information in some way >to >broaden operator participation - I am not sure how to get there from >here (or from the ID). That=B9s exactly the conversation we were hoping this working group would have, which is of course why we submitted the document for adoption. I see this as an opportunity missed, but we=B9ll try again=8A Disappointed in Denver, ~Chris From nobody Fri Jan 23 07:13:46 2015 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 0DD371A9111 for ; Fri, 23 Jan 2015 07:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NjJ2urBCDh01 for ; Fri, 23 Jan 2015 07:13:39 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA831A90F0 for ; Fri, 23 Jan 2015 07:13:35 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0A2CE28B003D; Fri, 23 Jan 2015 10:13:35 -0500 (EST) Received: from ispx.vb.futz.org (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id CCB141F8035; Fri, 23 Jan 2015 10:13:34 -0500 (EST) Date: Fri, 23 Jan 2015 10:13:52 -0500 From: Robert Story To: Johannes Merkle Message-ID: <20150123101352.69cc34f1@ispx.vb.futz.org> In-Reply-To: <54C21DE7.4030700@secunet.com> References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> <66E79E433DA56A4BBE653AE8767EC2353E1BBF27@szxema505-mbs.china.huawei.com> <54C21DE7.4030700@secunet.com> Organization: Parsons X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/nMueNOK1weBL9oWz5tQuH7K"; protocol="application/pgp-signature" Archived-At: Cc: "opsawg@ietf.org" , "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.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, 23 Jan 2015 15:13:42 -0000 --Sig_/nMueNOK1weBL9oWz5tQuH7K Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 23 Jan 2015 11:09:43 +0100 Johannes wrote: JM> I don't mean say that the issue is completely irrelevant, but just it JM> is not as severe as your post seems to imply. And given the JM> difficulties involved with a potential change, I doubt that it is worth. JM>=20 JM> That said, I suggest to include a warning into the security JM> considerations of draft-hmac-sha-2-usm-snmp pointing to this issue and JM> recommending (generally) to use sufficiently strong passwords. RFC 3414 JM> already contains such a caveat but repeating it in the new JM> specification might help to draw attention to it. +1 Robert --=20 Senior Software Engineer @ Parsons --Sig_/nMueNOK1weBL9oWz5tQuH7K Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUwmU0AAoJEMHFVuy5l8Y4/VgQAKkSSFy6/9vKWhXsdv4WkA2o c10KWwbYCQokIb6x4jvDJA61ykaMXk+tt+jOGFq6CD0xX0hjrw+P2dwFv9KjItwE Gr7L7N6+TypWpm8vr/Lf/+0Xdz2VezwOdR4tRWOtlYH33FqG5VjngJ0GWZFEShgC OPVjog3j4va/YZX8F1/RrMiBCWG7i5fSgrg4BZ9wvcdx1DCJpNdML4bsP+jnj9uL VWRHVMmCT+QiYhPlwujV3Cof6VvEg67LrfA8cylvYJZ1SPXQ+6hJd/WR5aEiQHs2 Dx3pJNnU9rdcw8FI3haVpkLJGLI7KLAgw01rBU4ENhJBbHJQZO4SIVan/nkE6EIg ogp2Pc01bKsOfjrV0N9RdnuvzOHKMzwKQJDEIoVAsXBPCuCOmKndRfAnoFM3Ua6J XMSbKOnjEYV3/gMT8eY/lx8opuMUd0QsSq3u4u6Vb6uSP0U4NFHGs5eFNfpv7fKk 3euxrl0G1hPJ3llC77LlJ/daFAHTbs/D8Qxy41z1fOhdRCnjYU1Hw7ZZq62m3duB WuOqbipF8R3qhGtUBrdfulNZXCM5nfUcdSdvOdIIi0KIAbZkh77PwASsEYrSv8nW PJqWcn9+qeHVaeg7GjgblaSdlUSnzJzAe2n8ZZkszOjgXG1ikUuaIqIr/eCe/jg/ ytCPmaKfnnsl8zZlshq8 =i/zy -----END PGP SIGNATURE----- --Sig_/nMueNOK1weBL9oWz5tQuH7K-- From nobody Fri Jan 23 07:22:48 2015 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 95B371A9132 for ; Fri, 23 Jan 2015 07:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 KlkfS-U-p8gn for ; Fri, 23 Jan 2015 07:22:42 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA7D1A9130 for ; Fri, 23 Jan 2015 07:22:42 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E9BA3F99; Fri, 23 Jan 2015 16:22:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lrbKd-qPJuOr; Fri, 23 Jan 2015 16:22:13 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 Jan 2015 16:22:40 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38FF620036; Fri, 23 Jan 2015 16:22:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wYxNytZsSNb7; Fri, 23 Jan 2015 16:14:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41EF320035; Fri, 23 Jan 2015 16:22:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DCCA030E5A38; Fri, 23 Jan 2015 16:22:37 +0100 (CET) Date: Fri, 23 Jan 2015 16:22:37 +0100 From: Juergen Schoenwaelder To: Chris Grundemann Message-ID: <20150123152237.GA40827@elstar.local> Mail-Followup-To: Chris Grundemann , Scott Bradner , "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" References: <20150107225223.GA14477@elstar.local> <20150108072623.GB15231@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F645E91358@dfweml701-chm> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "opsawg@ietf.org" , "draft-opsawg-operators-ietf@tools.ietf.org" , Scott Bradner Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 15:22:47 -0000 On Fri, Jan 23, 2015 at 03:13:08PM +0000, Chris Grundemann wrote: > > That¹s exactly the conversation we were hoping this working group would > have, which is of course why we submitted the document for adoption. I see > this as an opportunity missed, but we¹ll try againÅ  > I believe it makes sense to publish the survey report as an individual submission and in addition to have discussions on possible actions and implications in OPSAWG or OPS-AREA. Should those discussions lead to something sensible worth documenting, this can become an OPSAWG work item. There is no need to adopt a document to have a conversation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jan 23 08:44:43 2015 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 AA7FF1A9126 for ; Fri, 23 Jan 2015 08:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nIdTSQuwpfhE for ; Fri, 23 Jan 2015 08:44:39 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8291A1AD8 for ; Fri, 23 Jan 2015 08:44:39 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0NGiZ0W001100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 11:44:36 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t0NGiZ0W001100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1422031477; bh=QwqSEhN/zCxNSPAYhoA/X0AdrJk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=cCvRLRT+LLV48LhqUXrOZmm1Fq31HfcFKZ55rErpF5bwEEb083sWFCpomN6yrH/5W vIfGn9bmT7SFwK8G0nryMo+Vzk+hywUDWE4V0MMVPd/ObUjgdjrXzE0k76BjakUyL4 df83vRHaayJ29FQCnoAoCO1X1Z8tzr6oF2Zqdiwo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t0NGiZ0W001100 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 23 Jan 2015 11:42:23 -0500 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t0NGiGhQ032209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 11:44:17 -0500 Received: from MXHUB105.corp.emc.com (10.253.50.22) by mxhub26.corp.emc.com (10.254.110.182) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 23 Jan 2015 11:44:16 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB105.corp.emc.com ([10.253.50.22]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 11:44:16 -0500 From: "Black, David" To: Chris Grundemann , Scott Bradner , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf Thread-Index: AQHQKsfdvQz/lZehfUuwJ6WO9r0McZy1l3SAgAAFzwCAAInOgIAA0qkAgAlCThCAAG7igIANYcmAgAAvvgD//8PboA== Date: Fri, 23 Jan 2015 16:44:15 +0000 Message-ID: References: <20150107225223.GA14477@elstar.local> <20150108072623.GB15231@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F645E91358@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.72] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "draft-opsawg-operators-ietf@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf 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, 23 Jan 2015 16:44:41 -0000 > >It is the opinion of this chair (Warren having recused himself) that the= ID author > >should see if he can do what David suggests (add material summarizing th= e > >problem at the end of the draft) and republish as a non-WG ID. The WG c= an revisit > >the question of adoption after that is done. > We can and will, although we were very much hoping to do this as more of = a > community and less as two individuals. Ah well - consensus was not met... As I originally wrote, I would support adoption of this draft if the purpos= e was to expand it into a problem statement, but that's not how the purpose of adopt= ing the draft was characterized. With luck, the added material can make that purpo= se clear, and a subsequent adoption call would have a positive outcome. Thanks, --David > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Chris Grundema= nn > Sent: Friday, January 23, 2015 10:13 AM > To: Scott Bradner; opsawg@ietf.org > Cc: draft-opsawg-operators-ietf@tools.ietf.org > Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf >=20 >=20 >=20 > On 1/23/15, 5:22 AM, "Scott O. Bradner" wrote: >=20 > >It is the opinion of this chair (Warren having recused himself) that the= ID > author > >should see if he can do what David suggests (add material summarizing th= e > >problem at the end of the draft) and republish as a non-WG ID. The WG c= an > revisit > >the question of adoption after that is done. >=20 > We can and will, although we were very much hoping to do this as more of = a > community and less as two individuals. Ah well - consensus was not met... > > > >My personal view is that this is useful information (though more details= of > the > >actual research would be helpful (as Juergen commented) and the IETF > >would benefit from the information being published as an RFC but it woul= d > >mostly help if the IETF actually made use of the information in some way= to > >broaden operator participation - I am not sure how to get there from > >here (or from the ID). >=20 > That=B9s exactly the conversation we were hoping this working group would > have, which is of course why we submitted the document for adoption. I se= e > this as an opportunity missed, but we=B9ll try again=D0 >=20 > Disappointed in Denver, > ~Chris >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Jan 26 07:35:24 2015 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 B9ACB1A8BBF for ; Mon, 26 Jan 2015 07:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 kypvy90bjcTo; Mon, 26 Jan 2015 07:35:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6051C1A88A1; Mon, 26 Jan 2015 07:35:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-use-cases.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126153519.1384.12030.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 07:35:19 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: 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: Mon, 26 Jan 2015 15:35:21 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Mon Jan 26 07:36:36 2015 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 CC6E81A8BC5; Mon, 26 Jan 2015 07:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 N0PYFdGgBuuf; Mon, 26 Jan 2015 07:36:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DB21A8BBF; Mon, 26 Jan 2015 07:36:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: iesg-secretary@ietf.org, iesg@ietf.org, opsawg@ietf.org, opsawg-chairs@tools.ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126153629.1315.24852.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 07:36:29 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] Telechat update notice: 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: Mon, 26 Jan 2015 15:36:33 -0000 Placed on agenda for telechat - 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ From nobody Mon Jan 26 07:39:27 2015 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 C432F1A9024 for ; Mon, 26 Jan 2015 07:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 k4kQMYJFatHu; Mon, 26 Jan 2015 07:39:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFB01A90AE; Mon, 26 Jan 2015 07:39:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126153922.1380.38506.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 07:39:22 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: 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: Mon, 26 Jan 2015 15:39:25 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ From nobody Mon Jan 26 14:05:16 2015 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 4B2C71B2AA8 for ; Mon, 26 Jan 2015 14:05:11 -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 Tif_HKsdv5tQ; Mon, 26 Jan 2015 14:05:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F3E1A0058; Mon, 26 Jan 2015 14:05:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-use-cases.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126220508.12335.53372.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 14:05:08 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: 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: Mon, 26 Jan 2015 22:05:11 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Mon Jan 26 14:27:11 2015 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 5AEA11B2AAF for ; Mon, 26 Jan 2015 14:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 43uOXndUhjti for ; Mon, 26 Jan 2015 14:26:59 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917151B2AB3 for ; Mon, 26 Jan 2015 14:26:59 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id l15so1347728wiw.0 for ; Mon, 26 Jan 2015 14:26:58 -0800 (PST) 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=OpgcoKpbfKclv/OgoIe0Ortp47pIZdt0jBuFmcmBJvQ=; b=iR7BK+z6/e3vWPdn3qRPcH1f4HOxARcIv08s9+EymSXYK5pLcIES9GHUtZgLTE2E6V /kiBy7nGwYhIof6/yXLJ6B9JKMwwFWtrlHUaHTO1NBSXzOr4dXP+h/vzAamXQzPvLDkM UmqQnkdyWj2hLIZE0fGPLScmhlPxELHW7hFZiohuHyVnSRWM6uNn8IdD6ceL/t45LjLL GKZaFALUPTQoV9h3/qsylM77SJaEhk2hyAiDfi/3wtESXmlI9HtPcMoqf15rDBvgVnxS DIAQg6vNDVqhh/mlHQU5mz7pcEFR3onP9Wwk4dy7LfZ3zGGyuq/jB/S1/Etye1By6t8e WIKA== X-Gm-Message-State: ALoCoQna2C33JMYtgzJ4S+NkI4KMsANxOyZgbg6fSQyjgla1R7JMZHKAf8BIM+DcbQek7984M3Tt MIME-Version: 1.0 X-Received: by 10.180.73.112 with SMTP id k16mr19000914wiv.42.1422311218263; Mon, 26 Jan 2015 14:26:58 -0800 (PST) Received: by 10.194.78.77 with HTTP; Mon, 26 Jan 2015 14:26:58 -0800 (PST) In-Reply-To: <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> Date: Mon, 26 Jan 2015 17:26:58 -0500 Message-ID: From: Warren Kumari To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dhcwg@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 26 Jan 2015 22:27:02 -0000 On Thu, Jan 22, 2015 at 6:39 PM, Ted Lemon wrote: > On Jan 4, 2015, at 4:32 PM, joel jaeggli wrote: >> After some dicussion last year, I have agreed to sponsor >> draft-wkumari-dhc-capport >> (https://tools.ietf.org/html/draft-wkumari-dhc-capport-07). what I'm >> looking for feeback on right now is feedback from potential >> implementors, either of client implementations of captive portal >> detection or captive portals as to: >> >> * Whether or not this represents a reasonable optimization, >> >> * Have we gotten the security considerations right? >> >> * Would you use it if there was general consensus to the approach. > > I haven't seen any responses to this. I don't expect you'll see any "we = would use this responses," and you shouldn't predicate this work on seeing = any. I think the idea is fine, although I think the requirement that the = URI use an address literal is unnecessary. If the implementor wants to do= that, they can, or they can just only answer DNS queries for the local dom= ain until the user authenticates. They'd have to do that to support the r= edirect anyway. > > I think the document has way too much explanatory text. It's good that = it's there for now so that people can understand the problem that this draf= t purports to solve, but it should not be in the final version. Just expl= ain how to use DHCP and ND to send this option (I think supporting it in ND= is worthwhile, because DHCP isn't really very useful in an IPv6 hotspot en= vironment). > I've made it quite a bit shorter, but I've left in *some* background so that it's clear to the intended audience why this is a better option than their current one. Some of the audience for this is people who run Captive Portals, and so a little more text than a usual IETF person will need is appropriate. > It would be nice to talk about ways to authenticate this, e.g. PKI or DNS= SEC certs. I do have some text in here about TLS for the payments part, but I'm unclear as to where else we would need to authenticate stuff. > > I think you should run it by some people with HTTP fu to make sure that y= ou haven't missed any obvious gaps, and of course run it by somebody with H= TTP security fu to make sure there aren't any security flaws that need to b= e addressed. Thank you, good point. I have already shown it to several people of that ilk and they are happy. > > I would not object to you AD-sponsoring this. It's not in-charter for D= HC, nor for 6man. You should get it reviewed in both places, not just in = DHC. Yeah. When I named the document I hadn't realized that simply using a dhcp option isn't something that DHC does. This means that it has been unnecessarily cluttering up their document queue - sorry! > > You may find section 5.7 of RFC 7227 useful: it would be good to make sur= e that your use of the DHCP URI option format meshes with what RFC 7227 doe= s. I didn't notice a problem, but didn't look all that carefully. Yup, thanks. I *think* it's OK, but I'll poke Dan (one of the authors of RFC 7227) and twist his arm ^w^w^w ask him nicely to have a look.... Thank you for your feedback. I've posted an edit buffer here: https://github.com/wkumari/draft-wkumari-dhc-capport and will release it once I've incorporated other comments too... W > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --=20 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 From nobody Mon Jan 26 18:06:21 2015 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 CF25E1A1B62 for ; Mon, 26 Jan 2015 18:06:12 -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 0n0Ztu_iTbl4; Mon, 26 Jan 2015 18:06:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CB71A1B3A; Mon, 26 Jan 2015 18:05:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150127020551.32608.20046.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 18:05:51 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: 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: Tue, 27 Jan 2015 02:06:16 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ From nobody Tue Jan 27 02:46:00 2015 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 35C7B1B2BB7; Mon, 26 Jan 2015 23:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZgVn4QWQJ3qM; Mon, 26 Jan 2015 23:50:30 -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 383911B2BBD; Mon, 26 Jan 2015 23:50:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL71875; Tue, 27 Jan 2015 07:50:22 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 Jan 2015 07:50:21 +0000 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.222]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 27 Jan 2015 15:50:14 +0800 From: "Fuyu (Eleven)" To: Tom Taylor Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-perrault-behave-natv2-mib-00.txt Thread-Index: AQHQM5wZ3ZnSCC9zhEy9NYG9dwVfrZzTo9cA Date: Tue, 27 Jan 2015 07:50:14 +0000 Message-ID: References: <20150119034503.15593.74413.idtracker@ietfa.amsl.com> <54BC8093.7030104@gmail.com> In-Reply-To: <54BC8093.7030104@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.99.184] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 27 Jan 2015 02:45:56 -0800 Cc: "opsawg@ietf.org" , "behave@ietf.org" , Spencer Dawkins Subject: Re: [OPSAWG] [BEHAVE] Fwd: New Version Notification for draft-perrault-behave-natv2-mib-00.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: Tue, 27 Jan 2015 07:50:32 -0000 Hi Tom,=20 Some comments for the draft-perrault-behave-natv2-mib-00.txt, I think they = are typos:) natv2PoolIndex OBJECT-TYPE SYNTAX Natv2PoolId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index of an address pool, unique for a given NAT instance. It is up to the agent implementation to determine and operate upon only those values that correspond to provisioned pools." ::=3D { natv2PoolEntry 2 } In this object, I think the SYNTAX should be Natv2PoolIndex. It doesn't def= ine Natv2PoolId in the draft-perrault-behave-natv2-mib-00.txt. natv2PortMapExternalPool OBJECT-TYPE SYNTAX Natv2PoolIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "Index of the address pool in the external realm from which the mapped external address given in natv2AddressMapExternalAddress was taken. Zero if the implementation does not support address pools but has chosen to support this object, or if no pool was configured for the given external realm." ::=3D { natv2AddressMapEntry 11 } The name of this object should be natv2AddressMapExternalPool. Cheers=20 Yu -----Original Message----- From: Behave [mailto:behave-bounces@ietf.org] On Behalf Of Tom Taylor Sent: Monday, January 19, 2015 11:57 AM To: behave@ietf.org; opsawg@ietf.org; David Harrington; Spencer Dawkins Subject: [BEHAVE] Fwd: New Version Notification for draft-perrault-behave-n= atv2-mib-00.txt Several months' work, almost done. A couple of sections need work, as indic= ated in the document, but there's lots to review including the complete MIB= module definition. This is a major rewrite from the draft-ietf-behave-nat-11 version of NAT MI= B. Reworking was needed to address all the issues outstanding against that = document. I suppose the next step is to send out a series of messages walki= ng through all the changes from draft-ietf-behave-nat-11 and how they respond to the open issues. I look forward to any comments on the new document. Tom Taylor -------- Forwarded Message -------- Subject: New Version Notification for draft-perrault-behave-natv2-mib-00.tx= t Date: Sun, 18 Jan 2015 19:45:03 -0800 From: internet-drafts@ietf.org .... A new version of I-D, draft-perrault-behave-natv2-mib-00.txt has been successfully submitted by Tom Taylor and posted to the IETF reposi= tory. Name: draft-perrault-behave-natv2-mib Revision: 00 Title: Definitions of Managed Objects for Network Address Translators (NAT= ) Document date: 2015-01-18 Group: Individual Submission Pages: 80 URL:=20 http://www.ietf.org/internet-drafts/draft-perrault-behave-natv2-mib-00.txt Status:=20 https://datatracker.ietf.org/doc/draft-perrault-behave-natv2-mib/ Htmlized:=20 http://tools.ietf.org/html/draft-perrault-behave-natv2-mib-00 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function. The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document. A companion document deprecates all objects in NAT- MIB. NATV2-MIB can be used for monitoring of NAT instances on a device capable of NAT function. Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN). =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From nobody Tue Jan 27 05:42:53 2015 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 000DD1A1A6E; Tue, 27 Jan 2015 05:42:43 -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 qVUvn9ao6fSO; Tue, 27 Jan 2015 05:42:35 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491811A026F; Tue, 27 Jan 2015 05:42:35 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id tr6so15111658ieb.4; Tue, 27 Jan 2015 05:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ttdyaCr/gbGVTat7ZVG8MPzRT38QlhwEH/DAofdW1SY=; b=wVfwELJsWhdGe2pA3qB+obcE0FSwLpTME2gUMpob05mX6z5UeskhkpElLcnMW8+nG2 FeZycMJDe4dnWIrxb/XfTV7XwClVhwz9L3A8fmsqsIE5c+wW738G0LX6dJAORpzU74RG j/gKu1LnAJbTG83SI7AciXUC961nUuJHfAXjfiYSWvUtoEhtKqjdAIwjHCmuZdmcUrOO cWp7qRyXfAlSHYmvwPedHVdq+gg7nLI8IRADFrd/XrmdcsV6T7l5QuB9tAhw748NLbQw cbt237XEaUKWmkmjnnldkXKC2TNZcQUDgJgPLo02QItI35YocCZ0QB3ufwG/7HslJYmo ZcZw== X-Received: by 10.50.176.196 with SMTP id ck4mr22448635igc.40.1422366154425; Tue, 27 Jan 2015 05:42:34 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-73-98.tor.primus.ca. [173.206.73.98]) by mx.google.com with ESMTPSA id w140sm701299iod.13.2015.01.27.05.42.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jan 2015 05:42:34 -0800 (PST) Message-ID: <54C795CA.6020206@gmail.com> Date: Tue, 27 Jan 2015 08:42:34 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Fuyu (Eleven)" References: <20150119034503.15593.74413.idtracker@ietfa.amsl.com> <54BC8093.7030104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "opsawg@ietf.org" , "behave@ietf.org" , Spencer Dawkins Subject: Re: [OPSAWG] [BEHAVE] Fwd: New Version Notification for draft-perrault-behave-natv2-mib-00.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: Tue, 27 Jan 2015 13:42:44 -0000 Thank you very much. Tom On 27/01/2015 2:50 AM, Fuyu (Eleven) wrote: > Hi Tom, > > Some comments for the draft-perrault-behave-natv2-mib-00.txt, I think they are typos:) > > natv2PoolIndex OBJECT-TYPE > SYNTAX Natv2PoolId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Index of an address pool, unique for a given NAT instance. > It is up to the agent implementation to determine and > operate upon only those values that correspond to > provisioned pools." > ::= { natv2PoolEntry 2 } > > In this object, I think the SYNTAX should be Natv2PoolIndex. It doesn't define Natv2PoolId in the draft-perrault-behave-natv2-mib-00.txt. > > natv2PortMapExternalPool OBJECT-TYPE > SYNTAX Natv2PoolIndexOrZero > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Index of the address pool in the external realm from which > the mapped external address given in > natv2AddressMapExternalAddress was taken. Zero if the > implementation does not support address pools but has chosen > to support this object, or if no pool was configured for the > given external realm." > ::= { natv2AddressMapEntry 11 } > > The name of this object should be natv2AddressMapExternalPool. > > Cheers > Yu > > -----Original Message----- > From: Behave [mailto:behave-bounces@ietf.org] On Behalf Of Tom Taylor > Sent: Monday, January 19, 2015 11:57 AM > To: behave@ietf.org; opsawg@ietf.org; David Harrington; Spencer Dawkins > Subject: [BEHAVE] Fwd: New Version Notification for draft-perrault-behave-natv2-mib-00.txt > > Several months' work, almost done. A couple of sections need work, as indicated in the document, but there's lots to review including the complete MIB module definition. > > This is a major rewrite from the draft-ietf-behave-nat-11 version of NAT MIB. Reworking was needed to address all the issues outstanding against that document. I suppose the next step is to send out a series of messages walking through all the changes from > draft-ietf-behave-nat-11 and how they respond to the open issues. > > I look forward to any comments on the new document. > > Tom Taylor > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-perrault-behave-natv2-mib-00.txt > Date: Sun, 18 Jan 2015 19:45:03 -0800 > From: internet-drafts@ietf.org > .... > > A new version of I-D, draft-perrault-behave-natv2-mib-00.txt > has been successfully submitted by Tom Taylor and posted to the IETF repository. > > Name: draft-perrault-behave-natv2-mib > Revision: 00 > Title: Definitions of Managed Objects for Network Address Translators (NAT) > Document date: 2015-01-18 > Group: Individual Submission > Pages: 80 > URL: > http://www.ietf.org/internet-drafts/draft-perrault-behave-natv2-mib-00.txt > Status: > https://datatracker.ietf.org/doc/draft-perrault-behave-natv2-mib/ > Htmlized: > http://tools.ietf.org/html/draft-perrault-behave-natv2-mib-00 > > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for devices implementing the Network Address Translator (NAT) > function. The new MIB module defined in this document, NATV2-MIB, is > intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not > backwards compatible with NAT-MIB, for reasons given in the text of > this document. A companion document deprecates all objects in NAT- > MIB. NATV2-MIB can be used for monitoring of NAT instances on a > device capable of NAT function. Compliance levels are defined for > three application scenarios: basic NAT, pooled NAT, and carrier-grade > NAT (CGN). > > > > > > 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 > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From nobody Tue Jan 27 07:20:45 2015 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 5DF181A87C9 for ; Tue, 27 Jan 2015 07:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 fqsM8qJnNxIX for ; Tue, 27 Jan 2015 07:20:41 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1996E1A87EF for ; Tue, 27 Jan 2015 07:20:31 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id y19so15370540wgg.2 for ; Tue, 27 Jan 2015 07:20:29 -0800 (PST) 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=s+64x61b5pSyqp2zSy0+OewS0V+3OwaHUPXeXGMjVCI=; b=l6ld/+fnN5oX/vlXCSHMaADpf6PkaoidbLjiRlmyStoKRzlT9Jv/uyxNIn93yh8E1R xbSTy6ddIOtg9wPKaca4l4/SjX9ejj3TR7+xbSE4Poug0h7GrjIHuHeZLZE21e49XVOf K+y4oZrRIl4mzojl1WYDQ+e/JcpEbf5quXhxtHujpRR2j1sY0IXM5DRf6WoNBMkm7u1g 1nu8/eUuMyYIpj3b788jfGLJFAVfdOw0IwDis5RTxC3nRYwr2JkeYd9E8EdoWk4dm4a/ ZaQBLyOAj6x1jSQYFp+1K/VVlX3U5DElI0+aTl9CJH5Kr238FZ+QlrUGWpNxrnDe329A LxHg== X-Gm-Message-State: ALoCoQn+/4PJRGi17xCq0CMiQwnPVNCxJ5dhZ8BUgskydmDAfvwO1r/+9BNeACXn4dZ+JOkKA3GF MIME-Version: 1.0 X-Received: by 10.194.184.41 with SMTP id er9mr3748748wjc.23.1422372029718; Tue, 27 Jan 2015 07:20:29 -0800 (PST) Received: by 10.194.78.77 with HTTP; Tue, 27 Jan 2015 07:20:29 -0800 (PST) In-Reply-To: References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> Date: Tue, 27 Jan 2015 10:20:29 -0500 Message-ID: From: Warren Kumari To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dhcwg@ietf.org" , Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 27 Jan 2015 15:20:43 -0000 On Fri, Jan 23, 2015 at 8:08 AM, Ted Lemon wrote: > On Jan 23, 2015, at 5:23 AM, Ole Troan wrote: >> is this needed when you have 802.11u? > > I've never actually seen an example of 802.11u in the wild. Have you? Not that I know of... > What I see in the wild are layer 3 solutions based on spoofing. It woul= d certainly be worth investigating this question, but I think even if 802.1= 1u did see wide deployment in large WiFi network scenarios, this would stil= l be useful for the coffee-shop scenario. I've just spent some time going through the .11u / WiFi Alliance Passpoint stuff (200page PDF, sells for $199.00!), and it seems like it would be overkill for many situations. It may be a good fit for a large provider, willing to roll out all of the needed back end stuff, etc but doesn't seem like a great fit for coffee-shop / doctor's office / hotels we go to, etc. It also seems like it will be a long time till this would be rolled out everywhere - the draft is simply a DHCP option that should be trivial to add. In addition, not *everything* is wireless - when I go to a hotel the first thing I look for is the wired jack, because hotel wifi is often less than brilliant. > >> does it conflict or should it be integrated with the prefix properties i= nhttp://tools.ietf.org/html/draft-lepape-6man-prefix-metadata-00 > > It seems orthogonal, but it sounds like you think it's not, so it might b= e worth you exploring that a bit more! I had a look at it, it expired in Jan 2014, as a -00, so I'm guessing it is not likely to progress. It didn't seem like it would really fit well - I think you *could* assign a well known color to flag "you are behind a CP", but I see an easy way to put in the URI, etc.. > >> what's this proposals relationship with MIF's PVDs? > > I think it's orthogonal. This doesn't really change what a hotspot netw= ork looks like--it just makes it possible to flag a network as a hotspot ne= twork without any skullduggery. Yup. This is really meant to be a *simple* solution that allows the captive portal to tell the client where to go to authenticate. W > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --=20 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 From nobody Tue Jan 27 07:31:26 2015 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 6181D1A8825; Tue, 27 Jan 2015 07:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Uerd4fhlRM9Z; Tue, 27 Jan 2015 07:31:11 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 0AC9C1A8771; Tue, 27 Jan 2015 07:31:09 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id CFF6BDA00DE; Tue, 27 Jan 2015 15:31:09 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id AF1C853E07D; Tue, 27 Jan 2015 07:31:09 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 27 Jan 2015 07:31:09 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Tue, 27 Jan 2015 10:31:01 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> To: Warren Kumari X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "dhcwg@ietf.org" , Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 27 Jan 2015 15:31:13 -0000 On Jan 27, 2015, at 10:20 AM, Warren Kumari wrote: > In addition, not *everything* is wireless - when I go to a hotel the > first thing I look for is the wired jack, because hotel wifi is often > less than brilliant. Good point. One thing I will say about this BTW is that you should treat DHCPv4 and = DHCPv6 as distinct protocols, because the option formats are different, = and I think it's potentially confusing to lump them together. And = mentioning DHCPv4 and DHCPv6 separately ensures that people won't think = this is an IPv6-only proposal. From nobody Tue Jan 27 07:54:47 2015 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 2EAD21A88BF for ; Tue, 27 Jan 2015 07:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 7OcTpmxGEP7K for ; Tue, 27 Jan 2015 07:54:43 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB831A8865 for ; Tue, 27 Jan 2015 07:51:15 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id x12so15504148wgg.7 for ; Tue, 27 Jan 2015 07:51:14 -0800 (PST) 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=CuvEL/N4P0DsrNvB5PW4nKViVnJ8o0M+zeGN/NHndwg=; b=ZJV7wEeJJQPsWUgtZ5sAqILpPLlnmfpvd6g8L3ce+L/dYAKZOkD5THsJ4gvZz2bG56 6Gza8V4de/QUpC2teFwctBkenayuG0BR1zdAinDuHzm0dNRJZULR1lAX7YylRjD358j0 NePiy/tq/tmQkJ75qt/hIRIO70rXC+e2hkuHJrQzJ/4Vg2pnlkklg1bUjMrZU3vVZTGJ 86j18ayknRbJHnCk3QUqZwMm41M/rtbGZbupHym2COKFGnG5COsdU+l+5iydsM28L9Ic HnmvKPHZfJE8uW54ChMz6ugbmDMFo5T9/OPUZwNTQh4ekqZW6y4zRcHOJRr+k0brcMJB Tukg== X-Gm-Message-State: ALoCoQmbLAQVPvCvG42nl6GVxGzrfagTj+wZ5vzw3t8hqsW8vbH3hVz4ZCT0FMatOLDD5Wo6ttJZ MIME-Version: 1.0 X-Received: by 10.180.105.68 with SMTP id gk4mr7163163wib.30.1422373872786; Tue, 27 Jan 2015 07:51:12 -0800 (PST) Received: by 10.194.78.77 with HTTP; Tue, 27 Jan 2015 07:51:12 -0800 (PST) In-Reply-To: <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> Date: Tue, 27 Jan 2015 10:51:12 -0500 Message-ID: From: Warren Kumari To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 27 Jan 2015 15:54:45 -0000 [ -DHC to cut down on their clutter ] On Tue, Jan 27, 2015 at 10:31 AM, Ted Lemon wrote: > On Jan 27, 2015, at 10:20 AM, Warren Kumari wrote: >> In addition, not *everything* is wireless - when I go to a hotel the >> first thing I look for is the wired jack, because hotel wifi is often >> less than brilliant. > > Good point. > > One thing I will say about this BTW is that you should treat DHCPv4 and D= HCPv6 as distinct protocols, because the option formats are different, and = I think it's potentially confusing to lump them together. And mentioning = DHCPv4 and DHCPv6 separately ensures that people won't think this is an IPv= 6-only proposal. > Good point, done, thanks. Posted a new version! W --=20 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 From nobody Tue Jan 27 08:02:38 2015 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 F18D81A1A60 for ; Tue, 27 Jan 2015 08:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 eL8qAcOVKqsf for ; Tue, 27 Jan 2015 08:02:21 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 D74141A8876 for ; Tue, 27 Jan 2015 08:00:56 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C2E7FDA00E8 for ; Tue, 27 Jan 2015 16:00:56 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id AE9F053E07D; Tue, 27 Jan 2015 08:00:56 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 27 Jan 2015 08:00:56 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Tue, 27 Jan 2015 11:00:48 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> To: Warren Kumari X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 27 Jan 2015 16:02:29 -0000 On Jan 27, 2015, at 10:51 AM, Warren Kumari wrote: > Good point, done, thanks. Hm, I didn't mean to eliminate DHCPv6 entirely. It's quite possible = that RA is sufficient, but for completeness I think it would be better = to have a DHCPv6 option just in case it's needed. From nobody Tue Jan 27 08:29:33 2015 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 ED3CF1A8868 for ; Tue, 27 Jan 2015 08:29:29 -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, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 qZFVcS4aKGUb for ; Tue, 27 Jan 2015 08:29:29 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06361A1A5E for ; Tue, 27 Jan 2015 08:20:01 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w55so10398784wes.1 for ; Tue, 27 Jan 2015 08:20:00 -0800 (PST) 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=bMYJ25h0F9M4y/whZAu9iyWUb/sWCmCbzMB7ExaRjPM=; b=jH/Dqa3K98FLD5OnPbNQ452C9vfqUo0YD46JqsCFrG3oH7rxBR0l8nmEtk81XFJsRw YKlR3NJxD2IJNcp8daGYzQ7ZHYfyADmXR99tbc5D1m858/0cVzCb/b2roo0eWk9UeQns o71P/nPwNIEsNx9o07rDA04XMrjaEWyxBJSkZ8Aw7whSgvvgzFQDu+Wi3tQz7P3Lo+b5 nFU+LdGdbKXeShKw71s+AZJJO8xYAZ61hxnTIh/DiNTYoeZhk0p1h6iYAlbsrOwDsPpl qblq03VGcfB7RsuAcQmvjRfB6Oav/ElSA9uImj2ktl8RLu49F4JopVMT9Qn4Ro1YiYNR BqRQ== X-Gm-Message-State: ALoCoQlTYoMTCLbX1fnpSRuoqsH4XTKj3Hihg2o+3WpB2qq8sG2yCb6wioWAWPZoq41GfjZZrfee MIME-Version: 1.0 X-Received: by 10.194.8.2 with SMTP id n2mr4410806wja.46.1422375600327; Tue, 27 Jan 2015 08:20:00 -0800 (PST) Received: by 10.194.78.77 with HTTP; Tue, 27 Jan 2015 08:20:00 -0800 (PST) In-Reply-To: <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> Date: Tue, 27 Jan 2015 11:20:00 -0500 Message-ID: From: Warren Kumari To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 27 Jan 2015 16:29:30 -0000 On Tue, Jan 27, 2015 at 11:00 AM, Ted Lemon wrote: > On Jan 27, 2015, at 10:51 AM, Warren Kumari wrote: >> Good point, done, thanks. > > Hm, I didn't mean to eliminate DHCPv6 entirely. It's quite possible that RA is sufficient, but for completeness I think it would be better to have a DHCPv6 option just in case it's needed. I can easily put it back :-) I've gone back and forth on the v6 DHCP case a few times. I think it goes like this: -00: DHCPv4 only -01: DHCPv4, DHCPv6 [ DHCPv6 added by Paul E] -02: DHCPv6, RA, DHCPv4 [ RA added as requested by Lorenzo C] -03: DHCPv4, RA [ DHCPv6 removed after threat^w request from Erik Kline :-) ] -04: DHCPv4, RA -05: DHCPv4, RA, bits of DHCPv6 came back. -06: DHCPv4, RA, bits of DHCPv6 -07: DHCPv4, RA, bits of DHCPv6 -08: DHCPv4, RA. I personally like DHCPv4 and DHCPv6, but there seems to be some religion around this stuff :-) Supporting multiple option for v6 means need to provide guidance on what to do when you get *different* answers in DHCPv6 and IPv6 RA. I had text in -02 covering this, I can easily put it back. The whole DHCPv6 vs RA topic is, um, interesting... there appear to be some quite strong opinions around this :-) I'll spin another version with both DHCPv6 and RA, and guidance on what to do if you get both. This will no-doubt annoy some folk, but I can leave the consensus call to Joel :-) W -- 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 From nobody Tue Jan 27 08:39:12 2015 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 14D661A8905 for ; Tue, 27 Jan 2015 08:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 19njethypRfy for ; Tue, 27 Jan 2015 08:39:01 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 1E7DC1A8895 for ; Tue, 27 Jan 2015 08:31:31 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id D2BE8DA00BE for ; Tue, 27 Jan 2015 16:31:30 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 838B653E07D; Tue, 27 Jan 2015 08:31:30 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 27 Jan 2015 08:31:30 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Tue, 27 Jan 2015 11:31:21 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <1CDD41DA-25A7-40D4-B1A7-EB78618E5DEE@nominum.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> To: Warren Kumari X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 27 Jan 2015 16:39:07 -0000 On Jan 27, 2015, at 11:20 AM, Warren Kumari wrote: > I personally like DHCPv4 and DHCPv6, but there seems to be some > religion around this stuff :-) > Supporting multiple option for v6 means need to provide guidance on > what to do when you get *different* answers in DHCPv6 and IPv6 RA. I > had text in -02 covering this, I can easily put it back. >=20 > The whole DHCPv6 vs RA topic is, um, interesting... there appear to be > some quite strong opinions around this :-) > I'll spin another version with both DHCPv6 and RA, and guidance on > what to do if you get both. This will no-doubt annoy some folk, but I > can leave the consensus call to Joel :-) The problem with RA as opposed to DHCPv6 is that we've seen that uptake = of RA options is slow compared to uptake of DHCPv6 options. But we = can't _just_ do DHCPv6, because as you say there is some religion about = DHCPv6, and so certain companies are slow to implement DHCPv6 client = features, if at all. I think the right answer in the case where one = sends it and the other doesn't is to assume that whatever _was_ sent is = definitive, since we can't assume that the source of the RA and the = source of the DHCP service will necessarily be updated at the same time. From nobody Tue Jan 27 09:39:54 2015 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 80E571A88B2 for ; Tue, 27 Jan 2015 09:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 b667Pz19cHm1 for ; Tue, 27 Jan 2015 09:39:50 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED80D1A1BEE for ; Tue, 27 Jan 2015 09:39:49 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id fb4so6645486wid.2 for ; Tue, 27 Jan 2015 09:39:48 -0800 (PST) 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=3hgPB8FH9MycfXVOYdRiK71CQeF4q8Rmy8bOPBw2Fwc=; b=LOLg1/RG/sMn16iJ2WUI1mVcJO/SlU9ggXWOS/ymfSFJBk0/D2Ncjst0EiENGojuN/ B0Z54aNCOuKzt64XIyiExAqEOij8mz8esa51oOryL9BzFBFn2eUNMevXorMqULnnqksN M5nls5WkYJMzOzkORATMAQAylwWwJhpYxfM664lkhGerNCSdvlyzuHcYn/2KpBJeLSPt biv3j0hP1yAWniF1vhXWpkbditTWXWmTr/6PCJ6YiOwtcvXipeGvbTrsq8ZqLiRhhFmL NGscgdu/nJEXCVtx25+MdrrspMnSj8jwrOUxbD+ZAQhuTuZu4REGJ03sE0foDH2F/k1s bl1g== X-Gm-Message-State: ALoCoQl7+44Dqzt9IO6VzF/XdY4qU0iv1jEOl1kr8gVfzkMVz6xFVjyFxX085uC0GUjxm9+MRa7r MIME-Version: 1.0 X-Received: by 10.180.21.162 with SMTP id w2mr9197536wie.42.1422380388601; Tue, 27 Jan 2015 09:39:48 -0800 (PST) Received: by 10.194.78.77 with HTTP; Tue, 27 Jan 2015 09:39:48 -0800 (PST) In-Reply-To: <1CDD41DA-25A7-40D4-B1A7-EB78618E5DEE@nominum.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> <1CDD41DA-25A7-40D4-B1A7-EB78618E5DEE@nominum.com> Date: Tue, 27 Jan 2015 12:39:48 -0500 Message-ID: From: Warren Kumari To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 27 Jan 2015 17:39:51 -0000 On Tue, Jan 27, 2015 at 11:31 AM, Ted Lemon wrote: > On Jan 27, 2015, at 11:20 AM, Warren Kumari wrote: >> I personally like DHCPv4 and DHCPv6, but there seems to be some >> religion around this stuff :-) >> Supporting multiple option for v6 means need to provide guidance on >> what to do when you get *different* answers in DHCPv6 and IPv6 RA. I >> had text in -02 covering this, I can easily put it back. >> >> The whole DHCPv6 vs RA topic is, um, interesting... there appear to be >> some quite strong opinions around this :-) >> I'll spin another version with both DHCPv6 and RA, and guidance on >> what to do if you get both. This will no-doubt annoy some folk, but I >> can leave the consensus call to Joel :-) > > The problem with RA as opposed to DHCPv6 is that we've seen that uptake o= f RA options is slow compared to uptake of DHCPv6 options. But we can't _= just_ do DHCPv6, because as you say there is some religion about DHCPv6, an= d so certain companies are slow to implement DHCPv6 client features, if at = all. Yup. I've been in the middle of some of these discussions :-) I've put back the DHCPv6, and made it clear that there are 2 DHCP options (v4 and v6) > I think the right answer in the case where one sends it and the other doe= sn't is to assume that whatever _was_ sent is definitive, since we can't as= sume that the source of the RA and the source of the DHCP service will nece= ssarily be updated at the same time. Actually, when I ended up doing was saying that devices should prefer the URI in DHCPv4, then DHCPv6, then RA. This gets around the problem of what to do if the CP *does* send multiple URIs (e.g to support clients that only do DHCPv6 or RA) and they are different. W --=20 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 From nobody Tue Jan 27 10:14:42 2015 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 D1C371A8907 for ; Tue, 27 Jan 2015 10:14: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, 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 XVHIfQ8FGiIl for ; Tue, 27 Jan 2015 10:14:29 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BA71A8904 for ; Tue, 27 Jan 2015 10:14:28 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 18:12:23 +0000 Message-ID: <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari , Johannes Merkle References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> Date: Tue, 27 Jan 2015 18:09:53 +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: [81.151.167.59] X-ClientProxiedBy: AMSPR02CA0049.eurprd02.prod.outlook.com (10.242.225.177) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) Authentication-Results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR07MB057; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB057; X-Forefront-PRVS: 046985391D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(377424004)(13464003)(24454002)(51444003)(92566002)(116806002)(77096005)(230783001)(84392001)(1556002)(15975445007)(1720100001)(1456003)(40100003)(77156002)(42186005)(122386002)(81816999)(46102003)(66066001)(50466002)(81686999)(76176999)(23756003)(50986999)(62236002)(61296003)(44716002)(33646002)(87976001)(44736004)(86362001)(19580405001)(50226001)(19580395003)(62966003)(47776003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2015 18:12:23.2007 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB057 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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: Tue, 27 Jan 2015 18:14:39 -0000 I think that there are still some glitches (and I have yet to finish reading it). The names used for the four protocols are not consistent within the document. Following RFC3414, I think that including Auth is correct. Updates to this registry requires a Standards Track document which this is not. MIB Module copyright is 2004 Does this document update RFC3414? It adds to the registry that that RFC created which some ADs say is NOT an update, some ADs say it IS an update; I think that we need guidance here (the update by RFC5590 of RFC3414 is a whole different ball game). Tom Petch ----- Original Message ----- From: "Warren Kumari" To: "Johannes Merkle" Cc: ; "Scott Bradner" Sent: Friday, January 16, 2015 9:21 P > Yup, please revise the document to address David's comment. > > There was a fair bit of discussion around this document before it was > adopted, and so it did get a fair bit of review then, but some more > would be even better... We could get that at LC, but getting that > before WGLC would be nicer -- so, can some folk please volunteer to > review? > > If we don't get any volunteers in the next week or two we'll force the > issue by going to LC... so, y'all can read it now, or you can read it > later. Now would be better :-) > > W > > > > On Thu, Jan 15, 2015 at 5:19 AM, Johannes Merkle > wrote: > > Warren, Scott, > > > > just one comment was received on the new draft (from David). Shall I revise the document accordingly and resubmit so > > that we can go for LC? > > > > Johannes > > > > > > internet-drafts@ietf.org schrieb am 12.12.2014 um 23:30: > >> > >> 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 : HMAC-SHA-2 Authentication Protocols in USM for SNMP > >> Authors : Johannes Merkle > >> Manfred Lochter > >> Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt > >> Pages : 13 > >> Date : 2014-12-12 > >> > >> Abstract: > >> This memo specifies new HMAC-SHA-2 authentication protocols for the > >> User-based Security Model (USM) for SNMPv3 defined in RFC 3414. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-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/ > >> > >> _______________________________________________ > >> 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 Jan 27 22:35:24 2015 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 CCBAB1A0041 for ; Tue, 27 Jan 2015 22:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 4Bwjvhd0wkSK for ; Tue, 27 Jan 2015 22:35:17 -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 472CF1A0029 for ; Tue, 27 Jan 2015 22:35:17 -0800 (PST) Received: from mb-aye.local ([IPv6:2601:9:7681:2d01:5d:b069:dde3:ac78]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t0S6ZDa4096006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Jan 2015 06:35:14 GMT (envelope-from joelja@bogus.com) Message-ID: <54C88320.8020705@bogus.com> Date: Tue, 27 Jan 2015 22:35:12 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Warren Kumari , Ted Lemon References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> <1CDD41DA-25A7-40D4-B1A7-EB78618E5DEE@nominum.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HAblCb4748L35AVSwGGW5qKiAQ0h6tJ2U" Archived-At: Cc: Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 28 Jan 2015 06:35:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HAblCb4748L35AVSwGGW5qKiAQ0h6tJ2U Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/27/15 9:39 AM, Warren Kumari wrote: > On Tue, Jan 27, 2015 at 11:31 AM, Ted Lemon wro= te: >> On Jan 27, 2015, at 11:20 AM, Warren Kumari wrote:= >>> I personally like DHCPv4 and DHCPv6, but there seems to be some >>> religion around this stuff :-) >>> Supporting multiple option for v6 means need to provide guidance on >>> what to do when you get *different* answers in DHCPv6 and IPv6 RA. I >>> had text in -02 covering this, I can easily put it back. >>> >>> The whole DHCPv6 vs RA topic is, um, interesting... there appear to b= e >>> some quite strong opinions around this :-) >>> I'll spin another version with both DHCPv6 and RA, and guidance on >>> what to do if you get both. This will no-doubt annoy some folk, but I= >>> can leave the consensus call to Joel :-) >> >> The problem with RA as opposed to DHCPv6 is that we've seen that uptak= e of RA options is slow compared to uptake of DHCPv6 options. But we ca= n't _just_ do DHCPv6, because as you say there is some religion about DHC= Pv6, and so certain companies are slow to implement DHCPv6 client feature= s, if at all. >=20 > Yup. I've been in the middle of some of these discussions :-) > I've put back the DHCPv6, and made it clear that there are 2 DHCP > options (v4 and v6) >=20 >=20 >> I think the right answer in the case where one sends it and the other = doesn't is to assume that whatever _was_ sent is definitive, since we can= 't assume that the source of the RA and the source of the DHCP service wi= ll necessarily be updated at the same time. >=20 > Actually, when I ended up doing was saying that devices should prefer > the URI in DHCPv4, then DHCPv6, then RA. > This gets around the problem of what to do if the CP *does* send > multiple URIs (e.g to support clients that only do DHCPv6 or RA) and > they are different. it's also plausible that the process of obtaining the information is a bit of a race between the two protocols, so you should be ok with the client starting with whichever finishes first. likewise the poosibly unfortunate case where both protocols are present but which you only recived a hint from one. > W >=20 >=20 --HAblCb4748L35AVSwGGW5qKiAQ0h6tJ2U 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTIgyEACgkQ8AA1q7Z/VrJ/IwCcDzxetIF5976s05z+WeUeUU9g zzMAn2i5fVj1KFwMFLjRDg4I/Z1oaN6f =ZhX3 -----END PGP SIGNATURE----- --HAblCb4748L35AVSwGGW5qKiAQ0h6tJ2U-- From nobody Wed Jan 28 10:43:17 2015 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 717121A19FE for ; Wed, 28 Jan 2015 10:43:16 -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 htiIdEyL0opT for ; Wed, 28 Jan 2015 10:43:14 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8867C1A1A2C for ; Wed, 28 Jan 2015 10:43:13 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.65.19; Wed, 28 Jan 2015 18:41:07 +0000 Message-ID: <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari , Johannes Merkle References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> Date: Wed, 28 Jan 2015 18:39:30 +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: [81.151.167.59] X-ClientProxiedBy: DB3PR05CA0030.eurprd05.prod.outlook.com (25.160.41.158) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) Authentication-Results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:AMSPR07MB051; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB051; X-Forefront-PRVS: 047001DADA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377424004)(24454002)(377454003)(84392001)(19580395003)(19580405001)(14496001)(122386002)(40100003)(77156002)(62966003)(86362001)(87976001)(42186005)(93886004)(61296003)(230783001)(116806002)(81816999)(50986999)(46102003)(81686999)(76176999)(92566002)(33646002)(66066001)(62236002)(44716002)(47776003)(50466002)(23756003)(77096005)(15975445007)(44736004)(50226001)(1720100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2015 18:41:07.8078 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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: Wed, 28 Jan 2015 18:43:16 -0000 Some more stray thoughts, having now read it all (but not followed up the details of HMAC-SHA-2 - too gory). s4.2.1 step 2 uses RFC6234 in a way that I think must make it a Normative reference. RFC6234 is not Standards Track but that is ok, it is already in the list of IESG permitted downrefs (does that need calling out at IETF Last Call?) s9.1 /apply the use /apply to the use / s9.2 is it the length of the key that gives it strength or its entropy? Is abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 really stronger than !qaurk/99SS~ ? I look at RFC5310 here (although there may be something more recent and better). s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I think that s9.4 should reflect that (lest it confuses, or am I confused having missed an OBJECT somewhere?) Tom Petch ----- Original Message ----- From: "t.petch" To: "Warren Kumari" ; "Johannes Merkle" Cc: ; "Scott Bradner" Sent: Tuesday, January 27, 2015 6:09 PM > I think that there are still some glitches (and I have yet to finish > reading it). > > The names used for the four protocols are not consistent within the > document. Following RFC3414, I think that including Auth is correct. > > Updates to this registry requires a Standards Track document which this > is not. > > MIB Module copyright is 2004 > > Does this document update RFC3414? It adds to the registry that that > RFC created which some ADs say is NOT an update, some ADs say it IS an > update; I think that we need guidance here (the update by RFC5590 of > RFC3414 is a whole different ball game). > > Tom Petch > > ----- Original Message ----- > From: "Warren Kumari" > To: "Johannes Merkle" > Cc: ; "Scott Bradner" > Sent: Friday, January 16, 2015 9:21 P > > > > Yup, please revise the document to address David's comment. > > > > There was a fair bit of discussion around this document before it was > > adopted, and so it did get a fair bit of review then, but some more > > would be even better... We could get that at LC, but getting that > > before WGLC would be nicer -- so, can some folk please volunteer to > > review? > > > > If we don't get any volunteers in the next week or two we'll force the > > issue by going to LC... so, y'all can read it now, or you can read it > > later. Now would be better :-) > > > > W > > > > > > > > On Thu, Jan 15, 2015 at 5:19 AM, Johannes Merkle > > wrote: > > > Warren, Scott, > > > > > > just one comment was received on the new draft (from David). Shall I > revise the document accordingly and resubmit so > > > that we can go for LC? > > > > > > Johannes > > > > > > > > > internet-drafts@ietf.org schrieb am 12.12.2014 um 23:30: > > >> > > >> 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 : HMAC-SHA-2 Authentication Protocols in > USM for SNMP > > >> Authors : Johannes Merkle > > >> Manfred Lochter > > >> Filename : > draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt > > >> Pages : 13 > > >> Date : 2014-12-12 > > >> > > >> Abstract: > > >> This memo specifies new HMAC-SHA-2 authentication protocols for > the > > >> User-based Security Model (USM) for SNMPv3 defined in RFC 3414. > > >> > > >> > > >> The IETF datatracker status page for this draft is: > > >> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > >> > > >> There's also a htmlized version available at: > > >> http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-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/ > > >> > > >> _______________________________________________ > > >> 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 > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Jan 28 11:02:20 2015 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 334F41A0027 for ; Wed, 28 Jan 2015 11:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 GYIM0zc4Gt5u for ; Wed, 28 Jan 2015 11:02:17 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BF01A1AB1 for ; Wed, 28 Jan 2015 11:02:16 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so22641977wes.10 for ; Wed, 28 Jan 2015 11:02:15 -0800 (PST) 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=xdVr56VKwN6VoTE+Cgm56/Fc+97MI7JWie0pyBW0w74=; b=g3uOdZGcTbWo5LnHAtdjf1hzwDjgSZf5rWC3lwQtFzDi4mZOyx5q3TVDvZc/dQGjjs lyBpkBqAWrXNI37nSjlllX6mriXgpGXd05gnhIbEJsX7Yo6Znz1alj5KTyeOS9vpqUEk rU0MKAaeeMGRF8YF62hRSo+oknphkgIydRBardrNpivjOdHqHuS60etlmptH2NLHlDwS dP4kKKLxXoQINUpW+wB3deWj5JO/p43z/7eyoXD9XCLWpeNfLzTHH8GhA9iG2DD37sgq MzkC8J52joq4eoDwtleeWE25g4NOrBfSr52+fQmhH+urK2u9HgoF45+qPhkpfDBrn+1d BQBQ== X-Gm-Message-State: ALoCoQmLr0/ho58TVS1ubz93FYn2xughMwRVuuWQOQn4h0YOvhE8f4WbPTytl7paP5jdSgj+Elna MIME-Version: 1.0 X-Received: by 10.180.21.162 with SMTP id w2mr9895191wie.42.1422471735719; Wed, 28 Jan 2015 11:02:15 -0800 (PST) Received: by 10.194.78.77 with HTTP; Wed, 28 Jan 2015 11:02:15 -0800 (PST) In-Reply-To: <54C88320.8020705@bogus.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> <1CDD41DA-25A7-40D4-B1A7-EB78618E5DEE@nominum.com> <54C88320.8020705@bogus.com> Date: Wed, 28 Jan 2015 14:02:15 -0500 Message-ID: From: Warren Kumari To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ole Troan , Ted Lemon , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 28 Jan 2015 19:02:19 -0000 On Wed, Jan 28, 2015 at 1:35 AM, joel jaeggli wrote: > On 1/27/15 9:39 AM, Warren Kumari wrote: >> On Tue, Jan 27, 2015 at 11:31 AM, Ted Lemon wrot= e: >>> On Jan 27, 2015, at 11:20 AM, Warren Kumari wrote: >>>> I personally like DHCPv4 and DHCPv6, but there seems to be some >>>> religion around this stuff :-) >>>> Supporting multiple option for v6 means need to provide guidance on >>>> what to do when you get *different* answers in DHCPv6 and IPv6 RA. I >>>> had text in -02 covering this, I can easily put it back. >>>> >>>> The whole DHCPv6 vs RA topic is, um, interesting... there appear to be >>>> some quite strong opinions around this :-) >>>> I'll spin another version with both DHCPv6 and RA, and guidance on >>>> what to do if you get both. This will no-doubt annoy some folk, but I >>>> can leave the consensus call to Joel :-) >>> >>> The problem with RA as opposed to DHCPv6 is that we've seen that uptake= of RA options is slow compared to uptake of DHCPv6 options. But we can't= _just_ do DHCPv6, because as you say there is some religion about DHCPv6, = and so certain companies are slow to implement DHCPv6 client features, if a= t all. >> >> Yup. I've been in the middle of some of these discussions :-) >> I've put back the DHCPv6, and made it clear that there are 2 DHCP >> options (v4 and v6) >> >> >>> I think the right answer in the case where one sends it and the other d= oesn't is to assume that whatever _was_ sent is definitive, since we can't = assume that the source of the RA and the source of the DHCP service will ne= cessarily be updated at the same time. >> >> Actually, when I ended up doing was saying that devices should prefer >> the URI in DHCPv4, then DHCPv6, then RA. >> This gets around the problem of what to do if the CP *does* send >> multiple URIs (e.g to support clients that only do DHCPv6 or RA) and >> they are different. > > it's also plausible that the process of obtaining the information is a > bit of a race between the two protocols, so you should be ok with the > client starting with whichever finishes first. Yup. In the doc I have: [Ed note: This ordering is somewhat arbitrary - this order was chosen because this is the order I expect the code to be implemented by OS vendors, and I'd like the same behavior from newer and older devices to make troubleshooting easier.] The reason I prefer this to "whatever finishes first" is that it is a bit more deterministic and so easier to troubleshoot. I also don't clients to connect to http:// one day, after an OS upgrade, suddenly start connecting to http://. In theory (and if the CP operators is sane) the =3D=3D , but... I don't think that the actual ordering is as important as the fact that there *is* a suggested ordering. If you'd prefer the "whatever comes first" I'm happy to make this change - it's all just bits... > likewise the poosibly > unfortunate case where both protocols are present but which you only > recived a hint from one. Well, the way the document is written, either you get the option or you don't. There is nothing wrong with having DHCPv4, DHCPv6 and RA, and only getting the option in any subset of these, you just follow the preference rule to decide which to use (if you get it from multiple and they differ). Anyway, this document has now gone through 9 revisions and it's been more than a year. I think we've wrung all of the review out of OpsAWG / DHC that we are likely to get - what happens next? W > >> W >> >> > > --=20 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 From nobody Wed Jan 28 11:08:06 2015 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 D6B861A1A22 for ; Wed, 28 Jan 2015 11:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 eyKlhRNqNX6X for ; Wed, 28 Jan 2015 11:08:00 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 D75BB1A00F3 for ; Wed, 28 Jan 2015 11:07:59 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id AFDE3DA00CD for ; Wed, 28 Jan 2015 19:07:59 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 69DFE53E07A; Wed, 28 Jan 2015 11:07:59 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 28 Jan 2015 11:07:59 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Wed, 28 Jan 2015 14:07:49 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6BD93E37-BAE3-4D83-97BC-248DEFC0924D@nominum.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> <1CDD41DA-25A7-40D4-B1A7-EB78618E5DEE@nominum.com> <54C88320.8020705@bogus.com> To: Warren Kumari X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 28 Jan 2015 19:08:02 -0000 On Jan 28, 2015, at 2:02 PM, Warren Kumari wrote: > The reason I prefer this to "whatever finishes first" is that it is a > bit more deterministic and so easier to troubleshoot. I also don't > clients to connect to http:// one day, after an OS > upgrade, suddenly start connecting to http://. In theory > (and if the CP operators is sane) the =3D=3D > , but... In practice it's always going to be RA-first, because DHCPv6 doesn't = start until after RA. And it's likely going to be non-deterministic = whether it's RA-first or DHCPv4-first, rather than being a function of = some implementation detail in the O.S. So I think Joel is right that there's no benefit to insisting on an = ordering. I think you should just say that the ordering is = indeterminate, and if different mechanisms give non-equivalent answers, = this is likely to cause operational problems in practice. From nobody Wed Jan 28 14:46:55 2015 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 7EE381A1AD3 for ; Wed, 28 Jan 2015 14:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 SrWrSlE2FADB for ; Wed, 28 Jan 2015 14:46:50 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 8B5D41A19F6 for ; Wed, 28 Jan 2015 14:46:50 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so1013656wib.1 for ; Wed, 28 Jan 2015 14:46:49 -0800 (PST) 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=2aNrJ8H3813zHjXJRy7dJAKZxi/OC+s72AmN6xu0J2k=; b=JUOVSOktyiNoWpxa6BzNj0Om0TG/KkBsZejoeoUrOjndZQF3/cK9t+JISFg4R/NA6s NYTbtESX4nkgaWJIORa37L7wVRDdqVzpunnjQuPeYHiOXiVv0uujkKF10oGzomWU3wIf PcBaKdgq9DicVhwU0UkhKsGOH5rJZSMGnJATxXb3FdL6c/4yiwIrHdlmTJMUlXHuXX6E 6VAti/cWKHTXHR+a2QqYhsaICMb0gxn+7cBH0WccYlii/IRgAP1g2khAB2DW4wHHO30k vR7TG4qD5D3qlIX2Kf1/Y9G+L4vsowV3vwwdK8kkFrw7rb9c/P0HfvkJWJrdRQYLtXrD 9nlg== X-Gm-Message-State: ALoCoQkkuFcTtGOlgaXjyFBrRIaz4of8PnDEWpkacmavovU6+mNvwui1+hgVjxqYQyOp0JSQH6GC MIME-Version: 1.0 X-Received: by 10.180.73.112 with SMTP id k16mr11578112wiv.42.1422485209253; Wed, 28 Jan 2015 14:46:49 -0800 (PST) Received: by 10.194.78.77 with HTTP; Wed, 28 Jan 2015 14:46:49 -0800 (PST) In-Reply-To: <6BD93E37-BAE3-4D83-97BC-248DEFC0924D@nominum.com> References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> <1CDD41DA-25A7-40D4-B1A7-EB78618E5DEE@nominum.com> <54C88320.8020705@bogus.com> <6BD93E37-BAE3-4D83-97BC-248DEFC0924D@nominum.com> Date: Wed, 28 Jan 2015 17:46:49 -0500 Message-ID: From: Warren Kumari To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 28 Jan 2015 22:46:52 -0000 On Wed, Jan 28, 2015 at 2:07 PM, Ted Lemon wrote: > On Jan 28, 2015, at 2:02 PM, Warren Kumari wrote: >> The reason I prefer this to "whatever finishes first" is that it is a >> bit more deterministic and so easier to troubleshoot. I also don't >> clients to connect to http:// one day, after an OS >> upgrade, suddenly start connecting to http://. In theory >> (and if the CP operators is sane) the == >> , but... > > In practice it's always going to be RA-first, because DHCPv6 doesn't start until after RA. Oh. Huh. Yeah, that didn't occur to me :-P > And it's likely going to be non-deterministic whether it's RA-first or DHCPv4-first, rather than being a function of some implementation detail in the O.S. > > So I think Joel is right that there's no benefit to insisting on an ordering. I wasn't really *insisting*, more of a general statement ("If the device gets different URIs (for example, via DHCPv6 and IPv6 RA) it should try them in the following order: DHCPv4, DHCPv6, RA."), but happy to remove that. > I think you should just say that the ordering is indeterminate, and if different mechanisms give non-equivalent answers, this is likely to cause operational problems in practice. Done! "In order to support multiple "classes" of clients (e.g: IPv4 only, IPv6 only with DHCPv6, IPv6 only with RA) the captive portal can provide the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, IPv6 RA). The captive portal operator should ensure that the URIs handed out are equivalent to reduce the chance of operational problems." Version -10 posted. This is a nice, round number... W > -- 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 From nobody Wed Jan 28 15:40:53 2015 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 AEB1E1A8546 for ; Wed, 28 Jan 2015 15:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 llKu0g6hbwE7 for ; Wed, 28 Jan 2015 15:40:50 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24A91A8545 for ; Wed, 28 Jan 2015 15:40:49 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id h11so17152003wiw.5 for ; Wed, 28 Jan 2015 15:40:48 -0800 (PST) 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:content-type; bh=Si/g2ipvZiQLrCaad2FT1+3FMhHUFU7cwueS6Z+NM5Y=; b=g3uOqUCyrLt0dc64zyyHfS3afdVC29jBMs0/YeS2l1HjhJWRPtaVxfj0FJTxk7+JSC bdfNL0l2wH62N3MBGCzSXT/ypBeXOAn2l4RImw2iZr5NUhI2SacHL4eRTz6N9zJfh6jj wSGhNdeLK3NFoyPa2cDETjQIQNVnKGOjSHhhwDluJr9Pa7eUDFkHxj3m4L6KBMHHnw7y IkQYXp0ISvnO/DFF9ulCAcoJn/ws/ALSWk0DVZEt4tX5xLjS6jeEUphZk4ovPgXxjrMJ uRJYRv4n9JveiosMnKA9uI0Nlhf2gSsafaKWKGBxGtz93BYr98T+PAOP8R9GM3K5jIWS NthQ== X-Gm-Message-State: ALoCoQm5F7WqtKvPDENhFFOG504VRlFiJSyrPItXRa0YZHCz+cTiluUGx1xilkv+2EuMgO39GaVB MIME-Version: 1.0 X-Received: by 10.194.8.2 with SMTP id n2mr12431716wja.46.1422488448507; Wed, 28 Jan 2015 15:40:48 -0800 (PST) Received: by 10.194.78.77 with HTTP; Wed, 28 Jan 2015 15:40:48 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Jan 2015 18:40:48 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 28 Jan 2015 23:40:51 -0000 On Fri, Jan 9, 2015 at 12:15 PM, Warren Kumari wrote: > Dear OpsAWG WG, > > The authors of draft-ietf-opsawg-vmm-mib have indicated that they > believe that the document is ready, and have asked for Working Group > Last Call. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This WGLC ends Fri 23-Jan-2015. > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-vmm-mib? If so, has this IPR been disclosed in > compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 > for more details.) > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) The WGLC has concluded with no feedback or comments, and so we have to conclude that the WG is no longer interested in this work. Apologies to the authors, W > > -- > 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 -- 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 From nobody Wed Jan 28 15:54:24 2015 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 455C01A87D1 for ; Wed, 28 Jan 2015 15:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] 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 ssqwt5b28cEm for ; Wed, 28 Jan 2015 15:54:21 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id C08CF1A854D for ; Wed, 28 Jan 2015 15:54:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 342A61164577; Wed, 28 Jan 2015 18:54:21 -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 3LmwqZtMysvF; Wed, 28 Jan 2015 18:54:20 -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 5D79F1164568; Wed, 28 Jan 2015 18:54:20 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Scott O. Bradner" In-Reply-To: Date: Wed, 28 Jan 2015 18:54:19 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 28 Jan 2015 23:54:23 -0000 which is too bad since I think the topic is a useful one but, as chairs, we are supposed to do things based on WG consensus and if no one speaks up we have no way to know if there is consensus one way or another Scott > On Jan 28, 2015, at 6:40 PM, Warren Kumari wrote: > > On Fri, Jan 9, 2015 at 12:15 PM, Warren Kumari wrote: >> Dear OpsAWG WG, >> >> The authors of draft-ietf-opsawg-vmm-mib have indicated that they >> believe that the document is ready, and have asked for Working Group >> Last Call. >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ >> >> Please review this draft to see if you think it is ready for >> publication and send comments to the list, clearly stating your view. >> >> This WGLC ends Fri 23-Jan-2015. >> >> In addition, to satisfy RFC 6702 ("Promoting Compliance with >> Intellectual Property Rights (IPR)"): >> Are you personally aware of any IPR that applies to >> draft-ietf-opsawg-vmm-mib? If so, has this IPR been disclosed in >> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 >> for more details.) >> >> Thanks, >> Warren Kumari >> (as OpsAWG WG co-chair) > > The WGLC has concluded with no feedback or comments, and so we have to > conclude that the WG is no longer interested in this work. > > Apologies to the authors, > W > >> >> -- >> 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 > > > > -- > 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 Wed Jan 28 15:58:59 2015 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 BFEA91A854D for ; Wed, 28 Jan 2015 15:58: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, 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 jDCIakgjIEmX for ; Wed, 28 Jan 2015 15:58:18 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0664.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:664]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92551A87E6 for ; Wed, 28 Jan 2015 15:58:17 -0800 (PST) Received: from CY1PR0701MB1082.namprd07.prod.outlook.com (25.160.145.154) by CY1PR0701MB1081.namprd07.prod.outlook.com (25.160.145.153) with Microsoft SMTP Server (TLS) id 15.1.65.19; Wed, 28 Jan 2015 23:57:55 +0000 Received: from CY1PR0701MB1082.namprd07.prod.outlook.com ([25.160.145.154]) by CY1PR0701MB1082.namprd07.prod.outlook.com ([25.160.145.154]) with mapi id 15.01.0065.013; Wed, 28 Jan 2015 23:57:54 +0000 From: "Bradner, Scott" To: Warren Kumari Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib Thread-Index: AQHQO1Y7PVWL1x1rXkmU3W4av1KsaA== Date: Wed, 28 Jan 2015 23:57:54 +0000 Message-ID: <927404EE-A73D-4429-94FC-9DDACA994E40@harvard.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.166.5.69] authentication-results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=harvard.edu; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CY1PR0701MB1081; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1081; x-forefront-prvs: 047001DADA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51704005)(164054003)(377454003)(90282001)(230783001)(87936001)(83716003)(33656002)(99286002)(106116001)(15975445007)(102836002)(89122001)(110136001)(2900100001)(82746002)(86362001)(2950100001)(19580405001)(2656002)(88552001)(66066001)(92566002)(46102003)(62966003)(77156002)(36756003)(76176999)(75432002)(50986999)(40100003)(19580395003)(54356999)(122556002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1081; H:CY1PR0701MB1082.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <7E2E059BED342E41AD8CB6130F325846@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2015 23:57:54.5274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1081 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib@tools.ietf.org" , "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 28 Jan 2015 23:58:22 -0000 X-List-Received-Date: Wed, 28 Jan 2015 23:58:22 -0000 which is too bad since I think the topic is a useful one but, as chairs, we are supposed to do things based on WG consensus=20 and if no one speaks up we have no way to know if there is consensus one way or another=20 Scott > On Jan 28, 2015, at 6:40 PM, Warren Kumari wrote: >=20 > On Fri, Jan 9, 2015 at 12:15 PM, Warren Kumari wrote: >> Dear OpsAWG WG, >>=20 >> The authors of draft-ietf-opsawg-vmm-mib have indicated that they >> believe that the document is ready, and have asked for Working Group >> Last Call. >>=20 >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ >>=20 >> Please review this draft to see if you think it is ready for >> publication and send comments to the list, clearly stating your view. >>=20 >> This WGLC ends Fri 23-Jan-2015. >>=20 >> In addition, to satisfy RFC 6702 ("Promoting Compliance with >> Intellectual Property Rights (IPR)"): >> Are you personally aware of any IPR that applies to >> draft-ietf-opsawg-vmm-mib? If so, has this IPR been disclosed in >> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 >> for more details.) >>=20 >> Thanks, >> Warren Kumari >> (as OpsAWG WG co-chair) >=20 > The WGLC has concluded with no feedback or comments, and so we have to > conclude that the WG is no longer interested in this work. >=20 > Apologies to the authors, > W >=20 >>=20 >> -- >> 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 >=20 >=20 >=20 > --=20 > 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 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Jan 28 15:59:01 2015 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 ABC891A854D for ; Wed, 28 Jan 2015 15:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 dkUCMfUeTKDQ for ; Wed, 28 Jan 2015 15:58:19 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7099F1A87E3 for ; Wed, 28 Jan 2015 15:58:19 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bs8so8899202wib.5 for ; Wed, 28 Jan 2015 15:58:18 -0800 (PST) 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=ubJ6r0ET5OcSqCD/gqX+k41AIAW6UGQEQ/nbuTqtwnk=; b=mg1oFRSBjtF5rrPuXg9hHiU+/GNI5McpYoTchmXFGO2546V+LQjb8Nw8CRYvCLEolD mPKG3vn6vwOGU0RyzuDcc/dHSYPYRLCCPfPHSf4uvNQsma91BnGcWkfnh1n++sV7IA67 OmBuPHqInBlQjs4ipYw9ZjVs84xv+k1MNA+sEjAtx5vkA81e3DlVJ1Tz8UfAmna+OZLg 0c/nDE7147WGiYrhg25Cu0hEZHPtjrQ9hCoQ31/NxIM6XW6HJhu0WXQjmW7Ra2+Xv+rh k7Stzxw9d4oGMU8EbmD8XvzsMP9Hacs6JInVJAnHJRGtF/lk8WWomi+9qVXSQhsAAzJE GH2Q== X-Gm-Message-State: ALoCoQnM07YYd0szasD5uNZgwmAQs3BUoNMTKjGf1He8nIwtgbfEiitJDoGlNpVzSFNqhHQj2DYZ MIME-Version: 1.0 X-Received: by 10.180.12.166 with SMTP id z6mr1074532wib.65.1422489498141; Wed, 28 Jan 2015 15:58:18 -0800 (PST) Received: by 10.194.78.77 with HTTP; Wed, 28 Jan 2015 15:58:18 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Jan 2015 18:58:18 -0500 Message-ID: From: Warren Kumari To: "Scott O. Bradner" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 28 Jan 2015 23:58:28 -0000 On Wed, Jan 28, 2015 at 6:54 PM, Scott O. Bradner wrote: > which is too bad since I think the topic is a useful one Yup, as do I... If there is a sudden upwelling of support and interest, we can definitely discuss rerunning the WGLC. > > but, as chairs, we are supposed to do things based on WG consensus > and if no one speaks up we have no way to know if there is consensus > one way or another Yup. The consensus on some of the documents we have progressed has been thiner that we'd like. We've been getting consensus, but from a much smaller group than ideal. Remember folk - if you might want the working group to review one of *your* documents in the future, you are going to have to review (and provide feedback!) on other peoples documents now... W > > Scott > >> On Jan 28, 2015, at 6:40 PM, Warren Kumari wrote: >> >> On Fri, Jan 9, 2015 at 12:15 PM, Warren Kumari wrote: >>> Dear OpsAWG WG, >>> >>> The authors of draft-ietf-opsawg-vmm-mib have indicated that they >>> believe that the document is ready, and have asked for Working Group >>> Last Call. >>> >>> The draft is available here: >>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ >>> >>> Please review this draft to see if you think it is ready for >>> publication and send comments to the list, clearly stating your view. >>> >>> This WGLC ends Fri 23-Jan-2015. >>> >>> In addition, to satisfy RFC 6702 ("Promoting Compliance with >>> Intellectual Property Rights (IPR)"): >>> Are you personally aware of any IPR that applies to >>> draft-ietf-opsawg-vmm-mib? If so, has this IPR been disclosed in >>> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 >>> for more details.) >>> >>> Thanks, >>> Warren Kumari >>> (as OpsAWG WG co-chair) >> >> The WGLC has concluded with no feedback or comments, and so we have to >> conclude that the WG is no longer interested in this work. >> >> Apologies to the authors, >> W >> >>> >>> -- >>> 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 >> >> >> >> -- >> 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 > -- 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 From nobody Wed Jan 28 16:03:50 2015 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 8805F1A8833 for ; Wed, 28 Jan 2015 16:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JFbfr2af1EdV for ; Wed, 28 Jan 2015 16:03:47 -0800 (PST) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503EE1A8838 for ; Wed, 28 Jan 2015 16:03:43 -0800 (PST) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 2E9AC29F29; Wed, 28 Jan 2015 16:03:43 -0800 (PST) Received: from EX13-CAS-010.vmware.com (EX13-CAS-010.vmware.com [10.113.191.62]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 2A065B0B95; Wed, 28 Jan 2015 16:03:43 -0800 (PST) Received: from EX13-MBX-020.vmware.com (10.113.191.40) by EX13-MBX-027.vmware.com (10.113.191.47) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 28 Jan 2015 16:03:42 -0800 Received: from EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7]) by EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7%15]) with mapi id 15.00.0913.011; Wed, 28 Jan 2015 16:03:30 -0800 From: Michael MacFaden To: "Scott O. Bradner" Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib Thread-Index: AQHQLC/bGVcfeNKm2UG77KA8EpD6FpzW1WsAgAADx4CAAAKQgA== Date: Thu, 29 Jan 2015 00:03:30 +0000 Message-ID: <5913A524-6B63-41CF-9F26-5F6C740EEDEF@vmware.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.113.160.246] Content-Type: multipart/alternative; boundary="_000_5913A5246B6341CF9F265F6C740EEDEFvmwarecom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib@tools.ietf.org" , "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 00:03:48 -0000 --_000_5913A5246B6341CF9F265F6C740EEDEFvmwarecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Exactly how many folks need to speak up? We did have operator input on this work. We can ping them to to send email to the list... Mike On Jan 28, 2015, at 3:54 PM, Scott O. Bradner > wrote: which is too bad since I think the topic is a useful one but, as chairs, we are supposed to do things based on WG consensus and if no one speaks up we have no way to know if there is consensus one way or another --_000_5913A5246B6341CF9F265F6C740EEDEFvmwarecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4193ED338122F84693813C2C0E9D1973@pa-exch1.vmware.com> Content-Transfer-Encoding: quoted-printable
Exactly  how many folks need to speak up?

We did have operator input on this work. 
We can ping them to to send email 
to the list...

Mike


On Jan 28, 2015, at 3:54 PM, Scott O. Bradner <sob@sobco.com> wrote:

which is too bad since I think the topic is a useful one

but, as chairs, we are supposed to do things based on WG consensus 
and if no one speaks up we have no way to know if there is consensus one way or another 

--_000_5913A5246B6341CF9F265F6C740EEDEFvmwarecom_-- From nobody Wed Jan 28 17:53:47 2015 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 AF0921A8ABF for ; Wed, 28 Jan 2015 17:53:45 -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 XzRWnqfFGkuN for ; Wed, 28 Jan 2015 17:53:44 -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 A78751A8ABD for ; Wed, 28 Jan 2015 17:53:43 -0800 (PST) Received: from CY1PR0701MB1082.namprd07.prod.outlook.com (25.160.145.154) by CY1PR0701MB1084.namprd07.prod.outlook.com (25.160.145.156) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 01:53:20 +0000 Received: from CY1PR0701MB1082.namprd07.prod.outlook.com ([25.160.145.154]) by CY1PR0701MB1082.namprd07.prod.outlook.com ([25.160.145.154]) with mapi id 15.01.0065.013; Thu, 29 Jan 2015 01:53:19 +0000 From: "Bradner, Scott" To: Michael MacFaden Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib Thread-Index: AQHQO2ZbPVWL1x1rXkmU3W4av1KsaA== Date: Thu, 29 Jan 2015 01:53:19 +0000 Message-ID: <031AA51A-F341-4BEB-926D-F5AE43C22CC2@harvard.edu> References: <5913A524-6B63-41CF-9F26-5F6C740EEDEF@vmware.com> In-Reply-To: <5913A524-6B63-41CF-9F26-5F6C740EEDEF@vmware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.248.127.162] authentication-results: vmware.com; dkim=none (message not signed) header.d=none;vmware.com; dmarc=none action=none header.from=harvard.edu; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CY1PR0701MB1084; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1084; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51704005)(377454003)(93886004)(2950100001)(102836002)(106116001)(89122001)(92566002)(90282001)(110136001)(66066001)(46102003)(75432002)(88552001)(2900100001)(15975445007)(36756003)(99286002)(230783001)(82746002)(19580405001)(83716003)(19580395003)(87936001)(77156002)(62966003)(40100003)(54356999)(33656002)(122556002)(2656002)(76176999)(86362001)(50986999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1084; H:CY1PR0701MB1082.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <2B20061C5260584186FD025AF3496DB8@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2015 01:53:19.5103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1084 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib@tools.ietf.org" , "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 01:53:45 -0000 no exact number but zero is not enough any intelligent input would be helpful Scott > On Jan 28, 2015, at 7:03 PM, Michael MacFaden wrote: >=20 > Exactly how many folks need to speak up? >=20 > We did have operator input on this work.=20 > We can ping them to to send email=20 > to the list... >=20 > Mike >=20 >=20 > On Jan 28, 2015, at 3:54 PM, Scott O. Bradner wrote: >=20 >> which is too bad since I think the topic is a useful one >>=20 >> but, as chairs, we are supposed to do things based on WG consensus=20 >> and if no one speaks up we have no way to know if there is consensus >> one way or another=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Jan 28 21:25:51 2015 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 578361A1BA7 for ; Wed, 28 Jan 2015 21:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.587 X-Spam-Level: * X-Spam-Status: No, score=1.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.793, 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 mIrEpKrBZwvk for ; Wed, 28 Jan 2015 21:25:44 -0800 (PST) Received: from sh.wide.ad.jp (unknown [IPv6:2001:200:0:180c::6]) by ietfa.amsl.com (Postfix) with ESMTP id 26FCC1A8749 for ; Wed, 28 Jan 2015 21:25:43 -0800 (PST) Received: from [IPv6:2001:df0:6800:cafe:6516:921c:1ac0:4b6e] ([IPv6:2001:df0:6800:cafe:6516:921c:1ac0:4b6e]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.21) with ESMTP id t0T5Peh5026902 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO); Thu, 29 Jan 2015 14:25:41 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Keiichi SHIMA In-Reply-To: Date: Thu, 29 Jan 2015 14:24:42 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4C8A2293-A317-4BC4-A61A-57D570905B55@wide.ad.jp> References: To: Warren Kumari , "Scott O. Bradner" , "opsawg@ietf.org" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 05:25:46 -0000 # resending, since my mail was bounced because of the sender address Hello all, I didn=E2=80=99t send any response to the last call of the vmm-mib since = I am one of the authors of the draft. But let me say one thing. I remember not a few people joined the discussion of this draft both on = the mailing list and on the mic. They gave us many useful comments, = questions, objections, and sometimes good revised text for making the = draft better. We incorporated those responses and make the final draft = which was shown during the last call. So, to those who joined the discussion before, please show your supports = of the draft, if you think the draft is valuable for the future = hypervisor operation and management systems. Thanks, --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc > On 2015Jan 29,, at 08:58, Warren Kumari wrote: >=20 > On Wed, Jan 28, 2015 at 6:54 PM, Scott O. Bradner = wrote: >> which is too bad since I think the topic is a useful one >=20 > Yup, as do I... >=20 > If there is a sudden upwelling of support and interest, we can > definitely discuss rerunning the WGLC. >=20 >>=20 >> but, as chairs, we are supposed to do things based on WG consensus >> and if no one speaks up we have no way to know if there is consensus >> one way or another >=20 > Yup. The consensus on some of the documents we have progressed has > been thiner that we'd like. We've been getting consensus, but from a > much smaller group than ideal. >=20 > Remember folk - if you might want the working group to review one of > *your* documents in the future, you are going to have to review (and > provide feedback!) on other peoples documents now... >=20 > W >=20 >=20 >=20 >>=20 >> Scott >>=20 >>> On Jan 28, 2015, at 6:40 PM, Warren Kumari = wrote: >>>=20 >>> On Fri, Jan 9, 2015 at 12:15 PM, Warren Kumari = wrote: >>>> Dear OpsAWG WG, >>>>=20 >>>> The authors of draft-ietf-opsawg-vmm-mib have indicated that they >>>> believe that the document is ready, and have asked for Working = Group >>>> Last Call. >>>>=20 >>>> The draft is available here: >>>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ >>>>=20 >>>> Please review this draft to see if you think it is ready for >>>> publication and send comments to the list, clearly stating your = view. >>>>=20 >>>> This WGLC ends Fri 23-Jan-2015. >>>>=20 >>>> In addition, to satisfy RFC 6702 ("Promoting Compliance with >>>> Intellectual Property Rights (IPR)"): >>>> Are you personally aware of any IPR that applies to >>>> draft-ietf-opsawg-vmm-mib? If so, has this IPR been disclosed in >>>> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and = 5378 >>>> for more details.) >>>>=20 >>>> Thanks, >>>> Warren Kumari >>>> (as OpsAWG WG co-chair) >>>=20 >>> The WGLC has concluded with no feedback or comments, and so we have = to >>> conclude that the WG is no longer interested in this work. >>>=20 >>> Apologies to the authors, >>> W >>>=20 >>>>=20 >>>> -- >>>> 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 >>>=20 >>>=20 >>>=20 >>> -- >>> 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 >>>=20 >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >=20 >=20 >=20 > --=20 > 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 From nobody Thu Jan 29 00:03:35 2015 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 CCDB21A901E for ; Thu, 29 Jan 2015 00:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 Aqo1WRys-oIW for ; Thu, 29 Jan 2015 00:03:24 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA551A900B for ; Thu, 29 Jan 2015 00:03:21 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id D48F91A009F; Thu, 29 Jan 2015 09:03:09 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j4AkTxNfvN1j; Thu, 29 Jan 2015 09:03:08 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id BCDB81A009D; Thu, 29 Jan 2015 09:03:08 +0100 (CET) Received: from [172.16.40.201] (172.16.40.201) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 29 Jan 2015 09:03:18 +0100 Message-ID: <54C9E945.5010808@secunet.com> Date: Thu, 29 Jan 2015 09:03:17 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: t.petch , Warren Kumari References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> In-Reply-To: <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.40.201] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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: Thu, 29 Jan 2015 08:03:28 -0000 Tom, thanks for the thorough review. This really helps improving the document. > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a > Normative reference. RFC6234 is not Standards Track but that is ok, it > is already in the list of IESG permitted downrefs (does that need > calling out at IETF Last Call?) You are right, but the question is whether I should rather use references [RFC2104] and [SHA] here. > > s9.1 > /apply the use /apply to the use / Right. > > s9.2 > is it the length of the key that gives it strength or its entropy? Is > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 > really stronger than > !qaurk/99SS~ ? Strictly speaking, you are right, but it is common sense that cryptographic keys should have maximum entropy, i.e., they should be selected uniformly at random from bit string of that length. Consequently, virtually all cryptographic papers and text books use key the key length synonymous to its entropy. Thus, I consider this distinction as unnecessary. > > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I think > that s9.4 should reflect that (lest it confuses, or am I confused having > missed an OBJECT somewhere?) Here I definitely need help, as I have no knowledge about MIBs. Actually, I copied that section from RFC 3411. Please give advise what to write here or if this section is needed at all. > The names used for the four protocols are not consistent within the > document. Following RFC3414, I think that including Auth is correct. > oops, this escaped my attention. > Updates to this registry requires a Standards Track document which this > is not. Wright. If the chairs agree, I'll change the track. > > MIB Module copyright is 2004 opps again. Copy and paste error. > > Does this document update RFC3414? It adds to the registry that that > RFC created which some ADs say is NOT an update, some ADs say it IS an > update; I think that we need guidance here (the update by RFC5590 of > RFC3414 is a whole different ball game). I will wait for the guidance here. -- Johannes From nobody Thu Jan 29 01:13:51 2015 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 355CD1A026E for ; Thu, 29 Jan 2015 01:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 oN-he6Zl1gMV for ; Thu, 29 Jan 2015 01:13:45 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742301A0267 for ; Thu, 29 Jan 2015 01:13:45 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C5151879; Thu, 29 Jan 2015 10:13:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ei5nJvaBdI7P; Thu, 29 Jan 2015 10:13:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 29 Jan 2015 10:13:43 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7F9520036; Thu, 29 Jan 2015 10:13:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2PAxlTD0DPxV; Thu, 29 Jan 2015 10:13:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 508C020035; Thu, 29 Jan 2015 10:13:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 59DE5311B670; Thu, 29 Jan 2015 10:13:40 +0100 (CET) Date: Thu, 29 Jan 2015 10:13:40 +0100 From: Juergen Schoenwaelder To: Johannes Merkle Message-ID: <20150129091339.GA17493@elstar.local> Mail-Followup-To: Johannes Merkle , "t. petch" , Warren Kumari , opsawg@ietf.org, Scott Bradner References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C9E945.5010808@secunet.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 09:13:48 -0000 On Thu, Jan 29, 2015 at 09:03:17AM +0100, Johannes Merkle wrote: > > > > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I think > > that s9.4 should reflect that (lest it confuses, or am I confused having > > missed an OBJECT somewhere?) > > Here I definitely need help, as I have no knowledge about MIBs. Actually, I copied that section from RFC 3411. Please > give advise what to write here or if this section is needed at all. > The 'official' security considerations template for MIB modules can be found here: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security It does not really apply here since this MIB module only defines a couple of constants. Perhaps write something along these lines: The SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values for use in other MIB modules. It does not define any objects that can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by itself, have any effect on the security of the Internet. The values defined in this module are expected to be used with the usmUserTable defined in the SNMP-USER-BASED-SM-MIB [RFC3414]. The considerations in Section 11.5 of [RFC3414] should be taken into account. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jan 29 02:49:54 2015 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 0263C1A01F6 for ; Thu, 29 Jan 2015 02:49:52 -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 CCirvsH2HjNn for ; Thu, 29 Jan 2015 02:49:49 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5417F1A019B for ; Thu, 29 Jan 2015 02:49:49 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 10:49:25 +0000 Message-ID: <01f001d03bb1$0e9a7c80$4001a8c0@gateway.2wire.net> From: t.petch To: Johannes Merkle , Warren Kumari References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> Date: Thu, 29 Jan 2015 10:30:22 +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: [81.151.167.59] X-ClientProxiedBy: DB3PR05CA0031.eurprd05.prod.outlook.com (25.160.41.159) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: secunet.com; dkim=none (message not signed) header.d=none;secunet.com; dmarc=none action=none header.from=btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 0471B73328 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(51704005)(51914003)(13464003)(377454003)(1456003)(92566002)(93886004)(44736004)(76176999)(81686999)(81816999)(50226001)(47776003)(66066001)(42186005)(77096005)(50466002)(230783001)(116806002)(50986999)(33646002)(77156002)(62966003)(40100003)(122386002)(84392001)(19580405001)(14496001)(61296003)(46102003)(62236002)(44716002)(86362001)(23746002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2015 10:49:25.4450 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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: Thu, 29 Jan 2015 10:49:52 -0000 ----- Original Message ----- From: "Johannes Merkle" To: "t.petch" ; "Warren Kumari" Cc: ; "Scott Bradner" Sent: Thursday, January 29, 2015 8:03 AM > Tom, > > thanks for the thorough review. This really helps improving the document. > > > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a > > Normative reference. RFC6234 is not Standards Track but that is ok, it > > is already in the list of IESG permitted downrefs (does that need > > calling out at IETF Last Call?) > > You are right, but the question is whether I should rather use references [RFC2104] and [SHA] here. Don't know - this is the gory detail which I did not pursue - really need an implementor to say if the older references are adequate for SHA2; but as I say, a Normative reference to RFC6234 is fine if we want it > > s9.1 > > /apply the use /apply to the use / > > Right. > > > > > s9.2 > > is it the length of the key that gives it strength or its entropy? Is > > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 > > really stronger than > > !qaurk/99SS~ ? > > Strictly speaking, you are right, but it is common sense that cryptographic keys should have maximum entropy, i.e., they > should be selected uniformly at random from bit string of that length. Consequently, virtually all cryptographic papers > and text books use key the key length synonymous to its entropy. Thus, I consider this distinction as unnecessary. Yes but, consider the audience. Cryptographic material is aimed at cryptographers who know about entropy without being told, the audience of this I-D is all sorts, including MIB module specialists whose knowledge of cryptography is probably less than useless. So I think 'length' is wrong, 'entropy' is probably too technical (especially if, like me, Thermodynamics was part of your degree), RFC5310 uses 'size and quality of the key' which is probably a good compromise. > > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I think > > that s9.4 should reflect that (lest it confuses, or am I confused having > > missed an OBJECT somewhere?) > > Here I definitely need help, as I have no knowledge about MIBs. Actually, I copied that section from RFC 3411. Please > give advise what to write here or if this section is needed at all. RFC3826 is a good parallel here - it omits this paragraph entirely so I would do the same, unless Juergen, Bert or Randy say otherwise. No further comments on the points outstanding below (Standards Track I consider a must, Updates RFC3414 not needed unless our AD requires it). Tom Petch > > > The names used for the four protocols are not consistent within the > > document. Following RFC3414, I think that including Auth is correct. > > > oops, this escaped my attention. > > > Updates to this registry requires a Standards Track document which this > > is not. > > Wright. If the chairs agree, I'll change the track. > > > MIB Module copyright is 2004 > > opps again. Copy and paste error. > > > > > Does this document update RFC3414? It adds to the registry that that > > RFC created which some ADs say is NOT an update, some ADs say it IS an > > update; I think that we need guidance here (the update by RFC5590 of > > RFC3414 is a whole different ball game). > > I will wait for the guidance here. > > -- > Johannes From nobody Thu Jan 29 02:50:05 2015 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 EB52F1A019B for ; Thu, 29 Jan 2015 02:49:52 -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 sVHoSvIPt9-d for ; Thu, 29 Jan 2015 02:49:49 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5B71A0151 for ; Thu, 29 Jan 2015 02:49:48 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 10:49:25 +0000 Message-ID: <01ef01d03bb1$0e575900$4001a8c0@gateway.2wire.net> From: t.petch To: "Bradner, Scott" References: <5913A524-6B63-41CF-9F26-5F6C740EEDEF@vmware.com> <031AA51A-F341-4BEB-926D-F5AE43C22CC2@harvard.edu> Date: Thu, 29 Jan 2015 10:10:14 +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: [81.151.167.59] X-ClientProxiedBy: DB3PR05CA0031.eurprd05.prod.outlook.com (25.160.41.159) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: harvard.edu; dkim=none (message not signed) header.d=none;harvard.edu; dmarc=none action=none header.from=btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 0471B73328 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(24454002)(377454003)(1456003)(92566002)(93886004)(44736004)(23756003)(76176999)(81686999)(81816999)(50226001)(47776003)(66066001)(42186005)(77096005)(50466002)(230783001)(110136001)(116806002)(50986999)(33646002)(77156002)(15975445007)(62966003)(40100003)(122386002)(84392001)(19580405001)(2171001)(14496001)(61296003)(46102003)(62236002)(44716002)(86362001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2015 10:49:25.0550 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 10:49:53 -0000 ----- Original Message ----- From: "Bradner, Scott" To: "Michael MacFaden" Sent: Thursday, January 29, 2015 1:53 AM > no exact number but zero is not enough > > any intelligent input would be helpful Scott This is probably unintelligent, but that is how I am! It is/was on my list of things to progress but it comes below e.g. draft-ietf-opsawg-hmac-sha-2-usm-snmp which has had issues outstanding with it for nearly a year, during which the call for adoption took about four months. That is where the time goes, checking, waiting, prodding, wondering, meandering off into appsawg whose calls for adoption - despite adopting a leaky bucket approach to adoption - seem even more fraught etc. So I have commented on this I-D in the past - I tend to read every mib module - but will not be doing so just yet. Perhaps when the shepherd write-up for draft-ietf-opsawg-hmac-sha-2-usm-snmp is complete, Tom Petch > Scott > > > On Jan 28, 2015, at 7:03 PM, Michael MacFaden wrote: > > > > Exactly how many folks need to speak up? > > > > We did have operator input on this work. > > We can ping them to to send email > > to the list... > > > > Mike > > > > > > On Jan 28, 2015, at 3:54 PM, Scott O. Bradner wrote: > > > >> which is too bad since I think the topic is a useful one > >> > >> but, as chairs, we are supposed to do things based on WG consensus > >> and if no one speaks up we have no way to know if there is consensus > >> one way or another > > > > _______________________________________________ > > 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 Jan 29 03:41:06 2015 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 8D3011A1A10 for ; Wed, 28 Jan 2015 19:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.192 X-Spam-Level: X-Spam-Status: No, score=-0.192 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_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, 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 5WNunAhjNE2V for ; Wed, 28 Jan 2015 19:39:40 -0800 (PST) Received: from omgo.iij.ad.jp (mo00.iij.ad.jp [202.232.30.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0895A1A00E4 for ; Wed, 28 Jan 2015 19:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iijlab.net; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding: Message-Id:References:To;i=keiichi@iijlab.net;s=omgo2;t=1422502778;x= 1423712378; bh=00X1NcKYEQ5cJolQ07UWmBKqyRIp4DXEkajESPbZOVE=; b=qIXtMi9vWaeJnIkR H30W8Mn4i/Ku+TqMmtaNboKCXp6myDbksyypzrQJ+hS8TTER4XlIIFhbv9CYzZNOM3+Irxza1jz/7 1ToM2lxAEEsyfbaSVAv2xSTsKnVmYZwAGETWzfMKLIkDdnZlvAbbIk3BtCFkMpN68WIH0LKoVSC47 VeUPlcMM9dvKk+P12pi8r9BrEuSxDKFQC98zxUuCheBxO257w+HaIHxEO29uyC7mhwXzlsBZ7zT1+ KgQuIs6zfKeoNjj0oXP47cPvQYEadOtTAGDe+YPyAJqV4jgPCwZ14m5JcG3D0a+5iNjT4wsETgxVo 5QGisDHozj5QKPN5mQ==; Received: by omgo.iij.ad.jp (mo00) id t0T3dc6R014572; Thu, 29 Jan 2015 12:39:38 +0900 X-MXL-Hash: 54c9ab7a3b0bbbe9-40f09333750e077a3830acd6426b20c6ecb80884 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Keiichi SHIMA In-Reply-To: Date: Thu, 29 Jan 2015 12:38:38 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <63100DCF-C794-4761-B350-B26EFF56910A@iijlab.net> References: To: Warren Kumari , "Scott O. Bradner" , "opsawg@ietf.org" X-Mailer: Apple Mail (2.1993) Archived-At: X-Mailman-Approved-At: Thu, 29 Jan 2015 03:41:02 -0800 Cc: draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 03:39:41 -0000 Hello all, I didn=E2=80=99t send any response to the last call of the vmm-mib since = I am one of the authors of the draft. But let me say one thing. I remember not a few people joined the discussion of this draft both on = the mailing list and on the mic. They gave us many useful comments, = questions, objections, and sometimes good revised text for making the = draft better. We incorporated those responses and make the final draft = which was shown during the last call. So, to those who joined the discussion before, please show your supports = of the draft, if you think the draft is valuable for the future = hypervisor operation and management systems. Thanks, --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) Research Laboratory, IIJ Innovation Institute, Inc WIDE project > On 2015Jan 29,, at 08:58, Warren Kumari wrote: >=20 > On Wed, Jan 28, 2015 at 6:54 PM, Scott O. Bradner = wrote: >> which is too bad since I think the topic is a useful one >=20 > Yup, as do I... >=20 > If there is a sudden upwelling of support and interest, we can > definitely discuss rerunning the WGLC. >=20 >>=20 >> but, as chairs, we are supposed to do things based on WG consensus >> and if no one speaks up we have no way to know if there is consensus >> one way or another >=20 > Yup. The consensus on some of the documents we have progressed has > been thiner that we'd like. We've been getting consensus, but from a > much smaller group than ideal. >=20 > Remember folk - if you might want the working group to review one of > *your* documents in the future, you are going to have to review (and > provide feedback!) on other peoples documents now... >=20 > W >=20 >=20 >=20 >>=20 >> Scott >>=20 >>> On Jan 28, 2015, at 6:40 PM, Warren Kumari = wrote: >>>=20 >>> On Fri, Jan 9, 2015 at 12:15 PM, Warren Kumari = wrote: >>>> Dear OpsAWG WG, >>>>=20 >>>> The authors of draft-ietf-opsawg-vmm-mib have indicated that they >>>> believe that the document is ready, and have asked for Working = Group >>>> Last Call. >>>>=20 >>>> The draft is available here: >>>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ >>>>=20 >>>> Please review this draft to see if you think it is ready for >>>> publication and send comments to the list, clearly stating your = view. >>>>=20 >>>> This WGLC ends Fri 23-Jan-2015. >>>>=20 >>>> In addition, to satisfy RFC 6702 ("Promoting Compliance with >>>> Intellectual Property Rights (IPR)"): >>>> Are you personally aware of any IPR that applies to >>>> draft-ietf-opsawg-vmm-mib? If so, has this IPR been disclosed in >>>> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and = 5378 >>>> for more details.) >>>>=20 >>>> Thanks, >>>> Warren Kumari >>>> (as OpsAWG WG co-chair) >>>=20 >>> The WGLC has concluded with no feedback or comments, and so we have = to >>> conclude that the WG is no longer interested in this work. >>>=20 >>> Apologies to the authors, >>> W >>>=20 >>>>=20 >>>> -- >>>> 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 >>>=20 >>>=20 >>>=20 >>> -- >>> 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 >>>=20 >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >=20 >=20 >=20 > --=20 > 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 From nobody Thu Jan 29 06:00:28 2015 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 C69F61A03A3 for ; Thu, 29 Jan 2015 06:00:23 -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 uhRlo3Oa_bUv for ; Thu, 29 Jan 2015 06:00:20 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439BE1A0AF1 for ; Thu, 29 Jan 2015 06:00:19 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 13:59:56 +0000 Message-ID: <02e901d03bcb$ac1065a0$4001a8c0@gateway.2wire.net> From: t.petch To: t.petch , Johannes Merkle , Warren Kumari References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> <01f001d03bb1$0e9a7c80$4001a8c0@gateway.2wire.net> Date: Thu, 29 Jan 2015 13:58:24 +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: [81.151.167.59] X-ClientProxiedBy: DB3PR05CA0027.eurprd05.prod.outlook.com (25.160.41.155) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:AMSPR07MB049; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB049; X-Forefront-PRVS: 0471B73328 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(51704005)(377454003)(51914003)(13464003)(64706001)(230783001)(50226001)(86362001)(19580405001)(116806002)(50986999)(66066001)(47776003)(44736004)(61296003)(19580395003)(23756003)(1556002)(81816999)(93886004)(46102003)(42186005)(14496001)(76176999)(81686999)(87976001)(92566002)(50466002)(84392001)(1456003)(77096005)(15975445007)(62966003)(33646002)(122386002)(44716002)(77156002)(62236002)(40100003)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2015 13:59:56.4317 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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: Thu, 29 Jan 2015 14:00:24 -0000 Another stray thought. I see RFC3412 in the references but cannot see it referenced in the text. And Juergen has responded on the question of what to put in the Security Considerations so ignore my comments on that. Tom Petch ----- Original Message ----- From: "t.petch" To: "Johannes Merkle" ; "Warren Kumari" Cc: ; "Scott Bradner" Sent: Thursday, January 29, 2015 10:30 AM Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt > ----- Original Message ----- > From: "Johannes Merkle" > To: "t.petch" ; "Warren Kumari" > Cc: ; "Scott Bradner" > Sent: Thursday, January 29, 2015 8:03 AM > > > Tom, > > > > thanks for the thorough review. This really helps improving the > document. > > > > > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a > > > Normative reference. RFC6234 is not Standards Track but that is ok, > it > > > is already in the list of IESG permitted downrefs (does that need > > > calling out at IETF Last Call?) > > > > You are right, but the question is whether I should rather use > references [RFC2104] and [SHA] here. > > Don't know - this is the gory detail which I did not pursue - really > need an implementor to say if the older references are adequate for > SHA2; but as I say, a Normative reference to RFC6234 is fine if we want > it > > > > s9.1 > > > /apply the use /apply to the use / > > > > Right. > > > > > > > > s9.2 > > > is it the length of the key that gives it strength or its entropy? > Is > > > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 > > > really stronger than > > > !qaurk/99SS~ ? > > > > Strictly speaking, you are right, but it is common sense that > cryptographic keys should have maximum entropy, i.e., they > > should be selected uniformly at random from bit string of that length. > Consequently, virtually all cryptographic papers > > and text books use key the key length synonymous to its entropy. Thus, > I consider this distinction as unnecessary. > > Yes but, consider the audience. Cryptographic material is aimed at > cryptographers who know about entropy without being told, the audience > of this I-D is all sorts, including MIB module specialists whose > knowledge of cryptography is probably less than useless. So I think > 'length' is wrong, 'entropy' is probably too technical (especially if, > like me, Thermodynamics was part of your degree), RFC5310 uses 'size and > quality of the key' which is probably a good compromise. > > > > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I > think > > > that s9.4 should reflect that (lest it confuses, or am I confused > having > > > missed an OBJECT somewhere?) > > > > Here I definitely need help, as I have no knowledge about MIBs. > Actually, I copied that section from RFC 3411. Please > > give advise what to write here or if this section is needed at all. > > RFC3826 is a good parallel here - it omits this paragraph entirely so I > would do the same, unless Juergen, Bert or Randy say otherwise. > > No further comments on the points outstanding below (Standards Track I > consider a must, Updates RFC3414 not needed unless our AD requires it). > > Tom Petch > > > > > The names used for the four protocols are not consistent within the > > > document. Following RFC3414, I think that including Auth is > correct. > > > > > oops, this escaped my attention. > > > > > Updates to this registry requires a Standards Track document which > this > > > is not. > > > > Wright. If the chairs agree, I'll change the track. > > > > > MIB Module copyright is 2004 > > > > opps again. Copy and paste error. > > > > > > > > Does this document update RFC3414? It adds to the registry that > that > > > RFC created which some ADs say is NOT an update, some ADs say it IS > an > > > update; I think that we need guidance here (the update by RFC5590 of > > > RFC3414 is a whole different ball game). > > > > I will wait for the guidance here. > > > > -- > > Johannes > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Jan 29 06:27:27 2015 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 69A2C1A19E9 for ; Thu, 29 Jan 2015 06:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Ax4CNe8IHTZr for ; Thu, 29 Jan 2015 06:27:20 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4591A047A for ; Thu, 29 Jan 2015 06:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=949; q=dns/txt; s=iport; t=1422541640; x=1423751240; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FJoPDVHmeMhvHLsISqr97yrq8gaJrZWuYcqHAHt8+54=; b=fhP59aaM+UI3k+PADD/6gUjZBnzXctUvy1xjU1e9CAEfqq4vvSX1VTOI peLvyeGIOqyBTQiRwIhviBkaLGuuCOSw/2JXT+XxitgpeGf8oEGrZNlG+ c7wIL0BlPP5fYIWYrVpmCnsfoJOyK/8CUYHMYjA7c+QekZbTpkr/r52Lh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AuBQBUQspU/51dJa1agwaELMdMAoEfQwEBAQEBfYQNAQEEIw8BBTYKARALGAICBRYLAgIJAwIBAgFFBgEMAQcBAYgowQOWBQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIY11EQFQB4JogUEBBIoNjgmBF4MBgiCIUYM9IoICHIFuIIE8gTcBAQE X-IronPort-AV: E=Sophos;i="5.09,486,1418083200"; d="scan'208";a="118620720" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 29 Jan 2015 14:27:19 +0000 Received: from [10.82.215.22] (rtp-vpn4-1814.cisco.com [10.82.215.22]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0TERIob003918; Thu, 29 Jan 2015 14:27:18 GMT Message-ID: <54CA4347.8060308@cisco.com> Date: Thu, 29 Jan 2015 09:27:19 -0500 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Keiichi SHIMA , Warren Kumari , "Scott O. Bradner" , "opsawg@ietf.org" References: <63100DCF-C794-4761-B350-B26EFF56910A@iijlab.net> In-Reply-To: <63100DCF-C794-4761-B350-B26EFF56910A@iijlab.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 14:27:23 -0000 On 1/28/15 10:38 PM, Keiichi SHIMA wrote: > Hello all, > > I didn’t send any response to the last call of the vmm-mib since I am one of the authors of the draft. But let me say one thing. > > I remember not a few people joined the discussion of this draft both on the mailing list and on the mic. They gave us many useful comments, questions, objections, and sometimes good revised text for making the draft better. We incorporated those responses and make the final draft which was shown during the last call. > > So, to those who joined the discussion before, please show your supports of the draft, if you think the draft is valuable for the future hypervisor operation and management systems. Yes, I had made many comments on this module before, and I feel that the WGLC version was good. I didn't have anything more to add. In fact, I thought I had said so on the list, but perhaps that email never did get sent. Joe From nobody Thu Jan 29 07:09:59 2015 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 347581A1A80 for ; Thu, 29 Jan 2015 07:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 iFd_ciukcIXG for ; Thu, 29 Jan 2015 07:09:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.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 01BC01A1AA4 for ; Thu, 29 Jan 2015 07:09:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YGqj4-0002Ns-EW for opsawg@ietf.org; Thu, 29 Jan 2015 15:09:46 +0000 Date: Thu, 29 Jan 2015 07:09:47 -0800 Message-ID: From: Randy Bush To: opsawg In-Reply-To: <54CA4347.8060308@cisco.com> References: <63100DCF-C794-4761-B350-B26EFF56910A@iijlab.net> <54CA4347.8060308@cisco.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] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 15:09:50 -0000 i read it and it's ok. i need it and will use it. randy From nobody Thu Jan 29 07:38:28 2015 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 B52B91A1A22 for ; Thu, 29 Jan 2015 07:38:27 -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, 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 0BGOU_CWPyNI for ; Thu, 29 Jan 2015 07:38:26 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0088.outbound.protection.outlook.com [65.55.169.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B501A1A1F for ; Thu, 29 Jan 2015 07:38:25 -0800 (PST) Received: from CY1PR0701MB1082.namprd07.prod.outlook.com (25.160.145.154) by CY1PR0701MB1081.namprd07.prod.outlook.com (25.160.145.153) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 15:38:23 +0000 Received: from CY1PR0701MB1082.namprd07.prod.outlook.com ([25.160.145.154]) by CY1PR0701MB1082.namprd07.prod.outlook.com ([25.160.145.154]) with mapi id 15.01.0065.013; Thu, 29 Jan 2015 15:38:23 +0000 From: "Bradner, Scott" To: t.petch Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib Thread-Index: AQHQO2ZbPVWL1x1rXkmU3W4av1KsaA== Date: Thu, 29 Jan 2015 15:38:23 +0000 Message-ID: <54419BE1-5006-48B0-9DFF-FF5ED387C7A5@harvard.edu> References: <5913A524-6B63-41CF-9F26-5F6C740EEDEF@vmware.com> <031AA51A-F341-4BEB-926D-F5AE43C22CC2@harvard.edu> <01ef01d03bb1$0e575900$4001a8c0@gateway.2wire.net> In-Reply-To: <01ef01d03bb1$0e575900$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.103.229.199] authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=harvard.edu; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CY1PR0701MB1081; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1081; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(13464003)(51704005)(24454002)(75432002)(76176999)(36756003)(19580395003)(46102003)(92566002)(62966003)(77156002)(54356999)(122556002)(50986999)(40100003)(66066001)(83716003)(33656002)(87936001)(230783001)(90282001)(19580405001)(82746002)(2950100001)(2656002)(93886004)(88552001)(102836002)(106116001)(99286002)(89122001)(15975445007)(110136001)(2900100001)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1081; H:CY1PR0701MB1082.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0488A47F9253B0468E861F0C896B1916@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2015 15:38:23.5008 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1081 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 15:38:27 -0000 we (the chairs) are trying to be better about paying attention to when last= calls and cals for adoption finish (Warren has set up calendar entries to remind = us) Scott > On Jan 29, 2015, at 5:10 AM, t.petch wrote: >=20 > ----- Original Message ----- > From: "Bradner, Scott" > To: "Michael MacFaden" > Sent: Thursday, January 29, 2015 1:53 AM >=20 >> no exact number but zero is not enough >>=20 >> any intelligent input would be helpful >=20 > Scott >=20 > This is probably unintelligent, but that is how I am! It is/was on my > list of things to progress but it comes below e.g. > draft-ietf-opsawg-hmac-sha-2-usm-snmp > which has had issues outstanding with it for nearly a year, during which > the call for adoption took about four months. That is where the time > goes, checking, waiting, prodding, wondering, meandering off into > appsawg whose calls for adoption - despite adopting a leaky bucket > approach to adoption - seem even more fraught etc. >=20 > So I have commented on this I-D in the past - I tend to read every mib > module - but will not be doing so just yet. Perhaps when the shepherd > write-up for > draft-ietf-opsawg-hmac-sha-2-usm-snmp > is complete, >=20 > Tom Petch >=20 >> Scott >>=20 >>> On Jan 28, 2015, at 7:03 PM, Michael MacFaden > wrote: >>>=20 >>> Exactly how many folks need to speak up? >>>=20 >>> We did have operator input on this work. >>> We can ping them to to send email >>> to the list... >>>=20 >>> Mike >>>=20 >>>=20 >>> On Jan 28, 2015, at 3:54 PM, Scott O. Bradner wrote: >>>=20 >>>> which is too bad since I think the topic is a useful one >>>>=20 >>>> but, as chairs, we are supposed to do things based on WG consensus >>>> and if no one speaks up we have no way to know if there is > consensus >>>> one way or another >>>=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 >=20 From nobody Thu Jan 29 08:05:13 2015 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 CEB011A8747 for ; Thu, 29 Jan 2015 08:05:11 -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, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 r2b_2LnjJvGG for ; Thu, 29 Jan 2015 08:05:10 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9B61A86FC for ; Thu, 29 Jan 2015 08:05:09 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id r20so26499803wiv.4 for ; Thu, 29 Jan 2015 08:05:08 -0800 (PST) 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=hekFNbGPuq+gkwuhvU8gIOZb6vBwt4a/Cc/95njsh9Y=; b=EuKnGGamD/m3YkO1dLaCESflYp1NpQnmA2DWypFtApaiKVpiN3e/kNb4z68ZDqZnNn w6jTnZ51vF7VQxdaWB/k1LJPxfG6eyrok1OjryYg+nGWweorVX21TdUj6qGzcq3sk8fc 5mh1B2CbV4YfaoZWY6SSOsPcuYHNjfHAuMpntMPExluylF2oeZs1JRbpyXuvSubTQN5i SHAOeDveA/NzVjz4dQOeud+/OB7G0JFZjEVjt07e/Mx87KKeXwz4m0SsQxMxHujHASGK sD1dEEDJua94u9LDGFNtiOcQIrGjCTK/pAfby8FQfF0njLcv7NXoTvgbcglNljTtCl4G nWwQ== X-Gm-Message-State: ALoCoQmROGRKvHJkpQNyU312KktNLJixBg70nbCm1sdMz9NbG80wIi82UAX52hfuz7l8mguGcJS1 MIME-Version: 1.0 X-Received: by 10.180.73.178 with SMTP id m18mr1222986wiv.65.1422547507456; Thu, 29 Jan 2015 08:05:07 -0800 (PST) Received: by 10.194.158.231 with HTTP; Thu, 29 Jan 2015 08:05:07 -0800 (PST) In-Reply-To: <01ef01d03bb1$0e575900$4001a8c0@gateway.2wire.net> References: <5913A524-6B63-41CF-9F26-5F6C740EEDEF@vmware.com> <031AA51A-F341-4BEB-926D-F5AE43C22CC2@harvard.edu> <01ef01d03bb1$0e575900$4001a8c0@gateway.2wire.net> Date: Thu, 29 Jan 2015 11:05:07 -0500 Message-ID: From: Warren Kumari To: "t.petch" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 16:05:12 -0000 On Thu, Jan 29, 2015 at 5:10 AM, t.petch wrote: > ----- Original Message ----- > From: "Bradner, Scott" > To: "Michael MacFaden" > Sent: Thursday, January 29, 2015 1:53 AM > >> no exact number but zero is not enough >> >> any intelligent input would be helpful > > Scott > > This is probably unintelligent, but that is how I am! It is/was on my > list of things to progress but it comes below e.g. > draft-ietf-opsawg-hmac-sha-2-usm-snmp > which has had issues outstanding with it for nearly a year, during which > the call for adoption took about four months. Yup, the CfA for this took a really long time, because we had 2 competing drafts, and delayed while waiting to see if the authors could merge them, which should take priority, etc. The WG -00 was posted on December 12th, the authors asked for LC on Jan 15th, and we said (on the 16th) that we'd like a bit more feedback and if we didn't, would try force the issue by going to WGLC. Sine then we've gotten review from one person - yourself. I have on my calendar (which you cannot see :-)): "Start WGLC on draft-ietf-opsawg-hmac-sha-2-usm-snmp-00 - Feb 2nd" > That is where the time > goes, checking, waiting, prodding, wondering, meandering off into > appsawg whose calls for adoption - despite adopting a leaky bucket > approach to adoption - seem even more fraught etc. > > So I have commented on this I-D in the past - I tend to read every mib > module - but will not be doing so just yet. Perhaps when the shepherd > write-up for > draft-ietf-opsawg-hmac-sha-2-usm-snmp > is complete, Ok, but there will not *be* a shepherd writeup until the WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp is done, and there is consensus. We've been having a really hard time getting people to review and comment in OpsAWG, partly during discussions, but especially during LC - if folk have reviewed and provided feedback during the evolution of the documents it is still helpful to comment (even just to say that they still approve, and still think it is worth publishing) at LC. Because of the nature of OpsAWG we often end up with documents that are only of interest to a small subset of participants and / or are maintenance type documents, and so we often only have a small number of people participating, but calling consensus on a tiny number of reviews (and explaining this is writeups) is getting old... W > > Tom Petch > >> Scott >> >> > On Jan 28, 2015, at 7:03 PM, Michael MacFaden > wrote: >> > >> > Exactly how many folks need to speak up? >> > >> > We did have operator input on this work. >> > We can ping them to to send email >> > to the list... >> > >> > Mike >> > >> > >> > On Jan 28, 2015, at 3:54 PM, Scott O. Bradner wrote: >> > >> >> which is too bad since I think the topic is a useful one >> >> >> >> but, as chairs, we are supposed to do things based on WG consensus >> >> and if no one speaks up we have no way to know if there is > consensus >> >> one way or another >> > >> > _______________________________________________ >> > 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 From nobody Thu Jan 29 09:12:09 2015 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 D9B0D1A87C4; Thu, 29 Jan 2015 09:12:00 -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 GPPBZHtE5Mal; Thu, 29 Jan 2015 09:11:59 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C351A87D2; Thu, 29 Jan 2015 09:11:19 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id ar1so36331944iec.13; Thu, 29 Jan 2015 09:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LD6gQTXq1jhAK7da1AqvZPnmAjzXhGf2WYNUogAaP3Q=; b=I9xvZ+cmIxK1M7TLKSuXmpq4/ldzH69tEEWkoMTd4XlvsR3jpma4po9RS1XRhGKXjV ct0wC8pJkVp6tQ1FREXzH4oKQ7nhqaYzNpjpymdw89F3QOy8g2ZDVprB48yA6KICK9Y7 US0jWb5b1mT7fjvi1FhqJbXA6nvFgKl3sXUUKvWytcRnf7KDiNOtXAd9/HkendwG2i/W Ce4hoPpHTGHADV45okkkFJXr6PIIbNUrmriZBn1BdEHdSxevnAlsjQzvM8E7prUi7Wa0 W5V9GPFaJltmSOR0WOu5Sl5pLkCtQ+Dr4iTo+WWTF+SHe0nU0WdQiyMlMLGm3vXKPBeH H0MA== X-Received: by 10.107.166.13 with SMTP id p13mr1831452ioe.61.1422551478336; Thu, 29 Jan 2015 09:11:18 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-73-98.tor.primus.ca. [173.206.73.98]) by mx.google.com with ESMTPSA id b7sm1196936igx.15.2015.01.29.09.11.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 09:11:18 -0800 (PST) Message-ID: <54CA69B9.8010305@gmail.com> Date: Thu, 29 Jan 2015 12:11:21 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" References: <20150129165436.19364.82358.idtracker@ietfa.amsl.com> In-Reply-To: <20150129165436.19364.82358.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150129165436.19364.82358.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Spencer Dawkins Subject: [OPSAWG] Fwd: New Version Notification for draft-perrault-behave-deprecate-nat-mib-v1-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: , X-List-Received-Date: Thu, 29 Jan 2015 17:12:01 -0000 A small update based on suggestions from AD Spencer Dawkins. Primarily, deleted the list of new features that was in section 3.2, leaving that to the NATV2-MIB document. Also fixed a couple of authors' addresses and a couple of typos. Tom Taylor -------- Forwarded Message -------- Subject: New Version Notification for draft-perrault-behave-deprecate-nat-mib-v1-01.txt Date: Thu, 29 Jan 2015 08:54:36 -0800 From: internet-drafts@ietf.org To: Tom Taylor , Simon Perreault , Senthil Sivakumar , Simon Perreault , Tina Tsou , Tina Tsou , Senthil Sivakumar , Tom Taylor A new version of I-D, draft-perrault-behave-deprecate-nat-mib-v1-01.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Name: draft-perrault-behave-deprecate-nat-mib-v1 Revision: 01 Title: Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT)) Document date: 2015-01-29 Group: Individual Submission Pages: 59 URL: http://www.ietf.org/internet-drafts/draft-perrault-behave-deprecate-nat-mib-v1-01.txt Status: https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ Htmlized: http://tools.ietf.org/html/draft-perrault-behave-deprecate-nat-mib-v1-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-01 Abstract: This memo deprecates MIB module NAT-MIB, a portion of the Management Information Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NAT-MIB-V2, which responds to deficiencies found in module NAT-MIB and adds new capabilities. This document obsoletes RFC 4008. 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 Jan 29 10:32:13 2015 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 6F6F61A1BCC for ; Thu, 29 Jan 2015 10:32:07 -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, 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 6XObp30WrKzd for ; Thu, 29 Jan 2015 10:32:05 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA52C1A1BBB for ; Thu, 29 Jan 2015 10:32:04 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 18:31:41 +0000 Message-ID: <036001d03bf1$a26aa6c0$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari References: <5913A524-6B63-41CF-9F26-5F6C740EEDEF@vmware.com><031AA51A-F341-4BEB-926D-F5AE43C22CC2@harvard.edu><01ef01d03bb1$0e575900$4001a8c0@gateway.2wire.net> Date: Thu, 29 Jan 2015 18:30:12 +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: [81.151.167.59] X-ClientProxiedBy: DB3PR05CA0039.eurprd05.prod.outlook.com (25.160.41.167) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) Authentication-Results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:AMSPR07MB051; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB051; X-Forefront-PRVS: 0471B73328 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(51704005)(377454003)(86362001)(40100003)(46102003)(122386002)(61296003)(62966003)(77156002)(47776003)(66066001)(62236002)(44716002)(19580405001)(19580395003)(1556002)(81816999)(92566002)(50226001)(84392001)(81686999)(50466002)(42186005)(1456003)(44736004)(110136001)(33646002)(23676002)(116806002)(93886004)(230783001)(76176999)(77096005)(50986999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2015 18:31:41.2821 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 18:32:07 -0000 ----- Original Message ----- From: "Warren Kumari" To: "t.petch" Sent: Thursday, January 29, 2015 4:05 PM > On Thu, Jan 29, 2015 at 5:10 AM, t.petch wrote: > > ----- Original Message ----- > > From: "Bradner, Scott" > > To: "Michael MacFaden" > > Sent: Thursday, January 29, 2015 1:53 AM > > > >> no exact number but zero is not enough > >> > >> any intelligent input would be helpful > > > > Scott > > > > This is probably unintelligent, but that is how I am! It is/was on my > > list of things to progress but it comes below e.g. > > draft-ietf-opsawg-hmac-sha-2-usm-snmp > > which has had issues outstanding with it for nearly a year, during which > > the call for adoption took about four months. > > Yup, the CfA for this took a really long time, because we had 2 > competing drafts, and delayed while waiting to see if the authors > could merge them, which should take priority, etc. The WG -00 was > posted on December 12th, the authors asked for LC on Jan 15th, and we > said (on the 16th) that we'd like a bit more feedback and if we > didn't, would try force the issue by going to WGLC. Sine then we've > gotten review from one person - yourself. > > I have on my calendar (which you cannot see :-)): "Start WGLC on > draft-ietf-opsawg-hmac-sha-2-usm-snmp-00 - Feb 2nd" Warren, but I have just raised several points, one of which needs AD input (IMHO), another of which needs WG Chair input, and to embark on a WG LC without clearing up these is, IMHO, likely to engender further confusion e.g. that points already raised will be re-raised and a new one from someone else will be lost in the noise. So for me, an I-D addressing the points raised comes first, then WG LC and, of course, the Shepherd write-up can only come after that, in, say, two months time. That is my, hatless, thinking. Meanwhile, I see other WG using tools to keep track of outstanding issues etc and not progressing any faster - tools may help, they can also hinder. Incidentally, I also see some WG chairs much more willing to abandon I-Ds completely at the WG LC stage, when getting no support on the list (as opposed to interpreting silence as no objections so on to AD review and IETF LC). I wonder if a few more such instances would galvanise action. Tom Petch > > That is where the time > > goes, checking, waiting, prodding, wondering, meandering off into > > appsawg whose calls for adoption - despite adopting a leaky bucket > > approach to adoption - seem even more fraught etc. > > > > So I have commented on this I-D in the past - I tend to read every mib > > module - but will not be doing so just yet. Perhaps when the shepherd > > write-up for > > draft-ietf-opsawg-hmac-sha-2-usm-snmp > > is complete, > > Ok, but there will not *be* a shepherd writeup until the WGLC for > draft-ietf-opsawg-hmac-sha-2-usm-snmp is done, and there is consensus. > > We've been having a really hard time getting people to review and > comment in OpsAWG, partly during discussions, but especially during LC > - if folk have reviewed and provided feedback during the evolution of > the documents it is still helpful to comment (even just to say that > they still approve, and still think it is worth publishing) at LC. > Because of the nature of OpsAWG we often end up with documents that > are only of interest to a small subset of participants and / or are > maintenance type documents, and so we often only have a small number > of people participating, but calling consensus on a tiny number of > reviews (and explaining this is writeups) is getting old... > > W > > > > Tom Petch > > > >> Scott > >> > >> > On Jan 28, 2015, at 7:03 PM, Michael MacFaden > > wrote: > >> > > >> > Exactly how many folks need to speak up? > >> > > >> > We did have operator input on this work. > >> > We can ping them to to send email > >> > to the list... > >> > > >> > Mike > >> > > >> > > >> > On Jan 28, 2015, at 3:54 PM, Scott O. Bradner wrote: > >> > > >> >> which is too bad since I think the topic is a useful one > >> >> > >> >> but, as chairs, we are supposed to do things based on WG consensus > >> >> and if no one speaks up we have no way to know if there is > > consensus > >> >> one way or another > >> > > >> > From nobody Thu Jan 29 11:15:18 2015 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 12A1A1A079A for ; Thu, 29 Jan 2015 11:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 0QRcFDZG4H2X for ; Thu, 29 Jan 2015 11:15:11 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34151A037C for ; Thu, 29 Jan 2015 11:15:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8DCFE1135; Thu, 29 Jan 2015 20:15:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id X-RE84221rmQ; Thu, 29 Jan 2015 20:15:06 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 29 Jan 2015 20:15:09 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3FE420038; Thu, 29 Jan 2015 20:15:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t_OgR8IYc_XJ; Thu, 29 Jan 2015 20:15:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C11FB20035; Thu, 29 Jan 2015 20:15:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EDFCB31212E0; Thu, 29 Jan 2015 20:15:07 +0100 (CET) Date: Thu, 29 Jan 2015 20:15:07 +0100 From: Juergen Schoenwaelder To: Warren Kumari Message-ID: <20150129191507.GA30178@elstar.local> Mail-Followup-To: Warren Kumari , "opsawg@ietf.org" , draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg-chairs@tools.ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 19:15:13 -0000 On Wed, Jan 28, 2015 at 06:40:48PM -0500, Warren Kumari wrote: > > The WGLC has concluded with no feedback or comments, and so we have to > conclude that the WG is no longer interested in this work. > > Apologies to the authors, Too bad, this document is actually useful and as far as I can tell technically sound (but then I am co-author and hence this voice does not count). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jan 29 13:16:38 2015 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 3DB861A0181 for ; Thu, 29 Jan 2015 13:16:36 -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, 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 SiZhzVNhylCz for ; Thu, 29 Jan 2015 13:16:34 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0699.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::699]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFECE1A0174 for ; Thu, 29 Jan 2015 13:16:33 -0800 (PST) Received: from CY1PR0701MB1082.namprd07.prod.outlook.com (25.160.145.154) by CY1PR0701MB1082.namprd07.prod.outlook.com (25.160.145.154) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 21:16:01 +0000 Received: from CY1PR0701MB1082.namprd07.prod.outlook.com ([25.160.145.154]) by CY1PR0701MB1082.namprd07.prod.outlook.com ([25.160.145.154]) with mapi id 15.01.0065.013; Thu, 29 Jan 2015 21:16:01 +0000 From: "Bradner, Scott" To: t.petch Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib Thread-Index: AQHQO2ZbPVWL1x1rXkmU3W4av1KsaA== Date: Thu, 29 Jan 2015 21:16:01 +0000 Message-ID: References: <5913A524-6B63-41CF-9F26-5F6C740EEDEF@vmware.com> <031AA51A-F341-4BEB-926D-F5AE43C22CC2@harvard.edu> <01ef01d03bb1$0e575900$4001a8c0@gateway.2wire.net> <036001d03bf1$a26aa6c0$4001a8c0@gateway.2wire.net> In-Reply-To: <036001d03bf1$a26aa6c0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.166.5.69] authentication-results: spf=none (sender IP is ) smtp.mailfrom=sob@harvard.edu; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CY1PR0701MB1082; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1082; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(377454003)(51704005)(54094003)(24454002)(13464003)(93886004)(92566002)(90282001)(33656002)(75432002)(86362001)(87936001)(2656002)(122556002)(66066001)(88552001)(46102003)(230783001)(50986999)(102836002)(77156002)(89122001)(62966003)(54356999)(110136001)(36756003)(76176999)(99286002)(106116001)(2900100001)(83716003)(19580405001)(2950100001)(82746002)(40100003)(19580395003)(7059030)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1082; H:CY1PR0701MB1082.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: harvard.edu does not designate permitted sender hosts) 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: 29 Jan 2015 21:16:01.6873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1082 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 29 Jan 2015 21:16:36 -0000 are you referring to the notes you sent back in may 2014? if not - please resend so we know what you are referring to thanks Scott > On Jan 29, 2015, at 1:30 PM, t.petch wrote: >=20 > ----- Original Message ----- > From: "Warren Kumari" > To: "t.petch" > Sent: Thursday, January 29, 2015 4:05 PM >=20 >=20 >> On Thu, Jan 29, 2015 at 5:10 AM, t.petch wrote: >>> ----- Original Message ----- >>> From: "Bradner, Scott" >>> To: "Michael MacFaden" >>> Sent: Thursday, January 29, 2015 1:53 AM >>>=20 >>>> no exact number but zero is not enough >>>>=20 >>>> any intelligent input would be helpful >>>=20 >>> Scott >>>=20 >>> This is probably unintelligent, but that is how I am! It is/was on > my >>> list of things to progress but it comes below e.g. >>> draft-ietf-opsawg-hmac-sha-2-usm-snmp >>> which has had issues outstanding with it for nearly a year, during > which >>> the call for adoption took about four months. >>=20 >> Yup, the CfA for this took a really long time, because we had 2 >> competing drafts, and delayed while waiting to see if the authors >> could merge them, which should take priority, etc. The WG -00 was >> posted on December 12th, the authors asked for LC on Jan 15th, and we >> said (on the 16th) that we'd like a bit more feedback and if we >> didn't, would try force the issue by going to WGLC. Sine then we've >> gotten review from one person - yourself. >>=20 >> I have on my calendar (which you cannot see :-)): "Start WGLC on >> draft-ietf-opsawg-hmac-sha-2-usm-snmp-00 - Feb 2nd" >=20 > Warren, >=20 > but I have just raised several points, one of which needs AD input > (IMHO), another of which needs WG Chair input, and to embark on a WG LC > without clearing up these is, IMHO, likely to engender further confusion > e.g. that points already raised will be re-raised and a new one from > someone else will be lost in the noise. So for me, an I-D addressing > the points raised comes first, then WG LC and, of course, the Shepherd > write-up can only come after that, in, say, two months time. >=20 > That is my, hatless, thinking. >=20 > Meanwhile, I see other WG using tools to keep track of outstanding > issues etc and not progressing any faster - tools may help, they can > also hinder. >=20 > Incidentally, I also see some WG chairs much more willing to abandon > I-Ds completely at the WG LC stage, when getting no support on the list > (as opposed to interpreting silence as no objections so on to AD review > and IETF LC). I wonder if a few more such instances would galvanise > action. >=20 > Tom Petch >=20 >=20 >>> That is where the time >>> goes, checking, waiting, prodding, wondering, meandering off into >>> appsawg whose calls for adoption - despite adopting a leaky bucket >>> approach to adoption - seem even more fraught etc. >>>=20 >>> So I have commented on this I-D in the past - I tend to read every > mib >>> module - but will not be doing so just yet. Perhaps when the > shepherd >>> write-up for >>> draft-ietf-opsawg-hmac-sha-2-usm-snmp >>> is complete, >>=20 >> Ok, but there will not *be* a shepherd writeup until the WGLC for >> draft-ietf-opsawg-hmac-sha-2-usm-snmp is done, and there is consensus. >>=20 >> We've been having a really hard time getting people to review and >> comment in OpsAWG, partly during discussions, but especially during LC >> - if folk have reviewed and provided feedback during the evolution of >> the documents it is still helpful to comment (even just to say that >> they still approve, and still think it is worth publishing) at LC. >> Because of the nature of OpsAWG we often end up with documents that >> are only of interest to a small subset of participants and / or are >> maintenance type documents, and so we often only have a small number >> of people participating, but calling consensus on a tiny number of >> reviews (and explaining this is writeups) is getting old... >>=20 >> W >>>=20 >>> Tom Petch >>>=20 >>>> Scott >>>>=20 >>>>> On Jan 28, 2015, at 7:03 PM, Michael MacFaden >>> wrote: >>>>>=20 >>>>> Exactly how many folks need to speak up? >>>>>=20 >>>>> We did have operator input on this work. >>>>> We can ping them to to send email >>>>> to the list... >>>>>=20 >>>>> Mike >>>>>=20 >>>>>=20 >>>>> On Jan 28, 2015, at 3:54 PM, Scott O. Bradner > wrote: >>>>>=20 >>>>>> which is too bad since I think the topic is a useful one >>>>>>=20 >>>>>> but, as chairs, we are supposed to do things based on WG > consensus >>>>>> and if no one speaks up we have no way to know if there is >>> consensus >>>>>> one way or another >>>>>=20 >>>>>=20 >=20 From nobody Thu Jan 29 17:57:01 2015 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 65D1D1A88AB for ; Thu, 29 Jan 2015 17:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] 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 V-gNUuZ3_tU7 for ; Thu, 29 Jan 2015 17:56:56 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15261A8888 for ; Thu, 29 Jan 2015 17:56:56 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-05v.sys.comcast.net with comcast id m1vz1p00653iAfU011wwVc; Fri, 30 Jan 2015 01:56:56 +0000 Received: from [192.168.1.3] ([24.218.118.50]) by resomta-po-10v.sys.comcast.net with comcast id m1ws1p00u15KgXL011wtUW; Fri, 30 Jan 2015 01:56:56 +0000 References: <20150129191507.GA30178@elstar.local> Mime-Version: 1.0 (1.0) In-Reply-To: <20150129191507.GA30178@elstar.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <80040898-5DDF-42D8-ACCD-F2B92B763124@comcast.net> X-Mailer: iPhone Mail (11D257) From: Andrew Donati Date: Thu, 29 Jan 2015 20:56:52 -0500 To: Juergen Schoenwaelder DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1422583016; bh=vY6OiXxmFDce9sTWuuI05PoUKIuKV4ilZc2ZOBwSf9k=; h=Received:Received:Mime-Version:Content-Type:Message-Id:From: Subject:Date:To; b=EgfeLfehLo7YK1UGqxROFq44m1SteGvvsd5IX4wn3d+GmtAH3EdzlSvDK1NIG6W+K HORLCncuI46TLwO8HoC3uhq6b8QwODb06PWSLdb7Hds+2rhjetXd/P39FByJ3jValu mN9VJqD38QjyVvAFg0WurTHe8DD8rndd12so/NQ/JjJuvz6pUe1eHRFeLOhUp7myH1 T0HUI7Ilo2+CftQ+j5D1FwKDUiMvN6uHSqZf/mNVTupQd8oUh8lgtHkb80GbwbHyTU yxk8d/4j4RGRoUlw3ZdTpOX4SP/7s5S9oUgQ9NEhjPMm3FvVmNgf6Acx6UDHIYKOZw lyqbekT+e4nIQ== Archived-At: Cc: "draft-ietf-opsawg-vmm-mib@tools.ietf.org" , "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 30 Jan 2015 01:56:58 -0000 The implementation of hypervisors and virtual machines is increasing and the= re needs to be a way for administrators to view a dashboard on the status of= multiple machines. The implementation of this module will be very useful i= n meeting this need. In addition, this module also supports a rich set of n= otifications which is equally important. I believe this document will be widely used. -Andy > On Jan 29, 2015, at 2:15 PM, Juergen Schoenwaelder wrote: >=20 >> On Wed, Jan 28, 2015 at 06:40:48PM -0500, Warren Kumari wrote: >>=20 >> The WGLC has concluded with no feedback or comments, and so we have to >> conclude that the WG is no longer interested in this work. >>=20 >> Apologies to the authors, >=20 > Too bad, this document is actually useful and as far as I can tell > technically sound (but then I am co-author and hence this voice does > not count). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Jan 30 02:24:19 2015 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 4B2241A8AB4 for ; Fri, 30 Jan 2015 02:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Mxd6GGZj2rOj for ; Fri, 30 Jan 2015 02:24:15 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA191A8AB1 for ; Fri, 30 Jan 2015 02:24:14 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.65.19; Fri, 30 Jan 2015 10:23:50 +0000 Message-ID: <012f01d03c76$a5759b60$4001a8c0@gateway.2wire.net> From: t.petch To: References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> Date: Fri, 30 Jan 2015 10:21:37 +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: [81.151.167.59] X-ClientProxiedBy: DB4PR02CA0036.eurprd02.prod.outlook.com (10.242.174.164) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: bogus.com; dkim=none (message not signed) header.d=none;bogus.com; dmarc=none action=none header.from=btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 04724A515E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(51704005)(377454003)(51914003)(13464003)(19580405001)(19580395003)(2351001)(122386002)(84392001)(87976001)(23746002)(62236002)(44716002)(1556002)(86362001)(14496001)(61296003)(46102003)(47776003)(42186005)(66066001)(93886004)(92566002)(1456003)(50226001)(44736004)(76176999)(81816999)(81686999)(62966003)(40100003)(77096005)(50466002)(50986999)(116806002)(110136001)(33646002)(77156002)(230783001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2015 10:23:50.7426 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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, 30 Jan 2015 10:24:17 -0000 Joel One of the issues that I raise below on this I-D would benefit from AD guidance. The I-D adds entries to a registry established by RFC3411. Should the I-D then say that is updates RFC3411 or not? My experience is that some ADs say that this is NOT an update, while other ADs have said, at least in the past, that it IS an update. I would prefer that the I-D is in line with your thinking before it advances. Guidance please. The nearest parallel in the SNMP world is RFC3826 which added an snmpPrivProtocol to the registry also established by RFC3411, in June 2004, and which is not listed as updating any RFC. Tom Petch ----- Original Message ----- From: "Johannes Merkle" To: "t.petch" ; "Warren Kumari" Cc: ; "Scott Bradner" Sent: Thursday, January 29, 2015 8:03 AM > Tom, > > thanks for the thorough review. This really helps improving the document. > > > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a > > Normative reference. RFC6234 is not Standards Track but that is ok, it > > is already in the list of IESG permitted downrefs (does that need > > calling out at IETF Last Call?) > > You are right, but the question is whether I should rather use references [RFC2104] and [SHA] here. > > > > > s9.1 > > /apply the use /apply to the use / > > Right. > > > > > s9.2 > > is it the length of the key that gives it strength or its entropy? Is > > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 > > really stronger than > > !qaurk/99SS~ ? > > Strictly speaking, you are right, but it is common sense that cryptographic keys should have maximum entropy, i.e., they > should be selected uniformly at random from bit string of that length. Consequently, virtually all cryptographic papers > and text books use key the key length synonymous to its entropy. Thus, I consider this distinction as unnecessary. > > > > > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I think > > that s9.4 should reflect that (lest it confuses, or am I confused having > > missed an OBJECT somewhere?) > > Here I definitely need help, as I have no knowledge about MIBs. Actually, I copied that section from RFC 3411. Please > give advise what to write here or if this section is needed at all. > > > > The names used for the four protocols are not consistent within the > > document. Following RFC3414, I think that including Auth is correct. > > > oops, this escaped my attention. > > > Updates to this registry requires a Standards Track document which this > > is not. > > Wright. If the chairs agree, I'll change the track. > > > > > MIB Module copyright is 2004 > > opps again. Copy and paste error. > > > > > Does this document update RFC3414? It adds to the registry that that > > RFC created which some ADs say is NOT an update, some ADs say it IS an > > update; I think that we need guidance here (the update by RFC5590 of > > RFC3414 is a whole different ball game). > > I will wait for the guidance here. > > -- > Johannes From nobody Fri Jan 30 02:24:22 2015 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 AFD8D1A8AB1 for ; Fri, 30 Jan 2015 02:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 TH-OWVCMS1BX for ; Fri, 30 Jan 2015 02:24:15 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298F31A8AB3 for ; Fri, 30 Jan 2015 02:24:15 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.65.19; Fri, 30 Jan 2015 10:23:51 +0000 Message-ID: <013001d03c76$a5da50a0$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> Date: Fri, 30 Jan 2015 10:22:21 +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: [81.151.167.59] X-ClientProxiedBy: DB4PR02CA0036.eurprd02.prod.outlook.com (10.242.174.164) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 04724A515E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(51704005)(377454003)(51914003)(13464003)(19580405001)(19580395003)(122386002)(84392001)(87976001)(23746002)(62236002)(44716002)(1556002)(86362001)(14496001)(61296003)(46102003)(47776003)(42186005)(66066001)(93886004)(92566002)(1456003)(50226001)(44736004)(76176999)(81816999)(81686999)(62966003)(40100003)(77096005)(50466002)(50986999)(116806002)(110136001)(33646002)(77156002)(15975445007)(230783001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2015 10:23:51.3822 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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, 30 Jan 2015 10:24:17 -0000 Warren One of the points I raise below calls for input from the WG Chairs. The registry that is being updated http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xh tml#snmp-number-spaces-5 requires Standards Track for updating. The current I-D is Informational. This will hit a brick wall when it reaches IANA (I-d Advancement Not Admissible). Johannes wisely said that that he would look for the agreement of the chairs for this change. Do you agree? Tom Petch ----- Original Message ----- From: "Johannes Merkle" To: "t.petch" ; "Warren Kumari" Cc: ; "Scott Bradner" Sent: Thursday, January 29, 2015 8:03 AM > Tom, > > thanks for the thorough review. This really helps improving the document. > > > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a > > Normative reference. RFC6234 is not Standards Track but that is ok, it > > is already in the list of IESG permitted downrefs (does that need > > calling out at IETF Last Call?) > > You are right, but the question is whether I should rather use references [RFC2104] and [SHA] here. > > > > > s9.1 > > /apply the use /apply to the use / > > Right. > > > > > s9.2 > > is it the length of the key that gives it strength or its entropy? Is > > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 > > really stronger than > > !qaurk/99SS~ ? > > Strictly speaking, you are right, but it is common sense that cryptographic keys should have maximum entropy, i.e., they > should be selected uniformly at random from bit string of that length. Consequently, virtually all cryptographic papers > and text books use key the key length synonymous to its entropy. Thus, I consider this distinction as unnecessary. > > > > > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I think > > that s9.4 should reflect that (lest it confuses, or am I confused having > > missed an OBJECT somewhere?) > > Here I definitely need help, as I have no knowledge about MIBs. Actually, I copied that section from RFC 3411. Please > give advise what to write here or if this section is needed at all. > > > > The names used for the four protocols are not consistent within the > > document. Following RFC3414, I think that including Auth is correct. > > > oops, this escaped my attention. > > > Updates to this registry requires a Standards Track document which this > > is not. > > Wright. If the chairs agree, I'll change the track. > > > > > MIB Module copyright is 2004 > > opps again. Copy and paste error. > > > > > Does this document update RFC3414? It adds to the registry that that > > RFC created which some ADs say is NOT an update, some ADs say it IS an > > update; I think that we need guidance here (the update by RFC5590 of > > RFC3414 is a whole different ball game). > > I will wait for the guidance here. > > -- > Johannes From nobody Fri Jan 30 03:13:56 2015 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 D31391A8AED for ; Fri, 30 Jan 2015 03:13:55 -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, 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 Gz4OeAhnV5f4 for ; Fri, 30 Jan 2015 03:13:54 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDC61A8AE9 for ; Fri, 30 Jan 2015 03:13:53 -0800 (PST) Received: from Macintosh-6.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id mBDi1p0033vXPcr01BDk2r; Fri, 30 Jan 2015 12:13:51 +0100 Message-ID: <54CB6765.1080608@bwijnen.net> Date: Fri, 30 Jan 2015 12:13:41 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "t.petch" , joelja@bogus.com References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> <012f01d03c76$a5759b60$4001a8c0@gateway.2wire.net> In-Reply-To: <012f01d03c76$a5759b60$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.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, 30 Jan 2015 11:13:56 -0000 My personal view is that it does NOT update RFC3411. It adds an entry to a registry that we maintain at IANA, right? WHen other IANA-maintained registries get an entry added, then that also does not mean that some other RFC (That established the registry and that specified the rules for adding entries) gets updated either (I would hope). Bert On 30/01/15 11:21, t.petch wrote: > Joel > > One of the issues that I raise below on this I-D would benefit from AD > guidance. > > The I-D adds entries to a registry established by RFC3411. Should the > I-D then say that is updates RFC3411 or not? My experience is that some > ADs say that this is NOT an update, while other ADs have said, at least > in the past, that it IS an update. I would prefer that the I-D is in > line with your thinking before it advances. > > Guidance please. > > The nearest parallel in the SNMP world is RFC3826 which added an > snmpPrivProtocol to the registry also established by RFC3411, in June > 2004, and which is not listed as updating any RFC. > > Tom Petch > > ----- Original Message ----- > From: "Johannes Merkle" > To: "t.petch" ; "Warren Kumari" > Cc: ; "Scott Bradner" > Sent: Thursday, January 29, 2015 8:03 AM > >> Tom, >> >> thanks for the thorough review. This really helps improving the > document. >> >>> s4.2.1 step 2 uses RFC6234 in a way that I think must make it a >>> Normative reference. RFC6234 is not Standards Track but that is ok, > it >>> is already in the list of IESG permitted downrefs (does that need >>> calling out at IETF Last Call?) >> >> You are right, but the question is whether I should rather use > references [RFC2104] and [SHA] here. >> >>> >>> s9.1 >>> /apply the use /apply to the use / >> >> Right. >> >>> >>> s9.2 >>> is it the length of the key that gives it strength or its entropy? > Is >>> abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 >>> really stronger than >>> !qaurk/99SS~ ? >> >> Strictly speaking, you are right, but it is common sense that > cryptographic keys should have maximum entropy, i.e., they >> should be selected uniformly at random from bit string of that length. > Consequently, virtually all cryptographic papers >> and text books use key the key length synonymous to its entropy. Thus, > I consider this distinction as unnecessary. >> >>> >>> s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I > think >>> that s9.4 should reflect that (lest it confuses, or am I confused > having >>> missed an OBJECT somewhere?) >> >> Here I definitely need help, as I have no knowledge about MIBs. > Actually, I copied that section from RFC 3411. Please >> give advise what to write here or if this section is needed at all. >> >> >>> The names used for the four protocols are not consistent within the >>> document. Following RFC3414, I think that including Auth is > correct. >>> >> oops, this escaped my attention. >> >>> Updates to this registry requires a Standards Track document which > this >>> is not. >> >> Wright. If the chairs agree, I'll change the track. >> >>> >>> MIB Module copyright is 2004 >> >> opps again. Copy and paste error. >> >>> >>> Does this document update RFC3414? It adds to the registry that > that >>> RFC created which some ADs say is NOT an update, some ADs say it IS > an >>> update; I think that we need guidance here (the update by RFC5590 of >>> RFC3414 is a whole different ball game). >> >> I will wait for the guidance here. >> >> -- >> Johannes > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Fri Jan 30 07:31:15 2015 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 EBD861A1A3D for ; Fri, 30 Jan 2015 07:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, 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 nCB7R3pCWpyx for ; Fri, 30 Jan 2015 07:31:12 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 F0E521A90B2 for ; Fri, 30 Jan 2015 07:31:09 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id bs8so3877291wib.3 for ; Fri, 30 Jan 2015 07:31:08 -0800 (PST) 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=cAanVgXc5ORN1Glxkcenf4wpulsCDUiDufQe0qeeY4U=; b=lGsGsznkCH2nqpjZeH9AdGvtAyapyPUDmLzVdEPtQ40KzhrqQiuPqrIypvA8JCKxq/ 3Xr1uDBNBbohNKbILkDb6gY44wcm7QNZF2DXMm7LJVQnWNxWG5TYp30PshMz+mUHUXyo e+OJADJn0xlrRAfJFlGe3GyN4LzcjEDgjhBQDVQxliUMV7kWAxGCtReMlN4BGXKY8Nfg WU53zgfXNc1YZeXg7W4NK/KfCZ0u9+4mIBQlxkdxE/AfJ/Lbs7R5wEggME/llJVvNyvR vwXx54BJTjeZqPFc+5LMus/ZVf1+0MVvAjM7N1tIXAjvfnq6CGadnPZjwMnIk4Mat4UV K1Cw== X-Gm-Message-State: ALoCoQmF/+pmRvZxmM3Lpx7mJm4Sg0WtRMjnfiRWQLA3kjbMpqpUQT8vmeUehCRqwHi/p1QSht1Q MIME-Version: 1.0 X-Received: by 10.180.76.133 with SMTP id k5mr5794612wiw.30.1422631868661; Fri, 30 Jan 2015 07:31:08 -0800 (PST) Received: by 10.194.158.231 with HTTP; Fri, 30 Jan 2015 07:31:08 -0800 (PST) In-Reply-To: References: <54A9B162.1040407@bogus.com> <1C56356A-A644-4E6E-AACF-D50183F467A4@nominum.com> <286FA72E-75AF-43D1-8A88-48E88BD625C2@nominum.com> <28C69FA7-F3D8-4681-8037-42D2A6B7C58F@nominum.com> <1CDD41DA-25A7-40D4-B1A7-EB78618E5DEE@nominum.com> <54C88320.8020705@bogus.com> <6BD93E37-BAE3-4D83-97BC-248DEFC0924D@nominum.com> Date: Fri, 30 Jan 2015 10:31:08 -0500 Message-ID: From: Warren Kumari To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ole Troan , "opsawg@ietf.org" Subject: Re: [OPSAWG] [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07 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, 30 Jan 2015 15:31:14 -0000 [ Top post ] The only change in -11 was to fix Olafur's affiliation.... I think that this is cooked / ready to go... W W On Wed, Jan 28, 2015 at 5:46 PM, Warren Kumari wrote: > On Wed, Jan 28, 2015 at 2:07 PM, Ted Lemon wrote: >> On Jan 28, 2015, at 2:02 PM, Warren Kumari wrote: >>> The reason I prefer this to "whatever finishes first" is that it is a >>> bit more deterministic and so easier to troubleshoot. I also don't >>> clients to connect to http:// one day, after an OS >>> upgrade, suddenly start connecting to http://. In theory >>> (and if the CP operators is sane) the == >>> , but... >> >> In practice it's always going to be RA-first, because DHCPv6 doesn't start until after RA. > > Oh. Huh. Yeah, that didn't occur to me :-P > >> And it's likely going to be non-deterministic whether it's RA-first or DHCPv4-first, rather than being a function of some implementation detail in the O.S. >> >> So I think Joel is right that there's no benefit to insisting on an ordering. > > I wasn't really *insisting*, more of a general statement ("If the > device gets different URIs (for example, via DHCPv6 and IPv6 RA) it > should try them in the following order: DHCPv4, DHCPv6, RA."), but > happy to remove that. > >> I think you should just say that the ordering is indeterminate, and if different mechanisms give non-equivalent answers, this is likely to cause operational problems in practice. > > Done! > "In order to support multiple "classes" of clients (e.g: IPv4 only, > IPv6 only with DHCPv6, IPv6 only with RA) the captive portal can > provide the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, IPv6 RA). > The captive portal operator should ensure that the URIs handed out are > equivalent to reduce the chance of operational problems." > > Version -10 posted. This is a nice, round number... > > W > >> > > > > -- > 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 -- 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 From nobody Fri Jan 30 12:50:15 2015 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 D9A401A8706; Fri, 30 Jan 2015 12:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 Nq6Vf2VOFy_P; Fri, 30 Jan 2015 12:50:07 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6401A8722; Fri, 30 Jan 2015 12:50:04 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id b6so38233621lbj.11; Fri, 30 Jan 2015 12:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=lYY9RJScyJhLe/MesJfm7xUe/xNEdTn6p0K4Ee53XN8=; b=dxOWJajW58mEX2mctYyDz8nLtGXnF06ud3xO4S3YwBpBrSh/vd3Fvww66k/1NQYGmH o9dnb/ZB7fQLB6AFX2SJsEkoUa1+WgrJ61WCKAGK6hNMUYcqqQJe6oe9sgTcj603RlJ3 ODFRZki0vVVBL1e2t7YmPFmd3dq78uUM/dkfgPmCClVzWhvjc4g3EJ4HH4j8hLLcc/dz v9vBSMRT/BUzmq0Sq+iGYz0O6NZAbcgyTB0vShY2nw9VBAY9Lb1jEChnVZAnZP0CkHtG VIlN7gBt3SOvZXvpGwZnJNbNVTUSmacGcICnTcZ2kaBnF4AE457dXf8vlhpj5OTosa0a fssA== MIME-Version: 1.0 X-Received: by 10.112.224.133 with SMTP id rc5mr4406223lbc.31.1422651002888; Fri, 30 Jan 2015 12:50:02 -0800 (PST) Received: by 10.152.1.6 with HTTP; Fri, 30 Jan 2015 12:50:02 -0800 (PST) Received: by 10.152.1.6 with HTTP; Fri, 30 Jan 2015 12:50:02 -0800 (PST) Date: Fri, 30 Jan 2015 14:50:02 -0600 Message-ID: From: Spencer Dawkins at IETF To: Tom Taylor Content-Type: multipart/alternative; boundary=001a11360522aaa9e8050de4bfac Archived-At: Cc: opsawg@ietf.org, behave@ietf.org Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-perrault-behave-natv2-mib-00.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, 30 Jan 2015 20:50:10 -0000 --001a11360522aaa9e8050de4bfac Content-Type: text/plain; charset=UTF-8 Hi, Tom, On Jan 18, 2015 9:57 PM, "Tom Taylor" wrote: > > Several months' work, almost done. A couple of sections need work, as indicated in the document, but there's lots to review including the complete MIB module definition. Tina was asking me about this draft - are you planning to have me send -00 to the IESG, or were you going to do another revision? Spencer, who thought he knew what the plan was, but ... :-) > This is a major rewrite from the draft-ietf-behave-nat-11 version of > NAT MIB. Reworking was needed to address all the issues outstanding against that document. I suppose the next step is to send out a series of messages walking through all the changes from > draft-ietf-behave-nat-11 and how they respond to the open issues. > > I look forward to any comments on the new document. > > Tom Taylor > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-perrault-behave-natv2-mib-00.txt > Date: Sun, 18 Jan 2015 19:45:03 -0800 > From: internet-drafts@ietf.org > .... > > A new version of I-D, draft-perrault-behave-natv2-mib-00.txt > has been successfully submitted by Tom Taylor and posted to the > IETF repository. > > Name: draft-perrault-behave-natv2-mib > Revision: 00 > Title: Definitions of Managed Objects for Network Address Translators (NAT) > Document date: 2015-01-18 > Group: Individual Submission > Pages: 80 > URL: http://www.ietf.org/internet-drafts/draft-perrault-behave-natv2-mib-00.txt > Status: https://datatracker.ietf.org/doc/draft-perrault-behave-natv2-mib/ > Htmlized: http://tools.ietf.org/html/draft-perrault-behave-natv2-mib-00 > > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for devices implementing the Network Address Translator (NAT) > function. The new MIB module defined in this document, NATV2-MIB, is > intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not > backwards compatible with NAT-MIB, for reasons given in the text of > this document. A companion document deprecates all objects in NAT- > MIB. NATV2-MIB can be used for monitoring of NAT instances on a > device capable of NAT function. Compliance levels are defined for > three application scenarios: basic NAT, pooled NAT, and carrier-grade > NAT (CGN). > > > > > > 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 > > > > --001a11360522aaa9e8050de4bfac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Tom,

On Jan 18, 2015 9:57 PM, "Tom Taylor" <tom.taylor.stds@gmail.com> wro= te:
>
> Several months' work, almost done. A couple of sections need work,= as indicated in the document, but there's lots to review including the= complete MIB module definition.

Tina was asking me about this draft - are you planning to ha= ve me send -00 to the IESG, or were you going to do another revision?

Spencer, who thought he knew what the plan was, but ... :-)<= /p>

> This is a major rewrite from the draft-ietf-behave-nat-= 11 version of
> NAT MIB. Reworking was needed to address all the issues outstanding ag= ainst that document. I suppose the next step is to send out a series of mes= sages walking through all the changes from
> draft-ietf-behave-nat-11 and how they respond to the open issues.
>
> I look forward to any comments on the new document.
>
> Tom Taylor
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-perrault-behave-natv2-mib-= 00.txt
> Date: Sun, 18 Jan 2015 19:45:03 -0800
> From: internet-drafts@ietf= .org
> ....
>
> A new version of I-D, draft-perrault-behave-natv2-mib-00.txt
> has been successfully submitted by Tom Taylor and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-perrault-behave-na= tv2-mib
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Definitions of Managed Object= s for Network Address Translators (NAT)
> Document date:=C2=A0 2015-01-18
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 80
> URL: http://www.ietf.org/internet-drafts/draft-perrault-be= have-natv2-mib-00.txt
> Status: https://datatracker.ietf.org/doc/draft-perrault-behave-natv= 2-mib/
> Htmlized: http://tools.ietf.org/html/draft-perrault-behave-natv2-mib-00=
>
>
> Abstract:
> =C2=A0 =C2=A0This memo defines a portion of the Management Information= Base (MIB)
> =C2=A0 =C2=A0for devices implementing the Network Address Translator (= NAT)
> =C2=A0 =C2=A0function.=C2=A0 The new MIB module defined in this docume= nt, NATV2-MIB, is
> =C2=A0 =C2=A0intended to replace module NAT-MIB (RFC 4008).=C2=A0 NATV= 2-MIB is not
> =C2=A0 =C2=A0backwards compatible with NAT-MIB, for reasons given in t= he text of
> =C2=A0 =C2=A0this document.=C2=A0 A companion document deprecates all = objects in NAT-
> =C2=A0 =C2=A0MIB.=C2=A0 NATV2-MIB can be used for monitoring of NAT in= stances on a
> =C2=A0 =C2=A0device capable of NAT function.=C2=A0 Compliance levels a= re defined for
> =C2=A0 =C2=A0three application scenarios: basic NAT, pooled NAT, and c= arrier-grade
> =C2=A0 =C2=A0NAT (CGN).
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>

--001a11360522aaa9e8050de4bfac-- From nobody Fri Jan 30 13:20:37 2015 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 6EF4D1A049A for ; Fri, 30 Jan 2015 13:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 zox_fL-5bNVh for ; Fri, 30 Jan 2015 13:20:28 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4501A8788 for ; Fri, 30 Jan 2015 13:20:15 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.65.19; Fri, 30 Jan 2015 21:16:28 +0000 Message-ID: <030b01d03cd1$d0f9af00$4001a8c0@gateway.2wire.net> From: t.petch To: "Bradner, Scott" References: <5913A524-6B63-41CF-9F26-5F6C740EEDEF@vmware.com> <031AA51A-F341-4BEB-926D-F5AE43C22CC2@harvard.edu> <01ef01d03bb1$0e575900$4001a8c0@gateway.2wire.net> <036001d03bf1$a26aa6c0$4001a8c0@gateway.2wire.net> Date: Fri, 30 Jan 2015 21:14:59 +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: [81.151.167.59] X-ClientProxiedBy: DB4PR02CA0030.eurprd02.prod.outlook.com (10.242.174.158) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: harvard.edu; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 04724A515E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(24454002)(36944003)(377454003)(54094003)(44736004)(81816999)(76176999)(1456003)(50226001)(77096005)(81686999)(23756003)(66066001)(42186005)(47776003)(93886004)(92566002)(77156002)(110136001)(33646002)(116806002)(230783001)(50466002)(40100003)(50986999)(62966003)(122386002)(84392001)(19580405001)(19580395003)(14496001)(62236002)(61296003)(46102003)(44716002)(87976001)(2171001)(1556002)(86362001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2015 21:16:28.3084 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib 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, 30 Jan 2015 21:20:30 -0000 ----- Original Message ----- From: "Bradner, Scott" To: "t.petch" Sent: Thursday, January 29, 2015 9:16 PM are you referring to the notes you sent back in may 2014? if not - please resend so we know what you are referring to thanks Scott sorry that I have confused you, I was only referring to draft-ietf-opsawg-hmac-sha-2-usm-snmp-00 as mentioned by Warren in the immediately preceding paragraph, so the comments I was referring to are those I have posted to the list this month. And I have since reposted the one which I think would benefit from AD input, to Joel, and the one that needs WG Chair input, to Warren, in the hope that that makes it clear(?) Tom Petch Scott > On Jan 29, 2015, at 1:30 PM, t.petch wrote: > > ----- Original Message ----- > From: "Warren Kumari" > To: "t.petch" > Sent: Thursday, January 29, 2015 4:05 PM > > >> On Thu, Jan 29, 2015 at 5:10 AM, t.petch wrote: >>> ----- Original Message ----- >>> From: "Bradner, Scott" >>> To: "Michael MacFaden" >>> Sent: Thursday, January 29, 2015 1:53 AM >>> >>>> no exact number but zero is not enough >>>> >>>> any intelligent input would be helpful >>> >>> Scott >>> >>> This is probably unintelligent, but that is how I am! It is/was on > my >>> list of things to progress but it comes below e.g. >>> draft-ietf-opsawg-hmac-sha-2-usm-snmp >>> which has had issues outstanding with it for nearly a year, during > which >>> the call for adoption took about four months. >> >> Yup, the CfA for this took a really long time, because we had 2 >> competing drafts, and delayed while waiting to see if the authors >> could merge them, which should take priority, etc. The WG -00 was >> posted on December 12th, the authors asked for LC on Jan 15th, and we >> said (on the 16th) that we'd like a bit more feedback and if we >> didn't, would try force the issue by going to WGLC. Sine then we've >> gotten review from one person - yourself. >> >> I have on my calendar (which you cannot see :-)): "Start WGLC on >> draft-ietf-opsawg-hmac-sha-2-usm-snmp-00 - Feb 2nd" > > Warren, > > but I have just raised several points, one of which needs AD input > (IMHO), another of which needs WG Chair input, and to embark on a WG LC > without clearing up these is, IMHO, likely to engender further confusion > e.g. that points already raised will be re-raised and a new one from > someone else will be lost in the noise. So for me, an I-D addressing > the points raised comes first, then WG LC and, of course, the Shepherd > write-up can only come after that, in, say, two months time. > > That is my, hatless, thinking. > > Meanwhile, I see other WG using tools to keep track of outstanding > issues etc and not progressing any faster - tools may help, they can > also hinder. > > Incidentally, I also see some WG chairs much more willing to abandon > I-Ds completely at the WG LC stage, when getting no support on the list > (as opposed to interpreting silence as no objections so on to AD review > and IETF LC). I wonder if a few more such instances would galvanise > action. > > Tom Petch > > >>> That is where the time >>> goes, checking, waiting, prodding, wondering, meandering off into >>> appsawg whose calls for adoption - despite adopting a leaky bucket >>> approach to adoption - seem even more fraught etc. >>> >>> So I have commented on this I-D in the past - I tend to read every > mib >>> module - but will not be doing so just yet. Perhaps when the > shepherd >>> write-up for >>> draft-ietf-opsawg-hmac-sha-2-usm-snmp >>> is complete, >> >> Ok, but there will not *be* a shepherd writeup until the WGLC for >> draft-ietf-opsawg-hmac-sha-2-usm-snmp is done, and there is consensus. >> >> We've been having a really hard time getting people to review and >> comment in OpsAWG, partly during discussions, but especially during LC >> - if folk have reviewed and provided feedback during the evolution of >> the documents it is still helpful to comment (even just to say that >> they still approve, and still think it is worth publishing) at LC. >> Because of the nature of OpsAWG we often end up with documents that >> are only of interest to a small subset of participants and / or are >> maintenance type documents, and so we often only have a small number >> of people participating, but calling consensus on a tiny number of >> reviews (and explaining this is writeups) is getting old... >> >> W >>> >>> Tom Petch >>> >>>> Scott >>>> >>>>> On Jan 28, 2015, at 7:03 PM, Michael MacFaden >>> wrote: >>>>> >>>>> Exactly how many folks need to speak up? >>>>> >>>>> We did have operator input on this work. >>>>> We can ping them to to send email >>>>> to the list... >>>>> >>>>> Mike >>>>> >>>>> >>>>> On Jan 28, 2015, at 3:54 PM, Scott O. Bradner > wrote: >>>>> >>>>>> which is too bad since I think the topic is a useful one >>>>>> >>>>>> but, as chairs, we are supposed to do things based on WG > consensus >>>>>> and if no one speaks up we have no way to know if there is >>> consensus >>>>>> one way or another >>>>> >>>>> > From nobody Fri Jan 30 15:33:27 2015 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 3A9C81A87AD; Fri, 30 Jan 2015 15:33:25 -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 gbrKh2iGAZlT; Fri, 30 Jan 2015 15:33:23 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302C01A87E6; Fri, 30 Jan 2015 15:33:15 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id ar1so6847034iec.13; Fri, 30 Jan 2015 15:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+KAJ4EwDint11bevk9igjVqPRg8YdoSwt/nh3AJb9Fc=; b=o8+4HnCz+nLhav07fhVN9U4ofx8m2Gqa6rC6wyQZYm3ebkKxw0jBi9grdpjcLJ+0cP oS3/mmBnUnpk76KU/OcvUFP04rT4TPDg3l7Z7r5W6n7uI9J2Wyw1XLPa7mQ7Cy7OohVm l6Xm06wPbPrA824PGiJPMIkbVDVSf27feb0nK7LwujYpMeQ0JCGpwCZDfo7YF9XebvSY 8OPskYclEXSiUVNtX3Lvly2PcNbJAG5KFJzydXise2u6j6J+VtFoOQUkeJ7HdM4n+FHo fKt36bS40Y1ZM978945nZGcx0QDRD+VXZOGMb1r5GLLqeSTVcnPTRf/IH6pd6ZCx3ZDZ GSZg== X-Received: by 10.43.19.134 with SMTP id qk6mr8748737icb.29.1422660794433; Fri, 30 Jan 2015 15:33:14 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-73-98.tor.primus.ca. [173.206.73.98]) by mx.google.com with ESMTPSA id n17sm2105163igi.2.2015.01.30.15.33.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jan 2015 15:33:13 -0800 (PST) Message-ID: <54CC14B8.1050900@gmail.com> Date: Fri, 30 Jan 2015 18:33:12 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Spencer Dawkins at IETF References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: opsawg@ietf.org, behave@ietf.org Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-perrault-behave-natv2-mib-00.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, 30 Jan 2015 23:33:25 -0000 I have to do another revision to add an Operational and Management Considerations section and update the Security Considerations section. I've been working through some other stuff, but this is next on my plate, I believe. Once I submit -01, it is ready to publish, subject to any review process you need to have happen first. So far I've had comments from Eleven Fuyu, who caught a couple of errors. Tom On 30/01/2015 3:50 PM, Spencer Dawkins at IETF wrote: > Hi, Tom, > > On Jan 18, 2015 9:57 PM, "Tom Taylor" wrote: >> >> Several months' work, almost done. A couple of sections need work, as > indicated in the document, but there's lots to review including the > complete MIB module definition. > > Tina was asking me about this draft - are you planning to have me send -00 > to the IESG, or were you going to do another revision? > > Spencer, who thought he knew what the plan was, but ... :-) > >> This is a major rewrite from the draft-ietf-behave-nat-11 version of >> NAT MIB. Reworking was needed to address all the issues outstanding > against that document. I suppose the next step is to send out a series of > messages walking through all the changes from >> draft-ietf-behave-nat-11 and how they respond to the open issues. >> >> I look forward to any comments on the new document. >> >> Tom Taylor >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for > draft-perrault-behave-natv2-mib-00.txt >> Date: Sun, 18 Jan 2015 19:45:03 -0800 >> From: internet-drafts@ietf.org >> .... >> >> A new version of I-D, draft-perrault-behave-natv2-mib-00.txt >> has been successfully submitted by Tom Taylor and posted to the >> IETF repository. >> >> Name: draft-perrault-behave-natv2-mib >> Revision: 00 >> Title: Definitions of Managed Objects for Network Address > Translators (NAT) >> Document date: 2015-01-18 >> Group: Individual Submission >> Pages: 80 >> URL: > http://www.ietf.org/internet-drafts/draft-perrault-behave-natv2-mib-00.txt >> Status: https://datatracker.ietf.org/doc/draft-perrault-behave-natv2-mib/ >> Htmlized: http://tools.ietf.org/html/draft-perrault-behave-natv2-mib-00 >> >> >> Abstract: >> This memo defines a portion of the Management Information Base (MIB) >> for devices implementing the Network Address Translator (NAT) >> function. The new MIB module defined in this document, NATV2-MIB, is >> intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not >> backwards compatible with NAT-MIB, for reasons given in the text of >> this document. A companion document deprecates all objects in NAT- >> MIB. NATV2-MIB can be used for monitoring of NAT instances on a >> device capable of NAT function. Compliance levels are defined for >> three application scenarios: basic NAT, pooled NAT, and carrier-grade >> NAT (CGN). >> ...