From internet-drafts@ietf.org Mon May 9 09:02:27 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA2E0819; Mon, 9 May 2011 09:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTkfGUmwAs9x; Mon, 9 May 2011 09:02:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0E0E0815; Mon, 9 May 2011 09:02:27 -0700 (PDT) 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.53 Message-ID: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 09:02:27 -0700 Cc: pppext@ietf.org Subject: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-04.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:02:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Point-to-Point Protocol Extensions Wo= rking Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : James Carlson Filename : draft-ietf-pppext-trill-protocol-04.txt Pages : 7 Date : 2011-05-09 The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-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-pppext-trill-protocol-04.txt From carlsonj@workingcode.com Mon May 9 09:32:40 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CD9E08F3 for ; Mon, 9 May 2011 09:32:40 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xmTQcWV2W-4 for ; Mon, 9 May 2011 09:32:39 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id CE046E08C9 for ; Mon, 9 May 2011 09:32:37 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p49GEC66023485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 May 2011 12:14:12 -0400 (EDT) Message-ID: <4DC812D4.2010307@workingcode.com> Date: Mon, 09 May 2011 12:14:12 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: PPP Extensions References: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> In-Reply-To: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Subject: [Pppext] Working group last call for PPP TRILL [was I-D Action: draft-ietf-pppext-trill-protocol-04.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:32:40 -0000 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > Title : PPP TRILL Protocol Control Protocol > Author(s) : James Carlson > Filename : draft-ietf-pppext-trill-protocol-04.txt > Pages : 7 > Date : 2011-05-09 In this new version, I've removed stray footnote references from the stand-alone Abstract section and added a bit of detail to the Security Considerations -- specifically citing at least a few of the protocols involved. There's a slippery slope here, in that I could easily end up describing all the possible deployment scenarios and incorporating essentially all of rfc-index.txt by reference, but I hope I've struck a reasonable balance. I've left the system ID issue as an informative reference. No matter how I read this PPP document, providing system IDs is not a requirement for implementing this protocol. It _might_ be a requirement for IS-IS implementations. But the protocol described here isn't IS-IS. So, with that, I'm starting up the last call period again. Please respond by May 23rd, 2011, if you have any comments. After that date, I'll ask the IESG to consider publishing. -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Mon May 9 09:51:29 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9566E07D8 for ; Mon, 9 May 2011 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN+tmLLXs7vk for ; Mon, 9 May 2011 09:51:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A14FFE0791 for ; Mon, 9 May 2011 09:51:07 -0700 (PDT) Received: by qwc23 with SMTP id 23so4039429qwc.31 for ; Mon, 09 May 2011 09:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sodO0Y4woj8j1O6MT4VgImHgVO8XbwFRxPAJXOxih40=; b=k1NbmTW4i8/YrInhYYFtkw+ZzP++48z9rk4KBSYozOeiUWmIIAgSeoynWFhY5qHWa6 XIUwOaaht/o7zZ6j0gXJIxsQnk3Goi86lQSNgFt5jixv96eb/YCEJ4j1B6Jhkpab6TeG y/wXwgygNWe/hJ9KjelIPPzKjftr9TPvFRBbs= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Y1w/MqPSEsimeCr+ndCpXDD7aRIWLHmnoXf1KVz0jOHhqD4yLTTkAkuxNBjAkQRC/z cuRjoZs5Hb8fvv97KuKLnmOpiXVYQbwPQdijsvBXUKHiGEqIdQHC2+MHgxdkeVoVEmQK fEaZNb+CfbC3D+ISzOb7VaKKwIPofyOJt3yVA= Received: by 10.224.195.133 with SMTP id ec5mr6367928qab.100.1304958476430; Mon, 09 May 2011 09:27:56 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id m11sm5055484qcu.33.2011.05.09.09.27.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 09:27:55 -0700 (PDT) Message-ID: <4DC81609.8040200@gmail.com> Date: Mon, 09 May 2011 12:27:53 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: pppext@ietf.org References: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> In-Reply-To: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-04.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:51:30 -0000 It seems to be a small improvement on the security details. What the status of the related TRILL drafts? Are we behind? From carlsonj@workingcode.com Mon May 9 11:17:40 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAB3E06B9 for ; Mon, 9 May 2011 11:17:40 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQPfkCNfx3P2 for ; Mon, 9 May 2011 11:17:39 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 00303E06A6 for ; Mon, 9 May 2011 11:17:38 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p49I5rDQ025561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 14:05:54 -0400 (EDT) Message-ID: <4DC82D01.10004@workingcode.com> Date: Mon, 09 May 2011 14:05:53 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: William Allen Simpson References: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> <4DC81609.8040200@gmail.com> In-Reply-To: <4DC81609.8040200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-04.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 18:17:40 -0000 William Allen Simpson wrote: > It seems to be a small improvement on the security details. Thanks. > What the > status of the related TRILL drafts? Are we behind? I'm not sure I know what you mean, but the rest of them are awaiting publication now: http://www.rfc-editor.org/cluster_info.php?cid=C74 So, yes, this draft is behind the other TRILL documents, but if we get to the end of the last call successfully this time, it won't be by much. -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Mon May 9 22:00:30 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7323E066A for ; Mon, 9 May 2011 22:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crKAu74vhuxm for ; Mon, 9 May 2011 22:00:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E845E0665 for ; Mon, 9 May 2011 22:00:28 -0700 (PDT) Received: by vws12 with SMTP id 12so327919vws.31 for ; Mon, 09 May 2011 22:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=w2m8xlV59d90ltNO9Iblm3L6tmf9XoeP+6HlnpQvDGw=; b=YM2Nvn1Deap+9xoH4DABCrGv9gscCh7P7ww1MdbHfW0N3+5BTmwzNtOKTZWLSc8E5d JMC/EwcEVTRROkmBkQyjx//walegQ66KlgFDyBJ0osISz8is5qTSYh9eMkT11WH8MoPm BziP3Z39hmQXsxbZ8HlHJiOM+fK3eTjm0ACWc= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=R3nh7WLAKS46l0g1eBEEcDJK2mr7jmSj65ukV96K0tcBuNZ2fUfnPnIaXaDJnSk5TG Rla0TwDJYGFtq7ReWwhxuqsEXacjuxpLIziqU2WWngL09T4Kj4PfbFZxmLnjAIldQzlg svFCo/ZPJbDIU53Kk2vxI4+FUvbHorf83aIIw= Received: by 10.220.125.9 with SMTP id w9mr1689866vcr.198.1305003626345; Mon, 09 May 2011 22:00:26 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id v16sm872855vcr.13.2011.05.09.22.00.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 22:00:25 -0700 (PDT) Message-ID: <4DC8C668.4060204@gmail.com> Date: Tue, 10 May 2011 01:00:24 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: pppext@ietf.org References: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> <4DC812D4.2010307@workingcode.com> In-Reply-To: <4DC812D4.2010307@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] Working group last call for PPP TRILL [was I-D Action: draft-ietf-pppext-trill-protocol-04.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 05:00:30 -0000 On 5/9/11 12:14 PM, James Carlson wrote: > In this new version, I've removed stray footnote references from the > stand-alone Abstract section and added a bit of detail to the Security > Considerations -- specifically citing at least a few of the protocols > involved. There's a slippery slope here, in that I could easily end up > describing all the possible deployment scenarios and incorporating > essentially all of rfc-index.txt by reference, but I hope I've struck a > reasonable balance. > Cynical overstatement. I don't understand why PPP encryption and L2TP are mentioned without providing a reference, but let's just agree to disagree and let the RFC Editor sort it out. > I've left the system ID issue as an informative reference. No matter > how I read this PPP document, providing system IDs is not a requirement > for implementing this protocol. It _might_ be a requirement for IS-IS > implementations. But the protocol described here isn't IS-IS. > Again, I've already agreed to disagree on the previous drafts. It's OK, as long as it references the proposed solution. > So, with that, I'm starting up the last call period again. Please > respond by May 23rd, 2011, if you have any comments. After that date, > I'll ask the IESG to consider publishing. > Ship it! The IESG consideration speed is so slow these days that it's best to get it into the queue, so that they can have their say. Ah well, now I'm being cynical. From william.allen.simpson@gmail.com Mon May 9 22:01:27 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0205BE0724 for ; Mon, 9 May 2011 22:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pUzBEPf5Qvw for ; Mon, 9 May 2011 22:01:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A358E0745 for ; Mon, 9 May 2011 22:01:19 -0700 (PDT) Received: by vws12 with SMTP id 12so328223vws.31 for ; Mon, 09 May 2011 22:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=h2APPKyy3L76Viwq/0m3y41A97HxqMl9EemtoNeWpAE=; b=DiheDLODRauOGV5Iz09c1Kk/vf0Trk6fiUrqmEa+3QBkaEFIYKVfSuRiXEX6ej626D rMtoLyJ3gU8AZfurN0gzDIt79SLHAAcxc/gTbkjWTAfqunFDVQLrKd+jUOIm/L40j+88 1NVUfX07E6m+6/iplsO6yuSMvooa2xDz2rWcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=RUBipdQyy4ygbbnCYMePZYcPz0y+IGbpA6oli4kgx/WNZxsjLaJHfnsaGCjCpSmpzl R4U28b0TfdAprP+eEjC4U5HA1/v49+Z1Us15Wfd+cjovfnSWTKrCh0ilYln5FBRIzgDp t0THCqcaGzkM8NVxIvqUDpUiOFmuR+0Zcx/kI= Received: by 10.52.177.9 with SMTP id cm9mr5192344vdc.217.1305003678616; Mon, 09 May 2011 22:01:18 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id zc5sm873216vdb.43.2011.05.09.22.01.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 22:01:17 -0700 (PDT) Message-ID: <4DC8C69B.80407@gmail.com> Date: Tue, 10 May 2011 01:01:15 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: pppext@ietf.org References: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> <4DC81609.8040200@gmail.com> <4DC82D01.10004@workingcode.com> In-Reply-To: <4DC82D01.10004@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-04.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 05:01:27 -0000 On 5/9/11 2:05 PM, James Carlson wrote: > William Allen Simpson wrote: >> What the >> status of the related TRILL drafts? Are we behind? > > I'm not sure I know what you mean, but the rest of them are awaiting > publication now: > > http://www.rfc-editor.org/cluster_info.php?cid=C74 > > So, yes, this draft is behind the other TRILL documents, but if we get > to the end of the last call successfully this time, it won't be by much. > Aha! I didn't know about clusters. Thanks! From d3e3e3@gmail.com Thu May 12 21:27:27 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFACE06B1 for ; Thu, 12 May 2011 21:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTagdiD-nFGh for ; Thu, 12 May 2011 21:27:27 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D54EE0681 for ; Thu, 12 May 2011 21:27:26 -0700 (PDT) Received: by gwb20 with SMTP id 20so965856gwb.31 for ; Thu, 12 May 2011 21:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Y++ef19qZw9h+Q0r0xEkaJfrc3vqj+aKTTM/jrw/hxc=; b=P/TofzOfKi+JXpiIycrGahe2LtoQjrlqJB5LBD67yblPXiOrInSsb4s/iLJLP44WYi 6TGO1vxhz9P4d1pNsLcs+d960xtiB+uLeNapdNoogbcTioRkoFDbdBJ3tLambwyB8/Zd oOj/GuvgOlDG/1LWGIvrSdduyvVcnU64dU+cE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ItIWx7hAlsjh6/uNNSO49HZfqIju8g6ool1TzjmxwLmf86Wq/MXMGwqe+t+65TF+dr PwupRKqxQ8/LZVyEIXymzOrpOxQGy9W93Z5XZ68LnmtAovSjmZiuBzI7hx4h7RVpPofo lRXmOVGhHTcmF3KvJfRquTZWJ+4hylYr5Eu7I= Received: by 10.150.47.2 with SMTP id u2mr1021634ybu.340.1305260846117; Thu, 12 May 2011 21:27:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.42.16 with HTTP; Thu, 12 May 2011 21:27:06 -0700 (PDT) In-Reply-To: <4DC812D4.2010307@workingcode.com> References: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> <4DC812D4.2010307@workingcode.com> From: Donald Eastlake Date: Fri, 13 May 2011 00:27:06 -0400 Message-ID: To: James Carlson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: PPP Extensions Subject: Re: [Pppext] Working group last call for PPP TRILL [was I-D Action: draft-ietf-pppext-trill-protocol-04.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 04:27:27 -0000 I've reviewed the new version and think it is fine. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, May 9, 2011 at 12:14 PM, James Carlson w= rote: > internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. This draft is a work item of the Point-to-Point Protocol Extensions= Working Group of the IETF. >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : PPP TRILL Protocol Control Proto= col >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : James Carlson >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-pppext-trill-protocol-0= 4.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 7 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-09 > > In this new version, I've removed stray footnote references from the > stand-alone Abstract section and added a bit of detail to the Security > Considerations -- specifically citing at least a few of the protocols > involved. =A0There's a slippery slope here, in that I could easily end up > describing all the possible deployment scenarios and incorporating > essentially all of rfc-index.txt by reference, but I hope I've struck a > reasonable balance. > > I've left the system ID issue as an informative reference. =A0No matter > how I read this PPP document, providing system IDs is not a requirement > for implementing this protocol. =A0It _might_ be a requirement for IS-IS > implementations. =A0But the protocol described here isn't IS-IS. > > So, with that, I'm starting up the last call period again. =A0Please > respond by May 23rd, 2011, if you have any comments. =A0After that date, > I'll ask the IESG to consider publishing. > > -- > James Carlson =A0 =A0 =A0 =A0 42.703N 71.076W =A0 =A0 =A0 =A0 > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext > From vjs@calcite.rhyolite.com Mon May 16 11:34:10 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAC4E0798 for ; Mon, 16 May 2011 11:34:10 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUJjXCJJ1XeJ for ; Mon, 16 May 2011 11:34:10 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 26374E0790 for ; Mon, 16 May 2011 11:34:07 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p4GIXY5J015744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for env-from ; Mon, 16 May 2011 18:33:34 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p4GIXT6E015741 for pppext@ietf.org; Mon, 16 May 2011 18:33:29 GMT Date: Mon, 16 May 2011 18:33:29 GMT From: Vernon Schryver Message-Id: <201105161833.p4GIXT6E015741@calcite.rhyolite.com> To: pppext@ietf.org X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Subject: Re: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-04.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 18:34:11 -0000 draft-ietf-pppext-trill-protocol-04.txt looks ok to me. Vernon Schryver vjs@rhyolite.com From carlsonj@workingcode.com Tue May 17 04:34:35 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50380E07E8 for ; Tue, 17 May 2011 04:34:35 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2jrTdGl80-g for ; Tue, 17 May 2011 04:34:34 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 959FCE0716 for ; Tue, 17 May 2011 04:34:33 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4HBYP95004234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 May 2011 07:34:26 -0400 (EDT) Message-ID: <4DD25D41.6070100@workingcode.com> Date: Tue, 17 May 2011 07:34:25 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: PPP Extensions Content-Type: multipart/mixed; boundary="------------070805020100030508020906" X-DCC-SIHOPE-DCC-3-Metrics: carlson; whitelist Subject: [Pppext] [Fwd: I-D Action: draft-boucadair-pppext-portrange-option-05.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 11:34:35 -0000 This is a multi-part message in MIME format. --------------070805020100030508020906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Another update of this draft. Among the changes, the draft now says that it intends "Informational" rather than "Experimental" status, and it has switched to use vendor-specific options rather than a distinct IPCP Option number. While I continue to believe that this is not the right layer at which to do this negotiation, and thus it's still an architectural error, the move to a vendor option alleviates many of my concerns. I think we're just down to the use of the IETF as a vanity press. Perhaps if it must go forward, we can agree on some disclaimer text explaining that it's not the product of this working group and that there are serious reservations concerning its use. -- James Carlson 42.703N 71.076W --------------070805020100030508020906 Content-Type: message/rfc822; name="I-D Action: draft-boucadair-pppext-portrange-option-05.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D Action: draft-boucadair-pppext-portrange-option-05.txt.e"; filename*1="ml" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on carlson.workingcode.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.4 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::1e]) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4H8wh2r001986 for ; Tue, 17 May 2011 04:58:44 -0400 (EDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A41FE0724; Tue, 17 May 2011 01:57:52 -0700 (PDT) X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922D6E070F for ; Tue, 17 May 2011 01:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FPSax80M3BX for ; Tue, 17 May 2011 01:57:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8AFE071E for ; Tue, 17 May 2011 01:57:51 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-boucadair-pppext-portrange-option-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110517085751.27321.26495.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2011 01:57:51 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-DCC-SIHOPE-DCC-3-Metrics: carlson; whitelist A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Huawei Port Range Configuration Options for PPP IPCP Author(s) : Mohamed Boucadair Pierre Levis Gabor Bajko Teemu Savolainen Tina Tsou Filename : draft-boucadair-pppext-portrange-option-05.txt Pages : 15 Date : 2011-05-17 This document defines two Huawei IPCP (IP Configuration Protocol) Options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based ones for port delegation and forwarding purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-pppext-portrange-option-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-boucadair-pppext-portrange-option-05.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070805020100030508020906-- From william.allen.simpson@gmail.com Wed May 18 07:22:33 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271F8E0688 for ; Wed, 18 May 2011 07:22:33 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62+PbzQJJZaZ for ; Wed, 18 May 2011 07:22:32 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89831E067F for ; Wed, 18 May 2011 07:22:32 -0700 (PDT) Received: by gxk19 with SMTP id 19so676663gxk.31 for ; Wed, 18 May 2011 07:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=r5Lg2q3/3yzQasb7Y3j3cjjcVjOtKsOGipTILFGG5J0=; b=Cq5hgAkj13ddXriSk8adqQif3a6V86RuwmHO4v8J5kWmuhXifBlDVMfHcRtHYZKgEl rPSngvE59fJxWzojLXbfn3gPlhsU5tWXREpvqzbTLF7e68Z+qSBCKnszmBWmYKDe7aOq cQzm44wQRmlzRpm9+arsk14FQt5qzCoxItLb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=FEiGEbqFcfkbM43Ma2TwYNWmUWz+A0RmvwG2RB+OtYZKyV3dfnruQ+AztT4sBn7sXd S6HAA42ZXDe1pFuY0PzhKAEYjtXG0prM+frjJH7shpDsqQ9xlFMgV4egjTMumqo5DNqW GtmoSPrgxQRzw8l/pP/6KVyyNdtONTpdC4nXk= Received: by 10.236.190.167 with SMTP id e27mr2101093yhn.235.1305728551897; Wed, 18 May 2011 07:22:31 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id c62sm684443yhe.16.2011.05.18.07.22.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 07:22:31 -0700 (PDT) Message-ID: <4DD3D625.3040705@gmail.com> Date: Wed, 18 May 2011 10:22:29 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF PPP Extensions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: [Pppext] I-D Action: draft-simpson-isis-ppp-unique-01.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 14:22:33 -0000 New "Intended status", updated with various minor changes, such as Radia's request for a bit more detail of Magic Numbers. Also tossed in a MUST to SHOULD change for Don, and made the probability comparison more explicit. Ready to roll. http://tools.ietf.org/rfcdiff?url2=draft-simpson-isis-ppp-unique-01.txt === A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generation of Unique IS-IS System Identifiers Author(s) : William Allen Simpson Filename : draft-simpson-isis-ppp-unique-01.txt Pages : 8 Date : 2011-05-18 The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires unique System Identifiers at the link layer. A common practice has been to use an existing IEEE 802 MAC link-layer interface identifier. When no unique MAC is available, this document specifies automatic generation of identifiers. It is fully interoperable with systems that do not support this extension. Additionally, the extension automatically resolves conflicts between System Identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-01.txt From jon.hudson@gmail.com Thu May 19 12:48:23 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E8BE0831 for ; Thu, 19 May 2011 12:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvaFBtBNrBhN for ; Thu, 19 May 2011 12:48:22 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B556E0742 for ; Thu, 19 May 2011 12:48:21 -0700 (PDT) Received: by pzk5 with SMTP id 5so1823881pzk.31 for ; Thu, 19 May 2011 12:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=XGO1wmni0s2EYWRA8sqHyOrT/LaJkEMXLlabipG3Yak=; b=VNWwbR9aJs6wtPoJy8ZeoBtuJpsaxzRl27IKRJmSFAJQEwesiOv91dS6Tmbqc48btp qW5IQZD9IGUUsliuX6csyppae3+Rltr5/8yY9AxejmJYv9fkT5a8kSWTovl5ZyD1xlgY 89aoujz4ceCWr8zzc8vEqc6KcGvcfDxWlQ6UA= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=v4cZgvw3gAMVGXdF7RHzLJGiaDwApSgz3uPObg60TJkTzzfgs+kmXpE6Lh9i1+oIe2 OMZQQGZi7IzDl3J7GYUgo1k2EkuzwGatXPZbJZUxICZF8ECEvRtJo9Eg+yKpG62WPP+t VpvtnVAFONS0DfUsZcu9blhnqSZzPlBJhvPUE= Received: by 10.68.20.137 with SMTP id n9mr5214962pbe.121.1305834501194; Thu, 19 May 2011 12:48:21 -0700 (PDT) Received: from [10.55.84.230] ([166.205.138.219]) by mx.google.com with ESMTPS id c14sm1938355pbu.84.2011.05.19.12.48.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 12:48:20 -0700 (PDT) References: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> <4DC812D4.2010307@workingcode.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <21EE648E-C85E-4AB6-BFFF-6FEF18FC8774@gmail.com> X-Mailer: iPhone Mail (8J2) From: Jon Hudson Date: Thu, 19 May 2011 12:48:11 -0700 To: "" X-Mailman-Approved-At: Thu, 19 May 2011 12:55:21 -0700 Subject: Re: [Pppext] [rbridge] Fwd: Working group last call for PPP TRILL [was I-D Action: draft-ietf-pppext-trill-protocol-04.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 19:49:28 -0000 Reviewed latest 04 version Happy, no issues. Jon On May 13, 2011, at 10:18 AM, Donald Eastlake wrote: > Hi, >=20 > TRILL participant may be interested in the below Last Call in the > PPPEXT Working Group. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3@gmail.com >=20 > ---------- Forwarded message ---------- > From: James Carlson > Date: Mon, May 9, 2011 at 12:14 PM > Subject: [Pppext] Working group last call for PPP TRILL [was I-D > Action: draft-ietf-pppext-trill-protocol-04.txt] > To: PPP Extensions >=20 >=20 > internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Point-to-Point Protocol Extensions W= orking Group of the IETF. >>=20 >> Title : PPP TRILL Protocol Control Protocol >> Author(s) : James Carlson >> Filename : draft-ietf-pppext-trill-protocol-04.txt >> Pages : 7 >> Date : 2011-05-09 >=20 > In this new version, I've removed stray footnote references from the > stand-alone Abstract section and added a bit of detail to the Security > Considerations -- specifically citing at least a few of the protocols > involved. There's a slippery slope here, in that I could easily end up > describing all the possible deployment scenarios and incorporating > essentially all of rfc-index.txt by reference, but I hope I've struck a > reasonable balance. >=20 > I've left the system ID issue as an informative reference. No matter > how I read this PPP document, providing system IDs is not a requirement > for implementing this protocol. It _might_ be a requirement for IS-IS > implementations. But the protocol described here isn't IS-IS. >=20 > So, with that, I'm starting up the last call period again. Please > respond by May 23rd, 2011, if you have any comments. After that date, > I'll ask the IESG to consider publishing. >=20 > -- > James Carlson 42.703N 71.076W > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext >=20 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From liyizhou@huawei.com Sun May 22 22:54:27 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB2FE072C for ; Sun, 22 May 2011 22:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Xy3cVjLErdB for ; Sun, 22 May 2011 22:54:26 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A6566E071A for ; Sun, 22 May 2011 22:54:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLM00GBTWBMZJ@szxga04-in.huawei.com> for pppext@ietf.org; Mon, 23 May 2011 13:52:34 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLM0014NWBIPJ@szxga04-in.huawei.com> for pppext@ietf.org; Mon, 23 May 2011 13:52:34 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 23 May 2011 13:52:31 +0800 Received: from l63746 (10.138.41.42) by smtpscn.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 23 May 2011 13:52:32 +0800 Date: Mon, 23 May 2011 13:52:31 +0800 From: Yizhou Li In-reply-to: X-Originating-IP: [10.138.41.42] To: pppext@ietf.org Message-id: <004a01cc190d$9bafa2f0$d30ee8d0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcwRlWF4/oyEV/ldTpKHzjwTlOHqMwHd/qhA References: <20110509160227.21325.4443.idtracker@ietfa.amsl.com> <4DC812D4.2010307@workingcode.com> X-Mailman-Approved-At: Mon, 23 May 2011 06:25:41 -0700 Subject: Re: [Pppext] [rbridge] Fwd: Working group last call for PPP TRILL [was I-D Action: draft-ietf-pppext-trill-protocol-04.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 05:54:27 -0000 I am ok with the latest version. Yizhou -----Original Message----- From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On Behalf Of Donald Eastlake Sent: Saturday, May 14, 2011 1:18 AM To: rbridge@postel.org Subject: [rbridge] Fwd: [Pppext] Working group last call for PPP TRILL = [was I-D Action: draft-ietf-pppext-trill-protocol-04.txt] Hi, TRILL participant may be interested in the below Last Call in the PPPEXT Working Group. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com ---------- Forwarded message ---------- From: James Carlson Date: Mon, May 9, 2011 at 12:14 PM Subject: [Pppext] Working group last call for PPP TRILL [was I-D Action: draft-ietf-pppext-trill-protocol-04.txt] To: PPP Extensions internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : PPP TRILL Protocol Control = Protocol > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : James Carlson > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: = draft-ietf-pppext-trill-protocol-04.txt > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 7 > =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-09 In this new version, I've removed stray footnote references from the stand-alone Abstract section and added a bit of detail to the Security Considerations -- specifically citing at least a few of the protocols involved. =A0There's a slippery slope here, in that I could easily end = up describing all the possible deployment scenarios and incorporating essentially all of rfc-index.txt by reference, but I hope I've struck a reasonable balance. I've left the system ID issue as an informative reference. =A0No matter how I read this PPP document, providing system IDs is not a requirement for implementing this protocol. =A0It _might_ be a requirement for IS-IS implementations. =A0But the protocol described here isn't IS-IS. So, with that, I'm starting up the last call period again. =A0Please respond by May 23rd, 2011, if you have any comments. =A0After that date, I'll ask the IESG to consider publishing. -- James Carlson =A0 =A0 =A0 =A0 42.703N 71.076W =A0 =A0 =A0 =A0 = _______________________________________________ Pppext mailing list Pppext@ietf.org https://www.ietf.org/mailman/listinfo/pppext _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From internet-drafts@ietf.org Mon May 23 13:51:13 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC53E082F; Mon, 23 May 2011 13:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLDAIesGGXAN; Mon, 23 May 2011 13:51:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E64CE069A; Mon, 23 May 2011 13:51:13 -0700 (PDT) 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.54 Message-ID: <20110523205113.11397.97194.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2011 13:51:13 -0700 Cc: pppext@ietf.org Subject: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-05.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 20:51:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Point-to-Point Protocol Extensions Wo= rking Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : James Carlson Filename : draft-ietf-pppext-trill-protocol-05.txt Pages : 7 Date : 2011-05-23 The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-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-pppext-trill-protocol-05.txt From carlsonj@workingcode.com Mon May 23 13:54:40 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3412E07F8 for ; Mon, 23 May 2011 13:54:40 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnjo--iajRiu for ; Mon, 23 May 2011 13:54:40 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id DE684E07BF for ; Mon, 23 May 2011 13:54:38 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4NKsTdK021540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 May 2011 16:54:29 -0400 (EDT) Message-ID: <4DDAC984.4030900@workingcode.com> Date: Mon, 23 May 2011 16:54:28 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: pppext@ietf.org References: <20110523205113.11397.97194.idtracker@ietfa.amsl.com> In-Reply-To: <20110523205113.11397.97194.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------060404070407070704060903" X-DCC-x.dcc-servers-Metrics: carlson; whitelist Subject: Re: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-05.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 20:54:40 -0000 This is a multi-part message in MIME format. --------------060404070407070704060903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > Title : PPP TRILL Protocol Control Protocol > Author(s) : James Carlson > Filename : draft-ietf-pppext-trill-protocol-05.txt > Pages : 7 > Date : 2011-05-23 > > The Point-to-Point Protocol (PPP) defines a Link Control Protocol > (LCP) and a method for negotiating the use of multi-protocol traffic > over point-to-point links. This document describes PPP support for > Transparent Interconnection of Lots of Links (TRILL) Protocol, > allowing direct communication between Routing Bridges (RBridges) via > PPP links. I made a few very minor edits to pass through the id-nits checker. Document shepherd write-up is attached. -- James Carlson 42.703N 71.076W --------------060404070407070704060903 Content-Type: text/plain; name="ppp-trill-writeup.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ppp-trill-writeup.txt" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is James Carlson, also the author and WG chair. The shepherd has reviewed this version of the document and believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had review from both key WG participants (Bill Simpson, Vern Schryver) and from key participants in the TRILL WG (Jon Hudson, Yizhou Li, Don Eastlake). The document shepherd has no concerns about the depth or breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document shepherd believes that all relevant areas have reviewed the document and contributed. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns, and no known IPR. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has concurrence from the individuals who have participated in the discussion. The vast majority of the working group is typically silent, so hearing at all from them is unusual, and a positive sign for the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No threats are known. The one dissenting issue -- Bill Simpson's concern about IS-IS System ID in a deployment with no source of System ID generation -- has been dealt with successfully by creating a new draft that addresses the situation for IS-IS and adding a reference in this document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document shepherd has put the current text through all of those checks, and it satisfies the checker and has no known additional criteria to meet. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, it has references split into normative and informative. There's one downward reference, and it's in the informative reference list. This is to Bill Simpson's "Generation of Unique IS-IS System Identifiers" draft. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section is present and describes the new values introduced by this document. The registries are clearly identified and the allocation procedures are noted. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No formal languages are present in the draft. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. Working Group Summary There is consensus in the WG to publish this document. There was some discussion in the working group about IS-IS System IDs, and the draft reflects the consensus. Document Quality There is a long list of vendors implementing TRILL, but at this point there are none that have announced support for TRILL over PPP. The PPP extensions described here are trivial, and the overall system implementation issues have been discussed in detail with several of the TRILL WG participants. No significant implementation, deployment, or interoperability concerns exist. Significant reviewers include Bill Simpson, Donald Eastlake, and Vern Schryver. --------------060404070407070704060903-- From hu.fangwei@zte.com.cn Mon May 23 20:29:21 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9998CE06CD; Mon, 23 May 2011 20:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex6QaLJZ+1cY; Mon, 23 May 2011 20:29:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5397EE0696; Mon, 23 May 2011 20:29:19 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 18342794298206; Tue, 24 May 2011 11:21:18 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 69695.3257572157; Tue, 24 May 2011 11:29:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p4O3T1cF004890; Tue, 24 May 2011 11:29:01 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) In-Reply-To: <4DDAC984.4030900@workingcode.com> To: James Carlson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: hu.fangwei@zte.com.cn Date: Tue, 24 May 2011 11:28:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-24 11:29:03, Serialize complete at 2011-05-24 11:29:03 Content-Type: multipart/alternative; boundary="=_alternative 001323284825789A_=" X-MAIL: mse01.zte.com.cn p4O3T1cF004890 Cc: pppext@ietf.org, pppext-bounces@ietf.org Subject: [Pppext] reply: Re: I-D Action: draft-ietf-pppext-trill-protocol-05.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 03:29:21 -0000 This is a multipart message in MIME format. --=_alternative 001323284825789A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdC4gSXQgaXMgZmluZSBmb3IgbWUhDQoNCg0KDQoNCkph bWVzIENhcmxzb24gPGNhcmxzb25qQHdvcmtpbmdjb2RlLmNvbT4gDQq3orz+yMs6ICBwcHBleHQt Ym91bmNlc0BpZXRmLm9yZw0KMjAxMS0wNS0yNCAwNDo1NA0KDQrK1bz+yMsNCnBwcGV4dEBpZXRm Lm9yZw0Ks63LzQ0KDQrW98ziDQpSZTogW1BwcGV4dF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1w cHBleHQtdHJpbGwtcHJvdG9jb2wtMDUudHh0DQoNCg0KDQoNCg0KDQppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgd3JvdGU6DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyANCmRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBQb2ludC10by1Qb2ludCBQcm90b2NvbCANCkV4dGVuc2lvbnMg V29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gDQo+ICAgICAgICAgICAgICAgIFRpdGxlICAg ICAgICAgICA6IFBQUCBUUklMTCBQcm90b2NvbCBDb250cm9sIFByb3RvY29sDQo+ICAgICAgICAg ICAgICAgIEF1dGhvcihzKSAgICAgICA6IEphbWVzIENhcmxzb24NCj4gICAgICAgICAgICAgICAg RmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1wcHBleHQtdHJpbGwtcHJvdG9jb2wtMDUudHh0 DQo+ICAgICAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDcNCj4gICAgICAgICAgICAgICAg RGF0ZSAgICAgICAgICAgIDogMjAxMS0wNS0yMw0KPiANCj4gICAgVGhlIFBvaW50LXRvLVBvaW50 IFByb3RvY29sIChQUFApIGRlZmluZXMgYSBMaW5rIENvbnRyb2wgUHJvdG9jb2wNCj4gICAgKExD UCkgYW5kIGEgbWV0aG9kIGZvciBuZWdvdGlhdGluZyB0aGUgdXNlIG9mIG11bHRpLXByb3RvY29s IHRyYWZmaWMNCj4gICAgb3ZlciBwb2ludC10by1wb2ludCBsaW5rcy4gIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIFBQUCBzdXBwb3J0IGZvcg0KPiAgICBUcmFuc3BhcmVudCBJbnRlcmNvbm5lY3Rp b24gb2YgTG90cyBvZiBMaW5rcyAoVFJJTEwpIFByb3RvY29sLA0KPiAgICBhbGxvd2luZyBkaXJl Y3QgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFJvdXRpbmcgQnJpZGdlcyAoUkJyaWRnZXMpIHZpYQ0K PiAgICBQUFAgbGlua3MuDQoNCkkgbWFkZSBhIGZldyB2ZXJ5IG1pbm9yIGVkaXRzIHRvIHBhc3Mg dGhyb3VnaCB0aGUgaWQtbml0cyBjaGVja2VyLg0KDQpEb2N1bWVudCBzaGVwaGVyZCB3cml0ZS11 cCBpcyBhdHRhY2hlZC4NCg0KLS0gDQpKYW1lcyBDYXJsc29uICAgICAgICAgNDIuNzAzTiA3MS4w NzZXICAgICAgICAgPGNhcmxzb25qQHdvcmtpbmdjb2RlLmNvbT4NCiAgKDEuYSkgV2hvIGlzIHRo ZSBEb2N1bWVudCBTaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVudD8gSGFzIHRoZQ0KICAgICAgICBE b2N1bWVudCBTaGVwaGVyZCBwZXJzb25hbGx5IHJldmlld2VkIHRoaXMgdmVyc2lvbiBvZiB0aGUg DQogICAgICAgIGRvY3VtZW50IGFuZCwgaW4gcGFydGljdWxhciwgZG9lcyBoZSBvciBzaGUgYmVs aWV2ZSB0aGlzIA0KICAgICAgICB2ZXJzaW9uIGlzIHJlYWR5IGZvciBmb3J3YXJkaW5nIHRvIHRo ZSBJRVNHIGZvciBwdWJsaWNhdGlvbj8gDQoNCiAgICAgICAgICAgICAgICAgVGhlIGRvY3VtZW50 IHNoZXBoZXJkIGlzIEphbWVzIENhcmxzb24sIGFsc28gdGhlIGF1dGhvciANCmFuZCBXRw0KICAg ICAgICAgICAgICAgICBjaGFpci4gIFRoZSBzaGVwaGVyZCBoYXMgcmV2aWV3ZWQgdGhpcyB2ZXJz aW9uIG9mIHRoZSANCmRvY3VtZW50DQogICAgICAgICAgICAgICAgIGFuZCBiZWxpZXZlcyBpdCBp cyByZWFkeSBmb3IgZm9yd2FyZGluZyB0byB0aGUgSUVTRyBmb3INCiAgICAgICAgICAgICAgICAg cHVibGljYXRpb24uDQoNCiAgKDEuYikgSGFzIHRoZSBkb2N1bWVudCBoYWQgYWRlcXVhdGUgcmV2 aWV3IGJvdGggZnJvbSBrZXkgV0cgbWVtYmVycyANCiAgICAgICAgYW5kIGZyb20ga2V5IG5vbi1X RyBtZW1iZXJzPyBEb2VzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZlIA0KICAgICAgICBhbnkg Y29uY2VybnMgYWJvdXQgdGhlIGRlcHRoIG9yIGJyZWFkdGggb2YgdGhlIHJldmlld3MgdGhhdCAN CiAgICAgICAgaGF2ZSBiZWVuIHBlcmZvcm1lZD8gDQoNCiAgICAgICAgICAgICAgICAgVGhlIGRv Y3VtZW50IGhhcyBoYWQgcmV2aWV3IGZyb20gYm90aCBrZXkgV0cgcGFydGljaXBhbnRzDQogICAg ICAgICAgICAgICAgIChCaWxsIFNpbXBzb24sIFZlcm4gU2Nocnl2ZXIpIGFuZCBmcm9tIGtleSBw YXJ0aWNpcGFudHMgDQppbiB0aGUNCiAgICAgICAgICAgICAgICAgVFJJTEwgV0cgKEpvbiBIdWRz b24sIFlpemhvdSBMaSwgRG9uIEVhc3RsYWtlKS4NCg0KICAgICAgICAgICAgICAgICBUaGUgZG9j dW1lbnQgc2hlcGhlcmQgaGFzIG5vIGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvcg0KICAgICAg ICAgICAgICAgICBicmVhZHRoIG9mIHRoZSByZXZpZXdzLg0KDQogICgxLmMpIERvZXMgdGhlIERv Y3VtZW50IFNoZXBoZXJkIGhhdmUgY29uY2VybnMgdGhhdCB0aGUgZG9jdW1lbnQgDQogICAgICAg IG5lZWRzIG1vcmUgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGJyb2FkZXIgcGVyc3BlY3Rp dmUsIA0KICAgICAgICBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxleGl0eSwgc29t ZW9uZSBmYW1pbGlhciB3aXRoIA0KICAgICAgICBBQUEsIGludGVybmF0aW9uYWxpemF0aW9uIG9y IFhNTD8gDQoNCiAgICAgICAgICAgICAgICAgVGhlIGRvY3VtZW50IHNoZXBoZXJkIGJlbGlldmVz IHRoYXQgYWxsIHJlbGV2YW50IGFyZWFzIA0KaGF2ZQ0KICAgICAgICAgICAgICAgICByZXZpZXdl ZCB0aGUgZG9jdW1lbnQgYW5kIGNvbnRyaWJ1dGVkLg0KDQogICgxLmQpIERvZXMgdGhlIERvY3Vt ZW50IFNoZXBoZXJkIGhhdmUgYW55IHNwZWNpZmljIGNvbmNlcm5zIG9yIA0KICAgICAgICBpc3N1 ZXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IN CiAgICAgICAgYW5kL29yIHRoZSBJRVNHIHNob3VsZCBiZSBhd2FyZSBvZj8gRm9yIGV4YW1wbGUs IHBlcmhhcHMgaGUgDQogICAgICAgIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlIHdpdGggY2VydGFp biBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yIA0KICAgICAgICBoYXMgY29uY2VybnMgd2hldGhl ciB0aGVyZSByZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4gSW4gYW55IA0KICAgICAgICBldmVudCwg aWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhvc2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVkIA0K ICAgICAgICB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0 YWlsIHRob3NlIA0KICAgICAgICBjb25jZXJucyBoZXJlLiBIYXMgYW4gSVBSIGRpc2Nsb3N1cmUg cmVsYXRlZCB0byB0aGlzIGRvY3VtZW50IA0KICAgICAgICBiZWVuIGZpbGVkPyBJZiBzbywgcGxl YXNlIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gdGhlIA0KICAgICAgICBkaXNjbG9zdXJlIGFuZCBz dW1tYXJpemUgdGhlIFdHIGRpc2N1c3Npb24gYW5kIGNvbmNsdXNpb24gb24gDQogICAgICAgIHRo aXMgaXNzdWUuIA0KDQogICAgICAgICAgICAgICAgIE5vIHNwZWNpZmljIGNvbmNlcm5zLCBhbmQg bm8ga25vd24gSVBSLg0KDQogICgxLmUpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vuc3VzIGJl aGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0IA0KICAgICAgICByZXByZXNlbnQgdGhlIHN0cm9u ZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCANCiAgICAgICAgb3RoZXJz IGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cgYXMgYSB3aG9sZSB1bmRlcnN0YW5kIGFuZCAN CiAgICAgICAgYWdyZWUgd2l0aCBpdD8gDQoNCiAgICAgICAgICAgICAgICAgVGhlIGRvY3VtZW50 IGhhcyBjb25jdXJyZW5jZSBmcm9tIHRoZSBpbmRpdmlkdWFscyB3aG8gDQpoYXZlDQogICAgICAg ICAgICAgICAgIHBhcnRpY2lwYXRlZCBpbiB0aGUgZGlzY3Vzc2lvbi4NCg0KICAgICAgICAgICAg ICAgICBUaGUgdmFzdCBtYWpvcml0eSBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0eXBpY2FsbHkg DQpzaWxlbnQsIHNvDQogICAgICAgICAgICAgICAgIGhlYXJpbmcgYXQgYWxsIGZyb20gdGhlbSBp cyB1bnVzdWFsLCBhbmQgYSBwb3NpdGl2ZSBzaWduIA0KZm9yDQogICAgICAgICAgICAgICAgIHRo ZSBkb2N1bWVudC4NCg0KICAoMS5mKSBIYXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9y IG90aGVyd2lzZSBpbmRpY2F0ZWQgZXh0cmVtZSANCiAgICAgICAgZGlzY29udGVudD8gSWYgc28s IHBsZWFzZSBzdW1tYXJpc2UgdGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluIA0KICAgICAgICBzZXBh cmF0ZSBlbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvci4gKEl0 IA0KICAgICAgICBzaG91bGQgYmUgaW4gYSBzZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVl c3Rpb25uYWlyZSBpcyANCiAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJRCBUcmFja2VyLikgDQoN CiAgICAgICAgICAgICAgICAgTm8gdGhyZWF0cyBhcmUga25vd24uICBUaGUgb25lIGRpc3NlbnRp bmcgaXNzdWUgLS0gQmlsbA0KICAgICAgICAgICAgICAgICBTaW1wc29uJ3MgY29uY2VybiBhYm91 dCBJUy1JUyBTeXN0ZW0gSUQgaW4gYSBkZXBsb3ltZW50IA0Kd2l0aA0KICAgICAgICAgICAgICAg ICBubyBzb3VyY2Ugb2YgU3lzdGVtIElEIGdlbmVyYXRpb24gLS0gaGFzIGJlZW4gZGVhbHQgd2l0 aA0KICAgICAgICAgICAgICAgICBzdWNjZXNzZnVsbHkgYnkgY3JlYXRpbmcgYSBuZXcgZHJhZnQg dGhhdCBhZGRyZXNzZXMgdGhlDQogICAgICAgICAgICAgICAgIHNpdHVhdGlvbiBmb3IgSVMtSVMg YW5kIGFkZGluZyBhIHJlZmVyZW5jZSBpbiB0aGlzIA0KZG9jdW1lbnQuDQoNCiAgKDEuZykgSGFz IHRoZSBEb2N1bWVudCBTaGVwaGVyZCBwZXJzb25hbGx5IHZlcmlmaWVkIHRoYXQgdGhlIA0KICAg ICAgICBkb2N1bWVudCBzYXRpc2ZpZXMgYWxsIElEIG5pdHM/IChTZWUgdGhlIEludGVybmV0LURy YWZ0cyBDaGVja2xpc3QgDQoNCiAgICAgICAgYW5kIGh0dHA6Ly90b29scy5pZXRmLm9yZy90b29s cy9pZG5pdHMvKS4gQm9pbGVycGxhdGUgY2hlY2tzIGFyZSANCiAgICAgICAgbm90IGVub3VnaDsg dGhpcyBjaGVjayBuZWVkcyB0byBiZSB0aG9yb3VnaC4gSGFzIHRoZSBkb2N1bWVudCANCiAgICAg ICAgbWV0IGFsbCBmb3JtYWwgcmV2aWV3IGNyaXRlcmlhIGl0IG5lZWRzIHRvLCBzdWNoIGFzIHRo ZSBNSUIgDQogICAgICAgIERvY3RvciwgbWVkaWEgdHlwZSBhbmQgVVJJIHR5cGUgcmV2aWV3cz8g DQoNCiAgICAgICAgICAgICAgICAgVGhlIGRvY3VtZW50IHNoZXBoZXJkIGhhcyBwdXQgdGhlIGN1 cnJlbnQgdGV4dCB0aHJvdWdoIA0KYWxsIG9mDQogICAgICAgICAgICAgICAgIHRob3NlIGNoZWNr cywgYW5kIGl0IHNhdGlzZmllcyB0aGUgY2hlY2tlciBhbmQgaGFzIG5vIA0Ka25vd24NCiAgICAg ICAgICAgICAgICAgYWRkaXRpb25hbCBjcml0ZXJpYSB0byBtZWV0Lg0KDQogICgxLmgpIEhhcyB0 aGUgZG9jdW1lbnQgc3BsaXQgaXRzIHJlZmVyZW5jZXMgaW50byBub3JtYXRpdmUgYW5kIA0KICAg ICAgICBpbmZvcm1hdGl2ZT8gQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRvY3Vt ZW50cyB0aGF0IA0KICAgICAgICBhcmUgbm90IHJlYWR5IGZvciBhZHZhbmNlbWVudCBvciBhcmUg b3RoZXJ3aXNlIGluIGFuIHVuY2xlYXIgDQogICAgICAgIHN0YXRlPyBJZiBzdWNoIG5vcm1hdGl2 ZSByZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZSANCiAgICAgICAgc3RyYXRlZ3kgZm9yIHRo ZWlyIGNvbXBsZXRpb24/IEFyZSB0aGVyZSBub3JtYXRpdmUgcmVmZXJlbmNlcyANCiAgICAgICAg dGhhdCBhcmUgZG93bndhcmQgcmVmZXJlbmNlcywgYXMgZGVzY3JpYmVkIGluIFtSRkMzOTY3XT8g SWYgDQogICAgICAgIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3VwcG9y dCB0aGUgQXJlYSANCiAgICAgICAgRGlyZWN0b3IgaW4gdGhlIExhc3QgQ2FsbCBwcm9jZWR1cmUg Zm9yIHRoZW0gW1JGQzM5NjddLg0KDQogICAgICAgICAgICAgICAgIFllcywgaXQgaGFzIHJlZmVy ZW5jZXMgc3BsaXQgaW50byBub3JtYXRpdmUgYW5kIA0KaW5mb3JtYXRpdmUuDQoNCiAgICAgICAg ICAgICAgICAgVGhlcmUncyBvbmUgZG93bndhcmQgcmVmZXJlbmNlLCBhbmQgaXQncyBpbiB0aGUg DQppbmZvcm1hdGl2ZQ0KICAgICAgICAgICAgICAgICByZWZlcmVuY2UgbGlzdC4gIFRoaXMgaXMg dG8gQmlsbCBTaW1wc29uJ3MgIkdlbmVyYXRpb24gb2YNCiAgICAgICAgICAgICAgICAgVW5pcXVl IElTLUlTIFN5c3RlbSBJZGVudGlmaWVycyIgZHJhZnQuDQoNCiAgKDEuaSkgSGFzIHRoZSBEb2N1 bWVudCBTaGVwaGVyZCB2ZXJpZmllZCB0aGF0IHRoZSBkb2N1bWVudCBJQU5BIA0KICAgICAgICBj b25zaWRlcmF0aW9uIHNlY3Rpb24gZXhpc3RzIGFuZCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGJv ZHkgDQogICAgICAgIG9mIHRoZSBkb2N1bWVudD8gSWYgdGhlIGRvY3VtZW50IHNwZWNpZmllcyBw cm90b2NvbCANCiAgICAgICAgZXh0ZW5zaW9ucywgYXJlIHJlc2VydmF0aW9ucyByZXF1ZXN0ZWQg aW4gYXBwcm9wcmlhdGUgSUFOQSANCiAgICAgICAgcmVnaXN0cmllcz8gQXJlIHRoZSBJQU5BIHJl Z2lzdHJpZXMgY2xlYXJseSBpZGVudGlmaWVkPyBJZiANCiAgICAgICAgdGhlIGRvY3VtZW50IGNy ZWF0ZXMgYSBuZXcgcmVnaXN0cnksIGRvZXMgaXQgZGVmaW5lIHRoZSANCiAgICAgICAgcHJvcG9z ZWQgaW5pdGlhbCBjb250ZW50cyBvZiB0aGUgcmVnaXN0cnkgYW5kIGFuIGFsbG9jYXRpb24gDQog ICAgICAgIHByb2NlZHVyZSBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/IERvZXMgaXQgc3VnZ2Vz dCBhIA0KICAgICAgICByZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0cnk/IFNlZSBb UkZDNTIyNl0uIElmIHRoZSANCiAgICAgICAgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIEV4cGVydCBS ZXZpZXcgcHJvY2VzcyBoYXMgU2hlcGhlcmQgDQogICAgICAgIGNvbmZlcnJlZCB3aXRoIHRoZSBS ZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQgdGhlIElFU0cgDQogICAgICAgIGNhbiBh cHBvaW50IHRoZSBuZWVkZWQgRXhwZXJ0IGR1cmluZyB0aGUgSUVTRyBFdmFsdWF0aW9uPyANCg0K ICAgICAgICAgICAgICAgICBUaGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHByZXNl bnQgYW5kIGRlc2NyaWJlcyANCnRoZQ0KICAgICAgICAgICAgICAgICBuZXcgdmFsdWVzIGludHJv ZHVjZWQgYnkgdGhpcyBkb2N1bWVudC4gIFRoZSByZWdpc3RyaWVzIA0KYXJlDQogICAgICAgICAg ICAgICAgIGNsZWFybHkgaWRlbnRpZmllZCBhbmQgdGhlIGFsbG9jYXRpb24gcHJvY2VkdXJlcyBh cmUgDQpub3RlZC4NCg0KICAoMS5qKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHZlcmlmaWVk IHRoYXQgc2VjdGlvbnMgb2YgdGhlIA0KICAgICAgICBkb2N1bWVudCB0aGF0IGFyZSB3cml0dGVu IGluIGEgZm9ybWFsIGxhbmd1YWdlLCBzdWNoIGFzIFhNTCANCiAgICAgICAgY29kZSwgQk5GIHJ1 bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0Yy4sIHZhbGlkYXRlIGNvcnJlY3RseSBpbiANCiAgICAg ICAgYW4gYXV0b21hdGVkIGNoZWNrZXI/IA0KDQogICAgICAgICAgICAgICAgIE5vIGZvcm1hbCBs YW5ndWFnZXMgYXJlIHByZXNlbnQgaW4gdGhlIGRyYWZ0Lg0KDQogICgxLmspIFRoZSBJRVNHIGFw cHJvdmFsIGFubm91bmNlbWVudCBpbmNsdWRlcyBhIERvY3VtZW50IA0KICAgICAgICBBbm5vdW5j ZW1lbnQgV3JpdGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2ggYSBEb2N1bWVudCANCiAgICAgICAg QW5ub3VuY2VtZW50IFdyaXRlLVVwPyBSZWNlbnQgZXhhbXBsZXMgY2FuIGJlIGZvdW5kIGluIHRo ZQ0KICAgICAgICAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHByb3ZlZCBkb2N1bWVudHMu IFRoZSBhcHByb3ZhbCANCiAgICAgICAgYW5ub3VuY2VtZW50IGNvbnRhaW5zIHRoZSBmb2xsb3dp bmcgc2VjdGlvbnM6IA0KDQogICAgIFRlY2huaWNhbCBTdW1tYXJ5IA0KDQogICAgICAgICAgICAg ICAgIFRoZSBQb2ludC10by1Qb2ludCBQcm90b2NvbCAoUFBQKSBkZWZpbmVzIGEgTGluayBDb250 cm9sDQogICAgICAgICAgICAgICAgIFByb3RvY29sIChMQ1ApIGFuZCBhIG1ldGhvZCBmb3IgbmVn b3RpYXRpbmcgdGhlIHVzZSBvZg0KICAgICAgICAgICAgICAgICBtdWx0aS1wcm90b2NvbCB0cmFm ZmljIG92ZXIgcG9pbnQtdG8tcG9pbnQgbGlua3MuICBUaGlzDQogICAgICAgICAgICAgICAgIGRv Y3VtZW50IGRlc2NyaWJlcyBQUFAgc3VwcG9ydCBmb3IgVHJhbnNwYXJlbnQgDQpJbnRlcmNvbm5l Y3Rpb24NCiAgICAgICAgICAgICAgICAgb2YgTG90cyBvZiBMaW5rcyAoVFJJTEwpIFByb3RvY29s LCBhbGxvd2luZyBkaXJlY3QNCiAgICAgICAgICAgICAgICAgY29tbXVuaWNhdGlvbiBiZXR3ZWVu IFJvdXRpbmcgQnJpZGdlcyAoUkJyaWRnZXMpIHZpYSBQUFANCiAgICAgICAgICAgICAgICAgbGlu a3MuDQoNCiAgICAgV29ya2luZyBHcm91cCBTdW1tYXJ5IA0KDQogICAgICAgICAgICAgICAgIFRo ZXJlIGlzIGNvbnNlbnN1cyBpbiB0aGUgV0cgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50LiANClRo ZXJlDQogICAgICAgICAgICAgICAgIHdhcyBzb21lIGRpc2N1c3Npb24gaW4gdGhlIHdvcmtpbmcg Z3JvdXAgYWJvdXQgSVMtSVMgDQpTeXN0ZW0NCiAgICAgICAgICAgICAgICAgSURzLCBhbmQgdGhl IGRyYWZ0IHJlZmxlY3RzIHRoZSBjb25zZW5zdXMuDQoNCiAgICAgRG9jdW1lbnQgUXVhbGl0eSAN Cg0KICAgICAgICAgICAgICAgICBUaGVyZSBpcyBhIGxvbmcgbGlzdCBvZiB2ZW5kb3JzIGltcGxl bWVudGluZyBUUklMTCwgYnV0IA0KYXQNCiAgICAgICAgICAgICAgICAgdGhpcyBwb2ludCB0aGVy ZSBhcmUgbm9uZSB0aGF0IGhhdmUgYW5ub3VuY2VkIHN1cHBvcnQgZm9yDQogICAgICAgICAgICAg ICAgIFRSSUxMIG92ZXIgUFBQLiAgVGhlIFBQUCBleHRlbnNpb25zIGRlc2NyaWJlZCBoZXJlIGFy ZQ0KICAgICAgICAgICAgICAgICB0cml2aWFsLCBhbmQgdGhlIG92ZXJhbGwgc3lzdGVtIGltcGxl bWVudGF0aW9uIGlzc3VlcyANCmhhdmUNCiAgICAgICAgICAgICAgICAgYmVlbiBkaXNjdXNzZWQg aW4gZGV0YWlsIHdpdGggc2V2ZXJhbCBvZiB0aGUgVFJJTEwgV0cNCiAgICAgICAgICAgICAgICAg cGFydGljaXBhbnRzLiAgTm8gc2lnbmlmaWNhbnQgaW1wbGVtZW50YXRpb24sIGRlcGxveW1lbnQs IA0Kb3INCiAgICAgICAgICAgICAgICAgaW50ZXJvcGVyYWJpbGl0eSBjb25jZXJucyBleGlzdC4N Cg0KICAgICAgICAgICAgICAgICBTaWduaWZpY2FudCByZXZpZXdlcnMgaW5jbHVkZSBCaWxsIFNp bXBzb24sIERvbmFsZCANCkVhc3RsYWtlLA0KICAgICAgICAgICAgICAgICBhbmQgVmVybiBTY2hy eXZlci4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQ cHBleHQgbWFpbGluZyBsaXN0DQpQcHBleHRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcHBwZXh0DQoNCg0K --=_alternative 001323284825789A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSByZXZpZXdlZCB0aGUg ZHJhZnQuIEl0IGlzIGZpbmUNCmZvciBtZSE8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SmFtZXMgQ2FybHNvbiAmbHQ7Y2FybHNvbmpA d29ya2luZ2NvZGUuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwcHBleHQtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTA1LTI0IDA0OjU0PC9mb250 Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+ yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnBwcGV4 dEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+UmU6IFtQcHBleHRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcHBwZXh0LXRy aWxsLXByb3RvY29sLTA1LnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9Mj48dHQ+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOjxicj4N CiZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzDQpkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgUG9pbnQtdG8tUG9pbnQgUHJvdG9jb2wgRXh0ZW5zaW9ucw0KV29ya2luZyBHcm91cCBv ZiB0aGUgSUVURi48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZQ0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFBQUCBUUklMTCBQcm90b2NvbCBDb250cm9sIFByb3Rv Y29sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0F1dGhvcihzKQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBKYW1l cyBDYXJsc29uPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZpbGVuYW1lDQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs6IGRyYWZ0LWlldGYtcHBwZXh0LXRyaWxsLXByb3RvY29sLTA1LnR4dDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtQYWdlcw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDc8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7RGF0ZQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6 IDIwMTEtMDUtMjM8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1RoZSBQb2ludC10 by1Qb2ludCBQcm90b2NvbCAoUFBQKSBkZWZpbmVzIGEgTGluayBDb250cm9sDQpQcm90b2NvbDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyhMQ1ApIGFuZCBhIG1ldGhvZCBmb3IgbmVnb3RpYXRpbmcg dGhlIHVzZSBvZiBtdWx0aS1wcm90b2NvbA0KdHJhZmZpYzxicj4NCiZndDsgJm5ic3A7ICZuYnNw O292ZXIgcG9pbnQtdG8tcG9pbnQgbGlua3MuICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVz DQpQUFAgc3VwcG9ydCBmb3I8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUcmFuc3BhcmVudCBJbnRl cmNvbm5lY3Rpb24gb2YgTG90cyBvZiBMaW5rcyAoVFJJTEwpDQpQcm90b2NvbCw8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDthbGxvd2luZyBkaXJlY3QgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFJvdXRp bmcgQnJpZGdlcw0KKFJCcmlkZ2VzKSB2aWE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtQUFAgbGlu a3MuPGJyPg0KPGJyPg0KSSBtYWRlIGEgZmV3IHZlcnkgbWlub3IgZWRpdHMgdG8gcGFzcyB0aHJv dWdoIHRoZSBpZC1uaXRzIGNoZWNrZXIuPGJyPg0KPGJyPg0KRG9jdW1lbnQgc2hlcGhlcmQgd3Jp dGUtdXAgaXMgYXR0YWNoZWQuPGJyPg0KPGJyPg0KLS0gPGJyPg0KSmFtZXMgQ2FybHNvbiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNDIuNzAzTiA3MS4wNzZXICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJmx0O2Nhcmxzb25qQHdvcmtpbmdjb2RlLmNvbSZndDs8YnI+DQogJm5ic3A7 KDEuYSkgV2hvIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVudD8gSGFz IHRoZTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtEb2N1bWVudCBTaGVwaGVyZCBw ZXJzb25hbGx5IHJldmlld2VkIHRoaXMNCnZlcnNpb24gb2YgdGhlIDxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtkb2N1bWVudCBhbmQsIGluIHBhcnRpY3VsYXIsIGRvZXMgaGUgb3Ig c2hlDQpiZWxpZXZlIHRoaXMgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3ZlcnNp b24gaXMgcmVhZHkgZm9yIGZvcndhcmRpbmcgdG8gdGhlIElFU0cNCmZvciBwdWJsaWNhdGlvbj8g PGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNClRoZSBkb2N1bWVudCBzaGVwaGVyZCBpcyBKYW1lcyBDYXJsc29uLCBhbHNv IHRoZSBhdXRob3IgYW5kIFdHPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmNoYWlyLiAmbmJzcDtUaGUgc2hlcGhlcmQgaGFzIHJl dmlld2VkIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQ8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KYW5kIGJlbGlldmVzIGl0 IGlzIHJlYWR5IGZvciBmb3J3YXJkaW5nIHRvIHRoZSBJRVNHIGZvcjxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpwdWJsaWNhdGlv bi48YnI+DQo8YnI+DQogJm5ic3A7KDEuYikgSGFzIHRoZSBkb2N1bWVudCBoYWQgYWRlcXVhdGUg cmV2aWV3IGJvdGggZnJvbSBrZXkgV0cgbWVtYmVycw0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2FuZCBmcm9tIGtleSBub24tV0cgbWVtYmVycz8gRG9lcyB0aGUgRG9jdW1lbnQN ClNoZXBoZXJkIGhhdmUgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FueSBjb25j ZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJlYWR0aCBvZg0KdGhlIHJldmlld3MgdGhhdCA8YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aGF2ZSBiZWVuIHBlcmZvcm1lZD8gJm5ic3A7 PGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNClRoZSBkb2N1bWVudCBoYXMgaGFkIHJldmlldyBmcm9tIGJvdGgga2V5IFdH IHBhcnRpY2lwYW50czxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQooQmlsbCBTaW1wc29uLCBWZXJuIFNjaHJ5dmVyKSBhbmQgZnJv bSBrZXkgcGFydGljaXBhbnRzIGluIHRoZTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUUklMTCBXRyAoSm9uIEh1ZHNvbiwgWWl6 aG91IExpLCBEb24gRWFzdGxha2UpLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUaGUgZG9jdW1lbnQgc2hlcGhlcmQg aGFzIG5vIGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvcjxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpicmVhZHRoIG9mIHRoZSBy ZXZpZXdzLjxicj4NCjxicj4NCiAmbmJzcDsoMS5jKSBEb2VzIHRoZSBEb2N1bWVudCBTaGVwaGVy ZCBoYXZlIGNvbmNlcm5zIHRoYXQgdGhlIGRvY3VtZW50DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7bmVlZHMgbW9yZSByZXZpZXcgZnJvbSBhIHBhcnRpY3VsYXIgb3IgYnJvYWRl cg0KcGVyc3BlY3RpdmUsIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlLmcuLCBz ZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxleGl0eSwgc29tZW9uZQ0KZmFtaWxpYXIgd2l0aCA8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QUFBLCBpbnRlcm5hdGlvbmFsaXphdGlv biBvciBYTUw/IDxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUaGUgZG9jdW1lbnQgc2hlcGhlcmQgYmVsaWV2ZXMgdGhh dCBhbGwgcmVsZXZhbnQgYXJlYXMgaGF2ZTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpyZXZpZXdlZCB0aGUgZG9jdW1lbnQgYW5k IGNvbnRyaWJ1dGVkLjxicj4NCjxicj4NCiAmbmJzcDsoMS5kKSBEb2VzIHRoZSBEb2N1bWVudCBT aGVwaGVyZCBoYXZlIGFueSBzcGVjaWZpYyBjb25jZXJucyBvciA8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7aXNzdWVzIHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBSZXNwb25z aWJsZQ0KQXJlYSBEaXJlY3Rvcjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbmQv b3IgdGhlIElFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3IgZXhhbXBsZSwNCnBlcmhhcHMgaGUg PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29yIHNoZSBpcyB1bmNvbWZvcnRhYmxl IHdpdGggY2VydGFpbiBwYXJ0cw0Kb2YgdGhlIGRvY3VtZW50LCBvciA8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7aGFzIGNvbmNlcm5zIHdoZXRoZXIgdGhlcmUgcmVhbGx5IGlzIGEg bmVlZA0KZm9yIGl0LiBJbiBhbnkgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V2 ZW50LCBpZiB0aGUgV0cgaGFzIGRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMNCmFuZCBoYXMgaW5kaWNh dGVkIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGF0IGl0IHN0aWxsIHdpc2hl cyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwNCmRldGFpbCB0aG9zZSA8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Y29uY2VybnMgaGVyZS4gSGFzIGFuIElQUiBkaXNjbG9zdXJlIHJl bGF0ZWQNCnRvIHRoaXMgZG9jdW1lbnQgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2JlZW4gZmlsZWQ/IElmIHNvLCBwbGVhc2UgaW5jbHVkZSBhIHJlZmVyZW5jZQ0KdG8gdGhlIDxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkaXNjbG9zdXJlIGFuZCBzdW1tYXJpemUg dGhlIFdHIGRpc2N1c3Npb24NCmFuZCBjb25jbHVzaW9uIG9uIDxicj4NCiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt0aGlzIGlzc3VlLiA8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KTm8gc3BlY2lmaWMgY29uY2Vy bnMsIGFuZCBubyBrbm93biBJUFIuPGJyPg0KPGJyPg0KICZuYnNwOygxLmUpIEhvdyBzb2xpZCBp cyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0DQo8YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVu Y2Ugb2YgYSBmZXcgaW5kaXZpZHVhbHMsDQp3aXRoIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBhcyBhIHdob2xlDQp1 bmRlcnN0YW5kIGFuZCA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWdyZWUgd2l0 aCBpdD8gJm5ic3A7IDxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUaGUgZG9jdW1lbnQgaGFzIGNvbmN1cnJlbmNlIGZy b20gdGhlIGluZGl2aWR1YWxzIHdobyBoYXZlPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnBhcnRpY2lwYXRlZCBpbiB0aGUgZGlz Y3Vzc2lvbi48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhlIHZhc3QgbWFqb3JpdHkgb2YgdGhlIHdvcmtpbmcgZ3Jv dXAgaXMgdHlwaWNhbGx5IHNpbGVudCwgc288YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KaGVhcmluZyBhdCBhbGwgZnJvbSB0aGVt IGlzIHVudXN1YWwsIGFuZCBhIHBvc2l0aXZlIHNpZ24gZm9yPGJyPg0KICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnRoZSBkb2N1bWVudC48 YnI+DQo8YnI+DQogJm5ic3A7KDEuZikgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBv ciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4dHJlbWUNCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtkaXNjb250ZW50PyBJZiBzbywgcGxlYXNlIHN1bW1hcmlzZSB0aGUgYXJlYXMNCm9m IGNvbmZsaWN0IGluIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZXBhcmF0ZSBl bWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUNCkFyZWEgRGlyZWN0b3IuIChJdCA8YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2hvdWxkIGJlIGluIGEgc2VwYXJhdGUgZW1h aWwgYmVjYXVzZSB0aGlzDQpxdWVzdGlvbm5haXJlIGlzIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtlbnRlcmVkIGludG8gdGhlIElEIFRyYWNrZXIuKSA8YnI+DQo8YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KTm8g dGhyZWF0cyBhcmUga25vd24uICZuYnNwO1RoZSBvbmUgZGlzc2VudGluZyBpc3N1ZSAtLSBCaWxs PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNClNpbXBzb24ncyBjb25jZXJuIGFib3V0IElTLUlTIFN5c3RlbSBJRCBpbiBhIGRlcGxv eW1lbnQgd2l0aDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQpubyBzb3VyY2Ugb2YgU3lzdGVtIElEIGdlbmVyYXRpb24gLS0gaGFz IGJlZW4gZGVhbHQgd2l0aDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpzdWNjZXNzZnVsbHkgYnkgY3JlYXRpbmcgYSBuZXcgZHJh ZnQgdGhhdCBhZGRyZXNzZXMgdGhlPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnNpdHVhdGlvbiBmb3IgSVMtSVMgYW5kIGFkZGlu ZyBhIHJlZmVyZW5jZSBpbiB0aGlzIGRvY3VtZW50Ljxicj4NCjxicj4NCiAmbmJzcDsoMS5nKSBI YXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgdmVyaWZpZWQgdGhhdCB0aGUgPGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvY3VtZW50IHNhdGlzZmllcyBhbGwgSUQg bml0cz8gKFNlZSB0aGUgSW50ZXJuZXQtRHJhZnRzDQpDaGVja2xpc3QgPGJyPg0KICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2FuZCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvaWRuaXRz LykuIEJvaWxlcnBsYXRlDQpjaGVja3MgYXJlIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlIHRob3JvdWdoLg0KSGFzIHRo ZSBkb2N1bWVudCA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWV0IGFsbCBmb3Jt YWwgcmV2aWV3IGNyaXRlcmlhIGl0IG5lZWRzIHRvLA0Kc3VjaCBhcyB0aGUgTUlCIDxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtEb2N0b3IsIG1lZGlhIHR5cGUgYW5kIFVSSSB0eXBl IHJldmlld3M/IDxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUaGUgZG9jdW1lbnQgc2hlcGhlcmQgaGFzIHB1dCB0aGUg Y3VycmVudCB0ZXh0IHRocm91Z2ggYWxsIG9mPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnRob3NlIGNoZWNrcywgYW5kIGl0IHNh dGlzZmllcyB0aGUgY2hlY2tlciBhbmQgaGFzIG5vIGtub3duPGJyPg0KICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmFkZGl0aW9uYWwgY3Jp dGVyaWEgdG8gbWVldC48YnI+DQo8YnI+DQogJm5ic3A7KDEuaCkgSGFzIHRoZSBkb2N1bWVudCBz cGxpdCBpdHMgcmVmZXJlbmNlcyBpbnRvIG5vcm1hdGl2ZSBhbmQgPGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2luZm9ybWF0aXZlPyBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5j ZXMNCnRvIGRvY3VtZW50cyB0aGF0IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDth cmUgbm90IHJlYWR5IGZvciBhZHZhbmNlbWVudCBvciBhcmUgb3RoZXJ3aXNlDQppbiBhbiB1bmNs ZWFyIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzdGF0ZT8gSWYgc3VjaCBub3Jt YXRpdmUgcmVmZXJlbmNlcyBleGlzdCwNCndoYXQgaXMgdGhlIDxicj4NCiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtzdHJhdGVneSBmb3IgdGhlaXIgY29tcGxldGlvbj8gQXJlIHRoZXJlIG5v cm1hdGl2ZQ0KcmVmZXJlbmNlcyA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhh dCBhcmUgZG93bndhcmQgcmVmZXJlbmNlcywgYXMgZGVzY3JpYmVkDQppbiBbUkZDMzk2N10/IElm IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzbywgbGlzdCB0aGVzZSBkb3dud2Fy ZCByZWZlcmVuY2VzIHRvIHN1cHBvcnQNCnRoZSBBcmVhIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtEaXJlY3RvciBpbiB0aGUgTGFzdCBDYWxsIHByb2NlZHVyZSBmb3IgdGhlbQ0K W1JGQzM5NjddLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpZZXMsIGl0IGhhcyByZWZlcmVuY2VzIHNwbGl0IGludG8g bm9ybWF0aXZlIGFuZCBpbmZvcm1hdGl2ZS48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhlcmUncyBvbmUgZG93bndh cmQgcmVmZXJlbmNlLCBhbmQgaXQncyBpbiB0aGUgaW5mb3JtYXRpdmU8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KcmVmZXJlbmNl IGxpc3QuICZuYnNwO1RoaXMgaXMgdG8gQmlsbCBTaW1wc29uJ3MgJnF1b3Q7R2VuZXJhdGlvbiBv Zjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQpVbmlxdWUgSVMtSVMgU3lzdGVtIElkZW50aWZpZXJzJnF1b3Q7IGRyYWZ0Ljxicj4N Cjxicj4NCiAmbmJzcDsoMS5pKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHZlcmlmaWVkIHRo YXQgdGhlIGRvY3VtZW50IElBTkENCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtj b25zaWRlcmF0aW9uIHNlY3Rpb24gZXhpc3RzIGFuZCBpcyBjb25zaXN0ZW50DQp3aXRoIHRoZSBi b2R5IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvZiB0aGUgZG9jdW1lbnQ/IElm IHRoZSBkb2N1bWVudCBzcGVjaWZpZXMNCnByb3RvY29sIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtleHRlbnNpb25zLCBhcmUgcmVzZXJ2YXRpb25zIHJlcXVlc3RlZCBpbiBhcHBy b3ByaWF0ZQ0KSUFOQSA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVnaXN0cmll cz8gQXJlIHRoZSBJQU5BIHJlZ2lzdHJpZXMgY2xlYXJseQ0KaWRlbnRpZmllZD8gSWYgPGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBkb2N1bWVudCBjcmVhdGVzIGEgbmV3IHJl Z2lzdHJ5LCBkb2VzIGl0DQpkZWZpbmUgdGhlIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtwcm9wb3NlZCBpbml0aWFsIGNvbnRlbnRzIG9mIHRoZSByZWdpc3RyeSBhbmQNCmFuIGFs bG9jYXRpb24gPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Byb2NlZHVyZSBmb3Ig ZnV0dXJlIHJlZ2lzdHJhdGlvbnM/IERvZXMgaXQNCnN1Z2dlc3QgYSA8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7cmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5PyBT ZWUgW1JGQzUyMjZdLg0KSWYgdGhlIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtk b2N1bWVudCBkZXNjcmliZXMgYW4gRXhwZXJ0IFJldmlldyBwcm9jZXNzDQpoYXMgU2hlcGhlcmQg PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbmZlcnJlZCB3aXRoIHRoZSBSZXNw b25zaWJsZSBBcmVhIERpcmVjdG9yDQpzbyB0aGF0IHRoZSBJRVNHIDxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtjYW4gYXBwb2ludCB0aGUgbmVlZGVkIEV4cGVydCBkdXJpbmcgdGhl IElFU0cNCkV2YWx1YXRpb24/IDxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUaGUgSUFOQSBjb25zaWRlcmF0aW9ucyBz ZWN0aW9uIGlzIHByZXNlbnQgYW5kIGRlc2NyaWJlcyB0aGU8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KbmV3IHZhbHVlcyBpbnRy b2R1Y2VkIGJ5IHRoaXMgZG9jdW1lbnQuICZuYnNwO1RoZSByZWdpc3RyaWVzIGFyZTxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpj bGVhcmx5IGlkZW50aWZpZWQgYW5kIHRoZSBhbGxvY2F0aW9uIHByb2NlZHVyZXMgYXJlIG5vdGVk Ljxicj4NCjxicj4NCiAmbmJzcDsoMS5qKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHZlcmlm aWVkIHRoYXQgc2VjdGlvbnMgb2YgdGhlIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtkb2N1bWVudCB0aGF0IGFyZSB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLA0Kc3VjaCBh cyBYTUwgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvZGUsIEJORiBydWxlcywg TUlCIGRlZmluaXRpb25zLCBldGMuLCB2YWxpZGF0ZQ0KY29ycmVjdGx5IGluIDxicj4NCiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbiBhdXRvbWF0ZWQgY2hlY2tlcj8gPGJyPg0KPGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN Ck5vIGZvcm1hbCBsYW5ndWFnZXMgYXJlIHByZXNlbnQgaW4gdGhlIGRyYWZ0Ljxicj4NCjxicj4N CiAmbmJzcDsoMS5rKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMgYSBE b2N1bWVudCA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QW5ub3VuY2VtZW50IFdy aXRlLVVwLiBQbGVhc2UgcHJvdmlkZSBzdWNoDQphIERvY3VtZW50IDxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtBbm5vdW5jZW1lbnQgV3JpdGUtVXA/IFJlY2VudCBleGFtcGxlcyBj YW4NCmJlIGZvdW5kIGluIHRoZTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVv dDtBY3Rpb24mcXVvdDsgYW5ub3VuY2VtZW50cyBmb3IgYXBwcm92ZWQNCmRvY3VtZW50cy4gVGhl IGFwcHJvdmFsIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbm5vdW5jZW1lbnQg Y29udGFpbnMgdGhlIGZvbGxvd2luZyBzZWN0aW9uczoNCjxicj4NCjxicj4NCiAmbmJzcDsgJm5i c3A7IFRlY2huaWNhbCBTdW1tYXJ5IDxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUaGUgUG9pbnQtdG8tUG9pbnQgUHJv dG9jb2wgKFBQUCkgZGVmaW5lcyBhIExpbmsgQ29udHJvbDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpQcm90b2NvbCAoTENQKSBh bmQgYSBtZXRob2QgZm9yIG5lZ290aWF0aW5nIHRoZSB1c2Ugb2Y8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KbXVsdGktcHJvdG9j b2wgdHJhZmZpYyBvdmVyIHBvaW50LXRvLXBvaW50IGxpbmtzLiAmbmJzcDtUaGlzPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmRv Y3VtZW50IGRlc2NyaWJlcyBQUFAgc3VwcG9ydCBmb3IgVHJhbnNwYXJlbnQgSW50ZXJjb25uZWN0 aW9uPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCm9mIExvdHMgb2YgTGlua3MgKFRSSUxMKSBQcm90b2NvbCwgYWxsb3dpbmcgZGly ZWN0PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCmNvbW11bmljYXRpb24gYmV0d2VlbiBSb3V0aW5nIEJyaWRnZXMgKFJCcmlkZ2Vz KSB2aWEgUFBQPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCmxpbmtzLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7IFdvcmtpbmcg R3JvdXAgU3VtbWFyeSA8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhlcmUgaXMgY29uc2Vuc3VzIGluIHRoZSBXRyB0 byBwdWJsaXNoIHRoaXMgZG9jdW1lbnQuICZuYnNwO1RoZXJlPGJyPg0KICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCndhcyBzb21lIGRpc2N1 c3Npb24gaW4gdGhlIHdvcmtpbmcgZ3JvdXAgYWJvdXQgSVMtSVMgU3lzdGVtPGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCklEcywg YW5kIHRoZSBkcmFmdCByZWZsZWN0cyB0aGUgY29uc2Vuc3VzLjxicj4NCjxicj4NCiAmbmJzcDsg Jm5ic3A7IERvY3VtZW50IFF1YWxpdHkgPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClRoZXJlIGlzIGEgbG9uZyBsaXN0 IG9mIHZlbmRvcnMgaW1wbGVtZW50aW5nIFRSSUxMLCBidXQgYXQ8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KdGhpcyBwb2ludCB0 aGVyZSBhcmUgbm9uZSB0aGF0IGhhdmUgYW5ub3VuY2VkIHN1cHBvcnQgZm9yPGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClRSSUxM IG92ZXIgUFBQLiAmbmJzcDtUaGUgUFBQIGV4dGVuc2lvbnMgZGVzY3JpYmVkIGhlcmUgYXJlPGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCnRyaXZpYWwsIGFuZCB0aGUgb3ZlcmFsbCBzeXN0ZW0gaW1wbGVtZW50YXRpb24gaXNzdWVz IGhhdmU8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KYmVlbiBkaXNjdXNzZWQgaW4gZGV0YWlsIHdpdGggc2V2ZXJhbCBvZiB0aGUg VFJJTEwgV0c8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KcGFydGljaXBhbnRzLiAmbmJzcDtObyBzaWduaWZpY2FudCBpbXBsZW1l bnRhdGlvbiwgZGVwbG95bWVudCwgb3I8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KaW50ZXJvcGVyYWJpbGl0eSBjb25jZXJucyBl eGlzdC48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KU2lnbmlmaWNhbnQgcmV2aWV3ZXJzIGluY2x1ZGUgQmlsbCBTaW1w c29uLCBEb25hbGQgRWFzdGxha2UsPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmFuZCBWZXJuIFNjaHJ5dmVyLjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUHBwZXh0IG1h aWxpbmcgbGlzdDxicj4NClBwcGV4dEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcHBwZXh0PGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 001323284825789A_=-- From jari.arkko@piuha.net Tue May 24 03:24:04 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29994E0709 for ; Tue, 24 May 2011 03:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.638 X-Spam-Level: X-Spam-Status: No, score=-102.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpapdlV1XtdX for ; Tue, 24 May 2011 03:24:03 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id F0EE6E0657 for ; Tue, 24 May 2011 03:24:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8029A2CC4B; Tue, 24 May 2011 13:24:00 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOM7sUIQbbJP; Tue, 24 May 2011 13:23:59 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8D0002CC2F; Tue, 24 May 2011 13:23:59 +0300 (EEST) Message-ID: <4DDB873F.5070204@piuha.net> Date: Tue, 24 May 2011 12:23:59 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "pppext@ietf.org" , James Carlson Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Pppext] AD review of draft-ietf-pppext-trill-protocol X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 10:24:04 -0000 I have reviewed this draft. I think it is basically in good shape, but needs to make a few things more explicit & correct small issues. For what it is worth, I'm happy with the resolution of the system ID issue; it really needs to be out of scope and dealt in ISIS WG, if they think its an issue. I'm expecting a new draft version. Then I can start an IETF Last Call. Also, for the record, as James is both the WG chair and the author, I have reviewed the discussion in the mailing list and believe that the Working Group has consensus to move the document forward. Section 2.1: > Data > > This field contains data in the same format as for the > corresponding LCP Code numbers. > > Can you clarify what this actually means. It was not clear (to this reader, at least). Is this where the configuration options would be, if some were defined? But if so, what does LCP code numbers have to do with it? Section 2.2: > When TNCP is in Opened state, TNP packets MAY be sent by setting the > PPP Protocol field to hex TBD-00XX (TNP) and placing the TRILL- > encapsulated data in the PPP Information field. > > A summary of this format is provided below: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ingress (RB1) Nickname | Inner Destination MAC ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > This is identical to the TRILL Ethernet format except that the Outer > MAC header and Ethertype are replaced by the PPP headers and Protocol > Field, and the Ethernet FCS is not present. Both user data and ESADI > packets are encoded in this format. Please add a reference to the document and Section where these fields are defined. > When TNCP is in Opened state, TLSP packets MAY be sent by setting the > PPP Protocol field to hex TBD-40XX (TLSP) and placing the IS-IS > Payload in the PPP Information field. TRILL version of IS-IS, I presume. Please provide a reference to the RFC that specifies the IS-IS payload used in this context. > 1. On a PPP link, TRILL always uses P2P Hellos. There is no need > for TRILL-Hello frames, nor is per-port configuration necessary. > P2P Hello messages, per section 9.3 of [6 ], do not use Neighbor > IDs. > Section 9.3 of [6] seems to talk about something else. If you meant [1] it has no Section 9.3. Please clarify. > If the peer is not an RBridge, then TRILL is not > possible. > I think you mean that if the peer is not an RBridge then the negotiation in this specification fails and no TRILL is used for the PPP link. > The encapsulated network layer data, carried in TNP packets, and > topology information, carried in TLSP packets, MUST NOT be sent > unless TNCP is in Opened state. If a TNP or TLSP packet is received > when TNCP is not in Opened state and LCP is Opened, an implementation > SHOULD respond using LCP Protocol-Reject. > > > 3. TRILL PPP Behavior I did not find a specification for the state machine (open/closed) in the draft. Please specify. > 4. MTU-probe and MTU-ack messages are not needed on a PPP link. > Implementations MUST NOT send MTU-probe and SHOULD NOT reply to > these messages. The MTU computed by LCP SHOULD be used instead. > Negotiating an LCP MTU of at least 1524, to allow for an inner > Ethernet payload of 1500 octets, is RECOMMENDED. > I think you mean TRILL MTU-probe. Please point to the appropriate section of [1] so that the reader knows for sure which messages you are referring to. > OUI Expand the acronym > Resolving that issue is outside the > scope of this document, but see [8 ] for one mechanism that should > be considered in this situation. > I would make this even clearer -- there's no official status yet for [8]. I'd use this: Resolving that issue is outside the scope of this document. Solutions to this issue may be defined elsewhere in the future, see [8] for an example. Jari From carlsonj@workingcode.com Tue May 24 08:12:47 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A87E073C for ; Tue, 24 May 2011 08:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxdm95ALCBGw for ; Tue, 24 May 2011 08:12:47 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 02575E06ED for ; Tue, 24 May 2011 08:12:46 -0700 (PDT) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4OFCaHl007951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 11:12:37 -0400 (EDT) Message-ID: <4DDBCAE4.8060908@workingcode.com> Date: Tue, 24 May 2011 11:12:36 -0400 From: James Carlson User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jari Arkko References: <4DDB873F.5070204@piuha.net> In-Reply-To: <4DDB873F.5070204@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: "pppext@ietf.org" Subject: Re: [Pppext] AD review of draft-ietf-pppext-trill-protocol X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:12:48 -0000 On 05/24/11 06:23, Jari Arkko wrote: > I have reviewed this draft. I think it is basically in good shape, but > needs to make a few things more explicit & correct small issues. For > what it is worth, I'm happy with the resolution of the system ID issue; > it really needs to be out of scope and dealt in ISIS WG, if they think > its an issue. Thanks! > I'm expecting a new draft version. Then I can start an IETF Last Call. Will do. > Section 2.1: > >> Data >> >> This field contains data in the same format as for the >> corresponding LCP Code numbers. >> >> > > Can you clarify what this actually means. It was not clear (to this > reader, at least). Is this where the configuration options would be, if > some were defined? But if so, what does LCP code numbers have to do with > it? It means that if the Code number is set to 01, then this document expects data in the Data field that's formatted in exactly the same way as you would also expect for an LCP Configure-Request. If it's set to 02, then it's formatted in the same way as LCP Configure-Ack. And so on. Of course, the point is somewhat moot in that there are no options as yet. But when (and if) they're defined, we're saying that this is the proper format. The reason this text is here is that implementations based on this draft that receive unexpected options will (a) need to be able to send properly-formatted Configure-Reject messages and (b) likely need to be able to write appropriate debug log messages concerning the event. Those things require an understanding of the format. (Additionally, network debugging tools such as 'ethereal' should be able to display the format without necessarily understanding the options.) I agree that the wording is unclear; I'll update it. > Section 2.2: > >> This is identical to the TRILL Ethernet format except that the Outer >> MAC header and Ethertype are replaced by the PPP headers and Protocol >> Field, and the Ethernet FCS is not present. Both user data and ESADI >> packets are encoded in this format. > > Please add a reference to the document and Section where these fields > are defined. This would be reference [1] in section 4.1, "Ethernet Data Encapsulation." Will add. >> When TNCP is in Opened state, TLSP packets MAY be sent by setting the >> PPP Protocol field to hex TBD-40XX (TLSP) and placing the IS-IS >> Payload in the PPP Information field. > > TRILL version of IS-IS, I presume. Please provide a reference to the RFC > that specifies the IS-IS payload used in this context. Yes. This is section 4.2.3, "TRILL IS-IS Frames." >> 1. On a PPP link, TRILL always uses P2P Hellos. There is no need >> for TRILL-Hello frames, nor is per-port configuration necessary. >> P2P Hello messages, per section 9.3 of [6 >> ], >> do not use Neighbor >> IDs. >> > > Section 9.3 of [6] seems to talk about something else. If you meant [1] > it has no Section 9.3. Please clarify. Section 9.3 of RFC 1142 is entitled "Point-to-Point IS to IS Hello PDU." That is the intended reference. At a guess, you might be looking at the weirdly-formatted text version of RFC 1142 rather than the PDF. Any suggestions on how to handle the odd differences in section numbering between these two formats? My understanding is that most people look at the PDF because it's somewhat legible, which is a feature the text version sadly lacks. >> If the peer is not an RBridge, then TRILL is not >> possible. >> > > I think you mean that if the peer is not an RBridge then the negotiation > in this specification fails and no TRILL is used for the PPP link. Yes; will update. >> The encapsulated network layer data, carried in TNP packets, and >> topology information, carried in TLSP packets, MUST NOT be sent >> unless TNCP is in Opened state. If a TNP or TLSP packet is received >> when TNCP is not in Opened state and LCP is Opened, an implementation >> SHOULD respond using LCP Protocol-Reject. >> >> 3. TRILL PPP Behavior > I did not find a specification for the state machine (open/closed) in > the draft. Please specify. It uses the LCP state machine. This was implied by: Link State Protocol (TLSP) on a PPP link. TNCP uses the same option negotiation mechanism as LCP. ... but I can make it explicit. >> 4. MTU-probe and MTU-ack messages are not needed on a PPP link. >> Implementations MUST NOT send MTU-probe and SHOULD NOT reply to >> these messages. The MTU computed by LCP SHOULD be used instead. >> Negotiating an LCP MTU of at least 1524, to allow for an inner >> Ethernet payload of 1500 octets, is RECOMMENDED. >> > > I think you mean TRILL MTU-probe. Please point to the appropriate > section of [1] so that the reader knows for sure which messages you are > referring to. OK. >> OUI > > Expand the acronym OK. >> Resolving that issue is outside the >> scope of this document, but see [8 >> ] for >> one mechanism that should >> be considered in this situation. >> > > I would make this even clearer -- there's no official status yet for > [8]. I'd use this: > > Resolving that issue is outside the > scope of this document. Solutions > to this issue may be defined elsewhere in the future, see > [8] for an example. OK. -- James Carlson 42.703N 71.076W From jari.arkko@piuha.net Tue May 24 13:54:19 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0D6E0792 for ; Tue, 24 May 2011 13:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.479 X-Spam-Level: X-Spam-Status: No, score=-101.479 tagged_above=-999 required=5 tests=[AWL=-1.179, BAYES_00=-2.599, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTRreBDQlvTE for ; Tue, 24 May 2011 13:54:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCA4E0791 for ; Tue, 24 May 2011 13:54:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 35C332CC4B; Tue, 24 May 2011 23:54:17 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU4by49mlyVl; Tue, 24 May 2011 23:54:16 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 066732CC2F; Tue, 24 May 2011 23:54:15 +0300 (EEST) Message-ID: <4DDC1AF6.2070607@piuha.net> Date: Tue, 24 May 2011 22:54:14 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: James Carlson References: <4DDB873F.5070204@piuha.net> <4DDBCAE4.8060908@workingcode.com> In-Reply-To: <4DDBCAE4.8060908@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pppext@ietf.org" Subject: Re: [Pppext] AD review of draft-ietf-pppext-trill-protocol X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:54:19 -0000 James , >> Section 2.1: >> >> >>> Data >>> >>> This field contains data in the same format as for the >>> corresponding LCP Code numbers. >>> >>> >>> >> Can you clarify what this actually means. It was not clear (to this >> reader, at least). Is this where the configuration options would be, if >> some were defined? But if so, what does LCP code numbers have to do with >> it? >> > > It means that if the Code number is set to 01, then this document > expects data in the Data field that's formatted in exactly the same way > as you would also expect for an LCP Configure-Request. If it's set to > 02, then it's formatted in the same way as LCP Configure-Ack. And so on. > > Of course, the point is somewhat moot in that there are no options as > yet. But when (and if) they're defined, we're saying that this is the > proper format. > > The reason this text is here is that implementations based on this draft > that receive unexpected options will (a) need to be able to send > properly-formatted Configure-Reject messages and (b) likely need to be > able to write appropriate debug log messages concerning the event. > Those things require an understanding of the format. (Additionally, > network debugging tools such as 'ethereal' should be able to display the > format without necessarily understanding the options.) > > I agree that the wording is unclear; I'll update it. > OK. >> Section 2.2: >> >> >>> This is identical to the TRILL Ethernet format except that the Outer >>> MAC header and Ethertype are replaced by the PPP headers and Protocol >>> Field, and the Ethernet FCS is not present. Both user data and ESADI >>> packets are encoded in this format. >>> >> Please add a reference to the document and Section where these fields >> are defined. >> > > This would be reference [1] in section 4.1, "Ethernet Data > Encapsulation." Will add. > OK >>> When TNCP is in Opened state, TLSP packets MAY be sent by setting the >>> PPP Protocol field to hex TBD-40XX (TLSP) and placing the IS-IS >>> Payload in the PPP Information field. >>> >> TRILL version of IS-IS, I presume. Please provide a reference to the RFC >> that specifies the IS-IS payload used in this context. >> > > Yes. This is section 4.2.3, "TRILL IS-IS Frames." > OK >>> 1. On a PPP link, TRILL always uses P2P Hellos. There is no need >>> for TRILL-Hello frames, nor is per-port configuration necessary. >>> P2P Hello messages, per section 9.3 of [6 >>> ], >>> do not use Neighbor >>> IDs. >>> >>> >> Section 9.3 of [6] seems to talk about something else. If you meant [1] >> it has no Section 9.3. Please clarify. >> > > Section 9.3 of RFC 1142 is entitled "Point-to-Point IS to IS Hello PDU." > That is the intended reference. > > At a guess, you might be looking at the weirdly-formatted text version > of RFC 1142 rather than the PDF. Ah, I was. > Any suggestions on how to handle the > odd differences in section numbering between these two formats? My > understanding is that most people look at the PDF because it's somewhat > legible, which is a feature the text version sadly lacks. > I have no solution for you... I guess we'll have to live with this issue. >>> If the peer is not an RBridge, then TRILL is not >>> possible. >>> >>> >> I think you mean that if the peer is not an RBridge then the negotiation >> in this specification fails and no TRILL is used for the PPP link. >> > > Yes; will update. > OK >>> The encapsulated network layer data, carried in TNP packets, and >>> topology information, carried in TLSP packets, MUST NOT be sent >>> unless TNCP is in Opened state. If a TNP or TLSP packet is received >>> when TNCP is not in Opened state and LCP is Opened, an implementation >>> SHOULD respond using LCP Protocol-Reject. >>> >>> 3. TRILL PPP Behavior >>> >> I did not find a specification for the state machine (open/closed) in >> the draft. Please specify. >> > > It uses the LCP state machine. This was implied by: > > Link State Protocol (TLSP) on a PPP link. TNCP uses the same option > negotiation mechanism as LCP. > > ... but I can make it explicit. > OK. Sorry for asking you to clarify many similar things. Some of these things are obvious to you, but may help other readers. >>> 4. MTU-probe and MTU-ack messages are not needed on a PPP link. >>> Implementations MUST NOT send MTU-probe and SHOULD NOT reply to >>> these messages. The MTU computed by LCP SHOULD be used instead. >>> Negotiating an LCP MTU of at least 1524, to allow for an inner >>> Ethernet payload of 1500 octets, is RECOMMENDED. >>> >>> >> I think you mean TRILL MTU-probe. Please point to the appropriate >> section of [1] so that the reader knows for sure which messages you are >> referring to. >> > > OK. > > >>> OUI >>> >> Expand the acronym >> > > OK. > > >>> Resolving that issue is outside the >>> scope of this document, but see [8 >>> ] for >>> one mechanism that should >>> be considered in this situation. >>> >>> >> I would make this even clearer -- there's no official status yet for >> [8]. I'd use this: >> >> Resolving that issue is outside the >> scope of this document. Solutions >> to this issue may be defined elsewhere in the future, see >> [8] for an example. >> > > OK. > > Jari From internet-drafts@ietf.org Wed May 25 05:27:05 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA27E0713; Wed, 25 May 2011 05:27:05 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhhSpzmDweH8; Wed, 25 May 2011 05:27:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D977E0657; Wed, 25 May 2011 05:27:05 -0700 (PDT) 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.55 Message-ID: <20110525122705.5896.14355.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2011 05:27:05 -0700 Cc: pppext@ietf.org Subject: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-06.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:27:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Point-to-Point Protocol Extensions Wo= rking Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : James Carlson Filename : draft-ietf-pppext-trill-protocol-06.txt Pages : 7 Date : 2011-05-25 The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-06.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-pppext-trill-protocol-06.txt From carlsonj@workingcode.com Wed May 25 05:41:23 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC8FE0723 for ; Wed, 25 May 2011 05:41:23 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuSHMylQUbNO for ; Wed, 25 May 2011 05:41:22 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 615BAE0713 for ; Wed, 25 May 2011 05:41:21 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4PCfJCL011944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 08:41:20 -0400 (EDT) Message-ID: <4DDCF8EF.8080504@workingcode.com> Date: Wed, 25 May 2011 08:41:19 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Jari Arkko References: <20110525122705.5896.14355.idtracker@ietfa.amsl.com> In-Reply-To: <20110525122705.5896.14355.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-wuwien-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-06.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:41:23 -0000 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. > > Title : PPP TRILL Protocol Control Protocol > Author(s) : James Carlson > Filename : draft-ietf-pppext-trill-protocol-06.txt > Pages : 7 > Date : 2011-05-25 > > The Point-to-Point Protocol (PPP) defines a Link Control Protocol > (LCP) and a method for negotiating the use of multi-protocol traffic > over point-to-point links. This document describes PPP support for > Transparent Interconnection of Lots of Links (TRILL) Protocol, > allowing direct communication between Routing Bridges (RBridges) via > PPP links. This should address all of your comments. Please let me know if there are any more changes that need to be made. -- James Carlson 42.703N 71.076W From jari.arkko@piuha.net Wed May 25 06:39:48 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0F2E0801 for ; Wed, 25 May 2011 06:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gYnwf0fPPe7 for ; Wed, 25 May 2011 06:39:48 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2A25BE07FD for ; Wed, 25 May 2011 06:39:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 328EE2CC3B; Wed, 25 May 2011 16:39:47 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imqDgUJU+u5U; Wed, 25 May 2011 16:39:46 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 610F92CC2F; Wed, 25 May 2011 16:39:46 +0300 (EEST) Message-ID: <4DDD06A1.9040209@piuha.net> Date: Wed, 25 May 2011 16:39:45 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: James Carlson References: <20110525122705.5896.14355.idtracker@ietfa.amsl.com> <4DDCF8EF.8080504@workingcode.com> In-Reply-To: <4DDCF8EF.8080504@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org Subject: Re: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-06.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:39:49 -0000 Looks good, thank you for the quick revision. I have sent the draft forward to an IETF Last Call. Jari James Carlson kirjoitti: > internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. >> >> Title : PPP TRILL Protocol Control Protocol >> Author(s) : James Carlson >> Filename : draft-ietf-pppext-trill-protocol-06.txt >> Pages : 7 >> Date : 2011-05-25 >> >> The Point-to-Point Protocol (PPP) defines a Link Control Protocol >> (LCP) and a method for negotiating the use of multi-protocol traffic >> over point-to-point links. This document describes PPP support for >> Transparent Interconnection of Lots of Links (TRILL) Protocol, >> allowing direct communication between Routing Bridges (RBridges) via >> PPP links. >> > > This should address all of your comments. Please let me know if there > are any more changes that need to be made. > > From iesg-secretary@ietf.org Wed May 25 09:13:58 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48047E07FE; Wed, 25 May 2011 09:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k86w5yjmZXMg; Wed, 25 May 2011 09:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCD3E0722; Wed, 25 May 2011 09:13:57 -0700 (PDT) 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.55 Message-ID: <20110525161357.5909.40860.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2011 09:13:57 -0700 Cc: pppext@ietf.org Subject: [Pppext] Last Call: (PPP TRILL Protocol Control Protocol) to Proposed Standard X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:13:58 -0000 The IESG has received a request from the Point-to-Point Protocol Extensions WG (pppext) to consider the following document: - 'PPP TRILL Protocol Control Protocol' as a Proposed Standard 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 2011-06-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 The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ No IPR declarations have been submitted directly on this I-D. From william.allen.simpson@gmail.com Wed May 25 09:55:48 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5C2E06B5 for ; Wed, 25 May 2011 09:55:48 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYka6vWDMD4I for ; Wed, 25 May 2011 09:55:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08098E066C for ; Wed, 25 May 2011 09:55:47 -0700 (PDT) Received: by ywp31 with SMTP id 31so3966547ywp.31 for ; Wed, 25 May 2011 09:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ckOLn02eHDCZmEY4teba+MQRjqfjql89P//fso9Vui0=; b=ru7NgMtpddnTzwjZtKsEZFnrqtLjdXFEs28kjXcwpRI1tZOAAZzpM6dEFRX75N7p9E HMF0PsccXN1bL4lzcTvymxz/liORyE+bZMNm3+E/jS4fildlur7r43coBN2YFNrpq4Yp VvGe2y4kyXzZgQ1nfIKb1NI9QTQ8u3pn4nFIo= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=aO182bIqjaAYCGaDrp6951nWtPqpvepAsM1xR0AgFmDe5M9C6UpxYMUT2JkkjRoHDk 53SpIywciUHl8YGUhOdpoHAN5H6ZBP6xMp8FeKRJ6MzT802EG/WraVtkU+9hCVoHNa7+ bWyjwEIC5efWjL1D/pNbBeu6aEk8nkmll8hB8= Received: by 10.151.5.14 with SMTP id h14mr5448696ybi.182.1306342547288; Wed, 25 May 2011 09:55:47 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id p23sm19885ybc.29.2011.05.25.09.55.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2011 09:55:46 -0700 (PDT) Message-ID: <4DDD3490.7060900@gmail.com> Date: Wed, 25 May 2011 12:55:44 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jari Arkko References: <4DDB873F.5070204@piuha.net> <4DDBCAE4.8060908@workingcode.com> <4DDC1AF6.2070607@piuha.net> In-Reply-To: <4DDC1AF6.2070607@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pppext@ietf.org" Subject: Re: [Pppext] AD review of draft-ietf-pppext-trill-protocol X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:55:49 -0000 Hey, I told him he needed more references.... Anyway, the way I usually deal with the section is to use the name, not the numbers. Numbers can change during formatting, and people scan for names more easily. From vineet.garg@aricent.com Thu May 26 02:25:28 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5CCE06EC for ; Thu, 26 May 2011 02:25:28 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mex5u5JxjFnb for ; Thu, 26 May 2011 02:25:28 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id A0210E06BE for ; Thu, 26 May 2011 02:25:27 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id A79A536B9A for ; Thu, 26 May 2011 14:51:12 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 8CF4336B95 for ; Thu, 26 May 2011 14:51:12 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.132]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Thu, 26 May 2011 14:55:25 +0530 From: Vineet kumar Garg To: "pppext@ietf.org" Date: Thu, 26 May 2011 14:51:45 +0530 Thread-Topic: Proposal to solve ML-PPP ambiguity Thread-Index: AQHMG4bE1TuNU/BcokGZt73huuWOIA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Pppext] Proposal to solve ML-PPP ambiguity X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 09:25:28 -0000 Hi All While working with ML-PPP over some time, I have come across some problems = which I think should be solved at the protocol level. Please review the abs= tract below and let me know your valuable opinions: As per existing RFC, following are the key characteristics of LCP negotiati= on for multi-link parameters: =95 MRRU option is considered as mandatory option for a link to join = a MC/ML-PPP bundle =95 Endpoint discriminator is optional and can be used to identify di= fferent PPP peers =95 Short-sequence number as an option is negotiated as part of LCP a= lthough same value has to be negotiated on all the links Problem that current protocol creates is that it allows a scope for= bundle level parameters to be negotiated with different values on differen= t links. This leads to an implementation ambiguity about which values to be= chosen for the bundle. Some of the ways applications can implement this ch= oice are: - Choose the negotiated value from = the latest link that came - Choose the first value that was n= egotiated - Choose the one matching operator = configuration etc. Is there already a solution to this problem as part of protocol that I am m= issing? -> Proposed solution Since the bundle level parameters like MRRU & sequence number len= gth are applicable to all bundles in a link, it is better to negotiate them= like an NCP after LCP has already been done. So, like other NCP protocols,= there can be a new protocol called ML-CP which will configure all bundle l= evel parameters for all the links in the bundle. This will remove the ambig= uity about choosing the values of bundle level parameters and also prevent = different values being negotiated for same parameter in case of some mis-co= nfiguration. However, still there is a need to have some parameter in LCP whic= h determines the bundle association of a link. In order to do that we can u= se endpoint discriminator as a mandatory option in LCP for links which want= to join a bundle. Maintaining backward compatibility with existing implementations might be a= challenge, however in this case. However, that can be resolved by includin= g a simple version number option in LCP. Regards Vineet "DISCLAIMER: This message is proprietary to the Aricent Group and is intend= ed solely for the use of the individual to whom it is addressed. It may con= tain privileged or confidential information and should not be circulated or= used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this m= essage. The Aricent Group accepts no responsibility for loss or damage aris= ing from the use of the information transmitted by this email including dam= age from virus." From carlsonj@workingcode.com Thu May 26 04:31:36 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15F913002F for ; Thu, 26 May 2011 04:31:36 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZxcD5J668iu for ; Thu, 26 May 2011 04:31:36 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id D73C013001F for ; Thu, 26 May 2011 04:31:35 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4QBVGsW003279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2011 07:31:28 -0400 (EDT) Message-ID: <4DDE3A04.2020502@workingcode.com> Date: Thu, 26 May 2011 07:31:16 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Vineet kumar Garg References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-DCC-Misty-Metrics: carlson; whitelist Cc: "pppext@ietf.org" Subject: Re: [Pppext] Proposal to solve ML-PPP ambiguity X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 11:31:36 -0000 Vineet kumar Garg wrote: > Hi All > > While working with ML-PPP over some time, I have come across some problems which I think should be solved at the protocol level. Please review the abstract below and let me know your valuable opinions: > > As per existing RFC, following are the key characteristics of LCP negotiation for multi-link parameters: > > • MRRU option is considered as mandatory option for a link to join a MC/ML-PPP bundle > • Endpoint discriminator is optional and can be used to identify different PPP peers > • Short-sequence number as an option is negotiated as part of LCP although same value has to be negotiated on all the links > > Problem that current protocol creates is that it allows a scope for bundle level parameters to be negotiated with different values on different links. This leads to an implementation ambiguity about which values to be chosen for the bundle. Some of the ways applications can implement this choice are: > - Choose the negotiated value from the latest link that came > - Choose the first value that was negotiated > - Choose the one matching operator configuration etc. > > Is there already a solution to this problem as part of protocol that I am missing? At the point where LCP is negotiated, it is not necessarily yet known to which bundle the new link belongs. You ordinarily have to wait for Authentication to complete. Thus, the negotiation of those low-level options needs to be separate. I think the solution is straightforward. When you create a new bundle head, you use the LCP options that were negotiated on that single link. When attempting to join a new link to an existing bundle (because authenticated peer names and E-Ds match), check the options on the new link. If they match the ones on the bundle, then join up. If they don't, then signal an error and terminate the new link. Since this is a "should never happen" case, it's not really something to worry about. Bundles are not just established out of the blue; they're established between cooperating systems. If you have one line configured to use short sequence numbers and the other not, then you've misconfigured your systems, and having those systems report errors and fail to establish the bundle is the best result. > -> Proposed solution > > Since the bundle level parameters like MRRU & sequence number length are applicable to all bundles in a link, it is better to negotiate them like an NCP after LCP has already been done. So, like other NCP protocols, there can be a new protocol called ML-CP which will configure all bundle level parameters for all the links in the bundle. This will remove the ambiguity about choosing the values of bundle level parameters and also prevent different values being negotiated for same parameter in case of some mis-configuration. > > However, still there is a need to have some parameter in LCP which determines the bundle association of a link. In order to do that we can use endpoint discriminator as a mandatory option in LCP for links which want to join a bundle. > > Maintaining backward compatibility with existing implementations might be a challenge, however in this case. However, that can be resolved by including a simple version number option in LCP. I don't think a new NCP is necessary. The current mechanism (checking parameter compatibility when joining links to an existing bundle) seems to work well enough. -- James Carlson 42.703N 71.076W From vineet.garg@aricent.com Thu May 26 12:45:58 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF0BE0789 for ; Thu, 26 May 2011 12:45:58 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA0a-bP852zd for ; Thu, 26 May 2011 12:45:57 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id EF478E0786 for ; Thu, 26 May 2011 12:45:56 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id D801136B81; Fri, 27 May 2011 01:11:38 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id C12C236B80; Fri, 27 May 2011 01:11:38 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.132]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Fri, 27 May 2011 01:15:52 +0530 From: Vineet kumar Garg To: James Carlson Date: Fri, 27 May 2011 01:15:50 +0530 Thread-Topic: [Pppext] Proposal to solve ML-PPP ambiguity Thread-Index: AcwbmHhlHmZlNZkMSr+61D3JxfHPTgAQmFR1 Message-ID: References: , <4DDE3A04.2020502@workingcode.com> In-Reply-To: <4DDE3A04.2020502@workingcode.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pppext@ietf.org" Subject: Re: [Pppext] Proposal to solve ML-PPP ambiguity X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 19:45:58 -0000 Hi James Thanks for your inputs on this. Really appreciate. I agree with your point that the situation mentioned below is an error case= and should be ok to not bring up the links in case of mismatch. You have explained how one of the possible solutions in such situation woul= d work. thats fine. But the solution described is not mentioned in the stan= dard (as far as I know) leading to ambiguity in implementation with a possi= blity of inter-operablity problems when two different approaches are chosen= to solve the problem at hand. IMHO, it will be nice if the best approach i= s documented in the RFC so as to remove the ambiguity. Another perspective of this could be using the latest negotiated option for= the bundle since the peer may have informed of a change in parameter (say = short seq number) at only one of the links in the bundle. I don't think RFC= requires a system to re-negotiate all its links if any of the bundle level= parameters change. Basically this is the ambiguity because of which I suggested about using a = separate negotiation leg for all the bundle level parameters. Maybe it does= not make a lot of sense making this big a change for an error scenario, bu= t it will lead to better and more clear designs and might hopefully have be= tter use cases in future. One more ambiguity in the protocol that I think can be clarified in RFC is = use of IPCP (or any other NCP) over a MC/ML-PPP bundle. Doesn't it make mor= e sense to use only IPCP over NCP when using ML-PPP to resolve the issue of= which member link to be used for IPCP? Regards Vineet ________________________________________ From: James Carlson [carlsonj@workingcode.com] Sent: Thursday, May 26, 2011 5:01 PM To: Vineet kumar Garg Cc: pppext@ietf.org Subject: Re: [Pppext] Proposal to solve ML-PPP ambiguity Vineet kumar Garg wrote: > Hi All > > While working with ML-PPP over some time, I have come across some problem= s which I think should be solved at the protocol level. Please review the a= bstract below and let me know your valuable opinions: > > As per existing RFC, following are the key characteristics of LCP negotia= tion for multi-link parameters: > > =95 MRRU option is considered as mandatory option for a link to joi= n a MC/ML-PPP bundle > =95 Endpoint discriminator is optional and can be used to identify = different PPP peers > =95 Short-sequence number as an option is negotiated as part of LCP= although same value has to be negotiated on all the links > > Problem that current protocol creates is that it allows a scope f= or bundle level parameters to be negotiated with different values on differ= ent links. This leads to an implementation ambiguity about which values to = be chosen for the bundle. Some of the ways applications can implement this = choice are: > - Choose the negotiated value fro= m the latest link that came > - Choose the first value that was= negotiated > - Choose the one matching operato= r configuration etc. > > Is there already a solution to this problem as part of protocol that I am= missing? At the point where LCP is negotiated, it is not necessarily yet known to which bundle the new link belongs. You ordinarily have to wait for Authentication to complete. Thus, the negotiation of those low-level options needs to be separate. I think the solution is straightforward. When you create a new bundle head, you use the LCP options that were negotiated on that single link. When attempting to join a new link to an existing bundle (because authenticated peer names and E-Ds match), check the options on the new link. If they match the ones on the bundle, then join up. If they don't, then signal an error and terminate the new link. Since this is a "should never happen" case, it's not really something to worry about. Bundles are not just established out of the blue; they're established between cooperating systems. If you have one line configured to use short sequence numbers and the other not, then you've misconfigured your systems, and having those systems report errors and fail to establish the bundle is the best result. > -> Proposed solution > > Since the bundle level parameters like MRRU & sequence number l= ength are applicable to all bundles in a link, it is better to negotiate th= em like an NCP after LCP has already been done. So, like other NCP protocol= s, there can be a new protocol called ML-CP which will configure all bundle= level parameters for all the links in the bundle. This will remove the amb= iguity about choosing the values of bundle level parameters and also preven= t different values being negotiated for same parameter in case of some mis-= configuration. > > However, still there is a need to have some parameter in LCP wh= ich determines the bundle association of a link. In order to do that we can= use endpoint discriminator as a mandatory option in LCP for links which wa= nt to join a bundle. > > Maintaining backward compatibility with existing implementations might be= a challenge, however in this case. However, that can be resolved by includ= ing a simple version number option in LCP. I don't think a new NCP is necessary. The current mechanism (checking parameter compatibility when joining links to an existing bundle) seems to work well enough. -- James Carlson 42.703N 71.076W "DISCLAIMER: This message is proprietary to the Aricent Group and is intend= ed solely for the use of the individual to whom it is addressed. It may con= tain privileged or confidential information and should not be circulated or= used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this m= essage. The Aricent Group accepts no responsibility for loss or damage aris= ing from the use of the information transmitted by this email including dam= age from virus." From vineet.garg@aricent.com Thu May 26 12:49:13 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2468EE0784 for ; Thu, 26 May 2011 12:49:13 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJxcGPNVd3-3 for ; Thu, 26 May 2011 12:49:12 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id D467EE068C for ; Thu, 26 May 2011 12:49:11 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id D338936B70; Fri, 27 May 2011 01:14:56 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id BD39E36B2B; Fri, 27 May 2011 01:14:56 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.132]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Fri, 27 May 2011 01:19:09 +0530 From: Vineet kumar Garg To: James Carlson Date: Fri, 27 May 2011 01:17:05 +0530 Thread-Topic: [Pppext] Proposal to solve ML-PPP ambiguity Thread-Index: AcwbmHhlHmZlNZkMSr+61D3JxfHPTgAQmFR1AAC1uQc= Message-ID: References: , <4DDE3A04.2020502@workingcode.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pppext@ietf.org" Subject: Re: [Pppext] Proposal to solve ML-PPP ambiguity X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 19:49:13 -0000 Hi James Thanks for your inputs on this. Really appreciate. I agree with your point that the situation mentioned below is an error case= and should be ok to not bring up the links in case of mismatch. You have explained how one of the possible solutions in such situation woul= d work. thats fine. But the solution described is not mentioned in the stan= dard (as far as I know) leading to ambiguity in implementation with a possi= blity of inter-operablity problems when two different approaches are chosen= to solve the problem at hand. IMHO, it will be nice if the best approach i= s documented in the RFC so as to remove the ambiguity. Another perspective of this could be using the latest negotiated option for= the bundle since the peer may have informed of a change in parameter (say = short seq number) at only one of the links in the bundle. I don't think RFC= requires a system to re-negotiate all its links if any of the bundle level= parameters change. Basically this is the ambiguity because of which I suggested about using a = separate negotiation leg for all the bundle level parameters. Maybe it does= not make a lot of sense making this big a change for an error scenario, bu= t it will lead to better and more clear designs and might hopefully have be= tter use cases in future. One more ambiguity in the protocol that I think can be clarified in RFC is = use of IPCP (or any other NCP) over a MC/ML-PPP bundle. Doesn't it make mor= e sense to use only IPCP over ML-PPP when using ML-PPP to resolve the issue= of which member link to be used for IPCP? Regards Vineet ________________________________________ From: James Carlson [carlsonj@workingcode.com] Sent: Thursday, May 26, 2011 5:01 PM To: Vineet kumar Garg Cc: pppext@ietf.org Subject: Re: [Pppext] Proposal to solve ML-PPP ambiguity Vineet kumar Garg wrote: > Hi All > > While working with ML-PPP over some time, I have come across some problem= s which I think should be solved at the protocol level. Please review the a= bstract below and let me know your valuable opinions: > > As per existing RFC, following are the key characteristics of LCP negotia= tion for multi-link parameters: > > =95 MRRU option is considered as mandatory option for a link to joi= n a MC/ML-PPP bundle > =95 Endpoint discriminator is optional and can be used to identify = different PPP peers > =95 Short-sequence number as an option is negotiated as part of LCP= although same value has to be negotiated on all the links > > Problem that current protocol creates is that it allows a scope f= or bundle level parameters to be negotiated with different values on differ= ent links. This leads to an implementation ambiguity about which values to = be chosen for the bundle. Some of the ways applications can implement this = choice are: > - Choose the negotiated value fro= m the latest link that came > - Choose the first value that was= negotiated > - Choose the one matching operato= r configuration etc. > > Is there already a solution to this problem as part of protocol that I am= missing? At the point where LCP is negotiated, it is not necessarily yet known to which bundle the new link belongs. You ordinarily have to wait for Authentication to complete. Thus, the negotiation of those low-level options needs to be separate. I think the solution is straightforward. When you create a new bundle head, you use the LCP options that were negotiated on that single link. When attempting to join a new link to an existing bundle (because authenticated peer names and E-Ds match), check the options on the new link. If they match the ones on the bundle, then join up. If they don't, then signal an error and terminate the new link. Since this is a "should never happen" case, it's not really something to worry about. Bundles are not just established out of the blue; they're established between cooperating systems. If you have one line configured to use short sequence numbers and the other not, then you've misconfigured your systems, and having those systems report errors and fail to establish the bundle is the best result. > -> Proposed solution > > Since the bundle level parameters like MRRU & sequence number l= ength are applicable to all bundles in a link, it is better to negotiate th= em like an NCP after LCP has already been done. So, like other NCP protocol= s, there can be a new protocol called ML-CP which will configure all bundle= level parameters for all the links in the bundle. This will remove the amb= iguity about choosing the values of bundle level parameters and also preven= t different values being negotiated for same parameter in case of some mis-= configuration. > > However, still there is a need to have some parameter in LCP wh= ich determines the bundle association of a link. In order to do that we can= use endpoint discriminator as a mandatory option in LCP for links which wa= nt to join a bundle. > > Maintaining backward compatibility with existing implementations might be= a challenge, however in this case. However, that can be resolved by includ= ing a simple version number option in LCP. I don't think a new NCP is necessary. The current mechanism (checking parameter compatibility when joining links to an existing bundle) seems to work well enough. -- James Carlson 42.703N 71.076W "DISCLAIMER: This message is proprietary to the Aricent Group and is intend= ed solely for the use of the individual to whom it is addressed. It may con= tain privileged or confidential information and should not be circulated or= used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this m= essage. The Aricent Group accepts no responsibility for loss or damage aris= ing from the use of the information transmitted by this email including dam= age from virus." From carlsonj@workingcode.com Thu May 26 14:32:40 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D19EE0707 for ; Thu, 26 May 2011 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smvSK7VTqFwJ for ; Thu, 26 May 2011 14:32:39 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDD0E06E1 for ; Thu, 26 May 2011 14:32:38 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4QLWVCj012698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2011 17:32:31 -0400 (EDT) Message-ID: <4DDEC6EF.5090205@workingcode.com> Date: Thu, 26 May 2011 17:32:31 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Vineet kumar Garg References: , <4DDE3A04.2020502@workingcode.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist Cc: "pppext@ietf.org" Subject: Re: [Pppext] Proposal to solve ML-PPP ambiguity X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:32:40 -0000 Vineet kumar Garg wrote: > Hi James > > Thanks for your inputs on this. Really appreciate. > > I agree with your point that the situation mentioned below is an error case and should be ok to not bring up the links in case of mismatch. > > You have explained how one of the possible solutions in such situation would work. thats fine. But the solution described is not mentioned in the standard (as far as I know) leading to ambiguity in implementation with a possiblity of inter-operablity problems when two different approaches are chosen to solve the problem at hand. IMHO, it will be nice if the best approach is documented in the RFC so as to remove the ambiguity. If someone is interested in writing a new document that resolves problems that have been seen in the existing document -- and that doesn't create new ones -- that's certainly fine by me. Have at it. For what it's worth, although I agree that an implementor's guide might be helpful, I'm not so sure that this is something that needs to be covered by the existing document. The existing text makes it clear that if you want to use the Short Sequence Number Header Format Option, you have to include it on all links: configure-Reject the option. If 12 bit sequence numbers are desired, this option MUST be negotiated when the bundle is instantiated, and MUST be explicitly included in every LCP configure request offered by a system when the system intends to include that link in an existing bundle using 12 bit sequence numbers. If this option is never negotiated during the life of a bundle, sequence numbers are 24 bits long. When a peer walks off the end of a "MUST," you're within your rights to do anything reasonable to resolve the problem. Often, the most "reasonable" answer is to drop the link and report an error, rather than continue talking to an obviously broken peer. Of course, some implementors may just ignore the problem and drive on. Your results may vary substantially. Not all implementations are equal in quality. > Another perspective of this could be using the latest negotiated option for the bundle since the peer may have informed of a change in parameter (say short seq number) at only one of the links in the bundle. I don't think RFC requires a system to re-negotiate all its links if any of the bundle level parameters change. The text above makes it clear that if you want 12-bit sequence numbers, you have to ask for them when the bundle is created, and you have to ask for them on every link that will join the bundle. And if you want 24-bit sequence numbers, you must never ask for the option on any of the links in the bundle. Because this option needs to be the same on all of the links in the bundle, the only reasonable solution I can see for changing this parameter would be to bring down the bundle head. To do that, you have to at least restart negotiation of LCP on all of the links or take the links down. But I'm unclear on what the point might be. Why would you ever want to do this? Sequence number size is basically a function of the relative link speed, available buffering, and tolerable timing skew among the links. If you don't know that 12-bit sequence numbers are safe for your application, don't use them. I don't think it's a flag that would make sense for users to flip on and off at random. > Basically this is the ambiguity because of which I suggested about using a separate negotiation leg for all the bundle level parameters. Maybe it does not make a lot of sense making this big a change for an error scenario, but it will lead to better and more clear designs and might hopefully have better use cases in future. RFC 1990 has remained unchanged (and in widespread use) since 1996. Are you certain that making a fundamental change to the way it is negotiated will bring benefits that are worth the incompatibilities it will cause? If so, then I would insist on seeing those "use cases" documented clearly now, and the compatibility issues described in detail. Changing an established protocol is not a matter of "if you build it, they will come." It has to be done only after all the reasonable alternatives have been exhausted. > One more ambiguity in the protocol that I think can be clarified in RFC is use of IPCP (or any other NCP) over a MC/ML-PPP bundle. Doesn't it make more sense to use only IPCP over NCP when using ML-PPP to resolve the issue of which member link to be used for IPCP? I don't think I understand the question. Once a link joins a bundle, all NCP messages (with some minor exceptions -- the per-link variants of ECP and CCP) are always processed at the bundle head, regardless of encapsulation. This is in section 2 of RFC 1990: fragmentation header. All packets received over links identified as belonging to the multilink arrangement are presented to the same network-layer protocol processing machine, whether they have multilink headers or not. In other words, with MP you have only a single IPCP instance, regardless of how many links the bundle may have, regardless of which link sends the IPCP negotiation messages, and regardless of whether MP headers are used on those messages. You don't get to run a separate instance of IPCP down at the per-link level with MP! Perhaps what you're saying is that you'd like to dedicate one link within a bundle to carry only a single protocol. Provided that you follow the sequence numbering rules in section 4.1, or you send all of those messages without MP headers, you're free to make the links unbalanced in any way you choose. The RFC is intentionally silent on that point; if you do this, it's up to you (the implementor) to decide how you want it to behave. There's no defined negotiation mechanism in MP that will allow you to determine non-uniform use of the links in the bundle. I would suggest that the easiest way to do this (if it's a requirement for your situation) would be to do it by prior arrangement. In other words, have a special configuration knob in your implementation. If negotiation is required, then I think a substantial amount of background information on the application and the requirements will be needed -- so write a draft. -- James Carlson 42.703N 71.076W From vjs@calcite.rhyolite.com Thu May 26 14:55:29 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6267713002B for ; Thu, 26 May 2011 14:55:29 -0700 (PDT) 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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+lfKbxfEjjd for ; Thu, 26 May 2011 14:55:28 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 88AE613002A for ; Thu, 26 May 2011 14:55:28 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p4QLtExu095282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from ; Thu, 26 May 2011 21:55:14 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p4QLtEts095281; Thu, 26 May 2011 21:55:14 GMT Date: Thu, 26 May 2011 21:55:14 GMT From: Vernon Schryver Message-Id: <201105262155.p4QLtEts095281@calcite.rhyolite.com> To: vineet.garg@aricent.com In-Reply-To: <4DDEC6EF.5090205@workingcode.com> X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] Proposal to solve ML-PPP ambiguity X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:55:29 -0000 > From: James Carlson > To: Vineet kumar Garg > Cc: "pppext@ietf.org" > For what it's worth, although I agree that an implementor's guide might > be helpful, What's wrong with the existing implementors' guides? I thought at least this one mentioned that de facto standard tactic for handling MP misconfiguration: "PPP Design, Implementation, and Debugging" (2nd Edition) by James D. Carlson ISBN: 0201700530 See http://www.google.com/search?q=PPP+Design%2C+Implementation%2C+and+Debugging http://www.workingcode.com/ppp/ Vernon Schryver vjs@rhyolite.com From carlsonj@workingcode.com Fri May 27 04:44:48 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BEEE06C2 for ; Fri, 27 May 2011 04:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FigxZe09ENu1 for ; Fri, 27 May 2011 04:44:47 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 85EE3E068F for ; Fri, 27 May 2011 04:44:47 -0700 (PDT) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4RBiXXA024956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 May 2011 07:44:34 -0400 (EDT) Message-ID: <4DDF8EA1.1060004@workingcode.com> Date: Fri, 27 May 2011 07:44:33 -0400 From: James Carlson User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Vernon Schryver References: <201105262155.p4QLtEts095281@calcite.rhyolite.com> In-Reply-To: <201105262155.p4QLtEts095281@calcite.rhyolite.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] Proposal to solve ML-PPP ambiguity X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 11:44:48 -0000 On 05/26/11 17:55, Vernon Schryver wrote: >> From: James Carlson >> To: Vineet kumar Garg >> Cc: "pppext@ietf.org" > >> For what it's worth, although I agree that an implementor's guide might >> be helpful, > > What's wrong with the existing implementors' guides? I thought at > least this one mentioned that de facto standard tactic for handling > MP misconfiguration: I meant an Informational or perhaps Best Practices RFC describing MP implementation issues. I was trying to redirect away from protocol-level fixes and towards documentation fixes. Yeah, I could have suggested googling ... but I was trying to walk a fine line about my own work. (For what it's worth, I no longer get a penny out of it. :-/) -- James Carlson 42.703N 71.076W From stbryant@cisco.com Tue May 31 06:26:18 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D829E06A6; Tue, 31 May 2011 06:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.597 X-Spam-Level: X-Spam-Status: No, score=-110.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLQEYgWelBdp; Tue, 31 May 2011 06:26:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DE32AE07A1; Tue, 31 May 2011 06:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1798; q=dns/txt; s=iport; t=1306848373; x=1308057973; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=eqrGFGuqWIYIjEJob2YJ8cbEjLY7sONg7ojsmUpa7/4=; b=P1eIU1EVE2BcwxkwtcMw1MmXuRZIHHs7Njt86Muz1nNCU4kC86Pp8pkB hMvcrtuQb5rS/lZFNDymP73xGJ5MJjxwewWkCqrgQoYIGZbP1BE2SX8eI 0hWVH6Bg9TW+7HLaBYe/XEC5xWhnQCF49/1m0fTWvp8cWeDa/aWdEzhp7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsIABvr5E2Q/khM/2dsb2JhbABTmAuOEneoV4J6DwGaRYYeBJBPjxs X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208";a="91568918" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 31 May 2011 13:26:11 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4VDQ7ve015034; Tue, 31 May 2011 13:26:07 GMT Received: from dhcp-gpk02-vlan300-64-103-65-100.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4VDQ2W25080; Tue, 31 May 2011 14:26:06 +0100 (BST) Message-ID: <4DE4EC76.6050902@cisco.com> Date: Tue, 31 May 2011 14:26:14 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ietf@ietf.org References: <20110525161357.5909.40860.idtracker@ietfa.amsl.com> In-Reply-To: <20110525161357.5909.40860.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 31 May 2011 06:40:45 -0700 Cc: pppext@ietf.org, The IESG , IETF-Announce Subject: Re: [Pppext] Last Call: (PPP TRILL Protocol Control Protocol) to Proposed Standard X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:26:18 -0000 The RTG-dir review comments : http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01533.html Should be addressed before publication. - Stewart On 25/05/2011 17:13, The IESG wrote: > The IESG has received a request from the Point-to-Point Protocol > Extensions WG (pppext) to consider the following document: > - 'PPP TRILL Protocol Control Protocol' > as a Proposed Standard > > 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 2011-06-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 > > > The Point-to-Point Protocol (PPP) defines a Link Control Protocol > (LCP) and a method for negotiating the use of multi-protocol traffic > over point-to-point links. This document describes PPP support for > Transparent Interconnection of Lots of Links (TRILL) Protocol, > allowing direct communication between Routing Bridges (RBridges) via > PPP links. > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From carlsonj@workingcode.com Tue May 31 10:05:15 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82415E088C for ; Tue, 31 May 2011 10:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a74Yg4xEOj3 for ; Tue, 31 May 2011 10:05:11 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 681D9E0882 for ; Tue, 31 May 2011 10:05:10 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4VH57cl018851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 May 2011 13:05:07 -0400 (EDT) Message-ID: <4DE51FC3.2070301@workingcode.com> Date: Tue, 31 May 2011 13:05:07 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: PPP Extensions Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist Subject: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:05:15 -0000 As part of IETF review, the Routing ADs are looking over draft-ietf-pppext-trill-protocol-06. Not too surprising to me -- given that I still think it's far out of scope -- the text concerning IS-IS System IDs is causing trouble in that review. See this thread: http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533 I wish I could leave the worms safely in the can, but it's looking like that might not be one of the options. Instead of the reference to Bill Simpson's draft, Stewart Bryant suggested replacement text like this: ISO/IEC 10589 states that it is the responsibility of the routeing domain administrative authority to enforce the uniqueness of the system ID. In cases where a zero configuration system is supplied the system manufacturer MUST install a suitable unique identifier at manufacturing time. One way to achieve this is for the manufacturer to use a unique IEEE MAC address following the allocation procedures normally used in the manufacture of an Ethernet interface. This tosses the issue back into the implementor's lap (which, incidentally, is exactly where I think the problem belongs), and suggests an existing and known solution where a MAC identifier may be allocated for the system itself and used as a global ID to construct the necessary IS-IS System ID. For use in this draft, I would alter the wording slightly to indicate that zero-configuration is strongly preferred for TRILL (as guidance), and that obtaining a suitable identifier is the implementor's responsibility, rather than just saying "in cases where." Would this change fly without breaking consensus? Or do we have to start over? -- James Carlson 42.703N 71.076W From d3e3e3@gmail.com Tue May 31 11:20:39 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E686E08C7 for ; Tue, 31 May 2011 11:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.741 X-Spam-Level: X-Spam-Status: No, score=-104.741 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DawX2GX2AjEt for ; Tue, 31 May 2011 11:20:38 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66584E08C6 for ; Tue, 31 May 2011 11:20:38 -0700 (PDT) Received: by yxk30 with SMTP id 30so2588190yxk.31 for ; Tue, 31 May 2011 11:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=mQRvsffsogWbhMmwWTZhmw84m8+KeU+Ryggsk9qUIZM=; b=tI7oGqhOnQfpcxa1iPz0xsQxodrbDehx11ekomscpyhk3Fg0neAUZ1qrWNY2DlEX0I 2Yevujn9+eqS884BIV8MCEb3F8hYJYlLPUa7Dxiub0gaIZWwZ8uCy/d/Be5/KxKF5j7O Rm+e45cESTmVcxCu+IpEqKXZzHa2Z9Yv3VB98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=vlnNE9cgqpfPfMiukDtntnjzgrKIqLHEcY1hCSVK17B9Q4HM6i0pZPIZryr2KXXje4 gOyqW5A71MsBI1WB82fEFne5H+QzGDmvdCQjYHx2vXQpnpiHtfkuWvqAoBKHgw1D18tb b9sVk6+mA5gYh/uvktYQ1BWnvhmbRWBVZPNE8= Received: by 10.150.208.11 with SMTP id f11mr5206026ybg.206.1306866036091; Tue, 31 May 2011 11:20:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.51.2 with HTTP; Tue, 31 May 2011 11:20:16 -0700 (PDT) In-Reply-To: <4DE51FC3.2070301@workingcode.com> References: <4DE51FC3.2070301@workingcode.com> From: Donald Eastlake Date: Tue, 31 May 2011 14:20:16 -0400 Message-ID: To: James Carlson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: PPP Extensions Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:20:39 -0000 James, I'm fine with your suggested tweak of Stewart Bryant's wording. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, May 31, 2011 at 1:05 PM, James Carlson w= rote: > As part of IETF review, the Routing ADs are looking over > draft-ietf-pppext-trill-protocol-06. =A0Not too surprising to me -- given > that I still think it's far out of scope -- the text concerning IS-IS > System IDs is causing trouble in that review. =A0See this thread: > > http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533 > > I wish I could leave the worms safely in the can, but it's looking like > that might not be one of the options. > > Instead of the reference to Bill Simpson's draft, Stewart Bryant > suggested replacement text like this: > > =A0ISO/IEC 10589 states that it is the responsibility of the routeing > =A0domain administrative authority to enforce the uniqueness of the > =A0system ID. In cases where a zero configuration system is > =A0supplied the system manufacturer MUST install a suitable > =A0unique identifier at manufacturing time. One way to achieve > =A0this is for the manufacturer to use a unique IEEE MAC address > =A0following the allocation procedures normally used in the > =A0manufacture of an Ethernet interface. > > This tosses the issue back into the implementor's lap (which, > incidentally, is exactly where I think the problem belongs), and > suggests an existing and known solution where a MAC identifier may be > allocated for the system itself and used as a global ID to construct the > necessary IS-IS System ID. > > For use in this draft, I would alter the wording slightly to indicate > that zero-configuration is strongly preferred for TRILL (as guidance), > and that obtaining a suitable identifier is the implementor's > responsibility, rather than just saying "in cases where." > > Would this change fly without breaking consensus? =A0Or do we have to > start over? > > -- > James Carlson =A0 =A0 =A0 =A0 42.703N 71.076W =A0 =A0 =A0 =A0 > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext >