From nobody Mon Dec 1 02:54:56 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151261A1B35 for ; Mon, 1 Dec 2014 02:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3SxDOWZtQs1 for ; Mon, 1 Dec 2014 02:54:52 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::712]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767931A1B2C for ; Mon, 1 Dec 2014 02:54:52 -0800 (PST) Received: from pc6 (86.184.62.161) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 1 Dec 2014 10:54:28 +0000 Message-ID: <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> From: t.petch To: "Zhangdacheng (Dacheng)" , "Hedanping (Ana)" , References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> Date: Mon, 1 Dec 2014 10:31:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.62.161] X-ClientProxiedBy: AM3PR03CA016.eurprd03.prod.outlook.com (10.141.191.144) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(7)(6); SRVR:DBXPR07MB061; X-Forefront-PRVS: 0412A98A59 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(189002)(199003)(377424004)(377454003)(61296003)(105586002)(104166001)(46102003)(42186005)(50466002)(2420400002)(62966003)(77156002)(102836001)(551544002)(106356001)(20776003)(47776003)(97736003)(64706001)(66066001)(15202345003)(107046002)(95666004)(77096004)(62236002)(101416001)(23756003)(44716002)(19580395003)(19580405001)(230783001)(116806002)(21056001)(14496001)(92566001)(122386002)(1556002)(87286001)(88136002)(92726001)(40100003)(33646002)(87976001)(84392001)(1720100001)(81816999)(76176999)(31966008)(81686999)(86362001)(93916002)(89996001)(50986999)(120916001)(15975445006)(99396003)(50226001)(4396001)(44736004)(1456002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/eazpOKo-AoTZoVF0gq8-gp9uPts Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 10:54:55 -0000 ----- Original Message ----- From: "Zhangdacheng (Dacheng)" To: "Hedanping (Ana)" ; Cc: Sent: Saturday, November 29, 2014 3:59 AM > Let me help clarify Danping's point. > > We found there was a problem in the localization algorithm, but we are not sure whether this issue is worthwhile for us to address, or the effort of addressing this issue is out of scope of the SNMP specification. So, we raise this question here, and hope to get comments or suggestions. The new algorithm that you propose seems to offer very little improvement. You suggest that after replicating the password, you then add the password length in the last four octets to bring the length up to 64 octet. This seems to add very little entropy. Also, an 8 character string, containing upper case, lower case, digit and extended punctuation would have been regarded as too weak many years ago and we should not be documenting such an approach now. Again, anyone who uses a password based system and does not have a extra module to ensure that passwords meet current standards deserves all the security breaches they get! Tom Petch > > Cheers > > Dacheng > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Hedanping > > (Ana) > > Sent: Saturday, November 29, 2014 10:52 AM > > To: opsawg@ietf.org > > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > > Subject: [OPSAWG] FW: New Version Notification for > > draft-du-opsawg-snmp-key-localization-00.txt > > > > Dear all, > > We find a security problem in the current SNMP key localization algorithm, but > > we are not sure whether IETF is the right place to improve it. The draft is > > submitted and comments are appreciated. > > > > A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt > > has been successfully submitted by Danping He and posted to the IETF > > repository. > > > > Name: draft-du-opsawg-snmp-key-localization > > Revision: 00 > > Title: A New Algorithm for SNMP Key Localization > > Document date: 2014-11-28 > > Group: Individual Submission > > Pages: 4 > > URL: > > http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localizatio n-00. > > txt > > Status: > > https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localization/ > > Htmlized: > > http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 > > > > > > Abstract: > > This draft discusses a security issue with the algorithm for > > generating SNMP localized keys and introduce a new algorithm to > > address this problem. > > > > > > Regards, > > Ana (Danping) From nobody Mon Dec 1 07:38:00 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6681A1EFF for ; Mon, 1 Dec 2014 07:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RZ8yhham_mF for ; Mon, 1 Dec 2014 07:37:48 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FFC1A1F73 for ; Mon, 1 Dec 2014 07:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20997; q=dns/txt; s=iport; t=1417448268; x=1418657868; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=4d+l3Bo1bek86Kthyx/u4V4Tm8VZiJ7N5zmXCmS3JV0=; b=BBajNAiOESYZ5x8TeKoh4AmLiqukXoLq1p4B119cKeX2SXQ8jNfwz/8H VXbluKyklcB72XnOhCnIs5QxDfSaiy0OMaOhE+F6gqYzytg4wVchNV/s6 sXX/+XaEYAudFpRih6WX8GrtFByEgu/hmh6jplH/5xI299FVCXMO9RoMc 4=; X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208,217";a="256749113" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 01 Dec 2014 15:37:46 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB1Fbh7i012527; Mon, 1 Dec 2014 15:37:44 GMT Message-ID: <547C8B47.8000809@cisco.com> Date: Mon, 01 Dec 2014 16:37:43 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Rajesh Pazhyannur (rpazhyan)" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" References: <546CF473.70201@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030405010100020503030405" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/P2bRcN5AyZySbA5Uo3n7Hh4CZhk Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 15:37:54 -0000 This is a multi-part message in MIME format. --------------030405010100020503030405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Rajesh, I'm concerned that: - draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution - draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from draft-xue-opsawg-capwap-alt-tunnel-information, an individual draft. - draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different tunnel types, and required expertise from many different group. This might take some time... Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel with the information elements for CAPWAP (not the others one). This way, this draft would be a complete solution. And if people wants alternate tunnel types, this would be done in draft-xue-opsawg-capwap-alt-tunnel-information Regards, Benoit/ // / > Hello > > I realized there was a typographical error in my response below. > Please see corrections. > > Regards > > Rajesh > From: Rajesh Pazhyannur > > Date: Thursday, November 20, 2014 at 12:30 AM > To: "Benoit Claise (bclaise)" >, > "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org > " >, > "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org > " > > > Cc: "opsawg@ietf.org " > > Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and > draft-xue-opsawg-capwap-alt-tunnel-information relationship > > Hi Benoit > > But now I wonder: why do we have two different drafts, as opposed to a > single one? > > This is a good question. > > [*original*] Yes, you are correct that > draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete > solution and needs something like > *draft-ietf-opsawg-capwap-alt-tunnel* to complete the solution. > [corrected statement] Y/es, you are correct that > draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete > solution and needs something like > *draft-xue-opsawg-capwap-alt-tunnel-information* to complete the > solution. / > > The best answer I have is that we wanted the keep the following two > areas separate (and in different drafts) > > 1. Discover and negotiation of alternate tunneling capability. These > are independent of specific alternate tunnel method > 2. [*original*] Definition of tunnel specific message elements. While > draft-ietf-opsawg-capwap-alt-tunnel contains message elements for > most of the tunneling methods defined in > *draft-ietf-opsawg-capwap-alt-tunnel*, I had anticipated separate > drafts for each tunneling protocol. > > /[corrected] 2 Definition of tunnel specific message elements. While > draft-ietf-opsawg-capwap-alt-tunnel contains message elements for most > of the tunneling methods defined in > *draft-xue-opsawg-capwap-alt-tunnel-information* I had anticipated > separate drafts for each tunneling protocol./ > > Finishing 1. would allow 2. to be completed separately and > independently in potentially different drafts (and potentially > different groups with relevant expertise). It is somewhat akin (though > not identical) to separation between RFC 5415 and RFC 5416 where RFC > 5415 is wireless technology independent and RFC 5416 is 802.11 specific. > > Hope the above makes sense. > > Regards > > Rajesh > From: "Benoit Claise (bclaise)" > > Date: Wednesday, November 19, 2014 at 11:50 AM > To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org > " >, > "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org > " > > > Cc: "opsawg@ietf.org " > > Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and > draft-xue-opsawg-capwap-alt-tunnel-information relationship > > Dear CAPWAP authors, > > After the draft-xue-opsawg-capwap-alt-tunnel-information presentation > at the last IETF meeting, I've been wondering about the relationship > between the two drafts: > - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types > Note:this draft is currently in AD review, so close to be sent to > the IESG. > - draft-xue-opsawg-capwap-alt-tunnel-information provides the encoding > of the tunnel-specific fields. > > I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel > doesn't provide a complete solution without > draft-xue-opsawg-capwap-alt-tunnel-information? > > I'm aware of the changes between version 3 and 4 (attached picture and > http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-04.txt) > > But now I wonder: why do we have two different drafts, as opposed to a > single one? > > Regards, Benoit > > --------------030405010100020503030405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Rajesh,

I'm concerned that:
- draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution
- draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from draft-xue-opsawg-capwap-alt-tunnel-information, an individual draft.
- draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different tunnel types, and required expertise from many different group. This might take some time...

Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel with the information elements for CAPWAP (not the others one). This way, this draft would be a complete solution.
And if people wants alternate tunnel types, this would be done in draft-xue-opsawg-capwap-alt-tunnel-information

Regards, Benoit

Hello

I realized there was a typographical error in my response below. 
Please see corrections.  

Regards

Rajesh
From: Rajesh Pazhyannur <rpazhyan@cisco.com>
Date: Thursday, November 20, 2014 at 12:30 AM
To: "Benoit Claise (bclaise)" <bclaise@cisco.com>, "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" <draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" <draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship

Hi Benoit

But now I wonder: why do we have two different drafts, as opposed to a single one?

This is a good question.  

[original] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution and needs something like  draft-ietf-opsawg-capwap-alt-tunnel to complete the solution. 
[corrected statement] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution and needs something like  draft-xue-opsawg-capwap-alt-tunnel-information to complete the solution. 

The best answer I have is  that we wanted the keep the following two areas separate (and in different drafts) 
  1. Discover and negotiation of alternate tunneling capability. These are  independent of specific alternate tunnel method 
  2. [original] Definition of tunnel specific message elements. While draft-ietf-opsawg-capwap-alt-tunnel contains message elements for most of the tunneling methods defined in  draft-ietf-opsawg-capwap-alt-tunnel, I had anticipated separate drafts for each tunneling protocol.
[corrected] 2 Definition of tunnel specific message elements. While draft-ietf-opsawg-capwap-alt-tunnel contains message elements for most of the tunneling methods defined in  draft-xue-opsawg-capwap-alt-tunnel-information I had anticipated separate drafts for each tunneling protocol.

Finishing 1. would allow 2. to be completed separately and independently in potentially different drafts (and potentially different groups with relevant expertise). It is somewhat akin (though not identical) to separation between RFC 5415 and RFC 5416 where RFC 5415 is wireless technology independent and RFC 5416 is 802.11 specific.  

Hope the above  makes sense. 

Regards

Rajesh
From: "Benoit Claise (bclaise)" <bclaise@cisco.com>
Date: Wednesday, November 19, 2014 at 11:50 AM
To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" <draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" <draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship

Dear CAPWAP authors,

After the draft-xue-opsawg-capwap-alt-tunnel-information presentation at the last IETF meeting, I've been wondering about the relationship between the two drafts:
- draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types
  Note:this draft is currently in AD review, so close to be sent to the IESG.
- draft-xue-opsawg-capwap-alt-tunnel-information provides the encoding of the tunnel-specific fields.

I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel doesn't provide a complete solution without draft-xue-opsawg-capwap-alt-tunnel-information?

I'm aware of the changes between version 3 and 4 (attached picture and http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-04.txt)

But now I wonder: why do we have two different drafts, as opposed to a single one?

Regards, Benoit

--------------030405010100020503030405-- From nobody Mon Dec 1 11:30:31 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB3C1A8A1E for ; Mon, 1 Dec 2014 11:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYZt7RI0DLpW; Mon, 1 Dec 2014 11:30:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A3B1A8A17; Mon, 1 Dec 2014 11:30:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, warren@kumari.net, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141201193012.26778.21285.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 11:30:12 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/K2Y-pDZrk5l7E4Np0XbqZ0TI3g0 Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 19:30:26 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ From nobody Mon Dec 1 14:26:01 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17631AC528 for ; Mon, 1 Dec 2014 14:25:59 -0800 (PST) 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 3CmCEH63h53c for ; Mon, 1 Dec 2014 14:25:58 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id D49171A1A96 for ; Mon, 1 Dec 2014 14:25:57 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id sB1MPu66005181; Mon, 1 Dec 2014 17:25:56 -0500 From: "Blumenthal, Uri - 0558 - MITLL" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt Thread-Index: AQHQDbXGNWdSKnFCiESQx2CAsX+ohg== Date: Mon, 1 Dec 2014 22:25:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [172.25.177.187] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-01_05:2014-12-01,2014-12-01,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-1412010213 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/YqOCBUHsx8B19t7DuBQnhqDpESs Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 22:26:00 -0000 Pj5XZSBmb3VuZCB0aGVyZSB3YXMgYSBwcm9ibGVtIGluIHRoZSBsb2NhbGl6YXRpb24gYWxnb3Jp dGhtDQoNCkZpcnN0IG9mIGFsbCwgSSBkb27igJl0IHRoaW5rIHRoZSBhYm92ZSBpcyBhIGNvcnJl Y3Qgc3RhdGVtZW50Lg0KDQpUaGVyZSBpcyBubyAqcHJvYmxlbSogaW4gdGhlIGFsZ29yaXRobSwg YnV0IGEgdXNhZ2UgY29uc3RyYWludCB0aGF0IHdhcw0KY2xlYXJseSBzdGF0ZWQgaW4gdGhlIFJG QywgYW5kIGlzIHVubGlrZWx5IHRvIG1hbmlmZXN0IGluIHRoZSByZWFsIHdvcmxkLg0KDQpUaGlz IGNvbnN0cmFpbnQgY291bGQgaGF2ZSBiZWVuIGFkZHJlc3NlZCBieSB0aGUgbWV0aG9kIHlvdSBw cm9wb3NlZCwgYW5kDQp0aGUgYWxnb3JpdGhtIHdvdWxkIGhhdmUgYmVlbiBiZXR0ZXIsIGFsYmVp dCBieSB2ZXJ5IGxpdHRsZS4gQnV0DQp1bmZvcnR1bmF0ZWx5IHlvdSB3ZXJlbuKAmXQgYXJvdW5k IHBhcnRpY2lwYXRpbmcgaW4gdGhpcyBkaXNjdXNzaW9uIGluIDIwMDIsDQphbmQgbm93IGl04oCZ cyByZWFsbHkgbGF0ZSAoc2VlIGJlbG93KS4NCg0KPj5idXQgd2UgYXJlIG5vdCBzdXJlIHdoZXRo ZXIgdGhpcyBpc3N1ZSBpcyB3b3J0aHdoaWxlIGZvciB1cyB0byBhZGRyZXNzLA0KDQpJIHRoaW5r IGl0IGRlZmluaXRlbHkgaXMgbm90IHdvcnRoIChub3Igd2lzZSkgYWRkcmVzc2luZywgYnkgY2hh bmdpbmcgdGhlDQpwcm92ZW4gYW5kIG1hdHVyZSBzdGFuZGFyZCBhdCB0aGlzIHBvaW50Lg0KDQpC ZXJ0IFdpam5lbiAobXkgY28tYXV0aG9yKSBjb25jdXJzLCBhcyBzdGF0ZWQgaW4gaGlzIGVtYWls IHRvIHRoZSBsaXN0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29wc2F3 Zy9jdXJyZW50L21zZzAzNjY4Lmh0bWwNCg0KDQo+IFRoZSBuZXcgYWxnb3JpdGhtIHRoYXQgeW91 IHByb3Bvc2Ugc2VlbXMgdG8gb2ZmZXIgdmVyeSBsaXR0bGUNCj5pbXByb3ZlbWVudC4NCg0KSSBh Z3JlZSB3aXRoIFRvbS4gSXQgY291bGQgbWFrZSBzZW5zZSBpZiB3ZSB3ZXJlIHN0YXJ0aW5nIGZy b20gc2NyYXRjaC4NCkJ1dCBmb3JjaW5nIGFsbCB0aGUgdmVuZG9ycyB0byBjaGFuZ2UgYWZ0ZXIg MTIrIHllYXJzIG9mIGRlcGxveW1lbnQgKHRoZQ0KYWxnb3JpdGhtIHdhcyBmaXJzdCBwdWJsaXNo ZWQgaW4gUkZDIDIyNjQgcHVibGlzaGVkIGluIEphbiAxOTk4KSwgYW5kIGZvcg0Kc3VjaCBhIG1l YWdlciBnYWluIC0ganVzdCBkb2VzIG5vdCBtYWtlIHNlbnNlLg0KDQo+WW91IHN1Z2dlc3QgdGhh dCBhZnRlciByZXBsaWNhdGluZyB0aGUgcGFzc3dvcmQsIHlvdSB0aGVuIGFkZCB0aGUNCj5wYXNz d29yZCBsZW5ndGggaW4gdGhlIGxhc3QgZm91ciBvY3RldHMgdG8gYnJpbmcgdGhlIGxlbmd0aCB1 cCB0byA2NA0KPm9jdGV0LiAgVGhpcyBzZWVtcyB0byBhZGQgdmVyeSBsaXR0bGUgZW50cm9weS4N Cg0KQWdhaW4sIEkgY29uY3VyIHdpdGggVG9tLiBUaGUgbnVtYmVyIG9mIGNhc2VzIHdoZXJlIHRo aXMgbW9kaWZpY2F0aW9uDQp3b3VsZCBoZWxwIGlzIHNtYWxsIHRvIG5lZ2xpZ2libGUuDQoNClRo YW5rcyENCg0KUC5TLiBJdCBjb3VsZCBtYWtlIHNlbnNlIGZvciAqbmV3KiBhbGdvcml0aG1zL3By b3RvY29scyB0aGF0IHVzZSBzaW1pbGFyDQp0ZWNobmlxdWVzIHRvIHNsb3cgdGhlIGF0dGFja2Vy IGRvd24uIEJ1dCBmb3IgbmV3IGFsZ29yaXRobXMgdGhhdCBzdGFydA0Kd2l0aCBubyBwYXN0IGJh Z2dhZ2UgdG8gY2FycnkgLSBwcm9iYWJseSBQQktERjIgb3Igc3VjaCB3b3VsZCBiZSBhIGJldHRl cg0KY2hvaWNlIGFsdG9nZXRoZXIuDQoNClAuUC5TLiBEb2VzIHlvdXIgcHJvcG9zZWQgY29kZSBy dW4gY29ycmVjdGx5IG9uIEJpZyBFbmRpYW4gKHN1Y2ggYXMNCk1vdG9yb2xhKSBhbmQgTGl0dGxl IEVuZGlhbiAoc3VjaCBhcyBJbnRlbCkgQ1BVcz8NCi0tDQpSZWdhcmRzLA0KVXJpIEJsdW1lbnRo YWwgICAgICAgICAgICAgICAgVm9pY2U6ICg3ODEpIDk4MS0xNjM4DQpDeWJlciBTeXN0ZW1zIGFu ZCBUZWNobm9sb2d5ICBGYXg6ICAgKDc4MSkgOTgxLTAxODYNCk1JVCBMaW5jb2xuIExhYm9yYXRv cnkNCjI0NCBXb29kIFN0cmVldCwgTGV4aW5ndG9uLCBNQSAgMDI0MjAtOTE4NSAgICAgIA0KDQo= From nobody Mon Dec 1 15:07:25 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A13C1A6F58 for ; Mon, 1 Dec 2014 15:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8eT6qCFp48z; Mon, 1 Dec 2014 15:07:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBD91ACD99; Mon, 1 Dec 2014 15:06:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, warren@kumari.net, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141201230651.629.49383.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 15:06:51 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/kqq8WXnxe7BUPb_JzVO9JRDOUgY Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 23:07:18 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ From nobody Tue Dec 2 02:59:13 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A231A1A95 for ; Tue, 2 Dec 2014 02:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PQQc4HSkpGt for ; Tue, 2 Dec 2014 02:59:10 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7871B1A1A93 for ; Tue, 2 Dec 2014 02:59:10 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 7B6061A008F; Tue, 2 Dec 2014 11:58:59 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ynxm8gl_k-Rb; Tue, 2 Dec 2014 11:58:50 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 62BB91A0085; Tue, 2 Dec 2014 11:58:50 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 2 Dec 2014 11:58:57 +0100 Message-ID: <547D9B71.40105@secunet.com> Date: Tue, 2 Dec 2014 11:58:57 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hedanping (Ana)" , "Zhangdacheng (Dacheng)" , "Bert Wijnen (IETF)" , "opsawg@ietf.org" References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <5479C937.7070808@bwijnen.net> <77FA386512F0D748BC7C02C36EB1106D8F4FD2@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8F4FD2@szxeml557-mbs.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/iabvKeglT5zDxN4T5Fl1_TWVlYc Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 10:59:12 -0000 Hedanping (Ana) wrote on 01.12.2014 04:51: > The security of SNMP is emerged to be enhanced . Besides customers won't check RFC before using SNMP devices, thus they are not aware of this vulnerability. Vendors have to implement extra modules to constrain user behavior, but not all the vendors do so. The current key localization algorithm is vulnerable, and the CVSS is rated as 7.6, AV:N/AC:H/Au:N/C:C/I:C/A:C. The new key localization mechanism might be bundled with SHA2 as important updates. > I think it is wise to keep the key localization algorithm in draft-hmac-sha-2-usm-snmp as it is, i.e., as specified in RFC 3414. In order to implement the new authentication algorithms, implementers just need to change the hash algorithms and the lengths of input and output values, which increases the probability of adoption. Any changes to the general processing, even in supporting algorithms like key localization, will hinder adoption and may even result in interop problems in cases where the changes have been overlooked. -- Johannes From nobody Tue Dec 2 03:02:05 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F72B1A1A98 for ; Tue, 2 Dec 2014 03:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHGkCcd-3L5d for ; Tue, 2 Dec 2014 03:02:02 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B531A1A91 for ; Tue, 2 Dec 2014 03:02:02 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 3EEE31A008F; Tue, 2 Dec 2014 12:01:53 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sh4YejEQnU3T; Tue, 2 Dec 2014 12:01:44 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id B57D31A008C; Tue, 2 Dec 2014 12:01:44 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 2 Dec 2014 12:01:51 +0100 Message-ID: <547D9C1F.5090105@secunet.com> Date: Tue, 2 Dec 2014 12:01:51 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Warren Kumari , David Reid References: <544A35BB.2070503@secunet.com> <201411241850.sAOIoVFg004859@mainfs.snmp.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/wu_Y6FGHPD5P0Ul0tu0UC-ztI2w Cc: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 11:02:03 -0000 Warren Kumari wrote on 26.11.2014 18:54: > So, dear authors, please resubmit as.. etc. ok, we will do so. Are there any further suggestion, e.g., from the authors of draft-hartman-snmp-sha2, for modifications? Now is the right time to express them. -- Johannes From nobody Tue Dec 2 06:59:00 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABC91ACE19 for ; Tue, 2 Dec 2014 06:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLvMUsDO193T; Tue, 2 Dec 2014 06:58:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DB61A1BDB; Tue, 2 Dec 2014 06:58:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, warren@kumari.net, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202145856.13409.99667.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 06:58:56 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/R7JR_CkJ4lhv7KBL_VEohyCscwM Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:58:58 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ From nobody Tue Dec 2 11:56:41 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C317C1A6FEB for ; Tue, 2 Dec 2014 11:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veaW7VJkjwYB for ; Tue, 2 Dec 2014 11:56:37 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14601A1F20 for ; Tue, 2 Dec 2014 11:56:36 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l2so17964679wgh.13 for ; Tue, 02 Dec 2014 11:56:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CkYBPli72YtNv7J2qJgAMyUUSXs6eZo1ZovgthVr3RA=; b=OEeIWp+2yLPu/j5w51n0Qns449k6C+E0qi+lxA0mcVFRTzfm6raXMBGsefMFc5UYYl fNdieB/Q869gHvGmOK2P1cZhSIZxfCDDZcYrrf3vQipI8KPVCIu0ZZpuhzG8f9P4N1Kd t0YVDTzE2MJNQwrP7qKZJ0QdQGlKhJmhu+HTH8Plz9ca16WOY7LWZTTEsq9+cOSqQAci A1ocjRRo03PhNxdP44U/hR53Tr2sublnYd6leSNHD6PV/9ub2hcG01qajxBbkM06DbYj jbetwY4jSeQ5pc7Xy6NiHk6f+mZ+R5oTLCwRLBH2Gu/+lVsNNRAgjT2UfLgoUXEnNiu6 hNDw== X-Gm-Message-State: ALoCoQlEosRmgWy8W0JmkVIAsDLUt1O9AVslzTIiHZoxLWGykALFpgLUo40qyfewYbNe4KztzK8P MIME-Version: 1.0 X-Received: by 10.181.13.179 with SMTP id ez19mr44662601wid.65.1417550195444; Tue, 02 Dec 2014 11:56:35 -0800 (PST) Received: by 10.194.64.37 with HTTP; Tue, 2 Dec 2014 11:56:35 -0800 (PST) In-Reply-To: <20141202145856.13409.99667.idtracker@ietfa.amsl.com> References: <20141202145856.13409.99667.idtracker@ietfa.amsl.com> Date: Tue, 2 Dec 2014 14:56:35 -0500 Message-ID: From: Warren Kumari To: IETF Secretariat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/e2EBLUdYFL6cXYwvK-PYpZjBvw8 Cc: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 19:56:39 -0000 A quick note to thank Tom Taylor and Dan Romascanu for taking this on and getting it done so quickly. W On Tue, Dec 2, 2014 at 9:58 AM, IETF Secretariat wrote: > IESG state changed to RFC Ed Queue from Approved-announcement sent > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Dec 2 23:59:25 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C011A00EA for ; Tue, 2 Dec 2014 23:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY9BPdFRch12 for ; Tue, 2 Dec 2014 23:59:20 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9091A00A6 for ; Tue, 2 Dec 2014 23:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25569; q=dns/txt; s=iport; t=1417593560; x=1418803160; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=qvgSvsOceK+GbdBeg5SueA9HrldFUyED/JO013+x1sw=; b=CQiwdTq2ay0B3cwjODWrAYXmrGku2JNxG92VYsXwhAYfx7VLkG97P0hq WTjm2F54rY8Iz/czmQzOufi2U7LkIpxO2NP/hHDMa3L8pbOLggks57sJz QzA4QrCevLvo9O2Sob5ZtAJaoeH/zkXeYV+ygXZrBBHSRipz2JUPR38Bb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAOLBflStJA2E/2dsb2JhbABbgkNEUlkExGaCKIYdAoESFgEBAQEBfYQCAQEBAwFrBwcFDQEIEQMBAgkYAwQtDBQJCAIEAQ0EARuIHAkN1W8BAQEBAQEBAQIBAQEBAQEBARqQXgwFBgEGhEIFjmKBf4Q+hmeBLDqCfpA9gjeBRG8BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,506,1413244800"; d="scan'208,217";a="102185932" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 03 Dec 2014 07:59:19 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB37xIJD017453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 07:59:18 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.207]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 01:59:18 -0600 From: "Sri Gundavelli (sgundave)" To: "Benoit Claise (bclaise)" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" Thread-Topic: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship Thread-Index: AQHQDs8KN0ZUZ3jGWU+ksWobl1VnqQ== Date: Wed, 3 Dec 2014 07:59:18 +0000 Message-ID: In-Reply-To: <547C8B47.8000809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.212] Content-Type: multipart/alternative; boundary="_000_D0A3FAB5181085sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/j-L-nk6lMrQYLXxH_eOH5FXFfwA Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 07:59:23 -0000 --_000_D0A3FAB5181085sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, > Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel wi= th the information elements for CAPWAP (not the others one). The above draft defines number of encapsulation modes and that list include= s, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. Each of those= tunnel types can be activated with a set of tunnel parameters. These param= eters include source IP, destination IP, sport, dport, GRE key ..etc. To mo= st part this is about identifying a common set of parameters, providing def= inition for those parameters and grouping the relevant one's for each of th= e encapsulation modes. Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), ea= ch are not radically different from the others and the above common paramet= er set is sufficient for these modes. To create a tunnel with GRE with IPv= 4 transport is not any different from GRE with IPv6 transport, or for that = matter for IP-in-IP mode. It is to be noted there are no proposed changes to any of these encapsulati= on modes, or to the control protocols activating those encap modes. Its mos= tly about activating a tunnel state with a set of parameters. If at all, C= APWAP data plane may be bit complex and even L2TP as its unclear if the con= trol protocol has semantics for the L2TP peers to separate control and data= plane. If not, it requires changes to the L2TP protocol. So, its easier to= keep CAPWAP + GRE/IP-in-IP modes in the main spec as the work has a well d= efined scope. So, my suggestion is to allow draft-ietf-opsawg-capwap-alt-tunnel to also = support GRE/IP-in-IP modes and have draft-xue focus exclusively on L2TP ext= ensions and move it on a fast track. IMO, this is a reasonably split. I'm = also happy to provide the text for the above encap modes and ensure the cha= nges do not delay the publication. Regards Sri From: "Benoit Claise (bclaise)" > Date: Monday, December 1, 2014 7:37 AM To: "Rajesh Pazhyannur (rpazhyan)" >, "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >, "draft-ietf-opsawg-cap= wap-alt-tunnel@tools.ietf.org" > Cc: "opsawg@ietf.org" > Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-ops= awg-capwap-alt-tunnel-information relationship Hi Rajesh, I'm concerned that: - draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution - draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from draft-xue-= opsawg-capwap-alt-tunnel-information, an individual draft. - draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different tunnel = types, and required expertise from many different group. This might take so= me time... Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel with= the information elements for CAPWAP (not the others one). This way, this d= raft would be a complete solution. And if people wants alternate tunnel types, this would be done in draft-xue= -opsawg-capwap-alt-tunnel-information Regards, Benoit Hello I realized there was a typographical error in my response below. Please see corrections. Regards Rajesh From: Rajesh Pazhyannur > Date: Thursday, November 20, 2014 at 12:30 AM To: "Benoit Claise (bclaise)" >= , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >, "draft-ietf-opsawg-capwap-alt= -tunnel@tools.ietf.org" > Cc: "opsawg@ietf.org" > Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-ops= awg-capwap-alt-tunnel-information relationship Hi Benoit But now I wonder: why do we have two different drafts, as opposed to a sing= le one? This is a good question. [original] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel do= es not provide a complete solution and needs something like draft-ietf-ops= awg-capwap-alt-tunnel to complete the solution. [corrected statement] Yes, you are correct that draft-ietf-opsawg-capwap-al= t-tunnel does not provide a complete solution and needs something like dra= ft-xue-opsawg-capwap-alt-tunnel-information to complete the solution. The best answer I have is that we wanted the keep the following two areas = separate (and in different drafts) 1. Discover and negotiation of alternate tunneling capability. These are= independent of specific alternate tunnel method 2. [original] Definition of tunnel specific message elements. While draf= t-ietf-opsawg-capwap-alt-tunnel contains message elements for most of the t= unneling methods defined in draft-ietf-opsawg-capwap-alt-tunnel, I had ant= icipated separate drafts for each tunneling protocol. [corrected] 2 Definition of tunnel specific message elements. While draft-i= etf-opsawg-capwap-alt-tunnel contains message elements for most of the tunn= eling methods defined in draft-xue-opsawg-capwap-alt-tunnel-information I = had anticipated separate drafts for each tunneling protocol. Finishing 1. would allow 2. to be completed separately and independently in= potentially different drafts (and potentially different groups with releva= nt expertise). It is somewhat akin (though not identical) to separation bet= ween RFC 5415 and RFC 5416 where RFC 5415 is wireless technology independen= t and RFC 5416 is 802.11 specific. Hope the above makes sense. Regards Rajesh From: "Benoit Claise (bclaise)" > Date: Wednesday, November 19, 2014 at 11:50 AM To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >, "draft-ietf-opsawg-capwap-a= lt-tunnel@tools.ietf.org" > Cc: "opsawg@ietf.org" > Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-= capwap-alt-tunnel-information relationship Dear CAPWAP authors, After the draft-xue-opsawg-capwap-alt-tunnel-information presentation at th= e last IETF meeting, I've been wondering about the relationship between the= two drafts: - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types Note:this draft is currently in AD review, so close to be sent to the IES= G. - draft-xue-opsawg-capwap-alt-tunnel-information provides the encoding of t= he tunnel-specific fields. I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel doesn't = provide a complete solution without draft-xue-opsawg-capwap-alt-tunnel-info= rmation? I'm aware of the changes between version 3 and 4 (attached picture and http= ://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-capwap-alt-tunnel-04.txt= ) [cid:part1.06060400.02040901@cisco.com] But now I wonder: why do we have two different drafts, as opposed to a sing= le one? Regards, Benoit --_000_D0A3FAB5181085sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0603BA887E6B9148B76FC9897F282666@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Benoit,

