From ietfdbh@comcast.net Thu Feb 2 06:12:36 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2940721F85AF for ; Thu, 2 Feb 2012 06:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh7g3NVdFiAB for ; Thu, 2 Feb 2012 06:12:35 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2675521F858D for ; Thu, 2 Feb 2012 06:12:35 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id V25b1i0041YDfWL532Cbjs; Thu, 02 Feb 2012 14:12:35 +0000 Received: from [192.168.1.7] ([96.252.194.151]) by omta20.westchester.pa.mail.comcast.net with comcast id V2CP1i0263GTgco3g2CSUW; Thu, 02 Feb 2012 14:12:33 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 02 Feb 2012 09:12:27 -0500 From: David Harrington To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: Thread-Topic: [OPSAWG] WGLC draft-ietf-opsawg-management-stds In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 14:12:36 -0000 That's better. Thanks, -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 1/30/12 2:30 PM, "Ersue, Mehmet (NSN - DE/Munich)" wrote: >Hi David, > >> >> NEW: >> >> An agent entity can restrict access to a certain portion of its >MIB, >> >> e.g. >> >> restrict some manager principals to view performance-related >statistics, >> >> >> >> allow only a single designated manager principal to view or update >> >> configuration parameters or disallow other manager principals to >read >> >> the performance-related statistics. >> > >> >OK >> >> I agree with making the text examples. I think one example should be >that >> some managers might only be allowed read-only access while others are >> allowed read-write access. >> The new text mixes operations and specific views (perf stats), so the >RO >> vs RW example is not very clearly shown. > >Would this work for you? If not please provide some NEW text. > >NEW: >An agent entity can restrict access to a certain portion of its MIB, >e.g. restrict >some manager principals to view only performance-related statistics, or >disallow >other manager principals to read those performance-related statistics. >An agent entity can also restrict to monitoring (read-only) as opposed >to monitoring >and configuration (read-write) of a certain portion of its MIB, e.g. >allowing only a >single designated manager principal to update configuration parameters. > >Cheers, >Mehmet > From mehmet.ersue@nsn.com Thu Feb 2 06:44:51 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C6821F8552 for ; Thu, 2 Feb 2012 06:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAhXMUsLunXQ for ; Thu, 2 Feb 2012 06:44:51 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D432621F854D for ; Thu, 2 Feb 2012 06:44:50 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q12Eino4026581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Feb 2012 15:44:49 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q12Eikj7021411 for ; Thu, 2 Feb 2012 15:44:49 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 15:44:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Feb 2012 15:44:46 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64035A06AC@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WGLC draft-ietf-opsawg-management-stds Thread-Index: AczhtLfJ96ScALNxRWKCTLJWPtiZzQABFBbg From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 02 Feb 2012 14:44:46.0883 (UTC) FILETIME=[3572FF30:01CCE1B9] Subject: [OPSAWG] FW: WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 14:44:51 -0000 I also changed "manager principle" to "principal" and=20 defined principal in the terminology section. Cheers,=20 Mehmet=20 -----Original Message----- From: ext David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Thursday, February 02, 2012 3:12 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds That's better. Thanks, -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 1/30/12 2:30 PM, "Ersue, Mehmet (NSN - DE/Munich)" wrote: >Hi David, > >> >> NEW: >> >> An agent entity can restrict access to a certain portion of its >MIB, >> >> e.g. >> >> restrict some manager principals to view performance-related >statistics, >> >> >> >> allow only a single designated manager principal to view or update >> >> configuration parameters or disallow other manager principals to >read >> >> the performance-related statistics. >> > >> >OK >>=20 >> I agree with making the text examples. I think one example should be >that >> some managers might only be allowed read-only access while others are >> allowed read-write access. >> The new text mixes operations and specific views (perf stats), so the >RO >> vs RW example is not very clearly shown. > >Would this work for you? If not please provide some NEW text. > >NEW:=20 >An agent entity can restrict access to a certain portion of its MIB, >e.g. restrict=20 >some manager principals to view only performance-related statistics, or >disallow=20 >other manager principals to read those performance-related statistics. >An agent entity can also restrict to monitoring (read-only) as opposed >to monitoring=20 >and configuration (read-write) of a certain portion of its MIB, e.g. >allowing only a=20 >single designated manager principal to update configuration parameters. > >Cheers, >Mehmet > From ietfc@btconnect.com Sat Feb 4 07:18:34 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A01F21F855F for ; Sat, 4 Feb 2012 07:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT6ux9SY7qTI for ; Sat, 4 Feb 2012 07:18:33 -0800 (PST) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3D79E21F8510 for ; Sat, 4 Feb 2012 07:18:32 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2beaomr06.btconnect.com with SMTP id GIO12068; Sat, 04 Feb 2012 15:18:31 +0000 (GMT) Message-ID: <010f01cce347$e6b7f360$4001a8c0@gateway.2wire.net> From: "t.petch" To: References: <20120126144944.GA64823@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> Date: Sat, 4 Feb 2012 15:18:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F2D4C46.000C, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.30.73017:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __STOCK_PHRASE_7, BODY_SIZE_600_699, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, BODY_SIZE_1000_LESS, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS, NO_URI_FOUND X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4F2D4C47.00E7,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Subject: [OPSAWG] IPv6 zoneid in SNMP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 15:18:34 -0000 [RFC4001] defines a 4 byte zone index for IPv6 with a display hint of 'd' "InetAddressIPv6z ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" DESCRIPTION "Represents a non-global IPv6 network address, together with its zone index: Octets Contents Encoding 1-16 IPv6 address network-byte order 17-20 zone index network-byte order Is this in use? I ask because draft-carpenter-6man-uri-zoneid-00.txt under discussion on the 6man list, has ABNF of ZoneID = 1*15unreserved which is a bit different (well, completely different:-( Tom Petch From j.schoenwaelder@jacobs-university.de Sat Feb 4 09:20:00 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFBC21F8551 for ; Sat, 4 Feb 2012 09:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dQc5D0QlcM3 for ; Sat, 4 Feb 2012 09:20:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E5D4E21F852A for ; Sat, 4 Feb 2012 09:19:59 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E732720C59; Sat, 4 Feb 2012 18:19:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CbUdFNVm6CgV; Sat, 4 Feb 2012 18:19:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C1FB20C53; Sat, 4 Feb 2012 18:19:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4FEC01CEAB12; Sat, 4 Feb 2012 18:19:39 +0100 (CET) Date: Sat, 4 Feb 2012 18:19:39 +0100 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20120204171938.GA16090@elstar.local> Mail-Followup-To: "t.petch" , opsawg@ietf.org References: <20120126144944.GA64823@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> <010f01cce347$e6b7f360$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010f01cce347$e6b7f360$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] IPv6 zoneid in SNMP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 04 Feb 2012 17:20:00 -0000 On Sat, Feb 04, 2012 at 03:18:37PM +0100, t.petch wrote: > [RFC4001] defines a 4 byte zone index for IPv6 with a display hint of 'd' > > "InetAddressIPv6z ::= TEXTUAL-CONVENTION > DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" > DESCRIPTION > "Represents a non-global IPv6 network address, together > with its zone index: > Octets Contents Encoding > 1-16 IPv6 address network-byte order > 17-20 zone index network-byte order > > Is this in use? > > I ask because > draft-carpenter-6man-uri-zoneid-00.txt > under discussion on the 6man list, has ABNF of > ZoneID = 1*15unreserved > which is a bit different (well, completely different:-( You can identify an interface by a number (ifIndex in SNMP land) or by a name. In other words, you can either identify an interfaces by using the result of if_nametoindex() [RFC3493] or its argument. On command lines and in URLs, systems and humans usually prefer names - internally systems usually prefer numbers (and SNMP land is typically closer to internal APIs and uses ifIndex values natively to identify interfaces). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brian.e.carpenter@gmail.com Sat Feb 4 11:27:53 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1499E21F8493 for ; Sat, 4 Feb 2012 11:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJBJtvguAW93 for ; Sat, 4 Feb 2012 11:27:52 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57B3321F848C for ; Sat, 4 Feb 2012 11:27:52 -0800 (PST) Received: by eaaq13 with SMTP id q13so299469eaa.31 for ; Sat, 04 Feb 2012 11:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lw6xpn11qMFCIW717/2kp+ZBYTKvtmj1c6Wl7mxH9UI=; b=DPtUJ0nr+ez+RC2YY4zSV/m2hg2DknPPfIFficpcv8ZNiZ//7fDNti15tGz36OUCJ9 wZvcVl42Fp4kNXK6VmIr3p/0zCLu/zi2u9jcOz6lU1mI+jgWRg/Rs54mBl4h/rj7hKuP fbZN9GroUjuB3d89pGn6GNfX+T4ku8V81uVaQ= Received: by 10.213.101.19 with SMTP id a19mr1899043ebo.90.1328383671581; Sat, 04 Feb 2012 11:27:51 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id o49sm38478604eeb.7.2012.02.04.11.27.48 (version=SSLv3 cipher=OTHER); Sat, 04 Feb 2012 11:27:50 -0800 (PST) Message-ID: <4F2D86AD.2090806@gmail.com> Date: Sun, 05 Feb 2012 08:27:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "t.petch" , opsawg@ietf.org References: <20120126144944.GA64823@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> <010f01cce347$e6b7f360$4001a8c0@gateway.2wire.net> <20120204171938.GA16090@elstar.local> In-Reply-To: <20120204171938.GA16090@elstar.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] IPv6 zoneid in SNMP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 19:27:53 -0000 On 2012-02-05 06:19, Juergen Schoenwaelder wrote: > On Sat, Feb 04, 2012 at 03:18:37PM +0100, t.petch wrote: >> [RFC4001] defines a 4 byte zone index for IPv6 with a display hint of 'd' >> >> "InetAddressIPv6z ::= TEXTUAL-CONVENTION >> DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" >> DESCRIPTION >> "Represents a non-global IPv6 network address, together >> with its zone index: >> Octets Contents Encoding >> 1-16 IPv6 address network-byte order >> 17-20 zone index network-byte order >> >> Is this in use? >> >> I ask because >> draft-carpenter-6man-uri-zoneid-00.txt >> under discussion on the 6man list, has ABNF of >> ZoneID = 1*15unreserved >> which is a bit different (well, completely different:-( > > You can identify an interface by a number (ifIndex in SNMP land) or by > a name. In other words, you can either identify an interfaces by using > the result of if_nametoindex() [RFC3493] or its argument. > > On command lines and in URLs, systems and humans usually prefer names > - internally systems usually prefer numbers (and SNMP land is > typically closer to internal APIs and uses ifIndex values natively to > identify interfaces). Exactly, and the mapping between the two forms is a host-specific function. We'll mention this in the next version of draft-carpenter-6man-uri-zoneid. Brian From rbonica@juniper.net Sun Feb 5 09:44:39 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C4821F8498 for ; Sun, 5 Feb 2012 09:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGtJB-PRU7mD for ; Sun, 5 Feb 2012 09:44:39 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A81F521F846F for ; Sun, 5 Feb 2012 09:44:38 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTy7AA/m4Qay5GJWDt/POQBFOrWc7IRk9@postini.com; Sun, 05 Feb 2012 09:44:38 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 5 Feb 2012 09:43:29 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Sun, 5 Feb 2012 12:43:28 -0500 From: Ronald Bonica To: Balaji Venkat Venkataswami , "opsawg@ietf.org" Date: Sun, 5 Feb 2012 12:43:27 -0500 Thread-Topic: I-D Action: draft-janapath-intarea-traceflow-00.txt Thread-Index: Aczb4GeAaWcXKGukTma2gO+dw9PEOwAAAVJwAhMRklA= Message-ID: <13205C286662DE4387D9AF3AC30EF456D764D55744@EMBX01-WF.jnpr.net> References: <5EC91DDA759C324DB62C5A5F7B492219394D4C2E1B@EXCH-CLUSTER-11.force10networks.com> In-Reply-To: <5EC91DDA759C324DB62C5A5F7B492219394D4C2E1B@EXCH-CLUSTER-11.force10networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D764D55744EMBX01WFjnprn_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "rgroves@microsoft.com" , "phoose@fb.com" Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 17:44:39 -0000 --_000_13205C286662DE4387D9AF3AC30EF456D764D55744EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Balaji, This draft appears to be an attempt to squeeze more information out of trac= eroute. Could you tell me what information you are probing for, beyond tha= t which can already be obtained using ICMP extensions defined in RFCs 4950 = and 5837? Why is a new approach required? If additional information is required, why = not extend the ICMP response, as RFCs 4950 and 5837 did? = Ron = /speaking as individual contributor From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Balaji Venkat Venkataswami Sent: Wednesday, January 25, 2012 11:12 PM To: opsawg@ietf.org Cc: phoose@fb.com; rgroves@microsoft.com Subject: [OPSAWG] FW: I-D Action: draft-janapath-intarea-traceflow-00.txt Hi all, Cross-posting this draft to the opsawg-group for comments / suggestions as it may be of relevance. thanks and regards, Jana and team. From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] Sent: Thursday, January 26, 2012 9:40 AM To: Balaji Venkat Venkataswami Subject: Fwd: I-D Action: draft-janapath-intarea-traceflow-00.txt --_000_13205C286662DE4387D9AF3AC30EF456D764D55744EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Balaji= ,

 =

This draft appears to be an attempt to sque= eze more information out of traceroute.  Could you tell me what inform= ation you are probing for, beyond that which can already be obtained using = ICMP extensions defined in RFCs 4950 and 5837?

 

Why is a new approach required? If additional information is required, w= hy not extend the ICMP response, as  RFCs 4950 and 5837 did?

 

         =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp; Ron

   =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;     /speaking as individual contributor<= /span>

 

 

 

 <= /span>

From: opsawg-bounces@iet= f.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Balaji Venkat Ve= nkataswami
Sent: Wednesday, January 25, 2012 11:12 PM
To: opsawg@ietf.org
Cc: phoose@fb.com; rgroves@microsoft.com
Subject: [OPSAWG] FW: I-D Action: draft-janapath-intarea-traceflow-00.= txt

 =

Hi all,

 

Cros= s-posting this draft to the opsawg-group for comments / suggestions

as it may be of relevance.

 

thanks and regards,

Jana and team.

 

From:<= /b> Bala= ji venkat Venkataswami [mailto:balajivenkat299@gmail.com]
Sent: = Thursday, January 26, 2012 9:40 AM
To: Balaji Venkat Venkataswami=
Subject: Fwd: I-D Action: draft-janapath-intarea-traceflow-00.tx= t

 

 

 

= --_000_13205C286662DE4387D9AF3AC30EF456D764D55744EMBX01WFjnprn_-- From melinda.shore@gmail.com Sun Feb 5 09:53:31 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9499121F8562 for ; Sun, 5 Feb 2012 09:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYFIk+NKxThx for ; Sun, 5 Feb 2012 09:53:30 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDC3C21F855D for ; Sun, 5 Feb 2012 09:53:30 -0800 (PST) Received: by dakl33 with SMTP id l33so4897746dak.31 for ; Sun, 05 Feb 2012 09:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RGf8fWbU4isOtLzS4eLF50de3POKt6gPNQgvcyxkObo=; b=H5gtspD9YcGZYA5gOcvEfaImXBPXyfMSoZH7VH9w60WywbKqcTIpC/MzugWe0f+rD9 /0HzhVomBEJvNTMt6xwU1mROUETJbgVpnOuIf8IRUnODtkBrbgGHAe61SuB1HNiHJJnZ e/4pnRI+rj1ebBx7sw3ZoWs/QL3X3XoaZo61Y= Received: by 10.68.225.4 with SMTP id rg4mr39515329pbc.111.1328464410608; Sun, 05 Feb 2012 09:53:30 -0800 (PST) Received: from polypro.local (66-230-86-56-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.86.56]) by mx.google.com with ESMTPS id q8sm9393311pbi.1.2012.02.05.09.53.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Feb 2012 09:53:29 -0800 (PST) Message-ID: <4F2EC218.9050003@gmail.com> Date: Sun, 05 Feb 2012 08:53:28 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.26) Gecko/20120129 Lightning/1.0b2 Thunderbird/3.1.18 MIME-Version: 1.0 To: opsawg@ietf.org References: <5EC91DDA759C324DB62C5A5F7B492219394D4C2E1B@EXCH-CLUSTER-11.force10networks.com> <13205C286662DE4387D9AF3AC30EF456D764D55744@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D764D55744@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 17:53:31 -0000 On 2/5/12 8:43 AM, Ronald Bonica wrote: > Why is a new approach required? If additional information is required, > why not extend the ICMP response, as RFCs 4950 and 5837 did? Hi, Ron: Speaking as an individual contributor and as someone who's worked on what are essentially path-coupled diagnostics, ICMP is probably not a great approach at all, given our frankly limited ability to secure both requests and responses, complete inability to route messages (it may be desirable to pin the reverse path to the forward path when sending diagnostics) and a whole host of other limitations. Using ICMP for this sort of thing is a quick hack, but I don't think it's very robust as a general-purpose diagnostic transport. Which, of course, raises the question of whether or not a general-purpose diagnostic transport is what's wanted in the first place. Melinda From internet-drafts@ietf.org Sun Feb 5 12:59:41 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7949B21F857D; Sun, 5 Feb 2012 12:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3bmlSFHJA7H; Sun, 5 Feb 2012 12:59:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52A21F854D; Sun, 5 Feb 2012 12:59:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120205205941.22814.19805.idtracker@ietfa.amsl.com> Date: Sun, 05 Feb 2012 12:59:41 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-management-stds-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 20:59:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Workin= g Group Working Group of the IETF. Title : An Overview of the IETF Network Management Standards Author(s) : Mehmet Ersue Benoit Claise Filename : draft-ietf-opsawg-management-stds-04.txt Pages : 79 Date : 2012-02-05 This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-management-stds-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsawg-management-stds-04.txt From rbonica@juniper.net Sun Feb 5 21:27:43 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D545421F848B for ; Sun, 5 Feb 2012 21:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqLVjCOBVmoq for ; Sun, 5 Feb 2012 21:27:42 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 57D6721F8495 for ; Sun, 5 Feb 2012 21:27:41 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTy9kzFfljgH7pTVe8dY+wn3KGqEqBy2Z@postini.com; Sun, 05 Feb 2012 21:27:42 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 5 Feb 2012 21:26:49 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 6 Feb 2012 00:26:48 -0500 From: Ronald Bonica To: Melinda Shore , "opsawg@ietf.org" Date: Mon, 6 Feb 2012 00:26:45 -0500 Thread-Topic: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt Thread-Index: AczkLxXtEeT8p0rxTkqkuv/CS2AKvwAXnfSw Message-ID: <13205C286662DE4387D9AF3AC30EF456D764D557C8@EMBX01-WF.jnpr.net> References: <5EC91DDA759C324DB62C5A5F7B492219394D4C2E1B@EXCH-CLUSTER-11.force10networks.com> <13205C286662DE4387D9AF3AC30EF456D764D55744@EMBX01-WF.jnpr.net> <4F2EC218.9050003@gmail.com> In-Reply-To: <4F2EC218.9050003@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 05:27:44 -0000 Hi Melinda, It seems that two sets of tools are required. The first set of tools offers= a general view of the device. These tools give operators access to fibs, r= ibs, mibs and everything else you can think of. CLI, NETCONF and SNMP occup= y this space. Those protocols already offer decent authentication capabilit= ies. The seconds set of tools give operators an opportunity to directly observe = forwarding behavior. Ping and traceroute fit the bill here. Because these t= ools offer relatively little information, they can be secured on an all-or-= none bases (either you filter selected ICMP messages or you don't). Am I missing a third set of tools? My question remains: What information is draft-janpapath trying to obtain t= hat isn't accessible already? Ron > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Melinda Shore > Sent: Sunday, February 05, 2012 12:53 PM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow- > 00.txt >=20 > On 2/5/12 8:43 AM, Ronald Bonica wrote: > > Why is a new approach required? If additional information is > required, > > why not extend the ICMP response, as RFCs 4950 and 5837 did? >=20 > Hi, Ron: >=20 > Speaking as an individual contributor and as someone who's worked on > what are essentially path-coupled diagnostics, ICMP is probably not > a great approach at all, given our frankly limited ability to secure > both requests and responses, complete inability to route messages > (it may be desirable to pin the reverse path to the forward path when > sending diagnostics) and a whole host of other limitations. Using > ICMP for this sort of thing is a quick hack, but I don't think it's > very robust as a general-purpose diagnostic transport. Which, of > course, raises the question of whether or not a general-purpose > diagnostic transport is what's wanted in the first place. >=20 > Melinda >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Sun Feb 5 22:01:27 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDA621F858E for ; Sun, 5 Feb 2012 22:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeBgbgS6IFNK for ; Sun, 5 Feb 2012 22:01:26 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67E7821F8589 for ; Sun, 5 Feb 2012 22:01:26 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1767275pbc.31 for ; Sun, 05 Feb 2012 22:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kTfVsPAldhtxwBk2nKiWmkO4yxFxobskUNI+avJmuHQ=; b=cXFhdQe7Sjz0Li4kqL/PCGdaoXrNojXzNXNf0+36SOVBKR6wiJB8Tu+TsQmxvIqACU L3udSZIlFvXae8mC4Idsq/1XvweXV8h6cKHOMsIIMwQgzm0Ms5yKwifzrrHI+qdDiuyj kJ98//EmkaCocY2oVbRkeSbedYpxvStANwWH4= Received: by 10.68.212.161 with SMTP id nl1mr44623553pbc.38.1328508086237; Sun, 05 Feb 2012 22:01:26 -0800 (PST) Received: from polypro.local (66-230-86-56-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.86.56]) by mx.google.com with ESMTPS id i10sm36835153pbg.10.2012.02.05.22.01.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Feb 2012 22:01:25 -0800 (PST) Message-ID: <4F2F6CB3.9000109@gmail.com> Date: Sun, 05 Feb 2012 21:01:23 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.26) Gecko/20120129 Lightning/1.0b2 Thunderbird/3.1.18 MIME-Version: 1.0 To: Ronald Bonica References: <5EC91DDA759C324DB62C5A5F7B492219394D4C2E1B@EXCH-CLUSTER-11.force10networks.com> <13205C286662DE4387D9AF3AC30EF456D764D55744@EMBX01-WF.jnpr.net> <4F2EC218.9050003@gmail.com> <13205C286662DE4387D9AF3AC30EF456D764D557C8@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D764D557C8@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 06:01:27 -0000 On 2/5/12 8:26 PM, Ronald Bonica wrote: > It seems that two sets of tools are required. The first set of tools offers a general view of the device. These tools give operators access to fibs, ribs, mibs and everything else you can think of. CLI, NETCONF and SNMP occupy this space. Those protocols already offer decent authentication capabilities. > The seconds set of tools give operators an opportunity to directly observe forwarding behavior. Ping and traceroute fit the bill here. Because these tools offer relatively little information, they can be secured on an all-or-none bases (either you filter selected ICMP messages or you don't). > Am I missing a third set of tools? Maybe. Traceroute is an interesting case because you're inferring router behavior or path characteristics from observed side-effects. When something goes wrong you really don't know why. If there's an asymmetry in the path it's very possible for everything to be copacetic in one direction but not in the other, and it's sometimes extremely difficult to differentiate the two. But aside from that we were interested in the ability to trigger diagnostics and provide some flexibility in what was returned. > My question remains: What information is draft-janpapath trying to obtain that isn't accessible already? It looks like they're interested in some of the same things we were. A packet goes into a network and disappears. What happened? Quite often it's the result of some sort of policy decision inside a router, or, heaven help us, firewall. As ACLs get increasingly hairy (research results show that literally 99% of firewall rulesets contain errors) it would be excellent to have a tool that shows you what rules were triggered at which device in a network. Better still is to have a reasonably general (but not unreasonably general) tool to trigger or collect diagnostics in a network. I don't love this draft (I think it's excessively blithe about transport) but I think it represents a real problem, and one for which we've seen interest from the community. Melinda From rbonica@juniper.net Sun Feb 5 22:25:33 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B4221F8503 for ; Sun, 5 Feb 2012 22:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWN1WdxIf2nk for ; Sun, 5 Feb 2012 22:25:33 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 2296521F84FC for ; Sun, 5 Feb 2012 22:25:32 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTy9yW3WtKgDFQKfZ3d+R9xUqvi/QyKwi@postini.com; Sun, 05 Feb 2012 22:25:32 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 5 Feb 2012 22:23:05 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 6 Feb 2012 01:23:01 -0500 From: Ronald Bonica To: Melinda Shore Date: Mon, 6 Feb 2012 01:22:59 -0500 Thread-Topic: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt Thread-Index: AczklNerZDSxXcJ5ST+N3+jNadlx3gAAogvg Message-ID: <13205C286662DE4387D9AF3AC30EF456D764D557DA@EMBX01-WF.jnpr.net> References: <5EC91DDA759C324DB62C5A5F7B492219394D4C2E1B@EXCH-CLUSTER-11.force10networks.com> <13205C286662DE4387D9AF3AC30EF456D764D55744@EMBX01-WF.jnpr.net> <4F2EC218.9050003@gmail.com> <13205C286662DE4387D9AF3AC30EF456D764D557C8@EMBX01-WF.jnpr.net> <4F2F6CB3.9000109@gmail.com> In-Reply-To: <4F2F6CB3.9000109@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 06:25:33 -0000 > -----Original Message----- > From: Melinda Shore [mailto:melinda.shore@gmail.com] > Sent: Monday, February 06, 2012 1:01 AM > To: Ronald Bonica > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow- > 00.txt [snip] >=20 >=20 > I don't love this draft (I think it's excessively blithe about > transport) but I think it represents a real problem, and one for which > we've seen interest from the community. >=20 > Melinda OK. I'll bite. Let's take some time to articulate that problem. We might to= do that on the mailing list before jumping too deeply into the solution. Ron From balajivenkat@force10networks.com Tue Feb 7 01:42:08 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1366D21F871C for ; Tue, 7 Feb 2012 01:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TcLypZwPj1D for ; Tue, 7 Feb 2012 01:42:06 -0800 (PST) Received: from mx.force10networks.com (maa.force10networks.com [59.163.202.254]) by ietfa.amsl.com (Postfix) with ESMTP id 33A1E21F870B for ; Tue, 7 Feb 2012 01:42:05 -0800 (PST) Received: from EXCH-CLUSTER-11.force10networks.com ([10.16.127.20]) by exch7-maa-fe.force10networks.com ([10.16.126.10]) with mapi; Tue, 7 Feb 2012 15:12:02 +0530 From: Balaji Venkat Venkataswami To: "rbonica@juniper.net" , "melinda.shore@gmail.com" , "opsawg@ietf.org" Date: Tue, 7 Feb 2012 15:11:52 +0530 Thread-Topic: draft-janapath-intarea-traceflow-00.txt Thread-Index: AczlfLkE1nZCVZOrTEy9ic9di79gaw== Message-ID: <5EC91DDA759C324DB62C5A5F7B492219394D8353BF@EXCH-CLUSTER-11.force10networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: DfyJ DpmF Du0g K3+k S6cd VP+h YLVU Y/bu gJBy jcZO ksp+ rLPb v9vp z1TI 3OoM 4NnC; 5; bQBlAGwAaQBuAGQAYQAuAHMAaABvAHIAZQBAAGcAbQBhAGkAbAAuAGMAbwBtADsAbwBwAHMAYQB3AGcAQABpAGUAdABmAC4AbwByAGcAOwBwAGgAbwBvAHMAZQBAAGYAYgAuAGMAbwBtADsAcgBiAG8AbgBpAGMAYQBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA7AHIAZwByAG8AdgBlAHMAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {9DD620E2-12F9-43CF-943B-C09FB7098FCF}; YgBhAGwAYQBqAGkAdgBlAG4AawBhAHQAQABmAG8AcgBjAGUAMQAwAG4AZQB0AHcAbwByAGsAcwAuAGMAbwBtAA==; Tue, 07 Feb 2012 09:41:53 GMT; ZAByAGEAZgB0AC0AagBhAG4AYQBwAGEAdABoAC0AaQBuAHQAYQByAGUAYQAtAHQAcgBhAGMAZQBmAGwAbwB3AC0AMAAwAC4AdAB4AHQA x-cr-puzzleid: {9DD620E2-12F9-43CF-943B-C09FB7098FCF} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5EC91DDA759C324DB62C5A5F7B492219394D8353BFEXCHCLUSTER11_" MIME-Version: 1.0 Cc: "phoose@fb.com" , Balaji Venkat Venkataswami Subject: [OPSAWG] draft-janapath-intarea-traceflow-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 09:42:08 -0000 --_000_5EC91DDA759C324DB62C5A5F7B492219394D8353BFEXCHCLUSTER11_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi ron, Melinda, In summary here is a list of things that the draft solves... a) The aim is to trace the path through the network for a specific flow, th= rough the member links for Multipathing (LAG at L2 and ECMP at L3). Hence m= ay need a more generic processing at intermediate nodes, which is not curre= ntly part of ICMP mechanisms. The packet's payload contains the flow inform= ation which is then inspected and a packet is built as it would have ingres= sed the device and the said packet is sent to the hardware. The said packet= is then trapped prior to actual forwarding and the forwarding result from = the hardware analyzed. This is not done in ICMP and a more control planish = approach is taken to send the response back to the Originator. The incoming packet has a payload which is the actual packet to be traced= , and the results are for this payload, rather than the incoming packet its= elf, and this would need the receiver to parse the payload and then try to = check the hardware for the embedded flow and calculate the egress port deta= ils. b) It is possible in this draft to have the response sent back to a node di= fferent from the one that originated the request. This to some extent allow= s us to trace a specific direction without depending on the reverse path, t= hough it now depends on the path to the management station to be up and wor= king. Please see the Indirect method in the draft for more details. c) Fan out as an option, where the result would be to indicate all the avai= lable paths to the destination and also to trace all the paths available to= the destination This would be very much useful for an NMS collecting detai= ls as it would see the entire fan-out rather than just a limited picture wh= ich is what the 2 RFCs provide. In general the requirement is similar to the reason why we tend to use hpin= g over ping, it allows us to test all of the possible paths, this is essent= ially the traceroute compliment, once we've identified that there is a prob= lem, we need to find it's source, today there's nothing that can do this wh= en ECMP/LAG is added to the mix. d) calculate more information about the paths and the status of the egress = port While it is possible that all of these can be added as additional objects= in ICMP, we feel that a new application would be a better choice 1) Routers which are unaware of these should be able to forward it as regul= ar data packet. As we send the original packet in the payload only those de= vices that recognize Traceflow packets will evaluate the payload and send t= o the Originator or the Indirect Originator the set of details required. Al= so we catch devices in the intermediate stages which do not support this fe= ature. 2) The processing that is required is significantly different from regular = ICMP and hence a new application may be a better choice 3) The mechanisms to trap the packet to the CPU is not the standard set of = ICMP error messages Ron's Comments : This draft appears to be an attempt to squeeze more information out of trac= eroute. Could you tell me what information you are probing for, beyond tha= t which can already be obtained using ICMP extensions defined in RFCs 4950 = and 5837? Why is a new approach required? If additional information is required, why = not extend the ICMP response, as RFCs 4950 and 5837 did? With respect to the draft, it is a more natural reflection of th= e decisions made on the forwarding plane (after consultation of the hardwar= e tables take place) that is sought to be highlighted. When a packet comes = into a device, the normal thing we would do in the case of an ICMP response= is to ignore the hardware decision to be taken and take a more control pla= nish approach to the packet and find out which interface it was to go out o= n through mimicking the hardware which might not be essentially the correct= result. With respect to getting both a LAG member on which the packet is t= o be sent on or a path in the set of links that constitute an ECMP set of p= aths this packet which is sought to be sent out is not thrust into the hard= ware to make out the decision taken (If at all the packet is to be forwarde= d or not) and the exact LAG member or ECMP member on which it is to be sent= . Another aspect is the fan-out option which is missing in the ICMP extension= s. Considering that ICMP messages are filtered a fan-out may not be impleme= ntable in the current scheme of things if ICMP messages are turned off or a= re filtered with respect to their forwarding. Aspects like the Utilization anomaly TLV and the extensions to the result T= LV, ACL decisions as a result of certain policies etc... are not taken into= account in the RFCs quoted. Also the original packet which is sought to be= forwarded is carried in the payload and decisions taken as per that packet= than the outer header packet which is sought to be taken into account in t= he regular TRACEROUTE case. Also aspects like the Hash algorithm to be used and the fields taken into a= ccount into this hash algorithm are not carried back to the Originator of s= ay a TRACEROUTE. As melinda suggested the path coupled properties are the h= ighlight of this draft. ICMP extensions are not path coupled as the story g= oes. We agree that the ICMP extensions in the second RFC quoted (5837) do h= ave information that necessarily coincides with the information w.r.t LAG a= nd ECMP. But the actual hardware plane is not tested with respect to the TR= ACEROUTE. It is thus a more control plane mimic of the hardware which may n= ot be accurate for all practical purposes. Melinda's comments : Speaking as an individual contributor and as someone who's worked on what a= re essentially path-coupled diagnostics, ICMP is probably not a great appro= ach at all, given our frankly limited ability to secure both requests and r= esponses, complete inability to route messages (it may be desirable to pin = the reverse path to the forward path when sending diagnostics) and a whole = host of other limitations. Using ICMP for this sort of thing is a quick ha= ck, but I don't think it's very robust as a general-purpose diagnostic tran= sport. Which, of course, raises the question of whether or not a general-p= urpose diagnostic transport is what's wanted in the first place. We agree. As far as the general purpose diagnostic transport is = concerned it is kind of out of scope of this document. It seems that two sets of tools are required. The first set of tools offers= a general view of the device. These tools give operators access to fibs, r= ibs, mibs and everything else you can think of. CLI, NETCONF and SNMP occup= y this space. Those protocols already offer decent authentication capabilit= ies. > The seconds set of tools give operators an opportunity to directly observ= e forwarding behavior. Ping and traceroute fit the bill here. Because these= tools offer relatively little information, they can be secured on an all-o= r-none bases (either you filter selected ICMP messages or you don't). > Am I missing a third set of tools? Maybe. Traceroute is an interesting case because you're inferring router b= ehavior or path characteristics from observed side-effects. When something = goes wrong you really don't know why. If there's an asymmetry in the path = it's very possible for everything to be copacetic in one direction but not = in the other, and it's sometimes extremely difficult to differentiate the t= wo. Copacetic means in excellent order. This kind of differentiation= is currently NOT possible and would be out of scope on this document. But aside from that we were interested in the ability to trigger diagnostic= s and provide some flexibility in what was returned. > My question remains: What information is draft-janpapath trying to obtain= that isn't accessible already? It looks like they're interested in some of the same things we were. A pack= et goes into a network and disappears. What happened? Quite often it's th= e result of some sort of policy decision inside a router, or, heaven help u= s, firewall. As ACLs get increasingly hairy (research results show that li= terally 99% of firewall rulesets contain errors) it would be excellent to h= ave a tool that shows you what rules were triggered at which device in a ne= twork. Better still is to have a reasonably general (but not unreasonably = general) tool to trigger or collect diagnostics in a network. Agree. I don't love this draft (I think it's excessively blithe about transport) b= ut I think it represents a real problem, and one for which we've seen inter= est from the community. How do we get to a less blithiness on the transport ? Could you = please elucidate this ? thanks and regards, Jana and team --_000_5EC91DDA759C324DB62C5A5F7B492219394D8353BFEXCHCLUSTER11_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi ron, Melinda,

In summary here is a list of things that the draft solves= ...

a) The aim is to trace the path through the network for a specific flow, through the member links for Multipathing (LAG at L2 and ECM= P at L3). Hence may need a more generic processing at intermediate nodes, which = is not currently part of ICMP mechanisms. The packet's payload contains the fl= ow information which is then inspected and a packet is built as it would have ingressed the device and the said packet is sent to the hardware. The said packet is then trapped prior to actual forwarding and the forwarding result from the hardware analyzed. This is not done in ICMP and a more control pla= nish approach is taken to send the response back to the Originator. <= /span>

 

  The incoming packet has a payload wh= ich is the actual packet to be traced, and the results are for this payload, ra= ther than the incoming packet itself, and this would need the receiver to parse = the payload and then try to check the hardware for the embedded flow and calcul= ate the egress port details.

