From nobody Tue Jun 2 20:42: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 3C6EE1B3361 for ; Tue, 2 Jun 2015 20:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] 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 6wYE2wNh1DOT for ; Tue, 2 Jun 2015 20:42:55 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD031B3366 for ; Tue, 2 Jun 2015 20:42:54 -0700 (PDT) Received: (qmail 8678 invoked from network); 2 Jun 2015 20:42:41 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Jun 2015 20:42:41 -0700 Date: Tue, 2 Jun 2015 20:42:41 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Bill Fenner In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: OPSAWG , IPV6 Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 03:42:56 -0000 Hello Bill, My guess would be that the only reason for not republishing these MIB modules as obsolete was the work involved, but since you have shouldered the burden, it seems to me like a good thing. That said, I am by no means sure that everyone would agree :-) As for venue, it seems to me that opsawg is arguably more appriate than 6man, so I have cc:'d that WG. I would like to make two small suggestions on the document itself: - please change the occurrences of "Deprecating this MIB" to "Obsoleting this MIB module" in the REVISION clauses (and if it's not too much trouble, try to hunt down any other occurrences of "this MIB", "these MIBs" etc. and change them to "this MIB module", "these MIB modules", and so on. - it seems that it would be a good idea to have the metadata for the four obsolete RFCs indicate that they are obsoleted by the RFCs containing the replacement MIB modules AND this document as well, changing section 7 to something substantive that would remain. Mike Heard On Mon, 1 Jun 2015, Bill Fenner wrote: > Hi, > > I've just published > https://tools.ietf.org/html/draft-fenner-ipv6-mibs-obsolete-00 , whose goal > is twofold: > > 1) Explicitly change the status of RFC2452 (IPV6-TCP-MIB), RFC2454 > (IPV6-UDP-MIB), RFC2465 (IPV6-TC, IPV6-MIB), and RFC2466 (IPV6-ICMP-MIB) to > Historic. They are currently Proposed Standard, Obsoleted by the newer > (2005) version-independent IP-MIB, UDP-MIB, TCP-MIB and IP-FORWARD-MIB. > (Oddly, RFC2454 is already Historic, but the others remain PS.) > > 2) Publish the MIBs with the "STATUS" field changed from "current" to > "obsolete". Many MIB repositories are simply populated from the newest RFC > containing a given MIB, so since the original RFCs with their "STATUS > current" remain in place, there is no signal when simply looking at the > MIBs that the IETF has moved in a different direction. > > The end goal is to make it more clear that the IP version independent MIBs > are the ones to use. > > Since the ipv6 wg published the IP version independent MIBs originally, I > thought that 6man would be an appropriate home for this update. > > Your thoughts and comments would be appreciated. > > Bill > > (While composing this email, I realized that I accidentally omitted RFC2466 > from the list in the document; I'll fix this before the next revision.) > From nobody Wed Jun 3 03:12: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 341F11A0146; Wed, 3 Jun 2015 03:12:30 -0700 (PDT) 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 TZRiGhhbw1Br; Wed, 3 Jun 2015 03:12:27 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD0F1A0141; Wed, 3 Jun 2015 03:12:26 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.162.168) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.184.17; Wed, 3 Jun 2015 10:12:10 +0000 Message-ID: <012d01d09de5$6a770140$4001a8c0@gateway.2wire.net> From: t.petch To: "C. M. Heard" , Bill Fenner References: Date: Wed, 3 Jun 2015 11:07:54 +0100 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.162.168] X-ClientProxiedBy: AM3PR03CA024.eurprd03.prod.outlook.com (10.141.191.152) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DBXPR07MB062; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB062; X-Forefront-PRVS: 05961EBAFC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(199003)(13464003)(24454002)(51444003)(189002)(14496001)(76176999)(50226001)(105586002)(81816999)(44716002)(19580405001)(189998001)(44736004)(42186005)(33646002)(19580395003)(61296003)(66066001)(64706001)(47776003)(116806002)(81686999)(50986999)(5001960100002)(87976001)(62236002)(1556002)(122386002)(40100003)(62966003)(77156002)(1456003)(5001860100001)(5001830100001)(84392001)(101416001)(86362001)(77096005)(15975445007)(92566002)(106356001)(50466002)(46102003)(68736005)(23756003)(4001540100001)(5001770100001)(97736004)(81156007)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2015 10:12:10.3497 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062 Archived-At: Cc: OPSAWG , IPV6 Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 10:12:30 -0000 ---- Original Message ----- From: "C. M. Heard" To: "Bill Fenner" Cc: "OPSAWG" ; "IPV6" Sent: Wednesday, June 03, 2015 4:42 AM > Hello Bill, > > My guess would be that the only reason for not republishing these > MIB modules as obsolete was the work involved, but since you have > shouldered the burden, it seems to me like a good thing. That said, > I am by no means sure that everyone would agree :-) > > As for venue, it seems to me that opsawg is arguably more appriate > than 6man, so I have cc:'d that WG. > > I would like to make two small suggestions on the document itself: > > - please change the occurrences of "Deprecating this MIB" to > "Obsoleting this MIB module" in the REVISION clauses (and if it's > not too much trouble, try to hunt down any other occurrences of > "this MIB", "these MIBs" etc. and change them to "this MIB > module", "these MIB modules", and so on. > > - it seems that it would be a good idea to have the metadata for the > four obsolete RFCs indicate that they are obsoleted by the RFCs > containing the replacement MIB modules AND this document as well, > changing section 7 to something substantive that would remain. Bill I am not a fan of this work. I think that it will cost more than it benefits. The RFC long predate RFC4181, or indeed our guidelines for RFC in general, so you are committing e.g. to tracking down the authors and updating their contact details, into splitting the references into Normative and Informative etc etc. The change of status may be a single bulk edit but it changes many many lines in the module with the scope for introducing errors. And any MIB Module is expensive in terms of IETF effort needed for review by MIB Doctor, at Last Call, by ADs etc. So by all means change the status of the RFC but open up a MIB Module, no, not worth is. Tom Petch > Mike Heard > > On Mon, 1 Jun 2015, Bill Fenner wrote: > > Hi, > > > > I've just published > > https://tools.ietf.org/html/draft-fenner-ipv6-mibs-obsolete-00 , whose goal > > is twofold: > > > > 1) Explicitly change the status of RFC2452 (IPV6-TCP-MIB), RFC2454 > > (IPV6-UDP-MIB), RFC2465 (IPV6-TC, IPV6-MIB), and RFC2466 (IPV6-ICMP-MIB) to > > Historic. They are currently Proposed Standard, Obsoleted by the newer > > (2005) version-independent IP-MIB, UDP-MIB, TCP-MIB and IP-FORWARD-MIB. > > (Oddly, RFC2454 is already Historic, but the others remain PS.) > > > > 2) Publish the MIBs with the "STATUS" field changed from "current" to > > "obsolete". Many MIB repositories are simply populated from the newest RFC > > containing a given MIB, so since the original RFCs with their "STATUS > > current" remain in place, there is no signal when simply looking at the > > MIBs that the IETF has moved in a different direction. > > > > The end goal is to make it more clear that the IP version independent MIBs > > are the ones to use. > > > > Since the ipv6 wg published the IP version independent MIBs originally, I > > thought that 6man would be an appropriate home for this update. > > > > Your thoughts and comments would be appreciated. > > > > Bill > > > > (While composing this email, I realized that I accidentally omitted RFC2466 > > from the list in the document; I'll fix this before the next revision.) > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Jun 3 11:12: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 AC9861A1A7E for ; Wed, 3 Jun 2015 11:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] 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 H-NDbYdnw-BX for ; Wed, 3 Jun 2015 11:12:31 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 273E31A1A66 for ; Wed, 3 Jun 2015 11:12:26 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so12530242lbc.1 for ; Wed, 03 Jun 2015 11:12:24 -0700 (PDT) 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=Nc9Dz5T/Cxsp3iYZRuAte3EBSCBqW/8QoXhOQkJWpZM=; b=I8eaiSU2WknA18djsXqNc/UeGkDQlIxYQtRYZ+wHtp3F0rWcx1/fNQ7lq/eussKI0B QPvteWa3EcmQwKoq9mRB0X1c0wVHtF++DG0AwT/MH7dbhqeVSObnrl//7D/53fMyGN1c 0S0HxKzQCqP4bxuFVqRVs12j0pZ/5LXhUrV1qGcJ+sRMLqwQKwv5cKdIbDKtnB56M+sE KvUi0GWlpeMQtkzYShXk36ZLmc57pblkjRMHgwW1xIAqLab7LUvPDJNx2wuIy/5w7fNs 8ppkNrMV773hdTZru6rD11ImbOgIsaYpj4B3hN2i0Oe8lA+fAMWAH5jdE9R8LJodMPbx WcRA== X-Gm-Message-State: ALoCoQl7H5j930Coxd8AAZplviU4X4Vm/m8sYkDQxR5aTER3lcv3JSrs/ObF0/bXUp274Gnm5Ma6 MIME-Version: 1.0 X-Received: by 10.152.29.195 with SMTP id m3mr31371476lah.118.1433355144569; Wed, 03 Jun 2015 11:12:24 -0700 (PDT) Received: by 10.25.206.145 with HTTP; Wed, 3 Jun 2015 11:12:24 -0700 (PDT) In-Reply-To: <012d01d09de5$6a770140$4001a8c0@gateway.2wire.net> References: <012d01d09de5$6a770140$4001a8c0@gateway.2wire.net> Date: Wed, 3 Jun 2015 11:12:24 -0700 Message-ID: From: Bill Fenner To: "t.petch" Content-Type: multipart/alternative; boundary=089e0158c8d63abc740517a100c3 Archived-At: Cc: "C. M. Heard" , OPSAWG , IPV6 Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 18:12:32 -0000 --089e0158c8d63abc740517a100c3 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 3:07 AM, t.petch wrote: > The RFC long predate RFC4181, or indeed our guidelines for RFC in > general, so you are committing e.g. to tracking down the authors and > updating their contact details, into splitting the references into > Normative and Informative etc etc. > No, I am not proposing republishing these RFCs. I am proposing republishing the modules, with a simple wrapper saying why, in a single document. See https://tools.ietf.org/html/draft-fenner-ipv6-mibs-obsolete, which contains all the modules I mentioned, with the STATUS changed to "obsolete" and the DESCRIPTION updated with an explanation as required by RFC2578. The change of status may be a single bulk edit but it changes many many > lines in the module with the scope for introducing errors. > I have re-extracted the modules from my I-D and run "smilint" against them, and it reports no errors (other than those in the original modules). I also have reviewed the diffs that I created and published at http://fenner.github.io/ipv6-mibs-historic/ to try to catch any unintentional changes. > And any MIB Module is expensive in terms of IETF effort needed for > review by MIB Doctor, at Last Call, by ADs etc. > How much review is needed for "change status of this object to obsolete and update the DESCRIPTION"? The rules about making sure that MIBs are good ideas to implement presumably don't apply to objects whose metadata says "do not implement this object". Bill --089e0158c8d63abc740517a100c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 3, 2015 at 3:07 AM, t.petch <ietfc@btconnect.com> = wrote:
The RFC long predate RFC4181, or indeed our guid= elines for RFC in
general, so you are committing e.g. to tracking down the authors and
updating their contact details, into splitting the references into
Normative and Informative etc etc.

No, = I am not proposing republishing these RFCs.=C2=A0 I am proposing republishi= ng the modules, with a simple wrapper saying why, in a single document.

See https://tools.ietf.org/html/draft-fenner-ipv6-mibs-o= bsolete, which contains all the modules I mentioned, with the STATUS ch= anged to "obsolete" and the DESCRIPTION updated with an explanati= on as required by RFC2578.

The change of status may be a single bulk edit but it changes many many
lines in the module with the scope for introducing errors.
=

I have re-extracted the modules from my I-D and run &qu= ot;smilint" against them, and it reports no errors (other than those i= n the original modules).=C2=A0 I also have reviewed the diffs that I create= d and published at = http://fenner.github.io/ipv6-mibs-historic/ to try to catch any uninten= tional changes.
=C2=A0
And any MIB Module is expensive in terms of IETF effort needed for
review by MIB Doctor, at Last Call, by ADs etc.

How much review is needed for "change status of this object t= o obsolete and update the DESCRIPTION"?=C2=A0 The rules about making s= ure that MIBs are good ideas to implement presumably don't apply to obj= ects whose metadata says "do not implement this object".

=C2=A0 Bill

--089e0158c8d63abc740517a100c3-- From nobody Wed Jun 3 12:36:44 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 525DE1A8756 for ; Wed, 3 Jun 2015 12:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 uQUsVsQBYRX1 for ; Wed, 3 Jun 2015 12:36:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 E353E1A877B for ; Wed, 3 Jun 2015 12:36:40 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so13920884lbc.1 for ; Wed, 03 Jun 2015 12:36:39 -0700 (PDT) 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=y9rbjdVHT2L7rKMYBsYlvq8uKwCVE8zyJdRfrjHOxO4=; b=YvZEcbeoiHDei5OPWRS95vkNcXWQuqocPf8fmUUDZSYdxn7LdetdGVuk6YMCvjOXqw 8J/oB6lVA8f7HKfgHNel0hAbxIHOWrDn143ui6WieQkh4BVeJo0qRLq278g3HpIzunJY HCx3Ps8GuCDFQxQuBW/K2bN1ajHI2zS3UHdPja7O99rg3H5XI+AWoUYXMgNNe8xjU1xD INCoGSB8Mi+PfvYkTiIAcuNoGlJg0nZ1SL59LJ4Kb89W1yJVtbo4+XPfJU1ALEH6M5cu A989roi4DNbvCpMc6Sh7Cres5A8A1H9vYb4qX/4C1LGhipvzo1fCGX3vJ9Tw1qaxqjl5 DPrQ== X-Gm-Message-State: ALoCoQkrIYO5uQgbm0lWVOZNVjgFXNUh9lDdH4rHWY1Rmpt6lF/9SkftTVmRQGhGlWLLG4/Bixq/ MIME-Version: 1.0 X-Received: by 10.112.137.232 with SMTP id ql8mr8710369lbb.121.1433360198175; Wed, 03 Jun 2015 12:36:38 -0700 (PDT) Received: by 10.25.206.145 with HTTP; Wed, 3 Jun 2015 12:36:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jun 2015 12:36:38 -0700 Message-ID: From: Bill Fenner To: "C. M. Heard" Content-Type: multipart/alternative; boundary=089e01176f0b72a1c80517a22d19 Archived-At: Cc: OPSAWG , IPV6 Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 19:36:42 -0000 --089e01176f0b72a1c80517a22d19 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 2, 2015 at 8:42 PM, C. M. Heard wrote: > My guess would be that the only reason for not republishing these > MIB modules as obsolete was the work involved, but since you have > shouldered the burden, it seems to me like a good thing. That was my hope :-) > That said, > I am by no means sure that everyone would agree :-) > > As for venue, it seems to me that opsawg is arguably more appriate > than 6man, so I have cc:'d that WG. > Thanks; that hadn't occurred to me. I would like to make two small suggestions on the document itself: > > - please change the occurrences of "Deprecating this MIB" to > "Obsoleting this MIB module" in the REVISION clauses (and if it's > not too much trouble, try to hunt down any other occurrences of > "this MIB", "these MIBs" etc. and change them to "this MIB > module", "these MIB modules", and so on. > Sure, thanks for the correction. - it seems that it would be a good idea to have the metadata for the > four obsolete RFCs indicate that they are obsoleted by the RFCs > containing the replacement MIB modules AND this document as well, > changing section 7 to something substantive that would remain. > I'm fine with changing section 7 to something that would remain (I wrote it that way because I thought that we would have a companion document for the reclassification, but I realized later that procedure is to be used when you *don't* have another document to use). However, are you sure it'd be useful for this document to be referred to in the RFC index for the historic RFCs? It seems like it'd just add a level of indirection, since this document says "go see the other RFC4xxx documents". Bill --089e01176f0b72a1c80517a22d19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 2, 2015 at 8:42 PM, C. M. Heard <heard@pobox.com> wrot= e:
My guess would be that the only reason= for not republishing these
MIB modules as obsolete was the work involved, but since you have
shouldered the burden, it seems to me like a good thing.
<= br>
That was my hope :-)
=C2=A0
=C2=A0 That said,
I am by no means sure that everyone would agree :-)

As for venue, it seems to me that opsawg is arguably more appriate
than 6man, so I have cc:'d that WG.

Thanks; that hadn't occurred to me.

I would like to make two small suggestions on the document itself:

- please change the occurrences of "Deprecating this MIB" to
=C2=A0 "Obsoleting this MIB module" in the REVISION clauses (and = if it's
=C2=A0 not too much trouble, try to hunt down any other occurrences of
=C2=A0 "this MIB", "these MIBs" etc. and change them to= "this MIB
=C2=A0 module", "these MIB modules", and so on.

Sure, thanks for the correction.

- it seems that it would be a good idea to have the metadata for the
=C2=A0 four obsolete RFCs indicate that they are obsoleted by the RFCs
=C2=A0 containing the replacement MIB modules AND this document as well, =C2=A0 changing section 7 to something substantive that would remain.

I'm fine with changing section 7 to some= thing that would remain (I wrote it that way because I thought that we woul= d have a companion document for the reclassification, but I realized later = that procedure is to be used when you *don't* have another document to = use).=C2=A0 However, are you sure it'd be useful for this document to b= e referred to in the RFC index for the historic RFCs?=C2=A0 It seems like i= t'd just add a level of indirection, since this document says "go = see the other RFC4xxx documents".

=C2=A0 Bill=

--089e01176f0b72a1c80517a22d19-- From nobody Wed Jun 3 12:40: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 A9E811ACC91 for ; Wed, 3 Jun 2015 12:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 ftPne_3yU_o5 for ; Wed, 3 Jun 2015 12:40:58 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7551A9051 for ; Wed, 3 Jun 2015 12:40:57 -0700 (PDT) Received: (qmail 12024 invoked from network); 3 Jun 2015 12:40:51 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Jun 2015 12:40:51 -0700 Date: Wed, 3 Jun 2015 12:40:51 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Bill Fenner In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: OPSAWG , IPV6 Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 19:40:58 -0000 On Wed, 3 Jun 2015, Bill Fenner wrote: > I'm fine with changing section 7 to something that would remain (I wrote it > that way because I thought that we would have a companion document for the > reclassification, but I realized later that procedure is to be used when > you *don't* have another document to use). However, are you sure it'd be > useful for this document to be referred to in the RFC index for the > historic RFCs? It seems like it'd just add a level of indirection, since > this document says "go see the other RFC4xxx documents". I think it would be useful, since it would allow the metadata to say or imply "go see RFCxxxx for the current version of these MIB modules." //cmh From nobody Thu Jun 4 07:18: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 A383B1B3518 for ; Thu, 4 Jun 2015 07:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 hYcYLje54SvJ for ; Thu, 4 Jun 2015 07:18:43 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2727D1B3515 for ; Thu, 4 Jun 2015 07:18:43 -0700 (PDT) Received: from AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) by AMSPR07MB179.eurprd07.prod.outlook.com (10.242.86.143) with Microsoft SMTP Server (TLS) id 15.1.184.17; Thu, 4 Jun 2015 14:16:55 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.162.168) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.1.184.17; Thu, 4 Jun 2015 14:16:55 +0000 Message-ID: <01e401d09ed0$c4d4a200$4001a8c0@gateway.2wire.net> From: t.petch To: Bill Fenner References: <012d01d09de5$6a770140$4001a8c0@gateway.2wire.net> Date: Thu, 4 Jun 2015 15:14:10 +0100 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.162.168] X-ClientProxiedBy: AM2PR08CA0023.eurprd08.prod.outlook.com (25.162.32.33) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB050; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB179; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:AMSPR07MB050; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB050; X-Forefront-PRVS: 0597911EE1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51704005)(13464003)(24454002)(377454003)(101416001)(40100003)(122386002)(81816999)(76176999)(50986999)(81686999)(61296003)(62966003)(77156002)(19580405001)(19580395003)(110136002)(189998001)(5001960100002)(68736005)(15975445007)(77096005)(92566002)(1456003)(87976001)(1556002)(42186005)(50466002)(23676002)(44716002)(62236002)(86362001)(47776003)(64706001)(84392001)(14496001)(50226001)(66066001)(44736004)(105586002)(93886004)(81156007)(5001860100001)(4001540100001)(97736004)(5001830100001)(46102003)(116806002)(33646002)(106356001)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB050; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2015 14:16:55.1737 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB050 X-OriginatorOrg: btconnect.com Archived-At: Cc: "C. M. Heard" , OPSAWG Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 14:18:45 -0000 ----- Original Message ----- From: "Bill Fenner" To: "t.petch" Cc: "C. M. Heard" ; "OPSAWG" ; "IPV6" Sent: Wednesday, June 03, 2015 7:12 PM > On Wed, Jun 3, 2015 at 3:07 AM, t.petch wrote: > > > The RFC long predate RFC4181, or indeed our guidelines for RFC in > > general, so you are committing e.g. to tracking down the authors and > > updating their contact details, into splitting the references into > > Normative and Informative etc etc. > No, I am not proposing republishing these RFCs. I am proposing > republishing the modules, with a simple wrapper saying why, in a single > document. > > See https://tools.ietf.org/html/draft-fenner-ipv6-mibs-obsolete, which > contains all the modules I mentioned, with the STATUS changed to "obsolete" > and the DESCRIPTION updated with an explanation as required by RFC2578. > > The change of status may be a single bulk edit but it changes many many > > lines in the module with the scope for introducing errors. > > > > I have re-extracted the modules from my I-D and run "smilint" against them, > and it reports no errors (other than those in the original modules). I > also have reviewed the diffs that I created and published at > http://fenner.github.io/ipv6-mibs-historic/ to try to catch any > unintentional changes. > > > And any MIB Module is expensive in terms of IETF effort needed for > > review by MIB Doctor, at Last Call, by ADs etc. > > > How much review is needed for "change status of this object to obsolete and > update the DESCRIPTION"? The rules about making sure that MIBs are good > ideas to implement presumably don't apply to objects whose metadata says > "do not implement this object". Mmm, I would not presume so. Publish a MIB Module in an RFC and I would assume that the rules for publishing MIB Modules apply, requiring someone to smilint them etc. Publish an RFC and again, there are processes that the IETF and IESG follow, which cost. Far simpler just to declare a status change of the RFC; no RFC needed. I did look at your I-D before my first post and, because it contains MIB Modules, would not be surprised to see a number of objections along the lines that it does not contain what is expected for an RFC containing a MIB Module. Tom Petch > Bill > From nobody Thu Jun 4 14:57: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 1CEA51ACC88 for ; Thu, 4 Jun 2015 14:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] 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 7odVapXsnwzZ for ; Thu, 4 Jun 2015 14:57:43 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 D18011AC82C for ; Thu, 4 Jun 2015 14:57:42 -0700 (PDT) Received: by laew7 with SMTP id w7so41550889lae.1 for ; Thu, 04 Jun 2015 14:57:41 -0700 (PDT) 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=V1OnmhQG8JFmbHOJ4PBvw+wRdj/ddYefdi8ZLiUXeXo=; b=YHRpXs1eMd4V1EdLhH7fBKo595jiSHOUuYR4TyRmV6InO2QRQcHupcIrr/+ry5J65g 89VnVHYIYQD8p22MMj3zguwdX+cyXjny9vrmLl1KMWhEH8i6H+aB6DGPyyhKtTsSBTd1 29OvVHr+3ofDlyLMceWgJNRFOaPiv3dVZpCxMoGzmS2Kzs0p8sIKkL0646Ih/d7JxYgq an3t1CUjV3aQkuCnnB67dmkyxhYVgW3CnpFeUT0bDRMRAr+pQiHaA+E3vBYdo00iOxML ZRswpPORqHcpxnKGBZPJAdXD6WMCVeO3r4SKUYEW7SFzedvQZ661TFLrqhJzNZp+NpZV xdVg== X-Gm-Message-State: ALoCoQm4To47AzsJ4KXBMG4cVJu3t7ciZA4idt+Lo0J9WyAQbRDEEr9oulbfIwLqcIwHwWcPtEz/ MIME-Version: 1.0 X-Received: by 10.112.156.231 with SMTP id wh7mr154463lbb.118.1433455061286; Thu, 04 Jun 2015 14:57:41 -0700 (PDT) Received: by 10.25.206.145 with HTTP; Thu, 4 Jun 2015 14:57:41 -0700 (PDT) In-Reply-To: <01e401d09ed0$c4d4a200$4001a8c0@gateway.2wire.net> References: <012d01d09de5$6a770140$4001a8c0@gateway.2wire.net> <01e401d09ed0$c4d4a200$4001a8c0@gateway.2wire.net> Date: Thu, 4 Jun 2015 14:57:41 -0700 Message-ID: From: Bill Fenner To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c260d2baece40517b843bf Archived-At: Cc: "C. M. Heard" , OPSAWG Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 21:57:44 -0000 --001a11c260d2baece40517b843bf Content-Type: text/plain; charset=UTF-8 On Thu, Jun 4, 2015 at 7:14 AM, t.petch wrote: > Far simpler just > to declare a status change of the RFC; no RFC needed. > But it doesn't address my primary problem: if you look at a MIB repository, you see a nice IPV6-MIB with lots of "STATUS current" objects, and you say "Ah, cool, here are all the objects I need to implement for IPv6!". I knew going into this effort that "just reclassify things as historic" would be one possible outcome, but I want to aim higher than that. Despite outward appearances, the IESG is not an inflexible automaton; I hope to be able to work with them to be able to come to agreement that this is a worthwhile endeavor and need not be subject to the significant scrutiny that a MIB module with implementable objects should be. The first step down that path is to publish my draft and say "this is what I'm thinking it'll look like". Bill --001a11c260d2baece40517b843bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 4, 2015 at 7:14 AM, t.petch <ietfc@btconnect.com> = wrote:
Far simpler just
to declare a status change of the RFC; no RFC needed.

But it doesn't address my primary problem: if you look at a = MIB repository, you see a nice IPV6-MIB with lots of "STATUS current&q= uot; objects, and you say "Ah, cool, here are all the objects I need t= o implement for IPv6!".=C2=A0 I knew going into this effort that "= ;just reclassify things as historic" would be one possible outcome, bu= t I want to aim higher than that.

Despite outward appearances, the IESG is not an= inflexible automaton; I hope to be able to work with them to be able to co= me to agreement that this is a worthwhile endeavor and need not be subject = to the significant scrutiny that a MIB module with implementable objects sh= ould be.=C2=A0 The first step down that path is to publish my draft and say= "this is what I'm thinking it'll look like".

=C2=A0 Bill
=

--001a11c260d2baece40517b843bf-- From nobody Thu Jun 4 15:29: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 09D561A1A9A for ; Thu, 4 Jun 2015 15:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, 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 dtHFQtzQAYG1 for ; Thu, 4 Jun 2015 15:29:42 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6457E1A1A91 for ; Thu, 4 Jun 2015 15:29:42 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-05v.sys.comcast.net with comcast id cNVS1q0032D5gil01NVhsi; Thu, 04 Jun 2015 22:29:41 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-ch2-06v.sys.comcast.net with comcast id cNVg1q00U2yZEBF01NVgbn; Thu, 04 Jun 2015 22:29:41 +0000 From: "ietfdbh" To: "'Bill Fenner'" , "'t.petch'" References: <012d01d09de5$6a770140$4001a8c0@gateway.2wire.net> <01e401d09ed0$c4d4a200$4001a8c0@gateway.2wire.net> In-Reply-To: Date: Thu, 4 Jun 2015 18:29:33 -0400 Message-ID: <060801d09f15$ef0312b0$cd093810$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0609_01D09EF4.67F2F950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJt5E4vBNJG2CNI7vFP2FXDwAvLtgI79WfJAvCvOjoCT0FVjgHZvHxtAWhEi52cDHFCUA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1433456981; bh=4PmzcqwYnEZBo/+77xbtM3kv5yVi+uXom33qaSCUe4s=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=W3BC0qCUTMO/fVozE04U+KcC7hj6NsZDMJAIuO4L1jQn287HLOjf+34ckmR9E9txb UGkFUYjXq97Hfnu6sbF4Yzi1rnqX56befw9xauKiuL3gwqGhFJizTxMPXpm/Q1pSYW y82DL8AQU70AzJMJfBdw6neirlITUm8vnBZGjxV1/2Enzf+lsc2oWnKhKl2N9ND6IL nI2yIxThiITD7E4o/+sAcWx3AzL+oApPWSQSBDDCK5TGMZB+YlRALzubpWEqIgQ5Pp darZ9S+lsezDSGNIMDB+2f8Nkca0UMyDqkPtDgne6+y5VX0OTD2h+9lSi2fqnQ0Ica fuWM9kZIf41XA== Archived-At: Cc: "'C. M. Heard'" , 'OPSAWG' Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 22:29:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0609_01D09EF4.67F2F950 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 As a MIB Doctor, and one who just worked with the Behave WG=E2=80=99s = document to deprecate/obsolete the old NAT-MIB, I think it would be = fairly simple to get Bill=E2=80=99s proposed changes through the = process. As long as the only thing changing in the MIB is the status of = the objects, that should be a slam dunk. =20 Publishing a new RFC has a few new wrinkles, mostly the legal stuff like = copyright and permission from the original authors. But that should be = fairly simple. =20 Just changing the status of the RFC really is not the right way to = obsolete a MIB module, because MIB modules often are published separate = from the RFC, and when a MIB module is imported into an NMS, the whole = RFC is not imported, just the MIB module. It could be helpful to = operators to see the current status of the relevant objects, which = doesn=E2=80=99t happen in an NMS by re-categorizing the status of the = RFC. =20 David Harrington ietfdbh@comcast.net +1-603-828-1401 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Bill Fenner Sent: Thursday, June 04, 2015 5:58 PM To: t.petch Cc: C. M. Heard; OPSAWG Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs =20 On Thu, Jun 4, 2015 at 7:14 AM, t.petch wrote: Far simpler just to declare a status change of the RFC; no RFC needed. But it doesn't address my primary problem: if you look at a MIB = repository, you see a nice IPV6-MIB with lots of "STATUS current" = objects, and you say "Ah, cool, here are all the objects I need to = implement for IPv6!". I knew going into this effort that "just = reclassify things as historic" would be one possible outcome, but I want = to aim higher than that. =20 Despite outward appearances, the IESG is not an inflexible automaton; I = hope to be able to work with them to be able to come to agreement that = this is a worthwhile endeavor and need not be subject to the significant = scrutiny that a MIB module with implementable objects should be. The = first step down that path is to publish my draft and say "this is what = I'm thinking it'll look like". =20 Bill =20 ------=_NextPart_000_0609_01D09EF4.67F2F950 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

As a MIB Doctor, and one who just worked with the Behave WG=E2=80=99s = document to deprecate/obsolete the old NAT-MIB, I think it would be = fairly simple to get Bill=E2=80=99s proposed changes through the = process. As long as the only thing changing in the MIB is the status of = the objects, that should be a slam dunk.

 

Publishing a new RFC has a few new wrinkles, mostly the legal stuff = like copyright and permission from the original authors. But that should = be fairly simple.

 

Just changing the status of the RFC really is not the right way to = obsolete a MIB module, because MIB modules often are published separate = from the RFC, and when a MIB module is imported into an NMS, the whole = RFC is not imported, just the MIB module. It could be helpful to = operators to see the current status of the relevant objects, which = doesn=E2=80=99t happen in an NMS by re-categorizing the status of the = RFC.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Bill = Fenner
Sent: Thursday, June 04, 2015 5:58 PM
To: = t.petch
Cc: C. M. Heard; OPSAWG
Subject: Re: = [OPSAWG] Cleaning up the state of IPv6 = MIBs

 

On Thu, Jun 4, 2015 at 7:14 AM, t.petch <ietfc@btconnect.com> wrote:

Far simpler just
to declare a status = change of the RFC; no RFC needed.


But it doesn't address my primary problem: if you = look at a MIB repository, you see a nice IPV6-MIB with lots of = "STATUS current" objects, and you say "Ah, cool, here are = all the objects I need to implement for IPv6!".  I knew going = into this effort that "just reclassify things as historic" = would be one possible outcome, but I want to aim higher than = that.

 

Despite outward appearances, the IESG is not an = inflexible automaton; I hope to be able to work with them to be able to = come to agreement that this is a worthwhile endeavor and need not be = subject to the significant scrutiny that a MIB module with implementable = objects should be.  The first step down that path is to publish my = draft and say "this is what I'm thinking it'll look = like".

 

  Bill

 

------=_NextPart_000_0609_01D09EF4.67F2F950-- From nobody Thu Jun 4 15:44: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 005551A87D4 for ; Thu, 4 Jun 2015 15:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 1NU4JUn4jz7i for ; Thu, 4 Jun 2015 15:44:40 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5186D1A877B for ; Thu, 4 Jun 2015 15:44:40 -0700 (PDT) Received: (qmail 26231 invoked from network); 4 Jun 2015 15:44:30 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jun 2015 15:44:30 -0700 Date: Thu, 4 Jun 2015 15:44:30 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: ietfdbh In-Reply-To: <060801d09f15$ef0312b0$cd093810$@comcast.net> Message-ID: References: <012d01d09de5$6a770140$4001a8c0@gateway.2wire.net> <01e401d09ed0$c4d4a200$4001a8c0@gateway.2wire.net> <060801d09f15$ef0312b0$cd093810$@comcast.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-242500751-1433457870=:19499" Archived-At: Cc: 'Bill Fenner' , 'OPSAWG' Subject: Re: [OPSAWG] Cleaning up the state of IPv6 MIBs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 22:44:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---2133786286-242500751-1433457870=:19499 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 4 Jun 2015, ietfdbh wrote: > Just changing the status of the RFC really is not the right way to > obsolete a MIB module, because MIB modules often are published > separate from the RFC, and when a MIB module is imported into an > NMS, the whole RFC is not imported, just the MIB module. It could > be helpful to operators to see the current status of the relevant > objects, which doesnÿÿt happen in an NMS by re-categorizing the > status of the RFC. Exactly. //cmh ---2133786286-242500751-1433457870=:19499-- From nobody Fri Jun 12 00:23: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 8C4B11A874B for ; Fri, 12 Jun 2015 00:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.004 X-Spam-Level: X-Spam-Status: No, score=-13.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, 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 LETYT20c2G57 for ; Fri, 12 Jun 2015 00:23:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7551A6FFC for ; Fri, 12 Jun 2015 00:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1587; q=dns/txt; s=iport; t=1434093823; x=1435303423; h=from:to:cc:subject:date:message-id:mime-version; bh=7s2p+upPBxklPYq1lrL0biBB4s7+HziDngv/RN8cZYs=; b=HWrPkWmdIeLqr3mFR64FSC2ojPr//LkhurOqlP/eZr+ZXnkgBE73BSzh 8sWjfDHsUOSq5eliXuau19Dl+86FGisinRuavlEHciBtvgTwVqgRnMe8I hWLM5pUO5oM7YnFjCOpN8kCfben+YqPqYp47imyr5a/EFq1///QwTR2Lk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiBACqiHpV/4cNJK1cgkVLgTm9XgmHW4FEOBQBAQEBAQEBdhSEGQwEeRIBCwF0JwQOiDTVVQEBAQEGAQEBAQEBARuQSYQ0BZEEglCLOI0fimMkY4MWgjWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,600,1427760000"; d="scan'208,217";a="1001002" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP; 12 Jun 2015 07:23:41 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5C7NfVR005424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jun 2015 07:23:41 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 12 Jun 2015 02:23:41 -0500 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: TACACS+ RFC Thread-Index: AQHQpOC0bfYSFaxNP0e8F7BNyOSwhg== Date: Fri, 12 Jun 2015 07:23:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.55.255.66] Content-Type: multipart/alternative; boundary="_000_D1A0478969633dcmgashciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Michael Keenan \(mikeenan\)" , "John Delaney \(jodelane\)" , Andrej Ota , Thorsten Dahm Subject: [OPSAWG] TACACS+ RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 07:23:45 -0000 --_000_D1A0478969633dcmgashciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, TACACS+ is a protocol widely deployed, based upon a draft specification tha= t Cisco submitted in 1998, but never completed to RFC status. The original = draft has been tidied and lightly enhanced and resubmitted, with the intent= to finally get it published as a standard. The best fit that we could see was for the opsawg. Many thanks, Regards, Doug. --_000_D1A0478969633dcmgashciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0D7BAEF66C72DE4FBF0EA4D2266800A9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

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