> Let me propose a solution: augment draft-ietf-opsawg-capwap-= alt-tunnel with the information elements for CAPWAP (not the others one).&n= bsp;

The above draft defines number of encapsulation modes and that list in= cludes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. Eac= h of those tunnel types can be activated with a set of tunnel parameters. T= hese parameters include source IP, destination IP, sport, dport, GRE key ..etc. To most part this is about identifying a = common set of parameters, providing definition for those parameters and gro= uping the relevant one's for each of the encapsulation modes. Taking GREv4,= GREv6, IP-in-IP or PMIP (uses GRE), each are not radically different from the others and the above common para= meter set is sufficient for these modes.  To create a tunnel with GRE = with IPv4 transport is not any different from GRE with IPv6 transport, or f= or that matter for IP-in-IP mode. 

It is to be noted there are no proposed changes to any of these encaps= ulation modes, or to the control protocols activating those encap modes. It= s mostly about activating a tunnel state with a set of parameters.  If= at all, CAPWAP data plane may be bit complex and even L2TP as its unclear if the control protocol has semantics= for the L2TP peers to separate control and data plane. If not, it requires= changes to the L2TP protocol. So, its easier to keep CAPWAP + GRE/IP-i= n-IP modes in the main spec as the work has a well defined scope.

So, my suggestion is to allow draft-ietf-opsawg-capwap-alt-tunnel=  to also support GRE/IP-in-IP modes and have draft-xue focus exclusiv= ely on L2TP extensions and move it on a fast track. IMO, this is a reasonab= ly split.  I'm also happy to provide the text for the above encap modes and ensure the changes do not delay the publicat= ion. 
 