b) It is possible in this draft to have the response sent back to a node different from the one that originated the request. This to some extent allows us to trace a specific direction withou= t depending on the reverse path, though it now depends on the path to the management station to be up and working. Please see the Indirect method in = the draft for more details.  

c) Fan out as an option, where the result w= ould be to indicate all the available paths to the destination and also to trace= all the paths available to the destination This would be very much useful for a= n NMS collecting details as it would see the entire fan-out rather than just = a limited picture which is what the 2 RFCs provide.

In general the requirement is similar to the reason why w= e tend to use hping over ping, it allows us to test all of the possible paths= , this is essentially the traceroute compliment, once we've identified that t= here is a problem, we need to find it's source, today there's nothing that can d= o this when ECMP/LAG is added to the mix.<= /o:p>

d) calculate more information about the pat= hs and the status of the egress port

  While it is possible that all of the= se can be added as additional objects in ICMP, we feel that a new application would be a better choice

1) Routers which are unaware of these shoul= d be able to forward it as regular data packet. As we send the original packet i= n the payload only those devices that recognize Traceflow packets will evalua= te the payload and send to the Originator or the Indirect Originator the set o= f details required. Also we catch devices in the intermediate stages which do= not support this feature.

2) The processing that is required is significantly different from regular ICMP and hence a new application may b= e a better choice