The best fit that we could see was for the opsawg.

Many thanks,

Regards,

Doug.
--_000_D1A0478969633dcmgashciscocom_-- From nobody Fri Jun 12 02:19:40 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 86DEE1A8A67 for ; Fri, 12 Jun 2015 02:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_JvUy-wHFus for ; Fri, 12 Jun 2015 02:19:35 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603C21A8A6A for ; Fri, 12 Jun 2015 02:19:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 69FA21836B4; Fri, 12 Jun 2015 05:19:33 -0400 (EDT) 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 KqwRy3JKpJi3; Fri, 12 Jun 2015 05:19:32 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 903111836A9; Fri, 12 Jun 2015 05:19:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Scott O. Bradner" In-Reply-To: Date: Fri, 12 Jun 2015 05:19:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <86CF0797-D301-43F2-90D4-A08953209F32@sobco.com> References: To: "Douglas Gash (dcmgash)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "John Delaney \(jodelane\)" , "opsawg@ietf.org" , "Michael Keenan \(mikeenan\)" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 09:19:39 -0000 please resubmit this draft under your name - e.g.,=20 draft-delaney-opsawg-tacacs Only documents that have been formally accepted by a WG to be a WG = document can use the draft-wg_name type of name we can have a discussion on the ID after you resubmit under your = own name to see if the WG supports adopting it and it fits in our charter (if it does not fit in the = charter we word have to discuss revising the charter with our ADs and with the IESG) Scot > On Jun 12, 2015, at 3:23 AM, Douglas Gash (dcmgash) = wrote: >=20 > Hi, >=20 > TACACS+ is a protocol widely deployed, based upon a draft = specification that Cisco submitted in 1998, but never completed to RFC = status. The original draft has been tidied and lightly enhanced and = resubmitted, with the intent to finally get it published as a standard. >=20 > The best fit that we could see was for the opsawg. >=20 > Many thanks, >=20 > Regards, >=20 > Doug. > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Jun 12 02:45: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 AAC681A8AC5 for ; Fri, 12 Jun 2015 02:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_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 ATDA6yniMayT for ; Fri, 12 Jun 2015 02:45:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E291A8ABF for ; Fri, 12 Jun 2015 02:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1266; q=dns/txt; s=iport; t=1434102336; x=1435311936; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iFXpL+gZvSnqDX/4H8cLst8Ywx6dUpPj7UxazGfaF8s=; b=KqZx8XZvGVxUadIAGAvVdPoZLQvZCIt7A/pCzfSK9U6E8KQVj2RpU9Zn BI/5C8pcXUxPo2Gl2bdZ8kYCbF40adnMrnp+8ICT5ZppDQygDfKNxYMdl VNbKa7eKN6bNhqXF7AzPGqqnclRcVYZKs82zevMCIeUi7dvfbkwgHx1Af 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmBACKqXpV/4YNJK1cgxBUXwa9XwmBVwqFMEoCgUY4FAEBAQEBAQGBCoQjAQEEAQEBNzQLEAIBCDYQJwslAgQOBYgvDdVfAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLQ4UGB4QtBYt5h1uLOIEwhACOd4NbJGODFm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,601,1427760000"; d="scan'208";a="6669137" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 12 Jun 2015 09:45:36 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5C9jai4031529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jun 2015 09:45:36 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 12 Jun 2015 04:45:36 -0500 From: "Douglas Gash (dcmgash)" To: "Scott O. Bradner" Thread-Topic: [OPSAWG] TACACS+ RFC Thread-Index: AQHQpOC0bfYSFaxNP0e8F7BNyOSwhp2o69gAgAAYCIA= Date: Fri, 12 Jun 2015 09:45:35 +0000 Message-ID: References: <86CF0797-D301-43F2-90D4-A08953209F32@sobco.com> In-Reply-To: <86CF0797-D301-43F2-90D4-A08953209F32@sobco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.55.255.66] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C3309F95C17754388E32B6C140A2AAF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "John Delaney \(jodelane\)" , "opsawg@ietf.org" , "Michael Keenan \(mikeenan\)" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 09:45:41 -0000 Thanks Scott, Should I unsubmit the original? On 12/06/2015 10:19, "Scott O. Bradner" wrote: >please resubmit this draft under your name - e.g., > > draft-delaney-opsawg-tacacs > >Only documents that have been formally accepted by a WG to be a WG >document can use the draft-wg_name type of name > > we can have a discussion on the ID after you resubmit under your own >name to see if the WG supports >adopting it and it fits in our charter (if it does not fit in the charter >we word have to discuss revising the >charter with our ADs and with the IESG) > >Scot > >> On Jun 12, 2015, at 3:23 AM, Douglas Gash (dcmgash) >>wrote: >>=20 >> Hi, >>=20 >> TACACS+ is a protocol widely deployed, based upon a draft specification >>that Cisco submitted in 1998, but never completed to RFC status. The >>original draft has been tidied and lightly enhanced and resubmitted, >>with the intent to finally get it published as a standard. >>=20 >> The best fit that we could see was for the opsawg. >>=20 >> Many thanks, >>=20 >> Regards, >>=20 >> Doug. >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > From nobody Fri Jun 12 02:48: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 129F61A8ABF for ; Fri, 12 Jun 2015 02:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M4D3qd_Og-G for ; Fri, 12 Jun 2015 02:47:56 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC901A8AD6 for ; Fri, 12 Jun 2015 02:47:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id DB6B2183926; Fri, 12 Jun 2015 05:47:54 -0400 (EDT) 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 DGeFGznOHCh9; Fri, 12 Jun 2015 05:47:54 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 5490018391B; Fri, 12 Jun 2015 05:47:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Scott O. Bradner" In-Reply-To: Date: Fri, 12 Jun 2015 05:47:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <404FC3A0-5AB9-4E04-9310-A62730EBAD28@sobco.com> References: <86CF0797-D301-43F2-90D4-A08953209F32@sobco.com> To: "Douglas Gash (dcmgash)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Michael Keenan \(mikeenan\)" , "opsawg@ietf.org" , "John Delaney \(jodelane\)" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 09:48:00 -0000 > On Jun 12, 2015, at 5:45 AM, Douglas Gash (dcmgash) = wrote: >=20 > Thanks Scott, >=20 > Should I unsubmit the original? yes if the cancelation I just did failed in some way Scott >=20 > On 12/06/2015 10:19, "Scott O. Bradner" wrote: >=20 >> please resubmit this draft under your name - e.g., >>=20 >> draft-delaney-opsawg-tacacs >>=20 >> Only documents that have been formally accepted by a WG to be a WG >> document can use the draft-wg_name type of name >>=20 >> we can have a discussion on the ID after you resubmit under your = own >> name to see if the WG supports >> adopting it and it fits in our charter (if it does not fit in the = charter >> we word have to discuss revising the >> charter with our ADs and with the IESG) >>=20 >> Scot >>=20 >>> On Jun 12, 2015, at 3:23 AM, Douglas Gash (dcmgash) = >>> wrote: >>>=20 >>> Hi, >>>=20 >>> TACACS+ is a protocol widely deployed, based upon a draft = specification >>> that Cisco submitted in 1998, but never completed to RFC status. The >>> original draft has been tidied and lightly enhanced and resubmitted, >>> with the intent to finally get it published as a standard. >>>=20 >>> The best fit that we could see was for the opsawg. >>>=20 >>> Many thanks, >>>=20 >>> Regards, >>>=20 >>> Doug. >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Jun 12 03:47: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 263AA1A907C for ; Fri, 12 Jun 2015 03:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_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 GnmIAYeVGfaJ for ; Fri, 12 Jun 2015 03:47:51 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52131A907B for ; Fri, 12 Jun 2015 03:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1858; q=dns/txt; s=iport; t=1434106071; x=1435315671; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ggg2oD6hxZuQ3UjzB7+jFrcEW+A+fVPSWz0qC13Kj8k=; b=Lu39xv9+/1VEjPmCzt9Zz9l4J/IRmM1D92KNLLIvZFjspJIqo2GDJU4L 5YAN0wai/mrDBiTNM1b2Ej2iELVUDgvVDn9il31UMLG/tiAnsy/dBH2gZ IfqZfw2FPvbFY2sTmenfZWJa4QAxbqBJeo6iC3k1YIoAute82J9XXfDh3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AoBAC/t3pV/4QNJK1cgxBUXwa9YgmBNSIKhTBKAoFHOBQBAQEBAQEBgQqEIgEBAQECAQEBATc0CxACAQgYHhAnCyUCBA4FiCcIDdVwAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLQ4UGB4QtBYt5hQuCUos8gTKEAY56g1smY4EoHIFSb4EDBD+BAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,601,1427760000"; d="scan'208";a="1039646" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 12 Jun 2015 10:47:50 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5CAloYu003171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jun 2015 10:47:50 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Fri, 12 Jun 2015 05:47:50 -0500 From: "Douglas Gash (dcmgash)" To: "Scott O. Bradner" Thread-Topic: [OPSAWG] TACACS+ RFC Thread-Index: AQHQpOC0bfYSFaxNP0e8F7BNyOSwhp2o69gAgAAYCID//+/lAIAAIYAA Date: Fri, 12 Jun 2015 10:47:50 +0000 Message-ID: References: <86CF0797-D301-43F2-90D4-A08953209F32@sobco.com> <404FC3A0-5AB9-4E04-9310-A62730EBAD28@sobco.com> In-Reply-To: <404FC3A0-5AB9-4E04-9310-A62730EBAD28@sobco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.55.255.66] Content-Type: text/plain; charset="us-ascii" Content-ID: <838AB7A96132A64081C85B34532715A8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Michael Keenan \(mikeenan\)" , "opsawg@ietf.org" , "John Delaney \(jodelane\)" , Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 10:47:53 -0000 Many Thanks Scott. Re-submitted. Regards, Doug On 12/06/2015 10:47, "Scott O. Bradner" wrote: > >> On Jun 12, 2015, at 5:45 AM, Douglas Gash (dcmgash) >>wrote: >>=20 >> Thanks Scott, >>=20 >> Should I unsubmit the original? > >yes if the cancelation I just did failed in some way > >Scott > >>=20 >> On 12/06/2015 10:19, "Scott O. Bradner" wrote: >>=20 >>> please resubmit this draft under your name - e.g., >>>=20 >>> draft-delaney-opsawg-tacacs >>>=20 >>> Only documents that have been formally accepted by a WG to be a WG >>> document can use the draft-wg_name type of name >>>=20 >>> we can have a discussion on the ID after you resubmit under your own >>> name to see if the WG supports >>> adopting it and it fits in our charter (if it does not fit in the >>>charter >>> we word have to discuss revising the >>> charter with our ADs and with the IESG) >>>=20 >>> Scot >>>=20 >>>> On Jun 12, 2015, at 3:23 AM, Douglas Gash (dcmgash) >>>> >>>> wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> TACACS+ is a protocol widely deployed, based upon a draft >>>>specification >>>> that Cisco submitted in 1998, but never completed to RFC status. The >>>> original draft has been tidied and lightly enhanced and resubmitted, >>>> with the intent to finally get it published as a standard. >>>>=20 >>>> The best fit that we could see was for the opsawg. >>>>=20 >>>> Many thanks, >>>>=20 >>>> Regards, >>>>=20 >>>> Doug. >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> OPSAWG@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsawg >>>=20 >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > From nobody Fri Jun 12 04:19: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 944981A904E for ; Fri, 12 Jun 2015 04:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 WUjpx--snArs for ; Fri, 12 Jun 2015 04:19:14 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9AE1A8AEA for ; Fri, 12 Jun 2015 04:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6657; q=dns/txt; s=iport; t=1434107953; x=1435317553; h=from:to:subject:date:message-id:mime-version; bh=1USSlScbrXuGoxUh23unKRsMz8UaTBzDbMz1mSmFsHc=; b=B/TBvK8w9XGus6DcpA99nxSY/Bfp0n9ufGn9m4lipVimHKuiZ10L0dui 8X6e1MShaNadWb0+T4L6XdWAlY5h4SEu74Ps8WXslQ43MmEykANSHNp2D w/VPnOZ8rmwMVFnFTPGUy04UbJFqCtxV/dhCJPKceqkGm2bR/ClNQyMes 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBADMvnpV/5hdJa1cgkVLgTMGvWQJh1uBSTgUAQEBAQEBAYEKhCIBAgEDchkBGQMBAig5FAkKBBOIL6FTtDsBCyCNAAGDN4RFBZEEglKLPIEyhAGHb4pmJmOBNYFhb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,601,1427760000"; d="scan'208,217";a="158793962" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 12 Jun 2015 11:19:13 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5CBJD9c021889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 12 Jun 2015 11:19:13 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.238]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 12 Jun 2015 06:19:12 -0500 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: TACACS+ RFC: Regarding submission Thread-Index: AQHQpQGbxfgfcV4DnUaXepkPf0DRUw== Date: Fri, 12 Jun 2015 11:19:11 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.55.255.66] Content-Type: multipart/alternative; boundary="_000_D1A07A3469BB3dcmgashciscocom_" MIME-Version: 1.0 Archived-At: Subject: [OPSAWG] TACACS+ RFC: Regarding submission X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 11:19:15 -0000 --_000_D1A07A3469BB3dcmgashciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please note the following concerning the document content: The majority of the document is a cleaned and tidied refresh of the origina= l draft. However, included in the document is a new feature that we propose for disc= ussion: Support for TLS using a new packet type allows the TACACS protocol = to upgrade itself to a TLS tunnel. Please see section 3.6.2. This is added = in a way that is intended not to interfere with any current implementations= of TACACS+. Also, a note in relation to TACACS+ and RADIUS. Although the protocols were= probably about equivalent in 1998, the addition of EAP and other enhanceme= nts mean that RADIUS is the default protocol for Network Access. By revivin= g the TACACS+ draft we have no intention of influencing this status quo. Ho= wever, TACACS+ does have a continued and widely deployed use case for Devic= e Administration. This is due to its strict separation of authorisation fro= m authentication which allows per-command authorisation, and its TCP transp= ort for allowing effective accounting. It is to support this use case that = TACACS+ is proposed for progress to a standard, and informed the thoughts f= or the potential selection of a workgroup, however if this selection is mis= guided, please let us know. Many thanks, Regards, Doug. From: Douglas Gash > Date: Friday, 12 June 2015 08:23 To: "opsawg@ietf.org" > Cc: Thorsten Dahm >= , Andrej Ota >, "Michael Keenan (mi= keenan)" >, "Satyanarayana Da= nda (sdanda)" >, "John Delaney (j= odelane)" > Subject: TACACS+ RFC Hi, TACACS+ is a protocol widely deployed, based upon a draft specification tha= t Cisco submitted in 1998, but never completed to RFC status. The original = draft has been tidied and lightly enhanced and resubmitted, with the intent= to finally get it published as a standard. The best fit that we could see was for the opsawg. Many thanks, Regards, Doug. --_000_D1A07A3469BB3dcmgashciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <04A574766F7FF448A8CE9C084B0847C7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Please note the following concerning the document content:

The majority of the document is a cleaned and tidied refresh of the or= iginal draft.
However, included in the document is a new feature that we propose for= discussion: Support for TLS using a new packet type allows the TACACS prot= ocol to upgrade itself to a TLS tunnel. Please see section 3.6.2. This is a= dded in a way that is intended not to interfere with any current implementations of TACACS+.

Also, a note in relation to TACACS+ and RADIUS. Although the proto= cols were probably about equivalent in 1998, the addition of EAP and other = enhancements mean that RADIUS is the default protocol for Network Access. B= y reviving the TACACS+ draft we have no intention of influencing this status quo. However, TACACS+ does hav= e a continued and widely deployed use case for Device Administration. This = is due to its strict separation of authorisation from authentication which = allows per-command authorisation, and its TCP transport for allowing effective accounting. It is to support this= use case that TACACS+ is proposed for progress to a standard, and info= rmed the thoughts for the potential selection of a workgroup, however if th= is selection is misguided, please let us know.

Many thanks,

Regards,

Doug.



From: Douglas Gash <dcmgash@cisco.com>
Date: Friday, 12 June 2015 08:23 To: "opsawg@ietf.org" <= opsawg@ietf.org>
Cc: Thorsten Dahm <thorstendlux@google.com>, Andrej Ota &= lt;aota@google.com>, "Michae= l Keenan (mikeenan)" <mikeena= n@cisco.com>, "Satyanarayana Danda (sdanda)" <sdanda@cisco.com>, "John Delaney (jodelane)" <jodelane@cisco.com>
Subject: TACACS+ RFC

Hi,

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

The best fit that we could see was for the opsawg.

Many thanks,

Regards,

Doug.
 --_000_D1A07A3469BB3dcmgashciscocom_-- From nobody Fri Jun 12 05:52: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 AFBE11A9111 for ; Fri, 12 Jun 2015 05:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 hjdEncVtcKkp for ; Fri, 12 Jun 2015 05:52:00 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFC71A9110 for ; Fri, 12 Jun 2015 05:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8638; q=dns/txt; s=iport; t=1434113520; x=1435323120; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=R/z33YYwPWkmGt3PzBkIBZ/QPNpE1rCcY9Z2xM9RS64=; b=RJ3ARORECCU7Uw5uv5QuIlfZc3UAwvIv3fS/cGsV4KGL7lx6YuMV0GUF w20V/oi9J3G8oDS/VxEHMcurnTR9XWHwI5mjCjxR08DNTAxMoOPdo1Bp3 pTATZMtxZYqaDeUeduDc6+PT+W4/b9MwjAuoF1YSCxfc7I4Sznd1C7SW3 E=; X-IronPort-AV: E=Sophos;i="5.13,602,1427760000"; d="scan'208,217";a="541267395" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 12 Jun 2015 12:51:58 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5CCpw4S029348; Fri, 12 Jun 2015 12:51:58 GMT Message-ID: <557AD5ED.3050003@cisco.com> Date: Fri, 12 Jun 2015 14:51:57 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Douglas Gash (dcmgash)" , "opsawg@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000406010200000707040801" Archived-At: Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 12:52:02 -0000 This is a multi-part message in MIME format. --------------000406010200000707040801 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit For information, the draft is at: http://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/ Regards, B; > Please note the following concerning the document content: > > The majority of the document is a cleaned and tidied refresh of the > original draft. > However, included in the document is a new feature that we propose for > discussion: Support for TLS using a new packet type allows the TACACS > protocol to upgrade itself to a TLS tunnel. Please see section 3.6.2. > This is added in a way that is intended not to interfere with any > current implementations of TACACS+. > > Also, a note in relation to TACACS+ and RADIUS. Although the protocols > were probably about equivalent in 1998, the addition of EAP and other > enhancements mean that RADIUS is the default protocol for Network > Access. By reviving the TACACS+ draft we have no intention of > influencing this status quo. However, TACACS+ does have a continued > and widely deployed use case for Device Administration. This is due to > its strict separation of authorisation from authentication which > allows per-command authorisation, and its TCP transport for allowing > effective accounting. It is to support this use case that TACACS+ is > proposed for progress to a standard, and informed the thoughts for the > potential selection of a workgroup, however if this selection is > misguided, please let us know. > > Many thanks, > > Regards, > > Doug. > > > > From: Douglas Gash > > Date: Friday, 12 June 2015 08:23 > To: "opsawg@ietf.org " > > Cc: Thorsten Dahm >, Andrej Ota >, "Michael Keenan (mikeenan)" > >, "Satyanarayana Danda > (sdanda)" >, "John Delaney > (jodelane)" > > Subject: TACACS+ RFC > > Hi, > > TACACS+ is a protocol widely deployed, based upon a draft > specification that Cisco submitted in 1998, but never completed to RFC > status. The original draft has been tidied and lightly enhanced and > resubmitted, with the intent to finally get it published as a standard. > > The best fit that we could see was for the opsawg. > > Many thanks, > > Regards, > > Doug. > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------000406010200000707040801 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
For information, the draft is at: http://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/

Regards, B;
Please note the following concerning the document content:

The majority of the document is a cleaned and tidied refresh of the original draft.
However, included in the document is a new feature that we propose for discussion: Support for TLS using a new packet type allows the TACACS protocol to upgrade itself to a TLS tunnel. Please see section 3.6.2. This is added in a way that is intended not to interfere with any current implementations of TACACS+.

Also, a note in relation to TACACS+ and RADIUS. Although the protocols were probably about equivalent in 1998, the addition of EAP and other enhancements mean that RADIUS is the default protocol for Network Access. By reviving the TACACS+ draft we have no intention of influencing this status quo. However, TACACS+ does have a continued and widely deployed use case for Device Administration. This is due to its strict separation of authorisation from authentication which allows per-command authorisation, and its TCP transport for allowing effective accounting. It is to support this use case that TACACS+ is proposed for progress to a standard, and informed the thoughts for the potential selection of a workgroup, however if this selection is misguided, please let us know.

Many thanks,

Regards,

Doug.



From: Douglas Gash <dcmgash@cisco.com>
Date: Friday, 12 June 2015 08:23
To: "opsawg@ietf.org" <opsawg@ietf.org>
Cc: Thorsten Dahm <thorstendlux@google.com>, Andrej Ota <aota@google.com>, "Michael Keenan (mikeenan)" <mikeenan@cisco.com>, "Satyanarayana Danda (sdanda)" <sdanda@cisco.com>, "John Delaney (jodelane)" <jodelane@cisco.com>
Subject: TACACS+ RFC

Hi,

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

The best fit that we could see was for the opsawg.

Many thanks,

Regards,

Doug.
 

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

--------------000406010200000707040801-- From nobody Fri Jun 12 12:37: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 8B4E81AD2A9 for ; Fri, 12 Jun 2015 12:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 kD5PYKFL0sVH for ; Fri, 12 Jun 2015 12:37:30 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 CAD3F1AD21C for ; Fri, 12 Jun 2015 12:37:29 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5CJbOog024472 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jun 2015 15:37:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t5CJbOog024472 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1434137846; bh=br51WmCEiO3QxqEyeZb+cdh/vIg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=XHWh3nfteDD8v45+N/sN6vMuBqntQVSQX78y9OUJwgz+IWXOFoZA8GJOgQ6Yh241f Bsh4O5IWzvxS0+lfxzEjf4Q/hDBS5bNoMFOBXlclTZc18qRtGeUc2kfdpNp5AvRBmt 3top53S5I5+hvp7Po0MYUIAX9KpbJr8/siP62fKM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t5CJbOog024472 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor); Fri, 12 Jun 2015 15:37:40 -0400 Received: from mxhub39.corp.emc.com (mxhub39.corp.emc.com [128.222.70.106]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5CJb3OZ026485 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jun 2015 15:37:07 -0400 Received: from MXHUB201.corp.emc.com (10.253.68.27) by mxhub39.corp.emc.com (128.222.70.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 12 Jun 2015 15:37:02 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.123]) by MXHUB201.corp.emc.com ([10.253.68.27]) with mapi id 14.03.0224.002; Fri, 12 Jun 2015 15:37:01 -0400 From: "Black, David" To: "Douglas Gash (dcmgash)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] TACACS+ RFC: Regarding submission Thread-Index: AQHQpQGbxfgfcV4DnUaXepkPf0DRU52pFiyAgAAlgmA= Date: Fri, 12 Jun 2015 19:37:01 +0000 Message-ID: References: <557AD5ED.3050003@cisco.com> In-Reply-To: <557AD5ED.3050003@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.140] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949360B373C10MX104CL02corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 19:37:34 -0000 --_000_CE03DB3D7B45C245BCA0D243277949360B373C10MX104CL02corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This generally seems like a good idea. > However, included in the document is a new feature that we propose for di= scussion: Support for TLS using > a new packet type allows the TACACS protocol to upgrade itself to a TLS t= unnel. Please see section 3.6.2. > This is added in a way that is intended not to interfere with any current= implementations of TACACS+. I think this feature is a good addition. The draft currently lacks a Secur= ity Considerations section - that would a good place to say that TLS is pre= ferable to legacy TACACS encryption (3.6.1) *when there is a choice* and di= scuss the circumstances under which there is no choice (e.g., interoperabil= ity required with deployed systems). Please consider the design alternative of using a separate port for TACACS-= over-TLS (NB: "consider" *not* "change to"). There is no protocol-independ= ent IETF consensus on whether separate ports should be used for secure and = insecure variants of the same protocol, see section 7.4 of draft-ietf-tsvwg= -port-use, currently at the RFC Editor: https://tools.ietf.org/html/draft-ietf-tsvwg-port-use-11#section-7.4 Hence, using a single port is fine, and is preferable in the absence of oth= er considerations, as one less port is used. I also see no IANA Considerations section - at a minimum, the AVPs in Secti= on 7 should be put into a new IANA registry, as that's an intended area of = extensibility. I also see a number of lists of values in Sections 4-6 that= may also benefit from being put into IANA registries if there's a reasonab= le possibility of future additions. > TACACS+ is a protocol widely deployed, based upon a draft specification t= hat Cisco submitted in 1998, but never completed to RFC status. > The original draft has been tidied and lightly enhanced and resubmitted, = with the intent to finally get it published as a standard. Some sort of reference to that original draft should be provided. The curr= ent [TheDraft] reference to RFC 2200 for this purpose doesn't get that job = done. It looks like that expired draft is draft-grant-tacacs-02. Is RFC 1= 492 also relevant? Thanks, --David From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Friday, June 12, 2015 8:52 AM To: Douglas Gash (dcmgash); opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission For information, the draft is at: http://datatracker.ietf.org/doc/draft-dah= m-opsawg-tacacs/ Regards, B; Please note the following concerning the document content: The majority of the document is a cleaned and tidied refresh of the origina= l draft. However, included in the document is a new feature that we propose for disc= ussion: Support for TLS using a new packet type allows the TACACS protocol = to upgrade itself to a TLS tunnel. Please see section 3.6.2. This is added = in a way that is intended not to interfere with any current implementations= of TACACS+. Also, a note in relation to TACACS+ and RADIUS. Although the protocols were= probably about equivalent in 1998, the addition of EAP and other enhanceme= nts mean that RADIUS is the default protocol for Network Access. By revivin= g the TACACS+ draft we have no intention of influencing this status quo. Ho= wever, TACACS+ does have a continued and widely deployed use case for Devic= e Administration. This is due to its strict separation of authorisation fro= m authentication which allows per-command authorisation, and its TCP transp= ort for allowing effective accounting. It is to support this use case that = TACACS+ is proposed for progress to a standard, and informed the thoughts f= or the potential selection of a workgroup, however if this selection is mis= guided, please let us know. Many thanks, Regards, Doug. From: Douglas Gash > Date: Friday, 12 June 2015 08:23 To: "opsawg@ietf.org" > Cc: Thorsten Dahm >= , Andrej Ota >, "Michael Keenan (mi= keenan)" >, "Satyanarayana Da= nda (sdanda)" >, "John Delaney (j= odelane)" > Subject: TACACS+ RFC Hi, TACACS+ is a protocol widely deployed, based upon a draft specification tha= t Cisco submitted in 1998, but never completed to RFC status. The original = draft has been tidied and lightly enhanced and resubmitted, with the intent= to finally get it published as a standard. The best fit that we could see was for the opsawg. Many thanks, Regards, Doug. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_CE03DB3D7B45C245BCA0D243277949360B373C10MX104CL02corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This generally seems like a good idea.

 

> However, included in the document is a new feature th= at we propose for discussion: Support for TLS using

> a new packet type allows the TACACS protocol to upgra= de itself to a TLS tunnel. Please see section 3.6.2.

> This is added in a way that is intended not to interf= ere with any current implementations of TACACS+.

 

I think this feature is a good addition.  The draft c= urrently lacks a Security Considerations section - that would a good place = to say that TLS is preferable to legacy TACACS encryption (3.6.1) *when there is a choice* and discuss the circumstances unde= r which there is no choice (e.g., interoperability required with deployed s= ystems).

 

Please consider the design alternative of using a separate= port for TACACS-over-TLS (NB: “consider” *not* “c= hange to”).  There is no protocol-independent IETF consensus on whether separate ports should be used for secure and insecure variants of = the same protocol, see section 7.4 of draft-ietf-tsvwg-port-use, currently = at the RFC Editor:

https://tools.ietf.org/ht= ml/draft-ietf-tsvwg-port-use-11#section-7.4

 

Hence, using a single port is fine, and is preferable in t= he absence of other considerations, as one less port is used.

 

I also see no IANA Considerations section - at a minimum, = the AVPs in Section 7 should be put into a new IANA registry, as that’= ;s an intended area of extensibility.  I also see a number of lists of values in Sections 4-6 that may also benefit from being= put into IANA registries if there’s a reasonable possibility of futu= re additions.

 

> TACACS+ is a protocol widely d= eployed, based upon a draft specification that Cisco submitted in 1998, but= never completed to RFC status.

> The original draft has been tidied= and lightly enhanced and resubmitted, with the intent to finally get it pu= blished as a standard.

 

Some sort of reference to that original draft should be pr= ovided.  The current [TheDraft] reference to RFC 2200 for this purpose= doesn’t get that job done.  It looks like that expired draft is draft-grant-tacacs-02.  Is RFC 1492 also relevant?

 

Thanks,
--David

 

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Friday, June 12, 2015 8:52 AM
To: Douglas Gash (dcmgash); opsawg@ietf.org
Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission

 

For information, the draft is at: http://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/

Regards, B;

Please note the following concerning the document co= ntent:

 

The majority of the document is a cleaned and tidied= refresh of the original draft.

However, included in the document is a new feature t= hat we propose for discussion: Support for TLS using a new packet type allo= ws the TACACS protocol to upgrade itself to a TLS tunnel. Please see sectio= n 3.6.2. This is added in a way that is intended not to interfere with any current implementations of TACACS= 3;.

 

Also, a note in relation to TACACS+ and RADIUS. = Although the protocols were probably about equivalent in 1998, the addition= of EAP and other enhancements mean that RADIUS is the default protocol for= Network Access. By reviving the TACACS+ draft we have no intention of influencing this status quo. However, TACACS= + does have a continued and widely deployed use case for Device Adminis= tration. This is due to its strict separation of authorisation from authent= ication which allows per-command authorisation, and its TCP transport for allowing effective accounting. It is to support = this use case that TACACS+ is proposed for progress to a standard, and = informed the thoughts for the potential selection of a workgroup, however i= f this selection is misguided, please let us know.

 

Many thanks,

 

Regards,

 

Doug.

 

 

 

From: Douglas Gash <dcmgash@cisco.com>
Date: Friday, 12 June 2015 08:23
To: "opsawg@ietf.org&quo= t; <opsawg@ietf.org>
Cc: Thorsten Dahm <tho= rstendlux@google.com>, Andrej Ota <aota@google.com>, "Michael Keenan (mikeenan)" <mikeenan@cisco.com>, "Satyan= arayana Danda (sdanda)" <sdanda@cisco.= com>, "John Delaney (jodelane)" <jodelane@cisco.com>
Subject: TACACS+ RFC

 

Hi,

 

TACACS+ is a protocol widely deploy= ed, based upon a draft specification that Cisco submitted in 1998, but neve= r completed to RFC status. The original draft has been tidied and lightly enhanced and resubmitted, with the intent to finally get it pu= blished as a standard.

 

The best fit that we could see was for = the opsawg.

 

Many thanks,

 

Regards,

 

Doug.




_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org

https://www.i=
etf.org/mailman/listinfo/opsawg

 