Regards
Sri






From: "Benoit Claise (bclaise)= " <bclaise@cisco.com> Date: Monday, December 1, 2014 7:37= AM
To: "Rajesh Pazhyannur (rpazhy= an)" <rpazhyan@cisco.com&= gt;, "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.= org" <draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" <= draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org>
Cc: "opsawg@ietf.org" <= opsawg@ietf.org>
Subject: Re: [OPSAWG] draft-ietf-op= sawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information r= elationship

Hi Rajesh,

I'm concerned that:
- draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution<= br> - draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from draft-xue-= opsawg-capwap-alt-tunnel-information, an individual draft.
- draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different tunnel = types, and required expertise from many different group. This might take so= me time...

Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel with= the information elements for CAPWAP (not the others one). This way, this d= raft would be a complete solution.
And if people wants alternate tunnel types, this would be done in draft-xue= -opsawg-capwap-alt-tunnel-information

Regards, Benoit

Hello

I realized there was a typographical er= ror in my response below. 
Please see corrections.  

Regards

Rajesh

Hi Benoit

But now I wonder: why d= o we have two different drafts, as opposed to a single one?

This is a good question.  

[original] Yes, you are correct that draft-ietf-opsawg-capwap-a= lt-tunnel does not provide a complete solution and needs something like  draft-ietf-opsawg-capwap-alt-tunnel to comple= te the solution. 
[corrected statement] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution and needs something like =  draft-xue-opsawg-capwap-alt-tunne= l-information to complete the solution. 