3) The mechanisms to trap the packet to the= CPU is not the standard set of ICMP error messages

 <= /span>

 <= /span>

 <= /span>

Ron's Comments :

 <= /span>

This draft appears to be an attempt to squeeze more information out of tracerout= e.  Could you tell me what information you are probing for, beyond that which c= an already be obtained using ICMP extensions defined in RFCs 4950 and 5837?

 

Why is a new approach required? If additional information is required, why not extend the ICMP response, as  RFCs 4950 and 5837 did?

 

<RESPONSE> W= ith respect to the draft, it is a more natural reflection of the decisions made= on the forwarding plane (after consultation of the hardware tables take place) that is sought to be highlighted. When a packet comes into a device, the no= rmal thing we would do in the case of an ICMP response is to ignore the hardware decision to be taken and take a more control planish approach to the packet= and find out which interface it was to go out on through mimicking the hardware which might not be essentially the correct result. With respect to getting = both a LAG member on which the packet is to be sent on or a path in the set of l= inks that constitute an ECMP set of paths this packet which is sought to be sent= out is not thrust into the hardware to make out the decision taken (If at all t= he packet is to be forwarded or not) and the exact LAG member or ECMP member o= n which it is to be sent.

Another aspect is = the fan-out option which is missing in the ICMP extensions. Considering that IC= MP messages are filtered a fan-out may not be implementable in the current sch= eme of things if ICMP messages are turned off or are filtered with respect to t= heir forwarding.

Aspects like the Utilization anomaly TLV and the extensions to the result TLV, ACL decisions= as a result of certain policies etc... are not taken into account in the RFCs quoted. Also the original packet which is sought to be forwarded is carried= in the payload and decisions taken as per that packet than the outer header pa= cket which is sought to be taken into account in the regular TRACEROUTE case.

Also aspects like = the Hash algorithm to be used and the fields taken into account into this hash algorithm are not carried back to the Originator of say a TRACEROUTE. As melinda suggested the path coupled properties are the highlight of this dra= ft. ICMP extensions are not path coupled as the story goes. We agree that the I= CMP extensions in the second RFC quoted (5837) do have information that necessa= rily coincides with the information w.r.t LAG and ECMP. But the actual hardware plane is not tested with respect to the TRACEROUTE. It is thus a more contr= ol plane mimic of the hardware which may not be accurate for all practical purposes.

Melinda's comments :

 

Speaking as an individual contributor and as someone who's worked on what are essentially path-coupled diagnostics, ICMP is probably not a great approach= at all, given our frankly limited ability to secure both requests and response= s, complete inability to route messages (it may be desirable to pin the revers= e path to the forward path when sending diagnostics) and a whole host of othe= r limitations.  Using ICMP for this sort of thing is a quick hack, but I= don't think it's very robust as a general-purpose diagnostic transport.  Whi= ch, of course, raises the question of whether or not a general-purpose diagnostic = transport is what's wanted in the first place.

 

<RESPONSE> W= e agree. As far as the general purpose diagnostic transport is concerned it i= s kind of out of scope of this document.

It seems that two sets of tools are required. The first set of tools offers a = general view of the device. These tools give operators access to fibs, ribs, mibs a= nd everything else you can think of. CLI, NETCONF and SNMP occupy this space. Those protocols already offer decent authentication capabilities.

 

> The seconds set of tools give operators an opportunity to directly observe forwarding behavior. Ping and traceroute fit the bill here. Because these t= ools offer relatively little information, they can be secured on an all-or-none bases (either you filter selected ICMP messages or you don't).

> Am I missing a third set of tools?

 

Maybe.  Traceroute is an interesting case because you're inferring router behavior = or path characteristics from observed side-effects. When something goes wrong = you really don't know why.  If there's an asymmetry in the path it's very = possible for everything to be copacetic in one direction but not in the other, and i= t's sometimes extremely difficult to differentiate the two.

 

<RESPONSE> Copacetic means in excellent order. This kind of differentiation is currently NOT possible and would be out of scope on this document.

 

But aside from that we were interested in the ability to trigger diagnostics an= d provide some flexibility in what was returned.

 

> My question remains: What information is draft-janpapath trying to obtain t= hat isn't accessible already?

 

It looks like they're interested in some of the same things we were. A packet = goes into a network and disappears.  What happened?  Quite often it's = the result of some sort of policy decision inside a router, or, heaven help us, firewall. = ; As ACLs get increasingly hairy (research results show that literally 99% of firewal= l rulesets contain errors) it would be excellent to have a tool that shows yo= u what rules were triggered at which device in a network.  Better still = is to have a reasonably general (but not unreasonably general) tool to trigger or collect diagnostics in a network.

 

<RESPONSE> Agree.

 

I don't love this draft (I think it's excessively blithe about transport) but= I think it represents a real problem, and one for which we've seen interest f= rom the community.

 

<RESPONSE> H= ow do we get to a less blithiness on the transport ? Could you please elucidat= e this ?<= /span>

thanks and regards,

Jana and team