--_000_CE03DB3D7B45C245BCA0D243277949360B373C10MX104CL02corpem_-- From nobody Fri Jun 12 13:26: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 42A3A1A8897 for ; Fri, 12 Jun 2015 13:26:16 -0700 (PDT) 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 Vmc808OYqTEd for ; Fri, 12 Jun 2015 13:26:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BFF1A87AB for ; Fri, 12 Jun 2015 13:26:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z3VWn-0006yI-8h; Fri, 12 Jun 2015 20:26:13 +0000 Date: Sat, 13 Jun 2015 05:26:12 +0900 Message-ID: From: Randy Bush To: Douglas Gash In-Reply-To: References: <86CF0797-D301-43F2-90D4-A08953209F32@sobco.com> <404FC3A0-5AB9-4E04-9310-A62730EBAD28@sobco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] TACACS+ RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:26:16 -0000 do i need to sign an nda to get the name of the draft? :) randy From nobody Fri Jun 12 13:40: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 7DC901A8739 for ; Fri, 12 Jun 2015 13:40:48 -0700 (PDT) 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 CdfX2toxtyyY for ; Fri, 12 Jun 2015 13:40:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582071A87F2 for ; Fri, 12 Jun 2015 13:40:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z3Vkq-00070w-Pg; Fri, 12 Jun 2015 20:40:45 +0000 Date: Sat, 13 Jun 2015 05:40:43 +0900 Message-ID: From: Randy Bush To: Benoit Claise In-Reply-To: <557AD5ED.3050003@cisco.com> References: <557AD5ED.3050003@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: Cc: "Douglas Gash \(dcmgash\)" , "opsawg@ietf.org" Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:40:48 -0000 > http://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/ thanks! From nobody Mon Jun 15 09: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 0C0631A908D for ; Mon, 15 Jun 2015 09:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 kaAffkTEhHUC for ; Mon, 15 Jun 2015 09:44:06 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484131A909F for ; Mon, 15 Jun 2015 09:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24692; q=dns/txt; s=iport; t=1434386644; x=1435596244; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kkbzh0ZFKNWUxkkr/TBY4rFbVrnd7o3WtqE3VyTrEOA=; b=FoDcmf5DKfquJ2HkTVx+8BCsVjRISOfQ0M3Ezkmpz7yi62sKxFC0kFMf FZVMLHFnEFiD1pTk05tUYMBDwkZANyyZBHOannm43mOHymk/8hq+d1kyP ffGDwbITyPsVf5/9vbQaTpEmcXn3pEzaYIwKDC/KWXCnQAYgtETeIGuGd o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DWAAC3/35V/5NdJa1UCIJFS1RfBq8cjhsqCWwFZgEJhS5KAoE7OBQBAQEBAQEBgQqEIgEBAQMBAQEBKkEEBwULAgEIEQMBAQEhBwcnCxQJCAIEAQ0FiCcIDcs5AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tEgT0BgnEzEw0EBgEChCsFkQeCVAGET4JVhB2BM0GDQ5JZERVjgSgND4FSbwGBRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,618,1427760000"; d="scan'208,217";a="159657333" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 15 Jun 2015 16:44:03 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5FGi3B7017314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 16:44:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 11:44:02 -0500 From: "Douglas Gash (dcmgash)" To: "Black, David" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] TACACS+ RFC: Regarding submission Thread-Index: AQHQpQGbxfgfcV4DnUaXepkPf0DRU52pJu+AgABxLYCABJd4gA== Date: Mon, 15 Jun 2015 16:44:02 +0000 Message-ID: References: <557AD5ED.3050003@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.55.255.66] Content-Type: multipart/alternative; boundary="_000_D1A4BE70708EAdcmgashciscocom_" MIME-Version: 1.0 Archived-At: Cc: Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 16:44:10 -0000 --_000_D1A4BE70708EAdcmgashciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi David, Many thanks for the review and the insightful comments! 1: Thanks, yes, we will add the security considerations section as suggeste= d. 2: Originally we were going to use a separate port, however, when the start= -TLS mechanism was proposed this seemed more elegant, it seemed to be the p= recedent for other recent protocols that had TLS added (SMTP etc) and of co= urse, meant that a new port did not need to be allocated. So the use of a s= eparate port was deprecated because we believe that reusing the current was= the =93right thing to do=94. This is exactly the right place to find out i= f we were correct! If there is any thought that we proceeded down the wrong= path here, we will, of course, be happy to change. 3a: Registering the AV-Pairs with IANA: Certainly, makes sense. Just a sani= ty check though: it would be good to know the implications of doing this. I= n current deployments, many vendors freely use their own av-pairs. Would re= gistering these with IANA this impose an overhead that we do not currently = have, in vendors adding attributes?. 3b: Adding protocol constants to IANA: Certainly. However, most of these en= umerations are part of the protocol and should really be locked (such as st= atus, Authentication action etc) in order to achieve reasonable levels of i= nteroperability. By registering with IANA, can we still provide sufficient = control to ensure that they are not adversely adjusted? 4: Thanks yes, we will add/correct a reference to the original draft. Many thanks! (The doc authors collective). From: , David > Date: Friday, 12 June 2015 20:37 To: Douglas Gash >, "opsawg@iet= f.org" > Subject: RE: [OPSAWG] TACACS+ RFC: Regarding submission This generally seems like a good idea. > However, included in the document is a new feature that we propose for di= scussion: Support for TLS using > a new packet type allows the TACACS protocol to upgrade itself to a TLS t= unnel. Please see section 3.6.2. > This is added in a way that is intended not to interfere with any current= implementations of TACACS+. I think this feature is a good addition. The draft currently lacks a Secur= ity Considerations section - that would a good place to say that TLS is pre= ferable to legacy TACACS encryption (3.6.1) *when there is a choice* and di= scuss the circumstances under which there is no choice (e.g., interoperabil= ity required with deployed systems). Please consider the design alternative of using a separate port for TACACS-= over-TLS (NB: =93consider=94 *not* =93change to=94). There is no protocol-= independent IETF consensus on whether separate ports should be used for sec= ure and insecure variants of the same protocol, see section 7.4 of draft-ie= tf-tsvwg-port-use, currently at the RFC Editor: https://tools.ietf.org/html/draft-ietf-tsvwg-port-use-11#section-7.4 Hence, using a single port is fine, and is preferable in the absence of oth= er considerations, as one less port is used. I also see no IANA Considerations section - at a minimum, the AVPs in Secti= on 7 should be put into a new IANA registry, as that=92s an intended area o= f extensibility. I also see a number of lists of values in Sections 4-6 th= at may also benefit from being put into IANA registries if there=92s a reas= onable possibility of future additions. > TACACS+ is a protocol widely deployed, based upon a draft specification t= hat Cisco submitted in 1998, but never completed to RFC status. > The original draft has been tidied and lightly enhanced and resubmitted, = with the intent to finally get it published as a standard. Some sort of reference to that original draft should be provided. The curr= ent [TheDraft] reference to RFC 2200 for this purpose doesn=92t get that jo= b done. It looks like that expired draft is draft-grant-tacacs-02. Is RFC= 1492 also relevant? Thanks, --David From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Friday, June 12, 2015 8:52 AM To: Douglas Gash (dcmgash); opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission For information, the draft is at: http://datatracker.ietf.org/doc/draft-dah= m-opsawg-tacacs/ Regards, B; Please note the following concerning the document content: The majority of the document is a cleaned and tidied refresh of the origina= l draft. However, included in the document is a new feature that we propose for disc= ussion: Support for TLS using a new packet type allows the TACACS protocol = to upgrade itself to a TLS tunnel. Please see section 3.6.2. This is added = in a way that is intended not to interfere with any current implementations= of TACACS+. Also, a note in relation to TACACS+ and RADIUS. Although the protocols were= probably about equivalent in 1998, the addition of EAP and other enhanceme= nts mean that RADIUS is the default protocol for Network Access. By revivin= g the TACACS+ draft we have no intention of influencing this status quo. Ho= wever, TACACS+ does have a continued and widely deployed use case for Devic= e Administration. This is due to its strict separation of authorisation fro= m authentication which allows per-command authorisation, and its TCP transp= ort for allowing effective accounting. It is to support this use case that = TACACS+ is proposed for progress to a standard, and informed the thoughts f= or the potential selection of a workgroup, however if this selection is mis= guided, please let us know. Many thanks, Regards, Doug. From: Douglas Gash > Date: Friday, 12 June 2015 08:23 To: "opsawg@ietf.org" > Cc: Thorsten Dahm >= , Andrej Ota >, "Michael Keenan (mi= keenan)" >, "Satyanarayana Da= nda (sdanda)" >, "John Delaney (j= odelane)" > Subject: TACACS+ RFC Hi, TACACS+ is a protocol widely deployed, based upon a draft specification tha= t Cisco submitted in 1998, but never completed to RFC status. The original = draft has been tidied and lightly enhanced and resubmitted, with the intent= to finally get it published as a standard. The best fit that we could see was for the opsawg. Many thanks, Regards, Doug. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_D1A4BE70708EAdcmgashciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi David,

Many thanks for the review and the insightful comments!

1: Thanks, yes, we will add the security considerations section as sug= gested.
2: Originally we were going to use a separate port, however, when the = start-TLS mechanism was proposed this seemed more elegant, it seemed to be = the precedent for other recent protocols that had TLS added (SMTP etc) and = of course, meant that a new port did not need to be allocated. So the use of a separate port was deprecated= because we believe that reusing the current was the =93right thing to do= =94. This is exactly the right place to find out if we were correct! If the= re is any thought that we proceeded down the wrong path here, we will, of course, be happy to change.
3a: Registering the AV-Pairs with IANA: Certainly, makes sense. Just a= sanity check though: it would be good to know the implications of doing th= is. In current deployments, many vendors freely use their own av-pairs. Wou= ld registering these with IANA this impose an overhead that we do not currently have, in vendors adding attrib= utes?.
3b: Adding protocol constants to IANA: Certainly. However, most of the= se enumerations are part of the protocol and should really be locked (such = as status, Authentication action etc) in order to achieve reasonable levels= of interoperability. By registering with IANA, can we still provide sufficient control to ensure that they are= not adversely adjusted?
4: Thanks yes, we will add/correct a reference to the original draft.<= /div>

Many thanks!

(The doc authors collective).

From: <Black>, David <david.black@emc.com>
Date: Friday, 12 June 2015 20:37 To: Douglas Gash <dcmgash@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Subject: RE: [OPSAWG] TACACS+ R= FC: Regarding submission

This generally seems like a good idea.

 

> However, included in the document is a new feature that we pr= opose for discussion: Support for TLS using

> a new packet type allows the TACACS protocol to upgrade itsel= f to a TLS tunnel. Please see section 3.6.2.

> This is added in a way that is intended not to interfere with= any current implementations of TACACS+.

 

I think this feature is a good addition.  The draft currently= lacks a Security Considerations section - that would a good place to say t= hat TLS is preferable to legacy TACACS encryption (3.6.1) *when there is a choice* and discuss the circumstances unde= r which there is no choice (e.g., interoperability required with deployed s= ystems).

 

Please consider the design alternative of using a separate port fo= r TACACS-over-TLS (NB: =93consider=94 *not* =93change to=94).  = There is no protocol-independent IETF consensus on whether separate ports should be used for secure and insecure variants of = the same protocol, see section 7.4 of draft-ietf-tsvwg-port-use, currently = at the RFC Editor:

https://tools.ietf.org/html/draft= -ietf-tsvwg-port-use-11#section-7.4

 

Hence, using a single port is fine, and is preferable in the absen= ce of other considerations, as one less port is used.

 

I also see no IANA Considerations section - at a minimum, the AVPs= in Section 7 should be put into a new IANA registry, as that=92s an intend= ed area of extensibility.  I also see a number of lists of values in Sections 4-6 that may also benefit from bei= ng put into IANA registries if there=92s a reasonable possibility of future= additions.

 

> TACACS+ is a protocol widely deployed, based upon= a draft specification that Cisco submitted in 1998, but never completed to= RFC status.

> The original draft has been tidied and lightly enhanc= ed and resubmitted, with the intent to finally get it published as a standa= rd.

 

Some sort of reference to that original draft should be provided.&= nbsp; The current [TheDraft] reference to RFC 2200 for this purpose doesn= =92t get that job done.  It looks like that expired draft is draft-grant-tacacs-02.  Is RFC 1492 also relevant?

 

Thanks,
--David=

 

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Friday, June 12, 2015 8:52 AM
To: Douglas Gash (dcmgash); opsaw= g@ietf.org
Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission

 

For information, the draft is at: http://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/

Regards, B;

Please note the following concerning the document co= ntent:

 

The majority of the document is a cleaned and tidied= refresh of the original draft.

However, included in the document is a new feature t= hat we propose for discussion: Support for TLS using a new packet type allo= ws the TACACS protocol to upgrade itself to a TLS tunnel. Please see sectio= n 3.6.2. This is added in a way that is intended not to interfere with any current implementations of TACACS= 3;.

 

Also, a note in relation to TACACS+ and RADIUS. = Although the protocols were probably about equivalent in 1998, the addition= of EAP and other enhancements mean that RADIUS is the default protocol for= Network Access. By reviving the TACACS+ draft we have no intention of influencing this status quo. However, TACACS= + does have a continued and widely deployed use case for Device Adminis= tration. This is due to its strict separation of authorisation from authent= ication which allows per-command authorisation, and its TCP transport for allowing effective accounting. It is to support = this use case that TACACS+ is proposed for progress to a standard, and = informed the thoughts for the potential selection of a workgroup, however i= f this selection is misguided, please let us know.

 

Many thanks,

 

Regards,

 

Doug.

 

 

 

From: Douglas Gash <dcmgash@cisco.com<= /a>>
Date: Friday, 12 June 2015 08:23
To: "opsawg@ietf.org&quo= t; <opsawg@ietf.org>
Cc: Thorsten Dahm <tho= rstendlux@google.com>, Andrej Ota <aota@google.com>, "Michael Keenan (mikeenan)" <mikeenan@cisco.com>, "Satyan= arayana Danda (sdanda)" <sdanda@cisco.= com>, "John Delaney (jodelane)" <jodelane@cisco.com>
Subject: TACACS+ RFC

 

Hi,

 

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

 

The best fit that we could see was for the opsawg.

 

Many thanks,

 

Regards,

 

Doug.




_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org

https://www.i=
etf.org/mailman/listinfo/opsawg

 

 --_000_D1A4BE70708EAdcmgashciscocom_-- From nobody Mon Jun 15 11:00: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 5C3F21A0197 for ; Mon, 15 Jun 2015 10:59:58 -0700 (PDT) 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 iuceJXk9twQ3 for ; Mon, 15 Jun 2015 10:59:56 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (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 CB0321A01BA for ; Mon, 15 Jun 2015 10:59:41 -0700 (PDT) Received: by oiha141 with SMTP id a141so64610298oih.0 for ; Mon, 15 Jun 2015 10:59:41 -0700 (PDT) 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:content-transfer-encoding; bh=WEMuf/ahRg+iBn+bpscexCXhLsmrnQnn+txbuMd0nZA=; b=Vt5z/77upP6AWdw/XPLYLgnNTTJ8vl6oO42Tp3rpH5JYC/pWsQYATntiSgTDZDYW7W iB2Do6s1/+9Ch1PyJNNFL4fYA/OtJGURlqryK2LvkqH5J2E50/eKf6xOxBS0vU2BIyCk jp+jCDwvMfZYdixKdOZLniNqC+D93bf/J4+Dk5ha+oGnQ0pZlUAlbhWKgjHejbbhUYgO sII1H9kw6c2N2c1MbFM8J5Wc3uXiXZXNDSK2x5cBpvl0HUhqZ7miQfglEfVohKaLCJN6 X3UWgiKuATJPtQhd1ePGMcd/F7077eNYW4WOVVCMDRlVCHg9CB7YxL6o5x0l04fO9iKe 206g== X-Gm-Message-State: ALoCoQnUJScfQEQLFl3hHelyO8RuyAGW9I94LVBFtf68x1Qrqsll20/wbe43+msfQUZDrWWGhAYr MIME-Version: 1.0 X-Received: by 10.182.186.106 with SMTP id fj10mr24452073obc.54.1434391181080; Mon, 15 Jun 2015 10:59:41 -0700 (PDT) Received: by 10.202.196.75 with HTTP; Mon, 15 Jun 2015 10:59:41 -0700 (PDT) In-Reply-To: <20150615095928.18576.6993.idtracker@ietfa.amsl.com> References: <20150615095928.18576.6993.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 13:59:41 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , "dns-privacy@ietf.org" , "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [OPSAWG] Fwd: Third and FINAL call for volunteers, Nomcom 2015-2016 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:59:58 -0000 Please consider volunteering for the NomCom -- it is a very important position, and helps ensure that we select an IAB and IESG who will help make the IETF successful... W ---------- Forwarded message ---------- From: NomCom Chair 2015 Date: Mon, Jun 15, 2015 at 5:59 AM Subject: Third and FINAL call for volunteers, Nomcom 2015-2016 To: IETF Announcement List Cc: ietf@ietf.org ***Reminder: Deadline for volunteering for Nomcom is in ONE WEEK.*** The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF 88 (Vancouver), \ 89 (London), \ 90 (Toronto), *** ANY THREE! 91 (Honolulu), / 92 (Dallas) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointmen= t to any of the positions for which this nomcom is responsible. As of today, we have 151 confirmed volunteers. 72 of those who ticked the box on the registration form for Hawaii, Dallas and Prague have still not responded. If you believe you have volunteered, and your name is NOT below, please contact me as soon as possible. Thank you for volunteering! The list of people and posts whose terms end with the March 2016 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: No terms expire at this time. IAB: Mary Barnes Joe Hildebrand Ted Hardie Erik Nordmark Brian Trammell Marc Blanchet IESG: Alissa Cooper (ART) Barry Leiba (ART) Brian Haberman (Internet) Benoit Claise (Operations and Management) Alia Atlas (Routing) Kathleen Moriarty (Security) Martin Stiemerling (Transport) The Applications and Real-Time (ART) area is the expected new area resulting from the merge of the APP and RAI areas. All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas have at least one continuing AD. The primary activity for this nomcom will begin in July 2015 and should be completed in January 2016. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is al= so a very rewarding experience. It is very important that you be able to attend IETF94 (Yokohama) to conduct interviews. Being at IETF93 (Prague) is useful for orientation. Being at IETF95 is not essential. Please volunteer by sending me an email before 11:59 pm CET (UTC +2 hours) June 22, 2015, as follows: To: nomcom-chair-2015@ietf.org Subject: Nomcom 2015-16 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You will find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2015/ Thank you! Harald Alvestrand hta+nomcom@alvestrand.no nomcom-chair-2015@ietf.org =3D=3D=3D=3D=3D qualified volunteers so far, in alphabetical order by firs= t name Adam Montville Adrian Farrel ANDREW Dolganow Andrew Newton Andy Bierman ANM Zaheduzzaman Sarker Anoop Ghanwani Anthony Nadalin Ari Keranen Benno Overeinder Bernard Aboba Bhumip KHASNABISH Bing Liu Borje Ohlman Carl Moberg Carlos Martinez Cengiz Alaettinoglu Charles Eckel Charles Perkins Chris Bowers Christer Holmberg Christian Huitema Christian O'Flaherty Cong Liu Corinna Schmitt Cullen Jennings Damien Saucez Daniele Ceccarelli Dapeng Liu David Conrad David Lamparter David Mandelberg David Sinicrope Dean Bogdanovic Derek Atkins Dhruv Dhody Dimitri Papadimitriou Donald Eastlake 3rd Edward Lemon Eliot Lear Emil Ivov Eric Gray Eric Vyncke Fangwei Hu Fernando Gont Fred Baker George Michaelson George Swallow Georgios Karagiannis Gonzalo Salgueiro Gregory Mirsky Hannes Gredler Hongyu Li Huaimo Chen Ignas Bagdonas Jason Weil Jean-Marc Valin Jean-Michel Combes Jesus Maria Martin Garcia Joel Halpern John Bradley John Brzozowski John Drake John Mattsson John Scudder Jon Hudson Jon Mitchell jouni korhonen Karen O'Donoghue Keith Moore Kenneth Gray Kent Watsen Kepeng Li Keyur Patel Laurent Ciavaglia Lee Howard Liang Xia Linda Dunbar Lingli Deng Lixia Zhang Lucy Lynch Luigi Iannone Mach CHEN Magnus Westerlund Mahalingam Mani Mark Townsley Matthew Bocci Matthew Lepinski Mehmet Ersue Michael Jones Michael StJohns Min Ye nalini elkins Nancy Cam-Winget Nathan Egge Niel Harper Ning Kong Ning Zong Ole Jacobsen Ole Tr=C3=B8an Pascal Thubert Patrick McManus Paul Wouters Peng Fan Peter Koch Peter Yee P=C3=A5l-Erik Martinsen QIN WU Rich Salz Richard Barnes Robby Simpson Ron Bonica Ross Callon Salvatore Loreto Sam K. Aldrin Sanjay Mishra Scott Mansfield Sheng Jiang SHUCHENG LIU Simon Perreault Sri Gundavelli Stephan Wenger Stephen Kent Steve Donovan Steve Olshansky Steven Wright Suhas Nandakumar Suresh Krishnan Susan Hares Thomas Nadeau Thomas Walsh Tim Wicinski Timothy Terriberry Tina (Ting) Tsou (Zou) TIRUMALESWAR REDDY KONDA Tobias Gondrom Toerless Eckert Tomohiro Fujisaki Tony Hansen Uma Chunduri Vic Liu Vijay Gurbani Warren Kumari Wassim Haddad Wijnands IJsbrand Xufeng Liu Yi Zhao Yihong Huang Yizhou Li Yuanlong Jiang Zhaohui Zhang --=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 Jun 15 14:15: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 3E4601B2A68 for ; Mon, 15 Jun 2015 14:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 1g_uQd6OBs-e for ; Mon, 15 Jun 2015 14:15:08 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 E70951B2A6A for ; Mon, 15 Jun 2015 14:15:06 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5FLF2Zn018382 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jun 2015 17:15:03 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t5FLF2Zn018382 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1434402903; bh=w1ukBhX3tefxshswJfRbw5C9MMU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=rd0UrGPc6uOIRvSpTpZhQ1fBDzVTnckPsmm56dOswHsyfqgd71Tw5wf72IRGVHlab iWnzjQwlWqQuxkSwgD7GdjEE43gVm9MqrwDvJJUqDUolfnUpTUfbD8kSUsL2K4S9mm SkP4LtgPItogA1WXYon+ouBWM3ArZ+h2nhcmJGVY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t5FLF2Zn018382 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd54.lss.emc.com (RSA Interceptor); Mon, 15 Jun 2015 17:14:31 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5FLEimX024935 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 17:14:45 -0400 Received: from MXHUB101.corp.emc.com (10.253.50.15) by mxhub26.corp.emc.com (10.254.110.182) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 15 Jun 2015 17:14:44 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.123]) by MXHUB101.corp.emc.com ([::1]) with mapi id 14.03.0224.002; Mon, 15 Jun 2015 17:14:43 -0400 From: "Black, David" To: "Douglas Gash (dcmgash)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] TACACS+ RFC: Regarding submission Thread-Index: AQHQpQGbxfgfcV4DnUaXepkPf0DRU52pFiyAgAAlgmCABNJUAP//4kjw Date: Mon, 15 Jun 2015 21:14:43 +0000 Message-ID: References: <557AD5ED.3050003@cisco.com> 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.57] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949360B377E16MX104CL02corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 21:15:15 -0000 --_000_CE03DB3D7B45C245BCA0D243277949360B377E16MX104CL02corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Doug, > 2: Originally we were going to use a separate port, however, when the sta= rt-TLS mechanism was proposed this seemed more elegant, it seemed to be > the precedent for other recent protocols that had TLS added (SMTP etc) an= d of course, meant that a new port did not need to be allocated. So the use= of > a separate port was deprecated because we believe that reusing the curren= t was the "right thing to do". In other words, use of a separate port for TACACS+ over TLS has already bee= n considered, and the result is that a single port with start-TLS seems like the "right thing to do" for TACACS+= , which sounds like a fine conclusion to me. > 3a: Registering the AV-Pairs with IANA: Certainly, makes sense. Just a sa= nity check though: it would be good to know the implications of doing this. > In current deployments, many vendors freely use their own av-pairs. Would= registering these with IANA this impose an overhead that we do not > currently have, in vendors adding attributes?. How do current deployments avoid collisions between av-pairs defined by dif= ferent vendors, specifically two vendors using the same attribute name for = different attributes? This can be avoided by using IANA registration as a = low-overhead collision-avoidance mechanism. In RFC 5226 this is about the = difference between "Private Use" (collisions possible) and "First Come Firs= t Served" (IANA registration prevents collisions) in Section 4.1: https://tools.ietf.org/html/rfc5226#section-4.1 > 3b: Adding protocol constants to IANA: Certainly. However, most of these = enumerations are part of the protocol and should really be locked (such as = status, > Authentication action etc) in order to achieve reasonable levels of inte= roperability. By registering with IANA, can we still provide sufficient con= trol to ensure > that they are not adversely adjusted? Yes, by specifying a suitably restrictive allocation policy. RFC 6580 is a= worked example where analogous constants from another protocol were put in= to IANA registries - the suitably restrictive "magic words" used there are: Allocation Policy: Standards Action [RFC5226] That allocation policy requires a standards-track RFC to make additions or = changes, see Section 4.1 of RFC5226. Thanks, --David From: Douglas Gash (dcmgash) [mailto:dcmgash@cisco.com] Sent: Monday, June 15, 2015 12:44 PM To: Black, David; opsawg@ietf.org Cc: Thorsten Dahm; Andrej Ota Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission Hi David, Many thanks for the review and the insightful comments! 1: Thanks, yes, we will add the security considerations section as suggeste= d. 2: Originally we were going to use a separate port, however, when the start= -TLS mechanism was proposed this seemed more elegant, it seemed to be the p= recedent for other recent protocols that had TLS added (SMTP etc) and of co= urse, meant that a new port did not need to be allocated. So the use of a s= eparate port was deprecated because we believe that reusing the current was= the "right thing to do". This is exactly the right place to find out if we= were correct! If there is any thought that we proceeded down the wrong pat= h here, we will, of course, be happy to change. 3a: Registering the AV-Pairs with IANA: Certainly, makes sense. Just a sani= ty check though: it would be good to know the implications of doing this. I= n current deployments, many vendors freely use their own av-pairs. Would re= gistering these with IANA this impose an overhead that we do not currently = have, in vendors adding attributes?. 3b: Adding protocol constants to IANA: Certainly. However, most of these en= umerations are part of the protocol and should really be locked (such as st= atus, Authentication action etc) in order to achieve reasonable levels of i= nteroperability. By registering with IANA, can we still provide sufficient = control to ensure that they are not adversely adjusted? 4: Thanks yes, we will add/correct a reference to the original draft. Many thanks! (The doc authors collective). From: , David > Date: Friday, 12 June 2015 20:37 To: Douglas Gash >, "opsawg@iet= f.org" > Subject: RE: [OPSAWG] TACACS+ RFC: Regarding submission This generally seems like a good idea. > However, included in the document is a new feature that we propose for di= scussion: Support for TLS using > a new packet type allows the TACACS protocol to upgrade itself to a TLS t= unnel. Please see section 3.6.2. > This is added in a way that is intended not to interfere with any current= implementations of TACACS+. I think this feature is a good addition. The draft currently lacks a Secur= ity Considerations section - that would a good place to say that TLS is pre= ferable to legacy TACACS encryption (3.6.1) *when there is a choice* and di= scuss the circumstances under which there is no choice (e.g., interoperabil= ity required with deployed systems). Please consider the design alternative of using a separate port for TACACS-= over-TLS (NB: "consider" *not* "change to"). There is no protocol-independ= ent IETF consensus on whether separate ports should be used for secure and = insecure variants of the same protocol, see section 7.4 of draft-ietf-tsvwg= -port-use, currently at the RFC Editor: https://tools.ietf.org/html/draft-ietf-tsvwg-port-use-11#section-7.4 Hence, using a single port is fine, and is preferable in the absence of oth= er considerations, as one less port is used. I also see no IANA Considerations section - at a minimum, the AVPs in Secti= on 7 should be put into a new IANA registry, as that's an intended area of = extensibility. I also see a number of lists of values in Sections 4-6 that= may also benefit from being put into IANA registries if there's a reasonab= le possibility of future additions. > TACACS+ is a protocol widely deployed, based upon a draft specification t= hat Cisco submitted in 1998, but never completed to RFC status. > The original draft has been tidied and lightly enhanced and resubmitted, = with the intent to finally get it published as a standard. Some sort of reference to that original draft should be provided. The curr= ent [TheDraft] reference to RFC 2200 for this purpose doesn't get that job = done. It looks like that expired draft is draft-grant-tacacs-02. Is RFC 1= 492 also relevant? Thanks, --David From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Friday, June 12, 2015 8:52 AM To: Douglas Gash (dcmgash); opsawg@ietf.org Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission For information, the draft is at: http://datatracker.ietf.org/doc/draft-dah= m-opsawg-tacacs/ Regards, B; Please note the following concerning the document content: The majority of the document is a cleaned and tidied refresh of the origina= l draft. However, included in the document is a new feature that we propose for disc= ussion: Support for TLS using a new packet type allows the TACACS protocol = to upgrade itself to a TLS tunnel. Please see section 3.6.2. This is added = in a way that is intended not to interfere with any current implementations= of TACACS+. Also, a note in relation to TACACS+ and RADIUS. Although the protocols were= probably about equivalent in 1998, the addition of EAP and other enhanceme= nts mean that RADIUS is the default protocol for Network Access. By revivin= g the TACACS+ draft we have no intention of influencing this status quo. Ho= wever, TACACS+ does have a continued and widely deployed use case for Devic= e Administration. This is due to its strict separation of authorisation fro= m authentication which allows per-command authorisation, and its TCP transp= ort for allowing effective accounting. It is to support this use case that = TACACS+ is proposed for progress to a standard, and informed the thoughts f= or the potential selection of a workgroup, however if this selection is mis= guided, please let us know. Many thanks, Regards, Doug. From: Douglas Gash > Date: Friday, 12 June 2015 08:23 To: "opsawg@ietf.org" > Cc: Thorsten Dahm >= , Andrej Ota >, "Michael Keenan (mi= keenan)" >, "Satyanarayana Da= nda (sdanda)" >, "John Delaney (j= odelane)" > Subject: TACACS+ RFC Hi, TACACS+ is a protocol widely deployed, based upon a draft specification tha= t Cisco submitted in 1998, but never completed to RFC status. The original = draft has been tidied and lightly enhanced and resubmitted, with the intent= to finally get it published as a standard. The best fit that we could see was for the opsawg. Many thanks, Regards, Doug. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_CE03DB3D7B45C245BCA0D243277949360B377E16MX104CL02corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Doug,

 

> 2: Originally we were going to use a separate port, however, w= hen the start-TLS mechanism was proposed this seemed more elegant, it seeme= d to be

> the precedent for other recent pro= tocols that had TLS added (SMTP etc) and of course, meant that a new port d= id not need to be allocated. So the use of

> a separate port was deprecated bec= ause we believe that reusing the current was the “right thing to do&#= 8221;.

 

In other words, use of a separate port for TACACS+ ove= r TLS has already been considered, and the result is that=

a single port with start-TLS seems like the “right t= hing to do” for TACACS+, which sounds like a fine conclusion to m= e.

 

> 3a: Registering the AV-Pairs with = IANA: Certainly, makes sense. Just a sanity check though: it would be good = to know the implications of doing this.

> In current deployments, many vendo= rs freely use their own av-pairs. Would registering these with IANA this im= pose an overhead that we do not

> currently have, in vendors adding = attributes?.

 

How do current deployments avoid collisions between av-pai= rs defined by different vendors, specifically two vendors using the same at= tribute name for different attributes?  This can be avoided by using IANA registration as a low-overhead collision-avoidanc= e mechanism.  In RFC 5226 this is about the difference between “= Private Use” (collisions possible) and “First Come First Served= ” (IANA registration prevents collisions) in Section 4.1:<= /span>

      https://tools.i= etf.org/html/rfc5226#section-4.1

 

> 3b: Adding protocol constants to IANA: Certainly. However, mos= t of these enumerations are part of the protocol and should really be locke= d (such as status,

>  Authentication action etc) i= n order to achieve reasonable levels of interoperability. By registering wi= th IANA, can we still provide sufficient control to ensure

> that they are not adversely adjust= ed?

 

Yes, by specifying a suitably restrictive allocation polic= y.  RFC 6580 is a worked example where analogous constants from anothe= r protocol were put into IANA registries - the suitably restrictive “magic words” used there are:

Allocation Policy: Standards Ac= tion [RFC5226]

 

That allocation policy requires a standards-track RFC to m= ake additions or changes, see Section 4.1 of RFC5226.

 

Thanks,
--David

 

From: Douglas Gash (dcmgash) [mailto:dcmgash@cisco.com]
Sent: Monday, June 15, 2015 12:44 PM
To: Black, David; opsawg@ietf.org
Cc: Thorsten Dahm; Andrej Ota
Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission

 

Hi David,

 

Many thanks for the review and the insi= ghtful comments!

 

1: Thanks, yes, we will add the securit= y considerations section as suggested.

2: Originally we were going to use a se= parate port, however, when the start-TLS mechanism was proposed this seemed= more elegant, it seemed to be the precedent for other recent protocols that had TLS added (SMTP etc) and of course, meant that a new po= rt did not need to be allocated. So the use of a separate port was deprecat= ed because we believe that reusing the current was the “right thing t= o do”. This is exactly the right place to find out if we were correct! If there is any thought that we proceeded = down the wrong path here, we will, of course, be happy to change.

3a: Registering the AV-Pairs with IANA:= Certainly, makes sense. Just a sanity check though: it would be good to kn= ow the implications of doing this. In current deployments, many vendors freely use their own av-pairs. Would registering these with I= ANA this impose an overhead that we do not currently have, in vendors addin= g attributes?.

3b: Adding protocol constants to IANA: = Certainly. However, most of these enumerations are part of the protocol and= should really be locked (such as status, Authentication action etc) in order to achieve reasonable levels of interoperability. By = registering with IANA, can we still provide sufficient control to ensure th= at they are not adversely adjusted?

4: Thanks yes, we will add/correct a re= ference to the original draft.

 

Many thanks!

 

(The doc authors collective).

 

From: <Black>, David <david.black@emc.com>
Date: Friday, 12 June 2015 20:37
To: Douglas Gash <dcmgash@ci= sco.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Subject: RE: [OPSAWG] TACACS+ RFC: Regarding submission

 

This generally seems like a good idea.

 

> However, included in the document is a new feature th= at we propose for discussion: Support for TLS using

> a new packet type allows the TACACS protocol to upgra= de itself to a TLS tunnel. Please see section 3.6.2.

> This is added in a way that is intended not to interf= ere with any current implementations of TACACS+.

 

I think this feature is a good addition.  The draft c= urrently lacks a Security Considerations section - that would a good place = to say that TLS is preferable to legacy TACACS encryption (3.6.1) *when there is a choice* and discuss the circumstances unde= r which there is no choice (e.g., interoperability required with deployed s= ystems).

 

Please consider the design alternative of using a separate= port for TACACS-over-TLS (NB: “consider” *not* “c= hange to”).  There is no protocol-independent IETF consensus on whether separate ports should be used for secure and insecure variants of = the same protocol, see section 7.4 of draft-ietf-tsvwg-port-use, currently = at the RFC Editor:

https://tools.ietf.org/ht= ml/draft-ietf-tsvwg-port-use-11#section-7.4

 

Hence, using a single port is fine, and is preferable in t= he absence of other considerations, as one less port is used.

 

I also see no IANA Considerations section - at a minimum, = the AVPs in Section 7 should be put into a new IANA registry, as that’= ;s an intended area of extensibility.  I also see a number of lists of values in Sections 4-6 that may also benefit from being= put into IANA registries if there’s a reasonable possibility of futu= re additions.

 

> TACACS+ is a protocol widely d= eployed, based upon a draft specification that Cisco submitted in 1998, but= never completed to RFC status.

> The original draft has been tidied= and lightly enhanced and resubmitted, with the intent to finally get it pu= blished as a standard.

 

Some sort of reference to that original draft should be pr= ovided.  The current [TheDraft] reference to RFC 2200 for this purpose= doesn’t get that job done.  It looks like that expired draft is draft-grant-tacacs-02.  Is RFC 1492 also relevant?

 

Thanks,
--David

 

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Friday, June 12, 2015 8:52 AM
To: Douglas Gash (dcmgash); opsaw= g@ietf.org
Subject: Re: [OPSAWG] TACACS+ RFC: Regarding submission

 

For information, the draft is at: http://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/

Regards, B;

Please note the following concerning the document co= ntent:

 

The majority of the document is a cleaned and tidied= refresh of the original draft.

However, included in the document is a new feature t= hat we propose for discussion: Support for TLS using a new packet type allo= ws the TACACS protocol to upgrade itself to a TLS tunnel. Please see sectio= n 3.6.2. This is added in a way that is intended not to interfere with any current implementations of TACACS= 3;.

 

Also, a note in relation to TACACS+ and RADIUS. = Although the protocols were probably about equivalent in 1998, the addition= of EAP and other enhancements mean that RADIUS is the default protocol for= Network Access. By reviving the TACACS+ draft we have no intention of influencing this status quo. However, TACACS= + does have a continued and widely deployed use case for Device Adminis= tration. This is due to its strict separation of authorisation from authent= ication which allows per-command authorisation, and its TCP transport for allowing effective accounting. It is to support = this use case that TACACS+ is proposed for progress to a standard, and = informed the thoughts for the potential selection of a workgroup, however i= f this selection is misguided, please let us know.

 

Many thanks,

 

Regards,

 

Doug.

 

 

 

From: Douglas Gash <dcmgash@cisco.com>
Date: Friday, 12 June 2015 08:23
To: "opsawg@ietf.org&quo= t; <opsawg@ietf.org>
Cc: Thorsten Dahm <tho= rstendlux@google.com>, Andrej Ota <aota@google.com>, "Michael Keenan (mikeenan)" <mikeenan@cisco.com>, "Satyan= arayana Danda (sdanda)" <sdanda@cisco.= com>, "John Delaney (jodelane)" <jodelane@cisco.com>
Subject: TACACS+ RFC

 