The best answer I have is  that we wanted the keep the following two a= reas separate (and in different drafts) 
  1. Discover and negotiation of alternate tunneling capability. These are  = ;independent of specific alternate tunnel method 
  2. [= original] Definition of tunnel specific message elements. While = ;draft-ietf-opsawg-capwap-alt-tunne= l contains message elements for most of the tunneling methods defined in  draft-ietf-opsawg= -capwap-alt-tunnel, I had anticipated separate drafts for each t= unneling protocol.
[correcte= d] 2 Definition of tunnel specific message elements. While draft-ietf-opsawg-capwap-alt-tunnel conta= ins message elements for most of the tunneling methods defined in  draft-xue-opsawg-capwap-alt-tunnel-information I had anticipated separate drafts for each tunneling protocol.=

Finishing 1. would allow 2. to be com= pleted separately and independently in potentially different drafts (a= nd potentially different groups with relevant expertise). It is somewhat akin (though not identical) to separation between RFC 5415 and RFC 5416 where R= FC 5415 is wireless technology independent and RFC 5416 is 802.11 specific.=  

Hope the above  makes = sense. 

Regards

Rajesh
From: "Benoit Claise (bclaise)= " <bc= laise@cisco.com>
Date: Wednesday, November 19, 2014 = at 11:50 AM
To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org&quo= t; <draft-xue-opsawg-capwap-alt-tunnel-in= formation@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.o= rg" <draft-ietf-opsawg-capwap-alt-tunnel@to= ols.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org> Subject: [OPSAWG] draft-ietf-opsawg= -capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relat= ionship

Dear CAPWAP authors,

After the draft-xue-opsawg-capwap-alt-tunnel-information presentation at th= e last IETF meeting, I've been wondering about the relationship between the= two drafts:
- draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types
  Note:this draft is currently in AD review, so close to be sent to th= e IESG.
- draft-xue-opsawg-capwap-alt-tunnel-information provides the encoding of t= he tunnel-specific fields.

I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel doesn't = provide a complete solution without draft-xue-opsawg-capwap-alt-tunnel-info= rmation?

I'm aware of the changes between version 3 and 4 (attached picture and http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-capwap-alt-tunnel-04= .txt)
3D""
But now I wonder: why do we have two different drafts, as opposed to a sing= le one?