--_000_5EC91DDA759C324DB62C5A5F7B492219394D8353BFEXCHCLUSTER11_-- From j.schoenwaelder@jacobs-university.de Tue Feb 7 05:40:35 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273F821F8795; Tue, 7 Feb 2012 05:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7tC9Ao0k8hX; Tue, 7 Feb 2012 05:40:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4537D21F8751; Tue, 7 Feb 2012 05:40:34 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97B3320C83; Tue, 7 Feb 2012 14:40:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Xn4NKNHL3xc9; Tue, 7 Feb 2012 14:40:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC4D920C82; Tue, 7 Feb 2012 14:40:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AE56A1CEEB27; Tue, 7 Feb 2012 14:40:15 +0100 (CET) Date: Tue, 7 Feb 2012 14:40:15 +0100 From: Juergen Schoenwaelder To: Christopher LILJENSTOLPE Message-ID: <20120207134015.GB24691@elstar.local> Mail-Followup-To: Christopher LILJENSTOLPE , ops-area@ietf.org, opsawg@ietf.org References: <6731655C-241E-40F2-BE9A-DFFA6FE80B9B@cdl.asgaard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6731655C-241E-40F2-BE9A-DFFA6FE80B9B@cdl.asgaard.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org, ops-area@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] draft-ietf-opsawg-management-stds-04 - is there consensus? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:40:35 -0000 On Mon, Feb 06, 2012 at 03:45:37PM -0800, Christopher LILJENSTOLPE wrote: > Greetings, > > We've WGLC'd this document twice, and each time we've gotten submissions and suggestions. The authors have updated the text based on the last WGLC responses. As most of the response has been fairly positive, we would like to move this version of the document to the IESG for approval. If anyone has serious objections - please raise them on the list within 72 hours from now (say midnight Friday, 10 Feb, UTC). Silence is acceptance :) > I looked through the diffs and they seem to be fine. Before this document goes to the IESG, we should perhaps clear the open issues listed in Appendix C: o What is the status of draft-ietf-opsawg-oam-overview? It expired on November 2011. o Decide what to do with following references: o What is the status of draft-ietf-ipfix-export-per-sctp-stream-08? (RFC Ed Queue for 569 days, depends on draft-ietf-tsvwg-sctp-strrst-13.txt awaiting author action) o What is the status of draft-ietf-ipfix-configuration-model-10? (RFC Ed Queue for 198 days, depends on draft-ietf-ipfix-psamp-mib awaiting AD-Go-Ahead::External Party) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Tue Feb 7 05:56:20 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75B321F87D3; Tue, 7 Feb 2012 05:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C86fBoK9CnYy; Tue, 7 Feb 2012 05:56:20 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id BF52F21F87D2; Tue, 7 Feb 2012 05:56:19 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q17DuF4V019983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2012 14:56:15 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q17DuBOf005984; Tue, 7 Feb 2012 14:56:15 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 14:56:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Feb 2012 14:56:13 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64035E00DF@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120207134015.GB24691@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] draft-ietf-opsawg-management-stds-04 - is there consensus? Thread-Index: Aczlnhc58deOZbcfTyeMJdQ2pxj+BgAAGSNw References: <6731655C-241E-40F2-BE9A-DFFA6FE80B9B@cdl.asgaard.org> <20120207134015.GB24691@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Christopher LILJENSTOLPE" X-OriginalArrivalTime: 07 Feb 2012 13:56:14.0025 (UTC) FILETIME=[4150E390:01CCE5A0] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2871 X-purgate-ID: 151667::1328622975-00007EDF-23207F6B/0-0/0-0 Cc: opsawg@ietf.org, ops-area@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] draft-ietf-opsawg-management-stds-04 - is there consensus? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:56:20 -0000 Hi Juergen, thank you for the positive feedback. Concerning draft-ietf-ipfix-export-per-sctp-stream and draft-ietf-ipfix-configuration-model, I asked already our AD with an email after the submission of our draft. They seem=20 to be underway and will be available at the latest during the=20 publication of draft-ietf-opsawg-management-stds as=20 Informational RFC. RFC Editor can then replace the I-D=20 reference with the corresponding RFC reference. Concerning draft-ietf-opsawg-oam-overview I had to delete the=20 corresponding text, as it expired already in November 2011 and I did not get any answer to my earlier mail to the authors. I assume it is not going to be finalized soon.=20 May be OPSAWG chairs know more than I do and can say a few=20 clarifying words.=20 Cheers,=20 Mehmet=20 > -----Original Message----- > From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On Behalf Of > ext Juergen Schoenwaelder > Sent: Tuesday, February 07, 2012 2:40 PM > To: Christopher LILJENSTOLPE > Cc: opsawg@ietf.org; ops-area@ietf.org > Subject: Re: [OPS-AREA] draft-ietf-opsawg-management-stds-04 - is there > consensus? >=20 > On Mon, Feb 06, 2012 at 03:45:37PM -0800, Christopher LILJENSTOLPE wrote: > > Greetings, > > > > We've WGLC'd this document twice, and each time we've gotten submissions > and suggestions. The authors have updated the text based on the last WGLC > responses. As most of the response has been fairly positive, we would like to move > this version of the document to the IESG for approval. If anyone has serious > objections - please raise them on the list within 72 hours from now (say midnight > Friday, 10 Feb, UTC). Silence is acceptance :) > > >=20 > I looked through the diffs and they seem to be fine. Before this > document goes to the IESG, we should perhaps clear the open issues > listed in Appendix C: >=20 > o What is the status of draft-ietf-opsawg-oam-overview? It expired > on November 2011. >=20 > o Decide what to do with following references: >=20 > o What is the status of draft-ietf-ipfix-export-per-sctp-stream-08? > (RFC Ed Queue for 569 days, depends on > draft-ietf-tsvwg-sctp-strrst-13.txt awaiting author action) >=20 > o What is the status of draft-ietf-ipfix-configuration-model-10? > (RFC Ed Queue for 198 days, depends on draft-ietf-ipfix-psamp-mib > awaiting AD-Go-Ahead::External Party) >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From melinda.shore@gmail.com Wed Feb 8 17:42:31 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621EF21F84B5 for ; Wed, 8 Feb 2012 17:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z55-935+zLUY for ; Wed, 8 Feb 2012 17:42:30 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC59F21F8493 for ; Wed, 8 Feb 2012 17:42:30 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1899542obb.31 for ; Wed, 08 Feb 2012 17:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UQPzxqGDBuGk9d9Yrw2cUDaqWOPdEQmkETQ3FV9uMqo=; b=PiqLcxMMbpa4PwrMKCN+w6dV++fwPjPU4HHJI5ryi20Nr9ht8hBMRFdLu4axmHNRPi kg2SQ/1SJlRe4CHs3p+Mq5jEMGn3ENlQsX8BxA98uo+MFcMXNN/jXxGaPnmc9f4z/bZe ar3rMcm531xYQlHOXlngMbFwHFpnrI6/x2tSI= Received: by 10.50.6.194 with SMTP id d2mr37842266iga.24.1328751750316; Wed, 08 Feb 2012 17:42:30 -0800 (PST) Received: from [137.229.12.236] (drake.swits.alaska.edu. [137.229.12.236]) by mx.google.com with ESMTPS id 5sm1997176ibe.8.2012.02.08.17.42.29 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 17:42:29 -0800 (PST) Message-ID: <4F332485.4040901@gmail.com> Date: Wed, 08 Feb 2012 16:42:29 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Balaji Venkat Venkataswami References: <5EC91DDA759C324DB62C5A5F7B492219394D4C2E1B@EXCH-CLUSTER-11.force10networks.com> <13205C286662DE4387D9AF3AC30EF456D764D55744@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D764D55744@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 01:42:31 -0000 Hi, Balaji: I think this is where we stand with the draft: 1. There's a good chance there's a good idea lurking within all those TLV packetization diagrams 2. Unfortunately it's not presented very well and would need substantial revision. Specifically we'd really like to see a strong problem statement and a framework before diving into protocol details. And this is my *personal* bugaboo but wow, I really do not like seeing packet formats getting more attention than messaging and protocol operations. 3, In the best of all possible worlds you'd be able to find someone to work with who's been through the process and has experience writing successful IETF documents - at least we'd have a better basis for discussion 4. I hope this is with the understanding that even if you go ahead and produce a clearer document that doesn't mean that it necessarily becomes a working group item. But at least we'd have, as I mentioned, a better basis for further consideration. As a sort of corollary to all that, is there someone on the list who'd like to help clarify this document? Thanks, Melinda -- Melinda Shore melinda.shore@gmail.com Software longa, hardware brevis From balajivenkat@force10networks.com Wed Feb 8 21:01:27 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7E121E8023 for ; Wed, 8 Feb 2012 21:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PVp9RvYKn2l for ; Wed, 8 Feb 2012 21:01:27 -0800 (PST) Received: from mx.force10networks.com (maa.force10networks.com [59.163.202.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB1221E802B for ; Wed, 8 Feb 2012 21:01:26 -0800 (PST) Received: from EXCH-CLUSTER-11.force10networks.com ([10.16.127.20]) by exch7-maa-fe.force10networks.com ([10.16.126.10]) with mapi; Thu, 9 Feb 2012 10:31:21 +0530 From: Balaji Venkat Venkataswami To: Melinda Shore Date: Thu, 9 Feb 2012 10:31:19 +0530 Thread-Topic: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt Thread-Index: AczmzBeqhvVzlasKSDaB/s9UtCjFPQAG577Q Message-ID: <5EC91DDA759C324DB62C5A5F7B492219394D95821C@EXCH-CLUSTER-11.force10networks.com> References: <5EC91DDA759C324DB62C5A5F7B492219394D4C2E1B@EXCH-CLUSTER-11.force10networks.com> <13205C286662DE4387D9AF3AC30EF456D764D55744@EMBX01-WF.jnpr.net> <4F332485.4040901@gmail.com> In-Reply-To: <4F332485.4040901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:01:27 -0000 Hi Melinda, Thank you for your perusal of the document and subsequent comments. We will strive to present this in a more clearer fashion taking into accoun= t the points you have mentioned. thanks and regards, balaji venkat -----Original Message----- From: Melinda Shore [mailto:melinda.shore@gmail.com]=20 Sent: Thursday, February 09, 2012 7:12 AM To: Balaji Venkat Venkataswami Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt Hi, Balaji: I think this is where we stand with the draft: 1. There's a good chance there's a good idea lurking within all those TLV packetization diagrams 2. Unfortunately it's not presented very well and would need substantial revision. Specifically we'd really like to see a strong problem statement and a framework before diving into protocol details. And this is my *personal* bugaboo but wow, I really do not like seeing packet formats getting more attention than messaging and protocol operations. 3, In the best of all possible worlds you'd be able to find someone to work with who's been through the process and has experience writing successful IETF documents - at least we'd have a better basis for discussion 4. I hope this is with the understanding that even if you go ahead and produce a clearer document that doesn't mean that it necessarily becomes a working group item. But at least we'd have, as I mentioned, a better basis for further consideration. As a sort of corollary to all that, is there someone on the list who'd like to help clarify this document? Thanks, Melinda --=20 Melinda Shore melinda.shore@gmail.com Software longa, hardware brevis From bnordman@lbl.gov Wed Feb 8 23:36:34 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC09421F85AF; Wed, 8 Feb 2012 23:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.29 X-Spam-Level: X-Spam-Status: No, score=-5.29 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAJIjEp6JXJe; Wed, 8 Feb 2012 23:36:34 -0800 (PST) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 331FE21F8564; Wed, 8 Feb 2012 23:36:33 -0800 (PST) X-Ironport-SBRS: 3.8 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusCANJ2M0/RVdI0imdsb2JhbABAA4JNnCgBAYgYAYgKCCIBAQEKCQ0HEgYjgXcUAoEEB10SAQUBIgESCAEZh2ObbgqdHotSHwQJBhseg1kFGmIMCheDIgSIRoxnjh49hCM X-IronPort-AV: E=Sophos;i="4.73,388,1325491200"; d="scan'208";a="64566023" Received: from mail-pz0-f52.google.com ([209.85.210.52]) by ironport4.lbl.gov with ESMTP; 08 Feb 2012 23:36:32 -0800 Received: by mail-pz0-f52.google.com with SMTP id o14so1629566dad.39 for ; Wed, 08 Feb 2012 23:36:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.105 with SMTP id k9mr2966365pbv.121.1328772992662; Wed, 08 Feb 2012 23:36:32 -0800 (PST) Received: by 10.142.166.15 with HTTP; Wed, 8 Feb 2012 23:36:32 -0800 (PST) Date: Wed, 8 Feb 2012 23:36:32 -0800 Message-ID: From: Bruce Nordman To: eman mailing list , ops-area@ietf.org, opsawg@ietf.org Content-Type: multipart/alternative; boundary=f46d04190db436faf904b883125b X-Gm-Message-State: ALoCoQk8aX6hjx9gaJFeAqUx+GXzVnYUTW7FRXqQayrL9kJlXvfLoUJtmA08/zha9R2jt8sPTC7G Subject: [OPSAWG] Power Locator X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 07:36:35 -0000 --f46d04190db436faf904b883125b Content-Type: text/plain; charset=ISO-8859-1 At the last IETF I presented a draft on the concept of a "Power Locator" feature. I am interested to know if anyone knows of any relevant IP claims for what the RFC addresses. The draft is at: http://datatracker.ietf.org/doc/draft-nordman-power-locator/ The slides are at: http://www.ietf.org/proceedings/82/slides/opsarea-1.pdf Minutes of the presentation are at: http://www.ietf.org/proceedings/82/minutes/opsarea.txt The abstract in the RFC is: Power Locator draft-nordman-power-locator-00 Abstract This specification addresses how to request that a device should enter a "power locator" mode for a limited period of time. The mode involves a device cycling between a low and high power level in a predictable manner so that a power metering device upstream in the power distribution system can sense the signal and so determine where the device draws its power from. This will be useful in many types of buildings, particularly data centers and large commercial buildings. This draft addresses operation of the device carrying out the request, but not detailed operation of the device that makes the request and interprets the results. This draft is an initial discussion document to generate feedback and improvement. Thank you, --Bruce -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --f46d04190db436faf904b883125b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At the last IETF I presented a draft on the concept of a "Power Locato= r" feature.
I am interested to know if anyone knows of any relevant= IP claims for what
the RFC addresses.

The draft is at:
=A0 http= ://datatracker.ietf.org/doc/draft-nordman-power-locator/

The slides are at:
=A0 http://www.ietf.org/proceedings/82/slides/opsarea-1.= pdf

Minutes of the presentation are at:
=A0 http://www.ietf.org/proceedings/82/minutes/opsarea.txt
The abstract in the RFC is:

                             Power Locator
                     draft-nordman-power-locator-00

Abstract

   This specification addresses how to request that a device should
   enter a "power locator" mode for a limited period of time.  Th=
e mode
   involves a device cycling between a low and high power level in a
   predictable manner so that a power metering device upstream in the
   power distribution system can sense the signal and so determine where
   the device draws its power from.  This will be useful in many types
   of buildings, particularly data centers and large commercial
   buildings.  This draft addresses operation of the device carrying out
   the request, but not detailed operation of the device that makes the
   request and interprets the results.

   This draft is an initial discussion document to generate feedback and
   improvement.

Thank you,

--Bruce

--
B= ruce Nordman
Lawrence Berk= eley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--f46d04190db436faf904b883125b-- From ggolovinsky@gmail.com Fri Feb 10 08:00:52 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD03D21E8015 for ; Fri, 10 Feb 2012 08:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RPNo30lMyEh for ; Fri, 10 Feb 2012 08:00:52 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 06C1F21E8011 for ; Fri, 10 Feb 2012 08:00:52 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2651873pbc.31 for ; Fri, 10 Feb 2012 08:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=eN7xYQjTbUfweaJJqgACU0SmbmcnYvPdVuie5FQNOxM=; b=EJ0yK19bjLjMxcFjSjrpuf8yvCcZ6PMvRwNlIDUoGXcdGJjjz6n3+t8ea4tx5AwS1l PyarNxuUnM++guN0JU+1QgpSEiIgZzomH562UmGLYEjqHEjLeK7/9zT46+lfnV7x6wKs 3sF9A3T8A3ldaPl2/qZDfyL4zybXXSRFZ1rH4= Received: by 10.68.73.196 with SMTP id n4mr17490717pbv.33.1328889651886; Fri, 10 Feb 2012 08:00:51 -0800 (PST) Received: from 82218T420A (ip-64-39-108-96.us01.qualys.com. [64.39.108.96]) by mx.google.com with ESMTPS id kx17sm14615061pbb.19.2012.02.10.08.00.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 08:00:51 -0800 (PST) From: "Gene Golovinsky" To: , Date: Fri, 10 Feb 2012 08:00:50 -0800 Message-ID: <00e301cce80d$29d7d010$7d877030$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E4_01CCE7CA.1BB4DE30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczoC+8EikMbDRHcTTOGmKDaElIneQ== Content-Language: en-us Subject: [OPSAWG] Slot request for OPSAWG X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 16:00:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E4_01CCE7CA.1BB4DE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi. I would like to request a presentation slot for http://tools.ietf.org/html/draft-golovinsky-cloud-services-log-format-01 at OPSAWG meeting during upcoming IETF 83. This work is looking for a suitable home and I think fits well with the overall OPSAWG agenda since it is focusing on the nuances of logging in the cloud environments where traditional logging does not provide accurate enough information about users, identities and assets. This information is critical for operational and security tasks. I probably need about 15 minutes for me presentation. Many thanks. --Gene ------=_NextPart_000_00E4_01CCE7CA.1BB4DE30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Slot request for OPSAWG

Hi.

I would like to = request a presentation slot for =

http://tools.ietf.org/html/draft-golovinsky-cloud-servic= es-log-format-01

at OPSAWG = meeting during upcoming IETF 83.

This work is = looking for a suitable home and I think fits well with the overall = OPSAWG agenda since it is focusing on the nuances of logging in the cloud environments = where traditional logging does not provide accurate enough information about users, = identities and assets.

This = information is critical for operational and security = tasks.

I probably need = about 15 minutes for me presentation.

Many = thanks.

--Gene

------=_NextPart_000_00E4_01CCE7CA.1BB4DE30-- From ietf@cdl.asgaard.org Tue Feb 14 07:45:09 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6E21F8754 for ; Tue, 14 Feb 2012 07:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34t45qRlc3hn for ; Tue, 14 Feb 2012 07:45:05 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id E666921F8769 for ; Tue, 14 Feb 2012 07:45:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 3679FB974D7; Tue, 14 Feb 2012 15:45:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJlSk76h+cFi; Tue, 14 Feb 2012 15:44:57 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id F0970B974BE; Tue, 14 Feb 2012 15:44:56 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: multipart/signed; boundary="Apple-Mail=_249D7D3F-23F2-4F17-B64F-B1C33F22B9EA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Mon, 13 Feb 2012 15:14:39 -0800 Message-Id: <2BE690E1-84A1-40AB-9EBB-4FA55B2F884F@cdl.asgaard.org> To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Cc: opsawg-chairs@tools.ietf.org Subject: [OPSAWG] Consensus on draft-ietf-opsawg-management-stds-04? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 15:45:09 -0000 --Apple-Mail=_249D7D3F-23F2-4F17-B64F-B1C33F22B9EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, I believe that I sent this out last week, but can't seem to find = it - so here it is again.... The latest draft-ietf-opsawg-management-stds-04 is out and seems = to have addressed all the outstanding issues. We have WGLC'd this = twice. Instead of running this for a week, can we get anyone who has = substantive issues with this draft to speak up in the next 48-72 hours? = Say, by Wed night 23:59 UTC? If there are no comments, we will progress = the document. Thank you, Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_249D7D3F-23F2-4F17-B64F-B1C33F22B9EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPOZllAAoJEGmx2Mt/+Iw/VfAIAIIiCLc8Wx6y0/bU3b8p5hwX p3ouSset18XM8K4WCmZZZAUckxqYS7qZtP05H7bVjREm3mkkIZ/lCs1Yezn9rv0a N1gRbZjTZKPtZWaxQH+yZ8IAnSQfVoMYsnhxZyP+mLvt7RktlSC3JIgzN7IAJp7Q QJgWkuPnlkZN91zS0V2zsll4evmDOsKxWfYwbcG8t42b9/iPR9Q+AL7vBzUXrc5s 2zVHoCLvcGmxlAWhwE5IB/nQRW6Hf2LsSkWTHFWguNDCJY05V8D0ke065bZ1GGr7 HDiNpNSew2YOnBdeAlOUOxx4cgO7V+b4n+9I9l5ioAAqIekiYaOqTbvO4MliM0I= =uQJK -----END PGP SIGNATURE----- --Apple-Mail=_249D7D3F-23F2-4F17-B64F-B1C33F22B9EA-- From liu.bin21@zte.com.cn Tue Feb 14 01:07:04 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4E621F87B3 for ; Tue, 14 Feb 2012 01:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.373 X-Spam-Level: X-Spam-Status: No, score=-96.373 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_50=0.001, DEAR_SOMETHING=1.605, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKZmEMRNHrsF for ; Tue, 14 Feb 2012 01:07:03 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5A421F87B2 for ; Tue, 14 Feb 2012 01:07:02 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 523731390076507; Tue, 14 Feb 2012 17:01:38 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 25197.1390076507; Tue, 14 Feb 2012 17:06:54 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id q1E96rgn084695 for ; Tue, 14 Feb 2012 17:06:53 +0800 (GMT-8) (envelope-from liu.bin21@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1E82SlN072665; Tue, 14 Feb 2012 16:02:28 +0800 (GMT-8) (envelope-from liu.bin21@zte.com.cn) Message-Id: <201202140906.q1E96rgn084695@mse02.zte.com.cn> To: opsawg-chairs@tools.ietf.org, opsawg@ietf.org MIME-Version: 1.0 Importance: High X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: liu.bin21@zte.com.cn Date: Tue, 14 Feb 2012 16:02:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-14 16:02:31, Serialize complete at 2012-02-14 16:02:31 Content-Type: multipart/alternative; boundary="=_alternative 002C9A12482579A4_=" X-MAIL: mse02.zte.com.cn q1E96rgn084695 X-MSS: AUDITRELEASE@mse02.zte.com.cn X-Mailman-Approved-At: Tue, 14 Feb 2012 10:35:10 -0800 Cc: Richard Bin liu , yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, li.dongmei@zte.com.cn Subject: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 09:07:04 -0000 This is a multipart message in MIME format. --=_alternative 002C9A12482579A4_= Content-Type: text/plain; charset="US-ASCII" Dear Sir, After research and analysis, we had completed a draft on VM migration field. The draft has discussed the operation and management issues faced in DC and Cloud environments. The problems which emerge in the following scenarios, such as VM migration in DC local network, between DCI network consist of L2VPN, L3VPN, or ipv4&ipv6 mixed network, have been analysed, those who need to be resolved have been summarized. DC and Cloud have been active topics in the opsawg working group, and operation and management are related. So, I would like to request a time slot for presenting this draft: http://datatracker.ietf.org/doc/draft-khasnabish-vmmi-problems/?include_text=1 at OPSAWG meeting during upcoming IETF 83. And I need 20 minutes to present this draft. Many thanks and best wishes. Regards, Richard Bin Liu -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002C9A12482579A4_= Content-Type: text/html; charset="US-ASCII"
Dear Sir,

After research and analysis, we had completed a draft on VM migration field. The draft has discussed the operation and

management issues faced in DC and Cloud environments. The problems which emerge in the following scenarios, such as VM

migration in DC local network, between DCI network consist of L2VPN, L3VPN, or ipv4&ipv6 mixed network, have been analysed,

those who need to be resolved have been summarized.

DC and Cloud have been active topics in the opsawg working group, and operation and management are related.

So, I would like to request a time slot for presenting this draft:
http://datatracker.ietf.org/doc/draft-khasnabish-vmmi-problems/?include_text=1
at OPSAWG meeting during upcoming IETF 83. And I need 20 minutes to present this draft.

Many thanks and best wishes.

Regards,

Richard Bin Liu 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002C9A12482579A4_=-- From cdl@asgaard.org Tue Feb 14 10:38:36 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A9A21F85F6 for ; Tue, 14 Feb 2012 10:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbs+D-kSqJpW for ; Tue, 14 Feb 2012 10:38:35 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE5F21F8622 for ; Tue, 14 Feb 2012 10:38:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 07704BA662A; Tue, 14 Feb 2012 18:38:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9yJhDJvxN3t; Tue, 14 Feb 2012 18:38:30 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id CBA24BA6617; Tue, 14 Feb 2012 18:38:30 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_2DAB13E7-BEE9-4431-AE73-62974DA6CA77"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Christopher LILJENSTOLPE In-Reply-To: <2BE690E1-84A1-40AB-9EBB-4FA55B2F884F@cdl.asgaard.org> Date: Tue, 14 Feb 2012 10:38:30 -0800 Message-Id: <770BFB63-D0E7-494A-8554-1370AD5C4403@asgaard.org> References: <2BE690E1-84A1-40AB-9EBB-4FA55B2F884F@cdl.asgaard.org> To: opsawg@ietf.org X-Mailer: Apple Mail (2.1251.1) Cc: opsawg-chairs@tools.ietf.org Subject: Re: [OPSAWG] Consensus on draft-ietf-opsawg-management-stds-04? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:38:36 -0000 --Apple-Mail=_2DAB13E7-BEE9-4431-AE73-62974DA6CA77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I thought so, but I couldn't find it in the archives. We'll let this = run until tomorrow night, and call it. Chris On 13Feb2012, at 15.14, Christopher LILJENSTOLPE wrote: > Greetings, >=20 > I believe that I sent this out last week, but can't seem to find = it - so here it is again.... >=20 > The latest draft-ietf-opsawg-management-stds-04 is out and seems = to have addressed all the outstanding issues. We have WGLC'd this = twice. Instead of running this for a week, can we get anyone who has = substantive issues with this draft to speak up in the next 48-72 hours? = Say, by Wed night 23:59 UTC? If there are no comments, we will progress = the document. >=20 > Thank you, > Chris >=20 > -- =20 > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc > Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_2DAB13E7-BEE9-4431-AE73-62974DA6CA77 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPOqomAAoJEGmx2Mt/+Iw/SUEH/iGA7FMHEGDDtUwj+RGtA/le sxJgDFAn4AuqHVIRqFwmWkCz0UxOtvXAlXIivHI+3+eHQjFaOJHqRH+wcYHHOt9r G57bmwJ4aPgCIf9+fVmr0yWKG0/rrhrXHWQ4B7WPjwzq4diE3kwVcbKXcQEuPdzU AI0DB5aePG1bmBq9ss89kF7qsogSweWjhaAfncatGPBl6pf5WevUN+y2v3Pk0l/0 7i6fECFEEzQILWPuHk/BTaF+deGAN5KLu1GcFavSPCYUgBS57CPj2BPisBPzt9Xp uRhWT9WDFmssUqS000EyPEGVWeWnPVHbrfTVxjvLS0Ec/GR/etyXaLaMqcQsJBI= =heXP -----END PGP SIGNATURE----- --Apple-Mail=_2DAB13E7-BEE9-4431-AE73-62974DA6CA77-- From rbonica@juniper.net Wed Feb 15 07:30:16 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1CB21F8585 for ; Wed, 15 Feb 2012 07:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.431 X-Spam-Level: X-Spam-Status: No, score=-105.431 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, DEAR_SOMETHING=1.605, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzWrLqBCFr9r for ; Wed, 15 Feb 2012 07:30:12 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id C7FA521F8548 for ; Wed, 15 Feb 2012 07:29:40 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTzvPWgHgCP0miobw9ateH2YFOVqkipN6@postini.com; Wed, 15 Feb 2012 07:29:40 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 15 Feb 2012 07:27:42 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 15 Feb 2012 10:27:41 -0500 From: Ronald Bonica To: "liu.bin21@zte.com.cn" , "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" Date: Wed, 15 Feb 2012 10:27:40 -0500 Thread-Topic: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 Thread-Index: AczrR2vbkAwbnf6cRFCnirzxccBpZQArtApg Message-ID: <13205C286662DE4387D9AF3AC30EF456D766B576E1@EMBX01-WF.jnpr.net> References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> In-Reply-To: <201202140906.q1E96rgn084695@mse02.zte.com.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D766B576E1EMBX01WFjnprn_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: f8e27f27-03b2-4c3e-9447-119194e72cb6 Cc: "li.dongmei@zte.com.cn" , Richard Bin liu , "yu.jinghai@zte.com.cn" , "lizhong.jin@zte.com.cn" , "song.xiaoli@zte.com.cn" Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 15:30:16 -0000 --_000_13205C286662DE4387D9AF3AC30EF456D766B576E1EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Richard, Do you intend to present this draft in three WGs? Ron From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= liu.bin21@zte.com.cn Sent: Tuesday, February 14, 2012 3:02 AM To: opsawg-chairs@tools.ietf.org; opsawg@ietf.org Cc: Richard Bin liu; yu.jinghai@zte.com.cn; lizhong.jin@zte.com.cn; song.xi= aoli@zte.com.cn; li.dongmei@zte.com.cn Subject: [OPSAWG] request a time slot to present VMMI-problems draft in L2V= PN, L3VPN, and OPSAWG mtgs during IETF-83 Importance: High Dear Sir, After research and analysis, we had completed a draft on VM migration field= . The draft has discussed the operation and management issues faced in DC and Cloud environments. The problems which em= erge in the following scenarios, such as VM migration in DC local network, between DCI network consist of L2VPN, L3VPN,= or ipv4&ipv6 mixed network, have been analysed, those who need to be resolved have been summarized. DC and Cloud have been active topics in the opsawg working group, and opera= tion and management are related. So, I would like to request a time slot for presenting this draft: http://datatracker.ietf.org/doc/draft-khasnabish-vmmi-problems/?include_tex= t=3D1 at OPSAWG meeting during upcoming IETF 83. And I need 20 minutes to present= this draft. Many thanks and best wishes. Regards, Richard Bin Liu -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_13205C286662DE4387D9AF3AC30EF456D766B576E1EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard,<= o:p>

 

Do you intend to present this draft in three = WGs?

 

      &nbs= p;            &= nbsp;           &nbs= p;     Ron

 

 

From: opsawg-bounces@= ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of liu.bin21@zte= .com.cn
Sent: Tuesday, February 14, 2012 3:02 AM
To: op= sawg-chairs@tools.ietf.org; opsawg@ietf.org
Cc: Richard Bin liu; = yu.jinghai@zte.com.cn; lizhong.jin@zte.com.cn; song.xiaoli@zte.com.cn; li.d= ongmei@zte.com.cn
Subject: [OPSAWG] request a time slot to presen= t VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83
Importance: High

 

<= br>Dear S= ir,

After research and analysis, we had completed a draft on VM migra= tion field. The draft has discussed the operation and

management issu= es faced in DC and Cloud environments. The problems which emerge in the fol= lowing scenarios, such as VM

migration in DC local network, between D= CI network consist of L2VPN, L3VPN, or ipv4&ipv6 mixed network, have be= en analysed,

those who need to be resolved have been summarized.

DC and Cloud have been active topics in the opsawg working group, and ope= ration and management are related.

So, I would like to request a time= slot for presenting this draft:
http://datatracker.ietf.org/doc/draft-kh= asnabish-vmmi-problems/?include_text=3D1
at OPSAWG meeting during upcomin= g IETF 83. And I need 20 minutes to present this draft.

Many thanks a= nd best wishes.

Regards,

Richard Bin Liu

= 
 
------------------------------------------=
--------------
ZTE Information Security =
;Notice: The information contained in this ma=
il is solely property of the sender's or=
ganization. This mail communication is confidentia=
l. Recipients named above are obligated to&nb=
sp;maintain secrecy and are not permitted to&=
nbsp;disclose the contents of this communication&n=
bsp;to others.
This email and any&=
nbsp;files transmitted with it are confidential&nb=
sp;and intended solely for the use of th=
e individual or entity to whom they are&=
nbsp;addressed. If you have received this ema=
il in error please notify the originator =
;of the message. Any views expressed in =
this message are those of the individual =
;sender.
This message has been sca=
nned for viruses and Spam by ZTE Anti-Sp=
am system.
= --_000_13205C286662DE4387D9AF3AC30EF456D766B576E1EMBX01WFjnprn_-- From narten@us.ibm.com Wed Feb 15 12:52:16 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1267E21E80A4 for ; Wed, 15 Feb 2012 12:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.953 X-Spam-Level: X-Spam-Status: No, score=-108.953 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbOOQw+zNZWL for ; Wed, 15 Feb 2012 12:52:08 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 6B05D21E80B4 for ; Wed, 15 Feb 2012 12:52:06 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 Feb 2012 15:52:01 -0500 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 15 Feb 2012 15:51:59 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3BC6638C8069 for ; Wed, 15 Feb 2012 15:51:58 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1FKpq07328364 for ; Wed, 15 Feb 2012 15:51:56 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1FKpn4e014219 for ; Wed, 15 Feb 2012 18:51:49 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-65-205-222.mts.ibm.com [9.65.205.222]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1FKpmWi014078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 18:51:49 -0200 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q1FKpDNt026253; Wed, 15 Feb 2012 15:51:14 -0500 Message-Id: <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> To: liu.bin21@zte.com.cn In-reply-to: <201202140906.q1E96rgn084695@mse02.zte.com.cn> References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> Comments: In-reply-to liu.bin21@zte.com.cn message dated "Tue, 14 Feb 2012 16:02:28 +0800." Date: Wed, 15 Feb 2012 15:51:13 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12021520-9360-0000-0000-0000038E667C Cc: Richard Bin liu , yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, opsawg-chairs@tools.ietf.org, li.dongmei@zte.com.cn, opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 20:52:16 -0000 liu.bin21@zte.com.cn writes: > So, I would like to request a time slot for presenting this draft: > http://datatracker.ietf.org/doc/draft-khasnabish-vmmi-problems/?include_text=1 > at OPSAWG meeting during upcoming IETF 83. And I need 20 minutes to > present this draft. There were some discussion and questions about this draft on the DC list when it first came out in January. Go to http://www.ietf.org/mail-archive/web/dc/current/threads.html and search for "vmmi". IMO, that discussion raised a lot of questions, but there were few satisfactory answers. Moreover, there was no indication that the draft would be (or needed to be) revised based on those discussions. Given the confusion, I fear that a presentation in Paris would raise many of the same questions. That would not be a productive use of anyone's time. Question to any session chairs and the community at large: should this draft in its current state be grante a presentation slot in Paris? My personal opinion is no. I don't see such a presentation as making good use of the IETF's time. Do others feel differently? What I would like to see for this (and any other non-WG document wanting a presentation slot for that matter) is a show of support from a handful of non-authors who have read the document and believe that there is enough substance in the document to warrant a presentation slot. In some cases, a far better approach would be to have a few interested persons work with draft authors to improve a document prior to asking for a meeting slot to present it. Thoughts? Thomas From david.black@emc.com Wed Feb 15 13:48:20 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4943121E8032 for ; Wed, 15 Feb 2012 13:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.213 X-Spam-Level: X-Spam-Status: No, score=-109.213 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTry6zMCSAw5 for ; Wed, 15 Feb 2012 13:48:16 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8696121E8091 for ; Wed, 15 Feb 2012 13:48:12 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1FLm0l1028544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 16:48:09 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 15 Feb 2012 16:47:51 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1FLloaY018606; Wed, 15 Feb 2012 16:47:50 -0500 Received: from mx14a.corp.emc.com ([169.254.1.94]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Wed, 15 Feb 2012 16:47:50 -0500 From: To: , Date: Wed, 15 Feb 2012 16:47:48 -0500 Thread-Topic: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 Thread-Index: AczsJHA5+JeG0y85RXOWPUCJ9jSRdAABskgw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD33AB74@MX14A.corp.emc.com> References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> In-Reply-To: <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: richard.bohan.liu@gmail.com, yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, opsawg-chairs@tools.ietf.org, li.dongmei@zte.com.cn, opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 21:48:20 -0000 I basically concur with Thomas's concerns. What do the draft authors want the IETF to do as a result of presenting thi= s draft? Thanks, --David > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf = Of Thomas Narten > Sent: Wednesday, February 15, 2012 3:51 PM > To: liu.bin21@zte.com.cn > Cc: Richard Bin liu; yu.jinghai@zte.com.cn; lizhong.jin@zte.com.cn; song.= xiaoli@zte.com.cn; opsawg- > chairs@tools.ietf.org; li.dongmei@zte.com.cn; opsawg@ietf.org > Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft = in L2VPN, L3VPN, and OPSAWG > mtgs during IETF-83 >=20 > liu.bin21@zte.com.cn writes: >=20 > > So, I would like to request a time slot for presenting this draft: > > http://datatracker.ietf.org/doc/draft-khasnabish-vmmi-problems/?include= _text=3D1 > > at OPSAWG meeting during upcoming IETF 83. And I need 20 minutes to > > present this draft. >=20 > There were some discussion and questions about this draft on the DC > list when it first came out in January. Go to > http://www.ietf.org/mail-archive/web/dc/current/threads.html and > search for "vmmi". >=20 > IMO, that discussion raised a lot of questions, but there were few > satisfactory answers. Moreover, there was no indication that the draft > would be (or needed to be) revised based on those discussions. >=20 > Given the confusion, I fear that a presentation in Paris would raise > many of the same questions. That would not be a productive use of > anyone's time. >=20 > Question to any session chairs and the community at large: should this > draft in its current state be grante a presentation slot in Paris? My > personal opinion is no. I don't see such a presentation as making good > use of the IETF's time. >=20 > Do others feel differently? >=20 > What I would like to see for this (and any other non-WG document > wanting a presentation slot for that matter) is a show of support from > a handful of non-authors who have read the document and believe that > there is enough substance in the document to warrant a presentation > slot. In some cases, a far better approach would be to have a few > interested persons work with draft authors to improve a document prior > to asking for a meeting slot to present it. >=20 > Thoughts? >=20 > Thomas >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Wed Feb 15 15:15:56 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B28221E8084 for ; Wed, 15 Feb 2012 15:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.16 X-Spam-Level: X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy-8FNV7v-Pc for ; Wed, 15 Feb 2012 15:15:56 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1070321E8032 for ; Wed, 15 Feb 2012 15:15:55 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1952049pbc.31 for ; Wed, 15 Feb 2012 15:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GSGpbryC3rweJSTZ3w6eKqhuWP3OQdOBS6BtaWnZdq8=; b=x4oL2ACpWCdlx0woyRDz24ojtjs3cGewntQ7YeyHUTvf2Bp13uBn831CbEG9J7Xh4T seK1BYgN43D0ZkKPfThI5AktIGe5Yk9mSu9L7ZNSd3xbofkGJ8Z7vVpmZkrfuHG6tcFu rtZET7P6TLE14HYJ+qpTFwIvmtpnGzY18LTqc= Received: by 10.68.223.199 with SMTP id qw7mr7630822pbc.79.1329347755703; Wed, 15 Feb 2012 15:15:55 -0800 (PST) Received: from [137.229.12.236] (drake.swits.alaska.edu. [137.229.12.236]) by mx.google.com with ESMTPS id 4sm12185072pbo.4.2012.02.15.15.15.53 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 15:15:54 -0800 (PST) Message-ID: <4F3C3CAA.4050107@gmail.com> Date: Wed, 15 Feb 2012 14:15:54 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Thomas Narten References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> In-Reply-To: <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Richard Bin liu , yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, opsawg-chairs@tools.ietf.org, li.dongmei@zte.com.cn, opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 23:15:56 -0000 On 02/15/2012 11:51 AM, Thomas Narten wrote: > Given the confusion, I fear that a presentation in Paris would raise > many of the same questions. That would not be a productive use of > anyone's time. I'm not comfortable with the notion that meetings are places to promote new work, to be honest. I prefer to think of them as places for discussion, not presentation. I'm also unclear on what the intended outcome is. Is the request for slots in three different working groups in two different areas an attempt to engage subject matter experts, or is it forum shopping? At this point I think getting support from people who aren't involved with the draft is a high-ish bar - I haven't even seen any interest, frankly. There absolutely needs to be discussion here, first, and some clarification of both intent and why this work is being proposed (if that's what's happening) in three working groups. This may be a good time to remind folks to give sections 5.2 and 5.3 of RFC 4677 a good, careful read. Melinda -- Melinda Shore melinda.shore@gmail.com Software longa, hardware brevis From randy@psg.com Wed Feb 15 15:20:32 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1255421E8084 for ; Wed, 15 Feb 2012 15:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpEkB+hYVade for ; Wed, 15 Feb 2012 15:20:31 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id AFC3921E8032 for ; Wed, 15 Feb 2012 15:20:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rxo9C-0002rt-Al; Wed, 15 Feb 2012 23:20:26 +0000 Date: Wed, 15 Feb 2012 15:20:26 -0800 Message-ID: From: Randy Bush To: Thomas Narten In-Reply-To: <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 23:20:32 -0000 > Question to any session chairs and the community at large: should this > draft in its current state be grante a presentation slot in Paris? My > personal opinion is no. I don't see such a presentation as making good > use of the IETF's time. > > Do others feel differently? not this other randy From cdl@asgaard.org Wed Feb 15 18:09:22 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907DD21F8440 for ; Wed, 15 Feb 2012 18:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70Rhu5rMy2GN for ; Wed, 15 Feb 2012 18:09:18 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id D5C9221F842D for ; Wed, 15 Feb 2012 18:09:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id B117FBB3837; Thu, 16 Feb 2012 02:09:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nmrItN8ELMH; Thu, 16 Feb 2012 02:09:10 +0000 (UTC) Received: from [172.20.10.3] (unknown [166.205.136.111]) by asgaard.org (Postfix) with ESMTPSA id A4818BB3828; Thu, 16 Feb 2012 02:09:03 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_8EA84BE8-BA58-4053-A89B-44C6BAA8C975"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Christopher LILJENSTOLPE In-Reply-To: <4F3C3CAA.4050107@gmail.com> Date: Wed, 15 Feb 2012 18:09:02 -0800 Message-Id: References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> <4F3C3CAA.4050107@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1251.1) Cc: Thomas Narten , Richard Bin liu , yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, opsawg-chairs@tools.ietf.org, li.dongmei@zte.com.cn, opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 02:09:22 -0000 --Apple-Mail=_8EA84BE8-BA58-4053-A89B-44C6BAA8C975 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings Melinda, I would agree. It has been our position for the last few = meetings that the meetings are to continue discussions already ongoing = on the list - hence our request for discussion on the list before work = is discussed at a meeting. Chris On 15Feb2012, at 15.15, Melinda Shore wrote: > On 02/15/2012 11:51 AM, Thomas Narten wrote: >> Given the confusion, I fear that a presentation in Paris would raise >> many of the same questions. That would not be a productive use of >> anyone's time. >=20 > I'm not comfortable with the notion that meetings are places to > promote new work, to be honest. I prefer to think of them as > places for discussion, not presentation. I'm also unclear on what > the intended outcome is. Is the request for slots in three > different working groups in two different areas an attempt to > engage subject matter experts, or is it forum shopping? >=20 > At this point I think getting support from people who aren't > involved with the draft is a high-ish bar - I haven't even seen > any interest, frankly. There absolutely needs to be discussion > here, first, and some clarification of both intent and why this > work is being proposed (if that's what's happening) in three > working groups. >=20 > This may be a good time to remind folks to give sections 5.2 and > 5.3 of RFC 4677 a good, careful read. >=20 > Melinda >=20 > --=20 > Melinda Shore > melinda.shore@gmail.com > Software longa, hardware brevis > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_8EA84BE8-BA58-4053-A89B-44C6BAA8C975 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPPGU/AAoJEGmx2Mt/+Iw/y68H/AoXozHN1LJThHeFsaC9KyLf GuPooK/LmitG55j1gc9fj8Dyi5TkHBFIpbvnuzols6N8XreZ2licMZVRW8sIqH8w 6imLVx2wgU8+l8r7QcVUuJhUWI8MZwa04MJJ/J19JHXFc/RVbbYVhgvqlAmFm+Kj DakE8jBna5dwr8iX23GL7ySWbYK3AAqwjjw3GCUlxuvFqbRqVz7J0NXNl/gMQZMx VmllE2Zh4aL5dfyOB2B7bb509qz2sZcnMBtQmjcSVOSTkSjmsrpUfDtaMTSKU4/4 2U/eywqVahe1nXDwHeNI2qb772wPuoUr9MDNSUt3WIHNBpqeLINPd4CVF2qgcZ8= =uBK/ -----END PGP SIGNATURE----- --Apple-Mail=_8EA84BE8-BA58-4053-A89B-44C6BAA8C975-- From warren@kumari.net Thu Feb 16 13:41:08 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A8F21E8040 for ; Thu, 16 Feb 2012 13:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.186 X-Spam-Level: X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFmhXHoS88Hd for ; Thu, 16 Feb 2012 13:41:04 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5C13121E801B for ; Thu, 16 Feb 2012 13:41:04 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 1BB2E1B402A0; Thu, 16 Feb 2012 16:41:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Thu, 16 Feb 2012 16:41:01 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0EFF596B-C515-4A09-B8A1-ACF1DADE89CC@kumari.net> References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:41:08 -0000 On Feb 15, 2012, at 6:20 PM, Randy Bush wrote: >> Question to any session chairs and the community at large: should this >> draft in its current state be grante a presentation slot in Paris? My >> personal opinion is no. I don't see such a presentation as making good >> use of the IETF's time. >> >> Do others feel differently? > > not this other nor this one... W > > randy > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From vumip1@gmail.com Thu Feb 16 13:51:41 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8770E21E8051 for ; Thu, 16 Feb 2012 13:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.097 X-Spam-Level: X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x28S+TviXhmW for ; Thu, 16 Feb 2012 13:51:36 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38CA221E801C for ; Thu, 16 Feb 2012 13:51:36 -0800 (PST) Received: by iagf6 with SMTP id f6so4102453iag.31 for ; Thu, 16 Feb 2012 13:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n4acm7i12C3yTk2rjU/vGMx2JnBSB3TIo3POGLvipRk=; b=PiRiKWnTzA/RHo8jKN1j0LdyFLKyUmp1V+dVNOPqNDdldUTHSzsCrtiMu8GFuWAA6Y 5f79gsqMsUZQCCF/0L0bSs6T7nzhWVZJuib4wJwEMj9mFNMf4MJ0KL+8In2XeJChxQsH zCw9UOeb10suZV5QfPLG4CB3N09WZirmskJMc= MIME-Version: 1.0 Received: by 10.50.155.201 with SMTP id vy9mr5474855igb.16.1329429095885; Thu, 16 Feb 2012 13:51:35 -0800 (PST) Received: by 10.50.213.68 with HTTP; Thu, 16 Feb 2012 13:51:35 -0800 (PST) In-Reply-To: <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> Date: Thu, 16 Feb 2012 16:51:35 -0500 Message-ID: From: Bhumip Khasnabish To: Thomas Narten Content-Type: multipart/alternative; boundary=e89a8f3ba88d03a98d04b91bd5c4 Cc: Richard Bin liu , yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, opsawg-chairs@tools.ietf.org, li.dongmei@zte.com.cn, opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:51:41 -0000 --e89a8f3ba88d03a98d04b91bd5c4 Content-Type: text/plain; charset=ISO-8859-1 Hello Thomas, We are working on updating this draft. Many thanks to everyone for comments and suggestions. Best. Bhumip On Wed, Feb 15, 2012 at 3:51 PM, Thomas Narten wrote: > liu.bin21@zte.com.cn writes: > > > So, I would like to request a time slot for presenting this draft: > > > http://datatracker.ietf.org/doc/draft-khasnabish-vmmi-problems/?include_text=1 > > at OPSAWG meeting during upcoming IETF 83. And I need 20 minutes to > > present this draft. > > There were some discussion and questions about this draft on the DC > list when it first came out in January. Go to > http://www.ietf.org/mail-archive/web/dc/current/threads.html and > search for "vmmi". > > IMO, that discussion raised a lot of questions, but there were few > satisfactory answers. Moreover, there was no indication that the draft > would be (or needed to be) revised based on those discussions. > > Given the confusion, I fear that a presentation in Paris would raise > many of the same questions. That would not be a productive use of > anyone's time. > > Question to any session chairs and the community at large: should this > draft in its current state be grante a presentation slot in Paris? My > personal opinion is no. I don't see such a presentation as making good > use of the IETF's time. > > Do others feel differently? > > What I would like to see for this (and any other non-WG document > wanting a presentation slot for that matter) is a show of support from > a handful of non-authors who have read the document and believe that > there is enough substance in the document to warrant a presentation > slot. In some cases, a far better approach would be to have a few > interested persons work with draft authors to improve a document prior > to asking for a meeting slot to present it. > > Thoughts? > > Thomas > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --e89a8f3ba88d03a98d04b91bd5c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Thomas,
We are working on updating this draft.
Many thanks to everyone for comments and suggestions.
Best.
Bhumip

=A0
On Wed, Feb 15, 2012 at 3:51 PM, Thomas Narten <= span dir=3D"ltr"><narten@us.ibm.com= > wrote:
liu.bin21@zte.com= .cn writes:

> So, I would like to request a time slot for pre= senting this draft:
> http://data= tracker.ietf.org/doc/draft-khasnabish-vmmi-problems/?include_text=3D1 > at OPSAWG meeting during upcoming IETF 83. And I need 20 minutes to> present this draft.

There were some discussion and quest= ions about this draft on the DC
list when it first came out in January. = Go to
http://www.ietf.org/mail-archive/web/dc/current/threads.htm= l and
search for "vmmi".

IMO, that discussion raise= d a lot of questions, but there were few
satisfactory answers. Moreover, there was no indication that the draft
w= ould be (or needed to be) revised based on those discussions.

Given = the confusion, I fear that a presentation in Paris would raise
many of t= he same questions. That would not be a productive use of
anyone's time.

Question to any session chairs and the community = at large: should this
draft in its current state be grante a presentatio= n slot in Paris? My
personal opinion is no. I don't see such a prese= ntation as making good
use of the IETF's time.

Do others feel differently?

What = I would like to see for this (and any other non-WG document
wanting a pr= esentation slot for that matter) is a show of support from
a handful of = non-authors who have read the document and believe that
there is enough substance in the document to warrant a presentation
slot= . In some cases, a far better approach would be to have a few
interested= persons work with draft authors to improve a document prior
to asking f= or a meeting slot to present it.

Thoughts?

Thomas

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


=A0 --e89a8f3ba88d03a98d04b91bd5c4-- From vumip1@gmail.com Thu Feb 16 13:53:53 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1CA21E8065 for ; Thu, 16 Feb 2012 13:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVddrWB87wW7 for ; Thu, 16 Feb 2012 13:53:48 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C34421E8043 for ; Thu, 16 Feb 2012 13:53:45 -0800 (PST) Received: by yhkk25 with SMTP id k25so1772237yhk.31 for ; Thu, 16 Feb 2012 13:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xeTa3AgnbDr+Djrsk6D5mgZeouvcJ+8o53yaywgqd9w=; b=Y5yTjcQnahLilQWY72UESV8e2rpXzii6Vju1H7EDdMd2ktrWASNlfMQEXfiGE2hIUR legm7MaaPF6U3zw2sVmrA/2H2hxOPS51HNpsY2mbMKLIjEdKKlMWc1kq2zi9Vfn9h/Cx +i+vw6UFEg9We5COel4OBNsI6KzneK1QV1Xvo= MIME-Version: 1.0 Received: by 10.50.236.34 with SMTP id ur2mr5459458igc.20.1329429225362; Thu, 16 Feb 2012 13:53:45 -0800 (PST) Received: by 10.50.213.68 with HTTP; Thu, 16 Feb 2012 13:53:45 -0800 (PST) In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD33AB74@MX14A.corp.emc.com> References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AD33AB74@MX14A.corp.emc.com> Date: Thu, 16 Feb 2012 16:53:45 -0500 Message-ID: From: Bhumip Khasnabish To: david.black@emc.com Content-Type: multipart/alternative; boundary=14dae9399d7dbb542604b91bdccc Cc: narten@us.ibm.com, richard.bohan.liu@gmail.com, yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, opsawg-chairs@tools.ietf.org, li.dongmei@zte.com.cn, opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:53:53 -0000 --14dae9399d7dbb542604b91bdccc Content-Type: text/plain; charset=ISO-8859-1 >What do the draft authors want the IETF to do as a result of >presenting this draft? At this point the objective is to basically develop the VMMI requirements. On Wed, Feb 15, 2012 at 4:47 PM, wrote: > I basically concur with Thomas's concerns. > > What do the draft authors want the IETF to do as a result of presenting > this draft? > > Thanks, > --David > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Thomas Narten > > Sent: Wednesday, February 15, 2012 3:51 PM > > To: liu.bin21@zte.com.cn > > Cc: Richard Bin liu; yu.jinghai@zte.com.cn; lizhong.jin@zte.com.cn; > song.xiaoli@zte.com.cn; opsawg- > > chairs@tools.ietf.org; li.dongmei@zte.com.cn; opsawg@ietf.org > > Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft > in L2VPN, L3VPN, and OPSAWG > > mtgs during IETF-83 > > > > liu.bin21@zte.com.cn writes: > > > > > So, I would like to request a time slot for presenting this draft: > > > > http://datatracker.ietf.org/doc/draft-khasnabish-vmmi-problems/?include_text=1 > > > at OPSAWG meeting during upcoming IETF 83. And I need 20 minutes to > > > present this draft. > > > > There were some discussion and questions about this draft on the DC > > list when it first came out in January. Go to > > http://www.ietf.org/mail-archive/web/dc/current/threads.html and > > search for "vmmi". > > > > IMO, that discussion raised a lot of questions, but there were few > > satisfactory answers. Moreover, there was no indication that the draft > > would be (or needed to be) revised based on those discussions. > > > > Given the confusion, I fear that a presentation in Paris would raise > > many of the same questions. That would not be a productive use of > > anyone's time. > > > > Question to any session chairs and the community at large: should this > > draft in its current state be grante a presentation slot in Paris? My > > personal opinion is no. I don't see such a presentation as making good > > use of the IETF's time. > > > > Do others feel differently? > > > > What I would like to see for this (and any other non-WG document > > wanting a presentation slot for that matter) is a show of support from > > a handful of non-authors who have read the document and believe that > > there is enough substance in the document to warrant a presentation > > slot. In some cases, a far better approach would be to have a few > > interested persons work with draft authors to improve a document prior > > to asking for a meeting slot to present it. > > > > Thoughts? > > > > Thomas > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --14dae9399d7dbb542604b91bdccc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>What do the draft authors want the IETF to do as a result of >p= resenting this draft?
At this point the objective is to basically develop the VMMI requireme= nts.

On Wed, Feb 15, 2012 at 4:47 PM, <david.black@emc.com> wrote:
I basically concur with Thomas's = concerns.

What do the draft authors want the IETF to do as a result = of presenting this draft?

Thanks,
--David

> -----Original Message-----
> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Beh= alf Of Thomas Narten
> Sent: Wednesday, February 15, 2012 3:51 PM
> To: liu.bin21@zte.com.cn
> Cc: Richard Bin l= iu; yu.jinghai@zte.com.cn; lizhong.jin@zte.com.cn; song.xiaoli@zte.com.cn; opsawg-
> chairs@tools.ietf.org; li.dongmei@zte.com.cn; opsawg@ietf.org
> Subject: Re: [OPSAW= G] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and = OPSAWG
> mtgs during IETF-83
>
> liu.bin21@zt= e.com.cn writes:
>
> > So, I would like to request a tim= e slot for presenting this draft:
> > http://datatracker.ietf.org/doc/draft-khasnabish-vmmi-problems/?inc= lude_text=3D1
> > at OPSAWG meeting during upcoming IETF 83. And I need 20 minutes = to
> > present this draft.
>
> There were some discuss= ion and questions about this draft on the DC
> list when it first cam= e out in January. Go to
> http://www.ietf.org/mail-archive/web/dc/current/thread= s.html and
> search for "vmmi".
>
> IMO, th= at discussion raised a lot of questions, but there were few
> satisfactory answers. Moreover, there was no indication that the draft=
> would be (or needed to be) revised based on those discussions.
= >
> Given the confusion, I fear that a presentation in Paris would= raise
> many of the same questions. That would not be a productive use of
&= gt; anyone's time.
>
> Question to any session chairs and t= he community at large: should this
> draft in its current state be gr= ante a presentation slot in Paris? My
> personal opinion is no. I don't see such a presentation as making = good
> use of the IETF's time.
>
> Do others feel dif= ferently?
>
> What I would like to see for this (and any other = non-WG document
> wanting a presentation slot for that matter) is a show of support from=
> a handful of non-authors who have read the document and believe th= at
> there is enough substance in the document to warrant a presentat= ion
> slot. In some cases, a far better approach would be to have a few
&= gt; interested persons work with draft authors to improve a document prior<= br>> to asking for a meeting slot to present it.
>
> Thought= s?
>
> Thomas
>
> _______________________________________= ________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsa= wg

_______________________________________________
OPSAWG mailing list<= br>OPSAWG@ietf.org
https://www.ie= tf.org/mailman/listinfo/opsawg



=A0 --14dae9399d7dbb542604b91bdccc-- From vumip1@gmail.com Thu Feb 16 14:20:38 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0C321E8088 for ; Thu, 16 Feb 2012 14:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj1cIFakz0ZT for ; Thu, 16 Feb 2012 14:20:36 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE5D121E807C for ; Thu, 16 Feb 2012 14:20:36 -0800 (PST) Received: by iagf6 with SMTP id f6so4133033iag.31 for ; Thu, 16 Feb 2012 14:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vB89RTS6E2ffxb9+9KyLKLzuQNbC6O4rH8uVYpXNCpM=; b=IoSn0K6Au+vIKLMQPXny7aXcfPbvbhvZqogzBxIxOsoh16hW9Gocp817UCjgs84cDQ QwBveFx8F6LGbjH3IhmdLMrfNRcylKtQURICi1VuIKZwKZm48G2u3tVivRKA+rM1uXI1 bR4zZi0pzOBa66ukH5ijO8C/F/EU+SirfF0Gw= MIME-Version: 1.0 Received: by 10.42.155.5 with SMTP id s5mr4488215icw.13.1329430834827; Thu, 16 Feb 2012 14:20:34 -0800 (PST) Received: by 10.50.213.68 with HTTP; Thu, 16 Feb 2012 14:20:34 -0800 (PST) In-Reply-To: <4F3C3CAA.4050107@gmail.com> References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> <4F3C3CAA.4050107@gmail.com> Date: Thu, 16 Feb 2012 17:20:34 -0500 Message-ID: From: Bhumip Khasnabish To: Melinda Shore Content-Type: multipart/alternative; boundary=90e6ba1efd78a9d23504b91c3c5b Cc: Thomas Narten , Richard Bin liu , yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, opsawg-chairs@tools.ietf.org, li.dongmei@zte.com.cn, opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:20:38 -0000 --90e6ba1efd78a9d23504b91c3c5b Content-Type: text/plain; charset=ISO-8859-1 Hello Melinda, Thanks. Pls see responses below following the comments.. On Wed, Feb 15, 2012 at 6:15 PM, Melinda Shore wrote: > On 02/15/2012 11:51 AM, Thomas Narten wrote: > >> Given the confusion, I fear that a presentation in Paris would raise >> many of the same questions. That would not be a productive use of >> anyone's time. >> > > I'm not comfortable with the notion that meetings are places to > promote new work, to be honest. I prefer to think of them as > places for discussion, not presentation. I'm also unclear on what > the intended outcome is. Is the request for slots in three > different working groups in two different areas an attempt to > engage subject matter experts, or is it forum shopping? > ==> Yes, we would like to "engage subject matter experts" in order to receive comments and suggestions beyond what we have already received in dc@ietf.org. > > At this point I think getting support from people who aren't > involved with the draft is a high-ish bar - I haven't even seen > any interest, frankly. There absolutely needs to be discussion > here, first, and some clarification of both intent and why this > work is being proposed (if that's what's happening) in three > working groups. > > ==> Yes, agreed, as we mentioned before, we'll distribute the revised/updated draft to opsawg@ietf.org in addition to the other relevant lists .. > This may be a good time to remind folks to give sections 5.2 and > 5.3 of RFC 4677 a good, careful read. > ==>Thanks, and will do. > Melinda > > -- > Melinda Shore > melinda.shore@gmail.com > Software longa, hardware brevis > > ______________________________**_________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/**listinfo/opsawg > --90e6ba1efd78a9d23504b91c3c5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Melinda,
=A0
Thanks. Pls see responses below following the comments..

On Wed, Feb 15, 2012 at 6:15 PM, Melinda Shore <= span dir=3D"ltr"><melinda.sho= re@gmail.com> wrote:
On 02/15/2012 11:51 AM, Thomas Narten wrote:
Given the confusion, I fear that a pr= esentation in Paris would raise
many of the same questions. That would n= ot be a productive use of
anyone's time.

I'm not comfortable with t= he notion that meetings are places to
promote new work, to be honest. = =A0I prefer to think of them as
places for discussion, not presentation.= =A0I'm also unclear on what
the intended outcome is. =A0Is the request for slots in three
different = working groups in two different areas an attempt to
engage subject matte= r experts, or is it forum shopping?
=A0
=A0
=3D=3D> Yes, we would like to "engage subject matter experts&q= uot;=A0 in order to receive comments and suggestions beyond what we have al= ready received in dc@ietf.org.
=A0

At this point I think getting sup= port from people who aren't
involved with the draft is a high-ish ba= r - I haven't even seen
any interest, frankly. =A0There absolutely needs to be discussion
here, = first, and some clarification of both intent and why this
work is being = proposed (if that's what's happening) in three
working groups.
=A0
=3D=3D> Yes, agreed, as we mentioned before, we'll distribute t= he revised/updated draft to opsawg@ietf.= org=A0in addition to the other relevant lists ..
=A0
This may be a good time to remind fol= ks to give sections 5.2 and
5.3 of RFC 4677 a good, careful read.
=3D=3D>Thanks, and will do.
=A0
Melinda
--
Melinda Shore
melinda.shore@gmail.com
Software longa, hardware brevis=20

______________________________________________= _
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/o= psawg



=A0

--90e6ba1efd78a9d23504b91c3c5b-- From melinda.shore@gmail.com Thu Feb 16 14:22:34 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9003921E808F for ; Thu, 16 Feb 2012 14:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqYXwexbj8qe for ; Thu, 16 Feb 2012 14:22:31 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E75421E808D for ; Thu, 16 Feb 2012 14:22:31 -0800 (PST) Received: by dakl33 with SMTP id l33so2647844dak.31 for ; Thu, 16 Feb 2012 14:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5yw/WhSkiKV84DGVCTF5MhXMvVG8eTX/dNKRKbK7RNQ=; b=rWZwQqx2HJGqjxt1staalbrPReMmVE9qC6STPmdxGJmr+BSomkfnwZPsQ1QyrOMHI9 VXXaInfxF2JuazVZe6dicAnmnk3Hh4sYzMjzVzTS2J0l2EktJXaAU1D4KUUAtQCIAkCl Fjbl8yGy3JuCrdSSJuoRmlpeEGmU9yn7XniFo= Received: by 10.68.130.234 with SMTP id oh10mr12560448pbb.143.1329430951269; Thu, 16 Feb 2012 14:22:31 -0800 (PST) Received: from polypro.local (209-193-56-188-rb1.fai.dsl.dynamic.acsalaska.net. [209.193.56.188]) by mx.google.com with ESMTPS id q8sm14934662pbi.1.2012.02.16.14.22.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Feb 2012 14:22:30 -0800 (PST) Message-ID: <4F3D81A4.9010605@gmail.com> Date: Thu, 16 Feb 2012 13:22:28 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.26) Gecko/20120129 Lightning/1.0b2 Thunderbird/3.1.18 MIME-Version: 1.0 To: Bhumip Khasnabish References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> <4F3C3CAA.4050107@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Richard Bin liu , yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, opsawg-chairs@tools.ietf.org, li.dongmei@zte.com.cn, opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:22:34 -0000 On 2/16/12 1:20 PM, Bhumip Khasnabish wrote: > ==> Yes, we would like to "engage subject matter experts" in order to > receive comments and suggestions beyond what we have already received in > dc@ietf.org . Well, good. Let's see how discussions go on this mailing list, first. Melinda From vumip1@gmail.com Thu Feb 16 14:45:44 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A8821F87F8 for ; Thu, 16 Feb 2012 14:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE2dofxUcrwH for ; Thu, 16 Feb 2012 14:45:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5D721F87AD for ; Thu, 16 Feb 2012 14:45:44 -0800 (PST) Received: by iagf6 with SMTP id f6so4160431iag.31 for ; Thu, 16 Feb 2012 14:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qEYr1t8eAqwITTQDpijQ3CbCEHoYQ0myROywX7oZNA4=; b=AmoHL2E5d+HpZziow71K/QdrqO21lj2tMY5UNCkrquBJC/LaaTkVC8LzfbW0cPDph/ k3l/993cji1OsGd1wk+z5fdWW1gMM26D5NXRAa50jOE2Zgt8UU9STBta6J9CduGku+qB HbZrJH+PgivzYgjW/ejEsEbIuzbY0RsrDwzt4= MIME-Version: 1.0 Received: by 10.50.153.234 with SMTP id vj10mr5650670igb.16.1329432343759; Thu, 16 Feb 2012 14:45:43 -0800 (PST) Received: by 10.50.213.68 with HTTP; Thu, 16 Feb 2012 14:45:43 -0800 (PST) In-Reply-To: <4F3D81A4.9010605@gmail.com> References: <201202140906.q1E96rgn084695@mse02.zte.com.cn> <201202152051.q1FKpDNt026253@cichlid.raleigh.ibm.com> <4F3C3CAA.4050107@gmail.com> <4F3D81A4.9010605@gmail.com> Date: Thu, 16 Feb 2012 17:45:43 -0500 Message-ID: From: Bhumip Khasnabish To: Melinda Shore Content-Type: multipart/alternative; boundary=e89a8f3ba66d9a4a1b04b91c9646 Cc: Thomas Narten , Richard Bin liu , yu.jinghai@zte.com.cn, lizhong.jin@zte.com.cn, song.xiaoli@zte.com.cn, opsawg-chairs@tools.ietf.org, li.dongmei@zte.com.cn, opsawg@ietf.org Subject: Re: [OPSAWG] request a time slot to present VMMI-problems draft in L2VPN, L3VPN, and OPSAWG mtgs during IETF-83 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:45:44 -0000 --e89a8f3ba66d9a4a1b04b91c9646 Content-Type: text/plain; charset=ISO-8859-1 Thanks, as mentioned before, we'll distribute the updated (using comments rcvd in dc@ietf.org list) version of the VMMI-req. draft to this list as well. On Thu, Feb 16, 2012 at 5:22 PM, Melinda Shore wrote: > On 2/16/12 1:20 PM, Bhumip Khasnabish wrote: > >> ==> Yes, we would like to "engage subject matter experts" in order to >> receive comments and suggestions beyond what we have already received in >> dc@ietf.org . >> > > Well, good. Let's see how discussions go on this mailing list, > first. > > Melinda > --e89a8f3ba66d9a4a1b04b91c9646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, as mentioned before, we'll distribute the updated (using commen= ts rcvd in dc@ietf.org list) version of = the VMMI-req. draft to this list as well.

On Thu, Feb 16, 2012 at 5:22 PM, Melinda Shore <= span dir=3D"ltr"><melinda.sho= re@gmail.com> wrote:
On 2/16/12 1:20 PM, Bhumip Khasnabish wrote:
=3D=3D> Yes, we would like to "engage subject mat= ter experts" =A0in order to
receive comments and suggestions beyond= what we have already received in
dc@ietf.org <mailto:dc@ietf.org>.

Well, good. =A0Let's see how discussions go on this ma= iling list,
first.

Melinda



=A0 --e89a8f3ba66d9a4a1b04b91c9646-- From ietf@cdl.asgaard.org Thu Feb 16 18:00:15 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF0521E809E for ; Thu, 16 Feb 2012 18:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-rHII6cJVWz for ; Thu, 16 Feb 2012 18:00:11 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id EF31221E808F for ; Thu, 16 Feb 2012 18:00:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id BC22BBBDF77 for ; Fri, 17 Feb 2012 02:00:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE2yK27xJWhg for ; Fri, 17 Feb 2012 02:00:05 +0000 (UTC) Received: from fenrir.bigswitch.com (74-93-4-129-sfba.hfc.comcastbusiness.net [74.93.4.129]) by asgaard.org (Postfix) with ESMTPSA id 00506BBDF69 for ; Fri, 17 Feb 2012 02:00:04 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: multipart/signed; boundary="Apple-Mail=_E49B601F-7DB3-47AB-BC92-52B2C4C22696"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Thu, 16 Feb 2012 18:00:04 -0800 References: To: opsawg@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [OPSAWG] Fwd: [mpls] Reminder with respect to IETF IPR rules X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:00:15 -0000 --Apple-Mail=_E49B601F-7DB3-47AB-BC92-52B2C4C22696 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ross, Loa, and George did just a good job, I'm just going to shamelessly = forward this out. Chris Begin forwarded message: > From: Ross Callon > Subject: [mpls] Reminder with respect to IETF IPR rules > Date: 16 February 2012 08.37.37 -0800 > To: "mpls@ietf.org" > Cc: "mpls-chairs@tools.ietf.org" >=20 > All who participate in the IETF processes (whether by participating on = IETF > mailing lists, co-authoring documents, attending IETFs, or in other = ways) need > to be aware of the IETF rules with regard to Intellectual Property = Rights (IPR). > These rules are described in BCP79 and can be referenced through > http://www.ietf.org/ipr/policy.html.=20 >=20 > These are individual personal requirements that apply to all IETF = participants, > including participants in the MPLS working group. >=20 > As MPLS WG chairs, we would like to minimize or hopefully eliminate = late > disclosures relating to MPLS WG documents. Because of this, you may = see > "reminder" emails in the future to authors and/or to the MPLS email = list asking > people whether they know of IPR relating to specific documents. In = order to > comply with IETF processes while avoiding unnecessary delays, document = authors=20 > and contributors and anyone who knows of any IPR related to MPLS = documents are=20 > asked to take these emails seriously when they show up, and to respond = in a=20 > timely fashion. However, these reminder emails are just that: only a = reminder=20 > of existing IETF policy, and we are all bound by that policy even in = the=20 > absence of such reminder emails. >=20 > Thanks, Ross, Loa, and George > (as MPLS WG co-chairs) >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_E49B601F-7DB3-47AB-BC92-52B2C4C22696 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPPbSkAAoJEGmx2Mt/+Iw/hXYH/RuEB4jdSQj0J6dKnPRVTRmo UfqoBdh8W6mQX+2UlGbssdkctppSaegGwbjA/nZVOKmUNRxgH54ICdFLKDJ4dNgs mElra3JI4AlBOEu+DDUTq5IAa7l4ANwca2XtvUePVXTQPQOZoGrmqtsVNZziNGzu jSm/uN4hHJYZKvohiGH8olEWKsV5Xtv7StmYQvnuNXj2DqZq9pvAXoGe0vq3vD9v 8B+HEp5skxpjHr+9osXxYej+TI4cgF69O3Sr6sJTXD1VypGPDlx9oabtO4h+3bGy LSXmkpf0EzJdcdOcYdhLtj5tygz4shnCuFDVsDHupkPMCjmlu8Ta2D1u6a0ddjw= =ajuI -----END PGP SIGNATURE----- --Apple-Mail=_E49B601F-7DB3-47AB-BC92-52B2C4C22696-- From ietf@cdl.asgaard.org Sat Feb 18 10:26:31 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C68B21F85D5 for ; Sat, 18 Feb 2012 10:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ruBdamUUoOc for ; Sat, 18 Feb 2012 10:26:30 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 590FB21F857F for ; Sat, 18 Feb 2012 10:26:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 50D06BCEABE; Sat, 18 Feb 2012 18:26:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUrJMVy+o03r; Sat, 18 Feb 2012 18:26:28 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id 7BC79BCEAB0; Sat, 18 Feb 2012 18:26:28 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: multipart/signed; boundary="Apple-Mail=_32FC3A2C-19A2-44DE-80E5-A56BE241661E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Sat, 18 Feb 2012 10:26:27 -0800 Message-Id: To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: opsawg-chairs@tools.ietf.org Subject: [OPSAWG] draft-ietf-opsawg-management-stds-04 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 18:26:31 -0000 --Apple-Mail=_32FC3A2C-19A2-44DE-80E5-A56BE241661E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings all, As we didn't hear a chorus of no's, I believe we have consensus = and this draft will be sent to the IESG this weekend. Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_32FC3A2C-19A2-44DE-80E5-A56BE241661E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPP+1TAAoJEGmx2Mt/+Iw/2c4IAI3rZMS1PkYg7FscpGHGF/1i SnQhPtyT1k4vFOGkb1TIgQEOg1YQWygt7F6oSWuhcNHx9+V23ETkmAPSWHusAhtr ius6hLuvKne1TRHan8/WvltRBQaqSFJlcxuA+msQwZdJVBdqVYatuIn0AC8BuhM0 sXJraEwopNZXcbdDVJQHYrV8tprKgH/TUsVTFSmlzAhqwiI1lbaobiJP6VTqsXH1 2TUpbrZ4zbr/WAhx1zaQ53OKEeQrhwqf3jwm7hZ0ry7KGzl2HD+RZ+azywt7wE2Q 9OJlffAim8qXeHBhILKaSy45wzbAJ3mBvPxgwNteuMlDqwC87/I4gl82vWLx5Eg= =9nKa -----END PGP SIGNATURE----- --Apple-Mail=_32FC3A2C-19A2-44DE-80E5-A56BE241661E-- From internet-drafts@ietf.org Sun Feb 19 02:00:57 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B23821F85A4; Sun, 19 Feb 2012 02:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+AqpHAFNC8D; Sun, 19 Feb 2012 02:00:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F8421F859A; Sun, 19 Feb 2012 02:00:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120219100035.7749.32761.idtracker@ietfa.amsl.com> Date: Sun, 19 Feb 2012 02:00:35 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-management-stds-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 10:00:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Workin= g Group Working Group of the IETF. Title : An Overview of the IETF Network Management Standards Author(s) : Mehmet Ersue Benoit Claise Filename : draft-ietf-opsawg-management-stds-05.txt Pages : 95 Date : 2012-02-19 This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-management-stds-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsawg-management-stds-05.txt From ietf@cdl.asgaard.org Sun Feb 19 02:37:17 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FEF21F858F; Sun, 19 Feb 2012 02:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZrGg1KIca4s; Sun, 19 Feb 2012 02:37:16 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 42C4D21F8554; Sun, 19 Feb 2012 02:37:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 5E9D0BD555A; Sun, 19 Feb 2012 10:37:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JveMw3PEQjYs; Sun, 19 Feb 2012 10:37:13 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id 8AD5BBD554C; Sun, 19 Feb 2012 10:37:13 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: multipart/signed; boundary="Apple-Mail=_2AB84205-C7E5-4E7A-8148-8EC0C78D0BF4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Sun, 19 Feb 2012 02:37:13 -0800 Message-Id: <6F447D79-F626-4F5D-BFF7-B47DB9FF9916@cdl.asgaard.org> To: iesg-secretary@ietf.org, draft-ietf-opsawg-management-stds@tools.ietf.org, opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: opsawg-chairs@tools.ietf.org Subject: [OPSAWG] request to publish draft-ietf-opsawg-management-stds-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 10:37:17 -0000 --Apple-Mail=_2AB84205-C7E5-4E7A-8148-8EC0C78D0BF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings all, The Operations Area Working Group has reached consensus on = draft-ietf-opsawg-management-stds-04 and are requesting it to be published as an RFC. The RFC 4858 questions/considerations are addressed below: 1a) I will be the shepherd and I have personally reviewed the document and believe it is ready 1b) There has been adequate review both in and out of the WG 1c) I have no concerns in general, nor specifically wrt to AAA, security, XML, etc. 1d) I have no concerns about the content, and no IPR considerations have been raised 1e) There is solid consensus 1f) There has been no extreme discontent 1g) All nit's nitted 1h) no normative references, only informative 1i) The IANA consideration section exists and is consistent 1k) The MIB definition in the document passes automated validation checkers (minus the XXX as a place-holder for the RFC number) Technical Summary This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. Working group summary: There was nothing noteworthy in the working group process Any questions, please don't hesitate to contact me in the first instance, or Scott and Melinda. Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_2AB84205-C7E5-4E7A-8148-8EC0C78D0BF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPQNDZAAoJEGmx2Mt/+Iw/INgH/1T06Hl01c7Wc40l2HE6cep3 1Us3nsle9Q4JNsCgJbILOCHMtJdd55leaseq/tGQL306dEZvxPBeytGQsSPz1jrp 9hBGeyxtDe7Z5660CJtRD/tnVb4L7jAw8zKyiZ6WunRWUWengSOnXb35OeHWkulq GWp93ttfGHy0ZrlbKiIsiyeMOeHfVMD0FT63DSuGnxSSV7KXwumhkB/2iZs4r7lT BiSJSFC5wal1d1pEjTwtNpXRtteqZebTZJBWGTWTsqKuSQz+DA2GjmVbRrVBOw33 JQ3+ewQexoQipLkWGxIZRqiQfQT+LMYK1AJQy6S0TDzphlr0hafFPg0EcAoetW4= =52p9 -----END PGP SIGNATURE----- --Apple-Mail=_2AB84205-C7E5-4E7A-8148-8EC0C78D0BF4-- From victor.kuarsingh@gmail.com Mon Feb 20 20:58:13 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D010321F8534 for ; Mon, 20 Feb 2012 20:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbEmV8D7+Xzs for ; Mon, 20 Feb 2012 20:58:13 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 374BC21F8532 for ; Mon, 20 Feb 2012 20:58:13 -0800 (PST) Received: by dakl33 with SMTP id l33so6751182dak.31 for ; Mon, 20 Feb 2012 20:58:13 -0800 (PST) Received-SPF: pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.68.211.102 as permitted sender) client-ip=10.68.211.102; Authentication-Results: mr.google.com; spf=pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.68.211.102 as permitted sender) smtp.mail=victor.kuarsingh@gmail.com; dkim=pass header.i=victor.kuarsingh@gmail.com Received: from mr.google.com ([10.68.211.102]) by 10.68.211.102 with SMTP id nb6mr70327069pbc.54.1329800293128 (num_hops = 1); Mon, 20 Feb 2012 20:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=6XKmCd+t4LgVg/v6EVJDDQLdPlxw9ILemrt5yaFDNBg=; b=pOgIf0bQjvgeGfP7x3JrerxrFs2evomr9JzoC912b72uFWgI1kdh8zm5s4pmI86ZGH gQE8eaTsD1xccWROi42MmKN37DHOKacq5W7Q46bhLJxaJ2DtJRGNRl9Kq6jrK3D3tzBc 6Anj157NxUQgm/L76FQXig0uW5wn90QYpqchg= MIME-Version: 1.0 Received: by 10.68.211.102 with SMTP id nb6mr57860575pbc.54.1329800293048; Mon, 20 Feb 2012 20:58:13 -0800 (PST) Received: by 10.68.226.100 with HTTP; Mon, 20 Feb 2012 20:58:13 -0800 (PST) Date: Mon, 20 Feb 2012 23:58:13 -0500 Message-ID: From: Victor Kuarsingh To: opsawg@ietf.org Content-Type: multipart/alternative; boundary=e89a8ffba4ad16df9b04b972428a Subject: [OPSAWG] CGN Deployments Over MPLS/VPN Draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 04:58:13 -0000 --e89a8ffba4ad16df9b04b972428a Content-Type: text/plain; charset=ISO-8859-1 OPSAWG WG, I am seeking feedback and comments related to a draft which I had originally submitted a back in 2010. This draft describes a network architecture for deploying CGN based services (NAT444) using MPLS/VPNs. This [Network] architecture was developed a couple of years ago and has worked well in production (it works already). A number of other operators have shown interest in this option as it solves a number of the technical challenges when considering CGN deployments (these considerations are capture in document). Latest Posted Version - http://tools.ietf.org/html/draft-kuarsingh-lsn-deployment-06 (recently updated) Although I am not an advocate of CGNs, it will be a forced options for many operators who face IPv4 run out over the next few years. It was the goal of the authors to help ease this reality by providing an operational option which would work if needed. The document does post an option for IPv6 dual stack operation, but is somewhat focused on adding in CGN (as this is seen as a technical challenge in running state networks with preexisting IPv4 deployments). I had originally intended to discuss this in BEHAVE given that this deals with CGN, but that group was not quite suited for this type of work. v6ops is focused on IPv6 (rightfully so) and that is also not an appropriate group for this work. Therefore we are seeking input as a potential item for OPSAWG (given that this document is operationally focused and presents no new standards - only uses ones defined). So the main questions as it stands are: 1. Can we discuss this draft in this forum? 2. Comments as to whether we can adopt as WG item and/or generate discussion What I am not here to debate is whether CGN is good or bad. I think we all agree CGN is by nature bad, but when needed or forced to do so, it is essential that operators do it well and with the least impact as they can. regards, Victor K --e89a8ffba4ad16df9b04b972428a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OPSAWG WG,

I am seeking feedback and comments related to a draft whi= ch I had originally submitted a back in 2010.=A0 This draft describes a net= work architecture for deploying CGN based services (NAT444) using MPLS/VPNs= .

This [Network] architecture was developed a couple of years ago and has= worked well in production (it works already).=A0 A number of other operato= rs have shown interest in this option as it solves a number of the technica= l challenges when considering CGN deployments (these considerations are cap= ture in document).

Latest Posted Version - http://tools.ietf.org/html/draft-kuarsingh-lsn-de= ployment-06 (recently updated)

Although I am not an advocate of = CGNs, it will be a forced options for many operators who face IPv4 run out = over the next few years. It was the goal of the authors to help ease this r= eality by providing an operational option which would work if needed.=A0=A0= The document does post an option for IPv6 dual stack operation, but is som= ewhat focused on adding in CGN (as this is seen as a technical challenge in= running state networks with preexisting IPv4 deployments).

I had originally intended to discuss this in BEHAVE given that this dea= ls with CGN, but that group was not quite suited for this type of work.=A0 = v6ops is focused on IPv6 (rightfully so) and that is also not an appropriat= e group for this work.=A0 Therefore we are seeking input as a potential ite= m for OPSAWG (given that this document is operationally focused and present= s no new standards - only uses ones defined).

So the main questions as it stands are:
1. Can we discuss this draft= in this forum?
2. Comments as to whether we can adopt as WG item and/or= generate discussion

What I am not here to debate is whether CGN is = good or bad.=A0 I think we all agree CGN is by nature bad, but when needed = or forced to do so, it is essential that operators do it well and with the = least impact as they can.

regards,

Victor K

--e89a8ffba4ad16df9b04b972428a-- From randy@psg.com Mon Feb 20 22:28:31 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A3D21F84A6 for ; Mon, 20 Feb 2012 22:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr+z-5I9wegq for ; Mon, 20 Feb 2012 22:28:31 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0969D21F84A5 for ; Mon, 20 Feb 2012 22:28:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RzjDA-000Mxh-N9; Tue, 21 Feb 2012 06:28:29 +0000 Date: Tue, 21 Feb 2012 11:58:26 +0530 Message-ID: From: Randy Bush To: Victor Kuarsingh In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: opsawg@ietf.org Subject: Re: [OPSAWG] CGN Deployments Over MPLS/VPN Draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 06:28:31 -0000 > I had originally intended to discuss this in BEHAVE given that this > deals with CGN, but that group was not quite suited for this type of > work. in what way is it not suited? were the behave chairs not helpful? > v6ops is focused on IPv6 (rightfully so) and that is also not an > appropriate group for this work. quite. > Therefore we are seeking input as a potential item for OPSAWG (given > that this document is operationally focused and presents no new > standards - only uses ones defined). > 1. Can we discuss this draft in this forum? > 2. Comments as to whether we can adopt as WG item and/or generate > discussion i would personally prefer to see this in behave where the expertise on nat is concentrated. this is not a simple "how to run it or how to manage it draft." > What I am not here to debate is whether CGN is good or bad. I think we all > agree CGN is by nature bad, but when needed or forced to do so, it is > essential that operators do it well and with the least impact as they can. thank you for all the "we know this is stupid and evil but we're doing it anyway and we don't want to discuss it" statements. they are very reassuring. randy From victor.kuarsingh@gmail.com Tue Feb 21 05:37:41 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D221F87DB for ; Tue, 21 Feb 2012 05:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbIzgi5vjWVE for ; Tue, 21 Feb 2012 05:37:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD22221F87D5 for ; Tue, 21 Feb 2012 05:37:39 -0800 (PST) Received: by iagf6 with SMTP id f6so11196653iag.31 for ; Tue, 21 Feb 2012 05:37:39 -0800 (PST) Received-SPF: pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.42.152.134 as permitted sender) client-ip=10.42.152.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.42.152.134 as permitted sender) smtp.mail=victor.kuarsingh@gmail.com; dkim=pass header.i=victor.kuarsingh@gmail.com Received: from mr.google.com ([10.42.152.134]) by 10.42.152.134 with SMTP id i6mr26839121icw.27.1329831459601 (num_hops = 1); Tue, 21 Feb 2012 05:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=sl4xJWzgl2KeUGmeOymupBKZd3t4jHgrWfppUZpARxc=; b=EQPjgta6kbd50jIGhWJ0mhqElL6aP93RY3tq43uPAESjfPNY6cEcGu0HXEGrB7W7d+ /SfZvBciwwxkR3yxd+jcgLCXFJuY+gsM/oSKbExmAH0lsiXpjTQSdZVRPE8VCRVC2mX+ nlV648n1yDRsArPezE9wTVIa1FpiKgHjn2+TI= Received: by 10.42.152.134 with SMTP id i6mr21414104icw.27.1329831459549; Tue, 21 Feb 2012 05:37:39 -0800 (PST) Received: from [192.168.100.85] ([67.224.83.162]) by mx.google.com with ESMTPS id mr24sm32638972ibb.1.2012.02.21.05.37.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 05:37:38 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8J2) From: Victor Kuarsingh Date: Tue, 21 Feb 2012 08:38:18 -0500 To: Randy Bush Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] CGN Deployments Over MPLS/VPN Draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 13:37:41 -0000 Sent from my iPad On 2012-02-21, at 1:28 AM, Randy Bush wrote: >> I had originally intended to discuss this in BEHAVE given that this >> deals with CGN, but that group was not quite suited for this type of >> work. >=20 > in what way is it not suited? were the behave chairs not helpful? Chairs were always helpful. >=20 >> v6ops is focused on IPv6 (rightfully so) and that is also not an >> appropriate group for this work. >=20 > quite. >=20 >> Therefore we are seeking input as a potential item for OPSAWG (given >> that this document is operationally focused and presents no new >> standards - only uses ones defined). >=20 >> 1. Can we discuss this draft in this forum? >> 2. Comments as to whether we can adopt as WG item and/or generate >> discussion >=20 > i would personally prefer to see this in behave where the expertise on > nat is concentrated. this is not a simple "how to run it or how to > manage it draft." I had this thought as well except when looking into MPLS/VPNs and operating r= outing, we seemed to have gap. MPLS expertise are in other groups (although= we are not defining mpls here, we are using it). Operators however do ofte= n have this knowledge and are the target of this draft. However your though= ts are noted. Thanks for feedback. >=20 >> What I am not here to debate is whether CGN is good or bad. I think we a= ll >> agree CGN is by nature bad, but when needed or forced to do so, it is >> essential that operators do it well and with the least impact as they can= . >=20 > thank you for all the "we know this is stupid and evil but we're doing > it anyway and we don't want to discuss it" statements. they are very > reassuring. >=20 Understood. At least smart operators will only do such a thing with V6 plan= s and or rollout.=20 Victor K > randy >=20 From iesg-secretary@ietf.org Thu Feb 23 07:38:55 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE05521F8843; Thu, 23 Feb 2012 07:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzh2pZO6B2YH; Thu, 23 Feb 2012 07:38:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A821F8829; Thu, 23 Feb 2012 07:38:54 -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: 3.64p2 Message-ID: <20120223153854.14059.88347.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2012 07:38:54 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: (An Overview of the IETF Network Management Standards) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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: Thu, 23 Feb 2012 15:38:55 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'An Overview of the IETF Network Management Standards' as an 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 2012-03-08. 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 gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-management-stds/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-management-stds/ No IPR declarations have been submitted directly on this I-D.