Hi,

 

TACACS+ is a protocol widely deploy= ed, based upon a draft specification that Cisco submitted in 1998, but neve= r completed to RFC status. The original draft has been tidied and lightly enhanced and resubmitted, with the intent to finally get it pu= blished as a standard.

 

The best fit that we could see was for = the opsawg.

 

Many thanks,

 

Regards,

 

Doug.





_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org

https://www.i=
etf.org/mailman/listinfo/opsawg

 

--_000_CE03DB3D7B45C245BCA0D243277949360B377E16MX104CL02corpem_-- From nobody Wed Jun 17 22:21: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 E21FA1B2F64 for ; Wed, 17 Jun 2015 22:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-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 CjZDtk_JY8zT for ; Wed, 17 Jun 2015 22:21:42 -0700 (PDT) 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 715931B2F63 for ; Wed, 17 Jun 2015 22:21:42 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:647:4200:7a31:f1c5:f7c7:caa2:6dca]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t5I5LfXB031290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 18 Jun 2015 05:21:42 GMT (envelope-from joelja@bogus.com) To: "opsawg@ietf.org" From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <55825564.5080203@bogus.com> Date: Wed, 17 Jun 2015 22:21:40 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8UPLgWAv4kUgQBmSgHPVbc12KAbHcvra2" Archived-At: Subject: [OPSAWG] draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 about to send to the rfc editor. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 05:21:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8UPLgWAv4kUgQBmSgHPVbc12KAbHcvra2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stephen Farrell's comment ( and former dicuss) I think should be food for thought and I'd like if possible to briefly discuss it. ------ I'm a yes on this, but am still holding my nose:-) The yes is because it's a fine thing to make sure that up-to-date options for securing protocols are available The nose-holding is because defining multiple options that aren't significantly different in strength (if one assumes that key management is the likely weakest link) is a bad plan. In case it helps, my main logic for not wanting all these options is that it is overwhelmingly more likely that the code to switch between them or react to which you've received or to configure things will (due to bugs etc.) weaken security much much much more than the existence of more than one of these options could ever strengthen security. (Put another way the probability of a security bug due to adding N things here is far far higher than the probability that having N things saves the day when N-1 of them are no longer considered good crypto at some point.) So by defining more of these you are doing worse than if you only defined one of these. (The fact that all sha2 digests have the same internal structure is part of but not all of this argument.) On truncation, I'd argue that if that was a significant benefit then it'd be used everywhere and it is not. In fact I don't believe truncation is used anywhere else when there's no protocol (e.g. PDU/fragmentation) issue that causes us to want shorter MACs. I also believe that even those who for truncation would agree that the benefit of reasonable-length truncation is definitely an insignificant benefit, if any, and would also agree that that's a matter of taste when it comes to sha2 variants of hmac (assuming the protocol can live with full length, as in this case). Bottom line: Discuss is cleared and I'm out of the way, but with a heartfelt plea that you ditch all of these but one. And then ditch truncation too. And so end up with just adding hmac-sha2 as many other protocols have done. ------- so there's a plea for limiting the scope of options, if someone feels very strongly that this is important to address I would take that under advisement. on the other hand reasoned countervailing arguements would also be fine but are certainly not critical. --8UPLgWAv4kUgQBmSgHPVbc12KAbHcvra2 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 iEYEARECAAYFAlWCVWUACgkQ8AA1q7Z/VrJvXACfScCSyc6DBoXWojd0WjQ/tZQP 6vYAn3xUOe7ipivu5ZSTSzRWe6Qj17lA =A0b4 -----END PGP SIGNATURE----- --8UPLgWAv4kUgQBmSgHPVbc12KAbHcvra2-- From nobody Mon Jun 22 04:57: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 2DA701A0178; Mon, 22 Jun 2015 04:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 nWYyWsXhDJLR; Mon, 22 Jun 2015 04:57:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD56D1A0163; Mon, 22 Jun 2015 04:57:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150622115754.16811.17812.idtracker@ietfa.amsl.com> Date: Mon, 22 Jun 2015 04:57:54 -0700 Archived-At: Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) 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, 22 Jun 2015 11:57:56 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-opsawg-vmm-mib-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I found the SecDir review to be interesting, raising a point of clarification specific to this draft and not the agreed boilerplate text. Since there was confusion by the reader as to the access possibilities and where this mib is used, I think it's worth adding a sentence with the clarifying point from the discussion. How about: This MIB module is typically implemented on the hypervisor not inside a virtual machine. Virtual machines, possibly under other administrative domains, would not have access to this mib as the SNMP service would typically operate in a separate management network. https://www.ietf.org/mail-archive/web/secdir/current/msg05705.html https://www.ietf.org/mail-archive/web/secdir/current/msg05706.html The suggested text, or something similar might fit into the introduction to limit the scope or after paragraph 2 in Section 3. From nobody Mon Jun 22 07:31: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 DE9FB1ACD4C for ; Mon, 22 Jun 2015 07:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKBhJs0lwB0S for ; Mon, 22 Jun 2015 07:30:58 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 50AE31ACD6B for ; Mon, 22 Jun 2015 07:30:57 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5MEUe72018194; Mon, 22 Jun 2015 10:30:51 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: joel jaeggli , "opsawg@ietf.org" Thread-Topic: [OPSAWG] draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 about to send to the rfc editor. Thread-Index: AQHQqYa5kfKjaU16v0qXxEuI7si7hJ24nPsA Date: Mon, 22 Jun 2015 14:30:49 +0000 Message-ID: References: <55825564.5080203@bogus.com> In-Reply-To: <55825564.5080203@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3517813842_35787168" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-22_02:2015-06-22,2015-06-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506220243 Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 about to send to the rfc editor. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 14:31:05 -0000 --B_3517813842_35787168 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 6/18/15, 1:21 , "joel jaeggli" wrote: >Stephen Farrell's comment ( and former dicuss) I think should be food >for thought and I'd like if possible to briefly discuss it. It has already been discussed (briefly), both among the designers, and with the wider audience, including Stephen. We evaluated the arguments (and their accuracy), weighted them against the other reasons (such as providing a standardized auth method for standardized hashes), and decided what should stay in the draft. In summary, the decision was to provide a mandatory method, but in compliance with the standard SHA-2 specs define optional mechanisms pairing with the SHA-2 hash family members. Reason: those who for whatever reason need a hash from SHA-2 family, would have a *standard* way to use it within this spec. Is there anything not covered in the arguments Stephen made (some of which I disagree with, but it=E2=80=99s besides the point) and my answer above? >------ >I'm a yes on this, but am still holding my nose:-) > >The yes is because it's a fine thing to make sure that up-to-date >options for securing protocols are available > >The nose-holding is because defining multiple options that >aren't significantly different in strength (if one assumes that >key management is the likely weakest link) is a bad plan. > >In case it helps, my main logic for not wanting all these >options is that it is overwhelmingly more likely that the >code to switch between them or react to which you've received >or to configure things will (due to bugs etc.) weaken >security much much much more than the existence of more >than one of these options could ever strengthen security. >(Put another way the probability of a security bug due >to adding N things here is far far higher than the >probability that having N things saves the day when N-1 >of them are no longer considered good crypto at some >point.) > >So by defining more of these you are doing worse than >if you only defined one of these. (The fact that all sha2 >digests have the same internal structure is part of but >not all of this argument.) > >On truncation, I'd argue that if that was a significant >benefit then it'd be used everywhere and it is not. In >fact I don't believe truncation is used anywhere else >when there's no protocol (e.g. PDU/fragmentation) issue >that causes us to want shorter MACs. > >I also believe that even those who for truncation would >agree that the benefit of reasonable-length truncation is >definitely an insignificant benefit, if any, and would >also agree that that's a matter of taste when it comes >to sha2 variants of hmac (assuming the protocol can live >with full length, as in this case). > >Bottom line: Discuss is cleared and I'm out of the way, but >with a heartfelt plea that you ditch all of these but one. And >then ditch truncation too. And so end up with just adding >hmac-sha2 as many other protocols have done. >------- > >so there's a plea for limiting the scope of options, if someone feels >very strongly that this is important to address I would take that under >advisement. on the other hand reasoned countervailing arguements would >also be fine but are certainly not critical. --B_3517813842_35787168 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKE5SxSwAAAABE8TANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1MDYxNTE2MjQzOVoXDTE2MDYxNDE2MjQzOVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0tVFZOYvbDipiXfjylg0yIORem8AMZ4UQJ7EM2BI8 jKLj/h3RwH4w2DOMdepALLUqscSrpX6HPbo80M1O0cSSIYcYl8wQzDAMmvoD3HWbupwSXEPf eRtBo26jAvsDkOp46TPu40Pu61AkHx4vIgqU7XkofKhow18Ka/9ZkJ+oSnLK6Xy9+n8JiViO kTm2NjyF+CcpAobwZ3lBepHihvK3EilYR6V1EHQb+Y+2aWtexkFzBNXaN7i4Sdzq+LNSzCON DDDnRxA2c/B/p7MBDzocaigPxmKOHcE5eamxCgpJEUVCEALzeVZxcYURDJw68tZ90pJSLuw7 r6iigykQbRINAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUQzxm8xAhtcoaGyRStaMMhrmd7/Mw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAI8vbC+RZJEH0jhe5e9w F18xYCquDo5kxkoD83qYcVPVFYPnjuAvZ6o9ENa3F0GiAjFVm6HcUbm0zeWT6ZDYIrbh7GRM 4IO8pD9ziwvLIx8rvLvUhiBpsZvznVOWX1yGC0UkIKyiseAszczAYFVJonKB8jDRnxgFlPlo mFUaDtjL86cyp+pHc+ffUVyqMxacABFutJJ72HcK7tIf2gnh2qLdKToiTkDIWT+b1RrkQPSr Gr0YapAC5PgHd/RRY75FHdW/OEQOFimouKnBc5F2VsDJg0Ae9i0+nJPWwSpoXe0ISqIUMO47 Ei6ySfHR2mjymbByxmT5W3gAT3M2gyOd/XUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKKHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZ y/m+7FeYfCo3XYrNqx6/3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Y c0tmMzf5MXBrsub0nUyJeDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7L or1oLWSxNNUyp98gC4EpdHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOW IZULMaAc9JJEq8ctns9mGIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZ YEZ/AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSm i1Ti9F2f2/Are2a7a9E/IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adM wccDlKSR2uIDsiA7jodiTxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zP nWU1nWZBbJR7cLKgUTaEiQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4 kQr5teUVUNDoCj02x781GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+ Xdmbcd3OH6y8fNl1mZdXn8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCChOUsUsAAAAARPEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQg+Df/uh3ldyne1NTbs2nwV1oZ4vlRreKwMY8LkxzhQNAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNjIyMTQzMDQyWjANBgkqhkiG9w0BAQEFAASC AQCY+eM9vINW/WDvYy+q1eVANRy0aksoEVDezNyH/ULMIvo64RjltoqGEv7kymnzfxcsjX1k nU5Ua2RoyTVrbyHXuAA4Tw9TGzFrWf5E3n877Clc02N368Uf/3POVS3zcCuOoI/ir4hoWGAr feXkx20QfSQD5YSZKqEcrPOPkW7KaCx/8Og/XYRvWcLD+tqt/VXxl3rdaIObmWyp02XpS+wy OWlUDmY3yeqrlH7OBR0g0g/VzOFxoqGqSPiSq3vQ65//KW6CYbRQFOSW7lFsPVGnHbOKCZxg kPi6O/P0wax1TmrqSsFmD0RlOkIGvV+cQT8mHMfPmZLwDiHIk2PllqN2 --B_3517813842_35787168-- From nobody Mon Jun 22 09: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 0207F1AD35B; Mon, 22 Jun 2015 09:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 fDkIdJA3xZzF; Mon, 22 Jun 2015 09:58:55 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id E9F851AD35A; Mon, 22 Jun 2015 09:58:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rICS1z2DUfWK+rtmiAmnYd6FVDBexqN7/wM6T3qHnm/mATzoy3eDmiJ55RfZ5q7o; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Z753U-0004XE-Tk; Mon, 22 Jun 2015 12:58:44 -0400 Received: from 76.254.49.226 by webmail.earthlink.net with HTTP; Mon, 22 Jun 2015 12:58:44 -0400 Message-ID: <11802196.1434992324923.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Mon, 22 Jun 2015 09:58:44 -0700 (GMT-07:00) From: Randy Presuhn To: Kathleen Moriarty , The IESG Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba02bd25c05bfe7294af375f71c2131d0de350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 Archived-At: Cc: draft-ietf-opsawg-vmm-mib.ad@ietf.org, draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, opsawg-chairs@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 16:58:57 -0000 Hi - >From: Kathleen Moriarty >Sent: Jun 22, 2015 4:57 AM >To: The IESG >Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org >Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) ... >I found the SecDir review to be interesting, raising a point of >clarification specific to this draft and not the agreed boilerplate text. > Since there was confusion by the reader as to the access possibilities >and where this mib is used, I think it's worth adding a sentence with the >clarifying point from the discussion. How about: > >This MIB module is typically implemented on the hypervisor not inside a >virtual machine. Virtual machines, possibly under other administrative >domains, would not have access to this mib as the SNMP service would >typically operate in a separate management network. > >https://www.ietf.org/mail-archive/web/secdir/current/msg05705.html >https://www.ietf.org/mail-archive/web/secdir/current/msg05706.html > >The suggested text, or something similar might fit into the introduction >to limit the scope or after paragraph 2 in Section 3. If I understand the concern correctly, I'd suggest this text as an alternative. Instrumentation for this MIB module is typically implemented within the hypervisor for two reasons. First, that is where the necessary information is most readily available. Second, because individual virtual machines can be under other administrative domains and are thus not necessarily trusted by the hypervisor, there is no assurance that a given virtual machine will even contain supporting instrumentation, much less make it available in a trustworthy manner. Randy From nobody Mon Jun 22 12:09: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 7361A1A877C; Mon, 22 Jun 2015 12:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Fv-PEk5qeIA3; Mon, 22 Jun 2015 12:09:00 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5251A8795; Mon, 22 Jun 2015 12:08:46 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 8372128BC0; Mon, 22 Jun 2015 12:08:46 -0700 (PDT) Received: from EX13-CAS-002.vmware.com (EX13-CAS-002.vmware.com [10.113.191.52]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 7D5FB402BC; Mon, 22 Jun 2015 12:08:46 -0700 (PDT) Received: from EX13-MBX-032.vmware.com (10.113.191.72) by EX13-MBX-017.vmware.com (10.113.191.37) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 22 Jun 2015 12:08:44 -0700 Received: from EX13-MBX-020.vmware.com (10.113.191.40) by EX13-MBX-032.vmware.com (10.113.191.72) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 22 Jun 2015 12:08:38 -0700 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; Mon, 22 Jun 2015 12:08:20 -0700 From: Michael MacFaden To: Kathleen Moriarty , The IESG , Randy Presuhn Thread-Topic: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) Thread-Index: AQHQrQy7NbzEgj5a9Uy6QA+wOIFVCZ244L8h Date: Mon, 22 Jun 2015 19:08:20 +0000 Message-ID: <2541017878654c65beca7ec07a208b58@EX13-MBX-020.vmware.com> References: <11802196.1434992324923.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> In-Reply-To: <11802196.1434992324923.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.ad@ietf.org" , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "opsawg-chairs@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 19:09:01 -0000 Agree there should be some warning here. But if this text is intended for t= hose who implement it=0A= (like me) then I'd prefer to make it clear as mud what the issue is:=0A= =0A= Any implementation of this MIB module in an agent where the Virtual Machi= nes being monitored =0A= have access to this very agent or this MIB module creates an attack vecto= r on the system or on=0A= any other VM hosted by this system. =0A= =0A= Mike MacFaden=0A= From nobody Mon Jun 22 12:20: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 B4C3F1A88CF; Mon, 22 Jun 2015 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqW57oH4ljoX; Mon, 22 Jun 2015 12:19:44 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id C61811A88D2; Mon, 22 Jun 2015 12:19:43 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5MJJgmP005470; Mon, 22 Jun 2015 15:19:42 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Michael MacFaden , Kathleen Moriarty , The IESG , Randy Presuhn Thread-Topic: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) Thread-Index: AdCtIGOecEULplOqdUGaNvJX7P2yyQ== Date: Mon, 22 Jun 2015 19:19:41 +0000 Message-ID: <20150622191949.17764416.46013.4703@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1306795457==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-22_04:2015-06-22,2015-06-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506220322 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" , "opsawg-chairs@ietf.org" , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 19:19:48 -0000 --===============1306795457== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Anything more specific regarding what the potential issues are? =E2=80=8EBe= sides "adding an =E2=80=8Einterface adds an attack surface"? Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Michael MacFaden=E2=80=8E Sent: Monday, June 22, 2015 15:09 To: Kathleen Moriarty; The IESG; Randy Presuhn Cc: draft-ietf-opsawg-vmm-mib.ad@ietf.org; draft-ietf-opsawg-vmm-mib.shephe= rd@ietf.org; opsawg-chairs@ietf.org; draft-ietf-opsawg-vmm-mib@ietf.org; op= sawg@ietf.org Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg= -vmm-mib-03: (with COMMENT) Agree there should be some warning here. But if this text is intended for t= hose who implement it (like me) then I'd prefer to make it clear as mud what the issue is: Any implementation of this MIB module in an agent where the Virtual Machine= s being monitored=20 have access to this very agent or this MIB module creates an attack vector = on the system or on any other VM hosted by this system.=20 Mike MacFaden _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============1306795457== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYyMjE5MTkyN1owLwYJKoZIhvcNAQkEMSIEIMfkUhiCrpbG gYnwd6742Lw1FOvshLGHB3tOWsCDOoaRMAsGCSqGSIb3DQEBCwSCAQBxIL8feo/6bezFK/TBxtdn QR2+X5vehJyzJssE6QybdjFP30mEvbRVI7In3Csx9kDSMJ8Ey0VnF1yDVMp8T1Q9UPckEi7Ez1Ex PADt/mpSlvZ78rQOijQuvMxj8q7oP9qHbx32Ec9uOWcysKZKozaxnuHiXmjsePZKX6v1pq5BkvlR uScFkWwPVJ4GL+YHqzSwPjYR6jXkldR1ntb9NsC3+Po2TL8bsxN9y0EZ/YW+xYMcSqZUXXHJnycJ RAwugUDic6d273Ls10xAoDaNrPpdgAzAGTD/xV/oiJxuigWDjtIm78xmsFumvIkknd8xKcsChUoM 1AuCEvOk3uvwuF+LAAAAAAAA --===============1306795457==-- From nobody Mon Jun 22 12:45: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 0388B1A1A06; Mon, 22 Jun 2015 12:45:23 -0700 (PDT) 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 q7Ce21mJaSpU; Mon, 22 Jun 2015 12:45:21 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c: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 51FD61A001C; Mon, 22 Jun 2015 12:45:21 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so85501896wic.0; Mon, 22 Jun 2015 12:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xLHt2xJIy/aqOJ9eiDwf7leBApI4q/Y8fbtoe6gY56c=; b=C0zgIbssjOPA6sWEeT2pUk9JiXhSEWxlhqmBn2Fkqp6KLPT5d+ZPgNQ3MRJjmJFOLo ljxXWPi6BJx21Q0Ko6AZqTV9SEcxsGkNaKCcuowxboUgVGND65TSifRx3rAeic/rG7lo YGcMyhK/kUZYGKmy2BCyYZ0+anor3TNbdutHvRWOyzV0jNS4qj+q/x9Pbyfu5+5QBHsU xQRdbEOCR8MMfXOGpfdDpdTp53udgFto7yGDgd1PkRDGdcP5dk8DkbLZ6yag1NcyQcCp ydjHYLiAMGOv0HoUVtas/skzDnMRGQDv0xwM9rbVuD1VFG1nEKToX5GBtxitud5JEc0P rcog== X-Received: by 10.194.203.138 with SMTP id kq10mr53091669wjc.124.1435002320103; Mon, 22 Jun 2015 12:45:20 -0700 (PDT) Received: from [10.200.6.61] ([46.218.164.216]) by mx.google.com with ESMTPSA id ha4sm18360789wib.0.2015.06.22.12.45.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 12:45:19 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <2541017878654c65beca7ec07a208b58@EX13-MBX-020.vmware.com> Date: Mon, 22 Jun 2015 21:45:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11802196.1434992324923.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> <2541017878654c65beca7ec07a208b58@EX13-MBX-020.vmware.com> To: Michael MacFaden Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , Randy Presuhn , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 19:45:23 -0000 Hi Mike, Sent from my iPhone > On Jun 22, 2015, at 9:08 PM, Michael MacFaden wrote: >=20 > Agree there should be some warning here. But if this text is intended for t= hose who implement it > (like me) then I'd prefer to make it clear as mud what the issue is: >=20 > Any implementation of this MIB module in an agent where the Virtual Machi= nes being monitored=20 > have access to this very agent or this MIB module creates an attack vecto= r on the system or on > any other VM hosted by this system.=20 Yes and one of the responses to the SecDir review said this mib would just b= e on the hypervisor. It also said the virtual images managed by the hypervi= sor typically does not have access to the management connection for SNMP to t= he hypervisor, limiting the risk. Shouldn't the text include guidance that makes this clear (where this mib is= and the reality of whether or not it's a risk from managed virtual images)?= Recommending a separate management connection is one way to do that. Thanks, Kathleen=20 >=20 > Mike MacFaden From nobody Mon Jun 22 12:49: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 1DE8B1A8790; Mon, 22 Jun 2015 12:49:28 -0700 (PDT) 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 QMV_LyM2sKHK; Mon, 22 Jun 2015 12:49:20 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93F51A876E; Mon, 22 Jun 2015 12:49:19 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so86514558wic.1; Mon, 22 Jun 2015 12:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7hKPUjOSYtcKkeiigKfclZWAjXXRbjrvd/nfV7+sOps=; b=MUXvWek49/5EFrH1qkAT5itZuI+WI2y5sKiy051Y5G6MJZpyleGfkjJAYjKAqdGvDN /xvqy7yXy9RLqAaLfpe03BdaLqZJqunuE5VCy2zkyMc87EXQUHVQMmAPmKUmVoE++Qdy a1//4u3dSohfV9TPYiR0lgoVj5vFB6Ca2neQaugBmnn+LdpXfGFvK48YLDuT/w+QmxVB SiwROqD1zGjscPiNr+stBgPA9/+7UAB83HKXlLm71YslNPw0Vx/sPqgY1YnQGZ0ZN1qT FTM84A4g2NZbUKe36oQVSp4gHVgaXza9ENzXVW1Hq8GbOFvXUfB00ZcnoA7+uqg8+OTo 0dZQ== X-Received: by 10.180.94.39 with SMTP id cz7mr34256239wib.66.1435002558561; Mon, 22 Jun 2015 12:49:18 -0700 (PDT) Received: from [10.200.6.61] ([46.218.164.216]) by mx.google.com with ESMTPSA id i6sm32092690wjf.29.2015.06.22.12.49.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 12:49:18 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <11802196.1434992324923.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Mon, 22 Jun 2015 21:49:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BAB0FAA-9537-46DF-97E4-058C0D8D1519@gmail.com> References: <11802196.1434992324923.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> To: Randy Presuhn Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.ad@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 19:49:28 -0000 Hi, Sent from my iPhone > On Jun 22, 2015, at 6:58 PM, Randy Presuhn w= rote: >=20 > Hi - >=20 >> From: Kathleen Moriarty >> Sent: Jun 22, 2015 4:57 AM >> To: The IESG >> Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, draft-ietf-opsawg-vmm-mi= b@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-vmm-m= ib.ad@ietf.org >> Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-v= mm-mib-03: (with COMMENT) > ... >> I found the SecDir review to be interesting, raising a point of >> clarification specific to this draft and not the agreed boilerplate text.= >> Since there was confusion by the reader as to the access possibilities >> and where this mib is used, I think it's worth adding a sentence with the= >> clarifying point from the discussion. How about: >>=20 >> This MIB module is typically implemented on the hypervisor not inside a >> virtual machine. Virtual machines, possibly under other administrative >> domains, would not have access to this mib as the SNMP service would >> typically operate in a separate management network. >>=20 >> https://www.ietf.org/mail-archive/web/secdir/current/msg05705.html=20 >> https://www.ietf.org/mail-archive/web/secdir/current/msg05706.html >>=20 >> The suggested text, or something similar might fit into the introduction >> to limit the scope or after paragraph 2 in Section 3. >=20 > If I understand the concern correctly, I'd suggest this text as > an alternative. >=20 > Instrumentation for this MIB module is typically implemented > within the hypervisor for two reasons. First, that is where > the necessary information is most readily available. Second, > because individual virtual machines can be under other > administrative domains and are thus not necessarily trusted > by the hypervisor, there is no assurance that a given virtual > machine will even contain supporting instrumentation, > much less make it available in a trustworthy manner. >=20 This text is close to what I was looking for, thanks. It doesn't explicitly= say that the managed virtual machines would not have access to the SNMP man= agement interface clearly it just says they aren't trusted. Some recommendat= ion would be helpful. Thank you, Kathleen=20 > Randy From nobody Mon Jun 22 13:05: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 66F9B1ACDD2; Mon, 22 Jun 2015 13:05:00 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 AsyZ59tY2nX1; Mon, 22 Jun 2015 13:04:58 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id B4F4C1ACDD0; Mon, 22 Jun 2015 13:04:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Qh5YgVpgbxPturnFaP1T5w76mKlEMBuGZ4ca5fAlG9V+pxpkDh1qIN70JuS+BB8z; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Z77xh-0007s0-GI; Mon, 22 Jun 2015 16:04:57 -0400 Received: from 76.254.53.144 by webmail.earthlink.net with HTTP; Mon, 22 Jun 2015 16:04:56 -0400 Message-ID: <6497107.1435003497233.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Mon, 22 Jun 2015 13:04:56 -0700 (GMT-07:00) From: Randy Presuhn To: Kathleen Moriarty , Michael MacFaden Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba03c8969e78fe8d842c8415847a1e1c2af350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , Randy Presuhn , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 20:05:00 -0000 Hi - >From: Kathleen Moriarty >Sent: Jun 22, 2015 12:45 PM >To: Michael MacFaden >Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , Randy Presuhn , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) > >Hi Mike, > >Sent from my iPhone > >> On Jun 22, 2015, at 9:08 PM, Michael MacFaden wrote: >> >> Agree there should be some warning here. But if this text is intended for those who implement it >> (like me) then I'd prefer to make it clear as mud what the issue is: >> >> Any implementation of this MIB module in an agent where the Virtual Machines being monitored >> have access to this very agent or this MIB module creates an attack vector on the system or on >> any other VM hosted by this system. > >Yes and one of the responses to the SecDir review said this mib would just be on the hypervisor. It also said the virtual images managed by the hypervisor typically does not have access to the management connection for SNMP to the hypervisor, limiting the risk. > >Shouldn't the text include guidance that makes this clear (where this mib is and the reality of whether or not it's a risk from managed virtual images)? > >Recommending a separate management connection is one way to do that. I'm missing something here. Why is a monitored VM (where the MIB instrumentation is external to the VM) different from any other threat? It seems to me that "access to the management connection" is a red herring - the privacy protocol, along with authentication and access control (VACM) should just be left to do their job. Randy From nobody Mon Jun 22 13:12: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 C5A2B1ACF16; Mon, 22 Jun 2015 13:12:48 -0700 (PDT) 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 CuIVFosm4c8E; Mon, 22 Jun 2015 13:12:47 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C992D1ACF09; Mon, 22 Jun 2015 13:12:46 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so87130952wic.1; Mon, 22 Jun 2015 13:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ojC7RO75nqLDFCmM9rL3Ibh2ak9aWdBt1Jiq3JC5suY=; b=TZCaiZTGvKbEa+RZ4v0np8IqLSaBPbogmP8yuEgEskWu/o0qanjrA8PsT831HHDYhA aVcjIwbZihcQ8l8aVLlnLh1n6xdBUyyzRMfcga5BUACbkkwP7i7t5glLK8OrLZUohaZd ge6MGdFUcgdozABjyP0qbScSxGDd6PBfgco6GLFVgWb/W+jedaaq9ByMdcRm5X1Mv//B DHWrPlkaMqJzk4A1QFlv7+t6dYeFR4Mnu09uzd7GO7jBdjDEkRX60fWy1KTqaaeG3aXh QQrb71yVfMyq571mvKe6I6Rj29qvrsVfWAdzieMzRtJPgCgtj9gHsojkonyJ5gIZArNA UgYg== MIME-Version: 1.0 X-Received: by 10.180.86.168 with SMTP id q8mr34128121wiz.80.1435003965603; Mon, 22 Jun 2015 13:12:45 -0700 (PDT) Received: by 10.28.188.134 with HTTP; Mon, 22 Jun 2015 13:12:45 -0700 (PDT) In-Reply-To: <6497107.1435003497233.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> References: <6497107.1435003497233.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Mon, 22 Jun 2015 16:12:45 -0400 Message-ID: From: Kathleen Moriarty To: Randy Presuhn Content-Type: multipart/alternative; boundary=bcaec55550309f0626051920e592 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 20:12:48 -0000 --bcaec55550309f0626051920e592 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015 at 4:04 PM, Randy Presuhn wrote: > Hi - > > >From: Kathleen Moriarty > >Sent: Jun 22, 2015 12:45 PM > >To: Michael MacFaden > >Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" < > draft-ietf-opsawg-vmm-mib.shepherd@ietf.org>, Randy Presuhn < > randy_presuhn@mindspring.com>, "draft-ietf-opsawg-vmm-mib@ietf.org" < > draft-ietf-opsawg-vmm-mib@ietf.org>, "opsawg-chairs@ietf.org" < > opsawg-chairs@ietf.org>, The IESG , "opsawg@ietf.org" < > opsawg@ietf.org>, "draft-ietf-opsawg-vmm-mib.ad@ietf.org" < > draft-ietf-opsawg-vmm-mib.ad@ietf.org> > >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on > draft-ietf-opsawg-vmm-mib-03: (with COMMENT) > > > >Hi Mike, > > > >Sent from my iPhone > > > >> On Jun 22, 2015, at 9:08 PM, Michael MacFaden wrote: > >> > >> Agree there should be some warning here. But if this text is intended > for those who implement it > >> (like me) then I'd prefer to make it clear as mud what the issue is: > >> > >> Any implementation of this MIB module in an agent where the Virtual > Machines being monitored > >> have access to this very agent or this MIB module creates an attack > vector on the system or on > >> any other VM hosted by this system. > > > >Yes and one of the responses to the SecDir review said this mib would > just be on the hypervisor. It also said the virtual images managed by the > hypervisor typically does not have access to the management connection for > SNMP to the hypervisor, limiting the risk. > > > >Shouldn't the text include guidance that makes this clear (where this mib > is and the reality of whether or not it's a risk from managed virtual > images)? > > > >Recommending a separate management connection is one way to do that. > > I'm missing something here. Why is a monitored VM (where the > MIB instrumentation is external to the VM) different from any other > threat? It seems to me that "access to the management connection" > is a red herring - the privacy protocol, along with authentication > and access control (VACM) should just be left to do their job. > This came up in the SecDir review. I was happy with the response provided via email in how it was put out-of-scope. The draft itself does not have the explanation offered and I think it would be helpful to the reader in case the same question comes up later. I thought it was a reasonable question given the content of the draft and possible threat space. Thanks. > > Randy > -- Best regards, Kathleen --bcaec55550309f0626051920e592 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 22, 2015 at 4:04 PM, Randy Presuhn <randy_presu= hn@mindspring.com> wrote:
H= i -

>From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
>Sent: Jun 22, 2015 12:45 PM
>To: Michael MacFaden <mrm@vmware.c= om>
>Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" <draft-ietf-opsawg-vmm-mib.s= hepherd@ietf.org>, Randy Presuhn <randy_presuhn@mindspring.com>, "draft-ietf-opsawg-vmm-mib@ietf.org<= /a>" <draft-i= etf-opsawg-vmm-mib@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, The IESG <iesg@ietf.org>, "opsawg@ietf.org" <opsa= wg@ietf.org>, "draft-ietf-opsawg-vmm-mib.ad@ietf.org" <draft-ietf-opsawg-vmm-mib.ad@iet= f.org>
>Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-iet= f-opsawg-vmm-mib-03: (with COMMENT)
>
>Hi Mike,
>
>Sent from my iPhone
>
>> On Jun 22, 2015, at 9:08 PM, Michael MacFad= en <mrm@vmware.com> wrote:
>>
>> Agree there should be some warning here. But if this text is inten= ded for those who implement it
>> (like me) then I'd prefer to=C2=A0 make it clear as mud what t= he issue is:
>>
>>=C2=A0 Any implementation of this MIB module in an agent where the = Virtual Machines being monitored
>>=C2=A0 have access to this very agent or this MIB module creates an= attack vector on the system or on
>>=C2=A0 any other VM hosted by this system.
>
>Yes and one of the responses to the SecDir review said this mib would j= ust be on the hypervisor.=C2=A0 It also said the virtual images managed by = the hypervisor typically does not have access to the management connection = for SNMP to the hypervisor, limiting the risk.
>
>Shouldn't the text include guidance that makes this clear (where th= is mib is and the reality of whether or not it's a risk from managed vi= rtual images)?
>
>Recommending a separate management connection is one way to do that.
I'm missing something here.=C2=A0 Why is a monitored VM (wh= ere the
MIB instrumentation is external to the VM) different from any other
threat?=C2=A0 It seems to me that "access to the management connection= "
is a red herring - the privacy protocol, along with authentication
and access control (VACM) should just be left to do their job.

This came up in the SecDir review.=C2=A0 I was happ= y with the response provided via email in how it was put out-of-scope.=C2= =A0 The draft itself does not have the explanation offered and I think it w= ould be helpful to the reader in case the same question comes up later.=C2= =A0 I thought it was a reasonable question given the content of the draft a= nd possible threat space.

Thanks.

Randy



--