Regards, Benoit



 --_000_D0A3FAB5181085sgundaveciscocom_-- From nobody Wed Dec 3 02:02:57 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC001A1A10 for ; Wed, 3 Dec 2014 02:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, 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 MsbW14hOZNvo for ; Wed, 3 Dec 2014 02:02:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A751A0389 for ; Wed, 3 Dec 2014 02:02:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPN11103; Wed, 03 Dec 2014 10:02:49 +0000 (GMT) Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 3 Dec 2014 10:02:20 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.67]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.03.0158.001; Wed, 3 Dec 2014 18:00:17 +0800 From: "Hedanping (Ana)" To: "t.petch" , Johannes Merkle , "Bert Wijnen (IETF)" , "Zhangdacheng (Dacheng)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt Thread-Index: AQHQC32W7oq+6LVoDE6S5Cxlxqg8yZx25Uig//+PYQCABB7B5YADEpyQ Date: Wed, 3 Dec 2014 10:00:16 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8F534A@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> In-Reply-To: <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/fkcjYpXfmxYCyGvkfj9EyC3KBHw Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 10:02:56 -0000 Thanks for the comments and I answer all the questions together: The new algorithm only tries to tackle the repetitive password issue of key= localization. So, it is not the objective of this algorithm to increase en= tropy.=20 Tom mentioned 'anyone who uses a password based system and does not have an= extra module to ensure that passwords meet current standards deserves all = the security breaches they get ' , and it is really extreme. The more const= raints we impose on user password, the less the available password space wi= ll be, which will in turn increases the possibility of collision attack. We= examined enormous devices that have extra modules for SSH and even for Win= dows server. It turns out that the extra module for SNMPV3 already disobeys= the regular and prevalent way, which normally checks '8 character string, = upper case, lower case, digit and extended punctuation'. Thus 'BerT135!BerT= 135!BerT135!' is believed strong enough in a regular check. Hacker communities have mentioned the current key localization method as a = loophole, and plan to submit it to CVE. Moreover, as the co-author of 'draft-hartman-snmp-sha2', I definitely agree= SHA2 being used in SNMP. We also support the adoption of 'draft-hmac-sha-2= -usm-snmp ' in order to support SHA2 to be a standard SNMP authentication m= ethod. If SHA2 is adopted, changes are mandated in the SNMP module. I don't= think the change of key localization 'from 64bits to 60bits+4bits' can be = more than the change' from SHA1,MD5 to SHA2'! Hence why don't we change the key localization algorithm together with auth= entication method and enhance the SNMP to a better security level, and most= importantly with interoperability? I believe as time goes by standards should be updated. Especially for a pro= tocol like SNMP, which impacts worldwide devices, the requirements of stand= ardizing secure key localization method, authentication method and so on ar= e emerged. Cheers, Ana > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Monday, December 01, 2014 6:31 PM > To: Zhangdacheng (Dacheng); Hedanping (Ana); opsawg@ietf.org > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > Subject: Re: [OPSAWG] New Version Notification for > draft-du-opsawg-snmp-key-localization-00.txt >=20 > ----- Original Message ----- > From: "Zhangdacheng (Dacheng)" > To: "Hedanping (Ana)" ; > Cc: > Sent: Saturday, November 29, 2014 3:59 AM >=20 > > Let me help clarify Danping's point. > > > > We found there was a problem in the localization algorithm, but we are > not sure whether this issue is worthwhile for us to address, or the effor= t of > addressing this issue is out of scope of the SNMP specification. So, we r= aise this > question here, and hope to get comments or suggestions. >=20 > The new algorithm that you propose seems to offer very little improvement= . > You suggest that after replicating the password, you then add the passwor= d > length in the last four octets to bring the length up to 64 octet. This = seems to > add very little entropy. >=20 > Also, an 8 character string, containing upper case, lower case, digit and > extended punctuation would have been regarded as too weak many years ago > and we should not be documenting such an approach now. >=20 > Again, anyone who uses a password based system and does not have a extra > module to ensure that passwords meet current standards deserves all the > security breaches they get! >=20 > Tom Petch >=20 > > > > Cheers > > > > Dacheng > > > > > -----Original Message----- > > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Hedanping > > > (Ana) > > > Sent: Saturday, November 29, 2014 10:52 AM > > > To: opsawg@ietf.org > > > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > > > Subject: [OPSAWG] FW: New Version Notification for > > > draft-du-opsawg-snmp-key-localization-00.txt > > > > > > Dear all, > > > We find a security problem in the current SNMP key localization > algorithm, but > > > we are not sure whether IETF is the right place to improve it. The > draft is > > > submitted and comments are appreciated. > > > > > > A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt > > > has been successfully submitted by Danping He and posted to the IETF > > > repository. > > > > > > Name: draft-du-opsawg-snmp-key-localization > > > Revision: 00 > > > Title: A New Algorithm for SNMP Key Localization Document date: > > > 2014-11-28 > > > Group: Individual Submission > > > Pages: 4 > > > URL: > > > > http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localizatio > n-00. > > > txt > > > Status: > > > > https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localization/ > > > Htmlized: > > > http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 > > > > > > > > > Abstract: > > > This draft discusses a security issue with the algorithm for > > > generating SNMP localized keys and introduce a new algorithm to > > > address this problem. > > > > > > > > > Regards, > > > Ana (Danping) From nobody Wed Dec 3 02:24:58 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46881A0AF7 for ; Wed, 3 Dec 2014 02:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilEfCZIE8dYs for ; Wed, 3 Dec 2014 02:24:53 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB9D1A0461 for ; Wed, 3 Dec 2014 02:24:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5CE598F4; Wed, 3 Dec 2014 11:24:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xKEhOEfvY1cH; Wed, 3 Dec 2014 11:24:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Dec 2014 11:24:50 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C011220035; Wed, 3 Dec 2014 11:24:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZjJDImAyVP6N; Wed, 3 Dec 2014 11:24:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD92A2002C; Wed, 3 Dec 2014 11:24:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9B9772FE93C8; Wed, 3 Dec 2014 11:24:47 +0100 (CET) Date: Wed, 3 Dec 2014 11:24:46 +0100 From: Juergen Schoenwaelder To: "Hedanping (Ana)" Message-ID: <20141203102445.GA26792@elstar.local> Mail-Followup-To: "Hedanping (Ana)" , "t. petch" , Johannes Merkle , "Bert Wijnen (IETF)" , "Zhangdacheng (Dacheng)" , "opsawg@ietf.org" , "draft-du-opsawg-snmp-key-localization@tools.ietf.org" References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <019501d00d55$33c871e0$4001a8c0@gateway.2wire.net> <77FA386512F0D748BC7C02C36EB1106D8F534A@szxeml557-mbs.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8F534A@szxeml557-mbs.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/AfQ2PMIau7gouSAKI9nrbzkHzSE Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 10:24:55 -0000 On Wed, Dec 03, 2014 at 10:00:16AM +0000, Hedanping (Ana) wrote: > > Hacker communities have mentioned the current key localization method as a loophole, and plan to submit it to CVE. > [..] > > Hence why don't we change the key localization algorithm together with authentication method and enhance the SNMP to a better security level, and most importantly with interoperability? > There seems to be some confusion here. The key localization used in RFC 3414 has nothing to do with the password-to-key transformation. It can be applied to keys that are not derived from a password. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Dec 3 09:28:11 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25A31A1B91; Wed, 3 Dec 2014 09:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5ZgxcpxvCgJ; Wed, 3 Dec 2014 09:27:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F02D1A8A69; Wed, 3 Dec 2014 09:27:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141203172747.5244.40136.idtracker@ietfa.amsl.com> Date: Wed, 03 Dec 2014 09:27:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/_N-Qq4422ty4ZZUcWSxD6UB8RU0 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-hybridmac-07.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 17:27:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : IEEE 802.11 MAC Profile for CAPWAP Authors : Chunju Shao Hui Deng Rajesh S. Pazhyannur Farooq Bari Rong Zhang Satoru Matsushima Filename : draft-ietf-opsawg-capwap-hybridmac-07.txt Pages : 11 Date : 2014-12-03 Abstract: The Control And Provisioning of Wireless Access Points (CAPWAP) protocol defines two entities: a Wireless Transmission Point (WTP) and an Access Controller (AC). The CAPWAP protocol binding for IEEE 802.11 defines two MAC (Medium Access Control) modes for IEEE 802.11 WTP: Split and Local MAC, and describes the required functionality split between the WTP and AC for each mode. However, in the Split MAC mode, the partitioning of encryption/decryption functions are not clearly defined. In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either at the AC or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This lack of specification leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11 MAC profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC. The IEEE 802.11 MAC profile is used as follows: the WTP informs the AC of the supported profiles during the discovery or join process and the AC configures the WTP with one of the supported profiles when configuring the WLAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-hybridmac-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-hybridmac-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 4 16:25:07 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E266D1A883E; Thu, 4 Dec 2014 16:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD3rDOOHn_Q2; Thu, 4 Dec 2014 16:24:59 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3561A8839; Thu, 4 Dec 2014 16:24:59 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rd18so16841649iec.22 for ; Thu, 04 Dec 2014 16:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=9mmrgimc85eT/1bEeooqGGPDUd0R1OTcTFbSjL7GuhE=; b=rzgebS3N7q/z9uJM755JkP+Vgz3ukPFOyAY4Z+wswvDtgGgc2Ye8sYq9V1N4TsYS16 we2IDqg8G55w2/RZksQdTLG8nKZUtE5XUE8QnREDhcCd/UEm8V4+eMzLdZ3gmiuax13/ OgkAHcAgSPPgYXGxNO4G+hYTAVKHAOIl2Wb8htTxoigsxFI5AYvxzg6BLU4L9n7qjscR aUrGlTqDUYQoiiXMhDVW4VGoYg0zMSRag54NhbqC8RMXET6wx8ShHLX00B6voGswTQS8 kvA74Q4H+1VC5RUQZGW7YNqmJJdbzlRVbnb+SoS3+1Pa+JM3Apxa8KyqrRxKpn43/XNX zGjA== X-Received: by 10.50.3.67 with SMTP id a3mr50208iga.42.1417739098124; Thu, 04 Dec 2014 16:24:58 -0800 (PST) Received: from [192.168.0.101] ([216.254.164.46]) by mx.google.com with ESMTPSA id kv4sm33565igb.13.2014.12.04.16.24.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 16:24:57 -0800 (PST) Message-ID: <5480FB54.9040003@gmail.com> Date: Thu, 04 Dec 2014 19:24:52 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/0CD4BROiDcR2JH_QjYZ1_oX93wk Subject: [OPSAWG] NAT MIB: Tying packet classification to address realms rather than subscribers X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 00:25:01 -0000 I've been thinking through the implications of the NAT application scenarios presented in my E-mail of 21 November ("NAT MIB: compliance levels"). One of them is that the large-scale NAT application, even though it does not understand individual subscribers, must have a means to classify received packets into address realms. The conclusion is that the packet classification criteria represented by natSubscriberIdentifierType, natSubscriberVlanIdentifier, etc. in the -11 version of the NAT MIB draft should be pulled out of natSubscribersTable and put into a separate realm table. My instinct is to make this NAT instance specific, in that: -- different NAT instances on the same device may support different realms -- different NAT instances may use different criteria to distinguish the same realms, as a kind of load-sharing control Comments? Tom Taylor From nobody Fri Dec 5 17:34:06 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F031A87C8; Fri, 5 Dec 2014 17:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va-C7LWVydnZ; Fri, 5 Dec 2014 17:34:03 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490FD1A87CC; Fri, 5 Dec 2014 17:34:03 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so1802992ier.32 for ; Fri, 05 Dec 2014 17:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aeRK0/0QiYFCUZRakMo/VEaUFbgpIZtrkZ0xt1R0IZk=; b=ry9YKa6vYUwe03ntmh6FCt4m934ecG1Z32eHzb5wfYtbyy6RKDJggklApv0EEsp5pp ji7G6fCjSOluK7NYZFAnV4KnX3jlK3Qt4Q1/B6shChtACipEtWfMz7kxEAeg4K7MdhL6 KrS5HqqKp3bp9h4GUZJD9Nc3Y1X3RJ7DVgOKbMeo9hHKp76+PTfTGkUht8Q2kFKD+oAv QS6AQbxyJbLPh/RC+6xGUeBklu3GUMEASTU4oCTQjZtnpTcKb2Hrw7BLr1A2FwXpHJMF ptN4q87kqDQDYiniF2ZftZQy1a165YQXOfiC7ACB980/Q3Y1SAG3DRgvaH/mv0D6tO1a mEvw== X-Received: by 10.107.149.13 with SMTP id x13mr1378636iod.35.1417829642355; Fri, 05 Dec 2014 17:34:02 -0800 (PST) Received: from [192.168.0.101] ([216.254.164.46]) by mx.google.com with ESMTPSA id kv4sm73137igb.13.2014.12.05.17.34.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 17:34:01 -0800 (PST) Message-ID: <54825D0A.8060107@gmail.com> Date: Fri, 05 Dec 2014 20:34:02 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" References: <5480FB54.9040003@gmail.com> In-Reply-To: <5480FB54.9040003@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/u-jWeFmzYO6_5sjCJ_J6Y9_ZP_8 Subject: Re: [OPSAWG] NAT MIB: Tying packet classification to address realms rather than subscribers X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 06 Dec 2014 01:34:04 -0000 I've had second thoughts. The data used for packet classification by subscriber and realm is actually configuration data. "When in doubt, throw it out": this data didn't belong in the MIB in the first place unless someone sees it as particularly valuable for trouble-shooting. Tom Taylor On 04/12/2014 7:24 PM, Tom Taylor wrote: > I've been thinking through the implications of the NAT application > scenarios presented in my E-mail of 21 November ("NAT MIB: compliance > levels"). One of them is that the large-scale NAT application, even > though it does not understand individual subscribers, must have a means > to classify received packets into address realms. The conclusion is that > the packet classification criteria represented by > natSubscriberIdentifierType, natSubscriberVlanIdentifier, etc. in the > -11 version of the NAT MIB draft should be pulled out of > natSubscribersTable and put into a separate realm table. My instinct is > to make this NAT instance specific, in that: > -- different NAT instances on the same device may support different realms > -- different NAT instances may use different criteria to distinguish the > same realms, as a kind of load-sharing control > > Comments? > > Tom Taylor From nobody Sat Dec 6 11:46:40 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A3C1A1B15 for ; Sat, 6 Dec 2014 11:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIg1LYy3fnl4 for ; Sat, 6 Dec 2014 11:46:35 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14931A1AAF for ; Sat, 6 Dec 2014 11:46:34 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so2223426lab.4 for ; Sat, 06 Dec 2014 11:46:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BV0OxckwteBh15CZigvuIWbLY/bOkq3WSpFP3Ij2t5E=; b=KPNBOG7hB91KIea6RypxhNaFNCpxpwraB7WBRAA+NAyXoCa0NXE1UvUwZcbygwYiGd Qldcw8T6Azdp2DU/swksxFOnHFArbthnwOtwWfJuACtn2CV/5NjufF4fqAetmuyWolSb 7zPqXiS2TW/Q5lMUVj+1upm7e930Vujkh9a4EGpmPoLYj4XyfxRn3CY7+d8O8ZA0lxv3 o5sgwqJl9e9pgncXFYAwBR6pYY+LYR7Flw6u4S5s5geqN6DKSGaW/jVG3hoObjm169cq ojqd/kTAmbqiImX/ggZjaMynQYvLG9SFyJSwElQvpGEh7jx5kSjMj8A1jXRKMGt2KCTf RalQ== X-Gm-Message-State: ALoCoQnfI9e2qjEow0wRvbSZIRPaStaZGM/RAeluxCWl82/A8lb72oVWR54ucoP1yXCZi8XibJJY MIME-Version: 1.0 X-Received: by 10.152.37.38 with SMTP id v6mr9068065laj.10.1417895193261; Sat, 06 Dec 2014 11:46:33 -0800 (PST) Received: by 10.25.84.145 with HTTP; Sat, 6 Dec 2014 11:46:33 -0800 (PST) Received: by 10.25.84.145 with HTTP; Sat, 6 Dec 2014 11:46:33 -0800 (PST) In-Reply-To: <54825D0A.8060107@gmail.com> References: <5480FB54.9040003@gmail.com> <54825D0A.8060107@gmail.com> Date: Sat, 6 Dec 2014 12:46:33 -0700 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=089e0160b5f252d1e4050991737c Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/t9KDrVhTxQi8WXtLM8DYhMk8_pg Cc: "behave@ietf.org" , opsawg@ietf.org Subject: Re: [OPSAWG] NAT MIB: Tying packet classification to address realms rather than subscribers X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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, 06 Dec 2014 19:46:36 -0000 --089e0160b5f252d1e4050991737c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable WFM. Simon Le 2014-12-05 20:34, "Tom Taylor" a =C3=A9crit = : > I've had second thoughts. The data used for packet classification by > subscriber and realm is actually configuration data. "When in doubt, thro= w > it out": this data didn't belong in the MIB in the first place unless > someone sees it as particularly valuable for trouble-shooting. > > Tom Taylor > > On 04/12/2014 7:24 PM, Tom Taylor wrote: > >> I've been thinking through the implications of the NAT application >> scenarios presented in my E-mail of 21 November ("NAT MIB: compliance >> levels"). One of them is that the large-scale NAT application, even >> though it does not understand individual subscribers, must have a means >> to classify received packets into address realms. The conclusion is that >> the packet classification criteria represented by >> natSubscriberIdentifierType, natSubscriberVlanIdentifier, etc. in the >> -11 version of the NAT MIB draft should be pulled out of >> natSubscribersTable and put into a separate realm table. My instinct is >> to make this NAT instance specific, in that: >> -- different NAT instances on the same device may support different real= ms >> -- different NAT instances may use different criteria to distinguish the >> same realms, as a kind of load-sharing control >> >> Comments? >> >> Tom Taylor >> > --089e0160b5f252d1e4050991737c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