Best regards,
Kathleen
--bcaec55550309f0626051920e592-- From nobody Mon Jun 22 13:18: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 080FE1AD059; Mon, 22 Jun 2015 13:18:19 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 wDsKMopeBk56; Mon, 22 Jun 2015 13:18:17 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3C57F1A88B1; Mon, 22 Jun 2015 13:18:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dIhF9DBGteYcVlwht5NjiV49FzETmVX5kZouWfbmg3VAY/oxtU+69jRzCh4fiaVs; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Z78Aa-0000AG-Jy; Mon, 22 Jun 2015 16:18:16 -0400 Received: from 76.254.53.144 by webmail.earthlink.net with HTTP; Mon, 22 Jun 2015 16:18:16 -0400 Message-ID: <18951724.1435004296429.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Mon, 22 Jun 2015 13:18:16 -0700 (GMT-07:00) From: Randy Presuhn To: Kathleen Moriarty Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba04bee5a37159a21a8fcaf58f82119dc32350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.ad@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 20:18:19 -0000 Hi - >From: Kathleen Moriarty >Sent: Jun 22, 2015 12:49 PM >To: Randy Presuhn >Cc: The IESG , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) > >Hi, > >Sent from my iPhone > >> On Jun 22, 2015, at 6:58 PM, Randy Presuhn wrote: >> >> Hi - >> >>> From: Kathleen Moriarty >>> Sent: Jun 22, 2015 4:57 AM >>> To: The IESG >>> Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org >>> Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) >> ... >>> I found the SecDir review to be interesting, raising a point of >>> clarification specific to this draft and not the agreed boilerplate text. >>> Since there was confusion by the reader as to the access possibilities >>> and where this mib is used, I think it's worth adding a sentence with the >>> clarifying point from the discussion. How about: >>> >>> This MIB module is typically implemented on the hypervisor not inside a >>> virtual machine. Virtual machines, possibly under other administrative >>> domains, would not have access to this mib as the SNMP service would >>> typically operate in a separate management network. >>> >>> https://www.ietf.org/mail-archive/web/secdir/current/msg05705.html >>> https://www.ietf.org/mail-archive/web/secdir/current/msg05706.html >>> >>> The suggested text, or something similar might fit into the introduction >>> to limit the scope or after paragraph 2 in Section 3. >> >> If I understand the concern correctly, I'd suggest this text as >> an alternative. >> >> Instrumentation for this MIB module is typically implemented >> within the hypervisor for two reasons. First, that is where >> the necessary information is most readily available. Second, >> because individual virtual machines can be under other >> administrative domains and are thus not necessarily trusted >> by the hypervisor, there is no assurance that a given virtual >> machine will even contain supporting instrumentation, >> much less make it available in a trustworthy manner. >> >This text is close to what I was looking for, thanks. It doesn't >explicitly say that the managed virtual machines would not have >access to the SNMP management interface clearly it just says they >aren't trusted. Some recommendation would be helpful. I guess what I'm missing here is that I don't see how a managed virtual machine is different from any other managed resource. Whether a given managed virtual machine has been granted access (via VACM) and has the necessary network connectivity to reach the SNMP engine is a question of what that virtual machine is supposed to do and of security/administrative policy. For example, if that VM is hosting implementations of some of the distributed management MIB modules, it would be perfectly reasonable for an entity running on it to be an authorized user granted access by VACM to this MIB module. If, on the other hand, that VM hosts malware for observation purposes, one would probably not allow it to monitor or configure the hypervisor, and might choose to severely limit its connectivity. I don't see how this is substantially different from any other managed application. Randy From nobody Mon Jun 22 13:23: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 EDE571AD06D; Mon, 22 Jun 2015 13:23:54 -0700 (PDT) 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 jj_iVctS6tdy; Mon, 22 Jun 2015 13:23:52 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC19E1AD06E; Mon, 22 Jun 2015 13:23:51 -0700 (PDT) Received: by wgck11 with SMTP id k11so23793052wgc.0; Mon, 22 Jun 2015 13:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p66mBR5KimBbilHuzHbPq6bYF/cSQvKKXVvvh171EZM=; b=UMvnpTt5iQbCItcuE+sIclHPISJbbJ1q+F7aN4FqmMLQ1oiv2i5wei0VReccjSzJUp oheTefJqghc5eXZDgA4v1Q59XTHUA0Es73u5eIoXoAE9z6vhByaup2iUygtSs09IC/6j Ys+a965t43S2dW5ObTAH4OfdRTfzyp+nuM/V7jKzfLTSGthu8XPsOH8gbTHy/xC/8Dgd eW7KXPSlquh6SV+Hf/9yZLZQ6P7jSwhHepNIFp1HFK8a/jOEwPPxxM0nMvfQ0gFcJTgP 1WRuUyp3KzW/RB+qHCK8c8rmSIDozOAdLkyTFMqEVPbmx3XnK+BPjZ0t/MrcNQWdvGtk iWOA== MIME-Version: 1.0 X-Received: by 10.180.96.167 with SMTP id dt7mr4290581wib.80.1435004630579; Mon, 22 Jun 2015 13:23:50 -0700 (PDT) Received: by 10.28.188.134 with HTTP; Mon, 22 Jun 2015 13:23:50 -0700 (PDT) In-Reply-To: <18951724.1435004296429.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> References: <18951724.1435004296429.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Mon, 22 Jun 2015 16:23:50 -0400 Message-ID: From: Kathleen Moriarty To: Randy Presuhn Content-Type: multipart/alternative; boundary=f46d043c070041c1ea0519210dcf Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.ad@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 20:23:55 -0000 --f46d043c070041c1ea0519210dcf Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015 at 4:18 PM, Randy Presuhn wrote: > Hi - > > >From: Kathleen Moriarty > >Sent: Jun 22, 2015 12:49 PM > >To: Randy Presuhn > >Cc: The IESG , " > draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" < > draft-ietf-opsawg-vmm-mib.shepherd@ietf.org>, " > draft-ietf-opsawg-vmm-mib@ietf.org" , > "opsawg-chairs@ietf.org" , "opsawg@ietf.org" < > opsawg@ietf.org>, "draft-ietf-opsawg-vmm-mib.ad@ietf.org" < > draft-ietf-opsawg-vmm-mib.ad@ietf.org> > >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on > draft-ietf-opsawg-vmm-mib-03: (with COMMENT) > > > >Hi, > > > >Sent from my iPhone > > > >> On Jun 22, 2015, at 6:58 PM, Randy Presuhn < > randy_presuhn@mindspring.com> wrote: > >> > >> Hi - > >> > >>> From: Kathleen Moriarty > >>> Sent: Jun 22, 2015 4:57 AM > >>> To: The IESG > >>> Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, > draft-ietf-opsawg-vmm-mib@ietf.org, opsawg-chairs@ietf.org, > opsawg@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org > >>> Subject: [OPSAWG] Kathleen Moriarty's No Objection on > draft-ietf-opsawg-vmm-mib-03: (with COMMENT) > >> ... > >>> I found the SecDir review to be interesting, raising a point of > >>> clarification specific to this draft and not the agreed boilerplate > text. > >>> Since there was confusion by the reader as to the access possibilities > >>> and where this mib is used, I think it's worth adding a sentence with > the > >>> clarifying point from the discussion. How about: > >>> > >>> This MIB module is typically implemented on the hypervisor not inside a > >>> virtual machine. Virtual machines, possibly under other administrative > >>> domains, would not have access to this mib as the SNMP service would > >>> typically operate in a separate management network. > >>> > >>> https://www.ietf.org/mail-archive/web/secdir/current/msg05705.html > >>> https://www.ietf.org/mail-archive/web/secdir/current/msg05706.html > >>> > >>> The suggested text, or something similar might fit into the > introduction > >>> to limit the scope or after paragraph 2 in Section 3. > >> > >> If I understand the concern correctly, I'd suggest this text as > >> an alternative. > >> > >> Instrumentation for this MIB module is typically implemented > >> within the hypervisor for two reasons. First, that is where > >> the necessary information is most readily available. Second, > >> because individual virtual machines can be under other > >> administrative domains and are thus not necessarily trusted > >> by the hypervisor, there is no assurance that a given virtual > >> machine will even contain supporting instrumentation, > >> much less make it available in a trustworthy manner. > >> > >This text is close to what I was looking for, thanks. It doesn't > >explicitly say that the managed virtual machines would not have > >access to the SNMP management interface clearly it just says they > >aren't trusted. Some recommendation would be helpful. > > I guess what I'm missing here is that I don't see how a managed > virtual machine is different from any other managed resource. > Whether a given managed virtual machine has been granted access > (via VACM) and has the necessary network connectivity to reach > the SNMP engine is a question of what that virtual machine is > supposed to do and of security/administrative policy. For example, > if that VM is hosting implementations of some of the distributed > management MIB modules, it would be perfectly reasonable for > an entity running on it to be an authorized user granted access > by VACM to this MIB module. If, on the other hand, that VM hosts > malware for observation purposes, one would probably not allow it to > monitor or configure the hypervisor, and might choose to severely > limit its connectivity. I don't see how this is substantially > different from any other managed application. > > There would be a management connection to the virtual machine. Apparently (from a response to the SecDir review previously provided), the management channel is separate for SNMP to the hypervisor. That wasn't readily apparent to the SecDir reviewer or me. You shouldn't be able to use the management channel back from the virtual machine to the hypervisor to exploit the access possible via this mib. Some text to explain this is helpful. Thanks, > Randy > > -- Best regards, Kathleen --f46d043c070041c1ea0519210dcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 22, 2015 at 4:18 PM, Randy Presuhn <randy_presu= hn@mindspring.com> wrote:
<= span class=3D"">Hi -

>From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
>Sent: Jun 22, 2015 12:49 PM
>To: Randy Presuhn <r= andy_presuhn@mindspring.com>
>Cc: The IESG <iesg@ietf.org>= , "draf= t-ietf-opsawg-vmm-mib.shepherd@ietf.org" <draft-ietf-opsawg-vmm-mib.shepher= d@ietf.org>, "draft-ietf-opsawg-vmm-mib@ietf.org" <draft-ietf-opsawg-vmm-mib@ietf.org>= , "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.or= g>, "opsawg@ietf.org&quo= t; <opsawg@ietf.org>, "draft-ietf-opsawg-vm= m-mib.ad@ietf.org" <draft-ietf-opsawg-vmm-mib.ad@ietf.org>
>Subject: Re: [OPSAWG] Kathleen Moriarty's No Objec= tion on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)
>
>Hi,
>
>Sent from my iPhone
>
>> On Jun 22, 2015, at 6:58 PM, Randy Presuhn <randy_presuhn@mindspring.com> wrote: >>
>> Hi -
>>
>>> From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmai= l.com>
>>> Sent: Jun 22, 2015 4:57 AM
>>> To: The IESG <iesg@ietf.or= g>
>>> Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org >>> Subject: [OPSAWG] Kathleen Moriarty's No Objection on draf= t-ietf-opsawg-vmm-mib-03: (with COMMENT)
>> ...
>>> I found the SecDir review to be interesting, raising a point o= f
>>> clarification specific to this draft and not the agreed boiler= plate text.
>>> Since there was confusion by the reader as to the access possi= bilities
>>> and where this mib is used, I think it's worth adding a se= ntence with the
>>> clarifying point from the discussion.=C2=A0 How about:
>>>
>>> This MIB module is typically implemented on the hypervisor not= inside a
>>> virtual machine.=C2=A0 Virtual machines, possibly under other = administrative
>>> domains, would not have access to this mib as the SNMP service= would
>>> typically operate in a separate management network.
>>>
>>> https://www.ietf.org/= mail-archive/web/secdir/current/msg05705.html
>>> https://www.ietf.org/= mail-archive/web/secdir/current/msg05706.html
>>>
>>> The suggested text, or something similar might fit into the in= troduction
>>> to limit the scope or after paragraph 2 in Section 3.
>>
>> If I understand the concern correctly, I'd suggest this text a= s
>> an alternative.
>>
>>=C2=A0 Instrumentation for this MIB module is typically implemented=
>>=C2=A0 within the hypervisor for two reasons.=C2=A0 First, that is = where
>>=C2=A0 the necessary information is most readily available.=C2=A0 S= econd,
>>=C2=A0 because individual virtual machines can be under other
>>=C2=A0 administrative domains and are thus not necessarily trusted<= br> >>=C2=A0 by the hypervisor, there is no assurance that a given virtua= l
>>=C2=A0 machine will even contain supporting instrumentation,
>>=C2=A0 much less make it available in a trustworthy manner.
>>
>This text is close to what I was looking for, thanks.=C2=A0 It doesn= 9;t
>explicitly say that the managed virtual machines would not = have
>access to the SNMP management interface clearly it jus= t says they
>aren't trusted. Some recommendation would be helpful.

I guess what I'm missing here is that I don't see how a mana= ged
virtual machine is different from any other managed resource.
Whether a given managed virtual machine has been granted access
(via VACM) and has the necessary network connectivity to reach
the SNMP engine is a question of what that virtual machine is
supposed to do and of security/administrative policy.=C2=A0 For example, if that VM is hosting implementations of some of the distributed
management MIB modules, it would be perfectly reasonable for
an entity running on it to be an authorized user granted access
by VACM to this MIB module.=C2=A0 If, on the other hand, that VM hosts
malware for observation purposes, one would probably not allow it to
monitor or configure the hypervisor, and might choose to severely
limit its connectivity.=C2=A0 I don't see how this is substantially
different from any other managed application.

There would be a management connection to the virtual machine.=C2= =A0 Apparently (from a response to the SecDir review previously provided), = the management channel is separate for SNMP to the hypervisor.=C2=A0 That w= asn't readily apparent to the SecDir reviewer or me.=C2=A0 You shouldn&= #39;t be able to use the management channel back from the virtual machine t= o the hypervisor to exploit the access possible via this mib.=C2=A0 Some te= xt to explain this is helpful.

Thanks,
<= br>
=C2=A0
Randy




--

Best regards,
Kathleen
--f46d043c070041c1ea0519210dcf-- From nobody Mon Jun 22 14:01: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 01EB21A1A54; Mon, 22 Jun 2015 14:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 PvhAK91ybdbD; Mon, 22 Jun 2015 14:01:01 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id DEACD1A86FD; Mon, 22 Jun 2015 14:00:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bPYnPvwWlHGaSjNsl6mQdAsRCpwmOZOnJM8LwtoWuaXnxQ90fTOpjyHRq5q/d7+O; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Z78pv-0002ar-Ew; Mon, 22 Jun 2015 17:00:59 -0400 Received: from 76.254.53.144 by webmail.earthlink.net with HTTP; Mon, 22 Jun 2015 17:00:58 -0400 Message-ID: <2087814.1435006859224.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Mon, 22 Jun 2015 14:00:58 -0700 (GMT-07:00) From: Randy Presuhn To: Kathleen Moriarty Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 Content-Type: text/html; charset=UTF-8 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba09deef6202ff8630429fbb3ad40e41540350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.ad@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 21:01:03 -0000
Hi -

>From: Kathleen Moriarty
>Sent: Jun 22, 2015 1:23 PM
>To: Randy Presuhn =
>Cc: The IESG , "draft-= ietf-opsawg-vmm-mib.shepherd@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , "opsawg@ietf.= org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org"
>Subject: Re: [OPSAWG] Kathleen Moriarty= 's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)
>
= >On Mon, Jun 22, 2015 at 4:18 PM, Randy Presuhn >> wrote:
>
>> Hi -
>>
>> &= gt;From: Kathleen Moriarty
>> &= gt;Sent: Jun 22, 2015 12:49 PM
>> >To: Randy Presuhn
>> >Cc: The IESG , "
>= ;> draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" <
>> draft-i= etf-opsawg-vmm-mib.shepherd@ietf.org>, "
>> draft-ietf-opsawg-v= mm-mib@ietf.org" ,
>> "opsawg-= chairs@ietf.org" , "opsawg@ietf.org" <
>&g= t; opsawg@ietf.org>, "draft-ietf-opsawg-vmm-mib.ad@ietf.org" <
>= ;> draft-ietf-opsawg-vmm-mib.ad@ietf.org>
>> >Subject: Re= : [OPSAWG] Kathleen Moriarty's No Objection on
>> draft-ietf-opsaw= g-vmm-mib-03: (with COMMENT)
>> >
>> >Hi,
>&g= t; >
>> >Sent from my iPhone
>> >
>> &g= t;> On Jun 22, 2015, at 6:58 PM, Randy Presuhn <
>> randy_pr= esuhn@mindspring.com> wrote:
>> >>
>> >> H= i -
>> >>
>> >>> From: Kathleen Moriarty <= kathleen.moriarty.ietf@gmail.com>
>> >>> Sent: Jun 22, 20= 15 4:57 AM
>> >>> To: The IESG
>>= ; >>> Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org,
>>= draft-ietf-opsawg-vmm-mib@ietf.org, opsawg-chairs@ietf.org,
>> op= sawg@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org
>> >>&g= t; Subject: [OPSAWG] Kathleen Moriarty's No Objection on
>> draft-= ietf-opsawg-vmm-mib-03: (with COMMENT)
>> >> ...
>>= >>> I found the SecDir review to be interesting, raising a point = of
>> >>> clarification specific to this draft and not th= e agreed boilerplate
>> text.
>> >>> Since there= was confusion by the reader as to the access possibilities
>> >= ;>> and where this mib is used, I think it's worth adding a sentence = with
>> the
>> >>> clarifying point from the dis= cussion. How about:
>> >>>
>> >>> This= MIB module is typically implemented on the hypervisor not inside a
>= > >>> virtual machine. Virtual machines, possibly under other = administrative
>> >>> domains, would not have access to t= his mib as the SNMP service would
>> >>> typically operat= e in a separate management network.
>> >>>
>> &g= t;>> https://www.ietf.org/mail-archive/web/secdir/current/msg05705.ht= ml
>> >>> https://www.ietf.org/mail-archive/web/secdir/cu= rrent/msg05706.html
>> >>>
>> >>> The s= uggested text, or something similar might fit into the
>> introduc= tion
>> >>> to limit the scope or after paragraph 2 in Se= ction 3.
>> >>
>> >> If I understand the conc= ern correctly, I'd suggest this text as
>> >> an alternative= .
>> >>
>> >> Instrumentation for this MIB m= odule is typically implemented
>> >> within the hypervisor = for two reasons. First, that is where
>> >> the necessary = information is most readily available. Second,
>> >> becau= se individual virtual machines can be under other
>> >> adm= inistrative domains and are thus not necessarily trusted
>> >&g= t; by the hypervisor, there is no assurance that a given virtual
>&g= t; >> machine will even contain supporting instrumentation,
>&= gt; >> much less make it available in a trustworthy manner.
>&= gt; >>
>> >This text is close to what I was looking for, = thanks. It doesn't
>> >explicitly say that the managed virtual= machines would not have
>> >access to the SNMP management inte= rface clearly it just says they
>> >aren't trusted. Some recomm= endation would be helpful.
>>
>> I guess what I'm missing= here is that I don't see how a managed
>> virtual machine is diff= erent from any other managed resource.
>> Whether a given managed = virtual machine has been granted access
>> (via VACM) and has the = necessary network connectivity to reach
>> the SNMP engine is a qu= estion of what that virtual machine is
>> supposed to do and of se= curity/administrative policy. For example,
>> if that VM is hosti= ng implementations of some of the distributed
>> management MIB mo= dules, it would be perfectly reasonable for
>> an entity running o= n it to be an authorized user granted access
>> by VACM to this MI= B module. If, on the other hand, that VM hosts
>> malware for obs= ervation purposes, one would probably not allow it to
>> monitor o= r configure the hypervisor, and might choose to severely
>> limit = its connectivity. I don't see how this is substantially
>> differ= ent from any other managed application.
>>
> There would be = a management connection to the virtual machine. Apparently
>(from a = response to the SecDir review previously provided), the management
>c= hannel is separate for SNMP to the hypervisor. That wasn't readily
>= apparent to the SecDir reviewer or me. You shouldn't be able to use the>management channel back from the virtual machine to the hypervisor to<= br>>exploit the access possible via this mib. Some text to explain this= is
>helpful.

Sorry, I don't mean to be dense, but I can't pro= vide text to explain
this because this rationale doesn't make any sense = to me at all. I
still don't see how monitoring a not-necessarily-truste= d VM is in
any way different from monitoring any other not-necessarily-t= rusted
resource. Let me explain why this makes no sense to me.

T= here are about two-and-a-half strategies for connecting
MIB module instr= umentation to SNMP engines:

(1) build the instrumentation into the= same process as the SNMP
engine. Straightforward, but becomes a = software configuration
management nightmare.

(2) use a me= chanism such as AgentX to handle the chit-chat between
the master = agent (home to the SNMP engine) and subagents
   (a) inst= rumentation can be built directly into the resources,
   =       implying a certainly level of trust= that the subagent will
        = respond truthfully to get/set, etc.
   (b) instrumen= tation can be built into processes in turn
     = ;    monitor the resources by other means. This is useful         when, for examp= le, one does not have control of the
      = ;   source code for the resource.

2(b) would IMO = be the "obvious" preferred choice for implementing
this MIB module.
<= br>If one uses AgentX as the implementation technology, the protocol
pro= vides the subagent no means of access to other information known
to the = master agent. A malicious subagent (one that impersonates
another) is c= onceivable, but even a malicious subagent doesn't gain
access to existin= g management information of the subagent it is
impersonating - it only l= earns subsequent configuration requests
and what it can glean from index= values present in get/getnext/bulk
requests. None of this is specific = to management of VMs.

If someone uses some homebrew mechanism in pla= ce of AgentX, all bets
are off until there's been an analysis of that me= chanism.  Again, however,
this is true whether VMs are in the pictu= re or not.