WFM.

Simon

Le 2014-12-05 20:34, "Tom Taylor" <= tom.taylor.stds@gmail.com&= gt; a =C3=A9crit :
I= 've had second thoughts. The data used for packet classification by sub= scriber and realm is actually configuration data. "When in doubt, thro= w it out": this data didn't belong in the MIB in the first place u= nless someone sees it as particularly valuable for trouble-shooting.

Tom Taylor

On 04/12/2014 7:24 PM, Tom Taylor wrote:
I've been thinking through the implications of the NAT application
scenarios presented in my E-mail of 21 November ("NAT MIB: compliance<= br> levels"). One of them is that the large-scale NAT application, even though it does not understand individual subscribers, must have a means
to classify received packets into address realms. The conclusion is that the packet classification criteria represented by
natSubscriberIdentifierType, natSubscriberVlanIdentifier, etc. in the
-11 version of the NAT MIB draft should be pulled out of
natSubscribersTable and put into a separate realm table. My instinct is
to make this NAT instance specific, in that:
-- different NAT instances on the same device may support different realms<= br> -- different NAT instances may use different criteria to distinguish the same realms, as a kind of load-sharing control

Comments?

Tom Taylor
--089e0160b5f252d1e4050991737c-- From nobody Fri Dec 12 14:30:28 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0241A1A34; Fri, 12 Dec 2014 14:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxjost32UYJI; Fri, 12 Dec 2014 14:30:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1551A1E0F; Fri, 12 Dec 2014 14:30:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 14:30:24 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/uTmddKYoTOhz_cGj2AxPmU0m2pk Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 22:30:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : HMAC-SHA-2 Authentication Protocols in USM for SNMP Authors : Johannes Merkle Manfred Lochter Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt Pages : 13 Date : 2014-12-12 Abstract: This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 17 08:14:47 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382A71A8A8F for ; Wed, 17 Dec 2014 08:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q288pwdaZyeU for ; Wed, 17 Dec 2014 08:14:34 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 86CFC1A8AF6 for ; Wed, 17 Dec 2014 08:14:08 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA09038 for ; Wed, 17 Dec 2014 11:13:59 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id sBHGDtBn044568 for ; Wed, 17 Dec 2014 11:14:00 -0500 (EST) (envelope-from reid@snmp.com) Message-Id: <201412171614.sBHGDtBn044568@mainfs.snmp.com> To: opsawg@ietf.org From: David Reid In-reply-to: Your message of Fri, 12 Dec 2014 14:30:24 -0800. <20141212223024.19483.34288.idtracker@ietfa.amsl.com> Date: Wed, 17 Dec 2014 11:13:55 -0500 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/zzQYHlFZuZ6RWDBrO7B8_tTusAo Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 16:14:42 -0000 I have reviewed this document. It looks good. We plan to implement it. I have one minor suggestion. The names of the protocols are not always consistent. For example, section 4 uses usmHMAC128SHA224AuthProtocol, section 4.1 uses usm128HMACSHA224AuthProtocol, and the MIB uses usmHmac128Sha224Protocol. I suggest using names of the form usmHMAC128SHA224AuthProtocol in all cases. -David Reid > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. > > Title : HMAC-SHA-2 Authentication Protocols in USM for SNMP > Authors : Johannes Merkle > Manfred Lochter > Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt > Pages : 13 > Date : 2014-12-12 > > Abstract: > This memo specifies new HMAC-SHA-2 authentication protocols for the > User-based Security Model (USM) for SNMPv3 defined in RFC 3414. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Dec 17 09:46:48 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B051A6FC6 for ; Wed, 17 Dec 2014 09:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MACPHNYk-EVL for ; Wed, 17 Dec 2014 09:46:41 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808221A6FB2 for ; Wed, 17 Dec 2014 09:46:40 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 0F30B1A008B; Wed, 17 Dec 2014 18:46:30 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rDF2aa6xNDgF; Wed, 17 Dec 2014 18:46:21 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 82BB81A008A; Wed, 17 Dec 2014 18:46:21 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 17 Dec 2014 18:46:29 +0100 Message-ID: <5491C174.7040307@secunet.com> Date: Wed, 17 Dec 2014 18:46:28 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Reid , References: <201412171614.sBHGDtBn044568@mainfs.snmp.com> In-Reply-To: <201412171614.sBHGDtBn044568@mainfs.snmp.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/tkxfKn3CA_O9H7nvtt4qJBdmazE Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:46:44 -0000 > I have one minor suggestion. The names of the protocols are not always > consistent. For example, section 4 uses usmHMAC128SHA224AuthProtocol, > section 4.1 uses usm128HMACSHA224AuthProtocol, and the MIB uses > usmHmac128Sha224Protocol. I suggest using names of the form > usmHMAC128SHA224AuthProtocol in all cases. Thanks for pointing this out. As suggested, the names will be unified to usmHMACxxxSHAyyyAuthProtocol in the next version. Johannes From nobody Thu Dec 18 01:06:09 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C9E1A6F82 for ; Thu, 18 Dec 2014 01:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24lC3cKvPzxl for ; Thu, 18 Dec 2014 01:06:05 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34DA1A6F3F for ; Thu, 18 Dec 2014 01:06:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9C5BA93E for ; Thu, 18 Dec 2014 10:06:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kOGgyQ9fP50x for ; Thu, 18 Dec 2014 10:06:02 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 18 Dec 2014 10:06:03 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C2BC20035 for ; Thu, 18 Dec 2014 10:06:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Og7AvmdCWT79; Thu, 18 Dec 2014 10:06:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E967E2002C; Thu, 18 Dec 2014 10:06:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1F6F42FFB3D8; Thu, 18 Dec 2014 10:06:00 +0100 (CET) Date: Thu, 18 Dec 2014 10:06:00 +0100 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20141218090600.GA69757@elstar.local> Mail-Followup-To: opsawg@ietf.org References: <20141118150037.GB88064@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141118150037.GB88064@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/V8NrNDqiPnSEW90cciYPJ3i6FSc Subject: Re: [OPSAWG] document status X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 09:06:06 -0000 On Tue, Nov 18, 2014 at 04:00:37PM +0100, Juergen Schoenwaelder wrote: > Hi, > > since I could not follow the meeting in Honolulu, can I please get a > clarification where we are with these WG documents? [...] > - https://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-02 > > This I-D is still a WG document. What are the next steps and who > holds the token? Who is going to be the document shepherd? > > I just want to make sure it is clear who has to take the next action > so that we can wrap up things in a timely manner. Hi, where are we with this document? I did not see an answer. Can we get this moving please? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Dec 18 09:37:34 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20A91A911E; Thu, 18 Dec 2014 09:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMVYaI98Gl9R; Thu, 18 Dec 2014 09:37:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E671A8A8F; Thu, 18 Dec 2014 09:37:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218173730.15832.27019.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 09:37:30 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/UDXuIOX4h6IS4KBZOhz2rml1oYs Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-hybridmac-08.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 17:37:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : IEEE 802.11 MAC Profile for CAPWAP Authors : Chunju Shao Hui Deng Rajesh S. Pazhyannur Farooq Bari Rong Zhang Satoru Matsushima Filename : draft-ietf-opsawg-capwap-hybridmac-08.txt Pages : 10 Date : 2014-12-18 Abstract: The CAPWAP protocol binding for IEEE 802.11 defines two MAC (Medium Access Control) modes for IEEE 802.11 WTP (Wireless Transmission Point): Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions are not clearly defined. In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either the AC (Access Controller) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11 MAC profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-hybridmac-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-hybridmac-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 19 07:06:09 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968151A1AA0 for ; Fri, 19 Dec 2014 07:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q-OIB-sVYjG for ; Fri, 19 Dec 2014 07:06:00 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD881A8981 for ; Fri, 19 Dec 2014 07:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32165; q=dns/txt; s=iport; t=1419001559; x=1420211159; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=zhbw6AAHOjf7QMfFQ8XbvT7kVXyuWI/MPV9olZmAecA=; b=I0fA3cayFjFgZqsZgYa3Kc7ppDAlXWKxwrCXPZyJmqnEfRTwaAyaYLHz kGeEmZHQUfSdw+OJ92BNgWNkNWAnRsSzYjGGtAZOIeClcvIw09W7HDhnN YMgs5/DX8gXvnM4LcJpLqqeGon52OBJ60ogSJHIS848A35CK91v++V/yq M=; X-IronPort-AV: E=Sophos;i="5.07,607,1413244800"; d="scan'208,217";a="276129929" 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; 19 Dec 2014 15:05:57 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBJF5vsH009050; Fri, 19 Dec 2014 15:05:57 GMT Message-ID: <54943ED5.6050506@cisco.com> Date: Fri, 19 Dec 2014 16:05:57 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090406080205050408020205" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/QLOwztVnNOuR13hQzv6X7BhdCbM Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 15:06:06 -0000 This is a multi-part message in MIME format. --------------090406080205050408020205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote: > Hi Benoit, > > > Let me propose a solution: augment > draft-ietf-opsawg-capwap-alt-tunnel with the information elements for > CAPWAP (not the others one). > > The above draft defines number of encapsulation modes and that list > includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and > GREv6. Each of those tunnel types can be activated with a set of > tunnel parameters. These parameters include source IP, destination IP, > sport, dport, GRE key ..etc. To most part this is about identifying a > common set of parameters, providing definition for those parameters > and grouping the relevant one's for each of the encapsulation modes. > Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not > radically different from the others and the above common parameter set > is sufficient for these modes. To create a tunnel with GRE with IPv4 > transport is not any different from GRE with IPv6 transport, or for > that matter for IP-in-IP mode. > > It is to be noted there are no proposed changes to any of these > encapsulation modes, or to the control protocols activating those > encap modes. Its mostly about activating a tunnel state with a set of > parameters. If at all, CAPWAP data plane may be bit complex and even > L2TP as its unclear if the control protocol has semantics for the L2TP > peers to separate control and data plane. If not, it requires changes > to the L2TP protocol. So, its easier to keep CAPWAP + GRE/IP-in-IP > modes in the main spec as the work has a well defined scope. If it works for the WG, it works for me. Any objections anybody? That would imply a new draft and a new consensus call. Regards, Benoit > > So, my suggestion is to allow draft-ietf-opsawg-capwap-alt-tunnel to > also support GRE/IP-in-IP modes and have draft-xue focus exclusively > on L2TP extensions and move it on a fast track. IMO, this is a > reasonably split. I'm also happy to provide the text for the above > encap modes and ensure the changes do not delay the publication. > > Regards > Sri > > > > > > > From: "Benoit Claise (bclaise)" > > Date: Monday, December 1, 2014 7:37 AM > To: "Rajesh Pazhyannur (rpazhyan)" >, > "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org > " >, > "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org > " > > > Cc: "opsawg@ietf.org " > > Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and > draft-xue-opsawg-capwap-alt-tunnel-information relationship > > Hi Rajesh, > > I'm concerned that: > - draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution > - draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from > draft-xue-opsawg-capwap-alt-tunnel-information, an individual draft. > - draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different > tunnel types, and required expertise from many different group. This > might take some time... > > Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel > with the information elements for CAPWAP (not the others one). This > way, this draft would be a complete solution. > And if people wants alternate tunnel types, this would be done in > draft-xue-opsawg-capwap-alt-tunnel-information > > Regards, Benoit/ > // > / >> Hello >> >> I realized there was a typographical error in my response below. >> Please see corrections. >> >> Regards >> >> Rajesh >> From: Rajesh Pazhyannur > >> Date: Thursday, November 20, 2014 at 12:30 AM >> To: "Benoit Claise (bclaise)" > >, >> "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org >> " >> > >, >> "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org >> " >> > > >> Cc: "opsawg@ietf.org " > > >> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and >> draft-xue-opsawg-capwap-alt-tunnel-information relationship >> >> Hi Benoit >> >> But now I wonder: why do we have two different drafts, as opposed to >> a single one? >> >> This is a good question. >> >> [*original*] Yes, you are correct that >> draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete >> solution and needs something like >> *draft-ietf-opsawg-capwap-alt-tunnel* to complete the solution. >> [corrected statement] Y/es, you are correct that >> draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete >> solution and needs something like >> *draft-xue-opsawg-capwap-alt-tunnel-information* to complete the >> solution. / >> >> The best answer I have is that we wanted the keep the following two >> areas separate (and in different drafts) >> >> 1. Discover and negotiation of alternate tunneling capability. These >> are independent of specific alternate tunnel method >> 2. [*original*] Definition of tunnel specific message elements. >> While >> draft-ietf-opsawg-capwap-alt-tunnel contains message elements for >> most of the tunneling methods defined in >> *draft-ietf-opsawg-capwap-alt-tunnel*, I had anticipated separate >> drafts for each tunneling protocol. >> >> /[corrected] 2 Definition of tunnel specific message elements. While >> draft-ietf-opsawg-capwap-alt-tunnel contains message elements for >> most of the tunneling methods defined in >> *draft-xue-opsawg-capwap-alt-tunnel-information* I had anticipated >> separate drafts for each tunneling protocol./ >> >> Finishing 1. would allow 2. to be completed separately and >> independently in potentially different drafts (and potentially >> different groups with relevant expertise). It is somewhat akin >> (though not identical) to separation between RFC 5415 and RFC 5416 >> where RFC 5415 is wireless technology independent and RFC 5416 is >> 802.11 specific. >> >> Hope the above makes sense. >> >> Regards >> >> Rajesh >> From: "Benoit Claise (bclaise)" > > >> Date: Wednesday, November 19, 2014 at 11:50 AM >> To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org >> " >> > >, >> "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org >> " >> > > >> Cc: "opsawg@ietf.org " > > >> Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and >> draft-xue-opsawg-capwap-alt-tunnel-information relationship >> >> Dear CAPWAP authors, >> >> After the draft-xue-opsawg-capwap-alt-tunnel-information presentation >> at the last IETF meeting, I've been wondering about the relationship >> between the two drafts: >> - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types >> Note:this draft is currently in AD review, so close to be sent to >> the IESG. >> - draft-xue-opsawg-capwap-alt-tunnel-information provides the >> encoding of the tunnel-specific fields. >> >> I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel >> doesn't provide a complete solution without >> draft-xue-opsawg-capwap-alt-tunnel-information? >> >> I'm aware of the changes between version 3 and 4 (attached picture >> and >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-04.txt) >> >> But now I wonder: why do we have two different drafts, as opposed to >> a single one? >> >> Regards, Benoit >> >> > > . --------------090406080205050408020205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote:
Hi Benoit,

> Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel with the information elements for CAPWAP (not the others one). 

The above draft defines number of encapsulation modes and that list includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. Each of those tunnel types can be activated with a set of tunnel parameters. These parameters include source IP, destination IP, sport, dport, GRE key ..etc. To most part this is about identifying a common set of parameters, providing definition for those parameters and grouping the relevant one's for each of the encapsulation modes. Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not radically different from the others and the above common parameter set is sufficient for these modes.  To create a tunnel with GRE with IPv4 transport is not any different from GRE with IPv6 transport, or for that matter for IP-in-IP mode. 

It is to be noted there are no proposed changes to any of these encapsulation modes, or to the control protocols activating those encap modes. Its mostly about activating a tunnel state with a set of parameters.  If at all, CAPWAP data plane may be bit complex and even L2TP as its unclear if the control protocol has semantics for the L2TP peers to separate control and data plane. If not, it requires changes to the L2TP protocol. So, its easier to keep CAPWAP + GRE/IP-in-IP modes in the main spec as the work has a well defined scope.
If it works for the WG, it works for me. Any objections anybody?
That would imply a new draft and a new consensus call.

Regards, Benoit

So, my suggestion is to allow draft-ietf-opsawg-capwap-alt-tunnel  to also support GRE/IP-in-IP modes and have draft-xue focus exclusively on L2TP extensions and move it on a fast track. IMO, this is a reasonably split.  I'm also happy to provide the text for the above encap modes and ensure the changes do not delay the publication. 
 

Regards
Sri






From: "Benoit Claise (bclaise)" <bclaise@cisco.com>
Date: Monday, December 1, 2014 7:37 AM
To: "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>, "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" <draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" <draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship

Hi Rajesh,

I'm concerned that:
- draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution
- draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from draft-xue-opsawg-capwap-alt-tunnel-information, an individual draft.
- draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different tunnel types, and required expertise from many different group. This might take some time...

Let me propose a solution: augment draft-ietf-opsawg-capwap-alt-tunnel with the information elements for CAPWAP (not the others one). This way, this draft would be a complete solution.
And if people wants alternate tunnel types, this would be done in draft-xue-opsawg-capwap-alt-tunnel-information

Regards, Benoit

Hello

I realized there was a typographical error in my response below. 
Please see corrections.  

Regards

Rajesh
From: Rajesh Pazhyannur <rpazhyan@cisco.com>
Date: Thursday, November 20, 2014 at 12:30 AM
To: "Benoit Claise (bclaise)" <bclaise@cisco.com>, "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" <draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" <draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship

Hi Benoit

But now I wonder: why do we have two different drafts, as opposed to a single one?

This is a good question.  

[original] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution and needs something like  draft-ietf-opsawg-capwap-alt-tunnel to complete the solution. 
[corrected statement] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution and needs something like  draft-xue-opsawg-capwap-alt-tunnel-information to complete the solution. 

The best answer I have is  that we wanted the keep the following two areas separate (and in different drafts) 
  1. Discover and negotiation of alternate tunneling capability. These are  independent of specific alternate tunnel method 
  2. [original] Definition of tunnel specific message elements. While draft-ietf-opsawg-capwap-alt-tunnel contains message elements for most of the tunneling methods defined in  draft-ietf-opsawg-capwap-alt-tunnel, I had anticipated separate drafts for each tunneling protocol.
[corrected] 2 Definition of tunnel specific message elements. While draft-ietf-opsawg-capwap-alt-tunnel contains message elements for most of the tunneling methods defined in  draft-xue-opsawg-capwap-alt-tunnel-information I had anticipated separate drafts for each tunneling protocol.

Finishing 1. would allow 2. to be completed separately and independently in potentially different drafts (and potentially different groups with relevant expertise). It is somewhat akin (though not identical) to separation between RFC 5415 and RFC 5416 where RFC 5415 is wireless technology independent and RFC 5416 is 802.11 specific.  

Hope the above  makes sense. 

Regards

Rajesh
From: "Benoit Claise (bclaise)" <bclaise@cisco.com>
Date: Wednesday, November 19, 2014 at 11:50 AM
To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" <draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" <draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship

Dear CAPWAP authors,

After the draft-xue-opsawg-capwap-alt-tunnel-information presentation at the last IETF meeting, I've been wondering about the relationship between the two drafts:
- draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types
  Note:this draft is currently in AD review, so close to be sent to the IESG.
- draft-xue-opsawg-capwap-alt-tunnel-information provides the encoding of the tunnel-specific fields.

I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel doesn't provide a complete solution without draft-xue-opsawg-capwap-alt-tunnel-information?

I'm aware of the changes between version 3 and 4 (attached picture and http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-04.txt)

But now I wonder: why do we have two different drafts, as opposed to a single one?

Regards, Benoit



 .

--------------090406080205050408020205-- From nobody Fri Dec 19 07:08:42 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616461A89A5 for ; Fri, 19 Dec 2014 07:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.497 X-Spam-Level: * X-Spam-Status: No, score=1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnly8s1T4BMT for ; Fri, 19 Dec 2014 07:08:20 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB301A8981 for ; Fri, 19 Dec 2014 07:08:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id C611BD6922E; Fri, 19 Dec 2014 10:10:11 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZdC2RYAdcxm; Fri, 19 Dec 2014 10:10:10 -0500 (EST) Received: from newdev.cadm.harvard.edu (newdev.cadm.harvard.edu [128.103.229.199]) by sobco.sobco.com (Postfix) with ESMTPSA id B20ECD69221; Fri, 19 Dec 2014 10:10:10 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: "Scott O. Bradner" In-Reply-To: <54943ED5.6050506@cisco.com> Date: Fri, 19 Dec 2014 10:08:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54943ED5.6050506@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/i8RqhA_Qb0yZ4NJMcg_6wW6zr2I Cc: "opsawg@ietf.org" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 15:08:23 -0000 wfm > On Dec 19, 2014, at 10:05 AM, Benoit Claise wrote: >=20 > On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote: >> Hi Benoit, >>=20 >> > Let me propose a solution: augment = draft-ietf-opsawg-capwap-alt-tunnel with the information elements for = CAPWAP (not the others one).=20 >>=20 >> The above draft defines number of encapsulation modes and that list = includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. = Each of those tunnel types can be activated with a set of tunnel = parameters. These parameters include source IP, destination IP, sport, = dport, GRE key ..etc. To most part this is about identifying a common = set of parameters, providing definition for those parameters and = grouping the relevant one's for each of the encapsulation modes. Taking = GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not radically = different from the others and the above common parameter set is = sufficient for these modes. To create a tunnel with GRE with IPv4 = transport is not any different from GRE with IPv6 transport, or for that = matter for IP-in-IP mode.=20 >>=20 >> It is to be noted there are no proposed changes to any of these = encapsulation modes, or to the control protocols activating those encap = modes. Its mostly about activating a tunnel state with a set of = parameters. If at all, CAPWAP data plane may be bit complex and even = L2TP as its unclear if the control protocol has semantics for the L2TP = peers to separate control and data plane. If not, it requires changes to = the L2TP protocol. So, its easier to keep CAPWAP + GRE/IP-in-IP modes in = the main spec as the work has a well defined scope. > If it works for the WG, it works for me. Any objections anybody? > That would imply a new draft and a new consensus call. >=20 > Regards, Benoit >>=20 >> So, my suggestion is to allow draft-ietf-opsawg-capwap-alt-tunnel to = also support GRE/IP-in-IP modes and have draft-xue focus exclusively on = L2TP extensions and move it on a fast track. IMO, this is a reasonably = split. I'm also happy to provide the text for the above encap modes and = ensure the changes do not delay the publication.=20 >> =20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> From: "Benoit Claise (bclaise)" >> Date: Monday, December 1, 2014 7:37 AM >> To: "Rajesh Pazhyannur (rpazhyan)" , = "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" = , = "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" = >> Cc: "opsawg@ietf.org" >> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and = draft-xue-opsawg-capwap-alt-tunnel-information relationship >>=20 >> Hi Rajesh, >>=20 >> I'm concerned that: >> - draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete = solution >> - draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from = draft-xue-opsawg-capwap-alt-tunnel-information, an individual draft. >> - draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different = tunnel types, and required expertise from many different group. This = might take some time... >>=20 >> Let me propose a solution: augment = draft-ietf-opsawg-capwap-alt-tunnel with the information elements for = CAPWAP (not the others one). This way, this draft would be a complete = solution.=20 >> And if people wants alternate tunnel types, this would be done in = draft-xue-opsawg-capwap-alt-tunnel-information >>=20 >> Regards, Benoit >>=20 >>> Hello >>>=20 >>> I realized there was a typographical error in my response below.=20 >>> Please see corrections. =20 >>>=20 >>> Regards >>>=20 >>> Rajesh >>> From: Rajesh Pazhyannur >>> Date: Thursday, November 20, 2014 at 12:30 AM >>> To: "Benoit Claise (bclaise)" , = "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" = , = "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" = >>> Cc: "opsawg@ietf.org" >>> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and = draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>=20 >>> Hi Benoit >>>=20 >>> But now I wonder: why do we have two different drafts, as opposed to = a single one? >>>=20 >>> This is a good question. =20 >>>=20 >>> [original] Yes, you are correct that = draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution = and needs something like draft-ietf-opsawg-capwap-alt-tunnel to = complete the solution.=20 >>> [corrected statement] Yes, you are correct that = draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete solution = and needs something like draft-xue-opsawg-capwap-alt-tunnel-information = to complete the solution.=20 >>>=20 >>> The best answer I have is that we wanted the keep the following two = areas separate (and in different drafts)=20 >>> =95 Discover and negotiation of alternate tunneling capability. = These are independent of specific alternate tunnel method=20 >>> =95 [original] Definition of tunnel specific message elements. = While draft-ietf-opsawg-capwap-alt-tunnel contains message elements for = most of the tunneling methods defined in = draft-ietf-opsawg-capwap-alt-tunnel, I had anticipated separate drafts = for each tunneling protocol. >>> [corrected] 2 Definition of tunnel specific message elements. While = draft-ietf-opsawg-capwap-alt-tunnel contains message elements for most = of the tunneling methods defined in = draft-xue-opsawg-capwap-alt-tunnel-information I had anticipated = separate drafts for each tunneling protocol. >>>=20 >>> Finishing 1. would allow 2. to be completed separately and = independently in potentially different drafts (and potentially different = groups with relevant expertise). It is somewhat akin (though not = identical) to separation between RFC 5415 and RFC 5416 where RFC 5415 is = wireless technology independent and RFC 5416 is 802.11 specific. =20 >>>=20 >>> Hope the above makes sense.=20 >>>=20 >>> Regards >>>=20 >>> Rajesh >>> From: "Benoit Claise (bclaise)" >>> Date: Wednesday, November 19, 2014 at 11:50 AM >>> To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" = , = "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" = >>> Cc: "opsawg@ietf.org" >>> Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and = draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>=20 >>> Dear CAPWAP authors, >>>=20 >>> After the draft-xue-opsawg-capwap-alt-tunnel-information = presentation at the last IETF meeting, I've been wondering about the = relationship between the two drafts: >>> - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types >>> Note:this draft is currently in AD review, so close to be sent to = the IESG. >>> - draft-xue-opsawg-capwap-alt-tunnel-information provides the = encoding of the tunnel-specific fields. >>>=20 >>> I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel = doesn't provide a complete solution without = draft-xue-opsawg-capwap-alt-tunnel-information? >>>=20 >>> I'm aware of the changes between version 3 and 4 (attached picture = and = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-capwap-alt-tunnel-0= 4.txt) >>>=20 >>> But now I wonder: why do we have two different drafts, as opposed to = a single one? >>>=20 >>> Regards, Benoit >>>=20 >>>=20 >>=20 >> . >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Dec 22 04:59:21 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5401A8AF5 for ; Mon, 22 Dec 2014 04:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.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, 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 BbP2_tcn1mIc for ; Mon, 22 Dec 2014 04:59:16 -0800 (PST) Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327B41A8AF3 for ; Mon, 22 Dec 2014 04:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2361; q=dns/txt; s=iport; t=1419253157; x=1420462757; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=tjdXMbo3AOR/F4LstPra1wqdftek7lSzroYNZYsE1fA=; b=QZxXJc2jg9aeEiS2GMUfNzrzxUXb/8zVhusHdgtUI/2JF+JsYTvPzAT0 4ksIYmQ+7c68iYhDAOJqrh1ovLUws94QnbINZsMvuCypVLxAjJfKHIhKw XEmyQUbDT3yTnq0XWO5tIkjXLveoFQd4AccoTJxWcfBbhKULaqu/xsN2d A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAGMUmFRIo8UY/2dsb2JhbABbg1hYxkmFbgKBMAEBAQEBfYQNAQEEeBEPARwWDwkDAgECAUUGDQgBAYgoDc86AQEBAQEBAQMBAQEBAQEBARqPIQEBVoQpBZFPgX+DNYENMII0ghKLSCKDbz0xAYELgTcBAQE X-IronPort-AV: E=Sophos; i="5.07,623,1413244800"; d="scan'208,217"; a="14129485" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP; 22 Dec 2014 12:59:14 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBMCxBoJ020432 for ; Mon, 22 Dec 2014 12:59:12 GMT Message-ID: <5498159F.6050400@cisco.com> Date: Mon, 22 Dec 2014 13:59:11 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <54943DC6.9010205@cisco.com> In-Reply-To: <54943DC6.9010205@cisco.com> X-Forwarded-Message-Id: <54943DC6.9010205@cisco.com> Content-Type: multipart/alternative; boundary="------------040403060304030203020502" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/DdxCfXqdVarh8f_w4Bo98vfUWls Subject: [OPSAWG] OPSAWG WG transition to Joel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.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 Dec 2014 12:59:17 -0000 This is a multi-part message in MIME format. --------------040403060304030203020502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, In order to execute the IESG YANG Model Work Redistribution plan (see https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html), Joel will become the OPSAWG responsible AD. Practically, this implies that: - Joel will be AD reviewing draft-ietf-opsawg-coman-probstate-reqs-03 and draft-ietf-opsawg-coman-use-cases-03 . Note that Joel is already the responsible AD for those 2 drafts. - I will continue the draft-ietf-opsawg-capwap-alt-tunnel AD review. Please let us know if you have any questions. Regards, Benoit --------------040403060304030203020502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

In order to execute the IESG YANG Model Work Redistribution plan (see https://www.ietf.org/mail-archive/web/ietf/current/msg90926.html), Joel will become the OPSAWG responsible AD.

Practically, this implies that:
- Joel will be AD reviewing draft-ietf-opsawg-coman-probstate-reqs-03 and draft-ietf-opsawg-coman-use-cases-03. Note that  Joel is already the responsible AD for those 2 drafts.
- I will continue the draft-ietf-opsawg-capwap-alt-tunnel AD review.

Please let us know if you have any questions.

Regards, Benoit



--------------040403060304030203020502-- From nobody Wed Dec 31 07:17:19 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A3A1A904A for ; Wed, 31 Dec 2014 07:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de2tJIt5n9DI; Wed, 31 Dec 2014 07:17:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F631A904C; Wed, 31 Dec 2014 07:17:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231151709.1869.27955.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 07:17:09 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/6HDFOou82IWEQsa6Up2osz94h50 Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:17:15 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ From nobody Wed Dec 31 07:17:53 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB96C1A9033 for ; Wed, 31 Dec 2014 07:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leIYOJXjIvUV; Wed, 31 Dec 2014 07:17:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8251A904E; Wed, 31 Dec 2014 07:17:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-use-cases.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231151730.1946.91012.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 07:17:30 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/cLn5XRiwI-EcYwUrm4x5iGhJAxw Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:17:48 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Wed Dec 31 07:36:45 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F401A9044; Wed, 31 Dec 2014 07:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hU8dbhqqZ5i; Wed, 31 Dec 2014 07:36:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F141A9046; Wed, 31 Dec 2014 07:36:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141231153632.17392.1296.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 07:36:32 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/CIcy9pPIW-TBd0nUaNDFFVny4xQ Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: (Management of Networks with Constrained Devices: Problem Statement and Requirements) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:36:34 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Management of Networks with Constrained Devices: Problem Statement and Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-01-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a problem statement, deployment and management topology options as well as potential requirements for the management of networks where constrained devices are involved. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Dec 31 07:37:01 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7471A9076 for ; Wed, 31 Dec 2014 07:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSisFZzIwNNU; Wed, 31 Dec 2014 07:36:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A151A907F; Wed, 31 Dec 2014 07:36:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231153633.17392.59428.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 07:36:33 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/zLiQKzk6-0IBQldY4B4eggjYQGk Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:36:51 -0000 Last call has been made for draft-ietf-opsawg-coman-probstate-reqs and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ From nobody Wed Dec 31 07:38:07 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B5A1A903B; Wed, 31 Dec 2014 07:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-qDjZdo8bmX; Wed, 31 Dec 2014 07:38:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5D11A907F; Wed, 31 Dec 2014 07:37:49 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141231153749.10629.97783.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 07:37:49 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/F55h97Ti_sg64fIo02KxBhXqA8s Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: (Management of Networks with Constrained Devices: Use Cases) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:38:04 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Management of Networks with Constrained Devices: Use Cases' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-01-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document discusses use cases concerning the management of networks, where constrained devices are involved. A problem statement, deployment options and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements". The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Dec 31 07:38:18 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F391A903B for ; Wed, 31 Dec 2014 07:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNX0ZByuOxJV; Wed, 31 Dec 2014 07:38:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1951A90A1; Wed, 31 Dec 2014 07:37:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-use-cases.all@tools.ietf.org, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231153749.10629.15091.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 07:37:49 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/JDmXCVdICtk_RnnL_cr6uNJSuGU Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 15:38:07 -0000 Last call has been made for draft-ietf-opsawg-coman-use-cases and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/