Randy
From nobody Mon Jun 22 14:13: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 82B671ACD78; Mon, 22 Jun 2015 14:13:20 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 nki_qYjIMitg; Mon, 22 Jun 2015 14:13:18 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8B24D1A9171; Mon, 22 Jun 2015 14:13:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZYEbRz98E/Y4myT1Df6L0gn9V/RZVTNCHWJduIqVKIb4W7IvusK5LLTxw8dlDv5t; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Z791o-0001ke-Ul; Mon, 22 Jun 2015 17:13:16 -0400 Received: from 76.254.53.144 by webmail.earthlink.net with HTTP; Mon, 22 Jun 2015 17:13:16 -0400 Message-ID: <32973554.1435007596799.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Mon, 22 Jun 2015 14:13:16 -0700 (GMT-07:00) From: Randy Presuhn To: Randy Presuhn , Kathleen Moriarty Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba0dc53a571fc48bbe60cb50697b5442100350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 21:13:20 -0000 Hi - ARRGH! I apologize for sending a blast of HTML gobbledygook. Here's what I intended to say: Sorry, I don't mean to be dense, but I can't provide text to explain this because this rationale doesn't make any sense to me at all. I still don't see how monitoring a not-necessarily- trusted VM is in any way different from monitoring any other not-necessarily-trusted resource. Let me explain why this makes no sense to me. There are about two-and-a-half strategies for connecting MIB module instrumentation to SNMP engines: (1) build the instrumentation into the same process as the SNMP engine. Straightforward, but becomes a software configuration management nightmare. (2) use a mechanism such as AgentX to handle the chit-chat between the master agent (home to the SNMP engine) and subagents (a) instrumentation can be built directly into the resources, implying a certain level of trust that the subagent will respond truthfully to get/set, etc. (b) instrumentation can be built into processes which in turn monitor the resources by other means. This is useful when, for example, one does not have control of the source code for the resource. 2(b) would IMO be the obvious preferred choice for implementing this MIB module. If one uses AgentX as the implementation technology, the protocol provides the subagent no means of access to other information known to the master agent. A malicious subagent (one which impersonates another) is conceivable, but even a malicious subagent doesn't gain access to existing management information of the subagent it is impersonating - it only sees subsequent configuration requests and what it can glean from index values present in get/getnext/bulk requests. None of this is specific to management of VMs. If someone uses some homebrew mechanism in place of AgentX, all bets are off until there's been an analysis of that mechanism. Again, however, this is true whether VMs are in the picture or not. Randy From nobody Mon Jun 22 17:07: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 CE51A1ACEB4; Mon, 22 Jun 2015 17:07:10 -0700 (PDT) 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 4AwkXJXf3uIR; Mon, 22 Jun 2015 17:07:08 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 A57091ACE03; Mon, 22 Jun 2015 17:07:08 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5N075cf010322 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jun 2015 20:07:06 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t5N075cf010322 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1435018026; bh=QEH4xTFiXl6uDjTKBbukoKe4Rj8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=cNenkbNC92vd/Xh/3hA/X2wIhJXjGE64kiiQv3UbUo1JNRKjXu6RliqsAsiBXQBVW JciJp18l0TLxQVuR3ZsR4efrzex609V+26Xbq3eyQhmoceTs6vcxPec9Su+gZnN+SN THXuip8nIJnSC+ryOWz5/gQfMRIFoNRTXiB59hGw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t5N075cf010322 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd53.lss.emc.com (RSA Interceptor); Mon, 22 Jun 2015 20:06:59 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5N06tbN007993 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jun 2015 20:06:55 -0400 Received: from MXHUB208.corp.emc.com (10.253.68.34) by mxhub05.corp.emc.com (128.222.70.202) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 22 Jun 2015 20:06:54 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.107]) by MXHUB208.corp.emc.com ([10.253.68.34]) with mapi id 14.03.0224.002; Mon, 22 Jun 2015 20:06:54 -0400 From: "Black, David" To: Randy Presuhn , Kathleen Moriarty Thread-Topic: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) Thread-Index: AQHQrTBBOcaOUuu97EGJA0vNW5DELp25MNAg Date: Tue, 23 Jun 2015 00:06:53 +0000 Message-ID: References: <32973554.1435007596799.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> In-Reply-To: <32973554.1435007596799.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.ad@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 23 Jun 2015 00:07:11 -0000 Hi Randy, > I still don't see how monitoring a not-necessarily- > trusted VM is in any way different from monitoring any other > not-necessarily-trusted resource. =20 IMHO, it's not, but that does not appear to be the source of the concern. Here's an attempt to explain what I think is going on based on the AgentX example: > If one uses AgentX as the implementation technology, the protocol > provides the subagent no means of access to other information known > to the master agent. =20 As I understand the emails the concern wrt AgentX would be: If AgentX is used between: a) an SNMP engine plus master agent in a VM; and b) a sub-agent in the hypervisor, then a malicious VM (that isn't supposed to be using AgentX) could use AgentX to try to get into the hypervisor at least to access the data in this MIB, and possibly for other nefarious purposes. The secdir reviewer's original comment was: > I would also mention the specific problem of software running in a virtua= l > machine and accessing the hypervisor's variables. This is an attack vecto= r > that is somewhat specific to this MIB. It cannot be mitigated by network > firewalls. That would be a consideration if AgentX was running over some sort of hypervisor syscall interface that could not be interposed on by a firewall. In that scenario, some sort of access controls on that syscall interface would be a good idea. OTOH, if one forced the AgentX access into the hypervisor to be via network traffic, then a firewall (e.g., a software firewall on the same hypervisor)= , could provide some mitigation. Thanks, --David > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Randy Presuhn > Sent: Monday, June 22, 2015 5:13 PM > To: Randy Presuhn; Kathleen Moriarty > Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org; draft-ietf-opsawg-vmm- > mib@ietf.org; opsawg-chairs@ietf.org; The IESG; opsawg@ietf.org; draft-ie= tf- > opsawg-vmm-mib.ad@ietf.org > Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsa= wg- > vmm-mib-03: (with COMMENT) >=20 > Hi - >=20 > ARRGH! I apologize for sending a blast of HTML gobbledygook. > Here's what I intended to say: >=20 > Sorry, I don't mean to be dense, but I can't provide text to > explain this because this rationale doesn't make any sense to > me at all. I still don't see how monitoring a not-necessarily- > trusted VM is in any way different from monitoring any other > not-necessarily-trusted resource. Let me explain why this > makes no sense to me. >=20 > There are about two-and-a-half strategies for connecting MIB > module instrumentation to SNMP engines: >=20 > (1) build the instrumentation into the same process as the > SNMP engine. Straightforward, but becomes a software > configuration management nightmare. >=20 > (2) use a mechanism such as AgentX to handle the chit-chat > between the master agent (home to the SNMP engine) and > subagents >=20 > (a) instrumentation can be built directly into the resources, > implying a certain level of trust that the subagent will > respond truthfully to get/set, etc. >=20 > (b) instrumentation can be built into processes which in turn > monitor the resources by other means. This is useful > when, for example, one does not have control of the > source code for the resource. >=20 > 2(b) would IMO be the obvious preferred choice for implementing > this MIB module. >=20 > If one uses AgentX as the implementation technology, the protocol > provides the subagent no means of access to other information known > to the master agent. A malicious subagent (one which impersonates > another) is conceivable, but even a malicious subagent doesn't gain > access to existing management information of the subagent it is > impersonating - it only sees subsequent configuration requests > and what it can glean from index values present in get/getnext/bulk > requests. >=20 > None of this is specific to management of VMs. >=20 > If someone uses some homebrew mechanism in place of AgentX, > all bets are off until there's been an analysis of that > mechanism. Again, however, this is true whether VMs are in > the picture or not. >=20 > Randy >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Jun 22 17:32: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 B7BC61B3103; Mon, 22 Jun 2015 17:32:32 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 10xu7scMFWWU; Mon, 22 Jun 2015 17:32:31 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id F0C341B30AE; Mon, 22 Jun 2015 17:32:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sN0vfY17Zc9aaly6PcXr8RLI03R7b91OcBNKTHl/JSINRLuiQyncj4yhZ07jsUqP; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Z7C8b-000158-HA; Mon, 22 Jun 2015 20:32:29 -0400 Received: from 76.254.55.188 by webmail.earthlink.net with HTTP; Mon, 22 Jun 2015 20:32:28 -0400 Message-ID: <17588594.1435019549343.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Mon, 22 Jun 2015 17:32:28 -0700 (GMT-07:00) From: Randy Presuhn To: "Black,David" , Kathleen Moriarty Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba0953cd4942205048a5c9768186852fa53350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.30 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 00:32:32 -0000 Hi - >From: "Black, David" >Sent: Jun 22, 2015 5:06 PM >To: Randy Presuhn , Kathleen Moriarty >Cc: "draft-ietf-opsawg-vmm-mib.ad@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) > >Hi Randy, > >> I still don't see how monitoring a not-necessarily- >> trusted VM is in any way different from monitoring any other >> not-necessarily-trusted resource. > >IMHO, it's not, but that does not appear to be the source of the concern. >Here's an attempt to explain what I think is going on based on the AgentX >example: > >> If one uses AgentX as the implementation technology, the protocol >> provides the subagent no means of access to other information known >> to the master agent. > >As I understand the emails the concern wrt AgentX would be: > >If AgentX is used between: > a) an SNMP engine plus master agent in a VM; and > b) a sub-agent in the hypervisor, >then a malicious VM (that isn't supposed to be using AgentX) could >use AgentX to try to get into the hypervisor at least to access the >data in this MIB, and possibly for other nefarious purposes. No, Agentx provides no way for a subagent to access MIB data. The worst that a malicious subagent can do is to impersonate a legitimate subagent. >The secdir reviewer's original comment was: > >> I would also mention the specific problem of software running in a virtual >> machine and accessing the hypervisor's variables. This is an attack vector >> that is somewhat specific to this MIB. It cannot be mitigated by network >> firewalls. > >That would be a consideration if AgentX was running over some sort of >hypervisor syscall interface that could not be interposed on by a firewall. >In that scenario, some sort of access controls on that syscall interface >would be a good idea. AgentX and the related protocols I'm aware of provide no mechanism for a subagent to access the master agent's variables. Providing such a mechanism could completely negate the value of VACM. If someone's homebrew interface allows this sort of wanton behaviour, that's their problem. We can't (and should try to) call out every conceivable ill-advised implementation strategy. >OTOH, if one forced the AgentX access into the hypervisor to be via network >traffic, then a firewall (e.g., a software firewall on the same hypervisor), >could provide some mitigation. No. It would not provide any more protection than any other IPC mechanism might. AgentX and related mechanisms assume a degree of trust between the master and subagent. This is documented, for example, in the AgentX RFC. A consequence of this assumption is that the subagent code instrumenting a non-trusted resource should be implemented in a way that it is protected from misbehaviour by the resource; as a practical matter, this means in a separate subagent process, distinct from both the master agent and the stuff being managed. None of these concerns are the least specific to management of hypervisors / VMs, and are, as far as I know, widely understood among implementors of subagent technologies. Randy From nobody Mon Jun 22 22:11: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 163F21A1ABB; Mon, 22 Jun 2015 22:11:08 -0700 (PDT) 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 VHWkMRsA0GnR; Mon, 22 Jun 2015 22:11:06 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2882E1A1A78; Mon, 22 Jun 2015 22:11:06 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so94663254wic.1; Mon, 22 Jun 2015 22:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qvs+KSBHijwMkNMoJyruCHB0ugtPTr9LFM6V59IAbYE=; b=N3lsY2lULduWc+orso+qR+eY1hFKzCMPdIpBD+JC0KtdCl9QRqjTT0eaaVFee27jiG Itr1L397W39SapBhiRJF/x3QaCKXo4NL3Bahl+erPVucUwuwM687nJRw1iDWdTMjlRo1 tjVNfMIs//B2u6JZSQE50YkHmm76yWryzcKUW2j9y4ZmT1dk9BQyqIczHYmTnEKI2VCO r2SNGTKzm2W7faj2cLqMuvluYFHlEb/XWlxC5MLtQGl12Ev9qiiL8LnnqiPh4wK4ww3V JTX7aYotiLy1aXmCvHiaR9BTATBKB8rcUBSRBJWzNLUZxP2H2vmrzqJiF811NQSJbMn9 ULEw== X-Received: by 10.194.133.73 with SMTP id pa9mr58292885wjb.148.1435036264876; Mon, 22 Jun 2015 22:11:04 -0700 (PDT) Received: from [10.200.6.61] ([46.218.164.216]) by mx.google.com with ESMTPSA id gj7sm20403494wib.4.2015.06.22.22.11.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 22:11:01 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <17588594.1435019549343.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Tue, 23 Jun 2015 07:10:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DA452D2-5EC7-447B-B4F8-40E674AD2003@gmail.com> References: <17588594.1435019549343.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> To: Randy Presuhn Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 23 Jun 2015 05:11:08 -0000 Hi, Sent from my iPhone > On Jun 23, 2015, at 2:32 AM, Randy Presuhn w= rote: >=20 > Hi - >=20 >> From: "Black, David" >> Sent: Jun 22, 2015 5:06 PM >> To: Randy Presuhn , Kathleen Moriarty >> Cc: "draft-ietf-opsawg-vmm-mib.ad@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.= shepherd@ietf.org" >> Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsa= wg-vmm-mib-03: (with COMMENT) >>=20 >> Hi Randy, >>=20 >>> I still don't see how monitoring a not-necessarily- >>> trusted VM is in any way different from monitoring any other >>> not-necessarily-trusted resource. =20 >>=20 >> IMHO, it's not, but that does not appear to be the source of the concern.= >> Here's an attempt to explain what I think is going on based on the AgentX= >> example: >>=20 >>> If one uses AgentX as the implementation technology, the protocol >>> provides the subagent no means of access to other information known >>> to the master agent. =20 >>=20 >> As I understand the emails the concern wrt AgentX would be: >>=20 >> If AgentX is used between: >> a) an SNMP engine plus master agent in a VM; and >> b) a sub-agent in the hypervisor, >> then a malicious VM (that isn't supposed to be using AgentX) could >> use AgentX to try to get into the hypervisor at least to access the >> data in this MIB, and possibly for other nefarious purposes. >=20 > No, Agentx provides no way for a subagent to access MIB data. > The worst that a malicious subagent can do is to impersonate > a legitimate subagent. >=20 >> The secdir reviewer's original comment was: >>=20 >>> I would also mention the specific problem of software running in a virtu= al >>> machine and accessing the hypervisor's variables. This is an attack vect= or >>> that is somewhat specific to this MIB. It cannot be mitigated by network= >>> firewalls. >>=20 >> That would be a consideration if AgentX was running over some sort of >> hypervisor syscall interface that could not be interposed on by a firewal= l. >> In that scenario, some sort of access controls on that syscall interface >> would be a good idea. >=20 > AgentX and the related protocols I'm aware of provide no mechanism > for a subagent to access the master agent's variables. =20 This is not clear in the draft. If you make this clear, you put the problem= out-of-scope and you might be providing helpful guidance to someone impleme= nting with less experience than you. This is a non-blocking comment, so I'll leave it to the Responsible AD. Thanks, Kathleen=20 > Providing > such a mechanism could completely negate the value of VACM. If > someone's homebrew interface allows this sort of wanton behaviour, > that's their problem. We can't (and should try to) call out every > conceivable ill-advised implementation strategy. >=20 >> OTOH, if one forced the AgentX access into the hypervisor to be via netwo= rk >> traffic, then a firewall (e.g., a software firewall on the same hyperviso= r), >> could provide some mitigation. >=20 > No. It would not provide any more protection than any other IPC > mechanism might. AgentX and related mechanisms assume a degree > of trust between the master and subagent. This is documented, > for example, in the AgentX RFC. A consequence of this assumption > is that the subagent code instrumenting a non-trusted resource > should be implemented in a way that it is protected from misbehaviour > by the resource; as a practical matter, this means in a separate > subagent process, distinct from both the master agent and the > stuff being managed. >=20 > None of these concerns are the least specific to management of > hypervisors / VMs, and are, as far as I know, widely understood > among implementors of subagent technologies. >=20 > Randy From nobody Mon Jun 22 22:14: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 6A8D01A1ABF; Mon, 22 Jun 2015 22:14:10 -0700 (PDT) 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 AY8nOO_pVdUq; Mon, 22 Jun 2015 22:14:09 -0700 (PDT) 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 43BE21A1A78; Mon, 22 Jun 2015 22:14:09 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:647:4200:7a31:500d:16f9:714b:26df]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t5N5E25V010831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 Jun 2015 05:14:03 GMT (envelope-from joelja@bogus.com) To: "Black, David" , Randy Presuhn , Kathleen Moriarty References: <32973554.1435007596799.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <5588EB1A.5050308@bogus.com> Date: Mon, 22 Jun 2015 22:14:02 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gDIvJ5d1X08an25pcgi4tuCg0ATSveJAv" Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 23 Jun 2015 05:14:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gDIvJ5d1X08an25pcgi4tuCg0ATSveJAv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/22/15 5:06 PM, Black, David wrote: > Hi Randy, > The secdir reviewer's original comment was: >=20 >> I would also mention the specific problem of software running in a vir= tual >> machine and accessing the hypervisor's variables. This is an attack ve= ctor >> that is somewhat specific to this MIB. It cannot be mitigated by netwo= rk >> firewalls. >=20 > That would be a consideration if AgentX was running over some sort of > hypervisor syscall interface that could not be interposed on by a firew= all. > In that scenario, some sort of access controls on that syscall interfac= e > would be a good idea. that's consistent with the security considerations for agent-x > OTOH, if one forced the AgentX access into the hypervisor to be via net= work > traffic, then a firewall (e.g., a software firewall on the same hypervi= sor), > could provide some mitigation. I don't recall there inherently being a reason why agents couldn't use TLS, or some other socket transport like websockets it's just a tcp-stream wrapping agent-x pdus. > Thanks, > --David --gDIvJ5d1X08an25pcgi4tuCg0ATSveJAv 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 iEYEARECAAYFAlWI6xoACgkQ8AA1q7Z/VrKmoACfSPVS7mnKt1ecV1LY2rdZpVzm uwMAn3WqK1kf5Fd5R88BFm409lLAvPtF =YgHk -----END PGP SIGNATURE----- --gDIvJ5d1X08an25pcgi4tuCg0ATSveJAv-- From nobody Tue Jun 23 07:05: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 AC8BD1B2C3B; Tue, 23 Jun 2015 07:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 mVdr-eJctmPm; Tue, 23 Jun 2015 07:05:44 -0700 (PDT) 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 D26551A8ADA; Tue, 23 Jun 2015 07:05:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D4D4B12CA; Tue, 23 Jun 2015 16:05:40 +0200 (CEST) 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 Pzpghssw7Zh6; Tue, 23 Jun 2015 16:05:40 +0200 (CEST) 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; Tue, 23 Jun 2015 16:05:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53ACB2002B; Tue, 23 Jun 2015 16:05:40 +0200 (CEST) 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 wgcVLLWF4JaD; Tue, 23 Jun 2015 16:05:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA8C220013; Tue, 23 Jun 2015 16:05:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9D55934791D2; Tue, 23 Jun 2015 16:05:36 +0200 (CEST) Date: Tue, 23 Jun 2015 16:05:36 +0200 From: Juergen Schoenwaelder To: Kathleen Moriarty Message-ID: <20150623140536.GA35329@elstar.local> Mail-Followup-To: Kathleen Moriarty , Randy Presuhn , Michael MacFaden , "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" References: <6497107.1435003497233.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> 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.shepherd@ietf.org" , Randy Presuhn , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) 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: Tue, 23 Jun 2015 14:05:46 -0000 On Mon, Jun 22, 2015 at 04:12:45PM -0400, Kathleen Moriarty wrote: > On Mon, Jun 22, 2015 at 4:04 PM, Randy Presuhn > wrote: > > > Hi - > > > > >From: Kathleen Moriarty > > >Sent: Jun 22, 2015 12:45 PM > > >To: Michael MacFaden > > >Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" < > > draft-ietf-opsawg-vmm-mib.shepherd@ietf.org>, Randy Presuhn < > > randy_presuhn@mindspring.com>, "draft-ietf-opsawg-vmm-mib@ietf.org" < > > draft-ietf-opsawg-vmm-mib@ietf.org>, "opsawg-chairs@ietf.org" < > > opsawg-chairs@ietf.org>, The IESG , "opsawg@ietf.org" < > > opsawg@ietf.org>, "draft-ietf-opsawg-vmm-mib.ad@ietf.org" < > > draft-ietf-opsawg-vmm-mib.ad@ietf.org> > > >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on > > draft-ietf-opsawg-vmm-mib-03: (with COMMENT) > > > > > >Hi Mike, > > > > > >Sent from my iPhone > > > > > >> On Jun 22, 2015, at 9:08 PM, Michael MacFaden wrote: > > >> > > >> Agree there should be some warning here. But if this text is intended > > for those who implement it > > >> (like me) then I'd prefer to make it clear as mud what the issue is: > > >> > > >> Any implementation of this MIB module in an agent where the Virtual > > Machines being monitored > > >> have access to this very agent or this MIB module creates an attack > > vector on the system or on > > >> any other VM hosted by this system. > > > > > >Yes and one of the responses to the SecDir review said this mib would > > just be on the hypervisor. It also said the virtual images managed by the > > hypervisor typically does not have access to the management connection for > > SNMP to the hypervisor, limiting the risk. > > > > > >Shouldn't the text include guidance that makes this clear (where this mib > > is and the reality of whether or not it's a risk from managed virtual > > images)? > > > > > >Recommending a separate management connection is one way to do that. > > > > I'm missing something here. Why is a monitored VM (where the > > MIB instrumentation is external to the VM) different from any other > > threat? It seems to me that "access to the management connection" > > is a red herring - the privacy protocol, along with authentication > > and access control (VACM) should just be left to do their job. > > > > This came up in the SecDir review. I was happy with the response provided > via email in how it was put out-of-scope. The draft itself does not have > the explanation offered and I think it would be helpful to the reader in > case the same question comes up later. I thought it was a reasonable > question given the content of the draft and possible threat space. > Hi, the only meaningful way to implement this MIB is as part of the hypervisor. I think this actually follows directly from section 3. I am surprised that people got any different ideas from reading the document or looking at Figure 1. The resources are managed by the hypervisor so this is the natural authority for the information exposed by the MIB module. Given this, I do not really see why the security template text is not sufficient. If you expose the content of the MIB widely, then it does not matter whether it is read from a VM on the hypervisor, a VM on a different hypervisor or any other system with access to the Internet. (Sure, if something on a VM wants to break out of its walled garden, it might in principle help to know the hypervisor technology etc. But frankly, it is far easier and more robust to simply try all different break out techniques known to an attacker or to infer likely technology via fingerprinting or even social and web engineering). My preference is to make no change to the text. But, if the IESG feels strongly, I won't object putting in additional (but in my view unneeded) words if that helps to avoid spending cycles on discussions that I find not really relevant. (Who cares whether the MIB module is implemented on the hypervisor as part of a monolithic agent or a subagent - the security trade offs are known and documented - at least for the standardized protocols). /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 Tue Jun 23 07:23: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 83C471B2C55; Tue, 23 Jun 2015 07:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgJelZSxRjma; Tue, 23 Jun 2015 07:23:02 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id BB33D1A8F42; Tue, 23 Jun 2015 07:23:01 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t5NEMxms011621; Tue, 23 Jun 2015 10:22:59 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Juergen Schoenwaelder Thread-Topic: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) Thread-Index: AQHQrSa1cEULplOqdUGaNvJX7P2yyZ25OFqAgAErwQD//8HEAA== Date: Tue, 23 Jun 2015 14:22:58 +0000 Message-ID: References: <6497107.1435003497233.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <20150623140536.GA35329@elstar.local> In-Reply-To: <20150623140536.GA35329@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3517899772_40973039" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-23_03:2015-06-22,2015-06-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506230226 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , Kathleen Moriarty , Randy Presuhn , "draft-ietf-opsawg-vmm-mib@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 23 Jun 2015 14:23:04 -0000 --B_3517899772_40973039 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I concur with Randy and Juergen. -- Regards, Uri Blumenthal On 6/23/15, 10:05 , "Juergen Schoenwaelder" wrote: >On Mon, Jun 22, 2015 at 04:12:45PM -0400, Kathleen Moriarty wrote: >> On Mon, Jun 22, 2015 at 4:04 PM, Randy Presuhn >>> > wrote: >> >> > Hi - >> > >> > >From: Kathleen Moriarty >> > >Sent: Jun 22, 2015 12:45 PM >> > >To: Michael MacFaden >> > >Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" < >> > draft-ietf-opsawg-vmm-mib.shepherd@ietf.org>, Randy Presuhn < >> > randy_presuhn@mindspring.com>, "draft-ietf-opsawg-vmm-mib@ietf.org" < >> > draft-ietf-opsawg-vmm-mib@ietf.org>, "opsawg-chairs@ietf.org" < >> > opsawg-chairs@ietf.org>, The IESG , "opsawg@ietf.org" < >> > opsawg@ietf.org>, "draft-ietf-opsawg-vmm-mib.ad@ietf.org" < >> > draft-ietf-opsawg-vmm-mib.ad@ietf.org> >> > >Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on >> > draft-ietf-opsawg-vmm-mib-03: (with COMMENT) >> > > >> > >Hi Mike, >> > > >> > >Sent from my iPhone >> > > >> > >> On Jun 22, 2015, at 9:08 PM, Michael MacFaden >>wrote: >> > >> >> > >> Agree there should be some warning here. But if this text is >>intended >> > for those who implement it >> > >> (like me) then I'd prefer to make it clear as mud what the issue >>is: >> > >> >> > >> Any implementation of this MIB module in an agent where the >>Virtual >> > Machines being monitored >> > >> have access to this very agent or this MIB module creates an >>attack >> > vector on the system or on >> > >> any other VM hosted by this system. >> > > >> > >Yes and one of the responses to the SecDir review said this mib would >> > just be on the hypervisor. It also said the virtual images managed >>by the >> > hypervisor typically does not have access to the management >>connection for >> > SNMP to the hypervisor, limiting the risk. >> > > >> > >Shouldn't the text include guidance that makes this clear (where >>this mib >> > is and the reality of whether or not it's a risk from managed virtual >> > images)? >> > > >> > >Recommending a separate management connection is one way to do that. >> > >> > I'm missing something here. Why is a monitored VM (where the >> > MIB instrumentation is external to the VM) different from any other >> > threat? It seems to me that "access to the management connection" >> > is a red herring - the privacy protocol, along with authentication >> > and access control (VACM) should just be left to do their job. >> > >> >> This came up in the SecDir review. I was happy with the response >>provided >> via email in how it was put out-of-scope. The draft itself does not >>have >> the explanation offered and I think it would be helpful to the reader in >> case the same question comes up later. I thought it was a reasonable >> question given the content of the draft and possible threat space. >> > >Hi, > >the only meaningful way to implement this MIB is as part of the >hypervisor. I think this actually follows directly from section 3. I >am surprised that people got any different ideas from reading the >document or looking at Figure 1. The resources are managed by the >hypervisor so this is the natural authority for the information >exposed by the MIB module. > >Given this, I do not really see why the security template text is not >sufficient. If you expose the content of the MIB widely, then it does >not matter whether it is read from a VM on the hypervisor, a VM on a >different hypervisor or any other system with access to the Internet. >(Sure, if something on a VM wants to break out of its walled garden, >it might in principle help to know the hypervisor technology etc. But >frankly, it is far easier and more robust to simply try all different >break out techniques known to an attacker or to infer likely >technology via fingerprinting or even social and web engineering). > >My preference is to make no change to the text. But, if the IESG feels >strongly, I won't object putting in additional (but in my view >unneeded) words if that helps to avoid spending cycles on discussions >that I find not really relevant. (Who cares whether the MIB module is >implemented on the hypervisor as part of a monolithic agent or a >subagent - the security trade offs are known and documented - at least >for the standardized protocols). > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg --B_3517899772_40973039 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKE5SxSwAAAABE8TANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1MDYxNTE2MjQzOVoXDTE2MDYxNDE2MjQzOVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0tVFZOYvbDipiXfjylg0yIORem8AMZ4UQJ7EM2BI8 jKLj/h3RwH4w2DOMdepALLUqscSrpX6HPbo80M1O0cSSIYcYl8wQzDAMmvoD3HWbupwSXEPf eRtBo26jAvsDkOp46TPu40Pu61AkHx4vIgqU7XkofKhow18Ka/9ZkJ+oSnLK6Xy9+n8JiViO kTm2NjyF+CcpAobwZ3lBepHihvK3EilYR6V1EHQb+Y+2aWtexkFzBNXaN7i4Sdzq+LNSzCON DDDnRxA2c/B/p7MBDzocaigPxmKOHcE5eamxCgpJEUVCEALzeVZxcYURDJw68tZ90pJSLuw7 r6iigykQbRINAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUQzxm8xAhtcoaGyRStaMMhrmd7/Mw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAI8vbC+RZJEH0jhe5e9w F18xYCquDo5kxkoD83qYcVPVFYPnjuAvZ6o9ENa3F0GiAjFVm6HcUbm0zeWT6ZDYIrbh7GRM 4IO8pD9ziwvLIx8rvLvUhiBpsZvznVOWX1yGC0UkIKyiseAszczAYFVJonKB8jDRnxgFlPlo mFUaDtjL86cyp+pHc+ffUVyqMxacABFutJJ72HcK7tIf2gnh2qLdKToiTkDIWT+b1RrkQPSr Gr0YapAC5PgHd/RRY75FHdW/OEQOFimouKnBc5F2VsDJg0Ae9i0+nJPWwSpoXe0ISqIUMO47 Ei6ySfHR2mjymbByxmT5W3gAT3M2gyOd/XUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKKHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZ y/m+7FeYfCo3XYrNqx6/3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Y c0tmMzf5MXBrsub0nUyJeDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7L or1oLWSxNNUyp98gC4EpdHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOW IZULMaAc9JJEq8ctns9mGIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZ YEZ/AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSm i1Ti9F2f2/Are2a7a9E/IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adM wccDlKSR2uIDsiA7jodiTxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zP nWU1nWZBbJR7cLKgUTaEiQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4 kQr5teUVUNDoCj02x781GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+ Xdmbcd3OH6y8fNl1mZdXn8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCChOUsUsAAAAARPEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgjT0kzPfy+nv3RWtdKvtpN0F5XSj61UvqDfqK22vAAmgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNjIzMTQyMjUyWjANBgkqhkiG9w0BAQEFAASC AQAKQI4D1VvkHxoerpBl2/GOTjdNuUlFCeFjrlw3LsaVG7LdQEJHQp+QYFvCrPN83hyp4/r5 GgVbT7D1fZSLBZn1gsmhuKgbxnCyC5DXpfrK5bWA9T82G4bG8z709z5NEpq7nr+sJ0RQPIAh Jq0vpQ8wUYRFvxAYuHID7vuESi6aCG3tqcZfLnxqu3CRywka1pvNTdgiB0PnpGXB8Mdsf0lq x0lxIV1fOsrmoghgs+J6Uu86s9Z2gU4EzhJ/8E1pweMLHN0QKDZJKAb14x17sGa7kH1buT9L 5fmxUT0Nacnm6IVYsnv+0Sg8PSyNtbyV9XUObCUqD0HxyxK3gt6M4pV5 --B_3517899772_40973039-- From nobody Tue Jun 23 07:36: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 5183F1B2C2F; Tue, 23 Jun 2015 07:36:48 -0700 (PDT) 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 1h3_RZm3v0bv; Tue, 23 Jun 2015 07:36:47 -0700 (PDT) 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 D00BF1B2C64; Tue, 23 Jun 2015 07:36:46 -0700 (PDT) Received: from mb-aye.local (c-98-248-47-249.hsd1.ca.comcast.net [98.248.47.249]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t5NEYB7j013819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 Jun 2015 14:34:12 GMT (envelope-from joelja@bogus.com) To: "Blumenthal, Uri - 0553 - MITLL" , Juergen Schoenwaelder References: <6497107.1435003497233.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <20150623140536.GA35329@elstar.local> From: joel jaeggli Message-ID: <55896E5C.306@bogus.com> Date: Tue, 23 Jun 2015 07:34:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7etipgOa9cxAAQ7Bjwla5qv93cex1PEND" Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.shepherd@ietf.org" , "draft-ietf-opsawg-vmm-mib@ietf.org" , Randy Presuhn , Kathleen Moriarty , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-vmm-mib.ad@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 23 Jun 2015 14:36:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7etipgOa9cxAAQ7Bjwla5qv93cex1PEND Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/23/15 7:22 AM, Blumenthal, Uri - 0553 - MITLL wrote: > I concur with Randy and Juergen. Ok thanks, I think we have dicussed us. joel >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --7etipgOa9cxAAQ7Bjwla5qv93cex1PEND 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 iEYEARECAAYFAlWJbl0ACgkQ8AA1q7Z/VrLPgACcCs/VT5C8FLaqgzExctPkRfPZ d8sAnikfiz/bNrsZgdMDbj378TJDB6vB =qMtm -----END PGP SIGNATURE----- --7etipgOa9cxAAQ7Bjwla5qv93cex1PEND-- From nobody Tue Jun 23 13: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 80CF61B30D2; Tue, 23 Jun 2015 13:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 UKkhwfW103NP; Tue, 23 Jun 2015 13:42:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BB91B30D1; Tue, 23 Jun 2015 13:42:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150623204258.29457.10174.idtracker@ietfa.amsl.com> Date: Tue, 23 Jun 2015 13:42:58 -0700 Archived-At: Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org Subject: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) 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, 23 Jun 2015 20:43:00 -0000 Ben Campbell has entered the following ballot position for draft-ietf-opsawg-vmm-mib-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I mean the following as a question, because it's something I've never thought about, but seems odd: Is it normal to have 2119 language in the description fields in a MIB definition? Who is that language intended for? -- 6.1, vm-mib "description" field: Do you expect the sentence about 'yyy' being temporary to be removed by the RFC Editor? If so, you probably want a note to that effect. -- VirtualMachineList description: "... set of eight virtual machine vmIndex..." Should vmIndex be plural? -- 8, 1st paragraph: "noticeable number of notifications" Is "noticeable" the word you intended? It seems like any number of notifications might be noticeable--that's the point of notifications. Also, this sentence seems out of place (the next sentence seams to draw a conclusion from the sentence prior to this one.) "... It is recommended that attention be given to these objects ... I'm not sure what it means to give attention to the objects. Identifying who or what needs to give attention might help. (consider active voice) -- paragraph 5: "It is recommended that the implementers consider the security features as provided by the SNMPv3 framework." Do you mean "use the ... features" or "consider using the ... features"? From nobody Wed Jun 24 08:40:52 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 3FBEA1AC41F for ; Wed, 24 Jun 2015 08:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 kUE1DRW-d2rz for ; Wed, 24 Jun 2015 08:40:43 -0700 (PDT) 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 BD52D1A8FD2 for ; Wed, 24 Jun 2015 08:40:13 -0700 (PDT) Received: from mb-aye.local ([8.18.217.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t5OFeCEd022632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Jun 2015 15:40:13 GMT (envelope-from joelja@bogus.com) To: "Blumenthal, Uri - 0553 - MITLL" , "opsawg@ietf.org" References: <55825564.5080203@bogus.com> From: joel jaeggli Message-ID: <558ACF58.4070703@bogus.com> Date: Wed, 24 Jun 2015 08:40:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fPH9VnrsBFtqEPXhSxbaIucmiRjrWJicg" Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 about to send to the rfc editor. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 24 Jun 2015 15:40:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fPH9VnrsBFtqEPXhSxbaIucmiRjrWJicg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/22/15 7:30 AM, Blumenthal, Uri - 0553 - MITLL wrote: > On 6/18/15, 1:21 , "joel jaeggli" wrote: >=20 >> Stephen Farrell's comment ( and former dicuss) I think should be foo= d >> for thought and I'd like if possible to briefly discuss it. >=20 > It has already been discussed (briefly), both among the designers, and > with the wider audience, including Stephen. We evaluated the arguments > (and their accuracy), weighted them against the other reasons (such as > providing a standardized auth method for standardized hashes), and deci= ded > what should stay in the draft. >=20 > In summary, the decision was to provide a mandatory method, but in > compliance with the standard SHA-2 specs define optional mechanisms > pairing with the SHA-2 hash family members. Reason: those who for whate= ver > reason need a hash from SHA-2 family, would have a *standard* way to us= e > it within this spec. >=20 > Is there anything not covered in the arguments Stephen made (some of wh= ich > I disagree with, but it=E2=80=99s besides the point) and my answer abov= e? No, I think that's good. Thanks joel >=20 >> ------ >> I'm a yes on this, but am still holding my nose:-) >> >> The yes is because it's a fine thing to make sure that up-to-date >> options for securing protocols are available >> >> The nose-holding is because defining multiple options that >> aren't significantly different in strength (if one assumes that >> key management is the likely weakest link) is a bad plan. >> >> In case it helps, my main logic for not wanting all these >> options is that it is overwhelmingly more likely that the >> code to switch between them or react to which you've received >> or to configure things will (due to bugs etc.) weaken >> security much much much more than the existence of more >> than one of these options could ever strengthen security. >> (Put another way the probability of a security bug due >> to adding N things here is far far higher than the >> probability that having N things saves the day when N-1 >> of them are no longer considered good crypto at some >> point.) >> >> So by defining more of these you are doing worse than >> if you only defined one of these. (The fact that all sha2 >> digests have the same internal structure is part of but >> not all of this argument.) >> >> On truncation, I'd argue that if that was a significant >> benefit then it'd be used everywhere and it is not. In >> fact I don't believe truncation is used anywhere else >> when there's no protocol (e.g. PDU/fragmentation) issue >> that causes us to want shorter MACs. >> >> I also believe that even those who for truncation would >> agree that the benefit of reasonable-length truncation is >> definitely an insignificant benefit, if any, and would >> also agree that that's a matter of taste when it comes >> to sha2 variants of hmac (assuming the protocol can live >> with full length, as in this case). >> >> Bottom line: Discuss is cleared and I'm out of the way, but >> with a heartfelt plea that you ditch all of these but one. And >> then ditch truncation too. And so end up with just adding >> hmac-sha2 as many other protocols have done. >> ------- >> >> so there's a plea for limiting the scope of options, if someone feels >> very strongly that this is important to address I would take that unde= r >> advisement. on the other hand reasoned countervailing arguements would= >> also be fine but are certainly not critical. --fPH9VnrsBFtqEPXhSxbaIucmiRjrWJicg 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 iEYEARECAAYFAlWKz1kACgkQ8AA1q7Z/VrKhAgCeIrapHuBhOJYu1a8QlpWvSlRJ XdUAn0nIOKXDe4FbEWGkNYMfnx+HAO2o =jIPM -----END PGP SIGNATURE----- --fPH9VnrsBFtqEPXhSxbaIucmiRjrWJicg-- From nobody Wed Jun 24 08:49: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 B87741ACDF5 for ; Wed, 24 Jun 2015 08:49:21 -0700 (PDT) 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 hW3l9UD-wdDi for ; Wed, 24 Jun 2015 08:49:19 -0700 (PDT) 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 98F561ACDE4 for ; Wed, 24 Jun 2015 08:49:18 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2DBD81A0113; Wed, 24 Jun 2015 17:49:00 +0200 (CEST) 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 5oKVvHZ7vHJf; Wed, 24 Jun 2015 17:48:58 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id A5AEC1A0112; Wed, 24 Jun 2015 17:48:58 +0200 (CEST) Received: from [10.208.1.212] (10.208.1.212) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 24 Jun 2015 17:49:14 +0200 Message-ID: <558AD17A.1030800@secunet.com> Date: Wed, 24 Jun 2015 17:49:14 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: joel jaeggli , "Blumenthal, Uri - 0553 - MITLL" , "opsawg@ietf.org" References: <55825564.5080203@bogus.com> <558ACF58.4070703@bogus.com> In-Reply-To: <558ACF58.4070703@bogus.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.208.1.212] Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 about to send to the rfc editor. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 24 Jun 2015 15:49:21 -0000 needless to say that I agree with that ;-) Johannes joel jaeggli schrieb am 24.06.2015 um 17:40: > On 6/22/15 7:30 AM, Blumenthal, Uri - 0553 - MITLL wrote: >> On 6/18/15, 1:21 , "joel jaeggli" wrote: >> >>> Stephen Farrell's comment ( and former dicuss) I think should be food >>> for thought and I'd like if possible to briefly discuss it. >> >> It has already been discussed (briefly), both among the designers, and >> with the wider audience, including Stephen. We evaluated the arguments >> (and their accuracy), weighted them against the other reasons (such as >> providing a standardized auth method for standardized hashes), and decided >> what should stay in the draft. >> >> In summary, the decision was to provide a mandatory method, but in >> compliance with the standard SHA-2 specs define optional mechanisms >> pairing with the SHA-2 hash family members. Reason: those who for whatever >> reason need a hash from SHA-2 family, would have a *standard* way to use >> it within this spec. >> >> Is there anything not covered in the arguments Stephen made (some of which >> I disagree with, but it’s besides the point) and my answer above? > > No, I think that's good. > > Thanks > joel > >> >>> ------ >>> I'm a yes on this, but am still holding my nose:-) >>> >>> The yes is because it's a fine thing to make sure that up-to-date >>> options for securing protocols are available >>> >>> The nose-holding is because defining multiple options that >>> aren't significantly different in strength (if one assumes that >>> key management is the likely weakest link) is a bad plan. >>> >>> In case it helps, my main logic for not wanting all these >>> options is that it is overwhelmingly more likely that the >>> code to switch between them or react to which you've received >>> or to configure things will (due to bugs etc.) weaken >>> security much much much more than the existence of more >>> than one of these options could ever strengthen security. >>> (Put another way the probability of a security bug due >>> to adding N things here is far far higher than the >>> probability that having N things saves the day when N-1 >>> of them are no longer considered good crypto at some >>> point.) >>> >>> So by defining more of these you are doing worse than >>> if you only defined one of these. (The fact that all sha2 >>> digests have the same internal structure is part of but >>> not all of this argument.) >>> >>> On truncation, I'd argue that if that was a significant >>> benefit then it'd be used everywhere and it is not. In >>> fact I don't believe truncation is used anywhere else >>> when there's no protocol (e.g. PDU/fragmentation) issue >>> that causes us to want shorter MACs. >>> >>> I also believe that even those who for truncation would >>> agree that the benefit of reasonable-length truncation is >>> definitely an insignificant benefit, if any, and would >>> also agree that that's a matter of taste when it comes >>> to sha2 variants of hmac (assuming the protocol can live >>> with full length, as in this case). >>> >>> Bottom line: Discuss is cleared and I'm out of the way, but >>> with a heartfelt plea that you ditch all of these but one. And >>> then ditch truncation too. And so end up with just adding >>> hmac-sha2 as many other protocols have done. >>> ------- >>> >>> so there's a plea for limiting the scope of options, if someone feels >>> very strongly that this is important to address I would take that under >>> advisement. on the other hand reasoned countervailing arguements would >>> also be fine but are certainly not critical. > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Wed Jun 24 13:34: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 99B761B2DC9 for ; Wed, 24 Jun 2015 13:34:27 -0700 (PDT) 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 JlgwkF4_rO5M for ; Wed, 24 Jun 2015 13:34:26 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (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 65D401B2DB4 for ; Wed, 24 Jun 2015 13:34:26 -0700 (PDT) Received: by obctg8 with SMTP id tg8so34311773obc.3 for ; Wed, 24 Jun 2015 13:34:25 -0700 (PDT) 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=1Dt6fSV5xWYwI7q+rJvF0JIpF6ymObRW8en5L2ekHmc=; b=KisoOyylWi3OrZEXmhPrxah7tKl7n2rFbRhztokYtGetTgtIZu7wQtwxHGUvJSFOsJ BQyOVynuJ6aIZGFLZpEMcnM/gdFnR8LnIPJ0YkE2HJEUTeJpMrjZ17X0it2rwFQqEyof ArjS8STK50CTqyokMD54Ad5n7ayrsHE88y26URh9DApbGOulXsqbtFLBiKJfZSWekQ4j s5v8PHCrvSPVWfuHMLDp4t3nbNtbFYei68vL4Tklr8eE71WtoLHccdaWtMFwwbIwbSob Wu1AdfB/WdBW4UKSU2cSsr2eKasnG1AybxeKolaJ/LHXEJel1AJFaF81v2E2W9MQcEky VymQ== X-Gm-Message-State: ALoCoQnasvW8e19nkeXKrsOik9xqkoeRQO+dYYk7Jyq9TXGxMTq5jymjSyE3jw3Fv8VVxNaI9J/m MIME-Version: 1.0 X-Received: by 10.182.186.106 with SMTP id fj10mr35363218obc.54.1435178065832; Wed, 24 Jun 2015 13:34:25 -0700 (PDT) Received: by 10.202.196.75 with HTTP; Wed, 24 Jun 2015 13:34:25 -0700 (PDT) Date: Wed, 24 Jun 2015 16:34:25 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] OpsAWG will not meet in Prage (was "Call for agenda items for Prague.") X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 24 Jun 2015 20:34:27 -0000 Dear OpsAWG, Due to the fact that there were more requests for meeting slots in Prague than available, the secretariat and ADs asked WGs to consider not meeting if they didn't absolutely have to. OpsAWG looked at our open drafts, number of people who requested slots, etc, and have decided not to meet in Prague. The ADs have kindly agreed to give up a bit of the OpsArea meeting for the TACACS+ document (draft-dahm-opsawg-tacacs/) to be discussed. So, in summary - just look for OpsArea on the agenda, show up like you normally do, and everything will look remarkably familiar (modulo the swapping of the folk on state, tripping over the wires, etc). W On Tue, May 19, 2015 at 2:00 PM, Warren Kumari wrote: > Hi all, > > We have requested a slot for the joint OpsAWG / OpsArea meeting in Prague. > > Please send over requests for agenda time. > > Please remember that we give time to drafts that have already received > significant discussion on list. > > 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 Thu Jun 25 03:52: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 E50E91B34D2; Thu, 25 Jun 2015 03:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ENOZnvhomMIb; Thu, 25 Jun 2015 03:52:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 923061B34CE; Thu, 25 Jun 2015 03:52:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150625105252.8558.42452.idtracker@ietfa.amsl.com> Date: Thu, 25 Jun 2015 03:52:52 -0700 Archived-At: Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org Subject: [OPSAWG] Benoit Claise's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) 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: Thu, 25 Jun 2015 10:52:54 -0000 Benoit Claise has entered the following ballot position for draft-ietf-opsawg-vmm-mib-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Idnit complains: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: vmHvSoftware OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the hypervisor software. This value SHOULD not include its version as it SHOULD be included in `vmHvVersion'." ::= { vmHypervisor 1 } - EDITORIAL: there is something wrong with all single quote occurrences. Ex: `virtio' - If you ever post a new version, in order to ease IANA job, change: OLD: vmMIB { mib-2 TBD } IANAStorageMediaTypeMIB { mib-2 TBD } NEW: vmMIB { mib-2 yyy } IANAStorageMediaTypeMIB { mib-2 zzz } From nobody Thu Jun 25 03:55: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 251F21B34DA; Thu, 25 Jun 2015 03:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_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 V6glFC_ZsEPs; Thu, 25 Jun 2015 03:55:07 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323931B34D2; Thu, 25 Jun 2015 03:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1103; q=dns/txt; s=iport; t=1435229707; x=1436439307; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ABajzZxzuEHbK4WEn2pKVK7UIOQ750q+A4ZNjmGctmg=; b=MW+UkZaCfpCNLXmZi/xKqvNk94eH+kJwoWD7NR6xAo0LaxX6oI5DSDEU UxqnT3TGfONHuCCZhKqW6Mzh/MBn5NWfyPWPUtNVPQVbP2YBdG4/wIGlZ UK35ZOCKLTgOHi+ez69bG0vpD8V+jpzvZRgS40jESZWDG27FehLDg0FbH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DDBAC83ItV/xbLJq1bg2Vfgx61SYYahXgCggkBAQEBAQGBC4QjAQEEIxVBEAsYAgIFIQICDwJGBgEMCAEBiCsNtymWLgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKKYQjEQFRB4JogUMBBIcDjQKEWIZ5gTqEEIJrkAMmY4MZPDEBgQuBPAEBAQ X-IronPort-AV: E=Sophos;i="5.13,675,1427760000"; d="scan'208";a="536816251" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 25 Jun 2015 10:55:04 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5PAt327003663; Thu, 25 Jun 2015 10:55:03 GMT To: Ben Campbell , The IESG References: <20150623204258.29457.10174.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <558BDE07.60000@cisco.com> Date: Thu, 25 Jun 2015 12:55:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150623204258.29457.10174.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-opsawg-vmm-mib.ad@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-vmm-mib.shepherd@ietf.org Subject: Re: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 25 Jun 2015 10:55:09 -0000 On 23/06/2015 22:42, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-opsawg-vmm-mib-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I mean the following as a question, because it's something I've never > thought about, but seems odd: Is it normal to have 2119 language in the > description fields in a MIB definition? Who is that language intended > for? I've seen that before. I don't think that's an issue. Regards, Benoit From nobody Thu Jun 25 05:34: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 77C281A0389; Thu, 25 Jun 2015 05:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 r61DdGaNRGFB; Thu, 25 Jun 2015 05:33:57 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156771A036F; Thu, 25 Jun 2015 05:33:55 -0700 (PDT) Received: from Macintosh.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id kcZr1q0073vXPcr01cZs6S; Thu, 25 Jun 2015 14:33:53 +0200 Message-ID: <558BF52F.5070802@bwijnen.net> Date: Thu, 25 Jun 2015 14:33:51 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Benoit Claise , Ben Campbell , The IESG References: <20150623204258.29457.10174.idtracker@ietfa.amsl.com> <558BDE07.60000@cisco.com> In-Reply-To: <558BDE07.60000@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org, opsawg-chairs@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 25 Jun 2015 12:33:59 -0000 On 25/06/15 12:55, Benoit Claise wrote: > On 23/06/2015 22:42, Ben Campbell wrote: >> Ben Campbell has entered the following ballot position for >> draft-ietf-opsawg-vmm-mib-03: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I mean the following as a question, because it's something I've never >> thought about, but seems odd: Is it normal to have 2119 language in the >> description fields in a MIB definition? Who is that language intended >> for? > I've seen that before. > I don't think that's an issue. > In my view, it is OK to use rfc2119 language to describe specific required behaviour for a specific object. It is not ok to use rfc2119 lnguage to indicate if an object msut/should/or may be supported. That needs to be defined in the MODULE COMPLIANCE section of a MIB module. my 2 cents Bert > Regards, Benoit > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Thu Jun 25 06:05: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 64F6E1A879D for ; Thu, 25 Jun 2015 06:05:01 -0700 (PDT) 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 DOCIKZlWh9Rm for ; Thu, 25 Jun 2015 06:04:55 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.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 994211A8756 for ; Thu, 25 Jun 2015 06:04:52 -0700 (PDT) Received: by obpn3 with SMTP id n3so46533650obp.0 for ; Thu, 25 Jun 2015 06:04:52 -0700 (PDT) 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=ZgLQDD/1LYvi5qxDivhZb/MRVHl1rpDsGRVJ4Bee35w=; b=IFAg/ctXAjKcNqTnTkfVdbHGApLld/y8qs74KYyUGdIBvc81CYuDCkyfgzTRJ1kNT6 yIAS1UQw42xC+e1H3phN4lk+3tJxnbSnXhr3xLuMZmzW1YfA6MP/woKA26GhHDX+eBM+ sUPOZaZmevhcUyXBJRKC76yB56wf1Nu04rYfuUkTOaWrfL3P4Tvq9FjdACBMuY2KtZ0C 6kO86iQaPTQQ+zJ2y/A/4kQdDxboKhRBVgcCC7koOa5Amk0CSx2i89wcxOffgH08qha5 HHPAibsojPI+4gAbtSrS475M7Xhf129pBnhx3qkdHqSrabGjsFvJ7DkqAYDn1YGMggY1 s7zA== X-Gm-Message-State: ALoCoQm3sYlc+mcFg7s9sPfJmA+ndSfEqKPxbKBRhZJskHBRNj3NXu7elfdLcmONWuYiWQFR/r8S MIME-Version: 1.0 X-Received: by 10.182.148.5 with SMTP id to5mr38872507obb.71.1435237492035; Thu, 25 Jun 2015 06:04:52 -0700 (PDT) Received: by 10.202.196.75 with HTTP; Thu, 25 Jun 2015 06:04:51 -0700 (PDT) Date: Thu, 25 Jun 2015 09:04:51 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-you-opsawg-capwap-separation-for-mp@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] Call for Adoption: draft-you-opsawg-capwap-separation-for-mp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 25 Jun 2015 13:05:01 -0000 Dear OpsAWG WG, The authors of draft-you-opsawg-capwap-separation-for-mp have asked for this draft to be considered for OpsAWG adoption. It was presented and discussed somewhat at IETF91 in Dallas - there was a question raised about similarities / overlap with draft-ietf-opsawg-capwap-alt-tunnel (which lies with the IESG). After some discussions we have decided that these documents complement each other, and so ask the WG to consider draft-you-opsawg-capwap-separation-for-mp for adoption. We would like 4-5 people to commit to editing and contributing to the document, and a similar number to commit to reviewing it. The draft is available here: https://datatracker.ietf.org/doc/draft-you-opsawg-capwap-separation-for-mp/ 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 Thu 09-Jul-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-you-opsawg-capwap-separation-for-mp, 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 Thu Jun 25 06:21: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 9478D1A8852 for ; Thu, 25 Jun 2015 06:21:39 -0700 (PDT) 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=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 kWkQcWpyGt2s for ; Thu, 25 Jun 2015 06:21:38 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75421A8849 for ; Thu, 25 Jun 2015 06:21:36 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-12v.sys.comcast.net with comcast id kdMc1q0034zp9eg01dMcbp; Thu, 25 Jun 2015 13:21:36 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-po-07v.sys.comcast.net with comcast id kdMa1q00G2yZEBF01dMa5R; Thu, 25 Jun 2015 13:21:35 +0000 From: "ietfdbh" To: "'Benoit Claise'" , "'Ben Campbell'" , "'The IESG'" References: <20150623204258.29457.10174.idtracker@ietfa.amsl.com> <558BDE07.60000@cisco.com> In-Reply-To: <558BDE07.60000@cisco.com> Date: Thu, 25 Jun 2015 09:21:34 -0400 Message-ID: <069801d0af49$dc75de90$95619bb0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDSNOweCsemZKzLDUTkNumfC2I/GgK29OJNn6RtriA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1435238496; bh=59HU5qXavp6LTdWnoG+JyPuGMtfOa/8Xg5Tv7ywDEyM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=AuxJQ5SHODb6TDSwThPDRxMZP/IE2ewUxH8g84zZMbzKURUNtghkipOMrkJz96rxS 9YKhpwkjZhnxevT89rr76W4epZ8qIX+Ov3WYScRWJDCz3W2SeUxsGgFVBrPvC1nzs2 Wdpf5erunUF4NtxkhWaVyqgbYiV0+ibbs7RZYKhgS7Ii9sgGH9b8VNJZTPGu/0wTzd v81Et3IvEsWyCinzHskAKoilQ+DL8OTb+cCGGUrLw2hNm7+Fc32hx9cV1dAzfwgPN4 w5/5l555h7nDaC8GA+M3wtuShGvWFvxUSwEeeAMgpw7Lt5wrz+ZGKzeFCe6NLGdjNQ JLs6Mk2i+87vw== Archived-At: Cc: draft-ietf-opsawg-vmm-mib.shepherd@ietf.org, draft-ietf-opsawg-vmm-mib.ad@ietf.org, opsawg-chairs@ietf.org, draft-ietf-opsawg-vmm-mib@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 25 Jun 2015 13:21:39 -0000 A MIB specification serves as a contract between implementers and users. It is really a virtual database schema. When there is a MUST, a compliant implementer MUST ensure their implementation behaves as stated. When an operator retrieves a value from a compliance-claiming implementation, they expect the implementation to follow the specified behavior. However, technology is a moving target and sometimes how an entity can be monitored/manages needs to change to meet reality. So while the standards might mandate a specific behavior, innovations in implementations and usages might lead to non-compliant changes. As compared to, say, a transport protocol, the "sender" of monitored values is the MIB implementation, and the receiver is the NMS/operator. Be conservative in what you send - the MIB "agent" implementer should follow the MIB specifications in determining what to send. Be liberal in what you receive - an NMS/operator should "trust but verify" - and read the release notes. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit > Claise > Sent: Thursday, June 25, 2015 6:55 AM > To: Ben Campbell; The IESG > Cc: draft-ietf-opsawg-vmm-mib.ad@ietf.org; draft-ietf-opsawg-vmm- > mib@ietf.org; opsawg-chairs@ietf.org; opsawg@ietf.org; draft-ietf-opsawg- > vmm-mib.shepherd@ietf.org > Subject: Re: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg- > vmm-mib-03: (with COMMENT) > > On 23/06/2015 22:42, Ben Campbell wrote: > > Ben Campbell has entered the following ballot position for > > draft-ietf-opsawg-vmm-mib-03: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I mean the following as a question, because it's something I've never > > thought about, but seems odd: Is it normal to have 2119 language in the > > description fields in a MIB definition? Who is that language intended > > for? > I've seen that before. > I don't think that's an issue. > > Regards, Benoit > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Jun 26 18:45: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 D0B451B2AF3 for ; Fri, 26 Jun 2015 18:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 QggSXA-CY8Ux for ; Fri, 26 Jun 2015 18:45:06 -0700 (PDT) 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 0BA331B2AED for ; Fri, 26 Jun 2015 18:45:05 -0700 (PDT) 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 BYA86364; Sat, 27 Jun 2015 01:45:04 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 27 Jun 2015 02:45:01 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.68]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 27 Jun 2015 09:44:55 +0800 From: Youjianjie To: Warren Kumari , "opsawg@ietf.org" , "draft-you-opsawg-capwap-separation-for-mp@tools.ietf.org" Thread-Topic: Call for Adoption: draft-you-opsawg-capwap-separation-for-mp Thread-Index: AQHQr0efEWPZ9Uxu3U2T5y5F2FTbCJ2/lniw Date: Sat, 27 Jun 2015 01:44:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [OPSAWG] =?utf-8?b?562U5aSNOiBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQt?= =?utf-8?q?you-opsawg-capwap-separation-for-mp?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 01:45:09 -0000 U3VwcG9ydCBhcyBhIGNvLWF1dGhvci4gSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0KVGhhbmtzLA0KSmlhbmppZQ0KDQo+IC0tLS0t6YKu5Lu2 5Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBXYXJyZW4gS3VtYXJpIFttYWlsdG86d2FycmVuQGt1 bWFyaS5uZXRdDQo+IOWPkemAgeaXtumXtDogMjAxNeW5tDbmnIgyNeaXpSAyMTowNQ0KPiDmlLbk u7bkuro6IG9wc2F3Z0BpZXRmLm9yZzsNCj4gZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJh dGlvbi1mb3ItbXBAdG9vbHMuaWV0Zi5vcmcNCj4g5Li76aKYOiBDYWxsIGZvciBBZG9wdGlvbjog ZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXANCj4gDQo+IERlYXIgT3Bz QVdHIFdHLA0KPiANCj4gVGhlIGF1dGhvcnMgb2YgZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2Vw YXJhdGlvbi1mb3ItbXAgaGF2ZSBhc2tlZCBmb3IgdGhpcw0KPiBkcmFmdCB0byBiZSBjb25zaWRl cmVkIGZvciBPcHNBV0cgYWRvcHRpb24uIEl0IHdhcyBwcmVzZW50ZWQgYW5kIGRpc2N1c3NlZA0K PiBzb21ld2hhdCBhdCBJRVRGOTEgaW4gRGFsbGFzIC0gdGhlcmUgd2FzIGEgcXVlc3Rpb24gcmFp c2VkIGFib3V0IHNpbWlsYXJpdGllcyAvDQo+IG92ZXJsYXAgd2l0aCBkcmFmdC1pZXRmLW9wc2F3 Zy1jYXB3YXAtYWx0LXR1bm5lbCAod2hpY2ggbGllcyB3aXRoIHRoZSBJRVNHKS4NCj4gQWZ0ZXIg c29tZSBkaXNjdXNzaW9ucyB3ZSBoYXZlIGRlY2lkZWQgdGhhdCB0aGVzZSBkb2N1bWVudHMgY29t cGxlbWVudA0KPiBlYWNoIG90aGVyLCBhbmQgc28gYXNrIHRoZSBXRyB0byBjb25zaWRlcg0KPiBk cmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcCBmb3IgYWRvcHRpb24uDQo+ IA0KPiBXZSB3b3VsZCBsaWtlIDQtNSBwZW9wbGUgdG8gY29tbWl0IHRvIGVkaXRpbmcgYW5kIGNv bnRyaWJ1dGluZyB0byB0aGUNCj4gZG9jdW1lbnQsIGFuZCBhIHNpbWlsYXIgbnVtYmVyIHRvIGNv bW1pdCB0byByZXZpZXdpbmcgaXQuDQo+IA0KPiBUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGhlcmU6 DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlvdS1vcHNhd2ctY2Fw d2FwLXNlcGFyYXRpb24tZm9yLW1wLw0KPiANCj4gUGxlYXNlIHJldmlldyB0aGlzIGRyYWZ0IHRv IHNlZSBpZiB5b3UgdGhpbmsgaXQgaXMgc3VpdGFibGUgZm9yIGFkb3B0aW9uIGJ5IE9wc0FXRywN Cj4gYW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBjbGVhcmx5IHN0YXRpbmcgeW91ciB2aWV3Lg0K PiANCj4gUGxlYXNlIGFsc28gaW5kaWNhdGUgaWYgeW91IGFyZSB3aWxsaW5nIHRvIGNvbnRyaWJ1 dGUgdGV4dCwgcmV2aWV3LCBldGMuDQo+IA0KPiBUaGlzIGNhbGwgZm9yIGFkb3B0aW9uIGVuZHMg VGh1IDA5LUp1bC0yMDE1Lg0KPiANCj4gSW4gYWRkaXRpb24sIHRvIHNhdGlzZnkgUkZDIDY3MDIg KCJQcm9tb3RpbmcgQ29tcGxpYW5jZSB3aXRoIEludGVsbGVjdHVhbA0KPiBQcm9wZXJ0eSBSaWdo dHMgKElQUikiKToNCj4gSWYgeW91IGFyZSBwZXJzb25hbGx5IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvDQo+IGRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1w LCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4NCj4gY29tcGxpYW5jZSB3aXRoIElFVEYg SVBSIHJ1bGVzPyAoU2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSwgYW5kDQo+IDUzNzggZm9yIG1v cmUgZGV0YWlscy4pDQo+IA0KPiANCj4gVGhhbmtzLA0KPiBXYXJyZW4gS3VtYXJpDQo+IChhcyBP cHNBV0cgV0cgY28tY2hhaXIpDQo+IA0KPiANCj4gLS0NCj4gSSBkb24ndCB0aGluayB0aGUgZXhl Y3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlvdXNseSBhIGJhZCBpZGVhIGluIHRo ZQ0KPiBmaXJzdCBwbGFjZS4NCj4gVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2VscyBp biB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdyZXQgYXQNCj4gaGF2aW5nIGNo b3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpciBvZiBwYW50 cy4NCj4gICAgLS0tbWFmDQo= From nobody Sat Jun 27 00:01:07 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 17FCF1B2EAE for ; Sat, 27 Jun 2015 00:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.079 X-Spam-Level: ** X-Spam-Status: No, score=2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Ssbzaxg10vCk for ; Sat, 27 Jun 2015 00:01:05 -0700 (PDT) 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 5BE901B2E8A for ; Sat, 27 Jun 2015 00:01:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYB00860; Sat, 27 Jun 2015 07:01:02 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 27 Jun 2015 08:01:00 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Sat, 27 Jun 2015 15:00:55 +0800 From: Duzongpeng To: "warren@kumari.net" Thread-Topic: =?gb2312?B?UkU6IFtPUFNBV0ddILTwuLQ6IENhbGwgZm9yIEFkb3B0aW9uOiBkcmFmdC15?= =?gb2312?Q?ou-opsawg-capwap-separation-for-mp?= Thread-Index: AdCwpwJa3cXHYdnaRMKXKtpZ3qQ2Qw== Date: Sat, 27 Jun 2015 07:00:54 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: multipart/alternative; boundary="_000_BAFEC9523F57BC48A51C20226A5589575E93233Ankgeml505mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] =?gb2312?b?tPC4tDogQ2FsbCBmb3IgQWRvcHRpb246IGRyYWZ0LXlv?= =?gb2312?b?dS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1w?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 07:01:07 -0000 --_000_BAFEC9523F57BC48A51C20226A5589575E93233Ankgeml505mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFdhcnJlbg0KDQpJIGNhbiBjb21taXQgdG8gZWRpdGluZyBhbmQgY29udHJpYnV0aW5nIHRv IHRoZSBkb2N1bWVudC4NCg0KQmVzdCBSZWdhcmRzDQpab25ncGVuZyBEdQ0KDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KW09QU0FXR10gtPC4tDogQ2FsbCBmb3IgQWRvcHRpb246 IGRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wDQoNCllvdWppYW5qaWUg PHlvdWppYW5qaWVAaHVhd2VpLmNvbT4gU2F0LCAyNyBKdW5lIDIwMTUgMDE6NDUgVVRDU2hvdyBo ZWFkZXI8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/ZW1haWxfbGlz dD1vcHNhd2c+DQoNCg0KDQpTdXBwb3J0IGFzIGEgY28tYXV0aG9yLiBJIGFtIG5vdCBhd2FyZSBv ZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Lg0KDQoNCg0KVGhhbmtzLA0KDQpK aWFuamllDQoNCg0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KDQo+ILeivP7IyzogV2FycmVuIEt1 bWFyaSBbbWFpbHRvOndhcnJlbkBrdW1hcmkubmV0XQ0KDQo+ILeiy83KsbzkOiAyMDE1xOo21MIy NcjVIDIxOjA1DQoNCj4gytW8/sjLOiBvcHNhd2dAaWV0Zi5vcmc7DQoNCj4gZHJhZnQteW91LW9w c2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXBAdG9vbHMuaWV0Zi5vcmcNCg0KPiDW98ziOiBD YWxsIGZvciBBZG9wdGlvbjogZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3It bXANCg0KPg0KDQo+IERlYXIgT3BzQVdHIFdHLA0KDQo+DQoNCj4gVGhlIGF1dGhvcnMgb2YgZHJh ZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAgaGF2ZSBhc2tlZCBmb3IgdGhp cw0KDQo+IGRyYWZ0IHRvIGJlIGNvbnNpZGVyZWQgZm9yIE9wc0FXRyBhZG9wdGlvbi4gSXQgd2Fz IHByZXNlbnRlZCBhbmQgZGlzY3Vzc2VkDQoNCj4gc29tZXdoYXQgYXQgSUVURjkxIGluIERhbGxh cyAtIHRoZXJlIHdhcyBhIHF1ZXN0aW9uIHJhaXNlZCBhYm91dCBzaW1pbGFyaXRpZXMgLw0KDQo+ IG92ZXJsYXAgd2l0aCBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0LXR1bm5lbCAod2hpY2gg bGllcyB3aXRoIHRoZSBJRVNHKS4NCg0KPiBBZnRlciBzb21lIGRpc2N1c3Npb25zIHdlIGhhdmUg ZGVjaWRlZCB0aGF0IHRoZXNlIGRvY3VtZW50cyBjb21wbGVtZW50DQoNCj4gZWFjaCBvdGhlciwg YW5kIHNvIGFzayB0aGUgV0cgdG8gY29uc2lkZXINCg0KPiBkcmFmdC15b3Utb3BzYXdnLWNhcHdh cC1zZXBhcmF0aW9uLWZvci1tcCBmb3IgYWRvcHRpb24uDQoNCj4NCg0KPiBXZSB3b3VsZCBsaWtl IDQtNSBwZW9wbGUgdG8gY29tbWl0IHRvIGVkaXRpbmcgYW5kIGNvbnRyaWJ1dGluZyB0byB0aGUN Cg0KPiBkb2N1bWVudCwgYW5kIGEgc2ltaWxhciBudW1iZXIgdG8gY29tbWl0IHRvIHJldmlld2lu ZyBpdC4NCg0KPg0KDQo+IFRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZToNCg0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0 aW9uLWZvci1tcC8NCg0KPg0KDQo+IFBsZWFzZSByZXZpZXcgdGhpcyBkcmFmdCB0byBzZWUgaWYg eW91IHRoaW5rIGl0IGlzIHN1aXRhYmxlIGZvciBhZG9wdGlvbiBieSBPcHNBV0csDQoNCj4gYW5k IGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBjbGVhcmx5IHN0YXRpbmcgeW91ciB2aWV3Lg0KDQo+DQoN Cj4gUGxlYXNlIGFsc28gaW5kaWNhdGUgaWYgeW91IGFyZSB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUg dGV4dCwgcmV2aWV3LCBldGMuDQoNCj4NCg0KPiBUaGlzIGNhbGwgZm9yIGFkb3B0aW9uIGVuZHMg VGh1IDA5LUp1bC0yMDE1Lg0KDQo+DQoNCj4gSW4gYWRkaXRpb24sIHRvIHNhdGlzZnkgUkZDIDY3 MDIgKCJQcm9tb3RpbmcgQ29tcGxpYW5jZSB3aXRoIEludGVsbGVjdHVhbA0KDQo+IFByb3BlcnR5 IFJpZ2h0cyAoSVBSKSIpOg0KDQo+IElmIHlvdSBhcmUgcGVyc29uYWxseSBhd2FyZSBvZiBhbnkg SVBSIHRoYXQgYXBwbGllcyB0bw0KDQo+IGRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRp b24tZm9yLW1wLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4NCg0KPiBjb21wbGlhbmNl IHdpdGggSUVURiBJUFIgcnVsZXM/IChTZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5LCBhbmQNCg0K PiA1Mzc4IGZvciBtb3JlIGRldGFpbHMuKQ0KDQo+DQoNCj4NCg0KPiBUaGFua3MsDQoNCj4gV2Fy cmVuIEt1bWFyaQ0KDQo+IChhcyBPcHNBV0cgV0cgY28tY2hhaXIpDQoNCj4NCg0KPg0KDQo+IC0t DQoNCj4gSSBkb24ndCB0aGluayB0aGUgZXhlY3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2Fz IG9idmlvdXNseSBhIGJhZCBpZGVhIGluIHRoZQ0KDQo+IGZpcnN0IHBsYWNlLg0KDQo+IFRoaXMg aXMgbGlrZSBwdXR0aW5nIHJhYmlkIHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4 cHJlc3NpbmcgcmVncmV0IGF0DQoNCj4gaGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJh YmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpciBvZiBwYW50cy4NCg0KPiAgICAtLS1tYWYNCg0K --_000_BAFEC9523F57BC48A51C20226A5589575E93233Ankgeml505mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Warren

 

I can commit to editing and con= tributing to the document.

 

Best Regards<= /p>

Zongpeng Du

 

 

-----Original Message-----

[OPSAWG] =B4=F0=B8=B4: Call for Adoption: draf= t-you-opsawg-capwap-separation-for-mp

Youjianjie <youjianjie@huawei.com>=  Sat, 27 June 2015 01:45 UTCShow header

 

Support as a co-author. I am not aware of any IPR that applies to =
this draft.
 
Than=
ks,
Jian=
jie
 
>=
 -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>=
 =B7=A2=BC=FE=C8=CB: Warren Kumari [mailto:wa=
rren@kumari.net]
>=
 =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C225=C8=D5 21:05
>=
 =CA=D5=BC=FE=C8=CB: opsawg@ietf.org;
>=
 draft-you-opsawg-capwap-separation-for-mp@tools.ietf.org=

>=
 =D6=F7=CC=E2: Call for Adoption: draft-you-o=
psawg-capwap-separation-for-mp
>=
 
>=
 Dear OpsAWG WG,
>=
 
>=
 The authors of draft-you-opsawg-capwap-separation-for-mp have asked for th=
is
>=
 draft to be considered for OpsAWG adoption. It was presented and discussed=

>=
 somewhat at IETF91 in Dallas - there was a question raised about similarit=
ies /
>=
 overlap with draft-ietf-opsawg-capwap-alt-tunnel (which lies with the IESG=
).
>=
 After some discussions we have decided that these documents complement
>=
 each other, and so ask the WG to consider
>=
 draft-you-opsawg-capwap-separation-for-mp for adoption.<=
/pre>

>=
 


>=
 We would like 4-5 people to commit to editing and contributing to the=



>=
 document, and a similar number to commit to reviewing it.


>=
 


>=
 The draft is available here:


>=
 https://datatracker.ietf.org/doc/draft-you-opsawg-capwap-separation-for-mp=
/


>=
 


>=
 Please review this draft to see if you think it is suitable for adoption b=
y 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 Thu 09-Jul-2015.


>=
 


>=
 In addition, to satisfy RFC 6702 ("Promoting Compliance with Intellec=
tual


>=
 Property Rights (IPR)"):


>=
 If you are personally aware of any IPR that applies to

>=
 draft-you-opsawg-capwap-separation-for-mp, has this IPR been disclosed in<=
o:p>


>=
 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 i=
n the


>=
 first place.


>=
 This is like putting rabid weasels in your pants, and later expressing reg=
ret at


>=
 having chosen those particular rabid weasels and that pair of pants.<=
/o:p>


>=
    ---maf


 
--_000_BAFEC9523F57BC48A51C20226A5589575E93233Ankgeml505mbxchi_-- From nobody Sun Jun 28 18:29: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 96FBE1AD26B for ; Sun, 28 Jun 2015 18:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.654 X-Spam-Level: * X-Spam-Status: No, score=1.654 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 yEfmPw1tm_MI for ; Sun, 28 Jun 2015 18:29:05 -0700 (PDT) Received: from 189corp.21cn.com (forptr.bnet.cn [183.61.185.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5A10D1AD34E for ; Sun, 28 Jun 2015 18:29:03 -0700 (PDT) HMM_SOURCE_IP: 10.64.15.12:52019.1241299911 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from zr-54b147581e9f (unknown [10.64.15.12]) by 189corp.21cn.com (HERMES) with ESMTP id C3D343C0093; Mon, 29 Jun 2015 09:28:35 +0800 (CST) Received: from zr-54b147581e9f ([121.33.232.98]) by zmentas2(MEDUSA 10.64.15.12) with ESMTP id 1435541315.179389 for youjianjie@huawei.com ; Mon Jun 29 09:28:53 2015 0/X-Total-Score: 20: X-FILTER-SCORE: to=<9a90968b8a828f8b8a866189968298868a4f84908e98829393868f618c968e82938a4f8f8695709194627868618a8695874f90938885938287954e9a90964e9091948298884e8482919882914e948691829382958a908f4e8790934e8e91619590908d944f8a8695874f909388>, score=<1435541333NNNNNNNONNNOOOOQQQNNNN5qZ55Z5eZq5e24n8oFZ5ZZ> X-REAL-FROM: zhangr@gsta.com X-Receive-IP: 121.33.232.98 zhangr@gsta.com Date: Mon, 29 Jun 2015 09:28:34 +0800 From: =?utf-8?B?56CU56m26Zmi5byg6I2j?= To: Youjianjie , "Warren Kumari" , "opsawg@ietf.org" , "draft-you-opsawg-capwap-separation-for-mp@tools.ietf.org" References: , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <201506290928317506241@gsta.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart068850252344_=----" Archived-At: Subject: Re: [OPSAWG] =?utf-8?b?562U5aSNOiBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQt?= =?utf-8?q?you-opsawg-capwap-separation-for-mp?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 29 Jun 2015 01:29:10 -0000 This is a multi-part message in MIME format. ------=_001_NextPart068850252344_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYSBjby1hdXRob3IsSSBoYXZlbid0IGZvdW5kIGFueSBJUFIgYXBwbHlpbmcgdG8gdGhlIGRy YWZ0LiBJIHN1cHBvcnQgaXRzIGFkb3B0aW9uLiANClRoYW5rcy4NCg0KDQoNClJvbmcNCg0K5Y+R 5Lu25Lq677yaIFlvdWppYW5qaWUNCuWPkemAgeaXtumXtO+8miAyMDE1LTA2LTI3IDA5OjQ0DQrm lLbku7bkurrvvJogV2FycmVuIEt1bWFyaTsgb3BzYXdnQGlldGYub3JnOyBkcmFmdC15b3Utb3Bz YXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcEB0b29scy5pZXRmLm9yZw0K5Li76aKY77yaIFtP UFNBV0dd562U5aSNOiBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAt c2VwYXJhdGlvbi1mb3ItbXANClN1cHBvcnQgYXMgYSBjby1hdXRob3IuIEkgYW0gbm90IGF3YXJl IG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQuDQoNClRoYW5rcywNCkppYW5q aWUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogV2FycmVuIEt1bWFy aSBbbWFpbHRvOndhcnJlbkBrdW1hcmkubmV0XQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTXlubQ25pyI MjXml6UgMjE6MDUNCj4g5pS25Lu25Lq6OiBvcHNhd2dAaWV0Zi5vcmc7DQo+IGRyYWZ0LXlvdS1v cHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wQHRvb2xzLmlldGYub3JnDQo+IOS4u+mimDog Q2FsbCBmb3IgQWRvcHRpb246IGRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9y LW1wDQo+IA0KPiBEZWFyIE9wc0FXRyBXRywNCj4gDQo+IFRoZSBhdXRob3JzIG9mIGRyYWZ0LXlv dS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wIGhhdmUgYXNrZWQgZm9yIHRoaXMNCj4g ZHJhZnQgdG8gYmUgY29uc2lkZXJlZCBmb3IgT3BzQVdHIGFkb3B0aW9uLiBJdCB3YXMgcHJlc2Vu dGVkIGFuZCBkaXNjdXNzZWQNCj4gc29tZXdoYXQgYXQgSUVURjkxIGluIERhbGxhcyAtIHRoZXJl IHdhcyBhIHF1ZXN0aW9uIHJhaXNlZCBhYm91dCBzaW1pbGFyaXRpZXMgLw0KPiBvdmVybGFwIHdp dGggZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwgKHdoaWNoIGxpZXMgd2l0aCB0 aGUgSUVTRykuDQo+IEFmdGVyIHNvbWUgZGlzY3Vzc2lvbnMgd2UgaGF2ZSBkZWNpZGVkIHRoYXQg dGhlc2UgZG9jdW1lbnRzIGNvbXBsZW1lbnQNCj4gZWFjaCBvdGhlciwgYW5kIHNvIGFzayB0aGUg V0cgdG8gY29uc2lkZXINCj4gZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3It bXAgZm9yIGFkb3B0aW9uLg0KPiANCj4gV2Ugd291bGQgbGlrZSA0LTUgcGVvcGxlIHRvIGNvbW1p dCB0byBlZGl0aW5nIGFuZCBjb250cmlidXRpbmcgdG8gdGhlDQo+IGRvY3VtZW50LCBhbmQgYSBz aW1pbGFyIG51bWJlciB0byBjb21taXQgdG8gcmV2aWV3aW5nIGl0Lg0KPiANCj4gVGhlIGRyYWZ0 IGlzIGF2YWlsYWJsZSBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcC8NCj4gDQo+IFBsZWFzZSBy ZXZpZXcgdGhpcyBkcmFmdCB0byBzZWUgaWYgeW91IHRoaW5rIGl0IGlzIHN1aXRhYmxlIGZvciBh ZG9wdGlvbiBieSBPcHNBV0csDQo+IGFuZCBjb21tZW50cyB0byB0aGUgbGlzdCwgY2xlYXJseSBz dGF0aW5nIHlvdXIgdmlldy4NCj4gDQo+IFBsZWFzZSBhbHNvIGluZGljYXRlIGlmIHlvdSBhcmUg d2lsbGluZyB0byBjb250cmlidXRlIHRleHQsIHJldmlldywgZXRjLg0KPiANCj4gVGhpcyBjYWxs IGZvciBhZG9wdGlvbiBlbmRzIFRodSAwOS1KdWwtMjAxNS4NCj4gDQo+IEluIGFkZGl0aW9uLCB0 byBzYXRpc2Z5IFJGQyA2NzAyICgiUHJvbW90aW5nIENvbXBsaWFuY2Ugd2l0aCBJbnRlbGxlY3R1 YWwNCj4gUHJvcGVydHkgUmlnaHRzIChJUFIpIik6DQo+IElmIHlvdSBhcmUgcGVyc29uYWxseSBh d2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0bw0KPiBkcmFmdC15b3Utb3BzYXdnLWNhcHdh cC1zZXBhcmF0aW9uLWZvci1tcCwgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluDQo+IGNv bXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcz8gKFNlZSBSRkNzIDM5NzksIDQ4NzksIDM2Njks IGFuZA0KPiA1Mzc4IGZvciBtb3JlIGRldGFpbHMuKQ0KPiANCj4gDQo+IFRoYW5rcywNCj4gV2Fy cmVuIEt1bWFyaQ0KPiAoYXMgT3BzQVdHIFdHIGNvLWNoYWlyKQ0KPiANCj4gDQo+IC0tDQo+IEkg ZG9uJ3QgdGhpbmsgdGhlIGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3Vz bHkgYSBiYWQgaWRlYSBpbiB0aGUNCj4gZmlyc3QgcGxhY2UuDQo+IFRoaXMgaXMgbGlrZSBwdXR0 aW5nIHJhYmlkIHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3NpbmcgcmVn cmV0IGF0DQo+IGhhdmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFu ZCB0aGF0IHBhaXIgb2YgcGFudHMuDQo+ICAgIC0tLW1hZg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FXR0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c= ------=_001_NextPart068850252344_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
As a co-author,I haven't found any IPR applying to the draft. I suppo= rt its=20 adoption.
Thanks.
Rong
 
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Youjianjie
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A 2015-06-27&= nbsp;09:44
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Warren Kumari; opsawg@ietf.org; d= raft-you-opsawg-capwap-separation-for-mp@tools.ietf.org
=E4=B8=BB=E9=A2=98=EF=BC=9A [OPSAWG]=E7=AD=94=E5=A4=8D: C= all for Adoption:=20 draft-you-opsawg-capwap-separation-for-mp
Support as a co-author. I am not a= ware of any IPR that applies to this&nb= sp;draft.
 
Thanks,
Jianjie
 
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Warren Kumari [= mailto:warren@kumari.net]
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B46= =E6=9C=8825=E6=97=A5 21:05
> =E6=94=B6=E4=BB=B6=E4=BA=BA: opsawg@ietf.org;
> draft-you-opsawg-capwap-separation-for-mp@tools.ietf.org
> =E4=B8=BB=E9=A2=98: Call for Adoption: = draft-you-opsawg-capwap-separation-for-mp
> 
> Dear OpsAWG WG,
> 
> The authors of draft-you-opsawg-capwap-separ= ation-for-mp have asked for this
> draft to be considered for OpsAWG&= nbsp;adoption. It was presented and discussed
> somewhat at IETF91 in Dallas -&nbs= p;there was a question raised about similari= ties /
> overlap with draft-ietf-opsawg-capwap-alt-tunnel&= nbsp;(which lies with the IESG).
> After some discussions we have dec= ided that these documents complement
> each other, and so ask the WG=  to consider
> draft-you-opsawg-capwap-separation-for-mp for ado= ption.
> 
> We would like 4-5 people to c= ommit to editing and contributing to the
> document, and a similar number to&= nbsp;commit to reviewing it.
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-you-opsawg-capwap-se= paration-for-mp/
> 
> Please review this draft to see&nb= sp;if you think it is suitable for adop= tion by OpsAWG,
> and comments to the list, clearly&= nbsp;stating your view.
> 
> Please also indicate if you are&nb= sp;willing to contribute text, review, etc.
> 
> This call for adoption ends Thu&nb= sp;09-Jul-2015.
> 
> In addition, to satisfy RFC 6702&n= bsp;("Promoting Compliance with Intellectual
> Property Rights (IPR)"):
> If you are personally aware of&nbs= p;any IPR that applies to
> draft-you-opsawg-capwap-separation-for-mp, has th= is IPR been disclosed in
> compliance with IETF IPR rules? (S= ee RFCs 3979, 4879, 3669, and
> 5378 for more details.)
> 
> 
> Thanks,
> Warren Kumari
> (as OpsAWG WG co-chair)
> 
> 
> --
> I don't think the execution is&nbs= p;relevant when it was obviously a bad = idea in the
> first place.
> This is like putting rabid weasels=  in your pants, and later expressing re= gret at
> having chosen those particular rabid&nb= sp;weasels and that pair of pants.
>    ---maf
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
------=_001_NextPart068850252344_=------ From nobody Sun Jun 28 19:16: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 45B051B2E17 for ; Sun, 28 Jun 2015 19:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 51tun2odYIX1 for ; Sun, 28 Jun 2015 19:16:01 -0700 (PDT) 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 A2CF91B2E0C for ; Sun, 28 Jun 2015 19:16:00 -0700 (PDT) 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 BUM10318; Mon, 29 Jun 2015 02:15:58 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 03:15:57 +0100 Received: from NKGEML503-MBX.china.huawei.com ([169.254.5.172]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 10:15:50 +0800 From: Liyizhou To: Warren Kumari , "opsawg@ietf.org" , "draft-you-opsawg-capwap-separation-for-mp@tools.ietf.org" Thread-Topic: [OPSAWG]: Call for Adoption: draft-you-opsawg-capwap-separation-for-mp Thread-Index: AQHQshGEoqhqkA25qk28AkH+rFMH6A== Date: Mon, 29 Jun 2015 02:15:49 +0000 Message-ID: References: , <201506290928317506241@gsta.com> In-Reply-To: <201506290928317506241@gsta.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.180.237] Content-Type: multipart/alternative; boundary="_000_D408889639FC5E4FADB4E00A3E01FA8F8387EE73nkgeml503mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] : Call for Adoption: draft-you-opsawg-capwap-separation-for-mp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 29 Jun 2015 02:16:05 -0000 --_000_D408889639FC5E4FADB4E00A3E01FA8F8387EE73nkgeml503mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCB0aGUgYWRvcHRpb24uIEl0IGlzIGEgdXNlZnVsIGNvbXBvbmVudCBmb3IgYWx0ZXJu YXRlIHR1bm5lbCBzZXR1cCBjYXNlLg0KDQpJIGFtIHdpbGxpbmcgdG8gaGVscCB0aGUgcmV2aWV3 IGFuZCBlZGl0aW5nLg0KDQpUaGFua3MsDQpZaXpob3UNCg0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCj4g5Y+R5Lu25Lq6OiBXYXJyZW4gS3VtYXJpIFttYWlsdG86d2FycmVuQGt1bWFyaS5u ZXRdDQo+IOWPkemAgeaXtumXtDogMjAxNeW5tDbmnIgyNeaXpSAyMTowNQ0KPiDmlLbku7bkuro6 IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsNCj4gZHJhZnQteW91LW9w c2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wQHRvb2xzLmlldGYub3JnPg0KPiDk uLvpopg6IENhbGwgZm9yIEFkb3B0aW9uOiBkcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0 aW9uLWZvci1tcA0KPg0KPiBEZWFyIE9wc0FXRyBXRywNCj4NCj4gVGhlIGF1dGhvcnMgb2YgZHJh ZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAgaGF2ZSBhc2tlZCBmb3IgdGhp cw0KPiBkcmFmdCB0byBiZSBjb25zaWRlcmVkIGZvciBPcHNBV0cgYWRvcHRpb24uIEl0IHdhcyBw cmVzZW50ZWQgYW5kIGRpc2N1c3NlZA0KPiBzb21ld2hhdCBhdCBJRVRGOTEgaW4gRGFsbGFzIC0g dGhlcmUgd2FzIGEgcXVlc3Rpb24gcmFpc2VkIGFib3V0IHNpbWlsYXJpdGllcyAvDQo+IG92ZXJs YXAgd2l0aCBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0LXR1bm5lbCAod2hpY2ggbGllcyB3 aXRoIHRoZSBJRVNHKS4NCj4gQWZ0ZXIgc29tZSBkaXNjdXNzaW9ucyB3ZSBoYXZlIGRlY2lkZWQg dGhhdCB0aGVzZSBkb2N1bWVudHMgY29tcGxlbWVudA0KPiBlYWNoIG90aGVyLCBhbmQgc28gYXNr IHRoZSBXRyB0byBjb25zaWRlcg0KPiBkcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9u LWZvci1tcCBmb3IgYWRvcHRpb24uDQo+DQo+IFdlIHdvdWxkIGxpa2UgNC01IHBlb3BsZSB0byBj b21taXQgdG8gZWRpdGluZyBhbmQgY29udHJpYnV0aW5nIHRvIHRoZQ0KPiBkb2N1bWVudCwgYW5k IGEgc2ltaWxhciBudW1iZXIgdG8gY29tbWl0IHRvIHJldmlld2luZyBpdC4NCj4NCj4gVGhlIGRy YWZ0IGlzIGF2YWlsYWJsZSBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcC8NCj4NCj4gUGxlYXNl IHJldmlldyB0aGlzIGRyYWZ0IHRvIHNlZSBpZiB5b3UgdGhpbmsgaXQgaXMgc3VpdGFibGUgZm9y IGFkb3B0aW9uIGJ5IE9wc0FXRywNCj4gYW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBjbGVhcmx5 IHN0YXRpbmcgeW91ciB2aWV3Lg0KPg0KPiBQbGVhc2UgYWxzbyBpbmRpY2F0ZSBpZiB5b3UgYXJl IHdpbGxpbmcgdG8gY29udHJpYnV0ZSB0ZXh0LCByZXZpZXcsIGV0Yy4NCj4NCj4gVGhpcyBjYWxs IGZvciBhZG9wdGlvbiBlbmRzIFRodSAwOS1KdWwtMjAxNS4NCj4NCj4gSW4gYWRkaXRpb24sIHRv IHNhdGlzZnkgUkZDIDY3MDIgKCJQcm9tb3RpbmcgQ29tcGxpYW5jZSB3aXRoIEludGVsbGVjdHVh bA0KPiBQcm9wZXJ0eSBSaWdodHMgKElQUikiKToNCj4gSWYgeW91IGFyZSBwZXJzb25hbGx5IGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvDQo+IGRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2Fw LXNlcGFyYXRpb24tZm9yLW1wLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4NCj4gY29t cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPyAoU2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSwg YW5kDQo+IDUzNzggZm9yIG1vcmUgZGV0YWlscy4pDQo+DQo+DQo+IFRoYW5rcywNCj4gV2FycmVu IEt1bWFyaQ0KPiAoYXMgT3BzQVdHIFdHIGNvLWNoYWlyKQ0KPg0KPg0KPiAtLQ0KPiBJIGRvbid0 IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEg YmFkIGlkZWEgaW4gdGhlDQo+IGZpcnN0IHBsYWNlLg0KPiBUaGlzIGlzIGxpa2UgcHV0dGluZyBy YWJpZCB3ZWFzZWxzIGluIHlvdXIgcGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nIHJlZ3JldCBh dA0KPiBoYXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQgdGhh dCBwYWlyIG9mIHBhbnRzLg0KPiAgICAtLS1tYWYNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPUFNBV0cgbWFpbGluZyBsaXN0DQpPUFNBV0dAaWV0Zi5v cmc8bWFpbHRvOk9QU0FXR0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb3BzYXdnDQo= --_000_D408889639FC5E4FADB4E00A3E01FA8F8387EE73nkgeml503mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzsNCgltc28tYmVsaWV2ZS1ub3JtYWwtbGVmdDp5ZXM7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseTrlrovkvZM7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOah huaWh+acrCBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uQ2hhcg0KCXttc28t c3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2T O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IVtpZiBtc28gOV0+PHN0eWxlPnAuTXNv Tm9ybWFsDQoJe21hcmdpbi1sZWZ0OjcuNXB0O30NCjwvc3R5bGU+PCFbZW5kaWZdPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcuNXB0O21hcmdpbi10b3A6Ny41cHQ7bWFyZ2luLXJpZ2h0OjcuNXB0O21hcmdpbi1ib3R0b206 Ny41cHQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+ U3VwcG9ydCB0aGUgYWRvcHRpb24uIEl0IGlzIGEgdXNlZnVsIGNvbXBvbmVudCBmb3IgYWx0ZXJu YXRlIHR1bm5lbCBzZXR1cCBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkkgYW0gd2lsbGluZyB0byBoZWxwIHRoZSBy ZXZpZXcgYW5kIGVkaXRpbmcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+WWl6aG91PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBj bTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOy0tLS0tPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj7pgq7ku7bljp/ku7Y8c3BhbiBsYW5nPSJF Ti1VUyI+LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh Y2siPiZndDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46Jm5ic3A7V2FycmVuJm5ic3A7S3Vt YXJpJm5ic3A7WzxhIGhyZWY9Im1haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldCI+bWFpbHRvOndhcnJl bkBrdW1hcmkubmV0PC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPiZndDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46Jm5ic3A7MjAxNTwv c3Bhbj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Njwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+ MjU8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzIxOjA1PG86cD48L286cD48L3Nw YW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj7mlLbku7bkuro8c3BhbiBsYW5n PSJFTi1VUyI+OiZuYnNwOzxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmciPm9wc2F3Z0Bp ZXRmLm9yZzwvYT47PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj4mZ3Q7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNl cGFyYXRpb24tZm9yLW1wQHRvb2xzLmlldGYub3JnIj5kcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1z ZXBhcmF0aW9uLWZvci1tcEB0b29scy5pZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjombmJzcDtD YWxsJm5ic3A7Zm9yJm5ic3A7QWRvcHRpb246Jm5ic3A7ZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAt c2VwYXJhdGlvbi1mb3ItbXA8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+Jmd0OyZuYnNwO0RlYXImbmJzcDtPcHNBV0cmbmJzcDtXRyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNt O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7VGhlJm5ic3A7YXV0aG9ycyZuYnNwO29m Jm5ic3A7ZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAmbmJzcDtoYXZl Jm5ic3A7YXNrZWQmbmJzcDtmb3ImbmJzcDt0aGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDtkcmFmdCZuYnNwO3RvJm5ic3A7YmUmbmJzcDtjb25z aWRlcmVkJm5ic3A7Zm9yJm5ic3A7T3BzQVdHJm5ic3A7YWRvcHRpb24uJm5ic3A7SXQmbmJzcDt3 YXMmbmJzcDtwcmVzZW50ZWQmbmJzcDthbmQmbmJzcDtkaXNjdXNzZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jmd0OyZuYnNwO3NvbWV3aGF0Jm5ic3A7YXQmbmJz cDtJRVRGOTEmbmJzcDtpbiZuYnNwO0RhbGxhcyZuYnNwOy0mbmJzcDt0aGVyZSZuYnNwO3dhcyZu YnNwO2EmbmJzcDtxdWVzdGlvbiZuYnNwO3JhaXNlZCZuYnNwO2Fib3V0Jm5ic3A7c2ltaWxhcml0 aWVzJm5ic3A7LzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7 Jm5ic3A7b3ZlcmxhcCZuYnNwO3dpdGgmbmJzcDtkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0 LXR1bm5lbCZuYnNwOyh3aGljaCZuYnNwO2xpZXMmbmJzcDt3aXRoJm5ic3A7dGhlJm5ic3A7SUVT RykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDtB ZnRlciZuYnNwO3NvbWUmbmJzcDtkaXNjdXNzaW9ucyZuYnNwO3dlJm5ic3A7aGF2ZSZuYnNwO2Rl Y2lkZWQmbmJzcDt0aGF0Jm5ic3A7dGhlc2UmbmJzcDtkb2N1bWVudHMmbmJzcDtjb21wbGVtZW50 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDtlYWNo Jm5ic3A7b3RoZXIsJm5ic3A7YW5kJm5ic3A7c28mbmJzcDthc2smbmJzcDt0aGUmbmJzcDtXRyZu YnNwO3RvJm5ic3A7Y29uc2lkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+Jmd0OyZuYnNwO2RyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1w Jm5ic3A7Zm9yJm5ic3A7YWRvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+Jmd0OyZuYnNwO1dlJm5ic3A7d291bGQmbmJzcDtsaWtlJm5ic3A7NC01Jm5ic3A7cGVv cGxlJm5ic3A7dG8mbmJzcDtjb21taXQmbmJzcDt0byZuYnNwO2VkaXRpbmcmbmJzcDthbmQmbmJz cDtjb250cmlidXRpbmcmbmJzcDt0byZuYnNwO3RoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7ZG9jdW1lbnQsJm5ic3A7YW5kJm5ic3A7YSZuYnNw O3NpbWlsYXImbmJzcDtudW1iZXImbmJzcDt0byZuYnNwO2NvbW1pdCZuYnNwO3RvJm5ic3A7cmV2 aWV3aW5nJm5ic3A7aXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jmd0 OyZuYnNwO1RoZSZuYnNwO2RyYWZ0Jm5ic3A7aXMmbmJzcDthdmFpbGFibGUmbmJzcDtoZXJlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteW91LW9wc2F3Zy1jYXB3 YXAtc2VwYXJhdGlvbi1mb3ItbXAvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcC88L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jmd0OyZuYnNwO1BsZWFzZSZuYnNwO3JldmlldyZu YnNwO3RoaXMmbmJzcDtkcmFmdCZuYnNwO3RvJm5ic3A7c2VlJm5ic3A7aWYmbmJzcDt5b3UmbmJz cDt0aGluayZuYnNwO2l0Jm5ic3A7aXMmbmJzcDtzdWl0YWJsZSZuYnNwO2ZvciZuYnNwO2Fkb3B0 aW9uJm5ic3A7YnkmbmJzcDtPcHNBV0csPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPiZndDsmbmJzcDthbmQmbmJzcDtjb21tZW50cyZuYnNwO3RvJm5ic3A7dGhlJm5i c3A7bGlzdCwmbmJzcDtjbGVhcmx5Jm5ic3A7c3RhdGluZyZuYnNwO3lvdXImbmJzcDt2aWV3Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDtQbGVhc2UmbmJz cDthbHNvJm5ic3A7aW5kaWNhdGUmbmJzcDtpZiZuYnNwO3lvdSZuYnNwO2FyZSZuYnNwO3dpbGxp bmcmbmJzcDt0byZuYnNwO2NvbnRyaWJ1dGUmbmJzcDt0ZXh0LCZuYnNwO3JldmlldywmbmJzcDtl dGMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jmd0OyZuYnNwO1RoaXMm bmJzcDtjYWxsJm5ic3A7Zm9yJm5ic3A7YWRvcHRpb24mbmJzcDtlbmRzJm5ic3A7VGh1Jm5ic3A7 MDktSnVsLTIwMTUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZn dDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jmd0OyZu YnNwO0luJm5ic3A7YWRkaXRpb24sJm5ic3A7dG8mbmJzcDtzYXRpc2Z5Jm5ic3A7UkZDJm5ic3A7 NjcwMiZuYnNwOygmcXVvdDtQcm9tb3RpbmcmbmJzcDtDb21wbGlhbmNlJm5ic3A7d2l0aCZuYnNw O0ludGVsbGVjdHVhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4m Z3Q7Jm5ic3A7UHJvcGVydHkmbmJzcDtSaWdodHMmbmJzcDsoSVBSKSZxdW90Oyk6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDtJZiZuYnNwO3lvdSZu YnNwO2FyZSZuYnNwO3BlcnNvbmFsbHkmbmJzcDthd2FyZSZuYnNwO29mJm5ic3A7YW55Jm5ic3A7 SVBSJm5ic3A7dGhhdCZuYnNwO2FwcGxpZXMmbmJzcDt0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7ZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2Vw YXJhdGlvbi1mb3ItbXAsJm5ic3A7aGFzJm5ic3A7dGhpcyZuYnNwO0lQUiZuYnNwO2JlZW4mbmJz cDtkaXNjbG9zZWQmbmJzcDtpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj4mZ3Q7Jm5ic3A7Y29tcGxpYW5jZSZuYnNwO3dpdGgmbmJzcDtJRVRGJm5ic3A7SVBSJm5i c3A7cnVsZXM/Jm5ic3A7KFNlZSZuYnNwO1JGQ3MmbmJzcDszOTc5LCZuYnNwOzQ4NzksJm5ic3A7 MzY2OSwmbmJzcDthbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ Jmd0OyZuYnNwOzUzNzgmbmJzcDtmb3ImbmJzcDttb3JlJm5ic3A7ZGV0YWlscy4pPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7V2FycmVuJm5ic3A7S3VtYXJp PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsoYXMm bmJzcDtPcHNBV0cmbmJzcDtXRyZuYnNwO2NvLWNoYWlyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+Jmd0OyZuYnNwOy0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPiZndDsmbmJzcDtJJm5ic3A7ZG9uJ3QmbmJzcDt0aGluayZuYnNwO3RoZSZuYnNw O2V4ZWN1dGlvbiZuYnNwO2lzJm5ic3A7cmVsZXZhbnQmbmJzcDt3aGVuJm5ic3A7aXQmbmJzcDt3 YXMmbmJzcDtvYnZpb3VzbHkmbmJzcDthJm5ic3A7YmFkJm5ic3A7aWRlYSZuYnNwO2luJm5ic3A7 dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZndDsmbmJzcDtm aXJzdCZuYnNwO3BsYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij4mZ3Q7Jm5ic3A7VGhpcyZuYnNwO2lzJm5ic3A7bGlrZSZuYnNwO3B1dHRpbmcmbmJzcDtyYWJp ZCZuYnNwO3dlYXNlbHMmbmJzcDtpbiZuYnNwO3lvdXImbmJzcDtwYW50cywmbmJzcDthbmQmbmJz cDtsYXRlciZuYnNwO2V4cHJlc3NpbmcmbmJzcDtyZWdyZXQmbmJzcDthdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7aGF2aW5nJm5ic3A7Y2hvc2Vu Jm5ic3A7dGhvc2UmbmJzcDtwYXJ0aWN1bGFyJm5ic3A7cmFiaWQmbmJzcDt3ZWFzZWxzJm5ic3A7 YW5kJm5ic3A7dGhhdCZuYnNwO3BhaXImbmJzcDtvZiZuYnNwO3BhbnRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 LS0tbWFmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjow Y207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPk9QU0FXRyZuYnNwO21haWxpbmcmbmJzcDtsaXN0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpP UFNBV0dAaWV0Zi5vcmciPk9QU0FXR0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vcHNhd2ciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b3BzYXdnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D408889639FC5E4FADB4E00A3E01FA8F8387EE73nkgeml503mbxchi_-- From nobody Sun Jun 28 20:26: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 B81281B3151 for ; Sun, 28 Jun 2015 20:26:24 -0700 (PDT) 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 RyHlid0BNFVa for ; Sun, 28 Jun 2015 20:26:23 -0700 (PDT) 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 B553A1A907A for ; Sun, 28 Jun 2015 20:26:21 -0700 (PDT) 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 BUM14596; Mon, 29 Jun 2015 03:26:20 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 04:26:19 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.89]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 11:26:12 +0800 From: "Songhaibin (A)" To: Warren Kumari , "opsawg@ietf.org" , "draft-you-opsawg-capwap-separation-for-mp@tools.ietf.org" Thread-Topic: Call for Adoption: draft-you-opsawg-capwap-separation-for-mp Thread-Index: AQHQr0egtAxM9zPPuUaAPXxbWa71kJ3C19CQ Date: Mon, 29 Jun 2015 03:26:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] Call for Adoption: draft-you-opsawg-capwap-separation-for-mp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 29 Jun 2015 03:26:24 -0000 QXMgYSBjby1hdXRob3IsIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlz IGRyYWZ0LiBJIGFsc28gc3VwcG9ydCB0aGUgYWRvcHRpb24uDQoNCkJlc3QgUmVnYXJkcyENCi1I YWliaW4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdhcnJlbiBL dW1hcmkgW21haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldF0NCj4gU2VudDogVGh1cnNkYXksIEp1bmUg MjUsIDIwMTUgOTowNSBQTQ0KPiBUbzogb3BzYXdnQGlldGYub3JnOw0KPiBkcmFmdC15b3Utb3Bz YXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcEB0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBD YWxsIGZvciBBZG9wdGlvbjogZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3It bXANCj4gDQo+IERlYXIgT3BzQVdHIFdHLA0KPiANCj4gVGhlIGF1dGhvcnMgb2YgZHJhZnQteW91 LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAgaGF2ZSBhc2tlZCBmb3IgdGhpcw0KPiBk cmFmdCB0byBiZSBjb25zaWRlcmVkIGZvciBPcHNBV0cgYWRvcHRpb24uIEl0IHdhcyBwcmVzZW50 ZWQgYW5kIGRpc2N1c3NlZA0KPiBzb21ld2hhdCBhdCBJRVRGOTEgaW4gRGFsbGFzIC0gdGhlcmUg d2FzIGEgcXVlc3Rpb24gcmFpc2VkIGFib3V0IHNpbWlsYXJpdGllcyAvDQo+IG92ZXJsYXAgd2l0 aCBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0LXR1bm5lbCAod2hpY2ggbGllcyB3aXRoIHRo ZSBJRVNHKS4NCj4gQWZ0ZXIgc29tZSBkaXNjdXNzaW9ucyB3ZSBoYXZlIGRlY2lkZWQgdGhhdCB0 aGVzZSBkb2N1bWVudHMgY29tcGxlbWVudA0KPiBlYWNoIG90aGVyLCBhbmQgc28gYXNrIHRoZSBX RyB0byBjb25zaWRlcg0KPiBkcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1t cCBmb3IgYWRvcHRpb24uDQo+IA0KPiBXZSB3b3VsZCBsaWtlIDQtNSBwZW9wbGUgdG8gY29tbWl0 IHRvIGVkaXRpbmcgYW5kIGNvbnRyaWJ1dGluZyB0byB0aGUNCj4gZG9jdW1lbnQsIGFuZCBhIHNp bWlsYXIgbnVtYmVyIHRvIGNvbW1pdCB0byByZXZpZXdpbmcgaXQuDQo+IA0KPiBUaGUgZHJhZnQg aXMgYXZhaWxhYmxlIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLw0KPiANCj4gUGxlYXNlIHJl dmlldyB0aGlzIGRyYWZ0IHRvIHNlZSBpZiB5b3UgdGhpbmsgaXQgaXMgc3VpdGFibGUgZm9yIGFk b3B0aW9uIGJ5IE9wc0FXRywNCj4gYW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBjbGVhcmx5IHN0 YXRpbmcgeW91ciB2aWV3Lg0KPiANCj4gUGxlYXNlIGFsc28gaW5kaWNhdGUgaWYgeW91IGFyZSB3 aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdGV4dCwgcmV2aWV3LCBldGMuDQo+IA0KPiBUaGlzIGNhbGwg Zm9yIGFkb3B0aW9uIGVuZHMgVGh1IDA5LUp1bC0yMDE1Lg0KPiANCj4gSW4gYWRkaXRpb24sIHRv IHNhdGlzZnkgUkZDIDY3MDIgKCJQcm9tb3RpbmcgQ29tcGxpYW5jZSB3aXRoIEludGVsbGVjdHVh bA0KPiBQcm9wZXJ0eSBSaWdodHMgKElQUikiKToNCj4gSWYgeW91IGFyZSBwZXJzb25hbGx5IGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvDQo+IGRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2Fw LXNlcGFyYXRpb24tZm9yLW1wLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4NCj4gY29t cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPyAoU2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSwg YW5kDQo+IDUzNzggZm9yIG1vcmUgZGV0YWlscy4pDQo+IA0KPiANCj4gVGhhbmtzLA0KPiBXYXJy ZW4gS3VtYXJpDQo+IChhcyBPcHNBV0cgV0cgY28tY2hhaXIpDQo+IA0KPiANCj4gLS0NCj4gSSBk b24ndCB0aGluayB0aGUgZXhlY3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlvdXNs eSBhIGJhZCBpZGVhIGluIHRoZQ0KPiBmaXJzdCBwbGFjZS4NCj4gVGhpcyBpcyBsaWtlIHB1dHRp bmcgcmFiaWQgd2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdy ZXQgYXQNCj4gaGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5k IHRoYXQgcGFpciBvZiBwYW50cy4NCj4gICAgLS0tbWFmDQo= From nobody Mon Jun 29 08:36: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 EC99B1ACE1B for ; Mon, 29 Jun 2015 08:36:32 -0700 (PDT) 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 JXxJodyWGiN9 for ; Mon, 29 Jun 2015 08:36:27 -0700 (PDT) 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 EF03C1ACE18 for ; Mon, 29 Jun 2015 08:36:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUM93404; Mon, 29 Jun 2015 15:36:24 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 16:36:23 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 08:36:13 -0700 From: Linda Dunbar To: Youjianjie , Warren Kumari , "opsawg@ietf.org" , "draft-you-opsawg-capwap-separation-for-mp@tools.ietf.org" Thread-Topic: Call for Adoption: draft-you-opsawg-capwap-separation-for-mp Thread-Index: AQHQr0efEWPZ9Uxu3U2T5y5F2FTbCJ2/lniwgAQNi6A= Date: Mon, 29 Jun 2015 15:36:12 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C85376@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.110] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] Call for Adoption: draft-you-opsawg-capwap-separation-for-mp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 29 Jun 2015 15:36:33 -0000 U3VwcG9ydCwgDQoNCkxpbmRhIER1bmJhcg0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g 5Y+R5Lu25Lq6OiBXYXJyZW4gS3VtYXJpIFttYWlsdG86d2FycmVuQGt1bWFyaS5uZXRdDQo+IOWP kemAgeaXtumXtDogMjAxNeW5tDbmnIgyNeaXpSAyMTowNQ0KPiDmlLbku7bkuro6IG9wc2F3Z0Bp ZXRmLm9yZzsNCj4gZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXBAdG9v bHMuaWV0Zi5vcmcNCj4g5Li76aKYOiBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQteW91LW9wc2F3 Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXANCj4gDQo+IERlYXIgT3BzQVdHIFdHLA0KPiANCj4g VGhlIGF1dGhvcnMgb2YgZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAg aGF2ZSBhc2tlZCANCj4gZm9yIHRoaXMgZHJhZnQgdG8gYmUgY29uc2lkZXJlZCBmb3IgT3BzQVdH IGFkb3B0aW9uLiBJdCB3YXMgcHJlc2VudGVkIA0KPiBhbmQgZGlzY3Vzc2VkIHNvbWV3aGF0IGF0 IElFVEY5MSBpbiBEYWxsYXMgLSB0aGVyZSB3YXMgYSBxdWVzdGlvbiANCj4gcmFpc2VkIGFib3V0 IHNpbWlsYXJpdGllcyAvIG92ZXJsYXAgd2l0aCBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0 LXR1bm5lbCAod2hpY2ggbGllcyB3aXRoIHRoZSBJRVNHKS4NCj4gQWZ0ZXIgc29tZSBkaXNjdXNz aW9ucyB3ZSBoYXZlIGRlY2lkZWQgdGhhdCB0aGVzZSBkb2N1bWVudHMgY29tcGxlbWVudCANCj4g ZWFjaCBvdGhlciwgYW5kIHNvIGFzayB0aGUgV0cgdG8gY29uc2lkZXIgDQo+IGRyYWZ0LXlvdS1v cHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wIGZvciBhZG9wdGlvbi4NCj4gDQo+IFdlIHdv dWxkIGxpa2UgNC01IHBlb3BsZSB0byBjb21taXQgdG8gZWRpdGluZyBhbmQgY29udHJpYnV0aW5n IHRvIHRoZSANCj4gZG9jdW1lbnQsIGFuZCBhIHNpbWlsYXIgbnVtYmVyIHRvIGNvbW1pdCB0byBy ZXZpZXdpbmcgaXQuDQo+IA0KPiBUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGhlcmU6DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFy YXRpb24tZm8NCj4gci1tcC8NCj4gDQo+IFBsZWFzZSByZXZpZXcgdGhpcyBkcmFmdCB0byBzZWUg aWYgeW91IHRoaW5rIGl0IGlzIHN1aXRhYmxlIGZvciANCj4gYWRvcHRpb24gYnkgT3BzQVdHLCBh bmQgY29tbWVudHMgdG8gdGhlIGxpc3QsIGNsZWFybHkgc3RhdGluZyB5b3VyIHZpZXcuDQo+IA0K PiBQbGVhc2UgYWxzbyBpbmRpY2F0ZSBpZiB5b3UgYXJlIHdpbGxpbmcgdG8gY29udHJpYnV0ZSB0 ZXh0LCByZXZpZXcsIGV0Yy4NCj4gDQo+IFRoaXMgY2FsbCBmb3IgYWRvcHRpb24gZW5kcyBUaHUg MDktSnVsLTIwMTUuDQo+IA0KPiBJbiBhZGRpdGlvbiwgdG8gc2F0aXNmeSBSRkMgNjcwMiAoIlBy b21vdGluZyBDb21wbGlhbmNlIHdpdGggDQo+IEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMg KElQUikiKToNCj4gSWYgeW91IGFyZSBwZXJzb25hbGx5IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBh cHBsaWVzIHRvIA0KPiBkcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcCwg aGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIA0KPiBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJ UFIgcnVsZXM/IChTZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5LCBhbmQNCj4gNTM3OCBmb3IgbW9y ZSBkZXRhaWxzLikNCj4gDQo+IA0KPiBUaGFua3MsDQo+IFdhcnJlbiBLdW1hcmkNCj4gKGFzIE9w c0FXRyBXRyBjby1jaGFpcikNCj4gDQo+IA0KPiAtLQ0KPiBJIGRvbid0IHRoaW5rIHRoZSBleGVj dXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFkIA0KPiBpZGVhIGlu IHRoZSBmaXJzdCBwbGFjZS4NCj4gVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2VscyBp biB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyANCj4gcmVncmV0IGF0IGhhdmluZyBj aG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFuZCB0aGF0IHBhaXIgb2YgcGFu dHMuDQo+ICAgIC0tLW1hZg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg== From nobody Tue Jun 30 08:43: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 08AB81ACCFD; Tue, 30 Jun 2015 08:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 87W_7bxnkEkk; Tue, 30 Jun 2015 08:43:29 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2321ACD0D; Tue, 30 Jun 2015 08:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28053; q=dns/txt; s=iport; t=1435678997; x=1436888597; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Cw9TJIssV0Sw+Q6lu5uDnKH7XSOqCjgy5fGr0irA62w=; b=kQTur9TMIqoEihkh+znu5SML8WGLfE7ma/R+qiL8belrt6hO/yRasPQa j6CBwo/tTKfuHCahZYW095MxSI8+2ztD1bPKZSbJRYCNp0NvRNOtGs8c/ GS7bytJacWFq/U+yqKbBn2cm3dkqf/8/lsjBAnq45TM31R3ih83KKSn60 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqBACpuJJV/xbLJq1bgkWBIF+DHrwUhXgCghkBAQEBAQGBC4QjAQEEHQYKSwEQCyEWAQEJAgIJAwIBAgFFBg0IAQGIKw2wepZyAQEBAQEBAQEBAQEBAQEBAQEBAQEYi0qFBgeCaIFDAQSUB4Rahn2BOkSDToJriAOIAyZjgxk8MYJIAQEB X-IronPort-AV: E=Sophos;i="5.15,378,1432598400"; d="scan'208,217";a="545339797" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 30 Jun 2015 15:43:13 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t5UFhDCo016138; Tue, 30 Jun 2015 15:43:13 GMT To: "ops-area@ietf.org" References: <557ADB1C.7070608@cisco.com> From: Benoit Claise Message-ID: <5592B911.8000202@cisco.com> Date: Tue, 30 Jun 2015 17:43:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <557ADB1C.7070608@cisco.com> Content-Type: multipart/alternative; boundary="------------020509040601090000010307" Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] [OPSAWG and OPSAREA] Call for agenda items for Prague. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 30 Jun 2015 15:43:31 -0000 This is a multi-part message in MIME format. --------------020509040601090000010307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is the agenda so far. -TACACS+: draft-dahm-opsawg-tacacs-00 (OPSAWG, duration to be confirmed) -YANG Model Coordination Group Update (Benoit, 15 min): -DNSOP activities (Joel, 10 min) Any other requests? Regards, Benoit > Forwarding Warren's message. > > Regards, Benoit > > =============================== > > Hi all, > > We have requested a slot for the joint OpsAWG / OpsArea meeting in > Prague. > > Please send over requests for agenda time. > > Please remember that we give time to drafts that have already received > significant discussion on list. > > W > --------------020509040601090000010307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dear all,

Here is the agenda so far.
-  TACACS+: draft-dahm-opsawg-tacacs-00 (OPSAWG, duration to be confirmed)
-   YANG Model Coordination Group Update (Benoit, 15 min):
-  DNSOP activities (Joel, 10 min)

Any other requests?

Regards, Benoit
Forwarding Warren's message.

Regards, Benoit

===============================

Hi all,

We have requested a slot for the joint OpsAWG / OpsArea meeting in Prague.

Please send over requests for agenda time.

Please remember that we give time to drafts that have already received
significant discussion on list.

W


--------------020509040601090000010307-- From nobody Tue Jun 30 10:58: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 8B2111B2A15 for ; Tue, 30 Jun 2015 10:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_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 Yhx1QBBazn_a for ; Tue, 30 Jun 2015 10:58:27 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69981B2A3F for ; Tue, 30 Jun 2015 10:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2281; q=dns/txt; s=iport; t=1435687106; x=1436896706; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=o6rrEGKrDLORvR5V76fgd2sfog/UphW0PRl2nOVaFT4=; b=Vckz6Kl07Qa4+14F67qiF7fZl//CqZxLZ3KcluJb2pps9dVP08NPDI41 Gb9TjTYZ2G9xmfyhY6IJ+zKZdil7Ur3jX14TBHCeFvNTTtPgLBxOKrG2F 9REC7mec0hTz0+cnQCFxL8LTEeP9d9xAY0+wmbmg/9w++Vkb3sA5euQMg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnAwCJ15JV/49dJa1bgxFUXwa9PQmBYQyFLEoCgVE4FAEBAQEBAQGBCoQjAQEEAQEBGh00GwIBCDYQJwslAgQBEogvDch9AQEBAQEBAQEBAQEBAQEBAQEBARUEi0qFDYQrBZQHAYRZhn2BOoQSjxSDXSZjgxdvgUaBAgEBAQ X-IronPort-AV: E=Sophos;i="5.15,379,1432598400"; d="scan'208";a="164039965" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 30 Jun 2015 17:58:25 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5UHwP6t017524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 17:58:25 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.112]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 12:58:25 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Warren Kumari , "opsawg@ietf.org" , "draft-you-opsawg-capwap-separation-for-mp@tools.ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-you-opsawg-capwap-separation-for-mp Thread-Index: AQHQs15cn4GoW9ZoY02aiB6rXkhd7w== Date: Tue, 30 Jun 2015 17:58:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.154.200.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <36723E7C495486429AF7A471420B6BCB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] Call for Adoption: draft-you-opsawg-capwap-separation-for-mp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 30 Jun 2015 17:58:28 -0000 Hello Warren I am happy to review. Also, being the lead author for the other draft mentioned here (draft-ietf-opsawg-capwap-alt-tunnel) I wanted to highlight that the draft needs to be progressed. We would like to progress that draft. Specifically, can I request a WG last call. Thanks Rajesh On 6/25/15, 6:04 AM, "OPSAWG on behalf of Warren Kumari" wrote: >Dear OpsAWG WG, > >The authors of draft-you-opsawg-capwap-separation-for-mp have asked >for this draft to be considered for OpsAWG adoption. It was presented >and discussed somewhat at IETF91 in Dallas - there was a question >raised about similarities / overlap with >draft-ietf-opsawg-capwap-alt-tunnel (which lies with the IESG). After >some discussions we have decided that these documents complement each >other, and so ask the WG to consider >draft-you-opsawg-capwap-separation-for-mp for adoption. > >We would like 4-5 people to commit to editing and contributing to the >document, and a similar number to commit to reviewing it. > >The draft is available here: >https://datatracker.ietf.org/doc/draft-you-opsawg-capwap-separation-for-mp >/ > >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 Thu 09-Jul-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-you-opsawg-capwap-separation-for-mp, 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) > > >--=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 > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg