From CWallace@cygnacom.com Wed Dec 1 04:34:58 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584CF3A6C6B; Wed, 1 Dec 2010 04:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imgOQmb9FDLD; Wed, 1 Dec 2010 04:34:54 -0800 (PST) Received: from sottexchE2.entrust.com (sottexche2.entrust.com [216.191.252.22]) by core3.amsl.com (Postfix) with ESMTP id 98DF83A69ED; Wed, 1 Dec 2010 04:34:54 -0800 (PST) Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE2.entrust.com (216.191.252.22) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 1 Dec 2010 07:35:51 -0500 Received: from scygexch1.cygnacom.com (10.60.50.8) by scygexch7.cygnacom.com (10.4.60.22) with Microsoft SMTP Server id 8.3.106.1; Wed, 1 Dec 2010 07:36:07 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9154.3A0D0863" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: secdir review of draft-stone-mgcp-vbd-08.txt Date: Wed, 1 Dec 2010 07:35:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-stone-mgcp-vbd-08.txt Thread-Index: AcuRU6b/7VIg6RDFTPSE5MacEo0z4Q== From: Carl Wallace To: , , X-Mailman-Approved-At: Wed, 01 Dec 2010 10:52:20 -0800 Cc: s.sharma@cablelabs.com, rkumar@cisco.com, joestone@cisco.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 12:34:58 -0000 ------_=_NextPart_001_01CB9154.3A0D0863 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. =20 This is a re-review. Following the last review, changes were made to the security considerations section to highlight a disconnect with the referenced security considerations in RFC 3435. This seems sufficient to me (though there is a typo in the new text - "securuty"). ------_=_NextPart_001_01CB9154.3A0D0863 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = reviewed this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG.  = These comments were written primarily for the benefit of the security = area directors.  Document editors and WG chairs should treat these = comments just like any other last call comments.

 

This is a = re-review.  Following the last review, changes were made to the = security considerations section to highlight a disconnect with the = referenced security considerations in RFC 3435.  This seems = sufficient to me (though there is a typo in the new text – = “securuty”).

------_=_NextPart_001_01CB9154.3A0D0863-- From sm@resistor.net Wed Dec 1 12:14:15 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7CA28C0EB for ; Wed, 1 Dec 2010 12:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.465 X-Spam-Level: X-Spam-Status: No, score=-103.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a8PulOxtU-P for ; Wed, 1 Dec 2010 12:14:14 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 57D9128C0D6 for ; Wed, 1 Dec 2010 12:14:14 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oB1KEw2R009040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Dec 2010 12:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1291234525; x=1291320925; bh=g5z6xaps5X9IkyDbMMpJ2TSdrdx2U90FiSvyBWcGw5U=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=m6K63q6ldtxrhPCjaPoa1bf+OHv76u/AJmfqw79jUwd+jRxYpqfYZ1+jfhE2lOJo9 e0CxSbk+FtCz6gaeTGU5pG8K50Clwcrheg3KID5AKxyTrfPsUNFtG4dGGRlKU3r+iQ eGYB6ZcGW3u4VIitmbTZu/AXj7ZLGw3VOLhS5m/8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1291234525; x=1291320925; bh=g5z6xaps5X9IkyDbMMpJ2TSdrdx2U90FiSvyBWcGw5U=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Ey1zjRuz6ouyqjXrqHinyli8oiJ9niP+zdDSKTGLh4tLJ8EgOsBElm1wod4l/rN5o wSMo3zPdi0PKjlNSf+/EeIN48ZFuKNwkh8VHifGZrPF5s2cecZOsgz5insi1RGYJqO 4mdf0uTieGZGlrB75wXkjIwJFjJPu8KjH9mAmisM= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=qJOxyzwDsul5DJ+CVV9m2LnlXNhwHNuBr6WoxcFcQi2iokDINb22iH5M83w5dbFKO UeTIG5tbKw5r++6RWCuWBaO+wWvWJqctfhnj3FMJR4/UJVUyaQcCMWZkOhQk/WDFb+C DW6c2DPJTJqpvsVFx0RszbUjPM2g1quGSSO3bD0= Message-Id: <6.2.5.6.2.20101201085038.0d8a44c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 01 Dec 2010 12:14:40 -0800 To: ietf@ietf.org From: SM Subject: Re: Feedback on Day Passes In-Reply-To: <20101122220433.123863A6AB8@core3.amsl.com> References: <20101122220433.123863A6AB8@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 20:14:16 -0000 At 14:04 22-11-10, The IAOC wrote: >As part of the IAOC presentation in Beijing, I said that the IAOC will be >making a decision on Day Passes in the middle of December. I would like >your feedback on the Day Pass experiment. [snip] >Possible reasons to discontinue offering Day Passes: > >- Caused unexpected effect on Nomcom qualification. The IESG published a statement on May 24 [1] on "NomCom Eligibility and Day Passes". According to that statement: "An update to RFC 3777 will be needed to address this situation if at the end of the experiment the IAOC decides to make day passes a regular meeting registration alternative." Could the IAOC and the IESG discuss about the the unexpected effect [2] before it takes a decision about Day Passes? Regards, -sm 1. http://www.ietf.org/iesg/statement/nomcom-eligibility-and-day-passes.html 2. http://www.ietf.org/mail-archive/web/ietf/current/msg61647.html From dhc2@dcrocker.net Wed Dec 1 12:15:50 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CC928C0E2; Wed, 1 Dec 2010 12:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.643 X-Spam-Level: X-Spam-Status: No, score=-6.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzmVZIUcOZLb; Wed, 1 Dec 2010 12:15:49 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 7E76728C0D6; Wed, 1 Dec 2010 12:15:49 -0800 (PST) Received: from [192.168.1.2] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oB1KGvrd004925 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 1 Dec 2010 12:17:03 -0800 Message-ID: <4CF6AD35.2080308@dcrocker.net> Date: Wed, 01 Dec 2010 12:16:53 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: iesg Subject: Re: Last Call: (Authentication-Results Registration For Vouch By Reference Results) to Proposed Standard References: <20101201135537.20212.92034.idtracker@localhost> In-Reply-To: <20101201135537.20212.92034.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 01 Dec 2010 12:17:04 -0800 (PST) Cc: IETF Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 20:15:50 -0000 > The IESG has received a request from an individual submitter to consider > the following document: > - 'Authentication-Results Registration For Vouch By Reference Results' > 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 2010-12-29. VBR usage is still nascent, but the scenario that this draft provides -- evaluation by a border MTA that wishes to pass the results on to an interior MTA or an MUA -- is classic. The specifications seems well enough formed and detailed. Please approve it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From gwz@net-zen.net Wed Dec 1 18:30:15 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA973A682E for ; Wed, 1 Dec 2010 18:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.579 X-Spam-Level: X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 190QRvr4wCMb for ; Wed, 1 Dec 2010 18:30:14 -0800 (PST) Received: from p3plsmtpa01-04.prod.phx3.secureserver.net (p3plsmtpa01-04.prod.phx3.secureserver.net [72.167.82.84]) by core3.amsl.com (Postfix) with SMTP id 9C0A73A6812 for ; Wed, 1 Dec 2010 18:30:14 -0800 (PST) Received: (qmail 4032 invoked from network); 2 Dec 2010 02:31:28 -0000 Received: from unknown (124.120.167.172) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 02 Dec 2010 02:31:27 -0000 From: "Glen Zorn" To: References: <20101201135503.20212.98672.idtracker@localhost> In-Reply-To: <20101201135503.20212.98672.idtracker@localhost> Subject: RE: Last Call: (Prohibiting SSL Version 2.0) to Proposed Standard Date: Thu, 2 Dec 2010 09:31:14 +0700 Organization: Network Zen Message-ID: <002a01cb91c8$ff8f4fe0$feadefa0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuRYBZ3dIPgyVnZTee4pzcyBHVLRgAZm1rw Content-Language: en-us Cc: tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 02:30:15 -0000 Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO messages." and "TLS servers MUST NOT negotiate or use SSL 2.0" and later "TLS servers that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO messages as the first message of a TLS handshake for interoperability with old clients." Taken together, I find these statements quite confusing, if not outright self-contradictory. Maybe, a "However" might fix the problem, though: TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS servers MAY accept SSL 2.0 CLIENT-HELLO messages as the first message of a TLS handshake in order to maintain interoperability with legacy clients. From johnl@iecc.com Wed Dec 1 19:44:37 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D48E3A6873 for ; Wed, 1 Dec 2010 19:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.484 X-Spam-Level: X-Spam-Status: No, score=-110.484 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+iU4uKb-OPI for ; Wed, 1 Dec 2010 19:44:36 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 2F1223A686D for ; Wed, 1 Dec 2010 19:44:36 -0800 (PST) Received: (qmail 92728 invoked from network); 2 Dec 2010 03:45:50 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 2 Dec 2010 03:45:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=e16f.4cf7166e.k1012; i=johnl@user.iecc.com; bh=td5rNqsdjNXYFaDTQvrhzeZ18wVSybAxpYe5XyaaZ7Q=; b=GWyLLMp/Opvj65qfxfX9NVRbfmg7bLFfD7VetMzMnE+DLasbBuC3E3nUAI8/IbySdxAiYDX9k7c7GmEHBdSvYxXwvEapI4T/Gm23RtPzZ3NFtpYzoM4eMKrayzOamb4WhETQ7hiXzT4rqeu5stZDdax9mtpwbcf4LIJacC2Dts0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Dec 2010 03:45:50 -0000 Message-ID: <20101202034550.57710.qmail@joyce.lan> From: John Levine To: ietf@ietf.org Subject: Re: Last Call: (Authentication-Results Registration For Vouch By Reference Results) to Proposed Standard In-Reply-To: <4CF6AD35.2080308@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 03:44:37 -0000 >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Authentication-Results Registration For Vouch By Reference Results' >> 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 2010-12-29. I'm one of the authors of the VBR spec. This spec will be useful for systems that want to collect authentication info at the border (where for a variety of reasons it is easier to do so) and pass it along to an interior engine that interprets it. Please approve it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From gwz@net-zen.net Thu Dec 2 06:00:27 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457DC28C0CE for ; Thu, 2 Dec 2010 06:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0u+UcEbhbyo for ; Thu, 2 Dec 2010 06:00:26 -0800 (PST) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id 738FF28C129 for ; Thu, 2 Dec 2010 06:00:26 -0800 (PST) Received: (qmail 7926 invoked from network); 2 Dec 2010 14:01:41 -0000 Received: from unknown (124.120.167.172) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 02 Dec 2010 14:01:40 -0000 From: "Glen Zorn" To: "'Michael D'Errico'" References: <20101201135503.20212.98672.idtracker@localhost> <002a01cb91c8$ff8f4fe0$feadefa0$@net> <4CF7283C.2030905@pobox.com> In-Reply-To: <4CF7283C.2030905@pobox.com> Subject: RE: [TLS] Last Call: (Prohibiting SSL Version 2.0) to Proposed Standard Date: Thu, 2 Dec 2010 21:01:23 +0700 Organization: Network Zen Message-ID: <000001cb9229$6a09e960$3e1dbc20$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuR3grKseMC7xo1TYSM6z+JPSvaAAAStEkQ Content-Language: en-us Cc: ietf@ietf.org, tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 14:00:27 -0000 Michael D'Errico [mailto:mike-list@pobox.com] writes: > Glen Zorn wrote: > > Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO > messages." > > and "TLS servers MUST NOT negotiate or use SSL 2.0" and later "TLS > servers > > that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO > messages as > > the first message of a TLS handshake for interoperability with old > clients." > > Taken together, I find these statements quite confusing, if not > outright > > self-contradictory. Maybe, a "However" might fix the problem, though: > > > > TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS > servers > > MAY accept SSL 2.0 CLIENT-HELLO messages as the first message of a > > TLS handshake in order to maintain interoperability with legacy > > clients. > > Glen, > > There is no contradiction among the statements, but they may be > confusing (I > can't tell anymore since I've gone through the drafts several times). Maybe I just don't understand the word "use". It seems like if a server accepts a protocol message it's using the protocol... ... From jsalowey@cisco.com Thu Dec 2 10:23:36 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE0C28C0EE; Thu, 2 Dec 2010 10:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92JpOdqWyAFQ; Thu, 2 Dec 2010 10:23:35 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4DB7628C0FB; Thu, 2 Dec 2010 10:23:35 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA5z90yrR7H+/2dsb2JhbACjJXGnbpsghUcEhF6GCIMR X-IronPort-AV: E=Sophos;i="4.59,289,1288569600"; d="scan'208";a="629659475" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2010 18:24:51 +0000 Received: from [10.33.251.139] ([10.33.251.139]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB2IOnp5014382; Thu, 2 Dec 2010 18:24:50 GMT Subject: Re: Last Call: (Prohibiting SSL Version 2.0) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <002a01cb91c8$ff8f4fe0$feadefa0$@net> Date: Thu, 2 Dec 2010 10:25:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101201135503.20212.98672.idtracker@localhost> <002a01cb91c8$ff8f4fe0$feadefa0$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1082) Cc: ietf@ietf.org, tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 18:23:36 -0000 Hi Glen, In reading the text and I'm not exactly sure where the confusion or = contradiction comes in. I think your suggested text is fine, but I'm = not sure how it improves things. If I understand your point correctly = accepting an SSL 2.0 hello as the first message in the TLS handshake is = an example of using at least part of SSL 2.0, so we should indicate that = this is an exception to the MUST NOT use SSL 2.0 directive. Is this = your concern? Thanks, Joe On Dec 1, 2010, at 6:31 PM, Glen Zorn wrote: > Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO = messages." > and "TLS servers MUST NOT negotiate or use SSL 2.0" and later "TLS = servers > that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO = messages as > the first message of a TLS handshake for interoperability with old = clients." > Taken together, I find these statements quite confusing, if not = outright > self-contradictory. Maybe, a "However" might fix the problem, though:=20= >=20 > TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS = servers=20 > MAY accept SSL 2.0 CLIENT-HELLO messages as the first message of = a=20 > TLS handshake in order to maintain interoperability with legacy=20= > clients. >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From mrex@sap.com Thu Dec 2 10:45:17 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4FD3A69C4; Thu, 2 Dec 2010 10:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.112 X-Spam-Level: X-Spam-Status: No, score=-10.112 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRiDxQRA6aEu; Thu, 2 Dec 2010 10:45:16 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id D65453A69D5; Thu, 2 Dec 2010 10:45:15 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oB2IkUhg023691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Dec 2010 19:46:30 +0100 (MET) From: Martin Rex Message-Id: <201012021846.oB2IkTCi019858@fs4113.wdf.sap.corp> Subject: Re: [TLS] Last Call: To: gwz@net-zen.net (Glen Zorn) Date: Thu, 2 Dec 2010 19:46:29 +0100 (MET) In-Reply-To: <000001cb9229$6a09e960$3e1dbc20$@net> from "Glen Zorn" at Dec 2, 10 09:01:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal03 X-SAP: out Cc: mike-list@pobox.com, ietf@ietf.org, tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 18:45:17 -0000 Glen Zorn wrote: > > > Glen Zorn wrote: > > > Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO > > messages." > > > and "TLS servers MUST NOT negotiate or use SSL 2.0" and later "TLS > > servers > > > that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO > > messages as > > > the first message of a TLS handshake for interoperability with old > > clients." > > > Taken together, I find these statements quite confusing, if not > > outright > > > self-contradictory. Maybe, a "However" might fix the problem, though: > > > > > > TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS > > servers > > > MAY accept SSL 2.0 CLIENT-HELLO messages as the first message of a > > > TLS handshake in order to maintain interoperability with legacy > > > clients. > > Maybe I just don't understand the word "use". It seems like if a server > accepts a protocol message it's using the protocol... With "negotiate" I meant returning a ServerHello handshake message with that version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 ServerHello with a server version of { 0x02,0x00 }). With "use" I meant to successfully complete the handshake and start exchanging application data protected under protocol version {0x02,0x00}. The Server accepts the SSL 2.0 CLIENT-HELLO protocol data unit (PDU), but not the SSL 2.0 protocol. If there are no SSLv3 or TLS cipher suites in that CLIENT-HELLO, or if the (version) field of the SSL 2.0 CLIENT-HELLO does not indicate at least 3.0, then the server still MUST abort. -Martin From Jeff.Hodges@KingsMountain.com Thu Dec 2 12:59:25 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20DE3A69ED for ; Thu, 2 Dec 2010 12:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.514 X-Spam-Level: X-Spam-Status: No, score=-101.514 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_DUL=0.877, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVlORcDDLkAt for ; Thu, 2 Dec 2010 12:59:24 -0800 (PST) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id C20623A699D for ; Thu, 2 Dec 2010 12:59:24 -0800 (PST) Received: (qmail 24899 invoked by uid 0); 2 Dec 2010 21:00:40 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 2 Dec 2010 21:00:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=mLLlNIawjdvlt7qO2QWEJkDNBkHtfZk4UjVTgRKVapLeh8AuwDP0a/FyG/njMtgPVQRzzyWIy21gAHAnWLz16ezCbaAj1KyXxACr47SnPE6Fhq3qZKM5HhCU+xEy7aZJ; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.42]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1POGGd-00046E-04; Thu, 02 Dec 2010 14:00:39 -0700 Message-ID: <4CF808F3.10708@KingsMountain.com> Date: Thu, 02 Dec 2010 13:00:35 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "Richard L. Barnes" Subject: Re: [http-state] Gen-ART LC review of draft-ietf-httpstate-cookie-18 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF Discussion List , http-state X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 20:59:25 -0000 Hey Richard (& Adam), Thanks very much for the detailed & thorough review, and to you both for promptly resolving the raised issues. =JeffH From L.Wood@surrey.ac.uk Wed Dec 1 14:54:41 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72993A6802; Wed, 1 Dec 2010 14:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkJcHyrFa4I0; Wed, 1 Dec 2010 14:54:40 -0800 (PST) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id A6D283A672F; Wed, 1 Dec 2010 14:54:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-78.messagelabs.com!1291244152!26957781!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 11993 invoked from network); 1 Dec 2010 22:55:53 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-14.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 1 Dec 2010 22:55:53 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Wed, 1 Dec 2010 22:55:52 +0000 From: To: Date: Wed, 1 Dec 2010 22:53:35 +0000 Subject: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Topic: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Index: AQHLkarnKTi5BAB2C0mrGk8xbssWew== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 02 Dec 2010 13:56:28 -0800 Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 22:54:41 -0000 forwarding comments as per last call request. Lloyd Wood http://tinyurl.com/lloydwood-ccsr ________________________________________ From: Wood L Dr (Electronic Eng) Sent: 01 December 2010 07:56 To: turners@ieca.com; lily.chen@nist.gov; alexey.melnikov@isode.com Cc: Wood L Dr (Electronic Eng) Subject: Last Call draft-turner-md5-seccon-update http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/?include_tex= t=3D1 says The attacks on HMAC-MD5 do not seem to indicate a practical vulnerability when used as a message authentication code. or, when used for error detection, which is not discussed. MD5 is still perfectly acceptable in non-security contexts, for detecting e= .g. file corruption, as in checking that the .iso disk image downloaded is = good to use. I've spent a lot of time in the IETF dealing with security types who believ= e that, because MD5 has flaws that affect security use, it should therefore= not be used at all in any context -- although it's fine in a reliability-o= nly context and very useful for detecting errors. (This topic has derailed = protocol development, and has also been the subject of more than one IETF t= alk.) The document should imo indicate that MD5 remains acceptable in non-s= ecurity contexts, and indicate clearly and verbosely that the document is l= imiting its scope to security applications only, not non-security applicati= ons. Security Fear, Uncertainty and Doubt should not be allowed to spill ov= er into non-security contexts. I understand that this issue has been raised with the authors privately pre= viously by others, but has not been addressed. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood The IESG has received a request from an individual submitter to consider the following document: - 'Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-12-22. 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. From jg@goodmailsystems.com Wed Dec 1 19:51:03 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5143A686E for ; Wed, 1 Dec 2010 19:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 191FRUTTAqlR for ; Wed, 1 Dec 2010 19:51:02 -0800 (PST) Received: from mx1.goodmailsystems.com (mx1.goodmailsystems.com [67.110.227.25]) by core3.amsl.com (Postfix) with ESMTP id 329273A686A for ; Wed, 1 Dec 2010 19:51:01 -0800 (PST) Received: (qmail 1746 invoked from network); 2 Dec 2010 03:52:16 -0000 Received: from unknown (HELO [10.34.5.109]) (authenticated:jay@[10.34.5.109]) (envelope-sender ) by mx1.goodmailsystems.com (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 2 Dec 2010 03:52:16 -0000 Message-Id: <6782A22F-7AA1-43CF-B1A9-F874C50144C5@goodmailsystems.com> From: Jay Gopalakrishnan To: ietf@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Last Call: (Authentication-Results Registration For Vouch By Reference Results) to Proposed Standard Date: Wed, 1 Dec 2010 19:52:16 -0800 References: X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Thu, 02 Dec 2010 13:56:28 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 03:52:26 -0000 > > The IESG has received a request from an individual submitter to > consider > the following document: > - 'Authentication-Results Registration For Vouch By Reference Results' > 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 2010-12-29. This proposal will enable a standards-based approach to VBR processing and its relay of results. We expect this to be useful to mailbox providers, senders and third party vouching providers. Goodmail supports the publication of this document and also plans to implement it once published. > Regards, Jay -- Jay Gopalakrishnan Sr. Director, Engineering & Partner Programs Goodmail Systems www.goodmail.com From mike-list@pobox.com Wed Dec 1 21:00:43 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354733A689B; Wed, 1 Dec 2010 21:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T+5o1tQdTwG; Wed, 1 Dec 2010 21:00:42 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 0DA9C3A6899; Wed, 1 Dec 2010 21:00:40 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B75973F72; Thu, 2 Dec 2010 00:02:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=3Mxtlog5PtjX /9GQOi5V0/rBCAA=; b=r9xNuecF1k7zYSzIVr8YyC91bVDlmYXwM++qXaMlBLh4 j8hLHPPG4xxn2vQGdepc5mMrcXMC+Cq8QJc/JSE0oWafjjglMCJj27mvymUWZ8iD Fezw7jck32MedQY6U1PVOImYTiJTzihzfQzWd16HJZmf2jKveM04e2qIDPWoEng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=sOGOkB fnAYCFJS8zZHQ7+1hMoHhibeR0xED2eqen667cmMINMIwKERhlYeo5ag15mTDdmV KXcCF2MDwnE6w2WWSPOpJ9rThxyvHhFh87rLnSLgEjyBP97vqzsf2J9LlKqh45Yq s7OioziBTcJabtxD5kyH/KgukvVrMPksaXsfk= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 595103F70; Thu, 2 Dec 2010 00:02:12 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 5FDA43F6D; Thu, 2 Dec 2010 00:02:09 -0500 (EST) Message-ID: <4CF7283C.2030905@pobox.com> Date: Wed, 01 Dec 2010 21:01:48 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Glen Zorn Subject: Re: [TLS] Last Call: (Prohibiting SSL Version 2.0) to Proposed Standard References: <20101201135503.20212.98672.idtracker@localhost> <002a01cb91c8$ff8f4fe0$feadefa0$@net> In-Reply-To: <002a01cb91c8$ff8f4fe0$feadefa0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 52C88B62-FDD1-11DF-8898-CDEAE6EC64FC-38729857!a-pb-sasl-sd.pobox.com X-Mailman-Approved-At: Thu, 02 Dec 2010 13:56:28 -0800 Cc: ietf@ietf.org, tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 05:00:43 -0000 Glen Zorn wrote: > Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO messages." > and "TLS servers MUST NOT negotiate or use SSL 2.0" and later "TLS servers > that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO messages as > the first message of a TLS handshake for interoperability with old clients." > Taken together, I find these statements quite confusing, if not outright > self-contradictory. Maybe, a "However" might fix the problem, though: > > TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS servers > MAY accept SSL 2.0 CLIENT-HELLO messages as the first message of a > TLS handshake in order to maintain interoperability with legacy > clients. Glen, There is no contradiction among the statements, but they may be confusing (I can't tell anymore since I've gone through the drafts several times). The idea is that: - no TLS client should ever negotiate SSL 2.0; therefore there is never a need for it to send an SSL 2.0 CLIENT-HELLO - servers, however, need to interoperate with older software that might send an SSL 2.0 CLIENT-HELLO even though it supports SSLv3 or later, so it's OK for them to accept that message as long as the resulting version is not SSL 2.0. The reason it is OK to accept CLIENT-HELLO is because it can carry the SCSV cipher suite value used to plug the renegotiation security hole (RFC 5746). Mike From marsh@extendedsubset.com Thu Dec 2 10:10:11 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D59E28C13C; Thu, 2 Dec 2010 10:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNjn-cCCDNP6; Thu, 2 Dec 2010 10:10:04 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 0C97A28C136; Thu, 2 Dec 2010 10:10:03 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PODcl-000Mx4-Gb; Thu, 02 Dec 2010 18:11:19 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CE2A96018; Thu, 2 Dec 2010 18:11:17 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+oA6UNnysfvu8Ex31KMuOfqFH26eFeCps= Message-ID: <4CF7E145.8050209@extendedsubset.com> Date: Thu, 02 Dec 2010 12:11:17 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Glen Zorn Subject: Re: [TLS] Last Call: (Prohibiting SSL Version 2.0) to Proposed Standard References: <20101201135503.20212.98672.idtracker@localhost> <002a01cb91c8$ff8f4fe0$feadefa0$@net> <4CF7283C.2030905@pobox.com> <000001cb9229$6a09e960$3e1dbc20$@net> In-Reply-To: <000001cb9229$6a09e960$3e1dbc20$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Dec 2010 13:56:28 -0800 Cc: 'Michael D'Errico' , ietf@ietf.org, tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 18:10:11 -0000 On 12/02/2010 08:01 AM, Glen Zorn wrote: > > Maybe I just don't understand the word "use". It seems like if a > server accepts a protocol message it's using the protocol... Hard to argue with that logic...but... :-) The Client Hello message is the first message sent in the protocol. Its format changed completely from SSLv2 to what is used by SSLv3 thorough TLS 1.2. The number one job of the Hello messages (in any protocol) is generally to negotiate the version of the protocol used for all subsequent messages. Everything else in the Hello message is, in a sense, put there as an optimization to save some round trips. Since the ancient v2 servers obviously couldn't understand one bit of a v3 or later Client Hello (some would break quite badly), there was an option in the SSLv3 spec to lead off the handshake with a v2-compatible Client Hello. A direct transliteration of the v3 Client Hello message to a v2 was defined The only reason that worked was because the v3 Hello didn't introduce any significant new information (when it was first defined). So it is, in fact, possible to use a SSLv2 Client Hello message with later protocols, even if neither endpoint is willing to speak SSLv2 for the actual connection. There is a significant percentage of handshakes today which lead off with a v2 Hello, even though the vast majority of servers support TLS 1.0. The renegotiation problem required a means to signal at least one new flag (roughly, "I'm patched") in the initial Hello message. This is probably still fresh on everyone's minds, so the fact that a means was found to signal this bit in the SSLv2-format Client Hello message still feels relevant. If it had not been possible to squeeze that extra flag in, the text we have been discussing would be much different. On 12/01/2010 08:31 PM, Glen Zorn wrote: > Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO > messages." and "TLS servers MUST NOT negotiate or use SSL 2.0" and > later "TLS servers that do not support SSL 2.0 MAY accept version > 2.0 CLIENT-HELLO messages as the first message of a TLS handshake for > interoperability with old clients." Taken together, I find these > statements quite confusing, if not outright self-contradictory. I don't see any problem with them. Sometimes the wording in RFCs reads a bit like a bullet-point list of standalone requirements that got formatted into a paragraph. I find this style to actually be quite comforting when you go to implement something. You can turn it into an implementation checklist with less chance that you might lose something written between the lines. > Maybe, a "However" might fix the problem, though: > > TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS servers > MAY accept SSL 2.0 CLIENT-HELLO messages as the first message of a > TLS handshake in order to maintain interoperability with legacy > clients. I do like your wording better. But I don't think it's enough of a technical improvement to necessitate change during last call. - Marsh From jg@goodmailsystems.com Thu Dec 2 11:31:33 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD6B28C17C for ; Thu, 2 Dec 2010 11:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvVktSspBJIy for ; Thu, 2 Dec 2010 11:31:32 -0800 (PST) Received: from mx1.goodmailsystems.com (mx1.goodmailsystems.com [67.110.227.25]) by core3.amsl.com (Postfix) with ESMTP id 8980C28C14D for ; Thu, 2 Dec 2010 11:31:32 -0800 (PST) Received: (qmail 17660 invoked from network); 2 Dec 2010 19:32:48 -0000 Received: from unknown (HELO [10.34.3.149]) (authenticated:jay@[10.34.3.149]) (envelope-sender ) by mx1.goodmailsystems.com (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 2 Dec 2010 19:32:48 -0000 Message-Id: <181D3967-25E1-49DF-8042-7B4FE7BF4554@goodmailsystems.com> From: Jay Gopalakrishnan To: ietf@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-16--521445937 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Last Call: (Authentication-Results Registration For Vouch By Reference Results) to Proposed Standard Date: Thu, 2 Dec 2010 11:32:46 -0800 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Thu, 02 Dec 2010 13:56:28 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 19:31:33 -0000 --Apple-Mail-16--521445937 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > The IESG has received a request from an individual submitter to > consider > the following document: > - 'Authentication-Results Registration For Vouch By Reference Results' > 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 2010-12-29. This proposal will enable a standards-based approach to VBR processing and its relay of results. We expect this to be useful to mailbox providers, senders and third party vouching providers. Goodmail supports the publication of this document and also plans to implement it once published. Regards, Jay -- Jay Gopalakrishnan Sr. Director, Engineering & Partner Programs Goodmail Systems www.goodmail.com --Apple-Mail-16--521445937 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

The IESG has received a request from an individual = submitter to consider
the = following document:
- = 'Authentication-Results Registration For Vouch By Reference = Results'
<draft-kucherawy-authres-vbr-01.txt> 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 = 2010-12-29.

This proposal will enable a = standards-based approach to VBR processing and its relay of results. We = expect this to be useful to mailbox providers, senders and third party = vouching providers. Goodmail supports the publication of this document = and also plans to implement it once = published.


Regards,

Jay

--

Jay = Gopalakrishnan
Sr. Director, Engineering & Partner = Programs
Goodmail Systems
www.goodmail.com
= --Apple-Mail-16--521445937-- From jdfalk-lists@cybernothing.org Thu Dec 2 17:50:38 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1FB3A6A2D; Thu, 2 Dec 2010 17:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IIV64jP6lUB; Thu, 2 Dec 2010 17:50:37 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 94FC93A69F8; Thu, 2 Dec 2010 17:50:37 -0800 (PST) Received: from [172.19.10.114] (c-76-102-142-226.hsd1.ca.comcast.net [76.102.142.226]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oB31poxR012741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Dec 2010 17:51:52 -0800 Subject: Re: Last Call: (Authentication-Results Registration For Vouch By Reference Results) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "J.D. Falk" In-Reply-To: <4CF6AD35.2080308@dcrocker.net> Date: Thu, 2 Dec 2010 17:51:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9F73A5AB-9C65-42E1-8D41-2C1842BB28AB@cybernothing.org> References: <20101201135537.20212.92034.idtracker@localhost> <4CF6AD35.2080308@dcrocker.net> To: iesg X-Mailer: Apple Mail (2.1082) Cc: IETF Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 01:50:38 -0000 On Dec 1, 2010, at 12:16 PM, Dave CROCKER wrote: >> The IESG has received a request from an individual submitter to = consider >> the following document: >> - 'Authentication-Results Registration For Vouch By Reference = Results' >> as a Proposed Standard >>=20 >> 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 2010-12-29. >=20 > VBR usage is still nascent, but the scenario that this draft provides = -- evaluation by a border MTA that wishes to pass the results on to an = interior MTA or an MUA -- is classic. The specifications seems well = enough formed and detailed. >=20 > Please approve it. +1 From gwz@net-zen.net Thu Dec 2 20:43:25 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E568628C14E for ; Thu, 2 Dec 2010 20:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.089 X-Spam-Level: X-Spam-Status: No, score=-102.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbB-1G1plsKV for ; Thu, 2 Dec 2010 20:43:24 -0800 (PST) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by core3.amsl.com (Postfix) with SMTP id C87D43A688E for ; Thu, 2 Dec 2010 20:43:24 -0800 (PST) Received: (qmail 4317 invoked from network); 3 Dec 2010 04:44:37 -0000 Received: from unknown (124.120.77.76) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 03 Dec 2010 04:44:36 -0000 From: "Glen Zorn" To: References: <000001cb9229$6a09e960$3e1dbc20$@net> from "Glen Zorn" at Dec 2, 10 09:01:23 pm <201012021846.oB2IkTCi019858@fs4113.wdf.sap.corp> In-Reply-To: <201012021846.oB2IkTCi019858@fs4113.wdf.sap.corp> Subject: RE: [TLS] Last Call: Date: Fri, 3 Dec 2010 11:44:18 +0700 Organization: Network Zen Message-ID: <000401cb92a4$c1917ba0$44b472e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuSnxbKfvTgGoauTl+fVDS+abslrAABOzAg Content-Language: en-us Cc: mike-list@pobox.com, ietf@ietf.org, tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 04:43:26 -0000 Martin Rex [mailto:mrex@sap.com] writes: > Glen Zorn wrote: > > > > > Glen Zorn wrote: > > > > Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO > > > messages." > > > > and "TLS servers MUST NOT negotiate or use SSL 2.0" and later "TLS > > > servers > > > > that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO > > > messages as > > > > the first message of a TLS handshake for interoperability with old > > > clients." > > > > Taken together, I find these statements quite confusing, if not > > > outright > > > > self-contradictory. Maybe, a "However" might fix the problem, > though: > > > > > > > > TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS > > > servers > > > > MAY accept SSL 2.0 CLIENT-HELLO messages as the first > message of a > > > > TLS handshake in order to maintain interoperability with > legacy > > > > clients. > > > > Maybe I just don't understand the word "use". It seems like if a > server > > accepts a protocol message it's using the protocol... > > > With "negotiate" I meant returning a ServerHello handshake message with > that version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 > ServerHello with a server version of { 0x02,0x00 }). > > With "use" I meant to successfully complete the handshake and start > exchanging application data protected under protocol version > {0x02,0x00}. Maybe you could spell these things out in the draft just as you have above? > > > The Server accepts the SSL 2.0 CLIENT-HELLO protocol data unit (PDU), > but not the SSL 2.0 protocol. I see. Perhaps the distinction between PDU and "protocol" is just too subtle for me, but assuming (maybe too generously ;-) that I'm not a total moron, others might find it a little bit confusing as well. > If there are no SSLv3 or TLS cipher > suites in that CLIENT-HELLO, or if the (version) field of the > SSL 2.0 CLIENT-HELLO does not indicate at least 3.0, then the server > still MUST abort. > > > -Martin From gwz@net-zen.net Thu Dec 2 21:10:00 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED1428C18C for ; Thu, 2 Dec 2010 21:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7JeB5Yi2R6S for ; Thu, 2 Dec 2010 21:09:59 -0800 (PST) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id 25B6128C17D for ; Thu, 2 Dec 2010 21:09:59 -0800 (PST) Received: (qmail 22927 invoked from network); 3 Dec 2010 05:11:15 -0000 Received: from unknown (124.120.77.76) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 03 Dec 2010 05:11:14 -0000 From: "Glen Zorn" To: "'Joe Salowey'" References: <20101201135503.20212.98672.idtracker@localhost> <002a01cb91c8$ff8f4fe0$feadefa0$@net> In-Reply-To: Subject: RE: Last Call: (Prohibiting SSL Version 2.0) to Proposed Standard Date: Fri, 3 Dec 2010 12:10:57 +0700 Organization: Network Zen Message-ID: <000001cb92a8$7a2a1390$6e7e3ab0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuSWHBbb3ddVFwqTzeuCCD4iphdTAAT/J9w Content-Language: en-us Cc: ietf@ietf.org, tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 05:10:00 -0000 Joe Salowey [mailto:jsalowey@cisco.com] writes: > Hi Glen, > > In reading the text and I'm not exactly sure where the confusion or > contradiction comes in. I think your suggested text is fine, but I'm > not sure how it improves things. If I understand your point correctly > accepting an SSL 2.0 hello as the first message in the TLS handshake is > an example of using at least part of SSL 2.0, so we should indicate that > this is an exception to the MUST NOT use SSL 2.0 directive. Is this > your concern? Yup. ... From narten@us.ibm.com Thu Dec 2 21:51:59 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CDC3A6A6D for ; Thu, 2 Dec 2010 21:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.892 X-Spam-Level: X-Spam-Status: No, score=-104.892 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JQhT9k72uNE for ; Thu, 2 Dec 2010 21:51:58 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 4F5D93A68AF for ; Thu, 2 Dec 2010 21:51:58 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB35lMOV010517 for ; Thu, 2 Dec 2010 22:47:22 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB35r37Z149220 for ; Thu, 2 Dec 2010 22:53:03 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB35r3Fa028110 for ; Thu, 2 Dec 2010 22:53:03 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oB35r2PR028076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Dec 2010 22:53:03 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id oB35r2aH021663 for ; Fri, 3 Dec 2010 00:53:02 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.4/8.14.4/Submit) id oB35r21e021647 for ietf@ietf.org; Fri, 3 Dec 2010 00:53:02 -0500 From: Thomas Narten Message-Id: <201012030553.oB35r21e021647@rotala.raleigh.ibm.com> Date: Fri, 03 Dec 2010 00:53:02 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 05:51:59 -0000 Total of 36 messages in the last 7 days. script run at: Fri Dec 3 00:53:02 EST 2010 Messages | Bytes | Who --------+------+--------+----------+------------------------ 11.11% | 4 | 16.66% | 49132 | ron.even.tlv@gmail.com 8.33% | 3 | 13.84% | 40814 | rbarnes@bbn.com 5.56% | 2 | 10.40% | 30676 | ietf@adambarth.com 8.33% | 3 | 5.58% | 16437 | jsalowey@cisco.com 8.33% | 3 | 5.06% | 14908 | gwz@net-zen.net 5.56% | 2 | 6.55% | 19322 | jmpolk@cisco.com 5.56% | 2 | 5.13% | 15137 | rodunn@cisco.com 5.56% | 2 | 3.83% | 11285 | jg@goodmailsystems.com 2.78% | 1 | 3.77% | 11109 | bob.hinden@gmail.com 2.78% | 1 | 3.61% | 10643 | joelja@bogus.com 2.78% | 1 | 2.64% | 7784 | tobias.gondrom@gondrom.org 2.78% | 1 | 2.60% | 7654 | cwallace@cygnacom.com 2.78% | 1 | 2.44% | 7208 | marsh@extendedsubset.com 2.78% | 1 | 2.18% | 6428 | l.wood@surrey.ac.uk 2.78% | 1 | 2.11% | 6210 | mike-list@pobox.com 2.78% | 1 | 2.01% | 5927 | narten@us.ibm.com 2.78% | 1 | 1.88% | 5556 | sm@resistor.net 2.78% | 1 | 1.79% | 5269 | d3e3e3@gmail.com 2.78% | 1 | 1.71% | 5027 | mrex@sap.com 2.78% | 1 | 1.64% | 4837 | johnl@iecc.com 2.78% | 1 | 1.57% | 4634 | dhc2@dcrocker.net 2.78% | 1 | 1.50% | 4415 | jdfalk-lists@cybernothing.org 2.78% | 1 | 1.50% | 4411 | jeff.hodges@kingsmountain.com --------+------+--------+----------+------------------------ 100.00% | 36 |100.00% | 294823 | Total From vesely@tana.it Fri Dec 3 03:42:55 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A4B28C18C for ; Fri, 3 Dec 2010 03:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.327 X-Spam-Level: X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrsPWoIqo43I for ; Fri, 3 Dec 2010 03:42:54 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B6A2428C191 for ; Fri, 3 Dec 2010 03:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1291376647; bh=KYkpheghHB8ooucyDaZIvJZQazoDm+5GpYQAoBQ+EK0=; l=792; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Sy6GKPcXDJaXkfor6Q1e5ggdymn9zYvVmf2oFsVCtfqIXD0Nz5pgxuOmeDlfAI5MD 0OgWd8rtxkIhUD9qg26J4Hph57v23+TVjcDRAb6nNhbjHXsQPQcuU19Pyjad7e/bNh eq/ywAqkvZuZNA89xf/eolI7v6T87rm4pXeEw21M= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 03 Dec 2010 12:44:07 +0100 id 00000000005DC03F.000000004CF8D807.00002D6C Message-ID: <4CF8D808.9010501@tana.it> Date: Fri, 03 Dec 2010 12:44:08 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Last Call: (Authentication-Results Registration For Vouch By Reference Results) to Proposed Standard References: <20101202034550.57710.qmail@joyce.lan> In-Reply-To: <20101202034550.57710.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 11:42:56 -0000 On 02/Dec/10 04:45, John Levine wrote: >>> The IESG has received a request from an individual submitter to consider >>> the following document: >>> - 'Authentication-Results Registration For Vouch By Reference Results' >>> 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 2010-12-29. > > I'm one of the authors of the VBR spec. This spec will be useful for > systems that want to collect authentication info at the border (where > for a variety of reasons it is easier to do so) and pass it along to > an interior engine that interprets it. > > Please approve it. +1 From turners@ieca.com Fri Dec 3 07:55:01 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158C43A696C for ; Fri, 3 Dec 2010 07:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB6z1ilhsPTD for ; Fri, 3 Dec 2010 07:55:00 -0800 (PST) Received: from nm20-vm0.bullet.mail.sp2.yahoo.com (nm20-vm0.bullet.mail.sp2.yahoo.com [98.139.91.218]) by core3.amsl.com (Postfix) with SMTP id 3E3CA28C105 for ; Fri, 3 Dec 2010 07:55:00 -0800 (PST) Received: from [98.139.91.64] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 03 Dec 2010 15:56:15 -0000 Received: from [98.139.91.45] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 03 Dec 2010 15:56:15 -0000 Received: from [127.0.0.1] by omp1045.mail.sp2.yahoo.com with NNFMP; 03 Dec 2010 15:56:15 -0000 X-Yahoo-Newman-Id: 525442.22487.bm@omp1045.mail.sp2.yahoo.com Received: (qmail 52083 invoked from network); 3 Dec 2010 15:56:15 -0000 Received: from thunderfish.local (turners@71.191.10.118 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 03 Dec 2010 07:56:14 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: .MdzyhEVM1khw..xrwxzRevjxh52SoeA_8uCcFc8Uprt93J yMlUZHR7_i4bwOPoV3Eg4lfWQlR8B.Y9nn87uQQqPrNDjHS7n6H5SOuXvLY4 RNTf.1UQ_PioO4CESfU6rc3Fhy4AHnJsODHwW_PY9eLhyL3c2IjgLOBK9yeL uHFSvwKvGDeCcwlf6jeYP2SzTwLemAlXx7F8FTbkgHOggEnfDEh9Pmr3zszn ptaYAU.QsCDtYPoakzHX8liM5zzIWzGd4qQemSs5noRLuAaYusF1qlHjmI8i k0Yo4LKOJSLuNHN1kkEOdHmCySFvUmDUSUqQNVQZVRvqyaXe7zVU7pG_hyUm OMvByH2RnT1bwkhnBGw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CF9131C.6090303@ieca.com> Date: Fri, 03 Dec 2010 10:56:12 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 15:55:01 -0000 On 12/1/10 5:53 PM, L.Wood@surrey.ac.uk wrote: > forwarding comments as per last call request. > > Lloyd Wood > http://tinyurl.com/lloydwood-ccsr > ________________________________________ > From: Wood L Dr (Electronic Eng) > Sent: 01 December 2010 07:56 > To: turners@ieca.com; lily.chen@nist.gov; alexey.melnikov@isode.com > Cc: Wood L Dr (Electronic Eng) > Subject: Last Call draft-turner-md5-seccon-update > > http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/?include_text=1 > > says > > The attacks on HMAC-MD5 do not seem to indicate a practical > vulnerability when used as a message authentication code. > > or, when used for error detection, which is not discussed. > > MD5 is still perfectly acceptable in non-security contexts, for detecting e.g. file corruption, as in checking that the .iso disk image downloaded is good to use. > > I've spent a lot of time in the IETF dealing with security types who believe that, because MD5 has flaws that affect security use, it should therefore not be used at all in any context -- although it's fine in a reliability-only context and very useful for detecting errors. (This topic has derailed protocol development, and has also been the subject of more than one IETF talk.) The document should imo indicate that MD5 remains acceptable in non-security contexts, and indicate clearly and verbosely that the document is limiting its scope to security applications only, not non-security applications. Security Fear, Uncertainty and Doubt should not be allowed to spill over into non-security contexts. > > I understand that this issue has been raised with the authors privately previously by others, but has not been addressed. > Lloyd, Thanks for you comments. I remember the original comment from Wes. My response (which may have been more terse) was to add in to the draft that familiarity with RFC 4270 (the reference to HASH-Attack in the last paragraph of Section 1 of the md-seccon-update draft) is assumed. RFC 4270 Section 3 says: Of the above methods [there are 7], only the first two [non-repudiable signatures and digital signatures in certificates] are affected by collision attacks, and even then, only in limited circumstances. Based on the "new" #s for collision attacks and what's in RFC 4270 that means to me that using MD5 for anything that requires collision resistance (2 of the 7 uses) is bad but if they're using it for the other 5 they're okay. Do you think that's too many dots for people to connect? I'm not in favor or repeating everything in RFC 4270 (i.e., I'd rather not be verbose). spt From mrex@sap.com Fri Dec 3 11:57:26 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B9B3A698E; Fri, 3 Dec 2010 11:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3HBvj-uxAGm; Fri, 3 Dec 2010 11:57:25 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2C1D23A697A; Fri, 3 Dec 2010 11:57:25 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oB3Jwf2q008557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Dec 2010 20:58:41 +0100 (MET) From: Martin Rex Message-Id: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> Subject: Re: [TLS] Last Call: To: gwz@net-zen.net (Glen Zorn) Date: Fri, 3 Dec 2010 20:58:40 +0100 (MET) In-Reply-To: <000401cb92a4$c1917ba0$44b472e0$@net> from "Glen Zorn" at Dec 3, 10 11:44:18 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal03 X-SAP: out Cc: tls@ietf.org, mike-list@pobox.com, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 19:57:26 -0000 Glen Zorn wrote: > > Martin Rex wrote: > > > > Glen Zorn wrote: > > > > > > Maybe I just don't understand the word "use". It seems like if a > > > server accepts a protocol message it's using the protocol... > > > > With "negotiate" I meant returning a ServerHello handshake message with > > that version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 > > ServerHello with a server version of { 0x02,0x00 }). > > > > With "use" I meant to successfully complete the handshake and start > > exchanging application data protected under protocol version > > {0x02,0x00}. > > Maybe you could spell these things out in the draft just as you have above? I'm sorry, my explanations were misleading. I explained what I meant when I wrote these statements that ended up in the document. http://www.ietf.org/mail-archive/web/tls/current/msg07091.html The author/editor of this I-D is Sean Turner. > > > The Server accepts the SSL 2.0 CLIENT-HELLO protocol data unit (PDU), > > but not the SSL 2.0 protocol. > > I see. Perhaps the distinction between PDU and "protocol" is just too > subtle for me, but assuming (maybe too generously ;-) that I'm not a total > moron, others might find it a little bit confusing as well. I do agree that the "specification" part is extremely brief. The best way to adjust this (as we are in IETF Last Call for this document) is to propose a specific replacement/update text. :) The distinction is not so much about the difference between "PDU" and "protocol", than it is about "active" and "passive" and the general IETF principle of "Be liberal in what you accept, and conservative in what you send". So we don't want servers to "actively" (=send out) SSL 2.0 protocol, but continue to be liberal in what they accept, e.g. "SSL 2.0 CLIENT-HELLO as the first message of an SSLv3 or TLS handshake". At least while there is _no_known_ security problem associated with this particular behaviour, because it improves interoperability with the installed base. -Martin From L.Wood@surrey.ac.uk Fri Dec 3 09:31:12 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A1428C17E; Fri, 3 Dec 2010 09:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt72EFB5VykG; Fri, 3 Dec 2010 09:31:11 -0800 (PST) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 42DE328C179; Fri, 3 Dec 2010 09:31:10 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-12.tower-78.messagelabs.com!1291397547!46912395!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 21980 invoked from network); 3 Dec 2010 17:32:27 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-12.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 3 Dec 2010 17:32:27 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Fri, 3 Dec 2010 17:32:26 +0000 From: To: Date: Fri, 3 Dec 2010 17:32:23 +0000 Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Topic: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Index: AcuTEAvlxdiAVoazRC6z+Y6mrgHCYg== Message-ID: <2E536B32-428C-4BC7-A784-9DA348979819@surrey.ac.uk> References: <4CF9131C.6090303@ieca.com> In-Reply-To: <4CF9131C.6090303@ieca.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 03 Dec 2010 12:17:00 -0800 Cc: wes@mti-systems.com, iesg@ietf.org, L.Wood@surrey.ac.uk, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 17:31:12 -0000 Sean, thanks for your reply. As you suggest, that is too many dots for people to connect. I also take issue with RFC4270's claim that: The Internet protocol community needs to migrate in an orderly manner away from SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms. which is rather broad, and entirely without the context and qualifiers we'r= e discussing. RFC4270 was not written for a general audience, but for a sec= urity audience. The Internet _security protocol_ community may well need to= migrate from these for certain uses (despite there not yet being obvious t= hings to move _to_), but RFC4270 and your draft's sum take-away message tha= t MD5BADDONOTUSE overstates the case.=20 I see that RFC4270 was published in November 2005, which predates (and poss= ibly even caused) the MD5-always-bad-don't-use-it-at-all-ever security kerf= luffles that Wes and I have run into by several years. The fact that MD5 is= being marked DEPRECATED by your draft, coupled by this sentence in RFC4270= , _will_ lead to security types using it as justification to remove MD5 fro= m, well, everywhere. Despite the fact that, as you say, it's still good for= five of seven uses, including integrity protection (which gets a mere sent= ence in 4270 as the last of the seven - it's imo an area that is often negl= ected in protocol design). I hope you can see how your 'good for five of se= ven' assessment doesn't match with the messages in DEPRECATED and the quote= above. We need some clear language setting the boundaries for areas of concern whe= re MD5 should not be used, and areas where it is still considered highly us= eful - language that is unambiguous to both security and non-security exper= ts. Repeating the bullet list of the seven uses, if you like, and providin= g a short summary of why MD5 is and is not currently considered useful in e= ach case. RFCs are not written solely for an audience competent in security matters, = and the security audience is not always as competent as it likes to believe= . Some explicit text to join the dots for the readers would be helpful. thanks, L. is not claiming any particular expertise in security. On 3 Dec 2010, at 15:56, Sean Turner wrote: > On 12/1/10 5:53 PM, L.Wood@surrey.ac.uk wrote: >> forwarding comments as per last call request. >>=20 >> Lloyd Wood >> http://tinyurl.com/lloydwood-ccsr >> ________________________________________ >> From: Wood L Dr (Electronic Eng) >> Sent: 01 December 2010 07:56 >> To: turners@ieca.com; lily.chen@nist.gov; alexey.melnikov@isode.com >> Cc: Wood L Dr (Electronic Eng) >> Subject: Last Call draft-turner-md5-seccon-update >>=20 >> http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/?include_= text=3D1 >>=20 >> says >>=20 >> The attacks on HMAC-MD5 do not seem to indicate a practical >> vulnerability when used as a message authentication code. >>=20 >> or, when used for error detection, which is not discussed. >>=20 >> MD5 is still perfectly acceptable in non-security contexts, for detectin= g e.g. file corruption, as in checking that the .iso disk image downloaded = is good to use. >>=20 >> I've spent a lot of time in the IETF dealing with security types who bel= ieve that, because MD5 has flaws that affect security use, it should theref= ore not be used at all in any context -- although it's fine in a reliabilit= y-only context and very useful for detecting errors. (This topic has derail= ed protocol development, and has also been the subject of more than one IET= F talk.) The document should imo indicate that MD5 remains acceptable in no= n-security contexts, and indicate clearly and verbosely that the document i= s limiting its scope to security applications only, not non-security applic= ations. Security Fear, Uncertainty and Doubt should not be allowed to spill= over into non-security contexts. >>=20 >> I understand that this issue has been raised with the authors privately = previously by others, but has not been addressed. >>=20 >=20 > Lloyd, >=20 > Thanks for you comments. I remember the original comment from Wes. My=20 > response (which may have been more terse) was to add in to the draft=20 > that familiarity with RFC 4270 (the reference to HASH-Attack in the last= =20 > paragraph of Section 1 of the md-seccon-update draft) is assumed. RFC=20 > 4270 Section 3 says: >=20 > Of the above methods [there are 7], only the first two > [non-repudiable signatures and digital signatures in > certificates] are affected by collision attacks, and > even then, only in limited circumstances. >=20 > Based on the "new" #s for collision attacks and what's in RFC 4270 that=20 > means to me that using MD5 for anything that requires collision=20 > resistance (2 of the 7 uses) is bad but if they're using it for the=20 > other 5 they're okay. >=20 > Do you think that's too many dots for people to connect? >=20 > I'm not in favor or repeating everything in RFC 4270 (i.e., I'd rather=20 > not be verbose). >=20 > spt Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From turners@ieca.com Fri Dec 3 12:32:40 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451C83A68B1 for ; Fri, 3 Dec 2010 12:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ydzMdNW0HwV for ; Fri, 3 Dec 2010 12:32:40 -0800 (PST) Received: from nm18-vm0.bullet.mail.ac4.yahoo.com (nm18-vm0.bullet.mail.ac4.yahoo.com [98.139.53.210]) by core3.amsl.com (Postfix) with SMTP id 02DD428C136 for ; Fri, 3 Dec 2010 12:32:39 -0800 (PST) Received: from [98.139.52.192] by nm18.bullet.mail.ac4.yahoo.com with NNFMP; 03 Dec 2010 20:33:55 -0000 Received: from [98.139.52.165] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 03 Dec 2010 20:33:55 -0000 Received: from [127.0.0.1] by omp1048.mail.ac4.yahoo.com with NNFMP; 03 Dec 2010 20:33:55 -0000 X-Yahoo-Newman-Id: 374522.52500.bm@omp1048.mail.ac4.yahoo.com Received: (qmail 9206 invoked from network); 3 Dec 2010 20:27:15 -0000 Received: from thunderfish.local (turners@71.191.10.69 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 03 Dec 2010 12:27:15 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 4PA1aIUVM1lHreLUOlU23rQr2tKjd.YYCszI69xxiofUBHB Ni4tmmsdAy0DnpRxrY0XMpuDTHCL2uF..G23t8evW3JhPsDPtlzgxDgyvSRs SAL9LvqDYPvI2c0.QKzLcDiRXcvJFVnFy_A7OO0CTNjqNFvkSTn8kfsdxDQl XPPrC3dCEWwIRx.0QJYI6.bPMTusR.YNmSLGjeeacjRNWYkaOktahR_95gts 3WtYrfLwqGz038vNbQDkvJGhRJo4_Va.qshrQQgi2TC2dOr.dZCAfZ7yWnRc cKSrBQntmcVBEi4tZze32kXGJnX7fveb9207aortvPYe1gv04rMpXB7bRlMH 94Us9G.ynKRK4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CF952A2.2070904@ieca.com> Date: Fri, 03 Dec 2010 15:27:14 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: mrex@sap.com, Glen Zorn Subject: Re: [TLS] Last Call: References: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> In-Reply-To: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 20:32:40 -0000 On 12/3/10 2:58 PM, Martin Rex wrote: > Glen Zorn wrote: >> >> Martin Rex wrote: >>> >>> Glen Zorn wrote: >>>> >>>> Maybe I just don't understand the word "use". It seems like if a >>>> server accepts a protocol message it's using the protocol... >>> >>> With "negotiate" I meant returning a ServerHello handshake message with >>> that version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 >>> ServerHello with a server version of { 0x02,0x00 }). >>> >>> With "use" I meant to successfully complete the handshake and start >>> exchanging application data protected under protocol version >>> {0x02,0x00}. >> >> Maybe you could spell these things out in the draft just as you have above? > > I'm sorry, my explanations were misleading. I explained what I meant > when I wrote these statements that ended up in the document. > > http://www.ietf.org/mail-archive/web/tls/current/msg07091.html > > The author/editor of this I-D is Sean Turner. I've got no problem with providing additional clarifying text. How about we add the following (some minor tweaks to what you suggested) to explain what we mean by use and negotiate (send seems clear): "negotiate" means returning a ServerHello handshake message with that version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 ServerHello with a server version of { 0x02,0x00 }). "use" means to successfully complete the handshake and start exchanging application data protected under protocol version {0x02,0x00}. spt From hartmans@mit.edu Fri Dec 3 13:06:59 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8423C28C166; Fri, 3 Dec 2010 13:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.659 X-Spam-Level: X-Spam-Status: No, score=-102.659 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de6seIGEOw97; Fri, 3 Dec 2010 13:06:58 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id AD18928C15F; Fri, 3 Dec 2010 13:06:58 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 399922016A; Fri, 3 Dec 2010 16:07:27 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5B24E511D; Fri, 3 Dec 2010 16:07:58 -0500 (EST) From: Sam Hartman To: , wes@mti-systems.com, iesg@ietf.org, ietf@ietf.org Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC References: <4CF9131C.6090303@ieca.com> <2E536B32-428C-4BC7-A784-9DA348979819@surrey.ac.uk> Date: Fri, 03 Dec 2010 16:07:58 -0500 In-Reply-To: <2E536B32-428C-4BC7-A784-9DA348979819@surrey.ac.uk> (L. Wood's message of "Fri, 3 Dec 2010 17:32:23 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 21:06:59 -0000 So, I'm sympathetic to the idea that we in the security community can be overly paranoid. however I'm more sympathetic to the idea that it's hard to figure out what uses are security sensitive and what uses are not. At least in the case of md5, where backward compatibility concerns don't dictate otherwise, I'd say that moving away is better than not. Let me take a specific example from earlier in this discussion. The claim was made that using md5 to verify the checksum of ISOs downloaded off the Internet is still good. That depends entirely on what you're trying to protect against. If your concern is simply errors in the download and concerns that the TCP checksum may be inadequate, then I agree. However it's also fairly common to have md5 checksums on an initial page and then direct people to mirrors for the actual ISO. There, you're also protecting against substitution attacks mounted between the original page and the iso. If md5 is used in exactly the same context as the data, I agree it is still fine. However, the moment you separate the checksum from the data--by putting one in e-mail, one on a post-it note, one on a different mirror, you have made the hash security sensitive. For this specific use, I think the extra length of SHA-1 is worth it, and I think it is reasonable for us to recommend that something stronger than MD5 is appropriate. (SHA-2 would be better, although the length of SHA-2 starts to get prohibitive.) It's very easy for the security of a hash function to become important. I at least find it difficult to easily determine whether a particular use of a hash is security sensitive. I find that I disagree with the results from people who claim that this analysis is easy often enough that I'm reluctant to conclude that I'm simply unusually slow at thinking through these sorts of issues. So, I suggest that the problem of deciding whether the security of a hash is important may be a bit tricky. While we should not spread panic and we should be sensitive to these issues, I also would rather us err on the side of security in our recommendation. From mrex@sap.com Fri Dec 3 13:39:54 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385D028C0E2; Fri, 3 Dec 2010 13:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quxvSazSC7hJ; Fri, 3 Dec 2010 13:39:50 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id A770E28C0FD; Fri, 3 Dec 2010 13:39:48 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oB3Lf1fd023641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Dec 2010 22:41:02 +0100 (MET) From: Martin Rex Message-Id: <201012032140.oB3Lex75021511@fs4113.wdf.sap.corp> Subject: Re: Last Call: (Updated To: L.Wood@surrey.ac.uk Date: Fri, 3 Dec 2010 22:40:59 +0100 (MET) In-Reply-To: <2E536B32-428C-4BC7-A784-9DA348979819@surrey.ac.uk> from "L.Wood@surrey.ac.uk" at Dec 3, 10 05:32:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: wes@mti-systems.com, iesg@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 21:39:54 -0000 L.Wood@surrey.ac.uk wrote: > > I also take issue with RFC4270's claim that: > > The Internet protocol community needs to > migrate in an orderly manner away from SHA-1 and MD5 -- especially > MD5 -- and toward more secure hash algorithms. > > which is rather broad, and entirely without the context and qualifiers > we're discussing. RFC4270 was not written for a general audience, > but for a security audience. The Internet _security protocol_ community > may well need to migrate from these for certain uses (despite there not > yet being obvious things to move _to_), but RFC4270 and your draft's > sum take-away message that MD5BADDONOTUSE overstates the case. I agree that the above wording of rfc-4270 is BAD. It should have said: The Internet community needs to migrate in an orderly manner away from SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms for all security-related usages of hash functions in all protocols. > > Despite the fact that, as you say, it's still good for five of seven uses, > including integrity protection (which gets a mere sentence in 4270 as the > last of the seven - it's imo an area that is often neglected in protocol > design). IMHO there is a serious defect in rfc-4270. The "integrity protection" bullet ought to be bullet three, and MD5 is definitely _NOT_ suitable for anything with the term "integrity" in it. Integrity protection is terminology that is used in the security&cryptographic area and this defect of rfc-4270 is going to create misunderstandings. MD5 (and SHA-1) are hash functions, and as such, they exhibit probabilistic collisions for different inputs. MD5 is still useful for detection of "accidental" errors due to noise or distortion, but it is not suited to protect against intentional modification of data by an attacker. There are other algorithms for detecting "accidental" errors, like "ECC bits", or CRCs of various sizes, e.g. http://en.wikipedia.org/wiki/Cyclic_redundancy_check Think of MD5 as an alternative to CRC128. -Martin From mrex@sap.com Fri Dec 3 19:22:12 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58763A6822; Fri, 3 Dec 2010 19:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sAbfR5eJFRJ; Fri, 3 Dec 2010 19:22:10 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 810933A681D; Fri, 3 Dec 2010 19:22:09 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oB43NPFc021548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Dec 2010 04:23:26 +0100 (MET) From: Martin Rex Message-Id: <201012040323.oB43NNj1010786@fs4113.wdf.sap.corp> Subject: Re: Last Call: (Updated To: L.Wood@surrey.ac.uk Date: Sat, 4 Dec 2010 04:23:23 +0100 (MET) In-Reply-To: <4FE8ED0D-70E2-41F9-A9F4-80FFE1FA870F@surrey.ac.uk> from "L.Wood@surrey.ac.uk" at Dec 3, 10 10:59:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: wes@mti-systems.com, iesg@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 03:22:13 -0000 L.Wood@surrey.ac.uk wrote: > > > and MD5 is definitely _NOT_ suitable > > for anything with the term "integrity" in it. > > That depends imo on whether "integrity" is used as a term in a security > context by a security person, or by anyone else. (I am not using the > term as a security person, but have been forced to use it when talking to > security people who have little notion of protection against errors or of > reliability.) > > > > Integrity protection is terminology that is used in the > > security&cryptographic area and this defect of rfc-4270 is going > > to create misunderstandings. > > Yes. > > We've actually run into this problem previously, and had to carefully use the > terms when talking to those who focus on terminology used, rather than the > overall point that is trying to be made. This leads to verbal gyrations > and a degree of doubletalk. > > 'Integrity' and 'protection' do have meanings outside security, and were used > long before their specific use in a security context (cf database integrity, > system integrity, even integrity protection in chemical plants). From context > here and the rest of the sentence, it's imo clear that reliability is what > is being referred to. I've been focused so much on security over more than a decade that myself I am actually unfamiliar with uses of "integrity protection" in a sense that is _not_ security-related. Although the attacks against MD5 published so far are practical only for creating collision pairs, there has not been published a practical preimage attack against MD5. But the practical collision attack alone is devastating for several integrity protection usage scenarios. see this here: http://www.win.tue.nl/hashclash/rogue-ca/ Open the "Certificate Manager" of a newer Firefox/Mozilla browser (Menu: Tools->Options, Section "Advanced", Tab "Encryption", Button "View Certificates", Tab "Authorities") Under "Equifax Secure Inc." you will probably find a CA certificate labelled "MD5 Collisions Inc. (http://www.phreedom.org/md5)" signed by Equifax Secure Global eBusiness CA-1, expired in Sep-2004 and that cert is pre-configured to be _not_ trusted for any purpose. (a somewhat non-obvious way of blacklisting a certificate). The MD5-based RSA signature in that cert still contains the original MD5 checksum that Equifax calculated when it issued a different (but fairly similar) end-entity cert with a different validity. This fake CA certificate was created with the help of the MD5 collision attack, not by a preimage attack. But if you look at the purpose / usage scenario of the MD5 hash here, then it is about some SSL client ("Bob") receiving an assertion of identity for a server "i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org" integrity protected by an RSA-encrypted MD5 hash from Equifax ("Alice"), which can be successfully substitued by an attacker ("mallory") with an intermediate CA certificate (plus an end-entity cert for any arbitrary server created at will by mallory), and the Equifax-signed MD5 checksum does not protect against this substitution, because the fake CA cert has the exact same MD5 checksum as the cert originally issued by Equifax. The details are described in section 5.3 (but only 5.2 has an anchor tag): http://www.win.tue.nl/hashclash/rogue-ca/#sec52 Admittedly it isn't trivial to use a collision attack to do achieve something that normally requires a preimage attack, but it is going to be possible much more often than you will want it to for a creative attacker. And a lot of PDUs that are digitally signed these days provide wiggle room for "binary random stuffing" necessary to precompute collision attacks and will be ignored by recipients. Especially in protocols using ASN.1. According to this report: http://www.eff.org/files/DefconSSLiverse.pdf there appear to exist almost 1500 "trustworthy" SSL CAs, and and attacker only needs to find a single one among them where such an attack still works... -Martin From ron.even.tlv@gmail.com Sat Dec 4 07:42:16 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CE628C0E1; Sat, 4 Dec 2010 07:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPWvbn-HBdoz; Sat, 4 Dec 2010 07:42:15 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 55F1828C0DD; Sat, 4 Dec 2010 07:42:15 -0800 (PST) Received: by wwa36 with SMTP id 36so11063541wwa.13 for ; Sat, 04 Dec 2010 07:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=h3Su8TpeB4eIyDmJxXk3trtTTja36EW+9gm5Vw1rN0k=; b=e/p0541m3S4B6OlmCCjR8WOl0611B9VcYdXHXlEMDfLUv+82r157ZJHFVkLG99atpu PLj5DIoQOYq0jh6uLJ370bVXbuekomDJoJujbBCg7WHJX52umD8QbrqQsPyXB7mPi65T K5Wae64Kp42A8rrJNGuh/mIHAUPk3RJGJmPF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; b=TBAPPIg9TUBCFbuYpeF4Un5u6TjB4RVIwadhAWCimrLsYz+IngvR67qUrA3a/f6ZXW fgqGTRPBXIyBR3bS6KECkRcAnsUp6WsnkmjO6yfEVVAXr372oEamaDMJ2gypHCK7AUg0 SH2X2DoT/sOE6EPvA7OdcTWUgekcpnH8MOtC0= Received: by 10.216.142.131 with SMTP id i3mr615799wej.5.1291477414450; Sat, 04 Dec 2010 07:43:34 -0800 (PST) Received: from windows8d787f9 (bzq-79-179-19-14.red.bezeqint.net [79.179.19.14]) by mx.google.com with ESMTPS id w84sm1451300weq.20.2010.12.04.07.43.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 04 Dec 2010 07:43:32 -0800 (PST) From: "Roni Even" To: "'General Area Review Team'" , Subject: Gen-ART IETF LC review of draft-ietf-ecrit-lost-servicelistboundary Date: Sat, 4 Dec 2010 17:41:32 +0200 Message-ID: <4cfa61a4.eaecd80a.64b7.ffff8243@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013E_01CB93DA.88E51820" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuTybiC/+hqNiudRUOFZK+8ttfUZg== Content-language: en-us Cc: 'IETF-Discussion list' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 15:42:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_013E_01CB93DA.88E51820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ecrit-lost-servicelistboundary-04 Reviewer: Roni Even Review Date: 2010-12-04 IETF LC End Date: 2010-12-14 IESG Telechat date: (if known) Summary: This draft is ready for publication as an Experimental RFC. There are some nits Major issues: Minor issues: Nits/editorial comments: 1. In the abstract the document starts with LoST, Please expand to Location-to-Service Translation 2. At the end of section 3.2 in the note, I think that the first "getServiceListBoundary" should be " getServiceBoundary" Roni Even ------=_NextPart_000_013E_01CB93DA.88E51820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am the = assigned Gen-ART reviewer for this draft. For background on Gen-ART, = please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq= >.

 

Please resolve these comments along with any other = Last Call comments you may receive.

 

Document: draft-ietf-ecrit-lost-servicelistboundar= y-04

Reviewer: Roni = Even

Review = Date: 2010-12-04

IETF LC End = Date: 2010-12-14

IESG Telechat = date: (if known)

 

Summary: = This draft is ready for publication as an Experimental RFC. There are = some nits

 

Major issues:

 

Minor = issues:

 

Nits/editorial comments:

1.      = In the abstract the = document starts with LoST,  Please expand to Location-to-Service = Translation

2.      = At the end of = section 3.2  in the note, I think that the first = "getServiceListBoundary" should be " = getServiceBoundary"

 

 

 

Roni = Even

------=_NextPart_000_013E_01CB93DA.88E51820-- From mnot@mnot.net Sun Dec 5 21:12:17 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11EDB3A69D4; Sun, 5 Dec 2010 21:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.678 X-Spam-Level: X-Spam-Status: No, score=-104.678 tagged_above=-999 required=5 tests=[AWL=-2.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1O8REzja9fX; Sun, 5 Dec 2010 21:12:16 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id DC1043A69D1; Sun, 5 Dec 2010 21:12:15 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4C0B722E1EB; Mon, 6 Dec 2010 00:13:32 -0500 (EST) Subject: Re: [http-state] Last Call: (HTTP State Management Mechanism) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <20101118193017.8754.963.idtracker@localhost> Date: Mon, 6 Dec 2010 16:13:29 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101118193017.8754.963.idtracker@localhost> To: The IETF X-Mailer: Apple Mail (2.1082) Cc: http-state@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 05:12:17 -0000 Apologies for the late reply. FWIW, I support publication; this is a very well-written spec, and a = long overdue revision. One small suggestion: it may be worthwhile to point out that the = presence of a Cookie request header or Set-Cookie response header does = not preclude HTTP caches from storing and reusing a response. Regards, On 19/11/2010, at 6:30 AM, The IESG wrote: >=20 > The IESG has received a request from the HTTP State Management = Mechanism > WG (httpstate) to consider the following document: > - 'HTTP State Management Mechanism' > as a Proposed Standard >=20 > 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 2010-12-02. 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. >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > http-state mailing list > http-state@ietf.org > https://www.ietf.org/mailman/listinfo/http-state -- Mark Nottingham http://www.mnot.net/ From ietf@adambarth.com Sun Dec 5 21:38:53 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80A628C0E9; Sun, 5 Dec 2010 21:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.003 X-Spam-Level: X-Spam-Status: No, score=-4.003 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c0KSp+4JIZT; Sun, 5 Dec 2010 21:38:13 -0800 (PST) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id DD3583A69DD; Sun, 5 Dec 2010 21:37:55 -0800 (PST) Received: by gxk8 with SMTP id 8so33133632gxk.27 for ; Sun, 05 Dec 2010 21:39:08 -0800 (PST) Received: by 10.150.227.7 with SMTP id z7mr8526017ybg.330.1291613947799; Sun, 05 Dec 2010 21:39:07 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id r18sm3057289yba.3.2010.12.05.21.39.06 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Dec 2010 21:39:06 -0800 (PST) Received: by iwn40 with SMTP id 40so14977747iwn.31 for ; Sun, 05 Dec 2010 21:39:06 -0800 (PST) Received: by 10.231.160.78 with SMTP id m14mr5359027ibx.128.1291613946044; Sun, 05 Dec 2010 21:39:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.12.77 with HTTP; Sun, 5 Dec 2010 21:38:35 -0800 (PST) In-Reply-To: References: <20101118193017.8754.963.idtracker@localhost> From: Adam Barth Date: Sun, 5 Dec 2010 21:38:35 -0800 Message-ID: Subject: Re: [http-state] Last Call: (HTTP State Management Mechanism) to Proposed Standard To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: The IETF , http-state@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 05:38:54 -0000 On Sun, Dec 5, 2010 at 9:13 PM, Mark Nottingham wrote: > FWIW, I support publication; this is a very well-written spec, and a long= overdue revision. Thanks. > One small suggestion: it may be worthwhile to point out that the presence= of a Cookie request header or Set-Cookie response header does not preclude= HTTP caches from storing and reusing a response. I've added a sentence to this effect to the overview. Adam > On 19/11/2010, at 6:30 AM, The IESG wrote: >> The IESG has received a request from the HTTP State Management Mechanism >> WG (httpstate) to consider the following document: >> - 'HTTP State Management Mechanism' >> =A0 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 2010-12-02. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> http-state mailing list >> http-state@ietf.org >> https://www.ietf.org/mailman/listinfo/http-state > > -- > Mark Nottingham =A0 http://www.mnot.net/ > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From ben@nostrum.com Fri Dec 3 13:23:40 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CBD28C0FD; Fri, 3 Dec 2010 13:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76ZCMkQrXWwQ; Fri, 3 Dec 2010 13:23:39 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C8FDF28C127; Fri, 3 Dec 2010 13:23:38 -0800 (PST) Received: from dn3-174.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB3LOsvq069402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Dec 2010 15:24:55 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Gen-ART LC Review of draft-saintandre-tls-server-id-check-11 Date: Fri, 3 Dec 2010 15:24:54 -0600 Message-Id: <92AA0A47-B3EE-4931-9203-92DB67946F3A@nostrum.com> To: draft-saintandre-tls-server-id-check.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Mon, 06 Dec 2010 07:31:30 -0800 Cc: General Area Review Team , The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 21:23:40 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-saintandre-tls-server-id-check-11 Reviewer: Ben Campbell Review Date: 2010-12-03 IETF LC End Date: 2010-12-16 Summary: This draft is almost ready for publication as a BCP. I have a = few questions and comments that I think should be considered first, as = well as a few editorial comments. *** Major issues: -- [ Not so much a "major issue" as a "slightly less minor" one] I'd = like to see more discussion around URI-IDs. These seem to me to be the = most complex ID type to get right, but there are no examples and limited = discussion. Picking on SIP, purely as an example for which I have a = passing familiarity: Would a SIP reference identity match a SIPS URI-ID = in a certificate? Do I put both a URI-ID and an SRV-ID in my reference = set and/or certificate? How do I handle the fact that I sometimes need = to do a NAPTR query, before the SRV query depending on whether I know = the transport protocol? (I realize SIP already defines cert ID matching, = but what would I do for a new application protocol URI with similar = properties?) I wonder if the answer is that such things are scheme specific, and that = its hard to say much about the generic handling of URI-IDs. If so, it = might be worth mentioning that, and maybe discuss what things the = designer of a new scheme should keep in mind. *** Minor issues: -- 1.2, last paragraph: Nothing normative here? Do we think that protocol designers SHOULD = reference document instead of rolling their own? For example, would you = expect additional IESG or SECDIR scrutiny for a new spec that rolls its = own rather than referenda this? As stated, this paragraph makes it sound = like this is something designers could use, rather than something = designers should use. It seems like a BCP might take a stronger = position. -- 1.4.2, 2nd bullet item: "We also do not address identifiers derived = from Naming Authority Pointer (NAPTR) DNS resource records [NAPTR] and = related technologies such as [S-NAPTR], since such identifiers cannot be = validated in a trusted manner in the absence of [DNSSEC]." Does that mean validation of a source domain that will be used to = construct a NAPTR request is out of scope, or just validation against = the result of a NAPTR query? (I note SIP may require the first). -- 2.3, paragraph 1: A DN example might be helpful. -- 2.3, paragraph 3: "application service is identified by a name or = names carried in the subject field and/or in one of the following = identifier types" May be identified, right? Since, as you mentioned earlier, it is common = to identify a service with a name plus service designator, and only the = SRV-ID and URI-ID intrinsically do this. -- 3.1, rule 3: What happens when you have multiple schemes that are defined to refer to = the same resource. For example, SIP and SIPS? Does a SIP URI-ID match = an otherwise identical SIPS URI-ID? (Maybe this should be left to the = URI definitions themselves, but it might be worth mentioning the = complication somewhere.) -- 3.1, rule 5: "... unless a profile of this specification... " This pattern recurs throughout the document. Can you elaborate on what = you mean by "profile"? Normally I think of a "profile" as defining a = subset of choices for some particular application. But if a profile = relaxes a requirement (i.e. encouraging something that is a SHOULD NOT = here), that's not really a subset. Are you referring to an application = protocol spec that refers to this document? Updates to this document? = (I'm not sure if this should count as a minor issue or an editorial = comment. It depends on whether its just a confusion around the word = choice, or whether you have something specific in mind that I did not = grok). -- 3.1, rule 6: Can you motivate why this is not a MUST NOT? -- section 3.2: I'd like to see a (non-trivial) URL-ID example. -- 3.2, first example: Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it in = examples? The example does seem to make sense, but it makes me wonder if = the SHOULD NOT would be better placed on the client verification process = not the cert generation process. --4.2.1, paragraph 3: It's probably out of scope, but it might be useful to offer some = guidance on how ensuring the extraction is "not subject to subversion" = is not always trivial. For example, if you got your input URI by = clicking on a link in a phishing email, that can be almost isomorphic to = using a delegation from a non-trusted source. -- 4.2.2: Can we have a URI-ID example? (and maybe an explanation why the HTTP = example doesn't use one?) -- 4.3, 4th bullet item: An example would be helpful here. -- 4.4, rule 1: Why not MUST NOT? -- 5.1: Should this doc mention anything about the ability to unpin? *** Nits/editorial comments: -- 1.1, paragraph 1: "...visible face of the Internet consists of = services that employ a client-server architecture..." This seems a little overstated. Client-server applications are certainly = common, but they don't represent all common uses of the Internet. (Or do = I misinterpret what you mean by "visible face"?) "references some conception... of... identity" I'm not sure what that means. Can you state this more plainly? Maybe = "concept of identity" or "idea of identity"? (I realize "conception" can = mean "concept", but it sounds strained to my mental ear.)=20 -- 1.2, Paragraph 1: "document does not supersede the rules for = certificate issuance or validation provided in [PKIX]" If this document does not supercede PKIX, then that also means that PKIX = is authoritative on any point for which is draft may be in conflict with = it, right? "Specifically, in order to ensure proper authentication, application = clients need to verify the entire certification path, because this = document addresses only name forms in the leaf server certificate, not = any name forms in the chain of certificates used to validate the server = certificate." Sentence hard to parse. Can it be broken up or simplified? -- 1.2, Paragraph 2: "existing application protocols" Probably worth tying that to a point in time, as in "application = protocols that were specified prior to the publication of this BCP" -- 1.5, first paragraph: "each entry is preceded by a dollar sign ($) = and a space." I don't see any $'s=20 -- 1.5, definition of "delegated domain": "connecting to the source = domain" Is connecting to really the term you want here? Maybe "associated with"? = In the context of this draft, I'm afraid people will think of connection = in terms of tcp connections, etc. -- 1.5, definition of "subject name" Is there a definition or reference for "composite name"? -- 1.6: I don't know if it matters, but I usually see contributors and = acknowledgments sections near the end. It seems sort of abrupt to find = them imbedded between technical content sections. -- 3.1, 1st paragraph: It's probably worth emphasizing that the rules are often cumulative. I = think someone thinking about these for the first time might not grasp = that until they see examples later in the doc. -- 4.3, implementation note: "although such behavior is not forbidden by = this document" The "SHOULD stop the search" language in previous paragraph implies that = you SHOULD NOT do this, doesn't it? So while it's not strictly = forbidden, it's strongly discouraged. The implementation note makes it = sound more like it is merely out of scope. -- 4.3, 4th bullet item does the ABNF or URI reference define "reg-name" as well as "scheme"? = That seems ambiguous. If not, then it might be helpful to have an = expansion, definition, or reference for "reg-name". -- 4.4: "Furthermore, if the client supports presented identifiers that = contain the wildcard character =92*=92, we define a supplemental rule = for so-called "wildcard certificates". I think the definition will stay there regardless of the intent of the = client :-) Perhaps something to the effect of "... We define a = supplemental rule...which may be used by clients that support = wildcards." From L.Wood@surrey.ac.uk Fri Dec 3 14:58:04 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98653A69C3; Fri, 3 Dec 2010 14:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DLkW1Dm7ujs; Fri, 3 Dec 2010 14:58:03 -0800 (PST) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 5454B3A69B8; Fri, 3 Dec 2010 14:58:03 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-3.tower-72.messagelabs.com!1291417161!28987127!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 3384 invoked from network); 3 Dec 2010 22:59:21 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-3.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 3 Dec 2010 22:59:21 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 3 Dec 2010 22:59:20 +0000 From: To: Date: Fri, 3 Dec 2010 22:59:19 +0000 Subject: Re: Last Call: (Updated Thread-Topic: Last Call: (Updated Thread-Index: AcuTPbfkBsDf+h/RQsycP5kvyeVI2g== Message-ID: <4FE8ED0D-70E2-41F9-A9F4-80FFE1FA870F@surrey.ac.uk> References: <201012032140.oB3Lex75021511@fs4113.wdf.sap.corp> In-Reply-To: <201012032140.oB3Lex75021511@fs4113.wdf.sap.corp> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 06 Dec 2010 07:31:30 -0800 Cc: wes@mti-systems.com, iesg@ietf.org, L.Wood@surrey.ac.uk, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 22:58:05 -0000 On 3 Dec 2010, at 21:40, Martin Rex wrote: > L.Wood@surrey.ac.uk wrote: >>=20 >> I also take issue with RFC4270's claim that: >>=20 >> The Internet protocol community needs to >> migrate in an orderly manner away from SHA-1 and MD5 -- especially >> MD5 -- and toward more secure hash algorithms. >>=20 >> which is rather broad, and entirely without the context and qualifiers >> we're discussing. RFC4270 was not written for a general audience, >> but for a security audience. The Internet _security protocol_ community >> may well need to migrate from these for certain uses (despite there not >> yet being obvious things to move _to_), but RFC4270 and your draft's >> sum take-away message that MD5BADDONOTUSE overstates the case.=20 >=20 > I agree that the above wording of rfc-4270 is BAD. >=20 > It should have said: >=20 > The Internet community needs to migrate in an orderly manner away from > SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithm= s > for all security-related usages of hash functions in all protocols. That wording is better, though I would also add a qualifier on the front by saying 'away from reliance for security purposes on SHA-1 and MD-5...'. This should imo be filed as an erratum on RFC4270. >> Despite the fact that, as you say, it's still good for five of seven use= s, >> including integrity protection (which gets a mere sentence in 4270 as th= e >> last of the seven - it's imo an area that is often neglected in protocol >> design). >=20 > IMHO there is a serious defect in rfc-4270. The "integrity protection" > bullet ought to be bullet three, The list isn't explicitly ranked. But putting the reliability point last does say something interesting about the security mindset... if it's not a deliberate attack, it's just not interesting or worthy of note. > and MD5 is definitely _NOT_ suitable > for anything with the term "integrity" in it. That depends imo on whether "integrity" is used as a term in a security context by a security person, or by anyone else. (I am not using the term as a security person, but have been forced to use it when talking to security people who have little notion of protection against errors or of reliability.) > Integrity protection is terminology that is used in the > security&cryptographic area and this defect of rfc-4270 is going > to create misunderstandings. Yes. We've actually run into this problem previously, and had to carefully use t= he terms when talking to those who focus on terminology used, rather than the overall point that is trying to be made. This leads to verbal gyrations and a degree of doubletalk. 'Integrity' and 'protection' do have meanings outside security, and were us= ed long before their specific use in a security context (cf database integrity= , system integrity, even integrity protection in chemical plants). From conte= xt here and the rest of the sentence, it's imo clear that reliability is what is being referred to. I don't think this is necessarily a second erratum, but then I'm not a security type, and think that this is an example of why mathematicians often invent new terms, rather than overloading old ones. > MD5 (and SHA-1) are hash functions, and as such, they exhibit probabilist= ic > collisions for different inputs. MD5 is still useful for detection of > "accidental" errors due to noise or distortion, or segmentation/reassembly overwriting bugs or... it can be used to support= the the end-to-end-principle. > but it is not suited > to protect against intentional modification of data by an attacker. agreed. > There are other algorithms for detecting "accidental" errors, like > "ECC bits", or CRCs of various sizes, e.g. > http://en.wikipedia.org/wiki/Cyclic_redundancy_check >=20 > Think of MD5 as an alternative to CRC128. Well, MD5 is not a cyclic code, and CRC128 wouldn't cope well with checking across anywhere near the sizes that MD5 can support; 128-bit MD5 has been compared in error-detection strength (nb not crypto strength!) to CRC2= 048++, which would be a rather complex polynomial. But I'm not so much of a purist= that I would stall at nitpicking your terminology here. Instead, I agree that th= e overall point that you're making here is expressing exactly the point about= MD5 that I've been trying to make, in relatively simple language for laymen. To come back to where we came in, MD5 is fine for detecting errors in a non-security context - but readers of RFC4270 and draft-turner-md5-seccon= -update are not going to pick that up from a casual read, and will come away with 'MD5 bad, do not use' (and what's the alternative?). draft-turner-md5-seccon-update needs to be much, much clearer on this and i= n setting scope for use of MD5. regards, L. >=20 >=20 >=20 > -Martin Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From L.Wood@surrey.ac.uk Sat Dec 4 03:42:13 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74A43A68BA; Sat, 4 Dec 2010 03:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S77Nyealus9R; Sat, 4 Dec 2010 03:42:12 -0800 (PST) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 42DB03A6AAB; Sat, 4 Dec 2010 03:42:10 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-78.messagelabs.com!1291463009!22152019!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 4852 invoked from network); 4 Dec 2010 11:43:29 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-7.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 4 Dec 2010 11:43:29 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Sat, 4 Dec 2010 11:43:29 +0000 From: To: Date: Sat, 4 Dec 2010 11:43:27 +0000 Subject: Re: Last Call: (Updated Thread-Topic: Last Call: (Updated Thread-Index: AcuTqHeBtHSjQwDBSC6qaqg4P1imoQ== Message-ID: References: <201012040323.oB43NNj1010786@fs4113.wdf.sap.corp> In-Reply-To: <201012040323.oB43NNj1010786@fs4113.wdf.sap.corp> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 06 Dec 2010 07:31:30 -0800 Cc: wes@mti-systems.com, iesg@ietf.org, L.Wood@surrey.ac.uk, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 11:42:13 -0000 On 4 Dec 2010, at 03:23, Martin Rex wrote: > Although the attacks against MD5 published so far are practical only > for creating collision pairs, there has not been published a practical > preimage attack against MD5. But the practical collision attack alone > is devastating for several integrity protection usage scenarios. I am wondering how the authors of RFC4270 wound up misusing the 'integrity protection' term to cover both intentional (attack) and unintentional=20 modifications, whereas reliability checking covers only the latter. But, to the security mindset, everything is an attack. I've now filed two errata on RFC4270. regards, L. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From McQuilWP@pobox.com Mon Dec 6 16:05:59 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5D63A68D7 for ; Mon, 6 Dec 2010 16:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20QInGnV5ago for ; Mon, 6 Dec 2010 16:05:58 -0800 (PST) Received: from sasl.smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by core3.amsl.com (Postfix) with ESMTP id 4F2DC3A68D5 for ; Mon, 6 Dec 2010 16:05:58 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 125B08A12; Mon, 6 Dec 2010 19:07:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:mime-version:content-type :content-transfer-encoding; s=sasl; bh=fs15RmuDucgeNej1TcXdCtmDi cE=; b=UR8DOmmui4WXm6I4M4CMswHk56xorptzRqbnp7v0spo3kO6pm1ST53rui wG9SulaCLMz5GSkAdbsybKtPwqg+N/LN9lyF8QVeMM9yYhAFHJD/cHUUXA7OOSTp nn4+chkzir4xqZ7pC1fxFzaS/4Eo//YNWvDgUUzt7ORgZJ770U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=sasl; b=lR4uJjAEsPhYPLS/1In grLc33FYJAoEfIP0HO7QTVqdbVB6DspnlzsXJFpkEmXzo3SDs5H1neG8UozZcgFR 9RKXxeXa3m/SL8JfyfS3QmH+ANdqG9fzz2XdhYJw4xnue6eLyntrOiOr9/qj0T2M DqO+M4/9ebPHI0/fAYf1s5M8= Received: from b-pb-sasl-quonix. (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id F34F38A10; Mon, 6 Dec 2010 19:07:19 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 827C48A0F; Mon, 6 Dec 2010 19:07:18 -0500 (EST) Date: Mon, 6 Dec 2010 16:07:17 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <113441059.20101206160717@pobox.com> To: IETF Discussion Subject: Re: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: F5608506-0195-11E0-93EB-8FD6ABFCE9A3-02871704!b-pb-sasl-quonix.pobox.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 00:05:59 -0000 I found several problems with this draft. In overview, the reason that we removed the #rule from ABNF was that it was very difficult to specify for a general case. This draft has the same problem. The production given does not actually produce the desired results. > n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element)) If the usage is: 5^(",")10 "abc" it would allow something like: abc abc abc abc abc abc , abc not: abc, abc, abc, abc, abc, abc, abd which was probably intended. ----- The production: > a = VCHAR / SP / HT / does not seem to address the possibility of multi-character separators very clearly. What if I want to define a list like: abc and def and ghi and jkl can I use: ^(" and ")ident ----- I also do not believe that *FWS belongs in such a general rule and should rather be defined by the actual usage. E.g.: 5^(*FWS "," *FWS)10 "abc" ----- Typo: 2.1 Examples, fourth example should be: ^("-")element -- Bill McQuillan From Martin.Thomson@andrew.com Mon Dec 6 16:45:56 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0001328C0DB for ; Mon, 6 Dec 2010 16:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEPs9cwCUT9W for ; Mon, 6 Dec 2010 16:45:55 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 1133E3A68DD for ; Mon, 6 Dec 2010 16:45:55 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:47443 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S517232Ab0LGArT (ORCPT ); Mon, 6 Dec 2010 18:47:19 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 6 Dec 2010 18:47:18 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 7 Dec 2010 08:47:17 +0800 From: "Thomson, Martin" To: Bill McQuillan , IETF Discussion Date: Tue, 7 Dec 2010 08:47:14 +0800 Subject: RE: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt Thread-Topic: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt Thread-Index: AcuVor8H86wKxUKpSTywUNz5VNFmYAAAHKPA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F347E28D@SISPE7MB1.commscope.com> References: <113441059.20101206160717@pobox.com> In-Reply-To: <113441059.20101206160717@pobox.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 00:45:56 -0000 SSB3aG9sbHkgYWdyZWUgd2l0aCBCaWxsIG9uIHRoaXMuDQoNCllvdSB3YW50IHNvbWV0aGluZyBh IGxpdHRsZSBtb3JlIGNvbXBsaWNhdGVkIHRoYW4geW91IGhhdmUgYWxyZWFkeSBzcGVjaWZpZWQ6 DQoNCiAge259Xih7YX0pe219e2V9ID0+IHtlfSB7bi0xfSp7bSA/IG0tbiA6ICcnfSh7YX0ge2V9 KSA7IHdoZXJlIG4gPiAwDQogICAgICAgICAgICAgICAgICAgICB7ZX0gKnttID8gbS0xIDogJyd9 KHthfSB7ZX0pICAgICAgOyB3aGVyZSBuID09IDAgb3IgbiB1bmRlZmluZWQNCg0KTm90ZSB0aGUg biA9PSAwIGlzIGEgc3BlY2lhbCBjYXNlLiAgTm90ZSB0aGF0IHRoaXMgYXNzdW1lcyB0aGF0IG0g PiBuLiAgVGhlcmUgc2VlbXMgbGl0dGxlIHBvaW50IGluIHRoaXMgY29uc3RydWN0aW9uIGlmIG0g PT0gMSwgYnV0IHRoaXMgZG9lcyBoYW5kbGUgdGhhdCBjYXNlLg0KDQoNCkFzaWRlIGZyb20gdGhv c2Ugc29ydHMgb2YgcHJvYmxlbXMsIHRoZSBkZWZpbml0aW9uIG9mICdhJyBpcyBhIGxpdHRsZSBs b29zZS4gIFlvdSBzaG91bGQgdHJ5IHRvIGJ1aWxkIG9uIHRoZSBSRkMgNTIzNCBBQk5GIGluIHlv dXIgZGVmaW5pdGlvbnMuDQoNClRoZSBwcm9wb3NlZCBydWxlIGhhcyBhbiBBQk5GIGRlZmluaXRp b24gc29tZXRoaW5nIGxpa2UgKD8pOiANCg0KICBoYXQtcnVsZSA9IDEqRElHSVQgIl4oIiBhICIp IiAxKkRJR0lUDQogIGEgPSBWQ0hBUiAvIFNQIC8gSFQgLyA8YW55IG90aGVyIHNlcGFyYXRvcj4N Cg0KVGhhdCdzIGEgbG90IG9mIGZsZXhpYmlsaXR5IGluIHRoZSBpbnRlcm5hbCBwYXJ0LiAgVG9v IG11Y2ggZmxleGliaWxpdHkuICBVc2luZyBwYXJlbnRoZXNlcyBtZWFucyB0aGF0IHRoZXkgbmVl ZCB0byBiZSBkaXN0aW5ndWlzaGVkIGZyb20gdGhlIHBhcmVudGhlc2VzIHRoYXQgbWlnaHQgYXBw ZWFyIGluIHRoZSAnYScgcGFydC4gDQoNCklmIHlvdSBzZWUgdGhpcyBhcyBhIHN1YnN0aXR1dGUg Zm9yIHRoZSAiKiIgaW4gYSBub3JtYWwgcmVwZXRpdGlvbiBydWxlLCB0aGF0IG1ha2VzIGl0IGVh c2llci4gIEdpdmVuIHRoYXQgaXQgaGFzIGxlbmd0aCBsb25nZXIgdGhhbiAxIGNoYXJhY3Rlciwg YnkgcHJvdmlkaW5nIGEgY2xlYXIgZGVsaW5lYXRpb24gb2YgdGhlIHN0YXJ0IGFuZCBlbmQgeW91 IGNhbiBiZSBtb3JlIGZsZXhpYmxlIG9uIHRoZSBjb250ZW50LiAgRWl0aGVyIHRoYXQgb3IgdG8g cmVzdHJpY3Qgd2hhdCBmb2xsb3dzIHRoZSBeLg0KDQpQcmVmZXJhYmx5IGRlbGluZWF0ZSBiZXR0 ZXIgQU5EIHJlc3RyaWN0IGNvbnRlbnQ6DQoNCiAgIHJlcGVhdCAvPSBoYXQtcnVsZQ0KICAgaGF0 LXJ1bGUgPSAqRElHSVQgIl4iIGVsZW1lbnQgIl4iICpESUdJVA0KDQpUaGlzIHJlc3RyaWN0cyB0 aGUgY29udGVudCB3aXRob3V0IHByZXZlbnRpbmcgdGhlIHVzZSBvZiBtb3JlIGNvbXBsZXggY29u dGVudCAtIHlvdSBqdXN0IGhhdmUgdG8gdXNlIGEgcnVsZW5hbWUgaW5zdGVhZC4NCg0KWW91IGNh bid0IHVzZSBlbGVtZW50cyAobm90ZSB0aGUgJ3MnKSBoZXJlIGJlY2F1c2UgdGhhdCBzb3J0IG9m IGNvbXBsZXhpdHkgaXMgYSByZWFsIHBhaW4gdG8gc3BlY2lmeS4NCg0KVGhhdCBsZWF2ZXMgZXhh bXBsZXM6DQoNCiAxXiI7Il4zZWxlbWVudCA7IDEgdG8gMyBlbGVtZW50cyBzZXBhcmF0ZWQgYnkg Ow0KIDFeU1BeZWxlbWVudCAgIDsgMSBvciBtb3JlIGVsZW1lbnRzIHNlcGFyYXRlZCBieSBTUCBy dWxlDQogXiIsIl4zZWxlbWVudCAgIDsgMCB0byAzIGVsZW1lbnRzIHNlcGFyYXRlZCBieSAsDQog XiV4MjAuMjBeZWxlbWVudCAgOyBhbnkgbnVtYmVyIG9mIGVsZW1lbnRzIHNlcGFyYXRlZCBieSBh IHR3byBzcGFjZSBjaGFyYWN0ZXJzDQoNCllvdSBzaG91bGQgdHJ5IHRvIGFuc3dlciB0aGUgcXVl c3Rpb24gaW4gdGhlIGRyYWZ0OiB3aHkgdXNlIHRoZSAnXicgY2hhcmFjdGVyIGluc3RlYWQgb2Yg dGhlICcjJyBjaGFyYWN0ZXI/ICBJIGd1ZXNzIHRoYXQgdGhpcyBpcyBhbiBhcmJpdHJhcnkgY2hv aWNlIG1vcmUgdGhhbiBhbnl0aGluZyBlbHNlLg0KDQotLU1hcnRpbg0KDQpPbiAyMDEwLTEyLTA3 IGF0IDExOjA3OjE3LCBCaWxsIE1jUXVpbGxhbiB3cm90ZToNCj4gSSBmb3VuZCBzZXZlcmFsIHBy b2JsZW1zIHdpdGggdGhpcyBkcmFmdC4NCj4gDQo+IEluIG92ZXJ2aWV3LCB0aGUgcmVhc29uIHRo YXQgd2UgcmVtb3ZlZCB0aGUgI3J1bGUgZnJvbSBBQk5GIHdhcyB0aGF0IGl0DQo+IHdhcw0KPiB2 ZXJ5IGRpZmZpY3VsdCB0byBzcGVjaWZ5IGZvciBhIGdlbmVyYWwgY2FzZS4gVGhpcyBkcmFmdCBo YXMgdGhlIHNhbWUNCj4gcHJvYmxlbS4NCj4gDQo+IFRoZSBwcm9kdWN0aW9uIGdpdmVuIGRvZXMg bm90IGFjdHVhbGx5IHByb2R1Y2UgdGhlIGRlc2lyZWQgcmVzdWx0cy4NCj4gDQo+ID4gICBuXihh KW0gZWxlbWVudCA9ICggbigqTFdTIGVsZW1lbnQpICpvKCpMV1MgYSAqTFdTIGVsZW1lbnQpKQ0K PiANCj4gSWYgdGhlIHVzYWdlIGlzOg0KPiANCj4gICAgIDVeKCIsIikxMCAiYWJjIg0KPiANCj4g aXQgd291bGQgYWxsb3cgc29tZXRoaW5nIGxpa2U6DQo+IA0KPiAgICAgYWJjIGFiYyBhYmMgYWJj IGFiYyBhYmMgLCBhYmMNCj4gDQo+IG5vdDoNCj4gDQo+ICAgICBhYmMsIGFiYywgYWJjLCBhYmMs IGFiYywgYWJjLCBhYmQNCj4gDQo+IHdoaWNoIHdhcyBwcm9iYWJseSBpbnRlbmRlZC4NCj4gDQo+ IC0tLS0tDQo+IA0KPiBUaGUgcHJvZHVjdGlvbjoNCj4gDQo+ID4gICBhICAgICAgICAgICAgICA9 IFZDSEFSIC8gU1AgLyBIVCAvIDxhbnkgb3RoZXIgc2VwYXJhdG9yPg0KPiANCj4gZG9lcyBub3Qg c2VlbSB0byBhZGRyZXNzIHRoZSBwb3NzaWJpbGl0eSBvZiBtdWx0aS1jaGFyYWN0ZXIgc2VwYXJh dG9ycw0KPiB2ZXJ5DQo+IGNsZWFybHkuIFdoYXQgaWYgSSB3YW50IHRvIGRlZmluZSBhIGxpc3Qg bGlrZToNCj4gDQo+ICAgICBhYmMgYW5kIGRlZiBhbmQgZ2hpIGFuZCBqa2wNCj4gDQo+IGNhbiBJ IHVzZToNCj4gDQo+ICAgICBeKCIgYW5kICIpaWRlbnQNCj4gDQo+IC0tLS0tDQo+IA0KPiBJIGFs c28gZG8gbm90IGJlbGlldmUgdGhhdCAqRldTIGJlbG9uZ3MgaW4gc3VjaCBhIGdlbmVyYWwgcnVs ZSBhbmQNCj4gc2hvdWxkDQo+IHJhdGhlciBiZSBkZWZpbmVkIGJ5IHRoZSBhY3R1YWwgdXNhZ2Uu IEUuZy46DQo+IA0KPiAgICAgNV4oKkZXUyAiLCIgKkZXUykxMCAiYWJjIg0KPiANCj4gLS0tLS0N Cj4gDQo+IFR5cG86IDIuMSBFeGFtcGxlcywgZm91cnRoIGV4YW1wbGUgc2hvdWxkIGJlOiBeKCIt IillbGVtZW50DQo+IA0KPiAtLQ0KPiBCaWxsIE1jUXVpbGxhbiA8TWNRdWlsV1BAcG9ib3guY29t Pg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gSWV0ZiBtYWlsaW5nIGxpc3QNCj4gSWV0ZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYNCg0KDQo= From Martin.Thomson@andrew.com Mon Dec 6 16:48:36 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0518928C0F5 for ; Mon, 6 Dec 2010 16:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGohclDHjoPr for ; Mon, 6 Dec 2010 16:48:35 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 4B01428C0EA for ; Mon, 6 Dec 2010 16:48:35 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:53331 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S39742921Ab0LGAt7 (ORCPT ); Mon, 6 Dec 2010 18:49:59 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 6 Dec 2010 18:49:59 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 7 Dec 2010 08:49:58 +0800 From: "Thomson, Martin" To: "Thomson, Martin" , IETF Discussion Date: Tue, 7 Dec 2010 08:49:56 +0800 Subject: RE: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt Thread-Topic: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt Thread-Index: AcuVor8H86wKxUKpSTywUNz5VNFmYAAAHKPAAAFUdZA= Message-ID: <8B0A9FCBB9832F43971E38010638454F03F347E28F@SISPE7MB1.commscope.com> References: <113441059.20101206160717@pobox.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 00:48:36 -0000 T24gMjAxMC0xMi0wNyBhdCAxMTo0NzoxNSwgVGhvbXNvbiwgTWFydGluIHdyb3RlOg0KPiAgIHtu fV4oe2F9KXttfXtlfSA9PiB7ZX0ge24tMX0qe20gPyBtLW4gOiAnJ30oe2F9IHtlfSkgOyB3aGVy ZSBuID4gMA0KPiAgICAgICAgICAgICAgICAgICAgICB7ZX0gKnttID8gbS0xIDogJyd9KHthfSB7 ZX0pICAgICAgOyB3aGVyZSBuID09IDANCg0KTXkgbWlzdGFrZSwgZm9yZ290IHRoZSBicmFja2V0 cyBvbiB0aGUgc2Vjb25kOg0KICAgICAgICAgICAgICAgICAgICAgW3tlfSAqe20gPyBtLTEgOiAn J30oe2F9IHtlfSldICAgICAgOyB3aGVyZSBuID09IDANCg== From jari.arkko@piuha.net Tue Dec 7 06:17:40 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957F228C0E0 for ; Tue, 7 Dec 2010 06:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM15KcGW3Eu1 for ; Tue, 7 Dec 2010 06:17:39 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9829128C0DC for ; Tue, 7 Dec 2010 06:17:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 98D9C2CC3C; Tue, 7 Dec 2010 16:19:04 +0200 (EET) 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 y+mk1h1R1jYN; Tue, 7 Dec 2010 16:19:04 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 0A7522CC2E; Tue, 7 Dec 2010 16:19:04 +0200 (EET) Message-ID: <4CFE4257.5070204@piuha.net> Date: Tue, 07 Dec 2010 16:19:03 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF Discussion , Ron Bonica Subject: Re: Last Call: (Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment) to Informational RFC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 14:17:40 -0000 Since the last call is still going on, I wanted to let you know that I have updated this draft today to address some feedback from Cameron Byrne and Shawn Emery. The diffs are available at http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines as soon as the tool server updates its draft version. Look for version 09. Many thanks to Shawn and Cameron for their comments. Jari From sm@resistor.net Tue Dec 7 13:35:48 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8893A689E for ; Tue, 7 Dec 2010 13:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.45 X-Spam-Level: X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t7xK6nRaYe1 for ; Tue, 7 Dec 2010 13:35:42 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 0A4763A6893 for ; Tue, 7 Dec 2010 13:35:42 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oB7LatvV006977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 13:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1291757826; x=1291844226; bh=rYj5JZJaLM4r9tuRIsGgZeI+3ePySBwa5U4YbSNpBMo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=EzYLscXe8l9utBVsKn4IG5sGKDLQDto7DJp6e4arw0SJi/Oddlm3znFuFjIUyiJ7S 412Dg0eHcui52jOnd4vicach9hT7sfDJspI6NYCiotq0uB9KzqxEG6/W3K2owFjUJp sbMHI8FD0gyWMWQom0LOLh3nXEUSnGONcXufkhBs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1291757826; x=1291844226; bh=rYj5JZJaLM4r9tuRIsGgZeI+3ePySBwa5U4YbSNpBMo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=x0iryRmm6uQgTZf4L8vIVL7Fh6CE5L1UbYV6y4EHa403KWF2OwlXZQcCrhZOzCSEp C3IEZ7n/WOggriHL8qqYYv5F1WCYsRCeHzvyB64GFjLarVbfmMJ9EUsncrJqmwSWGq 3JKQ/jM/6IVZezQBiY7wbaMx7l/2RQs6pghXa/Ec= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=iWp7dR5aroEsAaNp3UkgwEI5ibH2jLzykROhZmX3PFGRLy0S2shiwljZyw81DH7ck jMUaX/IBQNNDgAAueaiYA4q5/oS4xg81q/cd8yqqG55oRVnW7AVEnwQ4sXffTQ45zsU jjlIMt/3QfHKNUvu7f9hAx6C2AZWiJfLfNAEjNc= Message-Id: <6.2.5.6.2.20101207102917.0a8a8bd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Dec 2010 13:36:43 -0800 To: ietf@ietf.org From: SM Subject: Re: Second Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)) to BCP In-Reply-To: <20101118123651.8314.60809.idtracker@localhost> References: <20101118123651.8314.60809.idtracker@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Saint-Andre , Jeff Hodges X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 21:35:48 -0000 At 04:36 18-11-10, The IESG wrote: >The IESG has received a request from an individual submitter to consider >the following document: > >- 'Representation and Verification of Domain-Based Application Service > Identity within Internet Public Key Infrastructure Using X.509 (PKIX) > Certificates in the Context of Transport Layer Security (TLS) ' > as a BCP > >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 In Section 2.2: 'A "traditional domain name", i.e., a fully-qualified domain name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH labels" as defined in [IDNA-DEFS].' It would be better to reference RFC 1123 for LDH labels instead of RFC 5890 unless the authors would like to adopt a terminology that is specific to IDNA. In Section 3.1: "Unless a profile of this specification allows continued support for the wildcard character '*', the fully-qualified DNS domain name portion of a presented identifier SHOULD NOT contain the wildcard character, whether as the complete left-most label within the identifier (following the definition of "label" from [DNS], e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or foo*.example.com)." If the presented identifier is a fully-qualified DNS domain name (I assume that means FQDN), the left-most label cannot be a wildcard character according to LDH rules. I suggest rewriting that as: Unless a profile of this specification allows continued support for the wildcard character '*', the domain name portion of a presented identifier SHOULD NOT contain the wildcard character (e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or foo*.example.com). In Section 4.2.1: "The client might need to extract the source domain and service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., extracting the fully-qualified DNS domain name from the authority component of a URI or extracting the service type from the scheme of a URI) or information for which the extraction is performed in a manner that is not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection that provides both mutual authentication and integrity checking)." I read part of the above as meaning that data can only be extracted from DNS if the data has been resolved via DNSSEC. Is that the intent? Section 4.3 discusses about how to seek a match against the list of reference identifiers. I found the thread at http://www.ietf.org/mail-archive/web/certid/current/msg00318.html informative. In Section 4.4.3: "A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*' as part or all of a label (following the definition of "label" from [DNS])" According to the definition of label in RFC 1035, the wildcard character cannot be part of a label. I suggest removing the last part of that sentence. FWIW, RFC 4592 updates the wildcard definition in RFC 1034 and uses the term "asterisk label". Was the comment about the security note ( http://www.ietf.org/mail-archive/web/certid/current/msg00427.html ) in Section 4.6.4 addressed? Regards, -sm From samirs.lists@gmail.com Wed Dec 8 00:55:55 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2F73A6903 for ; Wed, 8 Dec 2010 00:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJi3PclxfkpZ for ; Wed, 8 Dec 2010 00:55:54 -0800 (PST) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by core3.amsl.com (Postfix) with ESMTP id C0F2E3A68BD for ; Wed, 8 Dec 2010 00:55:54 -0800 (PST) Received: by iwn39 with SMTP id 39so1351864iwn.27 for ; Wed, 08 Dec 2010 00:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=dEjVBxcPfiVR+UTEku8l8pYiJcx8YXGGB6D79LxwqW0=; b=eMsGHt1PU9GYnDnXBqTzOj28j9mFo0IrB5oAgjS0pamcywFfpMAc3JDfkK43F6ICbK JSDh95QZgPhYRwG5xZ1ODiiyLkual9Vk3aV3AgRBrCtJPAybzrkw79qWS0VtoIU9CbIZ m1sZze/FlTOVsNYovboLYV1QzseLnCmDxYqEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HPWxVSwy0XXpPLX0lG/kKnjK0a+LwkKdxnd4FQ0Qzs+Ygx0cZYTi4HeOb3juOaoyXd DUIv88sqhCzBSkoiN2sqUoiLVZt+4Y4S9haqQni0k1Qcxtw00naKSE+q73MUhpH97MYD RbRwtK1PVO23eOiziN8QdqizXzg6ZmjtDD1Lk= MIME-Version: 1.0 Received: by 10.231.169.208 with SMTP id a16mr224938ibz.199.1291798641741; Wed, 08 Dec 2010 00:57:21 -0800 (PST) Received: by 10.231.178.82 with HTTP; Wed, 8 Dec 2010 00:57:21 -0800 (PST) Date: Wed, 8 Dec 2010 00:57:21 -0800 Message-ID: Subject: Clarification for Copyright to referred material in IETF draft From: Samir Srivastava To: Ietf@ietf.org Content-Type: multipart/alternative; boundary=001636d34437298ecd0496e24fc6 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 08:55:55 -0000 --001636d34437298ecd0496e24fc6 Content-Type: text/plain; charset=ISO-8859-1 Hi, If a link is referred within the draft being submitted to IETF has link to other web-site as a reference for other work (such as wikipedia), does IETF require the copyright for that referred stuff also. Thx Samir --001636d34437298ecd0496e24fc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
=A0 If a link is referred within the draft being submitted to IETF has= link to other web-site as a reference for other work (such as wikipedia), = does IETF require the copyright for that referred stuff also.
=A0
Thx
Samir
--001636d34437298ecd0496e24fc6-- From Francis.Dupont@fdupont.fr Wed Dec 8 06:54:18 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4E23A6907; Wed, 8 Dec 2010 06:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG+cczNMlops; Wed, 8 Dec 2010 06:54:17 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 6DFF93A68CB; Wed, 8 Dec 2010 06:54:17 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id oB8EthVY034055; Wed, 8 Dec 2010 14:55:44 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201012081455.oB8EthVY034055@givry.fdupont.fr> From: Francis Dupont To: L.Wood@surrey.ac.uk Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC In-reply-to: Your message of Fri, 03 Dec 2010 17:32:23 GMT. <2E536B32-428C-4BC7-A784-9DA348979819@surrey.ac.uk> Date: Wed, 08 Dec 2010 15:55:43 +0100 Sender: Francis.Dupont@fdupont.fr Cc: wes@mti-systems.com, iesg@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 14:54:18 -0000 I have a concern about no security usages of MD5 for practical reasons: in some environments, including US Gov, crypto implementations (e.g., FIPS 140-2 HSMs) are required to not support MD5 so you can have to choose between a compliant application and a conformant crypto, for instance for DNS TSIG... So IMHO it is still a good idea to avoid MD5 in any uses, even when it is still far to have been proved insecure or for an use which is not about security. This could be caught by the "DEPRECATED" keyword in the registry but this registry doesn't seem to have usage entries?! To conclude I am fine with the implicit conclusion of the I-D to not use MD5 or HMAC-MD5 in new protocols. Thanks Francis.Dupont@fdupont.fr PS: I am the gen-art reviewer for this document too. From tme@americafree.tv Wed Dec 8 07:07:09 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18EB33A6941 for ; Wed, 8 Dec 2010 07:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.05 X-Spam-Level: X-Spam-Status: No, score=-102.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyPSgPbw-7yD for ; Wed, 8 Dec 2010 07:07:08 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id F23593A6954 for ; Wed, 8 Dec 2010 07:07:07 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 7988D96249C6; Wed, 8 Dec 2010 10:08:35 -0500 (EST) Subject: Re: Clarification for Copyright to referred material in IETF draft Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: Date: Wed, 8 Dec 2010 10:08:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Samir Srivastava X-Mailer: Apple Mail (2.1081) Cc: Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 15:07:09 -0000 On Dec 8, 2010, at 3:57 AM, Samir Srivastava wrote: > Hi, > =20 > If a link is referred within the draft being submitted to IETF has = link to other web-site as a reference for other work (such as = wikipedia), does IETF require the copyright for that referred stuff = also. > =20 Dear Samir; The IETF does not require copyright in any web-site reference. A link = reference is no different in this regard than any other.=20 This statement is based on our advice of counsel. Regards Marshall Eubanks=20 Chair / IETF Trust > Thx > Samir > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From Jeff.Hodges@KingsMountain.com Wed Dec 8 11:13:10 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70833A69A4 for ; Wed, 8 Dec 2010 11:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=1.759, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT1zQLfhGZb0 for ; Wed, 8 Dec 2010 11:13:09 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 533463A69A1 for ; Wed, 8 Dec 2010 11:13:09 -0800 (PST) Received: (qmail 26703 invoked by uid 0); 8 Dec 2010 19:14:36 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 8 Dec 2010 19:14:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=E7iINPOtvO4jfhKadzD0ckRfUoDNkVCbwYqcjwcokUPk0w8S2M7yKhiIvftC7hyM13Ct2jtvhmGh5bA2MTp4VUWv+QiYlifsIgOun0wa28ou1LwtJKZdH80eHb6wl1El; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PQPTI-0005pm-4t; Wed, 08 Dec 2010 12:14:36 -0700 Message-ID: <4CFFD91A.2060808@KingsMountain.com> Date: Wed, 08 Dec 2010 11:14:34 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: SM , IETF Discussion List , draft-saintandre-tls-server-id-check.all@tools.ietf.org, IETF cert-based identity Subject: Re: Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 19:13:10 -0000 [ adding certid@ list ] Thanks for the review SM. > In Section 2.2: > > 'A "traditional domain name", i.e., a fully-qualified domain name > or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH > labels" as defined in [IDNA-DEFS].' > > It would be better to reference RFC 1123 for LDH labels instead of > RFC 5890 unless the authors would like to adopt a terminology that is > specific to IDNA. I looked into this in detail earlier this year -- it was discussed on ietf@ (during the initial IETF LC for this spec), and this particular issue resolution was summarized here (by John Klensin).. Re: Last Call: draft-saintandre-tls-server-id-check http://www.ietf.org/mail-archive/web/ietf/current/msg62601.html In brief summary, RFCs {1034,1035,1123,2181} do not define "letter-digit-hyphen" DNS name labels in a concisely referenceable fashion, nor particularly clearly. The IDNA specs have done the wider DNS-community a service by doing so, and at present the fashion in which "traditional domain name" is defined and cited is the best we can do. Given that IDNs are a deployed reality, every (new or updated) spec that discusses domain names going forward is going to need to reference the IDNA specs in some fashion, and probably should simply use the LDH-Label, A-Label, and U-Label nomenclature. (IMV) > In Section 3.1: > > "Unless a profile of this specification allows continued support > for the wildcard character '*', the fully-qualified DNS domain > name portion of a presented identifier SHOULD NOT contain the > wildcard character, whether as the complete left-most label > within the identifier (following the definition of "label" from > [DNS], e.g., "*.example.com") or as a fragment thereof (e.g., > *oo.example.com, f*o.example.com, or foo*.example.com)." > > If the presented identifier is a fully-qualified DNS domain name (I > assume that means FQDN), the left-most label cannot be a wildcard > character according to LDH rules. I suggest rewriting that as: > > Unless a profile of this specification allows continued support > for the wildcard character '*', the domain name portion of > a presented identifier SHOULD NOT contain the wildcard character > (e.g., "*.example.com") or as a fragment thereof (e.g., > *oo.example.com, f*o.example.com, or foo*.example.com). while I agree with your subtle substitution of.. "fully-qualified DNS domain name portion" ..with.. "domain name portion" ..however, I disagree with your further simplification of that paragraph because we feel we need to supply the more detailed context. > In Section 4.2.1: > > "The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs (e.g., > extracting the fully-qualified DNS domain name from the authority > component of a URI or extracting the service type from the scheme of > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g., > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain mapping > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking)." > > I read part of the above as meaning that data can only be extracted > from DNS if the data has been resolved via DNSSEC. Is that the intent? No, that is not the intent. We've further refined that paragraph as a result of a concurrent discussion with Ben Campbell (on certid@) and have this present working text.. The client might need to extract the source domain and service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., extracting the fully-qualified DNS domain name from the "authority" component of a URI or extracting the service type from the scheme of a URI) or information for which the extraction is performed in a manner that is not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection that provides both mutual authentication and integrity checking). These considerations apply only to extraction of the source domain from the inputs; naturally, if the inputs themselves are invalid or corrupt (e.g., a user has clicked a link provided by a malicious entity in a phishing attack), then the client might end up communicating with an unexpected application service. > Section 4.3 discusses about how to seek a match against the list of > reference identifiers. I found the thread at > http://www.ietf.org/mail-archive/web/certid/current/msg00318.html informative. > > In Section 4.4.3: > > "A client employing this specification's rules MAY match the reference > identifier against a presented identifier whose DNS domain name > portion contains the wildcard character '*' as part or all of a label > (following the definition of "label" from [DNS])" > > According to the definition of label in RFC 1035, the wildcard > character cannot be part of a label. I suggest removing the last > part of that sentence. You mean removing the parenthetical "(following the definition of "label" from [DNS])", yes? In reviewing RFC 1035 I see your concern, tho we'd like to reference a description of "label". I note that RFC 1034 [S3.1] seems to appropriately supply this, so I propose we keep the parenthetical but alter it to be.. (following the description of labels and domain names in [DNS-CONCEPTS]) > FWIW, RFC 4592 updates the wildcard > definition in RFC 1034 and uses the term "asterisk label". Yes, but that definition (and term) appears to be specific to underlying DNS internals, not to (pseudo) domain names as wielded (or "presented" (eg in certs)) in other protocols. > Was the comment about the security note ( > http://www.ietf.org/mail-archive/web/certid/current/msg00427.html ) > in Section 4.6.4 addressed? Yes, we believe so. thanks again for your review, =JeffH From wesley.m.eddy@nasa.gov Wed Dec 8 12:10:23 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27ADA3A68AB; Wed, 8 Dec 2010 12:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.117 X-Spam-Level: X-Spam-Status: No, score=-106.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wlvVlmbj3+1; Wed, 8 Dec 2010 12:10:22 -0800 (PST) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 71BD23A689A; Wed, 8 Dec 2010 12:10:18 -0800 (PST) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 1EA962D85E3; Wed, 8 Dec 2010 14:11:45 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id oB8KBjL6003391; Wed, 8 Dec 2010 14:11:45 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 8 Dec 2010 14:11:44 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Francis Dupont , "L.Wood@surrey.ac.uk" Date: Wed, 8 Dec 2010 14:08:03 -0600 Subject: RE: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Topic: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Index: AcuW6BKAcPNGEywQRI6TTXQPTS6SvgAK4xNo Message-ID: References: Your message of Fri, 03 Dec 2010 17:32:23 GMT. <2E536B32-428C-4BC7-A784-9DA348979819@surrey.ac.uk> ,<201012081455.oB8EthVY034055@givry.fdupont.fr> In-Reply-To: <201012081455.oB8EthVY034055@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-12-08_10:2010-12-08, 2010-12-08, 1970-01-01 signatures=0 Cc: "wes@mti-systems.com" , "iesg@ietf.org" , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 20:10:23 -0000 The logic doesn't make sense in this position. "Crypto modules can't use M= D5, thus no protocols at all should use MD5." ________________________________________ From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Francis Du= pont [Francis.Dupont@fdupont.fr] Sent: Wednesday, December 08, 2010 9:55 AM To: L.Wood@surrey.ac.uk Cc: wes@mti-systems.com; iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: (Updated = Security Considerations for the MD5 Message-Digest and the HMAC-M= D5 Algorithms) to Informational RFC I have a concern about no security usages of MD5 for practical reasons: in some environments, including US Gov, crypto implementations (e.g., FIPS 140-2 HSMs) are required to not support MD5 so you can have to choose between a compliant application and a conformant crypto, for instance for DNS TSIG... So IMHO it is still a good idea to avoid MD5 in any uses, even when it is still far to have been proved insecure or for an use which is not about security. This could be caught by the "DEPRECATED" keyword in the registry but this registry doesn't seem to have usage entries?! To conclude I am fine with the implicit conclusion of the I-D to not use MD5 or HMAC-MD5 in new protocols. Thanks Francis.Dupont@fdupont.fr PS: I am the gen-art reviewer for this document too. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf= From huitema@microsoft.com Wed Dec 8 13:23:59 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CA53A68B7; Wed, 8 Dec 2010 13:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.116 X-Spam-Level: X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3wnHL9C4ECo; Wed, 8 Dec 2010 13:23:48 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 6D51D3A687D; Wed, 8 Dec 2010 13:23:45 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 8 Dec 2010 13:25:06 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.255.3; Wed, 8 Dec 2010 13:25:06 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.228]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 8 Dec 2010 13:25:05 -0800 From: Christian Huitema To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , Francis Dupont , "L.Wood@surrey.ac.uk" Subject: RE: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Topic: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Index: AQHLlxRXkp8826zdvUCPqRshSRLcfZOXDdgQ Date: Wed, 8 Dec 2010 21:25:05 +0000 Message-ID: References: Your message of Fri, 03 Dec 2010 17:32:23 GMT. <2E536B32-428C-4BC7-A784-9DA348979819@surrey.ac.uk> ,<201012081455.oB8EthVY034055@givry.fdupont.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wes@mti-systems.com" , "iesg@ietf.org" , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 21:23:59 -0000 The issue would be a whole lot easier to resolve if we had an agreed upon a= lgorithm for the "non security" usages. CRC64 comes to mind. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Edd= y, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] Sent: Wednesday, December 08, 2010 12:08 PM To: Francis Dupont; L.Wood@surrey.ac.uk Cc: wes@mti-systems.com; iesg@ietf.org; ietf@ietf.org Subject: RE: Last Call: (Updated Se= curity Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm= s) to Informational RFC=20 The logic doesn't make sense in this position. "Crypto modules can't use M= D5, thus no protocols at all should use MD5." ________________________________________ From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Francis Du= pont [Francis.Dupont@fdupont.fr] Sent: Wednesday, December 08, 2010 9:55 AM To: L.Wood@surrey.ac.uk Cc: wes@mti-systems.com; iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: (Updated = Security Considerations for the MD5 Message-Digest and the HMAC-M= D5 Algorithms) to Informational RFC I have a concern about no security usages of MD5 for practical reasons: in some environments, including US Gov, crypto implementations (e.g., FIPS = 140-2 HSMs) are required to not support MD5 so you can have to choose betwe= en a compliant application and a conformant crypto, for instance for DNS TS= IG... So IMHO it is still a good idea to avoid MD5 in any uses, even when it is s= till far to have been proved insecure or for an use which is not about secu= rity. This could be caught by the "DEPRECATED" keyword in the registry but this r= egistry doesn't seem to have usage entries?! To conclude I am fine with the implicit conclusion of the I-D to not use MD= 5 or HMAC-MD5 in new protocols. Thanks Francis.Dupont@fdupont.fr PS: I am the gen-art reviewer for this document too. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From stpeter@stpeter.im Wed Dec 8 13:42:55 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3193A687D; Wed, 8 Dec 2010 13:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.394 X-Spam-Level: X-Spam-Status: No, score=-103.394 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBMHKYl3TDbN; Wed, 8 Dec 2010 13:42:53 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A15AD3A686B; Wed, 8 Dec 2010 13:42:52 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 99A264009B; Wed, 8 Dec 2010 14:56:12 -0700 (MST) Message-ID: <4CFFFC32.2000806@stpeter.im> Date: Wed, 08 Dec 2010 14:44:18 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: =JeffH Subject: Re: [certid] Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP References: <4CFFD91A.2060808@KingsMountain.com> In-Reply-To: <4CFFD91A.2060808@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050104060209080400010102" Cc: SM , IETF cert-based identity , IETF Discussion List , draft-saintandre-tls-server-id-check.all@tools.ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 21:42:56 -0000 This is a cryptographically signed message in MIME format. --------------ms050104060209080400010102 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/8/10 12:14 PM, =3DJeffH wrote: > [ adding certid@ list ] >=20 > Thanks for the review SM. >=20 >> In Section 2.2: >> >> 'A "traditional domain name", i.e., a fully-qualified domain name >> or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH >> labels" as defined in [IDNA-DEFS].' >> >> It would be better to reference RFC 1123 for LDH labels instead of >> RFC 5890 unless the authors would like to adopt a terminology that is >> specific to IDNA. >=20 > I looked into this in detail earlier this year -- it was discussed on > ietf@ (during the initial IETF LC for this spec), and this particular > issue resolution was summarized here (by John Klensin).. >=20 > Re: Last Call: draft-saintandre-tls-server-id-check > http://www.ietf.org/mail-archive/web/ietf/current/msg62601.html >=20 > In brief summary, RFCs {1034,1035,1123,2181} do not define > "letter-digit-hyphen" DNS name labels in a concisely referenceable > fashion, nor particularly clearly. >=20 > The IDNA specs have done the wider DNS-community a service by doing so,= > and at present the fashion in which "traditional domain name" is define= d > and cited is the best we can do. Given that IDNs are a deployed reality= , > every (new or updated) spec that discusses domain names going forward i= s > going to need to reference the IDNA specs in some fashion, and probably= > should simply use the LDH-Label, A-Label, and U-Label nomenclature. (IM= V) I agree with that assessment. >> In Section 3.1: >> >> "Unless a profile of this specification allows continued support >> for the wildcard character '*', the fully-qualified DNS domain >> name portion of a presented identifier SHOULD NOT contain the >> wildcard character, whether as the complete left-most label >> within the identifier (following the definition of "label" from >> [DNS], e.g., "*.example.com") or as a fragment thereof (e.g., >> *oo.example.com, f*o.example.com, or foo*.example.com)." >> >> If the presented identifier is a fully-qualified DNS domain name (I >> assume that means FQDN), the left-most label cannot be a wildcard >> character according to LDH rules. I suggest rewriting that as: >> >> Unless a profile of this specification allows continued support >> for the wildcard character '*', the domain name portion of >> a presented identifier SHOULD NOT contain the wildcard character >> (e.g., "*.example.com") or as a fragment thereof (e.g., >> *oo.example.com, f*o.example.com, or foo*.example.com). >=20 > while I agree with your subtle substitution of.. >=20 > "fully-qualified DNS domain name portion" >=20 > ..with.. >=20 > "domain name portion" Done. > ..however, I disagree with your further simplification of that paragrap= h > because we feel we need to supply the more detailed context. >=20 >=20 >=20 >> In Section 4.2.1: >> >> "The client might need to extract the source domain and service typ= e >> from the input(s) it has received. The extracted data MUST includ= e >> only information that can be securely parsed out of the inputs (e.= g., >> extracting the fully-qualified DNS domain name from the authority >> component of a URI or extracting the service type from the scheme = of >> a URI) or information for which the extraction is performed in a >> manner that is not subject to subversion by network attackers (e.g= =2E, >> pulling the data from a delegated domain that is explicitly >> established via client or system configuration, resolving the data= >> via [DNSSEC], or obtaining the data from a third-party domain mapp= ing >> service in which a human user has explicitly placed trust and with= >> which the client communicates over a connection that provides both= >> mutual authentication and integrity checking)." >> >> I read part of the above as meaning that data can only be extracted >> from DNS if the data has been resolved via DNSSEC. Is that the intent= ? >=20 > No, that is not the intent. We've further refined that paragraph as a > result of a concurrent discussion with Ben Campbell (on certid@) and > have this present working text.. >=20 > The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs (e.g.= , > extracting the fully-qualified DNS domain name from the "authority" > component of a URI or extracting the service type from the scheme of= > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g.,= > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain mappin= g > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking). These considerations= > apply only to extraction of the source domain from the inputs; > naturally, if the inputs themselves are invalid or corrupt (e.g., a > user has clicked a link provided by a malicious entity in a phishing= > attack), then the client might end up communicating with an > unexpected application service. >=20 >=20 >=20 >> Section 4.3 discusses about how to seek a match against the list of >> reference identifiers. I found the thread at >> http://www.ietf.org/mail-archive/web/certid/current/msg00318.html > informative. >> >> In Section 4.4.3: >> >> "A client employing this specification's rules MAY match the refere= nce >> identifier against a presented identifier whose DNS domain name >> portion contains the wildcard character '*' as part or all of a la= bel >> (following the definition of "label" from [DNS])" >> >> According to the definition of label in RFC 1035, the wildcard >> character cannot be part of a label. I suggest removing the last >> part of that sentence. >=20 > You mean removing the parenthetical "(following the definition of > "label" from [DNS])", yes? >=20 > In reviewing RFC 1035 I see your concern, tho we'd like to reference a > description of "label". I note that RFC 1034 [S3.1] seems to > appropriately supply this, so I propose we keep the parenthetical but > alter it to be.. >=20 > (following the description of labels and domain names in [DNS-CONCEPT= S]) Done. >> FWIW, RFC 4592 updates the wildcard >> definition in RFC 1034 and uses the term "asterisk label". >=20 > Yes, but that definition (and term) appears to be specific to underlyin= g > DNS internals, not to (pseudo) domain names as wielded (or "presented" > (eg in certs)) in other protocols. >=20 >=20 >> Was the comment about the security note ( >> http://www.ietf.org/mail-archive/web/certid/current/msg00427.html ) >> in Section 4.6.4 addressed? >=20 > Yes, we believe so. >=20 >=20 > thanks again for your review, Indeed. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050104060209080400010102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw ODIxNDQxOFowIwYJKoZIhvcNAQkEMRYEFDGp9KowI8RqylCoe8xsHue0LF9oMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBNx2pJET9NmKzBb9Fjk7x9z3UhfnVoE6q9x3KpzK72ZuCbyOPXHECd4O5+ zm3jwIuhRHdSTWEvN/BwO5z9xHgU4vY39Oo1leX99pIHJ5YPq+ItFycUVhVQeahWAtjuWxMx V7igVme9wkCG9BjIGGN66ZuQvvfiRCIg9bu0QkjtJnFF9O8H3yX87cgwWTIra/SIqDV9QgjU yqT9v788kJDcVBz+dc/5lwH6bf65f3Vs9cF6huUUiAVU/eZ04iUcKuiwc9ySIcuSou0DNhlx u7A8t2X/GccSB1De/sbf5I11oiG6yarLMa0iEUxN/f/1N2OqvjV5X84up7myth2DwbpaAAAA AAAA --------------ms050104060209080400010102-- From Francis.Dupont@fdupont.fr Wed Dec 8 15:32:18 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1FA3A68BA; Wed, 8 Dec 2010 15:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsktpA9uk+KS; Wed, 8 Dec 2010 15:32:16 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 0D7A43A6868; Wed, 8 Dec 2010 15:32:15 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id oB8NXhhe067090; Wed, 8 Dec 2010 23:33:43 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201012082333.oB8NXhhe067090@givry.fdupont.fr> From: Francis Dupont To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC In-reply-to: Your message of Wed, 08 Dec 2010 14:08:03 CST. Date: Thu, 09 Dec 2010 00:33:43 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "wes@mti-systems.com" , "iesg@ietf.org" , "L.Wood@surrey.ac.uk" , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 23:32:18 -0000 In your previous mail you wrote: The logic doesn't make sense in this position. "Crypto modules can't use MD5, thus no protocols at all should use MD5." => this is a silly/bad/... consequence of the crypto label attached to the MD5 name. I understand you are not happy with this but what do you propose? Regards Francis.Dupont@fdupont.fr PS: BTW I'd like to apply the argument only to *new* protocols. From wesley.m.eddy@nasa.gov Wed Dec 8 19:00:04 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB073A6816; Wed, 8 Dec 2010 19:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.197 X-Spam-Level: X-Spam-Status: No, score=-106.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOf6dmbf4QTt; Wed, 8 Dec 2010 19:00:03 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 99B5B3A69AD; Wed, 8 Dec 2010 19:00:03 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 338C5A8010; Wed, 8 Dec 2010 21:01:32 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id oB931WLa031539; Wed, 8 Dec 2010 21:01:32 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Wed, 8 Dec 2010 21:01:31 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Francis Dupont Date: Wed, 8 Dec 2010 21:01:32 -0600 Subject: RE: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Topic: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Index: AcuXMF3bv2g4uQumTcWXMNJDeLH4fgAGWK13 Message-ID: References: Your message of Wed, 08 Dec 2010 14:08:03 CST. ,<201012082333.oB8NXhhe067090@givry.fdupont.fr> In-Reply-To: <201012082333.oB8NXhhe067090@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-12-09_02:2010-12-08, 2010-12-09, 1970-01-01 signatures=0 Cc: "wes@mti-systems.com" , "iesg@ietf.org" , "L.Wood@surrey.ac.uk" , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 03:00:04 -0000 I think a published update to MD5 security considerations should clearly sa= y what it's still fine to do with MD5, in addition to what it's not safe to= do. This would mean adding a couple sentences, and that's about all it wo= uld really take to be clear on the issue: "Since RFC 1321 was published, MD5 found popular use in checksuming large f= ile transfers. This use of MD5 is still reasonable, as the level of collis= ion resistance is of less importance in this application and MD5 may be sig= nificantly more efficient than cryptographically stronger algorithms. Comm= unications, networking, and storage systems prone to errors (e.g. due to fa= ulty hardware, drivers, bit-errors, faulty NAT/ALG algorithms, etc) do not = implement the known MD5 collision-finding algorithms, and MD5 remains highl= y effective at detecting such errors." ________________________________________ From: Francis.Dupont@fdupont.fr [Francis.Dupont@fdupont.fr] Sent: Wednesday, December 08, 2010 6:33 PM To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] Cc: L.Wood@surrey.ac.uk; wes@mti-systems.com; iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: (Updated Se= curity Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm= s) to Informational RFC In your previous mail you wrote: The logic doesn't make sense in this position. "Crypto modules can't use MD5, thus no protocols at all should use MD5." =3D> this is a silly/bad/... consequence of the crypto label attached to the MD5 name. I understand you are not happy with this but what do you propose? Regards Francis.Dupont@fdupont.fr PS: BTW I'd like to apply the argument only to *new* protocols.= From shanna@juniper.net Wed Dec 8 22:22:40 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012373A69F0; Wed, 8 Dec 2010 22:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thBzB5Ntl827; Wed, 8 Dec 2010 22:22:35 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 7E7253A69F5; Wed, 8 Dec 2010 22:22:33 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTQB1/269RZGPLnPwZfXhZ4c8e+QyPEQ+@postini.com; Wed, 08 Dec 2010 22:24:02 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 8 Dec 2010 22:23:10 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 9 Dec 2010 01:23:09 -0500 From: Stephen Hanna To: "ietf@ietf.org" , "secdir@ietf.org" , "ipfix@ietf.org" Date: Thu, 9 Dec 2010 01:23:06 -0500 Subject: secdir review of draft-ietf-ipfix-mediators-framework-09.txt Thread-Topic: secdir review of draft-ietf-ipfix-mediators-framework-09.txt Thread-Index: Acth3WZtFoUbk+23ReaFVG39Xm1qzw1iXwtQ 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 06:22:40 -0000 I have reviewed this document as part of the security directorate's =20 ongoing effort to review all IETF documents being processed by the =20 IESG. These comments were written primarily for the benefit of the =20 security area directors. Document editors and WG chairs should treat =20 these comments just like any other last call comments. This document adds a new concept to the IPFIX architecture (RFC 5470): IPFIX Mediation. This concept allows conversion, correlation, selection, and other transformations on IPFIX records. The document is clear and the Security Considerations section seems to adequately cover the issues raised. I don't see any problems from a security perspective. Thanks, Steve From Francis.Dupont@fdupont.fr Thu Dec 9 13:59:18 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B68728C102; Thu, 9 Dec 2010 13:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdshL8eJ+isz; Thu, 9 Dec 2010 13:59:17 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 5A9CA28C0F3; Thu, 9 Dec 2010 13:59:17 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id oB9M0kJL049458; Thu, 9 Dec 2010 22:00:46 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201012092200.oB9M0kJL049458@givry.fdupont.fr> From: Francis Dupont To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC In-reply-to: Your message of Wed, 08 Dec 2010 21:01:32 CST. Date: Thu, 09 Dec 2010 23:00:46 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "wes@mti-systems.com" , "iesg@ietf.org" , "L.Wood@surrey.ac.uk" , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 21:59:18 -0000 In your previous mail you wrote: I think a published update to MD5 security considerations should clearly say what it's still fine to do with MD5, in addition to what it's not safe to do. This would mean adding a couple sentences, and that's about all it would really take to be clear on the issue: "Since RFC 1321 was published, MD5 found popular use in checksuming large file transfers. This use of MD5 is still reasonable, as the level of collision resistance is of less importance in this application and MD5 may be significantly more efficient than cryptographically stronger algorithms. Communications, networking, and storage systems prone to errors (e.g. due to faulty hardware, drivers, bit-errors, faulty NAT/ALG algorithms, etc) do not implement the known MD5 collision-finding algorithms, and MD5 remains highly effective at detecting such errors." => you are trying to amplify the practical issue so I can't see how it solves it (:-)... Regards Francis.Dupont@fdupont.fr PS: BTW IMHO a dedicated function should be better than MD5 for this use, of course to reuse MD5 is easier (and I did it too :-). From jmpolk@cisco.com Thu Dec 9 16:13:35 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7F53A6BE7; Thu, 9 Dec 2010 16:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.48 X-Spam-Level: X-Spam-Status: No, score=-110.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eujsXdCHhuO; Thu, 9 Dec 2010 16:13:35 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0DB863A69BC; Thu, 9 Dec 2010 16:13:35 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,322,1288569600"; d="scan'208";a="296959733" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 10 Dec 2010 00:15:05 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBA0F47M011963; Fri, 10 Dec 2010 00:15:05 GMT Message-Id: <201012100015.oBA0F47M011963@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Dec 2010 18:15:04 -0600 To: wjaeger@att.com, jmullool@cisco.com, tscholl@nlayer.net, djsmith@cisco.com, mpls@ietf.org From: "James M. Polk" Subject: TSVDIR Review for draft-ietf-mpls-ip-options-05 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf@ietf.org, tsv-dir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 00:13:36 -0000 I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. Summary: This is a well written, concise and needed modification to MPLS. That said, I don't understand why the 1st minor issue below is present. Recommend (fairly strongly) adding the "Document Updates: RFC 3031, RFC 3032" as mentioned below on this first page of this RFC to be. Transport Issues: There are no issues minor issues: - S2 "Motivation", last sentence is "We believe that this document adds details that have not been fully addressed in [RFC3031] and [RFC3032] as well as complements [RFC3270], [RFC3443] and [RFC4950]. " I find it surprising that this document does not formally update 3031 and 3032, given that it is mandatory to implement, optional to invoke. ISTM, as an outsider to MPLS, this would in fact be the case given the impact of/to IP stacks not adhering to this proposed standard. - Section 5.2 is about Router Alert Options, and states "At the time of this writing ...". I wonder if this subsection is valid, or needs another review against this IntArea ID http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations-02 to still be valid in a month or two once the IntArea ID (currently in WGLC) is processed by the IESG and RFC-Editor? IMO - these two docs are progressing near enough to each other to each consider what the other says - with or without a normative or informative reference in either or both docs to the other. nits: - I'm surprised to see the Abstract on page 2. I thought we collectively fixed the case in which the Abstract can be on any page other than page 1. - at the page Footer, in the middle of the line, there isn't a "short document name" - which has been there on all previous well formed IDs and RFCs that I have seen (which of course is not all of them). It is recommended the authors pick a short form name for the subject of this doc for this location, such as LER Header Option Behaviors - S3, 4th para, second to last sentence is: "First a downstream LSR may have not have sufficient IP routing information to forward the packet resulting in packet loss. " recommend removing the first instance of "have". The sentence reads better without it. - S3, 4th para, last two sentences list a "First" and a "Second" reason correctly, but are missing required commas after each word (i.e., "First, ...", and "Second, ..." ) - S3, 5th para, 1st sentence is lacking commas here: "...FEC, yet are forwarded into an IP/MPLS network without being MPLS-encapsulated, present..." - S5.1, last bullet has this: "...MPLS encapsulation at a ingress LER ..." ^^^^^ s/a/an James From narten@us.ibm.com Thu Dec 9 21:51:42 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B963A69DB for ; Thu, 9 Dec 2010 21:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.923 X-Spam-Level: X-Spam-Status: No, score=-105.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uH8y25IB3rI for ; Thu, 9 Dec 2010 21:51:42 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id D93053A6C42 for ; Thu, 9 Dec 2010 21:51:41 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oBA5Zuqo018558 for ; Fri, 10 Dec 2010 00:35:56 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id DA085728047 for ; Fri, 10 Dec 2010 00:53:05 -0500 (EST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oBA5r5Lq176850 for ; Fri, 10 Dec 2010 00:53:05 -0500 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oBA5r5El012961 for ; Thu, 9 Dec 2010 22:53:05 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oBA5r4dc012947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Dec 2010 22:53:05 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id oBA5r48o005954 for ; Fri, 10 Dec 2010 00:53:04 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.4/8.14.4/Submit) id oBA5r2gM005832 for ietf@ietf.org; Fri, 10 Dec 2010 00:53:02 -0500 From: Thomas Narten Message-Id: <201012100553.oBA5r2gM005832@rotala.raleigh.ibm.com> Date: Fri, 10 Dec 2010 00:53:02 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 05:51:42 -0000 Total of 33 messages in the last 7 days. script run at: Fri Dec 10 00:53:02 EST 2010 Messages | Bytes | Who --------+------+--------+----------+------------------------ 9.09% | 3 | 10.17% | 23071 | l.wood@surrey.ac.uk 9.09% | 3 | 8.17% | 18544 | mrex@sap.com 9.09% | 3 | 5.86% | 13294 | francis.dupont@fdupont.fr 6.06% | 2 | 5.86% | 13306 | wesley.m.eddy@nasa.gov 6.06% | 2 | 5.85% | 13267 | turners@ieca.com 3.03% | 1 | 8.82% | 20024 | stpeter@stpeter.im 6.06% | 2 | 5.26% | 11941 | martin.thomson@andrew.com 3.03% | 1 | 5.28% | 11973 | ben@nostrum.com 3.03% | 1 | 5.16% | 11706 | ron.even.tlv@gmail.com 3.03% | 1 | 4.92% | 11163 | jeff.hodges@kingsmountain.com 3.03% | 1 | 3.89% | 8824 | sm@resistor.net 3.03% | 1 | 3.06% | 6952 | huitema@microsoft.com 3.03% | 1 | 3.03% | 6876 | jmpolk@cisco.com 3.03% | 1 | 2.71% | 6156 | hartmans-ietf@mit.edu 3.03% | 1 | 2.67% | 6070 | narten@us.ibm.com 3.03% | 1 | 2.60% | 5904 | ietf@adambarth.com 3.03% | 1 | 2.41% | 5462 | mcquilwp@pobox.com 3.03% | 1 | 2.30% | 5215 | samirs.lists@gmail.com 3.03% | 1 | 2.19% | 4966 | mnot@mnot.net 3.03% | 1 | 2.14% | 4848 | vesely@tana.it 3.03% | 1 | 2.04% | 4632 | shanna@juniper.net 3.03% | 1 | 1.90% | 4310 | gwz@net-zen.net 3.03% | 1 | 1.86% | 4218 | tme@americafree.tv 3.03% | 1 | 1.85% | 4208 | jari.arkko@piuha.net --------+------+--------+----------+------------------------ 100.00% | 33 |100.00% | 226930 | Total From evnikita2@gmail.com Fri Dec 10 06:28:08 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2DC28C0EE; Fri, 10 Dec 2010 06:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNjsCHMMoht1; Fri, 10 Dec 2010 06:28:07 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 0373428C0E6; Fri, 10 Dec 2010 06:28:06 -0800 (PST) Received: by bwz8 with SMTP id 8so4259180bwz.38 for ; Fri, 10 Dec 2010 06:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=jIdN4rs7RR2VU1+DVEl51BRtF8SLEG2YDUIxO2IBkCs=; b=E+qApaC9BatbS8xN3SLrKVtBFUDfrKsGZhzW4rVyT9K6R1F+lslFhDZwlfleOBk14c NxA9miSzuW7anQ6NeNIy+BY3acKc0QrbCkffGI1aapVexPD6aOlgKYppzwwh3QZD5NSp D0kBsgw8uSLKDBHCPy69mX0NCmtTbRpdyXVsc= 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=hrPE5kDVkNRG10i8alAAum7N2Lsm856j7MRXsKOItcdkJ38IGa9a7kOue2TgmFaTn9 EqIvIW1gSWTRqBXcz1x7j4Gkomlxri59Hiwy2p3IK9EXXplYBa4w1Qzpn25e1EnucZo6 dkRYD0yFBZCs4ZDUMj92YRvQ2O4HLWI/UJIe8= Received: by 10.204.113.65 with SMTP id z1mr785285bkp.86.1291991376945; Fri, 10 Dec 2010 06:29:36 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id q15sm1571910bkk.13.2010.12.10.06.29.35 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Dec 2010 06:29:36 -0800 (PST) Message-ID: <4D023959.3070604@gmail.com> Date: Fri, 10 Dec 2010 16:29:45 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: IETF Discussion , apps-discuss@ietf.org Subject: RE: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 10 Dec 2010 08:44:01 -0800 Cc: Bill McQuillan , Martin.Thomson@andrew.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 14:28:08 -0000 Hello all, I have get known that there is a discussion of my draft on this list (IETF-discuss). So some notes on what have been already posted: > > I wholly agree with Bill on this. > > You want something a little more complicated than you have already > specified: > > {n}^({a}){m}{e} => {e} {n-1}*{m ? m-n : ''}({a} {e}) ; where n > 0 > {e} *{m ? m-1 : ''}({a} {e}) ; where n == 0 or n undefined This is not what is mentioned in my draft. Especially in the case when n=0. > > Note the n == 0 is a special case. Note that this assumes that m > n. > There seems little point in this construction if m == 1, but this does > handle that case. If m=1, there is no need to use the defined construction. It is 1 and nothing else. > > Aside from those sorts of problems, the definition of 'a' is a little > loose. You should try to build on the RFC 5234 ABNF in your definitions. > > The proposed rule has an ABNF definition something like (?): > > hat-rule = 1*DIGIT "^(" a ")" 1*DIGIT > a = VCHAR / SP / HT / > > That's a lot of flexibility in the internal part. Too much > flexibility. Using parentheses means that they need to be > distinguished from the parentheses that might appear in the 'a' part. > > If you see this as a substitute for the "*" in a normal repetition > rule, that makes it easier. Given that it has length longer than 1 > character, by providing a clear delineation of the start and end you > can be more flexible on the content. Either that or to restrict what > follows the ^. > > Preferably delineate better AND restrict content: > > repeat /= hat-rule > hat-rule = *DIGIT "^" element "^" *DIGIT OK. It will be taken into consideration. > > This restricts the content without preventing the use of more complex > content - you just have to use a rulename instead. > > You can't use elements (note the 's') here because that sort of > complexity is a real pain to specify. What do you mean? > > That leaves examples: > > 1^";"^3element ; 1 to 3 elements separated by ; > 1^SP^element ; 1 or more elements separated by SP rule > ^","^3element ; 0 to 3 elements separated by , > ^%x20.20^element ; any number of elements separated by a two space > characters Will be corrected. > > You should try to answer the question in the draft: why use the '^' > character instead of the '#' character? I guess that this is an > arbitrary choice more than anything else. # is already used in RFC2616 and ^ is used in order to to make the conflict between these documents. > > --Martin > > On 2010-12-07 at 11:07:17, Bill McQuillan wrote: > > I found several problems with this draft. > > > > In overview, the reason that we removed the #rule from ABNF was that it > > was > > very difficult to specify for a general case. This draft has the same > > problem. > > > > The production given does not actually produce the desired results. > > > > > n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element)) > > > > If the usage is: > > > > 5^(",")10 "abc" > > > > it would allow something like: > > > > abc abc abc abc abc abc , abc > > > > not: > > > > abc, abc, abc, abc, abc, abc, abd > > > > which was probably intended. > > > > ----- > > > > The production: > > > > > a = VCHAR / SP / HT / > > > > does not seem to address the possibility of multi-character separators > > very > > clearly. What if I want to define a list like: > > > > abc and def and ghi and jkl > > > > can I use: > > > > ^(" and ")ident > > > > ----- > > > > I also do not believe that *FWS belongs in such a general rule and > > should > > rather be defined by the actual usage. E.g.: > > > > 5^(*FWS "," *FWS)10 "abc" > > > > ----- > > > > Typo: 2.1 Examples, fourth example should be: ^("-")element > > > > -- > > Bill McQuillan > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > Bill, All your propositions have been taken into consideration. These comments concern -01 draft. As for FWS, it is *element so it can be used and can not be used. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf I really believe that the construction I have used is acceptable for all cases. Now I am working on -03 version of the draft so I'll get known when it will become available. All the best, Mykyta Yevstifeyev From evnikita2@gmail.com Fri Dec 10 06:38:27 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89ABB28C0F7; Fri, 10 Dec 2010 06:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsjblSoTDRjF; Fri, 10 Dec 2010 06:38:26 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id C6F6D28C0F6; Fri, 10 Dec 2010 06:38:25 -0800 (PST) Received: by bwz8 with SMTP id 8so4270729bwz.38 for ; Fri, 10 Dec 2010 06:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=qGodP4I3OTSDF0BJ9/u/dszzNhoEyQTAYjQm+4K4GvU=; b=nTD7q7SxTLeiHlLPgPfNi7Vi1ihc/TFXwUyTusSnY5aTP6jKxMH9IrFPfGoEcQ7DnZ q5MLZUzbWeBWtgTXiYb2mBNHMq0yoFhjHZXmsfLhroVC4XxhcQd/AkvacZgK3PkVkk7P rmwrgyYwZcH9iRTLAb+qG9/bn/qwXhx9lKXQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=VpovOsgvUCbTpQjmyY9BbqBwtcqCzv06QwFLKawwPbkKGQEDVPR/RmXD+2NzE9RDrz ak2hpSUK8Te6jEpHs6oMeeNCUPmRsjtXdnsU7RjZc5y3mVaO6crguBuXmkpyxZG5lpkE eiqG262sRx2qd0HMaDOmjKw2/0ZToJDMxDYwU= Received: by 10.204.101.13 with SMTP id a13mr782373bko.119.1291991995052; Fri, 10 Dec 2010 06:39:55 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id d27sm1578859bkw.2.2010.12.10.06.39.53 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Dec 2010 06:39:54 -0800 (PST) Message-ID: <4D023BC3.9030006@gmail.com> Date: Fri, 10 Dec 2010 16:40:03 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: apps-discuss@ietf.org, IETF Discussion Subject: A new version of draft-yevstifeyev-abnf-separated-lists Content-Type: multipart/alternative; boundary="------------040400080704080608040207" X-Mailman-Approved-At: Fri, 10 Dec 2010 08:44:04 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 14:38:27 -0000 This is a multi-part message in MIME format. --------------040400080704080608040207 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, A new vesrion of draft-yevstifeyev-abnf-separated-lists is available (-03). It is available here: https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/ Almost all comments were taken into account. Any suggestions and comments are welcome. All the best, Mykyta Yevstifeyev --------------040400080704080608040207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello all,

A new vesrion of draft-yevstifeyev-abnf-separated-lists is available (-03).

It is available here:

https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/

Almost all comments were taken into account.

Any suggestions and comments are welcome.

All the best,
Mykyta Yevstifeyev
--------------040400080704080608040207-- From doug@ewellic.org Fri Dec 10 10:00:58 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BD228C104 for ; Fri, 10 Dec 2010 10:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8U5Y3vvfbfo for ; Fri, 10 Dec 2010 10:00:57 -0800 (PST) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by core3.amsl.com (Postfix) with SMTP id CE5993A6CB6 for ; Fri, 10 Dec 2010 10:00:57 -0800 (PST) Received: (qmail 21279 invoked from network); 10 Dec 2010 18:02:28 -0000 Received: from unknown (HELO localhost) (72.167.218.132) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 10 Dec 2010 18:02:28 -0000 Received: (qmail 30859 invoked by uid 99); 10 Dec 2010 18:02:28 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.190 User-Agent: Web-Based Email 5.3.00 Message-Id: <20101210110228.665a7a7059d7ee80bb4d670165c8327d.7d33a4a589.wbe@email03.secureserver.net> From: "Doug Ewell" To: "Mykyta Yevstifeyev" Subject: RE: A new version of draft-yevstifeyev-abnf-separated-lists Date: Fri, 10 Dec 2010 11:02:28 -0700 Mime-Version: 1.0 Cc: IETF Discussion , apps-discuss@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 18:00:58 -0000 Mykyta Yevstifeyev wrote: > A new vesrion of draft-yevstifeyev-abnf-separated-lists is available (-03= ). >=20 > It is available here: >=20 > https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/ This document includes: > Acknowledgments > > Many thanks to (in alphabetical order): Tony Hansen, Thomson Martin > and Barry Leiba for their weighty input to this document. This doesn't look like alphabetical order to me. Is the parenthetical comment really necessary when only three names are involved? -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s =C2=AD From turners@ieca.com Fri Dec 10 13:34:17 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1460B3A6CC5 for ; Fri, 10 Dec 2010 13:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAIpeCTUQQ+F for ; Fri, 10 Dec 2010 13:34:14 -0800 (PST) Received: from nm20-vm0.bullet.mail.sp2.yahoo.com (nm20-vm0.bullet.mail.sp2.yahoo.com [98.139.91.218]) by core3.amsl.com (Postfix) with SMTP id 545773A6CC2 for ; Fri, 10 Dec 2010 13:34:13 -0800 (PST) Received: from [98.139.91.67] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 10 Dec 2010 21:35:42 -0000 Received: from [98.139.91.17] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 10 Dec 2010 21:35:42 -0000 Received: from [127.0.0.1] by omp1017.mail.sp2.yahoo.com with NNFMP; 10 Dec 2010 21:35:42 -0000 X-Yahoo-Newman-Id: 185024.20397.bm@omp1017.mail.sp2.yahoo.com Received: (qmail 82061 invoked from network); 10 Dec 2010 21:35:42 -0000 Received: from thunderfish.local (turners@71.191.10.121 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 10 Dec 2010 13:35:40 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: VaGs1dYVM1nTssJ3ATlpXecsuQbtf6t.IlnNmBl.y61c0BK ngQj8lobUPKiB1.gJQt.DBJi3KBQSfTBMGmcfBPvQQUVz_aLI3gvUBKz2f9J 5Sb948RHjtBTN9ipLBQHhmGppDekeI0oY3gcO1Y.9WkazA8moNRNN41iRCjQ v_VPNTUS8T6JwbZqYxvpZSU9MzRwbE1MViKt0sqNCPHPa1KvZ2tvMHMwYBnK xJfRTeOqAjJjW9vfr8C7HJzeZfqveZxmBnunXfuFJNtI.Bz5lTGqb4z8XdLH 34pr0YrMnAQAPjc0TZrMnyIHxDn5nzuAtGQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D029D2B.9090900@ieca.com> Date: Fri, 10 Dec 2010 16:35:39 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] Last Call: References: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> <4CF952A2.2070904@ieca.com> In-Reply-To: <4CF952A2.2070904@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 21:34:18 -0000 On 12/3/10 3:27 PM, Sean Turner wrote: > On 12/3/10 2:58 PM, Martin Rex wrote: >> Glen Zorn wrote: >>> >>> Martin Rex wrote: >>>> >>>> Glen Zorn wrote: >>>>> >>>>> Maybe I just don't understand the word "use". It seems like if a >>>>> server accepts a protocol message it's using the protocol... >>>> >>>> With "negotiate" I meant returning a ServerHello handshake message with >>>> that version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 >>>> ServerHello with a server version of { 0x02,0x00 }). >>>> >>>> With "use" I meant to successfully complete the handshake and start >>>> exchanging application data protected under protocol version >>>> {0x02,0x00}. >>> >>> Maybe you could spell these things out in the draft just as you have >>> above? >> >> I'm sorry, my explanations were misleading. I explained what I meant >> when I wrote these statements that ended up in the document. >> >> http://www.ietf.org/mail-archive/web/tls/current/msg07091.html >> >> The author/editor of this I-D is Sean Turner. > > I've got no problem with providing additional clarifying text. How about > we add the following (some minor tweaks to what you suggested) to > explain what we mean by use and negotiate (send seems clear): > > "negotiate" means returning a ServerHello handshake message with that > version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 > ServerHello with a server version of { 0x02,0x00 }). > > "use" means to successfully complete the handshake and start exchanging > application data protected under protocol version {0x02,0x00}. So it's been proposed that I better integrate the text after the bullets into the bullets and better explain negotiate and use. I'm game. For the client, all I've ever wanted to do is change the "TLS 1.2 clients SHOULD NOT support SSL 2.0" to a MUST NOT. For me, client support meant sending SSL 2.0 CLIENT-HELLO, accepting SSL 2.0 SERVER-HELLO, and then proceeding using SSL 2.0 records. I can see that people might not make the leap that client support meant accepting the SSL 2.0 SERVER-HELLO and using SSL 2.0 records because the above-quoted sentence was in a warning that discussed 2.0 CLIENT-HELLOs. For servers, my thinking has evolved. I'm now at the point where I'd like to have TLS servers not have to support SSL 2.0 SERVER-HELLOs and SSL 2.0 records after the handshake (RFC 5246 is clear that TLS 1.*/SSLv3 servers can accept a SSL 2.0 CLIENT-HELLO). If we prohibited TLS client's sending SSL 2.0 CLIENT-HELLO and TLS servers sending SSL 2.0 SERVER-HELLO, then I'd be happy because clients won't send SSL 2.0, servers won't respond with SSL 2.0, and therefore clients won't end up agreeing to send SSL 2.0 records and the server won't have to do SSL 2.0 records. How the following replacement text for Section 3: Because of the deficiencies noted in the previous section: * TLS Clients MUST NOT propose SSL 2.0 to a TLS server by sending an initial SSL 2.0 CLIENT-HELLO handshake message with protocol version { 0x02, 0x00 }. * According to [RFC5246] Appendix E.2, TLS Servers, even when not implementing SSL 2.0, MAY accept an initial SSL 2.0 CLIENT-HELLO as the first handshake message of a SSLv3 or TLS handshake. [RFC5246] allowed TLS servers to respond with a SSL 2.0 SERVER-HELLO message. This is no longer allowed. That is, TLS Servers MUST NOT reply with a SSL 2.0 SERVER-HELLO with a protocol version of { 0x02, 0x00 } and instead MUST abort the connection, i.e., when the highest protocol version offered by the client is { 0x02, 0x00 } the TLS connection will be refused. Note that the number of servers that support this above-mentioned "MAY accept" implementation option is declining, and the SSL 2.0 CLIENT-HELLO precludes the use of TLS protocol enhancements that require TLS extensions. TLS extensions can only be sent as part of an (Extended) ClientHello handshake message. spt From mnot@mnot.net Fri Dec 10 14:50:39 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62BBD28C158; Fri, 10 Dec 2010 14:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.603 X-Spam-Level: X-Spam-Status: No, score=-104.603 tagged_above=-999 required=5 tests=[AWL=-2.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiEA5AR+J-wQ; Fri, 10 Dec 2010 14:50:38 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 521F828C101; Fri, 10 Dec 2010 14:50:38 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0CB6922E1F4; Fri, 10 Dec 2010 17:52:03 -0500 (EST) Subject: Re: New Non-WG Mailing List: Cdni -- Interconnection of Content Delivery Networks (CDNs) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <20101210185637.29C8828C143@core3.amsl.com> Date: Sat, 11 Dec 2010 09:52:01 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <20101210185637.29C8828C143@core3.amsl.com> To: IETF Secretariat X-Mailer: Apple Mail (2.1082) Cc: flefauch@cisco.com, The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 22:50:39 -0000 I'm confused. http://www.ietf.org/wg/concluded/cdi.html is this a resurrection of the old WG? Why not reuse the list? On 11/12/2010, at 5:56 AM, IETF Secretariat wrote: > A new IETF non-working group email list has been created. > > List address: cdni@ietf.org > Archive: http://www.ietf.org/mail-archive/web/cdni/ > To subscribe: https://www.ietf.org/mailman/listinfo/cdni > > Description: There is an emerging requirement for interconnecting content > delivery networks (CDNs) so they can interoperate as an open content > delivery infrastructure for the end-to-end delivery of content from > Content Service Providers (CSPs) to end users. This list is to discuss the > proposed development of IETF standards to facilitate such CDN > interconnection. These standards might include protocols for > > 1) exchange of metadata between CDNs, > 2) exchange of transaction logs > 3) exchange of monitoring information > 4) exchange of policies & capabilities, and > 5) content management/flushing > > For additional information, please contact the list administrators. > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce -- Mark Nottingham http://www.mnot.net/ From d3e3e3@gmail.com Fri Dec 10 17:00:53 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F7B28C158; Fri, 10 Dec 2010 17:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.105 X-Spam-Level: X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRzW7CTdLXlV; Fri, 10 Dec 2010 17:00:52 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 0864528C118; Fri, 10 Dec 2010 17:00:51 -0800 (PST) Received: by wyf23 with SMTP id 23so4125351wyf.31 for ; Fri, 10 Dec 2010 17:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u7lRdjuVq9l8uiOaPR1XmWRgNHnVuGaBq4TRZDrKau4=; b=iQECOg1JyfCPONWsFYBezei4pcjW0nMrIgSWp4960rQwsVToSdOvqpiSJe0Dj0Wgdj 3Od1/rG5pSCn5eaYP46MT1h9fX1Zch50x0zWeK8LYrKmVpVABqkQQj5ZJZzmlyqBY9yk IShCtVIEgfSN2ehCKI70CdQA1FJdIPrJb6GCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AE5t0H26c0tVwjBCpQbDgoEUaUvsfGld9+F8a7paRYaZPHVn4Zj7mnaWeL7dCbwEtN hsedIsW356Q/mT+6YfwJMqmNXfLlLVqGGma4VL2RGzFqzmscs+KcNNMrkf1j5iIUTvGb oWtUPVIY+lcnODKdTTQOY0FaojOCgMEiAuNNk= MIME-Version: 1.0 Received: by 10.227.167.8 with SMTP id o8mr81121wby.166.1292029343126; Fri, 10 Dec 2010 17:02:23 -0800 (PST) Received: by 10.227.153.8 with HTTP; Fri, 10 Dec 2010 17:02:23 -0800 (PST) In-Reply-To: <20101210110228.665a7a7059d7ee80bb4d670165c8327d.7d33a4a589.wbe@email03.secureserver.net> References: <20101210110228.665a7a7059d7ee80bb4d670165c8327d.7d33a4a589.wbe@email03.secureserver.net> Date: Fri, 10 Dec 2010 20:02:23 -0500 Message-ID: Subject: Re: A new version of draft-yevstifeyev-abnf-separated-lists From: Donald Eastlake To: Doug Ewell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Discussion , apps-discuss@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 01:00:53 -0000 On Fri, Dec 10, 2010 at 1:02 PM, Doug Ewell wrote: > Mykyta Yevstifeyev wrote: > >... > >> Acknowledgments >> >> =A0 =A0Many thanks to (in alphabetical order): Tony Hansen, Thomson Mart= in >> =A0 =A0and Barry Leiba for their weighty input to this document. > > This doesn't look like alphabetical order to me. =A0... Isn't it obvious? They are in inverse alphabetic order by first name. > Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org > RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s =AD Donald From gwz@net-zen.net Fri Dec 10 19:32:55 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71BCD3A6CBF for ; Fri, 10 Dec 2010 19:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2WPmEbZZXnO for ; Fri, 10 Dec 2010 19:32:54 -0800 (PST) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id D0B5E3A6C20 for ; Fri, 10 Dec 2010 19:32:53 -0800 (PST) Received: (qmail 25649 invoked from network); 11 Dec 2010 03:34:25 -0000 Received: from unknown (124.122.184.73) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 11 Dec 2010 03:34:24 -0000 From: "Glen Zorn" To: "'Sean Turner'" References: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> <4CF952A2.2070904@ieca.com> <4D029D2B.9090900@ieca.com> In-Reply-To: <4D029D2B.9090900@ieca.com> Subject: RE: [TLS] Last Call: Date: Sat, 11 Dec 2010 10:34:04 +0700 Organization: Network Zen Message-ID: <000601cb98e4$453ca980$cfb5fc80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuYsjKOzaswq6UsQFqLxJ8pj+jS4AAMf1VQ Content-Language: en-us Cc: tls@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 03:32:56 -0000 Looks good to me. Hope this helps. ~gwz > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Saturday, December 11, 2010 4:36 AM > To: tls@ietf.org; ietf@ietf.org > Cc: mrex@sap.com; Glen Zorn > Subject: Re: [TLS] Last Call: > > On 12/3/10 3:27 PM, Sean Turner wrote: > > On 12/3/10 2:58 PM, Martin Rex wrote: > >> Glen Zorn wrote: > >>> > >>> Martin Rex wrote: > >>>> > >>>> Glen Zorn wrote: > >>>>> > >>>>> Maybe I just don't understand the word "use". It seems like if a > >>>>> server accepts a protocol message it's using the protocol... > >>>> > >>>> With "negotiate" I meant returning a ServerHello handshake message > with > >>>> that version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 > >>>> ServerHello with a server version of { 0x02,0x00 }). > >>>> > >>>> With "use" I meant to successfully complete the handshake and start > >>>> exchanging application data protected under protocol version > >>>> {0x02,0x00}. > >>> > >>> Maybe you could spell these things out in the draft just as you have > >>> above? > >> > >> I'm sorry, my explanations were misleading. I explained what I meant > >> when I wrote these statements that ended up in the document. > >> > >> http://www.ietf.org/mail-archive/web/tls/current/msg07091.html > >> > >> The author/editor of this I-D is Sean Turner. > > > > I've got no problem with providing additional clarifying text. How > about > > we add the following (some minor tweaks to what you suggested) to > > explain what we mean by use and negotiate (send seems clear): > > > > "negotiate" means returning a ServerHello handshake message with that > > version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 > > ServerHello with a server version of { 0x02,0x00 }). > > > > "use" means to successfully complete the handshake and start > exchanging > > application data protected under protocol version {0x02,0x00}. > > So it's been proposed that I better integrate the text after the bullets > into the bullets and better explain negotiate and use. I'm game. > > For the client, all I've ever wanted to do is change the "TLS 1.2 > clients SHOULD NOT support SSL 2.0" to a MUST NOT. For me, client > support meant sending SSL 2.0 CLIENT-HELLO, accepting SSL 2.0 > SERVER-HELLO, and then proceeding using SSL 2.0 records. I can see that > people might not make the leap that client support meant accepting the > SSL 2.0 SERVER-HELLO and using SSL 2.0 records because the above-quoted > sentence was in a warning that discussed 2.0 CLIENT-HELLOs. > > For servers, my thinking has evolved. I'm now at the point where I'd > like to have TLS servers not have to support SSL 2.0 SERVER-HELLOs and > SSL 2.0 records after the handshake (RFC 5246 is clear that TLS > 1.*/SSLv3 servers can accept a SSL 2.0 CLIENT-HELLO). > > If we prohibited TLS client's sending SSL 2.0 CLIENT-HELLO and TLS > servers sending SSL 2.0 SERVER-HELLO, then I'd be happy because clients > won't send SSL 2.0, servers won't respond with SSL 2.0, and therefore > clients won't end up agreeing to send SSL 2.0 records and the server > won't have to do SSL 2.0 records. > > How the following replacement text for Section 3: > > Because of the deficiencies noted in the previous section: > > * TLS Clients MUST NOT propose SSL 2.0 to a TLS server by sending > an initial SSL 2.0 CLIENT-HELLO handshake message with protocol > version { 0x02, 0x00 }. > > * According to [RFC5246] Appendix E.2, TLS Servers, even when not > implementing SSL 2.0, MAY accept an initial SSL 2.0 CLIENT-HELLO > as the first handshake message of a SSLv3 or TLS handshake. > > [RFC5246] allowed TLS servers to respond with a SSL 2.0 > SERVER-HELLO message. This is no longer allowed. That is, TLS > Servers MUST NOT reply with a SSL 2.0 SERVER-HELLO with a protocol > version of { 0x02, 0x00 } and instead MUST abort the connection, > i.e., when the highest protocol version offered by the client is > { 0x02, 0x00 } the TLS connection will be refused. > > Note that the number of servers that support this above-mentioned "MAY > accept" implementation option is declining, and the SSL 2.0 CLIENT-HELLO > precludes the use of TLS protocol enhancements that require TLS > extensions. TLS extensions can only be sent as part of an (Extended) > ClientHello handshake message. > > spt From Francis.Dupont@fdupont.fr Sat Dec 11 05:19:17 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5643A6ADF; Sat, 11 Dec 2010 05:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqWQ0e8Se-bf; Sat, 11 Dec 2010 05:19:15 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id B215F3A6D21; Sat, 11 Dec 2010 05:18:37 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id oBBDK9uK092902; Sat, 11 Dec 2010 13:20:10 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201012111320.oBBDK9uK092902@givry.fdupont.fr> From: Francis Dupont Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC In-reply-to: Your message of Thu, 09 Dec 2010 23:00:46 +0100. <201012092200.oB9M0kJL049458@givry.fdupont.fr> Date: Sat, 11 Dec 2010 14:20:09 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "wes@mti-systems.com" , "ietf@ietf.org" , "iesg@ietf.org" , "L.Wood@surrey.ac.uk" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 13:19:17 -0000 I add a third option: enforce the fact the document is about "security considerations" and add nothing about not security uses, one way or the other. Regards Francis.Dupont@fdupont.fr From evnikita2@gmail.com Mon Dec 13 06:06:59 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D377B3A6E95; Mon, 13 Dec 2010 06:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNwGYBYF8vk6; Mon, 13 Dec 2010 06:06:59 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 4E65F3A6D9D; Mon, 13 Dec 2010 06:06:58 -0800 (PST) Received: by bwz8 with SMTP id 8so7057149bwz.38 for ; Mon, 13 Dec 2010 06:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=PamuDMvVneTnBLNtrFzkbr3eej5QFfmPta4v7dSoSaA=; b=dfmrTP0ijHd+RaWdV4S0+xvqXy8SM6CrMnPYo/tILkDNfzbLx2oNFUG/JpmYjQiKO5 4W07bJlzE2e6CTQm3qc++HheFvoBTbmU2sqAvomeHJ/WLU/bUjMX3sSu6InsyXBiAN/H 3fj0JY2JxOTO2hDRAGzw8yDYYeOOxZrlCFPmU= 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=NkSKkj/AHyrtqdwDABLo+hjogSVfEi6hd9dRROLhoLp60jV5Czx+K76BTxAnvyfNcJ fp2lY0A/PGsoTBCpsl9RS0Hyavx+654pN1/zyZp0EWzPxns7Gco0uy8+x9M46hB49a7g Mg1MSSEixoAkE+53nrbRdfD9xtuaL91ibsZ94= Received: by 10.204.59.9 with SMTP id j9mr3713422bkh.68.1292249315303; Mon, 13 Dec 2010 06:08:35 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id j11sm90657bka.12.2010.12.13.06.08.33 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 06:08:34 -0800 (PST) Message-ID: <4D0628EC.4080903@gmail.com> Date: Mon, 13 Dec 2010 16:08:44 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC References: <20101213132808.2379.30041.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, ietf@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 14:06:59 -0000 Hello all, [To HYBI list members: I am sending the copy of the letter to your list following the advice of L. Wood (see below).] L. Wood, the reference you have mentioned does not seem to concern ti Content-* headers. Moreover, HTTP clients are not able to generate answer codes, but only requests. This makes your proposal impossible to implement. Secondly, proxies usually do not generate separate requests to HTTP servers but only pass them through. So this will not make any problems. Best regards, Mykyta Yevstifeyev 13.12.2010 16:00, L.Wood@surrey.ac.uk wrote: > This draft does not discuss the Content-* rule. Content-* headers are special, in that they may not be ignored (section 9.6 of [RFC2616]). Recipients not understanding Content-blah: will generate a "501 (Not Implemented)" error code. That overrides the proposal below, I think. > > The proposal in the draft doesn't appear to work with proxies, which often may be passing through headers that they themselves don't understand. > > This draft does not appear to be associated with a working group. I suggest discussing this on the hybi mailing list; it's a little offtopic, but a bunch of http experts do read that list and can offer comments. > > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: 13 December 2010 13:28 > To: IETF-Announce > Subject: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC > > > The IESG has received a request from an individual submitter to consider the following document: > - ''Headers-Not-Recognized' HTTP Header Field' > as an Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-01-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/ > > > 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 > From marsh@extendedsubset.com Fri Dec 10 15:07:52 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9BE228C170; Fri, 10 Dec 2010 15:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0bONNl1Bq7S; Fri, 10 Dec 2010 15:07:49 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id D5FD328C18C; Fri, 10 Dec 2010 15:07:48 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PRC5Z-000D9R-0B; Fri, 10 Dec 2010 23:09:21 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 28EB660C7; Fri, 10 Dec 2010 23:09:19 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+nLlMPekWHiYXeDpreLClZciN1UEd3EQs= Message-ID: <4D02B31D.8010906@extendedsubset.com> Date: Fri, 10 Dec 2010 17:09:17 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Sean Turner Subject: Re: [TLS] Last Call: References: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> <4CF952A2.2070904@ieca.com> <4D029D2B.9090900@ieca.com> In-Reply-To: <4D029D2B.9090900@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 07:29:05 -0800 Cc: tls@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 23:07:52 -0000 On 12/10/2010 03:35 PM, Sean Turner wrote: > On 12/3/10 3:27 PM, Sean Turner wrote: >> >> "negotiate" means returning a ServerHello handshake message with that >> version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 >> ServerHello with a server version of { 0x02,0x00 }). >> >> "use" means to successfully complete the handshake and start exchanging >> application data protected under protocol version {0x02,0x00}. How could you ever "use" it without "negotiating" it first? It seems like a distinction without a difference in this document. > So it's been proposed that I better integrate the text after the bullets > into the bullets and better explain negotiate and use. I'm game. > > For the client, all I've ever wanted to do is change the "TLS 1.2 > clients SHOULD NOT support SSL 2.0" to a MUST NOT. Sounds good to me. > For me, client > support meant sending SSL 2.0 CLIENT-HELLO, accepting SSL 2.0 > SERVER-HELLO, and then proceeding using SSL 2.0 records. I can see that > people might not make the leap that client support meant accepting the > SSL 2.0 SERVER-HELLO and using SSL 2.0 records because the above-quoted > sentence was in a warning that discussed 2.0 CLIENT-HELLOs. >RFC2246: TLS 1.0 clients that support SSL Version 2.0 servers >RFC2246: must send SSL Version 2.0 client hello messages [SSL2]. IMHO, this is statement on its own is ambiguous to the point of being wrong. The problem is that is muddies up the essential distinction: The term "SSL Version 2.0" refers to a completely different thing than an "SSLv2-format compatible Client Hello message". But it is cleared up in subsequent wording: >RFC 2246: TLS servers should accept either client hello format if This uses the word "format" to make that critical distinction. RFC2246: they wish to support SSL 2.0 clients on the same RFC2246: connection port. The only deviations from the Version 2.0 RFC2246: specification are the ability to specify a version with a RFC2246: value of three and the support for more ciphering types RFC2246: in the CipherSpec. It's really imprecise to talk about a "Version 2.0 Client Hello" message because one of the primary purposes of the initial hello message exchange is to negotiate exactly which protocol will be used for all subsequent messages (i.e., the "protocol version"). The Client Hello, in effect, has its own protocol version which has evolved somewhat independently over the years: SSLv2 SSLv2 with SCSV SSLv3/TLS SSLv3/TLS with SCSV SSLv3/TLS with extensions > For servers, my thinking has evolved. I'm now at the point where I'd > like to have TLS servers not have to support SSL 2.0 SERVER-HELLOs and > SSL 2.0 records after the handshake (RFC 5246 is clear that TLS > 1.*/SSLv3 servers can accept a SSL 2.0 CLIENT-HELLO). Isn't an "SSL 2.0 SERVER-HELLO" is equivalent to negotiating the use of the SSL 2.0 protocol? Isn't that the thing for which we're trying to put the final nail in the coffin? > If we prohibited TLS client's sending SSL 2.0 CLIENT-HELLO and TLS > servers sending SSL 2.0 SERVER-HELLO, then I'd be happy because clients > won't send SSL 2.0, servers won't respond with SSL 2.0, and therefore > clients won't end up agreeing to send SSL 2.0 records and the server > won't have to do SSL 2.0 records. Really all you have to do is prohibit the client from sending an SSLv2-compatible client hello. It may not hurt to reiterate that this implies that the server will not be subsequently negotiating the use of SSL 2.0 either. But the client hello messages and the server hello messages have completely different considerations, so there's no point in trying to make the language symmetric. > How the following replacement text for Section 3: > > Because of the deficiencies noted in the previous section: > > * TLS Clients MUST NOT propose SSL 2.0 to a TLS server by sending > an initial SSL 2.0 CLIENT-HELLO handshake message with protocol > version { 0x02, 0x00 }. How about "TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-HELLO message format. Clients MUST NOT send any client hello message which specifies a protocol version less than { 0x03, 0x00 }. As previously stated by the definitions of all previous versions of TLS, the client SHOULD specify the highest protocol version it supports." > * According to [RFC5246] Appendix E.2, TLS Servers, even when not > implementing SSL 2.0, MAY accept an initial SSL 2.0 CLIENT-HELLO > as the first handshake message of a SSLv3 or TLS handshake. "TLS servers MAY continue to accept client hello messages in the version 2 client hello format as specified in TLS [RFC2246]. Note that this does not contradict the prohibition against actually negotiating the use of SSL 2.0." > [RFC5246] allowed TLS servers to respond with a SSL 2.0 > SERVER-HELLO message. I don't see where it says that explicitly. I would have interpreted RFC5246 as being mostly irrelevant once each endpoint learns that the highest mutually-supported version was something less than TLS 1.2. AFAICT, this is the first document in the SSL/TLS evolution that attempts to mandate behavior WRT earlier versions of the protocol. > This is no longer allowed. That is, TLS > Servers MUST NOT reply with a SSL 2.0 SERVER-HELLO with a protocol > version of { 0x02, 0x00 } and instead MUST abort the connection, > i.e., when the highest protocol version offered by the client is > { 0x02, 0x00 } the TLS connection will be refused. Would "is less than { 0x03, 0x00 }" be a better condition? Not that many clients are likely to send { 0x02, 0xFF }, but we might as well prohibit it. - Marsh From flefauch@cisco.com Sun Dec 12 06:58:18 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2739C3A6DC8; Sun, 12 Dec 2010 06:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.71 X-Spam-Level: X-Spam-Status: No, score=-9.71 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mLRPyX4v3jP; Sun, 12 Dec 2010 06:58:16 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7B14E3A6CB5; Sun, 12 Dec 2010 06:58:15 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.59,332,1288569600"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="15105593" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 12 Dec 2010 14:59:50 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oBCExnqe016459; Sun, 12 Dec 2010 14:59:49 GMT Subject: Re: New Non-WG Mailing List: Cdni -- Interconnection of Content Delivery Networks (CDNs) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-39-326187764 From: Francois Le Faucheur In-Reply-To: Date: Sun, 12 Dec 2010 16:00:00 +0100 Message-Id: <4AB3C974-3419-40B2-B566-2C0005748A91@cisco.com> References: <20101210185637.29C8828C143@core3.amsl.com> To: Mark Nottingham X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Mon, 13 Dec 2010 07:29:05 -0800 Cc: Francois Le Faucheur , IETF Secretariat , The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 14:58:18 -0000 --Apple-Mail-39-326187764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Mark, We did discuss this.=20 While CDI did very relevant work, it was argued that we may not = necessarily resume from exactly where they left it. And, if the IETF = does decide to take on that work, it is to be discussed and decided = whether this should be considered a resurrection of the concluded CDI WG = or creation of a new WG. So it was felt that using a different name would give more flexibility. Cheers Francois On 10 Dec 2010, at 23:52, Mark Nottingham wrote: > I'm confused.=20 >=20 > http://www.ietf.org/wg/concluded/cdi.html >=20 > is this a resurrection of the old WG? Why not reuse the list? >=20 >=20 > On 11/12/2010, at 5:56 AM, IETF Secretariat wrote: >=20 >> A new IETF non-working group email list has been created. >>=20 >> List address: cdni@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/cdni/ >> To subscribe: https://www.ietf.org/mailman/listinfo/cdni >>=20 >> Description: There is an emerging requirement for interconnecting = content >> delivery networks (CDNs) so they can interoperate as an open content >> delivery infrastructure for the end-to-end delivery of content from >> Content Service Providers (CSPs) to end users. This list is to = discuss the >> proposed development of IETF standards to facilitate such CDN >> interconnection. These standards might include protocols for >>=20 >> 1) exchange of metadata between CDNs, >> 2) exchange of transaction logs >> 3) exchange of monitoring information >> 4) exchange of policies & capabilities, and >> 5) content management/flushing >>=20 >> For additional information, please contact the list administrators. >>=20 >>=20 >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-39-326187764 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-40-326187764 --Apple-Mail-40-326187764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = Mark,

We did discuss this. 
While CDI = did very relevant work, it was argued that we may not necessarily resume = from exactly where they left it. And, if the IETF does decide to take on = that work, it is to be discussed and decided whether this should be = considered a resurrection of the concluded CDI WG or creation of a new = WG.
So it was felt that using a different name would = give more = flexibility.

Cheers

Fran= cois

On 10 Dec 2010, at 23:52, Mark Nottingham = wrote:

I'm confused.

http://www.ietf.org/wg/= concluded/cdi.html

is this a resurrection of the old WG? Why = not reuse the list?


On 11/12/2010, at 5:56 AM, IETF = Secretariat wrote:

A new IETF = non-working group email list has been = created.

List address: = cdni@ietf.org
Archive: = http://www.ietf.org/mail-archive/web/cdni/
To subscribe: = https://www.ietf.org/mailman/listinfo/cdni

Description: = There is an emerging requirement for interconnecting = content
delivery networks = (CDNs) so they can interoperate as an open = content
delivery = infrastructure for the end-to-end delivery of content = from
Content Service Providers = (CSPs) to end users. This list is to discuss = the
proposed development of = IETF standards to facilitate such CDN
interconnection. These standards might include protocols = for

1) exchange of metadata between = CDNs,
2) exchange of = transaction logs
3) exchange = of monitoring information
4) = exchange of policies & capabilities, and
5) content management/flushing

For additional = information, please contact the list = administrators.



_______________________________________________
IETF-Announce mailing = list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--
Mark Nottingham =   http://www.mnot.net/



<= br>


Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-40-326187764 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-40-326187764-- --Apple-Mail-39-326187764-- From L.Wood@surrey.ac.uk Mon Dec 13 05:58:27 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9EC3A6E8E; Mon, 13 Dec 2010 05:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id folVoZgsUlpy; Mon, 13 Dec 2010 05:58:26 -0800 (PST) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 9D5DE3A6D9E; Mon, 13 Dec 2010 05:58:25 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-12.tower-78.messagelabs.com!1292248802!48393541!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 1808 invoked from network); 13 Dec 2010 14:00:02 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-12.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 13 Dec 2010 14:00:02 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Mon, 13 Dec 2010 14:00:02 +0000 From: To: , Date: Mon, 13 Dec 2010 14:00:01 +0000 Subject: RE: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC Thread-Topic: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC Thread-Index: AcuayfE8T/y4Eq7qQlmztRlanfNlIQAAIrbQ Message-ID: References: <20101213132808.2379.30041.idtracker@localhost> In-Reply-To: <20101213132808.2379.30041.idtracker@localhost> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 13 Dec 2010 07:29:05 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 13:58:27 -0000 This draft does not discuss the Content-* rule. Content-* headers are speci= al, in that they may not be ignored (section 9.6 of [RFC2616]). Recipients= not understanding Content-blah: will generate a "501 (Not Implemented)" er= ror code. That overrides the proposal below, I think. The proposal in the draft doesn't appear to work with proxies, which often = may be passing through headers that they themselves don't understand. This draft does not appear to be associated with a working group. I suggest= discussing this on the hybi mailing list; it's a little offtopic, but a bu= nch of http experts do read that list and can offer comments. -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of The IESG Sent: 13 December 2010 13:28 To: IETF-Announce Subject: Last Call: = ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC The IESG has received a request from an individual submitter to consider th= e following document: - ''Headers-Not-Recognized' HTTP Header Field' as an Experimental= RFC The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2011-01-14. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recogniz= ed/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recogniz= ed/ 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 From julian.reschke@gmx.de Mon Dec 13 08:18:06 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6B928C0DC for ; Mon, 13 Dec 2010 08:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.801 X-Spam-Level: X-Spam-Status: No, score=-105.801 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOdL78Ft6lZ6 for ; Mon, 13 Dec 2010 08:18:05 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 4171128C0D0 for ; Mon, 13 Dec 2010 08:18:04 -0800 (PST) Received: (qmail invoked by alias); 13 Dec 2010 16:19:41 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp049) with SMTP; 13 Dec 2010 17:19:41 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+1dMde4BW1MJMqB8arzzbl0JO/vkEsYhegHxeEV9 EWD15Y3RUkWpV0 Message-ID: <4D06479A.7020809@gmx.de> Date: Mon, 13 Dec 2010 17:19:38 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC References: <20101213132808.2379.30041.idtracker@localhost> <4D0628EC.4080903@gmail.com> In-Reply-To: <4D0628EC.4080903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf@ietf.org, L.Wood@surrey.ac.uk X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 16:18:06 -0000 un-cc'ing IESG and Hybi... On 13.12.2010 15:08, Mykyta Yevstifeyev wrote: > Hello all, > > [To HYBI list members: I am sending the copy of the letter to your list > following the advice of L. Wood (see below).] > > L. Wood, the reference you have mentioned does not seem to concern ti > Content-* headers. Moreover, HTTP clients are not able to generate > answer codes, but only requests. This makes your proposal impossible to > implement. "Recipient" as in "the server receiving". > Secondly, proxies usually do not generate separate requests to HTTP > servers but only pass them through. So this will not make any problems. But there are hop-by-hop headers and end-to-end headers. Also, they *do* generate their own request, for instance to validate an etag. > Best regards, > Mykyta Yevstifeyev > > 13.12.2010 16:00, L.Wood@surrey.ac.uk wrote: >> This draft does not discuss the Content-* rule. Content-* headers are >> special, in that they may not be ignored (section 9.6 of [RFC2616]). >> Recipients not understanding Content-blah: will generate a "501 (Not >> Implemented)" error code. That overrides the proposal below, I think. >> >> The proposal in the draft doesn't appear to work with proxies, which >> often may be passing through headers that they themselves don't >> understand. >> >> This draft does not appear to be associated with a working group. I >> suggest discussing this on the hybi mailing list; it's a little >> offtopic, but a bunch of http experts do read that list and can offer >> comments. I'm sure the Hybi mailing list will be excited. Pick one of ietf-discuss (we're in LC anyway), apps-discuss, or HTTPbis. Best regards, Julian From turners@ieca.com Mon Dec 13 11:44:03 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C663D28C0EB for ; Mon, 13 Dec 2010 11:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go2c-HPiNMyz for ; Mon, 13 Dec 2010 11:44:02 -0800 (PST) Received: from nm26.bullet.mail.ac4.yahoo.com (nm26.bullet.mail.ac4.yahoo.com [98.139.52.223]) by core3.amsl.com (Postfix) with SMTP id 9CCBE28C116 for ; Mon, 13 Dec 2010 11:44:02 -0800 (PST) Received: from [98.139.52.191] by nm26.bullet.mail.ac4.yahoo.com with NNFMP; 13 Dec 2010 19:45:38 -0000 Received: from [98.139.52.184] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 13 Dec 2010 19:45:38 -0000 Received: from [127.0.0.1] by omp1067.mail.ac4.yahoo.com with NNFMP; 13 Dec 2010 19:45:38 -0000 X-Yahoo-Newman-Id: 303260.58500.bm@omp1067.mail.ac4.yahoo.com Received: (qmail 71627 invoked from network); 13 Dec 2010 19:45:37 -0000 Received: from thunderfish.local (turners@96.241.0.81 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 13 Dec 2010 11:45:37 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 0GY8xAgVM1lj2tp5K8BiPYAVSWBgzCMlt3fONclSXIFeZrU Nx4_ziBt9Xbgp7m86pNOJd.ClRXTHNUZUADm0tqdT4ull3ieC.a.YRvrOo3a w3mgTJZSGOKXukEhhXKwXXYFP4Ya1D6VbCKzB4yok_NRMffg7RT9JqVC6D.M HDtu6FsCHX9Gkl1jwOE4Ik12RCIdOkWZuL7Jx7CuC3y8e4Gh8bAsKuDP8NtX bkXaWGmnnrpn3Z.LJTbkHsfXt9BGwdDrdbAoKwPayeXgM.UBkqIUesfnxOO3 NXwNNK.OMMekP7Ew4KviCl5F6gaQxG4qKM8hQVCT90XgpiEEA7IaheCLimIe DLCSXlCdhBkf95eFjTykdGeFtqfqbso.oBLVByJ1_g4c- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D0677E0.4010009@ieca.com> Date: Mon, 13 Dec 2010 14:45:36 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marsh Ray Subject: Re: [TLS] Last Call: References: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> <4CF952A2.2070904@ieca.com> <4D029D2B.9090900@ieca.com> <4D02B31D.8010906@extendedsubset.com> In-Reply-To: <4D02B31D.8010906@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 19:44:03 -0000 On 12/10/10 6:09 PM, Marsh Ray wrote: > On 12/10/2010 03:35 PM, Sean Turner wrote: >> On 12/3/10 3:27 PM, Sean Turner wrote: >>> >>> "negotiate" means returning a ServerHello handshake message with that >>> version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3 >>> ServerHello with a server version of { 0x02,0x00 }). >>> >>> "use" means to successfully complete the handshake and start exchanging >>> application data protected under protocol version {0x02,0x00}. > > How could you ever "use" it without "negotiating" it first? > It seems like a distinction without a difference in this document. > >> So it's been proposed that I better integrate the text after the bullets >> into the bullets and better explain negotiate and use. I'm game. >> >> For the client, all I've ever wanted to do is change the "TLS 1.2 >> clients SHOULD NOT support SSL 2.0" to a MUST NOT. > > Sounds good to me. > >> For me, client >> support meant sending SSL 2.0 CLIENT-HELLO, accepting SSL 2.0 >> SERVER-HELLO, and then proceeding using SSL 2.0 records. I can see that >> people might not make the leap that client support meant accepting the >> SSL 2.0 SERVER-HELLO and using SSL 2.0 records because the above-quoted >> sentence was in a warning that discussed 2.0 CLIENT-HELLOs. > > >RFC2246: TLS 1.0 clients that support SSL Version 2.0 servers > >RFC2246: must send SSL Version 2.0 client hello messages [SSL2]. > > IMHO, this is statement on its own is ambiguous to the point of being > wrong. The problem is that is muddies up the essential distinction: > The term "SSL Version 2.0" refers to a completely different thing > than an "SSLv2-format compatible Client Hello message". > > But it is cleared up in subsequent wording: > >RFC 2246: TLS servers should accept either client hello format if > > This uses the word "format" to make that critical distinction. > > RFC2246: they wish to support SSL 2.0 clients on the same > RFC2246: connection port. The only deviations from the Version 2.0 > RFC2246: specification are the ability to specify a version with a > RFC2246: value of three and the support for more ciphering types > RFC2246: in the CipherSpec. > > It's really imprecise to talk about a "Version 2.0 Client Hello" message > because one of the primary purposes of the initial hello message > exchange is to negotiate exactly which protocol will be used for all > subsequent messages (i.e., the "protocol version"). > > The Client Hello, in effect, has its own protocol version which has > evolved somewhat independently over the years: > > SSLv2 > SSLv2 with SCSV > SSLv3/TLS > SSLv3/TLS with SCSV > SSLv3/TLS with extensions > >> For servers, my thinking has evolved. I'm now at the point where I'd >> like to have TLS servers not have to support SSL 2.0 SERVER-HELLOs and >> SSL 2.0 records after the handshake (RFC 5246 is clear that TLS >> 1.*/SSLv3 servers can accept a SSL 2.0 CLIENT-HELLO). > > Isn't an "SSL 2.0 SERVER-HELLO" is equivalent to negotiating the use of > the SSL 2.0 protocol? Isn't that the thing for which we're trying to put > the final nail in the coffin? > >> If we prohibited TLS client's sending SSL 2.0 CLIENT-HELLO and TLS >> servers sending SSL 2.0 SERVER-HELLO, then I'd be happy because clients >> won't send SSL 2.0, servers won't respond with SSL 2.0, and therefore >> clients won't end up agreeing to send SSL 2.0 records and the server >> won't have to do SSL 2.0 records. > > Really all you have to do is prohibit the client from sending an > SSLv2-compatible client hello. > > It may not hurt to reiterate that this implies that the server will not > be subsequently negotiating the use of SSL 2.0 either. But the client > hello messages and the server hello messages have completely different > considerations, so there's no point in trying to make the language > symmetric. > >> How the following replacement text for Section 3: >> >> Because of the deficiencies noted in the previous section: >> >> * TLS Clients MUST NOT propose SSL 2.0 to a TLS server by sending >> an initial SSL 2.0 CLIENT-HELLO handshake message with protocol >> version { 0x02, 0x00 }. > > How about > > "TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-HELLO > message format. Clients MUST NOT send any client hello message which > specifies a protocol version less than { 0x03, 0x00 }. As previously > stated by the definitions of all previous versions of TLS, the client > SHOULD specify the highest protocol version it supports." I don't have objections to this. >> * According to [RFC5246] Appendix E.2, TLS Servers, even when not >> implementing SSL 2.0, MAY accept an initial SSL 2.0 CLIENT-HELLO >> as the first handshake message of a SSLv3 or TLS handshake. > > "TLS servers MAY continue to accept client hello messages in the version > 2 client hello format as specified in TLS [RFC2246]. Note that this does > not contradict the prohibition against actually negotiating the use of > SSL 2.0." I'd only add a pointer to the specific place in 5246, which somebody else asked for. >> [RFC5246] allowed TLS servers to respond with a SSL 2.0 >> SERVER-HELLO message. > > I don't see where it says that explicitly. 5246 does not say this explicitly, or at least I couldn't find it either. I definitely inferred that it was allowed. > I would have interpreted RFC5246 as being mostly irrelevant once each > endpoint learns that the highest mutually-supported version was > something less than TLS 1.2. > > AFAICT, this is the first document in the SSL/TLS evolution that > attempts to mandate behavior WRT earlier versions of the protocol. > >> This is no longer allowed. That is, TLS >> Servers MUST NOT reply with a SSL 2.0 SERVER-HELLO with a protocol >> version of { 0x02, 0x00 } and instead MUST abort the connection, >> i.e., when the highest protocol version offered by the client is >> { 0x02, 0x00 } the TLS connection will be refused. > > Would "is less than { 0x03, 0x00 }" be a better condition? Not that many > clients are likely to send { 0x02, 0xFF }, but we might as well prohibit > it. It would line up better with the change to the 1st bullet. spt From mnot@mnot.net Mon Dec 13 16:08:19 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E795E3A6E17 for ; Mon, 13 Dec 2010 16:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.603 X-Spam-Level: X-Spam-Status: No, score=-104.603 tagged_above=-999 required=5 tests=[AWL=-2.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PRA+yJ+AY6j for ; Mon, 13 Dec 2010 16:08:19 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 0CE063A6E0F for ; Mon, 13 Dec 2010 16:08:18 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7AB4222E253; Mon, 13 Dec 2010 19:09:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: LC comments on draft-yevstifeyev-http-headers-not-recognized-08.txt From: Mark Nottingham Date: Tue, 14 Dec 2010 11:09:48 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101213132808.2379.30041.idtracker@localhost> To: The IETF X-Mailer: Apple Mail (2.1082) Cc: httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 00:08:20 -0000 The use cases for this draft are highly speculative and unproven, even = for something aspiring to be Experimental. I haven't seen any = implementers express interest in it.=20 The draft does not cover what it means for a server to "recognise" a = header, yet it places a MUST level requirement on this; e.g., if a = server doesn't actively use the "Via" header, should it list it as not = recognised? What about X-Forwarded-For? Deploying this on a server as-is = means that a lot of extra bytes will be sent in responses (and not just = because the field-name is so long, although that doesn't help). If the = client sends a 'Range' header but the server chooses not to sent a = partial response, should it be listed? And so on... It's also under-specified; e.g, I haven't seen any analysis on the = interaction of this mechanism with hop-by-hop headers, nor with content = negotiation, nor with caching.=20 Furthermore, the draft enables implementation of an anti-pattern for = HTTP, by offering an alternative to the 'must ignore' pattern. I = understand that the intent of the header is to enable debugging, but if = it gains deployment, it will be very tempting for developers to build on = top of it. Therefore, I recommend that this draft NOT be published as an RFC (of = any kind). Regards, Begin forwarded message: > From: The IESG > Date: 14 December 2010 12:28:08 AM AEDT > To: IETF-Announce > Subject: Last Call: = = ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC >=20 >=20 > The IESG has received a request from an individual submitter to = consider > the following document: > - ''Headers-Not-Recognized' HTTP Header Field' > as an > Experimental RFC >=20 > 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-01-14. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > = http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recogni= zed/ >=20 > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recogni= zed/ >=20 >=20 > 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 -- Mark Nottingham http://www.mnot.net/ From allison.mankin@gmail.com Mon Dec 13 18:55:18 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C5B28C124; Mon, 13 Dec 2010 18:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFOQFbVZp9Yh; Mon, 13 Dec 2010 18:55:17 -0800 (PST) Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by core3.amsl.com (Postfix) with ESMTP id 623863A6E34; Mon, 13 Dec 2010 18:55:16 -0800 (PST) Received: by fxm18 with SMTP id 18so183944fxm.16 for ; Mon, 13 Dec 2010 18:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4kls3oUkSJqX0fXjiZBI7IAt4s9eCeZkyKPGhbo1hCo=; b=kJMDUOdJVQaIMmv4UMEj5pYGpiKpAxb556aFkOLYnbhrRdL56ntbOzDK6bXkQoytXr 46RaWuKt5RKC093K0/uah5rfsbKK0e5xXV2KhMPgmP5/NkAr9fSJthsNQIHH+37h34Fj e0h/FBG4uILAMElhvdeHQAh0eFg6uQgpuQ8Ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Q3OUbzCSwD6pWuAB1BmbgUxqwlLqRmvoMzyOg93Q9S/3dh1a+Ll/xNSt77G9REo2T/ nTHJ51buTUFM/NG/jui8+VelRUQY0HSZJOrRpchUVxjN+KhtDHvMajuNuNVRh+kS9Nyc Faoud5VCukPTAvmQ/AZivuBC4lzWpwieho9WM= MIME-Version: 1.0 Received: by 10.223.83.199 with SMTP id g7mr5027023fal.81.1292295414560; Mon, 13 Dec 2010 18:56:54 -0800 (PST) Received: by 10.223.78.193 with HTTP; Mon, 13 Dec 2010 18:56:54 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Dec 2010 21:56:54 -0500 Message-ID: Subject: TSV-Dir Last Call review of draft-ietf-avt-rtp-cnames-02 From: Allison Mankin To: IETF Discussion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Allison Mankin , Ali Begen , Colin Perkins , Transport Directorate X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 02:55:18 -0000 TSV-DIR Last Call review of "Guidelines for Chosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document'= s authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. =A0Please always cc tsv-dir@ietf.org if yo= u reply to or forward this review. Summary: This draft is on the right track, but has open issues described in the review. The review below gives my basis for three recommendations: 1. For long-term persistent CNAMEs, differentiate among the UUID "Versions" in RFC 4122 2. For short-term persistent CNAMEs, allow IPv4-only endpoints to generate = a pseudo-random alternative to their MAC, if desired 3. For per-session CNAMEs, provide some guidance for the random value and the key, which are currently left underspecified. Section 3 sets up the major requirement to be met, which is better uniqueness properties than those of the CNAME generation in RFC 3550. There's a hint in the last sentence of the section about an additional requirement to afford privacy support. =A0This sentence only mentions avoid= ing exposure of private addresses. =A0Avoidance of linkage among RTP streams du= e to the use of fixed CNAMEs comes up later. Section 4 sets up the CNAME types, persistent versus per-session, and withi= n persistent types, short-term IPv4-only, short-term IPv6-capable, and long-term. =A0The methods of generating these CNAMEs are distinct and I understand from the WG mailing list discussion of their AD review that they are to be specified as mandatory. =A0 On December 2, Ali wrote to AVT that = the next revision will change language in Section 4 from the existing: =A0 =A0Other methods, beyond the three methods listed above, are not =A0 =A0compliant with this specification and SHOULD NOT be used. To the following: =A0 =A0It is believed that obtaining uniqueness is an important property th= at =A0 =A0requires careful evaluation of the method. This document provides a =A0 =A0number of methods, for which it is believed that at least one of the= m =A0 =A0would meet all deployment scenarios. This document therefore does no= t =A0 =A0provide for the implementor to define and select an alternative =A0 =A0method. =A0 =A0A future specification might define an alternative method for =A0 =A0generating RTCP CNAMEs as long as the proposed method has appropriat= e =A0 =A0uniqueness, and there is consistency between the methods used for =A0 =A0multiple RTP sessions that are to be correlated. However, such a =A0 =A0specification needs to be reviewed and approved before deployment. The second sentence of the first paragraph could be written better: =A0 =A0This document provides a number of methods, at least one of which =A0 =A0should be suitable for all deployment scenarios. My remaining discussion is about making this statement more true. First, all the methods should afford some access to privacy support, but as written, there is little or none for the long-term persistent and the IPv4-only short-term persistent CNAMEs. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= An implementation that wishes to =A0 discourage this type of third-party monitoring can generate a unique =A0 RTCP CNAME for each RTP session, or group of related RTP sessions, =A0 that it joins. =A0Such a per-session RTCP CNAME cannot be used for =A0 traffic analysis, and so provides some limited form of privacy The above statement implies that a long-term persistent CNAME inherently cannot have privacy support. =A0It's not necessarily so: if the CNAME doesn= 't embed identifying information, observers get connections among multiple streams but they only don't have a fixed host identity, only a pseudonym. Specific issues per CNAME method: 1) Long-term persistent CNAMEs are required to be generated by an adaptatio= n of RFC 4122 UUIDs (the adaptation is to leave off the string "urn:uuid:"). The draft references Section 3 of RFC 4122. =A0It should reference Section = 4 instead because Section 3 does not detail the UUID components. =A0Moreover,= it would be good for the draft to advise on usage among the four different versions of UUID that RFC 4122 covers: + Version 1: generated from clock + MAC, or + MAC-format random number + Version 3: generated from namespace:name + Version 4: generated from "truly random or pseudo-random number" + Version 5: generated from hash of namespace:name There needs to be some guidance because the use of the UUID Versions 3/5, derived from namespace:name, has the same problem with non-uniqueness of FQDNs as the RFC 3550 FQDN-based CNAMEs. =A0Perhaps this document should advise against using 3/5. =A0In addition, right now the draft is silent on mitigating identity exposure, but it could offer some guidance towards usin= g the variant of Version 1 that does not expose the MAC or towards using Version 4. 2) Short-term persistent CNAMEs =A0are allowed to use a pseudo-randomly generated RFC 4941 IPv6 privacy address if the device is IPv6-capable, but are required to exposetheir MACs if the device is IPv4-only. =A0Why not all= ow IPv4-only endpoints to to generate pseudo-random MACs using the specification of doing so provided for the Version 1 variant in RFC 4122? 3) Per-session CNAMEs are generated using SHA1-HMAC over the concatenation of the initially-used SSRC, the source and destination addresses and ports, and "a randomly generated value". =A0RFC 4086 is given as a reference for t= he randomly generated value. =A0I think an implementer would like to know how many bytes of randomly generated value should be used; this doesn't come ou= t clearly from reading RFC 4086. Further, what are the requirements for the key for HMAC here? =A0In reading RFC 2104, the reference for HMAC, I end up with some ideas about the key length, but not about how long/where I can us= e the same key or whether there are problematic keys - to mention two questions that come to mind. =A0Keying would not normally be easy to under-specify this way because a security application would call for some keying details, but in this application there is no security use for the keys. =A0Either it would be good to add some guidance or perhaps SHA1-HMAC could be replaced with an "insecure hash." =A0Thoughts about this have aris= en from re-reading EKR's SAAG talk from IETF 73: www.ietf.org/proceedings/08nov/slides/saag-0.pdf With best regards to all, Allison mankin@psg.com / allison.mankin@gmail.com / allison.mankin@jhuapl.edu From Chris.Dearlove@baesystems.com Tue Dec 14 01:56:06 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFAF3A6D79 for ; Tue, 14 Dec 2010 01:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci9aSFSwD0-Z for ; Tue, 14 Dec 2010 01:56:05 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 31B193A6D2D for ; Tue, 14 Dec 2010 01:56:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,341,1288569600"; d="scan'208,217";a="105139664" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Dec 2010 09:57:44 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBE9vhmJ009167; Tue, 14 Dec 2010 09:57:43 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Dec 2010 09:57:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9B75.553918DB" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Clarification for Copyright to referred material in IETF draft Date: Tue, 14 Dec 2010 09:57:21 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification for Copyright to referred material in IETF draft thread-index: AcuWtfURJYaFv0uVSkidhQCq+uU4XAEvwDiQ References: From: "Dearlove, Christopher (UK)" To: "Samir Srivastava" , X-OriginalArrivalTime: 14 Dec 2010 09:57:36.0626 (UTC) FILETIME=[55FC2D20:01CB9B75] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 09:56:07 -0000 ------_=_NextPart_001_01CB9B75.553918DB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would not consider that a link to Wikipedia is ever appropriate in an IETF draft. If it were, then an exact date and time would need to be included in the reference, but I'd be unhappy even with that. (This is not for copyright reasons.) -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ________________________________ From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Samir Srivastava Sent: 08 December 2010 08:57 To: Ietf@ietf.org Subject: Clarification for Copyright to referred material in IETF draft *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Hi, If a link is referred within the draft being submitted to IETF has link to other web-site as a reference for other work (such as wikipedia), does IETF require the copyright for that referred stuff also. Thx Samir ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01CB9B75.553918DB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
I would not consider that a link to Wikipedia is ever appropriate in an
IETF draft. If it were, then an exact date and time would need to be
included in the reference, but I'd be unhappy even with that. (This is
not for copyright reasons.)

--
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Samir Srivastava
Sent: 08 December 2010 08:57
To: Ietf@ietf.org
Subject: Clarification for Copyright to referred material in IETF draft

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet.
      Keep this in mind if you answer this message.
Hi,
 
  If a link is referred within the draft being submitted to IETF has link to other web-site as a reference for other work (such as wikipedia), does IETF require the copyright for that referred stuff also.
 
Thx
Samir

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

------_=_NextPart_001_01CB9B75.553918DB-- From julian.reschke@gmx.de Tue Dec 14 02:26:46 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2B73A6844 for ; Tue, 14 Dec 2010 02:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.625 X-Spam-Level: X-Spam-Status: No, score=-104.625 tagged_above=-999 required=5 tests=[AWL=-2.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8htskhrnj7mf for ; Tue, 14 Dec 2010 02:26:45 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 41F913A6841 for ; Tue, 14 Dec 2010 02:26:41 -0800 (PST) Received: (qmail invoked by alias); 14 Dec 2010 10:28:20 -0000 Received: from p508FD842.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.216.66] by mail.gmx.net (mp008) with SMTP; 14 Dec 2010 11:28:20 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/VyhE0cyDVAlVkf1l6Vwg/bQFkXzn2qtweTUXSP9 ZMt1suMRYGBsp6 Message-ID: <4D0746C3.8050205@gmx.de> Date: Tue, 14 Dec 2010 11:28:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" Subject: Re: Clarification for Copyright to referred material in IETF draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 10:26:46 -0000 On 14.12.2010 10:57, Dearlove, Christopher (UK) wrote: > I would not consider that a link to Wikipedia is ever appropriate in an > IETF draft. If it were, then an exact date and time would need to be > included in the reference, but I'd be unhappy even with that. (This is > not for copyright reasons.) > ... Out of curiosity, and because there may be drafts in the pipeline having links like that...: for which reasons? (I see why we wouldn't want to cite anything *normatively* there, so you don't need to explain that part...) Best regards, Julian From simon@josefsson.org Tue Dec 14 02:38:13 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC11A3A6F7D for ; Tue, 14 Dec 2010 02:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.952 X-Spam-Level: X-Spam-Status: No, score=-100.952 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX-TZfXpBZI5 for ; Tue, 14 Dec 2010 02:38:12 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 4F4B43A6841 for ; Tue, 14 Dec 2010 02:38:12 -0800 (PST) Received: from latte.josefsson.org (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oBEAdaBk004103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Dec 2010 11:39:37 +0100 From: Simon Josefsson To: Julian Reschke Subject: Re: Clarification for Copyright to referred material in IETF draft References: <4D0746C3.8050205@gmx.de> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101214:ietf@ietf.org::jVGQ4FEPhhU3OO75:2p15 X-Hashcash: 1:22:101214:chris.dearlove@baesystems.com::kY81+y12s4nbMYE6:E4tS X-Hashcash: 1:22:101214:julian.reschke@gmx.de::W0v0tToRMb8tgy/9:Lg9M Date: Tue, 14 Dec 2010 11:39:03 +0100 In-Reply-To: <4D0746C3.8050205@gmx.de> (Julian Reschke's message of "Tue, 14 Dec 2010 11:28:19 +0100") Message-ID: <87pqt4r648.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "Dearlove, Christopher \(UK\)" , Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 10:38:14 -0000 Julian Reschke writes: > On 14.12.2010 10:57, Dearlove, Christopher (UK) wrote: >> I would not consider that a link to Wikipedia is ever appropriate in an >> IETF draft. If it were, then an exact date and time would need to be >> included in the reference, but I'd be unhappy even with that. (This is >> not for copyright reasons.) >> ... > > Out of curiosity, and because there may be drafts in the pipeline > having links like that...: for which reasons? > > (I see why we wouldn't want to cite anything *normatively* there, so > you don't need to explain that part...) There is a bunch of RFCs with references to Wikipedia: jas@latte:~/rfc$ rgrep wikipedia rfc*.txt rfc4824.txt: en.wikipedia.org/wiki/Semaphore#Modern_semaphore>. rfc4984.txt: Wikipedia http://en.wikipedia.org/wiki/Moore's_law, rfc5290.txt: "http://en.wikipedia.org/wiki/Net_neutrality". rfc5345.txt: [1] rfc5456.txt: but [wikipedia] lists thirteen other publicly available rfc5456.txt: [wikipedia] Wikipedia, "Inter-Asterisk eXchange", rfc5456.txt: . rfc5638.txt: http://en.wikipedia.org/wiki/Rich_Internet_Applications. rfc5687.txt: en.wikipedia.org/wiki/Cisco_Discovery_Protocol>. rfc5975.txt: http://en.wikipedia.org/wiki/Endianness. jas@latte:~/rfc$ All are informational RFCs, except for RFC 5975 which is Experimental but the reference is informational only. I don't see a problem with this. If there are better references, that is great and they should be preferred, but Wikipedia has useful information and stable URLs, which makes it on par or better than other external references. /Simon From Chris.Dearlove@baesystems.com Tue Dec 14 02:39:53 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A0C28B797 for ; Tue, 14 Dec 2010 02:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6brPZ2ZTFras for ; Tue, 14 Dec 2010 02:39:52 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D357D28C0D8 for ; Tue, 14 Dec 2010 02:39:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,341,1288569600"; d="scan'208";a="105157204" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Dec 2010 10:41:31 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBEAfUbv008372; Tue, 14 Dec 2010 10:41:31 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Dec 2010 10:41:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Clarification for Copyright to referred material in IETF draft Date: Tue, 14 Dec 2010 10:41:31 -0000 Message-ID: In-Reply-To: <4D0746C3.8050205@gmx.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification for Copyright to referred material in IETF draft thread-index: AcubeaK4T+dVP3Y4QT63auFXS/M95AAACywA References: <4D0746C3.8050205@gmx.de> From: "Dearlove, Christopher (UK)" To: "Julian Reschke" X-OriginalArrivalTime: 14 Dec 2010 10:41:30.0766 (UTC) FILETIME=[780E0AE0:01CB9B7B] Cc: Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 10:39:53 -0000 Without a date and time, a link to Wikipedia is to something that anyone could change, at any time, to anything. (Unless locked, but that's unlikely to be the case here.) With a date and time, a link to Wikipedia is at least to a well-defined piece of text. And in technical areas it is often good. But there is no quality control or attribution, and accounts of Wikipedia problems are widespread. I would and do read such articles, but if the fact is important enough to need to be referenced, I'd check it, and reference the checked source. The sources I see as informative references (other drafts, RFCs, other standards or known bodies, textbooks, journal papers) almost always have passed higher standard tests. Finally, this is in line with accepted academic practice. I'm not an academic, but the last academic advice on the subject that I've seen (reported by a student to me) was "if you reference Wikipedia, I will fail you". Can anyone point to any peer-reviewed paper in a reputable source with a Wikipedia reference? -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: 14 December 2010 10:28 To: Dearlove, Christopher (UK) Cc: Samir Srivastava; Ietf@ietf.org Subject: Re: Clarification for Copyright to referred material in IETF draft *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. On 14.12.2010 10:57, Dearlove, Christopher (UK) wrote: > I would not consider that a link to Wikipedia is ever appropriate in an > IETF draft. If it were, then an exact date and time would need to be > included in the reference, but I'd be unhappy even with that. (This is > not for copyright reasons.) > ... Out of curiosity, and because there may be drafts in the pipeline having links like that...: for which reasons? (I see why we wouldn't want to cite anything *normatively* there, so you don't need to explain that part...) Best regards, Julian ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Tue Dec 14 02:43:55 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B333A6F81 for ; Tue, 14 Dec 2010 02:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo0awP5cDkIM for ; Tue, 14 Dec 2010 02:43:54 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 5E93E3A6E3A for ; Tue, 14 Dec 2010 02:43:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,341,1288569600"; d="scan'208";a="105158678" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Dec 2010 10:45:34 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBEAjXX9011347; Tue, 14 Dec 2010 10:45:33 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Dec 2010 10:45:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Clarification for Copyright to referred material in IETF draft Date: Tue, 14 Dec 2010 10:45:33 -0000 Message-ID: In-Reply-To: <87pqt4r648.fsf@latte.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification for Copyright to referred material in IETF draft thread-index: Acubez4QTcKD+oMqT+qxzVStxkna3AAAFRFA References: <4D0746C3.8050205@gmx.de> <87pqt4r648.fsf@latte.josefsson.org> From: "Dearlove, Christopher (UK)" To: "Simon Josefsson" , "Julian Reschke" X-OriginalArrivalTime: 14 Dec 2010 10:45:33.0436 (UTC) FILETIME=[08B28BC0:01CB9B7C] Cc: Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 10:43:55 -0000 > There is a bunch of RFCs with references to Wikipedia: I can only disagree with the practice. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From simon@josefsson.org Tue Dec 14 02:52:47 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDFFD3A690D for ; Tue, 14 Dec 2010 02:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PL+Yvttcl-m for ; Tue, 14 Dec 2010 02:52:47 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id ABE4A3A6F83 for ; Tue, 14 Dec 2010 02:52:46 -0800 (PST) Received: from latte.josefsson.org (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oBEAs6uN005002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Dec 2010 11:54:07 +0100 From: Simon Josefsson To: "Dearlove\, Christopher \(UK\)" Subject: Re: Clarification for Copyright to referred material in IETF draft References: <4D0746C3.8050205@gmx.de> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101214:julian.reschke@gmx.de::Ekts6xkcCKW0qL2w:5R4m X-Hashcash: 1:22:101214:chris.dearlove@baesystems.com::poOETXw81gt+n7iM:41oJ X-Hashcash: 1:22:101214:ietf@ietf.org::WpTprUNKjPCF0/dQ:TBHr Date: Tue, 14 Dec 2010 11:53:33 +0100 In-Reply-To: (Christopher Dearlove's message of "Tue, 14 Dec 2010 10:41:31 -0000") Message-ID: <87ei9kr5g2.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: Julian Reschke , Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 10:52:47 -0000 "Dearlove, Christopher (UK)" writes: > Without a date and time, a link to Wikipedia is to something > that anyone could change, at any time, to anything. (Unless > locked, but that's unlikely to be the case here.) A link to any external site is to something that _someone_ could change, at any time, to anything. I don't see how replacing 'someone' with 'anyone' makes a significant difference here, rather to the contrary since it means you or anyone inclined can improve it to restore its usefulness. External references always comes with the price of creating obsolete or incorrect links. /Simon From Chris.Dearlove@baesystems.com Tue Dec 14 02:58:36 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C23D3A6F91 for ; Tue, 14 Dec 2010 02:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1cQx2ktrT3O for ; Tue, 14 Dec 2010 02:58:35 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 7E7BC3A6F90 for ; Tue, 14 Dec 2010 02:58:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,341,1288569600"; d="scan'208";a="105164162" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Dec 2010 11:00:15 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBEB0EbJ022147; Tue, 14 Dec 2010 11:00:14 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Dec 2010 11:00:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Clarification for Copyright to referred material in IETF draft Date: Tue, 14 Dec 2010 11:00:14 -0000 Message-ID: In-Reply-To: <87ei9kr5g2.fsf@latte.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification for Copyright to referred material in IETF draft thread-index: AcubfUUfcG6Flr4zQWaMcsUT7FHnQQAAJwog References: <4D0746C3.8050205@gmx.de> <87ei9kr5g2.fsf@latte.josefsson.org> From: "Dearlove, Christopher (UK)" To: "Simon Josefsson" X-OriginalArrivalTime: 14 Dec 2010 11:00:14.0555 (UTC) FILETIME=[15E2A2B0:01CB9B7E] Cc: Julian Reschke , Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 10:58:36 -0000 My intended to be last comment. Most links are to something someone - if a good source a known someone - could change. A Wikipedia link is to something anyone can change. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Simon Josefsson [mailto:simon@josefsson.org] Sent: 14 December 2010 10:54 To: Dearlove, Christopher (UK) Cc: Julian Reschke; Ietf@ietf.org Subject: Re: Clarification for Copyright to referred material in IETF draft *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. "Dearlove, Christopher (UK)" writes: > Without a date and time, a link to Wikipedia is to something > that anyone could change, at any time, to anything. (Unless > locked, but that's unlikely to be the case here.) A link to any external site is to something that _someone_ could change, at any time, to anything. I don't see how replacing 'someone' with 'anyone' makes a significant difference here, rather to the contrary since it means you or anyone inclined can improve it to restore its usefulness. External references always comes with the price of creating obsolete or incorrect links. /Simon ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From mrex@sap.com Tue Dec 14 03:52:06 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CF43A6F97 for ; Tue, 14 Dec 2010 03:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.124 X-Spam-Level: X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLdlyLN0diuE for ; Tue, 14 Dec 2010 03:52:05 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id C2F2B3A6F96 for ; Tue, 14 Dec 2010 03:52:04 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBEBregn018595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 12:53:40 +0100 (MET) From: Martin Rex Message-Id: <201012141153.oBEBrahq003502@fs4113.wdf.sap.corp> Subject: Re: Clarification for Copyright to referred material in IETF draft To: Chris.Dearlove@baesystems.com (Dearlove Christopher) Date: Tue, 14 Dec 2010 12:53:36 +0100 (MET) In-Reply-To: from "Dearlove, Christopher" at Dec 14, 10 11:00:14 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal03 X-SAP: out Cc: julian.reschke@gmx.de, simon@josefsson.org, Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 11:52:06 -0000 Dearlove, Christopher wrote: > > Most links are to something someone - if a good source a known someone > - could change. A Wikipedia link is to something anyone can change. I think Wikipedia Articles make very good _informational_ references, and in particular because _anyone_ can change them! Informative References in the form of URLs to information that is under change control of individuals or companies is much more of a problem, because if these entities decide to change or remove that information, it is usually impossible for others to restore any information under that specific URL. Linking to other organization makes sense when it is about a _specification_ owned by or under change control of that organization. The problem with outdating URLs is still a problem, and Wikipedia appears to be one of the few Sites that lives up to the original idea behind URLs. Even the IETF is occasionally moving around stuff needlessly on their Web Server(s). -Martin From jnc@mercury.lcs.mit.edu Tue Dec 14 04:38:56 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8CCF3A6F5F for ; Tue, 14 Dec 2010 04:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO6LYU76OXmL for ; Tue, 14 Dec 2010 04:38:56 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id E6F643A6F7D for ; Tue, 14 Dec 2010 04:38:55 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D5F9C6BE5F2; Tue, 14 Dec 2010 07:40:34 -0500 (EST) To: Ietf@ietf.org Subject: Re: Clarification for Copyright to referred material in IETF draft Message-Id: <20101214124034.D5F9C6BE5F2@mercury.lcs.mit.edu> Date: Tue, 14 Dec 2010 07:40:34 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 12:38:56 -0000 > From: Simon Josefsson > Wikipedia has .. stable URLs, which makes it on par or better than > other external references. That's a sad truth - I find link-rot is an incredible problem with references when I'm looking at older material; stuff seems to go offline all the time, even valuable material. The company decides to redo their website, or someone moves to a new organization, or, or, or... Noel From doug@ewellic.org Tue Dec 14 05:04:12 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970A23A6F93 for ; Tue, 14 Dec 2010 05:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtVi42nT1tPe for ; Tue, 14 Dec 2010 05:04:11 -0800 (PST) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by core3.amsl.com (Postfix) with SMTP id 83E913A6F9F for ; Tue, 14 Dec 2010 05:04:11 -0800 (PST) Received: (qmail 1342 invoked from network); 14 Dec 2010 13:05:51 -0000 Received: from unknown (24.8.55.39) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 14 Dec 2010 13:05:50 -0000 Message-ID: From: "Doug Ewell" To: References: <201012141153.oBEBrahq003502@fs4113.wdf.sap.corp> Subject: Re: Clarification for Copyright to referred material in IETF draft Date: Tue, 14 Dec 2010 06:05:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 13:04:12 -0000 Martin Rex wrote: > Dearlove, Christopher wrote: >> >> Most links are to something someone - if a good source a known >> someone - could change. A Wikipedia link is to something anyone can >> change. > > I think Wikipedia Articles make very good _informational_ references, > and in particular because _anyone_ can change them! This is the eternal debate over Wikipedia: it's good because good people can make it better, it's bad because bad people can make it worse. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ­ From bortzmeyer@nic.fr Tue Dec 14 05:41:08 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68D828C0EE for ; Tue, 14 Dec 2010 05:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.454 X-Spam-Level: X-Spam-Status: No, score=-108.454 tagged_above=-999 required=5 tests=[AWL=1.795, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s+9EyHTJzwR for ; Tue, 14 Dec 2010 05:41:03 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id E18C828C110 for ; Tue, 14 Dec 2010 05:41:02 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 1833F1C0109; Tue, 14 Dec 2010 14:42:42 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 125AA1C00F8; Tue, 14 Dec 2010 14:42:42 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 0FEA07B0037; Tue, 14 Dec 2010 14:42:42 +0100 (CET) Date: Tue, 14 Dec 2010 14:42:42 +0100 From: Stephane Bortzmeyer To: Simon Josefsson Subject: Re: Clarification for Copyright to referred material in IETF draft Message-ID: <20101214134242.GA4387@nic.fr> References: <4D0746C3.8050205@gmx.de> <87ei9kr5g2.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ei9kr5g2.fsf@latte.josefsson.org> X-Operating-System: Debian GNU/Linux squeeze/sid X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Julian Reschke , "Dearlove, Christopher \(UK\)" , Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 13:41:08 -0000 On Tue, Dec 14, 2010 at 11:53:33AM +0100, Simon Josefsson wrote a message of 20 lines which said: > External references always comes with the price of creating obsolete > or incorrect links. Some organisations, like the RFC Editor, provide stable references to things that never change. Same thing with, for instance, the W3C. Most organisations do not provide such stable references and I do not understand why some people have a specific problem with Wikipedia since the IETF does *not* have a policy to allow only references to stable things (it would cut down severely the list of references at the end of RFCs...) From gtw@gtwassociates.com Tue Dec 14 06:54:20 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3ED3A6FA6 for ; Tue, 14 Dec 2010 06:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+c-EjngfvEp for ; Tue, 14 Dec 2010 06:54:18 -0800 (PST) Received: from mail9.primary.net (mail9.primary.net [216.87.38.215]) by core3.amsl.com (Postfix) with ESMTP id 1930A3A6DA9 for ; Tue, 14 Dec 2010 06:54:17 -0800 (PST) Received: from pool-173-66-18-193.washdc.fios.verizon.net ([173.66.18.193]:2110 helo=gtwassociates) by mail9.primary.net with esmtpa (Exim 4.63) (envelope-from ) id 1PSWIF-0001xi-IJ; Tue, 14 Dec 2010 08:55:57 -0600 Message-ID: From: "George Willingmyre" To: References: <20101214124034.D5F9C6BE5F2@mercury.lcs.mit.edu> Subject: Re: Clarification for Copyright to referred material in IETF draft Date: Tue, 14 Dec 2010 09:55:38 -0500 Organization: GTW Associates MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-ACL-Warn: X-The email account used to send this email was: gtw@gtwassociates.com Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: George Willingmyre List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 14:54:20 -0000 see here the OMB policy a-119 about federal references to standards: http://www.whitehouse.gov/omb/circulars_a119/ j. How should my agency reference voluntary consensus standards? Your agency should reference voluntary consensus standards, along with sources of availability, in appropriate publications, regulatory orders, and related internal documents. In regulations, the reference must include the date of issuance George T. Willingmyre, P.E. President, GTW Associates Spencerville, MD USA 20868 ----- Original Message ----- From: "Noel Chiappa" To: Cc: Sent: Tuesday, December 14, 2010 7:40 AM Subject: Re: Clarification for Copyright to referred material in IETF draft > > From: Simon Josefsson > > > Wikipedia has .. stable URLs, which makes it on par or better than > > other external references. > > That's a sad truth - I find link-rot is an incredible problem with > references > when I'm looking at older material; stuff seems to go offline all the > time, > even valuable material. The company decides to redo their website, or > someone > moves to a new organization, or, or, or... > > Noel > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From evnikita2@gmail.com Tue Dec 14 07:15:03 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272E83A6EB5 for ; Tue, 14 Dec 2010 07:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAYY0aaWGK+I for ; Tue, 14 Dec 2010 07:15:02 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 705E03A6DA9 for ; Tue, 14 Dec 2010 07:15:01 -0800 (PST) Received: by bwz8 with SMTP id 8so955479bwz.38 for ; Tue, 14 Dec 2010 07:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+RdDTH8JIKCrPNza4Z3bWQzERK5RVJyIQUiD4ZP1SbA=; b=gyyUQCRFFY5QjcUEvPEQyZJ+jx2XFJ0pXa4htjs2ErVPdykwkCgBoQRycniKiRXZOL yukBGu8Lfv5eXDaIKofoKyEP7YfFUAiCf9kWNSram1cnqwsIbTnPp9dBRVsL6p3/ia3P MULuFeH7hut+J6/IZOo97hOzNxw7mT1bbQF9U= 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=p6W2gzYSR+kFj+UyvuFqtIgTSCAU/R3B7FDMYKMha3MBsA9YBO8BtHhH6ccKXPgjCm ndsxMr6dnocXSf13k+r1PbTZHInYYKAzIhOEaNv8ivtMscROj/t29yay3ulKpki6DeIs BGUPQUrHYGGFQ80rFMFEcNLqcTa7fg4Gi/bCM= Received: by 10.204.82.84 with SMTP id a20mr1918977bkl.154.1292339799309; Tue, 14 Dec 2010 07:16:39 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id a27sm21946bka.22.2010.12.14.07.16.37 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 07:16:38 -0800 (PST) Message-ID: <4D078A60.7070403@gmail.com> Date: Tue, 14 Dec 2010 17:16:48 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: LC comments on draft-yevstifeyev-http-headers-not-recognized-08.txt References: <20101213132808.2379.30041.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: The IETF , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 15:15:03 -0000 Hello all, Let me explain some issues which were mentioned by Mark. 14.12.2010 2:09, Mark Nottingham wrote: > The use cases for this draft are highly speculative and unproven, even for something aspiring to be Experimental. I haven't seen any implementers express interest in it. > > The draft does not cover what it means for a server to "recognise" a header, yet it places a MUST level requirement on this; e.g., if a server doesn't actively use the "Via" header, should it list it as not recognised? What about X-Forwarded-For? Deploying this on a server as-is means that a lot of extra bytes will be sent in responses (and not just because the field-name is so long, although that doesn't help). If the client sends a 'Range' header but the server chooses not to sent a partial response, should it be listed? And so on... Firstly, why do we speak about extra bytes to be transferred now, almost in 2011? Does it seem to be a great problem? And do you really think that there will be *a lot* of such bytes? Secondly, 'doesn't actively use' does not mean 'not supports'. The examples you list are not appropriate for the situation we are discussing. I mean that if the server completely does not support one of headers the client sent, it'll form the corresponding response. And when the client receives, it will avoid sending the corresponding header(s) - so, using this header will allow to save 'extra bytes', as you say, than spend them. The proposal has the opposite effect than you describe. > It's also under-specified; e.g, I haven't seen any analysis on the interaction of this mechanism with hop-by-hop headers, nor with content negotiation, nor with caching. The points you raised are important, so I'll try to add some description in the next versions. > > > Furthermore, the draft enables implementation of an anti-pattern for HTTP, by offering an alternative to the 'must ignore' pattern. I understand that the intent of the header is to enable debugging, but if it gains deployment, it will be very tempting for developers to build on top of it. > > Therefore, I recommend that this draft NOT be published as an RFC (of any kind). > Regards, > > I think the following issue seems to be discussed by this document too - if not only the server, but the client does not recognize on of the header in received packet. I wonder this problem wasn't raised so I'll try to make the corresponding changes in the draft ASAP. I'll let you know when the new version of the draft will be available. All the best, Mykyta Yevstifeyev > Begin forwarded message: > >> From: The IESG >> Date: 14 December 2010 12:28:08 AM AEDT >> To: IETF-Announce >> Subject: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC >> >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - ''Headers-Not-Recognized' HTTP Header Field' >> as an >> Experimental RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2011-01-14. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/ >> >> >> 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 > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From tme@americafree.tv Tue Dec 14 07:40:22 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A153A6EB6 for ; Tue, 14 Dec 2010 07:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.104 X-Spam-Level: X-Spam-Status: No, score=-102.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYPKQGboAQkj for ; Tue, 14 Dec 2010 07:40:22 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id E20DB3A6E9E for ; Tue, 14 Dec 2010 07:40:21 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 45E5D96BFA92; Tue, 14 Dec 2010 10:42:02 -0500 (EST) Subject: Re: Clarification for Copyright to referred material in IETF draft Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <20101214124034.D5F9C6BE5F2@mercury.lcs.mit.edu> Date: Tue, 14 Dec 2010 10:42:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101214124034.D5F9C6BE5F2@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1081) Cc: Ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 15:40:22 -0000 On Dec 14, 2010, at 7:40 AM, Noel Chiappa wrote: >> From: Simon Josefsson >=20 >> Wikipedia has .. stable URLs, which makes it on par or better than >> other external references. >=20 > That's a sad truth - I find link-rot is an incredible problem with = references > when I'm looking at older material; stuff seems to go offline all the = time, > even valuable material. The company decides to redo their website, or = someone > moves to a new organization, or, or, or... The IETF probably should archive any material used as a reference in an = RFC, at the time the RFC is published. I do not believe that this would = cause copyright issues (note : IANAL), but making that archive publicly = available might. Maybe we could do something there in connection with = the Internet Archive. Regards Marshall >=20 > Noel > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From hartmans@mit.edu Tue Dec 14 08:07:51 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7D03A6FA7; Tue, 14 Dec 2010 08:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybyt97M-OmWz; Tue, 14 Dec 2010 08:07:50 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4A7243A6F9B; Tue, 14 Dec 2010 08:07:50 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4E9862013D; Tue, 14 Dec 2010 11:08:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C01224060; Tue, 14 Dec 2010 11:09:20 -0500 (EST) From: Sam Hartman To: draft-ietf-isis-trill-@tools.ietf.org,ietf@ietf.org,secdir@ietf.org Subject: Secdir review of draft-ietf-isis-trill Date: Tue, 14 Dec 2010 11:09:20 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 16:07:51 -0000 Please treat these as normal last call comments. I found the introduction to draft-ietf-isis-trill inadequate. I'm familiar with the base concepts behind TRILL, roughly understand what was going on and followed the chartering discussions of the WG fairly closely. I have read the requirements document but have not read the protocol document. In an ideal world this document would be significantly easier to follow; I suspect that after reading the protocol document I'd still find this a bit choppy. However, I understand that sometimes you can only spend so much time on a spec and sometimes you reach the point where if someone isn't willing to jump in and volunteer a lot of hours to add clarity, good enough is good enough. This document claims that it adds no new security considerations to IS-IS. That's true. However, TRILL is a new protocol--completely new. It re-uses IS-IS as a building block, but if I were a security AD I'd still insist that TRILL meet our current standards for security, including a strong mandatory-to-implement security mechanism and (where appropriate) automated key management. I definitely think that this specification should at least document how IS-IS+TRILL fall short of standards we'd require for a new protocol today. The big area I can think of is replay handling for hello packets, which I suspect leads to a DOS. If we had more success with multicast key management we'd probably also require automated key management for a protocol like this. However,we don't, so I think that the RFC 4107 analysis would conclude that manual key management is acceptable under the multicast exception. I suspect the sec ADs will not actually require a solution even though it is a new protocol. I think that's a mistake, but I also don't have a lot of time to spend on TRILL, and I'd definitely rather see it get published than bogged down. I think documenting how IS-IS security interacts with TRILL security and IETF security BCPs should only take a relatively short time. From hartmans@mit.edu Tue Dec 14 08:17:22 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E961C3A6EA4; Tue, 14 Dec 2010 08:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzzyLWmdjK47; Tue, 14 Dec 2010 08:17:22 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BD7C83A6DD2; Tue, 14 Dec 2010 08:17:22 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6E68220220; Tue, 14 Dec 2010 11:17:58 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CF6404060; Tue, 14 Dec 2010 11:18:52 -0500 (EST) From: Sam Hartman To: draft-ietf-isis-trill@tools.ietf.org,ietf@ietf.org,secdir@ietf.org Subject: Secdir review of draft-ietf-isis-trill Date: Tue, 14 Dec 2010 11:09:20 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 16:17:23 -0000 Please treat these as normal last call comments. I found the introduction to draft-ietf-isis-trill inadequate. I'm familiar with the base concepts behind TRILL, roughly understand what was going on and followed the chartering discussions of the WG fairly closely. I have read the requirements document but have not read the protocol document. In an ideal world this document would be significantly easier to follow; I suspect that after reading the protocol document I'd still find this a bit choppy. However, I understand that sometimes you can only spend so much time on a spec and sometimes you reach the point where if someone isn't willing to jump in and volunteer a lot of hours to add clarity, good enough is good enough. This document claims that it adds no new security considerations to IS-IS. That's true. However, TRILL is a new protocol--completely new. It re-uses IS-IS as a building block, but if I were a security AD I'd still insist that TRILL meet our current standards for security, including a strong mandatory-to-implement security mechanism and (where appropriate) automated key management. I definitely think that this specification should at least document how IS-IS+TRILL fall short of standards we'd require for a new protocol today. The big area I can think of is replay handling for hello packets, which I suspect leads to a DOS. If we had more success with multicast key management we'd probably also require automated key management for a protocol like this. However,we don't, so I think that the RFC 4107 analysis would conclude that manual key management is acceptable under the multicast exception. I suspect the sec ADs will not actually require a solution even though it is a new protocol. I think that's a mistake, but I also don't have a lot of time to spend on TRILL, and I'd definitely rather see it get published than bogged down. I think documenting how IS-IS security interacts with TRILL security and IETF security BCPs should only take a relatively short time. From sm@resistor.net Tue Dec 14 11:56:16 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B97928C0FA for ; Tue, 14 Dec 2010 11:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.469 X-Spam-Level: X-Spam-Status: No, score=-103.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLeYkvHO5eFU for ; Tue, 14 Dec 2010 11:56:13 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id DC71E28C0FE for ; Tue, 14 Dec 2010 11:56:13 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oBEJvOts007903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2010 11:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1292356671; x=1292443071; bh=GYVHe9AEBfLUgRHcgOjN4fP4W6IxgGLYnQSgpA2WlLM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ULOUK1GLEr84Px18PYDBDPAKvZixLRJtZ0X+tNlP+cwvbE5W1+FEOdS27MTIYhb4o FtHRsyXHvXVT2is3znrSPxcf7HlW1sca/lbp7Dzf6DwF0Gzya3jMpfZJ5miWOgABnx NET4ELHBVTBQ+YB2pDa+6cxONbZ75evPpb89ZEGY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1292356671; x=1292443071; bh=GYVHe9AEBfLUgRHcgOjN4fP4W6IxgGLYnQSgpA2WlLM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=iJKwxQWwTPnzLYN/di8OX3lwy4ab1zfnl/kxs2Va0TdtRGvhjyKkoNOma2G0XzK6k KLTBdbJ9s9uNdCRsmsQY3ZcGTWKdM710ME2va9bW8+pye2GapsESMHzYpMRZuPVU5B BTznT9fWZHoQ5P0nbBmNhWl981t8BK1cyrgbt+b4= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=nsBzApdilcM4asxvI3rdupPLoqWJZCeQXa18/4XmzU5IygB4ZhqtLd077w6gbQ/3g JQAQ9gJPxbQYShp/OmG1yS6pg24drBURsusvYbX7vMu9bmdVgHf8L4xrCXT9pfb1yZ+ /TQAj2GDoGGIOFspvdJEreaExanA2FzITHwNko8= Message-Id: <6.2.5.6.2.20101214102615.083489a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 14 Dec 2010 11:56:52 -0800 To: Julian Reschke From: SM Subject: Re: Clarification for Copyright to referred material in IETF draft In-Reply-To: <4D0746C3.8050205@gmx.de> References: <4D0746C3.8050205@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 19:56:16 -0000 Hi Julian, At 02:28 14-12-10, Julian Reschke wrote: >Out of curiosity, and because there may be drafts in the pipeline >having links like that...: for which reasons? This question would have been better suited for the RFC Editor (see RFC-interest mailing list) as it pertains to RFC style. Quoting Doug Ewell [1]: "I thought it would be good to let the list know that these misconceptions exist and may be widespread, because of the wide use of Wikipedia" And text from draft-narten-iana-rir-ipv6-considerations-00: 'At various times in the past, it has been asserted that we will "never run out of IPv6 addresses". For example, Wikipedia repeats the myth' If you are writing a draft about HTTP, for example, you will most likely do some research about the protocol. The best way to do that is to type the word "HTTP" in the browser bar and it will be magically transformed into an reference to the specification. The webpage which will appear has been peer reviewed by people with more expertise than the HTTPbis working group. :-) It is left as an exercise to the reader of the drafts in the pipeline having links like that to determine whether the authors used the above methodology. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ltru/current/msg06507.html From lauri.vosandi@gmail.com Tue Dec 14 12:01:32 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AA528C102 for ; Tue, 14 Dec 2010 12:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.152 X-Spam-Level: X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVvOkDVHregU for ; Tue, 14 Dec 2010 12:01:31 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DCAFB28C0F0 for ; Tue, 14 Dec 2010 12:01:30 -0800 (PST) Received: by iwn40 with SMTP id 40so1230018iwn.31 for ; Tue, 14 Dec 2010 12:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=n1uhTUqm7UIIM3ZBRAg/ZkGN1+FLcOrREHY8Q5BFiv8=; b=gHMg/H3hXKEhywljs5g9QeRTfLlfyM50IVvOVe7np2727yg+j9MmcOgMwYnqSEIxFk T9bFK4A5pu98GrxMuoTwSkIS3EuZwZJ6Mf6yUGnYWYQWbfRSTHEgdQTrL0uZRW9KVKSt nV3/CvVtHSlHboIbAADOW7kFksTmues13x9to= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=f1+Suz42yg9XZ8oVzz9mrV7VKpuHxPIeIWRACqI/iiW6AOS7NKakyY4Quqk3gEa/Zk oRjNy5f6g+dJdb9gX9uuUmtYVFnfPm/5hGeXiVCF+OgLATeiX9Ysi5kkzPPMNMSGaAb5 +b2EkQzCuchw7ooO3WWSgs42r4vIdvp0XmNEg= MIME-Version: 1.0 Received: by 10.231.17.205 with SMTP id t13mr3807379iba.80.1292356991369; Tue, 14 Dec 2010 12:03:11 -0800 (PST) Received: by 10.231.39.131 with HTTP; Tue, 14 Dec 2010 12:03:11 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Dec 2010 22:03:11 +0200 Message-ID: Subject: Secure Shell UNIX domain socket redirection to Proposed Standard From: lauri To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 20:01:32 -0000 Good evening, on GNU/Linux boxes there are many services which use UNIX domain sockets for inter-process communication. Most of them also support TCP sockets, but that needs additional code for authentication. There used to be streamlocal patch which implemented UNIX domain socket redirection for OpenSSH but now it seems to be dead: http://www.25thandclement.com/~william/projects/streamlocal.html Generally I think it would be good idea to have UNIX domain socket redirection in Secure Shell standard because the difference between TCP/IP redirection code and the one used for UNIX domain sockets is minor. The feature would benefit many LTSP deployments and other installations aswell. Blogpost related to the lack of UNIX domain socket redirection in Secure Shell standard can be found here: http://v6sa.wordpress.com/2010/12/01/gnulinux-based-terminal-servers-with-s= martcard-support/ --=20 Lauri V=F5sandi tel: +372 53329412 e-mail: lauri.vosandi@gmail.com company: Povi Software O=DC (http://www.povi.ee) blog: http://v6sa.wordpress.com/ From doug@ewellic.org Tue Dec 14 12:22:55 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C512928C115 for ; Tue, 14 Dec 2010 12:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH8valMtEybk for ; Tue, 14 Dec 2010 12:22:54 -0800 (PST) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by core3.amsl.com (Postfix) with SMTP id 94C6428C117 for ; Tue, 14 Dec 2010 12:22:54 -0800 (PST) Received: (qmail 7561 invoked from network); 14 Dec 2010 20:24:34 -0000 Received: from unknown (HELO localhost) (72.167.218.130) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 14 Dec 2010 20:24:34 -0000 Received: (qmail 7414 invoked by uid 99); 14 Dec 2010 20:24:34 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.190 User-Agent: Web-Based Email 5.3.00 Message-Id: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> From: "Doug Ewell" To: ietf@ietf.org Subject: Wikipedia (was: Re: Clarification for Copyright to referred material in IETF draft) Date: Tue, 14 Dec 2010 13:24:34 -0700 Mime-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 20:22:55 -0000 SM wrote: > Quoting Doug Ewell [1]: >=20 > "I thought it would be good to let the list know that these > misconceptions exist and may be widespread, because of the wide > use of Wikipedia" I like Wikipedia and usually find its articles to be accurate. The article on BCP 47 language tags to which I was referring happened to be filled with errors and oversimplifications. (Its author was, and is, known to make the same blunders on mailing lists.) It would be a mistake to assume that all Wikipedia articles are either 100% accurate or 100% inaccurate. Cross-checking with other sources is often a wise move. This is also true for books, magazines, technical journals, mailing lists, and blogs. I've even read standards and specifications that contained factual errors; I suppose we all have. The fact that Wikipedia articles can be edited by anyone, and do not undergo a formal peer review process by people with abbreviations at the end of their names, does not automatically mean they are chock-full of damaging errors. Civilians with better information fix problems all the time. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s =C2=AD From tme@americafree.tv Tue Dec 14 12:25:58 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9F428C11B for ; Tue, 14 Dec 2010 12:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.109 X-Spam-Level: X-Spam-Status: No, score=-102.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7A2FcG2Ucve for ; Tue, 14 Dec 2010 12:25:57 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id B153228C0FA for ; Tue, 14 Dec 2010 12:25:57 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 5AB2B96C5265; Tue, 14 Dec 2010 15:27:38 -0500 (EST) Subject: Re: Wikipedia (was: Re: Clarification for Copyright to referred material in IETF draft) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> Date: Tue, 14 Dec 2010 15:27:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> To: "Doug Ewell" X-Mailer: Apple Mail (2.1081) Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 20:25:58 -0000 =20 On Dec 14, 2010, at 3:24 PM, Doug Ewell wrote: > SM wrote: >=20 >> Quoting Doug Ewell [1]: >>=20 >> "I thought it would be good to let the list know that these >> misconceptions exist and may be widespread, because of the wide >> use of Wikipedia" >=20 > I like Wikipedia and usually find its articles to be accurate. The > article on BCP 47 language tags to which I was referring happened to = be > filled with errors and oversimplifications. (Its author was, and is, > known to make the same blunders on mailing lists.) The problem I have with this is not the content (presumably the author = of the I-D is vouching for any references they use), it's that the content can change at any time. Regards Marshall >=20 > It would be a mistake to assume that all Wikipedia articles are either > 100% accurate or 100% inaccurate. Cross-checking with other sources = is > often a wise move. This is also true for books, magazines, technical > journals, mailing lists, and blogs. I've even read standards and > specifications that contained factual errors; I suppose we all have. >=20 > The fact that Wikipedia articles can be edited by anyone, and do not > undergo a formal peer review process by people with abbreviations at = the > end of their names, does not automatically mean they are chock-full of > damaging errors. Civilians with better information fix problems all = the > time. >=20 > -- > Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org > RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From tony@att.com Tue Dec 14 13:09:29 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DE828C123 for ; Tue, 14 Dec 2010 13:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.495 X-Spam-Level: X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTQonSWf+bbG for ; Tue, 14 Dec 2010 13:09:28 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 4028E28C11B for ; Tue, 14 Dec 2010 13:09:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-11.tower-161.messagelabs.com!1292361066!15162198!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 3609 invoked from network); 14 Dec 2010 21:11:07 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2010 21:11:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBELBQ61009709 for ; Tue, 14 Dec 2010 16:11:26 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBELBJwn009539 for ; Tue, 14 Dec 2010 16:11:19 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBELAwZw000842 for ; Tue, 14 Dec 2010 16:10:58 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBELAqfL000540 for ; Tue, 14 Dec 2010 16:10:52 -0500 Received: from [135.70.79.141] (vpn-135-70-79-141.vpn.swst.att.com[135.70.79.141]) by maillennium.att.com (mailgw1) with ESMTP id <20101214211051gw1004lk9re> (Authid: tony); Tue, 14 Dec 2010 21:10:51 +0000 X-Originating-IP: [135.70.79.141] Message-ID: <4D07DD5A.6030400@att.com> Date: Tue, 14 Dec 2010 16:10:50 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Wikipedia References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> In-Reply-To: <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 21:09:29 -0000 On 12/14/2010 3:27 PM, Marshall Eubanks wrote: > The problem I have with this is not the content (presumably the author of the I-D is vouching for any references they use), it's > that the content can change at any time. The problem with referencing *any* web page, whether it's Wikipedia or otherwise, is that the content can change at any time. So you not only need spatial coordinates (the URL), but also the temporal coordinates (date and time) for *when* the pertinent data was accessed and found to be on that web page. Interestingly enough, the "rules" for external references in Wikipedia also require the temporal coordinates to be recorded. And for Wikipedia itself, for any given date and time you can always pull up in the history what the page had on it right then. Tony Hansen tony@att.com From mnot@mnot.net Tue Dec 14 13:27:41 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A026E28C0EB for ; Tue, 14 Dec 2010 13:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.621 X-Spam-Level: X-Spam-Status: No, score=-104.621 tagged_above=-999 required=5 tests=[AWL=-2.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY4zTIU8Jtde for ; Tue, 14 Dec 2010 13:27:40 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 8772328C13A for ; Tue, 14 Dec 2010 13:27:40 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AB58922E1F4; Tue, 14 Dec 2010 16:29:14 -0500 (EST) Subject: Re: LC comments on draft-yevstifeyev-http-headers-not-recognized-08.txt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4D078A60.7070403@gmail.com> Date: Wed, 15 Dec 2010 08:29:10 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <9AEDD923-5AE2-48F7-8180-3E0E97463274@mnot.net> References: <20101213132808.2379.30041.idtracker@localhost> <4D078A60.7070403@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1082) Cc: The IETF , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 21:27:41 -0000 On 15/12/2010, at 2:16 AM, Mykyta Yevstifeyev wrote: > Hello all, >=20 > Let me explain some issues which were mentioned by Mark. >=20 > 14.12.2010 2:09, Mark Nottingham wrote: >> The use cases for this draft are highly speculative and unproven, = even for something aspiring to be Experimental. I haven't seen any = implementers express interest in it. >>=20 >> The draft does not cover what it means for a server to "recognise" a = header, yet it places a MUST level requirement on this; e.g., if a = server doesn't actively use the "Via" header, should it list it as not = recognised? What about X-Forwarded-For? Deploying this on a server as-is = means that a lot of extra bytes will be sent in responses (and not just = because the field-name is so long, although that doesn't help). If the = client sends a 'Range' header but the server chooses not to sent a = partial response, should it be listed? And so on... > Firstly, why do we speak about extra bytes to be transferred now, = almost in 2011? Does it seem to be a great problem? I can point you at lots of people who work at Amazon, Yahoo, Google, = Akamai and other large-scale Web development shops who are painfully = aware of both the costs of bandwidth (especially in many non-US markets) = and the effect of adding packets on end-user perceived latency. It = matters very much. > And do you really think that there will be *a lot* of such bytes? = Secondly, 'doesn't actively use' does not mean 'not supports'. The = examples you list are not appropriate for the situation we are = discussing. I mean that if the server completely does not support one of = headers the client sent, it'll form the corresponding response. As it sits, it's impossible to say; your draft doesn't contain the word = "supports" "actively use" or anything else to describe how this = mechanism would work in practice, nor are there examples. > And when the client receives, it will avoid sending the corresponding = header(s) - so, using this header will allow to save 'extra bytes', as = you say, than spend them. The proposal has the opposite effect than you = describe. To achieve that effect, you have to get widespread support in both = servers and clients. Have you had any discussions with vendors of = either? What are your goals here, overall? =46rom previous discussions, I'd = thought it was to provide a debugging mechanism. Here, you express = interest in saving bytes. I suspect that having both as goals will be = pulling you in different directions... Regards, -- Mark Nottingham http://www.mnot.net/ From robert@timetraveller.org Tue Dec 14 15:15:13 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD7928C143 for ; Tue, 14 Dec 2010 15:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huxLWdRE5PMr for ; Tue, 14 Dec 2010 15:15:12 -0800 (PST) Received: from capella.opentrend.net (capella.opentrend.net [64.22.125.103]) by core3.amsl.com (Postfix) with ESMTP id 6B81728C136 for ; Tue, 14 Dec 2010 15:15:12 -0800 (PST) Received: by capella.opentrend.net (Postfix, from userid 1004) id 1A63A138CAE; Tue, 14 Dec 2010 23:16:52 +0000 (UTC) Received: from proxima.opentrend.net (unknown [192.168.121.26]) by capella.opentrend.net (Postfix) with ESMTP id E0C0FDDD2 for ; Tue, 14 Dec 2010 23:16:50 +0000 (UTC) Received: by proxima.opentrend.net (Postfix, from userid 103) id CD2BF77411E; Tue, 14 Dec 2010 18:22:32 -0500 (EST) Received: by proxima.opentrend.net (Postfix, from userid 1000) id 66095774113; Tue, 14 Dec 2010 18:07:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by proxima.opentrend.net (Postfix) with ESMTP id 62432794FA9 for ; Tue, 14 Dec 2010 18:07:30 -0500 (EST) Date: Tue, 14 Dec 2010 18:07:30 -0500 (EST) From: Robert Brockway X-X-Sender: robert@proxima To: ietf@ietf.org Subject: Re: Wikipedia (was: Re: Clarification for Copyright to referred material in IETF draft) In-Reply-To: <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> Message-ID: References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 23:15:13 -0000 On Tue, 14 Dec 2010, Marshall Eubanks wrote: > The problem I have with this is not the content (presumably the author > of the I-D is vouching for any references they use), it's that the > content can change at any time. Hi Marshall. Mediawiki (the software behind Wikipedia and a lot of other sites) solved this problem years ago. It is possible to link to a specific version of any article on a Mediawiki site. Just look for the 'Permanent link' link on the page. In my experience very few sites linking to Wikipedia use this capability, proably because they don't know about it. Ideally anyone linking to Wikipedia from an article would link to the specific version so that the reader sees exactly what the author saw when they wrote the article. More recent versions of Mediawiki advise that the copy of the page is old and provide a link to the latest version. That's fine too. Eg, here is a link to a version of the IETF article from yesterday: http://en.wikipedia.org/w/index.php?title=Internet_Engineering_Task_Force&oldid=390092590 Cheers, Rob -- Email: robert@timetraveller.org Linux counter ID #16440 IRC: Solver (OFTC & Freenode) Web: http://www.practicalsysadmin.com Contributing member of Software in the Public Interest (http://spi-inc.org/) Open Source: The revolution that silently changed the world From cheshire@apple.com Tue Dec 14 17:06:32 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416413A6E22 for ; Tue, 14 Dec 2010 17:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.849 X-Spam-Level: X-Spam-Status: No, score=-107.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvo0+0i179HF for ; Tue, 14 Dec 2010 17:06:31 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 203393A6E1F for ; Tue, 14 Dec 2010 17:06:31 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 74F21C418FB6 for ; Tue, 14 Dec 2010 17:08:12 -0800 (PST) X-AuditID: 11807136-b7b9aae0000052f6-18-4d0814fcecb5 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id A7.20.21238.CF4180D4; Tue, 14 Dec 2010 17:08:12 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [10.0.1.201] ([173.164.252.149]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDG00JFT35NNW30@elliott.apple.com> for ietf@ietf.org; Tue, 14 Dec 2010 17:08:12 -0800 (PST) In-reply-to: <4CE9F51C.2010201@dougbarton.us> References: <4CE9F51C.2010201@dougbarton.us> Message-id: From: Stuart Cheshire Subject: Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt Date: Tue, 14 Dec 2010 17:08:19 -0800 To: Doug Barton X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 01:06:32 -0000 On 21 Nov 2010, at 8:44 PM, Doug Barton wrote: > That said, I'm reasonably supportive of the draft moving forward Thanks. > 1. In Section 4.1, 4th full paragraph, the bit, " (because of the > limitations of the typing-based user interfaces of that era)" > should be stricken. It does not add value to the clarity of the > text, nor would arguing about whether it's correct or not. I see your point, but I think the text provides useful context to remind readers about the user-interface considerations of that era -- especially young readers who don't remember the time when computers only had text-based interfaces. > 2. In that same paragraph, shortly after the above, "from a list of > choices presented on the screen ..." should be something similar to > "from a list of choices presented by the user interface ..." Very good point. Of course, the concept of having a screen doesn't even apply to Apple's new telepathic-projection antimatter-powered iPhone. We've updated the document accordingly. > One could also argue that the "not intended to ever by typed in" > should be replaced with the appropriate 2119 language. The text is illustrative, not prescriptive. We have changed the text to say this: Users generally access a service not by typing in the Instance Name, but by selecting it from a list presented by a user interface. > 3. In Section 7, 3rd full paragraph, it says, "conforming to normal > DNS host name rules: Only lower-case letters ..." The "normal DNS > host name rules" [citation required] do not permit only lower case > letters. I do think however that it would be ok to spell out that > this protocol requires that, like what was done with disallowing > names without an alphabetic. Good catch. We have removed the incorrect and irrelevant side comment mentioning "normal DNS host name rules": Application Protocol Names may be no more than fifteen characters (not counting the mandatory underscore), consisting of only letters, digits, and hyphens, must begin and end with a letter or digit, and must contain at least one letter. The requirement to contain at least one letter is prevent service names such as "80" or "6000-6063" which could be misinterpreted as port numbers or port number ranges. While both upper case and lower case letters may be used for mnemonic clarity, case is ignored for comparison purposes, so the strings "HTTP" and "http" refer to the same service. This is however just temporary text, and will be removed entirely when draft-ietf-tsvwg-iana-ports is published. > 4. I'm not sure Section 15.2 needs to be in the document at all, > although I am not formally opposed to its inclusion. User interface considerations were a central aspect of the design constraints for DNS-SD and mDNS. Rather than design a protocol first and then work out the UI second, with DNS-SD and mDNS we first worked out the user experience we wanted, and then designed the protocols to provide that user experience. This section explains how those requirements influenced the design decisions for the protocol. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From tme@americafree.tv Tue Dec 14 18:00:56 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4C728C15B for ; Tue, 14 Dec 2010 18:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4NDf70chDsw for ; Tue, 14 Dec 2010 18:00:55 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 7660E28C0F3 for ; Tue, 14 Dec 2010 18:00:55 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id C870B96CB09E; Tue, 14 Dec 2010 21:02:36 -0500 (EST) Subject: Re: Wikipedia (was: Re: Clarification for Copyright to referred material in IETF draft) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: Date: Tue, 14 Dec 2010 21:02:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <183DE488-730D-46F0-AFC6-92710EEC7AF1@americafree.tv> References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> To: Robert Brockway X-Mailer: Apple Mail (2.1081) Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 02:00:56 -0000 On Dec 14, 2010, at 6:07 PM, Robert Brockway wrote: > On Tue, 14 Dec 2010, Marshall Eubanks wrote: >=20 >> The problem I have with this is not the content (presumably the = author of the I-D is vouching for any references they use), it's that = the content can change at any time. >=20 > Hi Marshall. Mediawiki (the software behind Wikipedia and a lot of = other sites) solved this problem years ago. It is possible to link to a = specific version of any article on a Mediawiki site. Just look for the = 'Permanent link' link on the page. >=20 > In my experience very few sites linking to Wikipedia use this = capability, proably because they don't know about it. Ideally anyone = linking to Wikipedia from an article would link to the specific version = so that the reader sees exactly what the author saw when they wrote the = article. >=20 > More recent versions of Mediawiki advise that the copy of the page is = old and provide a link to the latest version. That's fine too. >=20 > Eg, here is a link to a version of the IETF article from yesterday: >=20 > = http://en.wikipedia.org/w/index.php?title=3DInternet_Engineering_Task_Forc= e&oldid=3D390092590 Then (although this is the IESG's call and this is just my opinion), I = think that the IETF should require this usage in anything published.=20 Regards Marshall >=20 > Cheers, >=20 > Rob >=20 > --=20 > Email: robert@timetraveller.org Linux counter ID #16440 > IRC: Solver (OFTC & Freenode) > Web: http://www.practicalsysadmin.com > Contributing member of Software in the Public Interest = (http://spi-inc.org/) > Open Source: The revolution that silently changed the world > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From cheshire@apple.com Tue Dec 14 18:39:56 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9480428C0F3 for ; Tue, 14 Dec 2010 18:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.885 X-Spam-Level: X-Spam-Status: No, score=-106.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfjDf-rVOm3e for ; Tue, 14 Dec 2010 18:39:54 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 377BE3A6FD2 for ; Tue, 14 Dec 2010 18:39:54 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 066F9C41D92E for ; Tue, 14 Dec 2010 18:41:14 -0800 (PST) X-AuditID: 1180711d-b7c30ae0000055b4-eb-4d082ac9e24e Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id FE.BD.21940.9CA280D4; Tue, 14 Dec 2010 18:41:13 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [10.0.1.201] ([173.164.252.149]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDG00JXH7GPNW50@elliott.apple.com> for ietf@ietf.org; Tue, 14 Dec 2010 18:41:13 -0800 (PST) In-reply-to: <4CEC2A46.8040300@dougbarton.us> References: <4CE9F51C.2010201@dougbarton.us> <4CEC2A46.8040300@dougbarton.us> Message-id: <8392F332-80B1-4B50-990E-2A773243255A@apple.com> From: Stuart Cheshire Subject: Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt Date: Tue, 14 Dec 2010 18:41:21 -0800 To: Doug Barton X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 02:39:56 -0000 On 23 Nov 2010, at 12:55 PM, Doug Barton wrote: > Allow me to amplify my argument more completely. There are already > 2 open source implementations of dns-sd that I'm familiar with, > mDNSResponder and avahi; in addition to apple's Rendezvous. The OS > versions are mostly interoperable on the protocol level, but not on > the binary level. One example that I've been working with lately > can be found at http://www.avahi.org/ticket/303. That is an API compatibility issue. The bug report says "kDNSServiceFlagsShareConnection not implemented, affects CUPS". You won't find a mention of "kDNSServiceFlagsShareConnection" anywhere in draft-cheshire-dnsext-dns-sd-07.txt. The IETF specifies on-the-wire protocols, not APIs. There are many different implementations of DNS-SD, with different APIs, for different languages. The fact that people are complaining about subtle differences in one particular API between two different independent implementations should be a sign of how widely deployed this is. > Regarding the document itself, I have reservations about the > quality of the document, and whether or not it describes the > protocol in sufficient detail that someone starting from scratch > could develop another interoperable version. I think the Avahi bug report you found is adequate evidence of independent interoperable implementations. > However I tend to agree with the point of view that the world is a > better place if we have _a_ spec than if we have none, so I'm > specifically not asking to re-address all of the concerns that have > been discussed previously with the document. However the bit about > lower case labels should definitely be fixed (either by removal, a > citation, or a clarification that the requirement applies only to > this protocol). This has been corrected. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Dec 14 19:08:22 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4DF28C0F3; Tue, 14 Dec 2010 19:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.849 X-Spam-Level: X-Spam-Status: No, score=-106.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8rfrKs64hvC; Tue, 14 Dec 2010 19:08:20 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 1833B28C13B; Tue, 14 Dec 2010 19:08:20 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id CABCDBFA61A3; Tue, 14 Dec 2010 19:10:01 -0800 (PST) X-AuditID: 1180711d-b7c30ae0000055b4-48-4d0831899829 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id B8.C5.21940.981380D4; Tue, 14 Dec 2010 19:10:01 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Received: from [10.0.1.201] ([173.164.252.149]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDG00JPJ8SPNW60@elliott.apple.com>; Tue, 14 Dec 2010 19:10:01 -0800 (PST) In-reply-to: References: Message-id: Content-transfer-encoding: quoted-printable From: Stuart Cheshire Subject: Re: draft-cheshire-dnsext-multicastdns-12.txt Date: Tue, 14 Dec 2010 19:10:09 -0800 To: Donald Eastlake X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: IETF Discussion , secdir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 03:08:22 -0000 On 30 Nov 2010, at 9:13 AM, Donald Eastlake wrote: > I would suggest that the first word of Section 20, currently "The", =20= > should be replaced by "A major" or "One of the" or the like. Agreed. The document now says: Multicast DNS shares, as much as possible, the familiar APIs, naming syntax, resource record types, etc., of Unicast DNS. > For consistency with RFC 5395, all occurrences of "pseudo-RR" =20 > should be replace with "meta-RR" dictionary.reference.com says: > meta > > A prefix meaning one level of description higher. If X is some =20 > concept then meta-X is data about, or processes operating on, X. =20 > For example, a metasyntax is syntax for specifying syntax, =20 > metalanguage is a language used to discuss language, meta-data is =20 > data about data, and meta-reasoning is reasoning about reasoning. Is that what you mean? A "meta resource record" is a "resource record =20= about resource records". The term "pseudo-RR" means: =93false=94, =93pretended=94 or =93unreal=94. In this context the text is referring to any apparent RR in the =20 packet that's not really an RR, not solely to RRs that describe other =20= RRs. > it would not hurt to add a reference to RFC 5395 Where would you like this reference to appear? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Dec 14 21:58:19 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125443A6FE2 for ; Tue, 14 Dec 2010 21:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.642 X-Spam-Level: X-Spam-Status: No, score=-106.642 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVKsc7yLMjfQ for ; Tue, 14 Dec 2010 21:58:17 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id DA7D93A6FDF for ; Tue, 14 Dec 2010 21:58:16 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id A97B9BFB317D for ; Tue, 14 Dec 2010 21:59:58 -0800 (PST) X-AuditID: 11807136-b7b9aae0000052f6-88-4d08595edab9 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay15.apple.com (Apple SCV relay) with SMTP id A6.2A.21238.E59580D4; Tue, 14 Dec 2010 21:59:58 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [10.0.1.201] ([173.164.252.149]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDG004ABGNXXR60@et.apple.com> for ietf@ietf.org; Tue, 14 Dec 2010 21:59:58 -0800 (PST) In-reply-to: References: <20101026145701.22996.35291.idtracker@localhost> Message-id: From: Stuart Cheshire Subject: Re: Last Call: (DNS-Based Service Discovery) to Proposed Standard Date: Tue, 14 Dec 2010 22:00:06 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: draft-cheshire-dnsext-dns-sd@tools.ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 05:58:19 -0000 On 17 Nov 2010, at 11:32 PM, Pekka Savola wrote: > I have mostly heard and seen DNS-SD used in conjunction with mDNS. > I do not > know how much it has been used with regular DNS. Issues like DNS > updates > that have only received superficial attention in this document will be > present there. I'd be interested in hearing how much this is used with > regular DNS and how information is in practise stored there (manual > insertion vs dynamic updates). Many millions of Apple customers have been using DNS-SD with regular unicast DNS for since 2007. We have added this to the document: While the original focus of Multicast DNS and DNS-Based Service Discovery was for Zero Configuration environments without a conventional unicast DNS server, DNS-Based Service Discovery also works using unicast DNS servers, using DNS Update [RFC2136] to create service discovery records and standard DNS queries to query for them. Apple's Back to My Mac service, launched with Mac OS X 10.5 Leopard in October 2007, uses DNS-Based Service Discovery over unicast DNS. > Also, there is quite a bit of text that's not specific to DNS-SD > protocol, but rather how e.g. an app developer should use it. > It's not > obvious how that should be part of the main spec. I wonder if > these could > be split off to a be under a single section for clarity (e.g. > most of S 8, S 15). The entire document is talking about how an app developer should use it. "It" in this context is the domain name system. DNS-SD is not a protocol in itself. It's a usage convention for DNS records. The entire document is telling server developers what DNS records we recommend they use to describe their service, and telling client developers what DNS records we recommend they query for to discover those advertised services. It describes what app developers should pick for Instance names and Service names. It describes what data app developers should put into TXT records. If we took out all the text directed at app developers there would be virtually nothing left. They are the audience for this document. > In cases where the DNS server returns a negative > response for the name in question, client software MAY choose to > retry the query using "Punycode" [RFC 3492] encoding, beginning > with > using Punycode encoding for the top level label, and then issuing > the query repeatedly, with successively more labels converted to > Punycode each time, and giving up if it has converted all labels > to Punycode and the query still fails. > > .. would this "retry with punycode, expanding each label at a time" > result > in a typical case in at least 3 additional lookups in the case of > missing > services? Since clients only look up services they have discovered via PTR queries, discovering nonexistent services would be a rare error resulting from some bad misconfiguration. > .. it appears to me that you should provide a more precise > specification > isntead of 'a negative response'. We use 'negative response' in the usual DNS sense to mean NXDOMAIN or no-error-no-answer. > Every DNS-SD service MUST > have a TXT record in addition to its SRV record, with the same > name, > even if the service has no additional data to store and the TXT > record contains no more than a single zero byte. > > ... why? what happens if this is not the case? will the client > protocol > break down and fall to pieces? IMHO, there should be a strong > operational > and/or service publication recommendation to publish TXT records, > but on > _client_ side, this kind of mandate flies against the robustness > principle. We have added this to the document: DNS-SD clients SHOULD treat the following as equivalent: o A TXT record containing a single zero byte. (i.e. a single empty string.) o An empty (zero-length) TXT record (This is not strictly legal, but should one be received it should be interpreted as the same as a single empty string.) o No TXT record. (i.e. an NXDOMAIN or no-error-no-answer response.) > The portion of a Service Instance Name consists of a pair > of DNS labels, following the convention already established for > SRV records [RFC 2782], namely: the first label of the pair is an > underscore character followed by the Application Protocol Name, and > the second label is either "_tcp" or "_udp". > > For applications using other transport protocols, such as SCTP, > DCCP, > Adobe's RTMFP, etc., the second label of portion of its > DNS-SD name should be "_udp". > > ... this might be inappropriate overloading of UDP. The referred spec > says any protocol is valid: > > Proto > The symbolic name of the desired protocol, with an underscore > (_) prepended to prevent collisions with DNS labels that occur > in nature. _TCP and _UDP are at present the most useful > values > for this field, though any name defined by Assigned Numbers or > locally may be used (as for Service). The Proto is case > insensitive. > > ... but I suppose changing this from UDP is a non-starter for > background-compatibility perspective. If so, I suggest documenting > this as a > backward-compat solution rather than construing as if the referred > spec > required this. We have added this to the document: Note that this usage of the "_udp" label for all protocols other than TCP applies only to DNS-SD names following the conventions established by this document. Other specifications using SRV records may specify other naming conventions. > In S 8: > > To help guard against this, when there are two or more network > protocols which perform roughly the same logical function, one of > the protocols is declared the "flagship" of the fleet of related > protocols. Typically the flagship protocol is the oldest and/or > best-known protocol of the set. > > .. who makes this flagship declaration? The next paragraph appears > to imply > that it must be done when registering DNS-SD profiles with IANA (in > the > future). In which case IANA guidance would be needed. I may be > misunderstanding something. We have added this to the document: When IANA records an application protocol name registration, if the new application protocol is one that conceptually duplicates existing functionality of an older protocol, and the implementers desire the Flagship Naming behavior described in Section 8, then the registrant should request IANA to note the name of the flagship protocol in the "notes" field of the new registration. For example, the registrations for "ipp" and "pdl-datastream" both reference "printer" as the flagship protocol name for this collection of printing-related protocols. > 17. Security Considerations > > DNSSEC [RFC 2535] should be used where the authenticity of > information is important. Since DNS-SD is just a naming and usage > convention for records in the existing DNS system, it has no > specific > additional security requirements over and above those that already > apply to DNS queries and DNS updates. > > .. this is a bit weak. There's more stuff to put in DNS updates. > See the > referred sec-dir review from two years ago. The text is unchanged. The sec-dir review said "I find this inadequate" and "this document seems to need more work". Can you suggest some specific text? DNS-SD is a convention for how to name and use DNS records. Every security consideration that applies to a client using DNS queries and updates would apply to a client following the conventions in this document. Right now we have updated the document to say this: Since DNS-SD is just a naming and usage convention for records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates. For DNS queries, DNSSEC [RFC 2535] should be used where the authenticity of information is important. For DNS updates, secure updates [RFC 3007] should generally be used to control which clients have permission to update DNS records. > 18. IANA Considerations > > IMPORTANT NOTE: Once draft-ietf-tsvwg-iana-ports is published, most > of this IANA Considerations section can be deleted. > > .. I don't quite understand how draft-ietf-tsvwg-iana-ports relates > here and > more specific descriptions would be useful. Because draft-ietf-tsvwg-iana-ports documents how to register service names with IANA. > .. Is this doc expected to be published before draft-ietf-tsvwg- > iana-ports? It's not a normative reference, and if you want to wait > for that to complete, it should be recorded as normative. Normative Reference added. > Some developers have expressed concern that publicly registering > their service names (and port numbers today) with IANA before a > product ships may give away clues about that product to > competitors. > For this reason, IANA should consider allowing service name > applications to remain secret for some period of time, much as US > patent applications remain secret for two years after the date of > filing. > > .. How is this protected with current dns-sd.org maintenance > regime? Unless > you make an NDA with the party you're exposing your patent secrets > to, you're > considered to have been made information public. So creating a new > kind of > secret registration doesn't seem to cut it. Just register when > you're ready > to register? We have deleted this section. > Editorial: > ---------- > > - IANA considerations does not explicitly mention 'DNS-SD profile' > referred to in S 6 (though you can work out what you mean). Can you suggest some specific text? > For this reason, a special meta-query is defined. A DNS query > for PTR > records with the name "_services._dns-sd._udp." > > .. in the DNS-SD profiles or IANA considerations, you do not define > these > special strings that should not be registered. The "_dns-sd" string is already in the list at and will be migrated to IANA as per draft-ietf- tsvwg-iana-ports. > Similarly, what would happen if someone named their Application > instance '_sub' Nothing bad would happen. > '_printer._sub' ? Application protocol names are not allowed to contain dots. > 16. IPv6 Considerations > > IPv6 has no significant differences, except that the address of the > SRV record's target host is given by the appropriate IPv6 "AAAA" > address records instead of (or in addition to) IPv4 "A" records. > > .. well it's not obvious if you count it significant or not, but the > reverses IP entries are under a different tree and longer. This > comes up > e.g. with _dns-sd discovery of browsing domains (S 12). We have updated the document to say: IPv6 has only minor differences. The address of the SRV record's target host is given by the appropriate IPv6 "AAAA" address records instead of (or in addition to) IPv4 "A" records. Address-based Domain Enumeration queries are performed using names under the IPv6 reverse-mapping tree, which is different to the IPv4 reverse-mapping tree and has longer names in it. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From evnikita2@gmail.com Wed Dec 15 01:20:08 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C81D3A7000 for ; Wed, 15 Dec 2010 01:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.688 X-Spam-Level: X-Spam-Status: No, score=-3.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t55V2rd1lS9h for ; Wed, 15 Dec 2010 01:20:07 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 1DED33A6FFF for ; Wed, 15 Dec 2010 01:20:07 -0800 (PST) Received: by ywk9 with SMTP id 9so975543ywk.31 for ; Wed, 15 Dec 2010 01:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=O4mUDgZO7u4PnkK1hK+oz5qmNWG+ASb7ziGzOSJ+17U=; b=gJNNTPTXJyrHJtyk7GqgSfYJMj9WaonEAvdY1rVLXJmbIJjTjjmybLLHIIOQENFHTc IJaUpeBrwmYTVcyrdE2aJuvHVxor2AayAdM4YSjCXUbbSv4n08zx6gIlREFCSBbEksl5 RrhGaNlUmYdcPhTPxh5E4n7npyxyWdsCZjYB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VSDmZV3FDH30uAM7QTj+0eLL+HReX40hNJ1S0Ih9+VRBtEI9qf6LqMmc0HC5Obbe/R yngQAPumGOwRYene8us/eWfDoKxsO/4NHYnmMOdaRV4VMWGNj2MuFUG8r1v9AUdRlgiL IXBrxJWl2qS1rWnhIVu2PA4Um3oGCRFzhN/EY= MIME-Version: 1.0 Received: by 10.151.155.12 with SMTP id h12mr5565831ybo.171.1292404908534; Wed, 15 Dec 2010 01:21:48 -0800 (PST) Received: by 10.150.52.19 with HTTP; Wed, 15 Dec 2010 01:21:48 -0800 (PST) In-Reply-To: <9AEDD923-5AE2-48F7-8180-3E0E97463274@mnot.net> References: <20101213132808.2379.30041.idtracker@localhost> <4D078A60.7070403@gmail.com> <9AEDD923-5AE2-48F7-8180-3E0E97463274@mnot.net> Date: Wed, 15 Dec 2010 11:21:48 +0200 Message-ID: Subject: Re: LC comments on draft-yevstifeyev-http-headers-not-recognized-08.txt From: Mykyta Yevstifeyev To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: The IETF , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 09:20:08 -0000 Mark, Some notes on what you said: 2010/12/14, Mark Nottingham : > > On 15/12/2010, at 2:16 AM, Mykyta Yevstifeyev wrote: > >> Hello all, >> >> Let me explain some issues which were mentioned by Mark. >> >> 14.12.2010 2:09, Mark Nottingham wrote: >>> The use cases for this draft are highly speculative and unproven, even >>> for something aspiring to be Experimental. I haven't seen any >>> implementers express interest in it. >>> >>> The draft does not cover what it means for a server to "recognise" a >>> header, yet it places a MUST level requirement on this; e.g., if a server >>> doesn't actively use the "Via" header, should it list it as not >>> recognised? What about X-Forwarded-For? Deploying this on a server as-is >>> means that a lot of extra bytes will be sent in responses (and not just >>> because the field-name is so long, although that doesn't help). If the >>> client sends a 'Range' header but the server chooses not to sent a >>> partial response, should it be listed? And so on... > >> Firstly, why do we speak about extra bytes to be transferred now, almost >> in 2011? Does it seem to be a great problem? > > I can point you at lots of people who work at Amazon, Yahoo, Google, Akamai > and other large-scale Web development shops who are painfully aware of both > the costs of bandwidth (especially in many non-US markets) and the effect of > adding packets on end-user perceived latency. It matters very much. > > >> And do you really think that there will be *a lot* of such bytes? >> Secondly, 'doesn't actively use' does not mean 'not supports'. The >> examples you list are not appropriate for the situation we are discussing. >> I mean that if the server completely does not support one of headers the >> client sent, it'll form the corresponding response. > > As it sits, it's impossible to say; your draft doesn't contain the word > "supports" "actively use" or anything else to describe how this mechanism > would work in practice, nor are there examples. > Yes, you are right, my draft does not contain these issues. But for this *draft* and *last call* stand for - comments and improvements. So I'll correct it. > >> And when the client receives, it will avoid sending the corresponding >> header(s) - so, using this header will allow to save 'extra bytes', as you >> say, than spend them. The proposal has the opposite effect than you >> describe. > > To achieve that effect, you have to get widespread support in both servers > and clients. Have you had any discussions with vendors of either? > At the moment I didn't. > What are your goals here, overall? From previous discussions, I'd thought it > was to provide a debugging mechanism. Here, you express interest in saving > bytes. I suspect that having both as goals will be pulling you in different > directions... The main goal is debugging - I was only trying to persuade you that that would not make 'extra bytes' sent but would have the opposite meaning. All the best, Mykyta Yevstifeyev > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ > > > > From cheshire@apple.com Wed Dec 15 02:29:11 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121E93A7020; Wed, 15 Dec 2010 02:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.753 X-Spam-Level: X-Spam-Status: No, score=-107.753 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfa437eQ6X3b; Wed, 15 Dec 2010 02:29:08 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id B8F973A701E; Wed, 15 Dec 2010 02:29:06 -0800 (PST) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 1896DC4331C9; Wed, 15 Dec 2010 02:30:49 -0800 (PST) X-AuditID: 11807137-b7bafae00000075a-5f-4d0898d879af Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id 28.71.01882.8D8980D4; Wed, 15 Dec 2010 02:30:48 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [10.0.1.201] ([173.164.252.149]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDG007EST7C4C00@elliott.apple.com>; Wed, 15 Dec 2010 02:30:48 -0800 (PST) In-reply-to: <70A16610-D605-4719-9C8D-3D1A678DB805@estacado.net> References: <70A16610-D605-4719-9C8D-3D1A678DB805@estacado.net> Message-id: From: Stuart Cheshire Subject: Re: Gen-ART LC Review of draft-cheshire-dnsext-multicastdns-12 Date: Wed, 15 Dec 2010 02:30:58 -0800 To: Ben Campbell X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: General Area Review Team , The IETF , draft-cheshire-dnsext-multicastdns.all@tools.ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 10:29:11 -0000 On 23 Nov 2010, at 6:49 PM, Ben Campbell wrote: > *** Major issues: > > None. > > *** Minor issues: > > -- Abstract, 2nd paragraph: > > The annual fee part is not a technical issue. Seems like a bit of a > straw man here. It is however a relevant difference that no money needs to change hands when using Multicast DNS names; often it does when using unicast DNS names. > -- 5.2, 2nd paragraph: "However, there are other DNS queries where > more than one response is possible and useful, and for these > queries a more advanced Multicast DNS client should include the > ability to wait for an appropriate period of time to collect > multiple responses" > > How does a client know when it is useful to wait? I have deleted this section. > -- 6.2: > > This section seems to create a lot of work to avoid redundant > answers. Is it really worthwhile from a complexity vs efficiency > trade-off? Yes. > -- ..., 2nd paragraph: "...it SHOULD delete that answer from the > list of answers it is planning to give..." > > The previous section had a MUST level requirement for the > corresponding situation. Are they different on purpose? Previously we had thought the Multi-Packet Known Answer Suppression case might be harder to implement, but you are right. We have changed this to MUST. > -- 6.3: > > Shouldn't there be something normative in section 6.3? I have changed the "should" to capital letters. > "Planning a query" is not well defined, and its likely a querier > won't know it plans to send a query until time to send it. Is the > querier expected to remember observed queries in case it might want > to send a duplicate in the future? See "Continuous Multicast DNS Querying". All active queries have a timeline of planned future retransmissions. A Multicast DNS Querier knows when it next expects to send a given query, and if it sees an equivalent query issued by another host, then it should treat its own query as having been sent on its behalf. > -- 6.4, 1st paragraph: "...record is not less than the TTL this > host would have given..." > > Really? If the responder has a short TTL than another responder, > should the first one really let the other increase the value? Yes. In the case of misconfiguration it's important that hosts do not create a packet storm fighting about it. > -- section 7.6: > > I assume this is for backwards compatibility with existing deployed > implementations? If so, it would be worth mentioning that.? I have changed the document to say: If the source UDP port in a received Multicast DNS Query is not port 5353, this indicates that the client originating the query is a simple client that does not fully implement all of Multicast DNS, as described in Section 5.1 "One-Shot Multicast DNS Queries". > -- 8.1, 4th paragraph: "250ms after the first query the host should > send a second, then 250ms after that a third. If, by 250ms after > the third probe, no conflicting Multicast DNS responses have been > received, the host may move to the next step, announcing." > > Normative? Yes, but in the English language sense, not an RFC 2119 keyword. > -- 8.2, 2nd paragraph: "...the Authority Section must contain *all* > the records ..." > > Normative? Yes. Are you complaining that it's not clear what the sentence means unless some of the words are in all-capitals? > -- ..., 3rd paragraph: "The two records are compared and the > lexicographically later data wins." > > Seems like there might should be something normative there. > > -- ..., last paragraph: "Note that it is vital..." > > That would seem to imply something normative? Yes. I believe it is acceptable to write a specification using English. RFC 2119 keywords are sometimes useful for clarity, but I don't believe there is any requirement that every normative sentence contain at least one of them. > -- 8.3, 4th paragraph: "A Responder MAY send up to eight > gratuitous Responses, provided that the interval between gratuitous > responses increases by at least a factor of two with every response > sent." > > Why the option? When would a responder want to send more than two? The same reason TCP retransmits more than once: Packet loss. > -- 8.4, 1st paragraph: > > No need to repeat the probe? No. The host does not need to repeat the Probing step because it has already established unique ownership of that name. > -- 10, 1st paragraph: "As a general rule, the recommended TTL > value..." > > Normative? Yes. > -- ..., 3rd paragraph: "A client with an active outstanding query > will issue a query packet when one or more of the resource record > (s) in its cache is (are) 80% of the way to expiry." > > What does an outstanding query have to do with it? Do you mean to > say a cached record? See "Continuous Multicast DNS Querying". On your Mac or Windows machine type: "dns-sd -B _http._tcp". Now you have an active query. Press Ctrl-C. Now you cancelled it. > -- section 12, 3rd paragraph: "This characteristic is not unique to > Multicast DNS. Although the original concept of DNS was a single > global namespace, in recent years split views, firewalls, > intranets, and the like have increasingly meant that the answer to > a given DNS query has become dependent on the location of the > querier." > > I don't think this is a fair comparison, as it was not the intent > of the protocol designers for dns to be location specific, and many > would consider this an abuse of the protocol. OTOH, m-dns is, if I > understand correctly, is _intended_ to be location specific. The comment in parentheses is not a comparison. It does not state intent. It is merely an observation about current reality. > -- ..., 6th paragraph: "There are no NS records anywhere in > Multicast DNS Domains." > > Normative? Yes. > -- 14, 1st paragraph: "The option to fail-over to Multicast DNS for > names not ending in ".local." SHOULD be a user-configured option, > and SHOULD be disabled by default because of the possible security > issues related to unintended local resolution of apparently global > names." > > I have trouble imagining any safe circumstance to enable this. Can > you offer an example? On an isolated network, or on some future machine that exclusively uses DNSSEC for all DNS queries, thereby guarding itself against spoofing. > -- 15, 5th paragraph: "While this kind of name duplication should > be rare,..." > > Why should it be rare? Because users generally name their devices intelligently. Over the last eight years this kind of name duplication has not been a common problem. > -- 17, paragraph 1: > > How does this historical note relate to IDNA? Do you mean to say > that IDNA is not needed for mdns? It would be nice to have some > consistency here. Yes, IDNA is not needed for Multicast DNS. > -- ..., last paragraph > > If a CNAME record creates a name conflict, will m-dns > implementations notice and defend against it? A query for the name will generate a response which will signal a name conflict like any other response would. > -- 18, paragraph 3: "... specialized cases where the implementer > knows that all receivers implement reassembly." > > How could an implementor know this? Can you list some example > cases? It seems to me that, unless we know of such cases in > advance, it might be better to just forbid this. For example, factory floor CNC equipment, using Multicast DNS over a private Ethernet network. This is a mostly proprietary marketplace, and CNC equipment manufacturers know pretty precisely the capabilities of their other proprietary equipment on the network. > -- ..., last paragraph: > > If jumbo packets are rare, why not just stick to the 1500 limit? Some applications today need more than 1500-byte payloads. > -- 19.1, paragraphs 1 and 2: > > The first two paragraphs seem to make normative statements that are > redundant with the rest of the document. It's best to either state > this descriptively, or clearly attribute the requirements to the > authoritative sections. Otherwise if there is a conflict, it may > not be clear to the reader which text is authoritative. Can explain specifically what part you think is redundant, and suggest better text. > -- 19.14, paragraph 5: "Until future IETF Standards Action > specifying that names in the rdata of other types should be > compressed, names that appear within the rdata of any type not > listed above MUST NOT be compressed." > > Is this a new normative requirement, or a restatement of some > existing DNS rule that could be referenced? It is a normative requirement for Multicast DNS (this document). > -- 22, paragraph 3: "In an environment where there is a group of > cooperating participants, but there may be other antagonistic > participants on the same physical link,..." > > I think the sense of this should be more along the lines of "in all > environments where clients cannot be sure in advance that no > antagonistic hosts can exist on the same segment" or something to > that effect. Too many network managers naively believe that no > hostile devices can exist on their networks. I made this change. > -- ..., paragraph 4: "... it is *especially* important..." > > Normative? No. > -- 23, paragraph 4: > > This section needs to request registration of an explicit new IANA > table along with the criteria for adding new entries, or explicitly > reference an existing registry, then register the entries. Don't > expect IANA to infer this. Also, is suspect language like "IANA > should" would br better stated as "this document requests IANA to > register..." This is now covered by > -- ..., numbered list: > > Are you asking IANA to do something with the information about > special treatment of the multicast domains? That level of detail > would be unusual in an IANA registry--more likely they would just > reference this document for details. If you aren't asking them for > specific action about this information, then it should go elsewhere > in the document. This now the "Domain Name Reservation Considerations" section. > -- ..., list item 1, 2nd paragraph: > > I'm very skeptical about normative statements of the form of "users > SHOULD be aware...". What should _implementors_ do? See > -- ..., list items 4-7: > > These seem to put requirements on devices that do not implement > this spec. Why would the implementors of such even read this? No. Only devices that claim compliance with this spec have to follow these requirements. No RFC can impose requirements on any implementer unless that implementer voluntarily chooses to comply with the RFC. RFCs are not laws. > -- ..., 2nd to last paragraph: > > Again, this needs to be more explicit about what is requested from > IANA. IANA has clarified they understand this. > --, 25.2, "[B4W]" reference: > > Is it reasonable to reference something as ephemeral as wikipedia, > even for an informative reference? Remember RFCs live a long time. People objected to the apple.com reference so we changed it to wikipedia as being more neutral. > -- Appendix A: > > Please describe the conclusions, not just the arguments. Arguments were made for and against using Multicast on UDP port 53. The arguments for using a different port were greater in number and more compelling so the final decision was to use UDP port 5353. > *** Nits/editorial comments: > > -- Idnits shows 2 warnings and 3 comments. Please check. Checked. > -- general: > > I would like to have seen some general, non-normative, discussion > on how this all works together before jumping deep into protocol > details. I was fairly well into the document before I understood > the transaction-stateless nature of the mechanism. The document is already long. Others have been asking us to delete non-normative discussion. > -- 5.3, 5th paragraph: "To perform this cache maintenance, a > Multicast DNS Querier should plan to re-query for records after at > least 50% of the record lifetime has elapsed. This document > recommends the following specific strategy:" > > It might be helpful to include a note about the difference between > retransmitting a query vs re-querying. There is no difference between retransmitting a query vs re-querying. > -- Section 7: > > This section needs some subsections, or other organization. As it > is, it jumps from one topic to the next with little transition and > is hard to follow. We have already done many edits to try to organize this section into the best order we can. > -- ..., 2nd paragraph: "The record name must match the question > name, the record rrtype must match the question qtype unless the > qtype is "ANY" (255) or the rrtype is "CNAME" (5), and the record > rrclass must match the question qclass unless the qclass is "ANY"" > > References? Also, should the musts here be normative? Yes. > --... 5th paragraph: "A Multicast DNS Responder on Ethernet [IEEE. > 802.3] and similar shared multiple access networks..." > > Do you expect responders to vary behavior depending on the > underlying network type? We expect implementers using networks substantially dissimilar to Ethernet to consider whether the stated time constants are applicable for their network. > -- ..., later same paragraph: "...determined by the rules described > below." > > The way things are organized, it's hard to tell where the > referenced rules start and stop. It doesn't really matter very much. It is merely introduction to the text that follows. > -- 7.1, 5th paragraph from end: "For example, the TTL for address > records in Multicast DNS is typically 120 seconds, so the negative > cache lifetime for an address record that does not exist should > also be 120 seconds." > > Reference? Fixed. > -- ..., 4th paragraph from end: "name/rrtype/rrclass" > > Please avoid using a slash as a conjunction substitute. Can you explain what you'd like to see instead? > "(e.g. for reverse address..." > > For, or From? e.g. names of reverse address mapping PTR records, which are derived from IP addresses, and therefor can be assumed to be already unique. > -- section 7.3, last paragraph: "...SHOULD be randomly delayed in > the range 20-120ms, or 400- 500ms if the TC (truncated) bit is set, > as described above." > > Isn't this redundant with previous sections? No. Unlike single-question queries where responding without delay is allowed in appropriate cases, for query packets containing more than one question all (non-defensive) answers SHOULD be randomly delayed in the range 20-120ms, or 400-500ms if the TC (truncated) bit is set. > -- 8.1, 6th paragraph: "At the present time, this document > recommends..." > > Do you expect this to change? Good point. Removed. > -- 8.2, 4th paragraph: > > Inconsistent usage between "the host" and "ourself". Probably best > not to anthropomorphize. Changed to "from the host itself" > -- 8.2.1: > > Inconsistent section hierarchy. The single record case was in the > parent section, but the multiple level case has its own subsection. 8.2.1 is a continuation and elaboration of 8.2. > -- 8.3, 1st paragrah: "gratuitous" > > That seems the wrong choice of words, since such responses are not > "without cause or reason" which is the usual dictionary definition. > Maybe "unsolicited"? (No problem if this is some DNS term of art > that I haven't heard.) Changed. > -- ..., last paragraph: "as described below in "Conflict Resolution"." > > Section number cross-references would be helpful. Fixed. > -- 9, indented paragraph after numbered list item 5: > > It's not clear to me if this is supposed to refer to just item 5, > or to item 4 and 5. In any case, the advise that one may simply not > notify does not seem helpful for case 5. Thanks. That text was supposed to apply to item 4. > -- 11, 1st paragraph: "These older clients discard all packets with > TTLs other than 255." > > Can you provide a reference for this behavior? How old is old? This includes things like network printers implementing draft- cheshire-dnsext-multicastdns-04.txt, published February 2004. Some of these printers are still around today. > -- 12, 4th paragraph: "The IPv4 name server for a Multicast DNS > Domain is 224.0.0.251. The IPv6 name server for a Multicast DNS > Domain is FF02::FB." > > Name server _address_? Changed. > -- ..., 6th paragraph: "...delegation of all Multicast DNS Domains > to the 224.0.0.251:5353 and [FF02::FB]:5353,..." > > Missing words? Fixed. > -- ..., 7th paragraph: > > Please expand SOA on first mention Fixed. > -- 15, last paragraph: > > Can you provide section cross references for these safeguards? Fixed: Section 10.3 > -- 13: > > Seems like this should be stated early in the document, in the > intro, or in a scope section or applicability statement. ? > -- 16.3: "...each have their own..." > > its own I disagree: "clients" is plural. > -- 17, 3rd paragraph from end: > > This seems to imply there are no "letters" in UTF8 outside the > ASCII range. Fixed. > -- ..., last paragraph: "The simple rules for case-insensitivity in > Unicast DNS also apply..." > > Reference? Fixed: [RFC1034] [RFC1035] > -- 18, paragraph 3: "...,a Multicast DNS Responder SHOULD send the > Resource Record alone, in a single IP datagram, sent using multiple > IP fragments." > > I have trouble parsing this clause. Should "sent using" just be > "using"? Changed. > -- ..., 2nd to last paragraph: "Ethernet "Jumbo" packet" > > Reference? Added reference. > -- 19.2 and 19.3: > > Incomplete sentences Fixed. > -- 19.12 and 19.13: > > References to normative text? Fixed. > -- 20, paragraph 1: "The value of Multicast DNS is..." > > Is assume you mean "a value..." or "one value..."? Changed: Multicast DNS shares, as much as possible, the familiar APIs, naming syntax, resource record types, etc., of Unicast DNS. > -- 23, paragraphs 1 and 2: > > Can you provide references or pointer to the existing registrations? Added references. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From eburger-l@standardstrack.com Wed Dec 15 04:16:31 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DF83A6F7E for ; Wed, 15 Dec 2010 04:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAaCY0RcP2Sw for ; Wed, 15 Dec 2010 04:16:30 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [66.117.4.68]) by core3.amsl.com (Postfix) with ESMTP id B108B3A6E3A for ; Wed, 15 Dec 2010 04:16:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=H20jt4AY6x1n0yUGVoXDenElz2upfH3loOszLPK2TbP7qVeX4C1AaMCIMhhubNAwrh55S6QzSVhAd4b9f3U1f/t1T6NT0DOkcxGjIEwHplLuT8n3AtFNOSPZ0wgmRos7; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.184]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PSqIv-0008L8-Aa for Ietf@ietf.org; Wed, 15 Dec 2010 04:17:57 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: Clarification for Copyright to referred material in IETF draft From: Eric Burger In-Reply-To: Date: Wed, 15 Dec 2010 07:18:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101214124034.D5F9C6BE5F2@mercury.lcs.mit.edu> To: Ietf@ietf.org X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 12:16:31 -0000 [Soapbox warning] I love it! Finally a use for Informational RFC's that I get: Let's turn = Wikipedia pages into RFC's! [NOT] On Dec 14, 2010, at 10:42 AM, Marshall Eubanks wrote: >=20 > On Dec 14, 2010, at 7:40 AM, Noel Chiappa wrote: >=20 >>> From: Simon Josefsson >>=20 >>> Wikipedia has .. stable URLs, which makes it on par or better than >>> other external references. >>=20 >> That's a sad truth - I find link-rot is an incredible problem with = references >> when I'm looking at older material; stuff seems to go offline all the = time, >> even valuable material. The company decides to redo their website, or = someone >> moves to a new organization, or, or, or... >=20 > The IETF probably should archive any material used as a reference in = an RFC, at the time the RFC is published. I do not believe that this = would cause copyright issues (note : IANAL), but making that archive = publicly available might. Maybe we could do something there in = connection with the Internet Archive. >=20 > Regards > Marshall >=20 >>=20 >> Noel >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >>=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From fweimer@bfk.de Wed Dec 15 07:36:24 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90FB128C177 for ; Wed, 15 Dec 2010 07:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0TPwDO-5+0m for ; Wed, 15 Dec 2010 07:36:23 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id CD1F928C176 for ; Wed, 15 Dec 2010 07:36:20 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PStQU-0004vg-E6; Wed, 15 Dec 2010 15:37:58 +0000 Received: by bfk.de with local id 1PStQU-0006oW-91; Wed, 15 Dec 2010 15:37:58 +0000 To: Marshall Eubanks Subject: Re: Wikipedia References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> From: Florian Weimer Date: Wed, 15 Dec 2010 15:37:58 +0000 In-Reply-To: <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> (Marshall Eubanks's message of "Tue\, 14 Dec 2010 15\:27\:37 -0500") Message-ID: <821v5jqc6h.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 15:36:24 -0000 * Marshall Eubanks: > The problem I have with this is not the content (presumably the > author of the I-D is vouching for any references they use), it's > that the content can change at any time. I think that's why you're supposed to add a retrieved date to your citation. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From vesely@tana.it Wed Dec 15 08:22:42 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B9128C18B for ; Wed, 15 Dec 2010 08:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.268 X-Spam-Level: X-Spam-Status: No, score=-5.268 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm6ezjUZQ5SB for ; Wed, 15 Dec 2010 08:22:41 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 23BE828C18A for ; Wed, 15 Dec 2010 08:22:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1292430262; bh=J+h1XJEg4zKMQ71qLD25zYBVf3C5wzO7Jz7nsLtMx8Y=; l=886; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=BoTJm7UD4cLE1vs5BNwytHae6mbwcjJt8W0iLe2voVMjXWD1cMktHKhx1O4p29Bf/ GB9KNc3bM+87iF/j8baI8g2chJ7hAD6fulARypOXkC1etcw4dn2eZJXJpGvjzPZU9x CIDebEibPwguI85iDyuyrfk67MdaBCgPKEjTc/Hc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 15 Dec 2010 17:24:22 +0100 id 00000000005DC047.000000004D08EBB6.00000DD9 Message-ID: <4D08EBB5.5050105@tana.it> Date: Wed, 15 Dec 2010 17:24:21 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Wikipedia References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> <183DE488-730D-46F0-AFC6-92710EEC7AF1@americafree.tv> In-Reply-To: <183DE488-730D-46F0-AFC6-92710EEC7AF1@americafree.tv> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 16:22:42 -0000 On 15/Dec/10 03:02, Marshall Eubanks wrote: > On Dec 14, 2010, at 6:07 PM, Robert Brockway wrote: >> Eg, here is a link to a version of the IETF article from yesterday: >> >> http://en.wikipedia.org/w/index.php?title=Internet_Engineering_Task_Force&oldid=390092590 > > Then (although this is the IESG's call and this is just my > opinion), I think that the IETF should require this usage in > anything published. IMHO, whether to use temporal coordinates (where available) should be left to authors' judgment. Some authors diligently monitor the relevant Wikipedia pages. For symmetric citations, I'd note that Mediawiki recognizes inline references to RFCs[1] and that Wikipedia has a "Cite IETF"[2] template. There seems to be room for tighter cooperation... [1] http://www.mediawiki.org/wiki/Manual:RFC [2] http://en.wikipedia.org/wiki/Template:Cite_IETF From ajs@shinkuro.com Wed Dec 15 08:35:27 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE6428C19F for ; Wed, 15 Dec 2010 08:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUO55eHLzt69 for ; Wed, 15 Dec 2010 08:35:26 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9751828C19A for ; Wed, 15 Dec 2010 08:35:26 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8A9F01ECB41D for ; Wed, 15 Dec 2010 16:37:08 +0000 (UTC) Date: Wed, 15 Dec 2010 11:37:06 -0500 From: Andrew Sullivan To: ietf@ietf.org Subject: Re: Wikipedia Message-ID: <20101215163706.GE87411@shinkuro.com> References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> <183DE488-730D-46F0-AFC6-92710EEC7AF1@americafree.tv> <4D08EBB5.5050105@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D08EBB5.5050105@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 16:35:27 -0000 On Wed, Dec 15, 2010 at 05:24:21PM +0100, Alessandro Vesely wrote: > On 15/Dec/10 03:02, Marshall Eubanks wrote: > IMHO, whether to use temporal coordinates (where available) should be > left to authors' judgment. Some authors diligently monitor the > relevant Wikipedia pages. It makes no difference whether authors monitor the relevant Wikipedia pages, because you can't update the references section of the RFC once it's published. I find it slightly astonishing that the RFC Editor's instuctions on URLs don't require a visited-on parameter. Just about every academic style guide requires such a note for the obvious reason that the target of a URL can change. The whole reason we have the citation traditions we do is so that someone can follow the reference later and look up the material in question. This is an important feature of any reference, because without it the citation is all but worthless: it does nobody any good if you include a citation and then nobody can check whether you understood (or even quoted) the material correctly. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dworley@avaya.com Wed Dec 15 08:46:28 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C3328C105 for ; Wed, 15 Dec 2010 08:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xELlsdYUK25y for ; Wed, 15 Dec 2010 08:46:27 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 9286F3A7069 for ; Wed, 15 Dec 2010 08:46:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANN/CE3GmAcF/2dsb2JhbACkK3OpewKZN4VKBIRkiUc X-IronPort-AV: E=Sophos;i="4.59,349,1288584000"; d="scan'208";a="50183367" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 15 Dec 2010 11:48:08 -0500 X-IronPort-AV: E=Sophos;i="4.59,349,1288584000"; d="scan'208";a="556078909" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Dec 2010 11:48:07 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 15 Dec 2010 11:47:36 -0500 From: "Worley, Dale R (Dale)" To: Andrew Sullivan , "ietf@ietf.org" Date: Wed, 15 Dec 2010 11:43:31 -0500 Subject: RE: Wikipedia Thread-Topic: Wikipedia Thread-Index: AcucdnLuazkHUeKcQhS3zcBXcwyRhQAAMIeX Message-ID: References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> <183DE488-730D-46F0-AFC6-92710EEC7AF1@americafree.tv> <4D08EBB5.5050105@tana.it>,<20101215163706.GE87411@shinkuro.com> In-Reply-To: <20101215163706.GE87411@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 16:46:28 -0000 ________________________________________ From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Andrew Sul= livan [ajs@shinkuro.com] I find it slightly astonishing that the RFC Editor's instuctions on URLs don't require a visited-on parameter. Just about every academic style guide requires such a note for the obvious reason that the target of a URL can change. _______________________________________________ I see this in the 22 Sep 2009 draft of the instructions: The use of URLs in references in RFCs is generally discouraged, because URLs are often not stable. On the other hand, there are cases where a URL is demonstrably the most stable reference available for some reference. and URLs and DNS names in RFCs The use of URLs in RFCs is discouraged, because many URLs are not stable references. Exceptions may be made for normative references in those cases where the URL is demonstrably the most stable reference available. References to long-lived files on ietf.org and rfc-editor.org are generally acceptable. Given that, I would expect that a URL that is "demonstrably the most stable= reference available" would suggest that the contents of the URL at any dat= e near the publication date of the RFC "should" yield the same contents. I= f an RFC references a URL that is unstable enough for us to notice and comp= lain about it, the URL should not have been used in the first place. Dale From Jeff.Hodges@KingsMountain.com Wed Dec 15 08:57:27 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D187928C1B9 for ; Wed, 15 Dec 2010 08:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk7IfCywXY51 for ; Wed, 15 Dec 2010 08:57:26 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id D94C328C1B4 for ; Wed, 15 Dec 2010 08:57:25 -0800 (PST) Received: (qmail 13243 invoked by uid 0); 15 Dec 2010 16:59:04 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com.bluehost.com with SMTP; 15 Dec 2010 16:59:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=r4UoU19dVQJJpcsuqEM48cIOGlpzPceAUSxUQGN3cu8LYYdH8L2zzA1ko48VHUvbxPdhTLoB6UsnaqeU//xGlmK5Xdguj2pvvNmUmyJwTySg/34mwp8dPKKC9uKYetO3; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.140]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PSugv-0003ux-OP for ietf@ietf.org; Wed, 15 Dec 2010 09:59:02 -0700 Message-ID: <4D08F3D5.9060603@KingsMountain.com> Date: Wed, 15 Dec 2010 08:59:01 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF Discussion List Subject: Re: Second Last Call: draft-saintandre-tls-server-id-check to BCP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 16:57:28 -0000 fyi (technically, the 2nd last call ends tomorrow)... Subject: [certid] version 12 From: Peter Saint-Andre Date: Mon, 13 Dec 2010 12:49:49 -0700 (11:49 PST) To: IETF cert-based identity Cc: Ben Campbell Jeff and I have published version -12. The changes were driven by the Gen-ART review that Ben Campbell did, some feedback from our sponsoring Area Director, a few list discussions, and several rounds of editorial improvement. http://www.ietf.org/id/draft-saintandre-tls-server-id-check-12.txt The diff from -11 is here: http://tools.ietf.org/rfcdiff?url2=draft-saintandre-tls-server-id-check-12.txt Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@shinkuro.com Wed Dec 15 08:59:26 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC6B28C1C4 for ; Wed, 15 Dec 2010 08:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDiagthLVUCn for ; Wed, 15 Dec 2010 08:59:26 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 1381B28C1C3 for ; Wed, 15 Dec 2010 08:59:26 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 70E331ECB41D for ; Wed, 15 Dec 2010 17:01:08 +0000 (UTC) Date: Wed, 15 Dec 2010 12:01:06 -0500 From: Andrew Sullivan To: ietf@ietf.org Subject: Re: Wikipedia Message-ID: <20101215170106.GF87411@shinkuro.com> References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> <183DE488-730D-46F0-AFC6-92710EEC7AF1@americafree.tv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 16:59:26 -0000 On Wed, Dec 15, 2010 at 11:43:31AM -0500, Worley, Dale R (Dale) wrote: > Given that, I would expect that a URL that is "demonstrably the most > stable reference available" would suggest that the contents of the > URL at any date near the publication date of the RFC "should" yield > the same contents. If an RFC references a URL that is unstable > enough for us to notice and complain about it, the URL should not > have been used in the first place. But as I tried to explain in my note, _it doesn't matter_ whether the URL is stable during the time you happen to be checking. When you make a reference to a book, magazine article, or newspaper column, you always include information like the series, edition, publication date, and so on. This isn't for decoration; it's there so that later, if someone wanted to look the thing up again, they could. Such a desire could happen years later. (Irrelevant aside: In a previous career I was regularly reading things about eighty years old, but I could still follow the citations back to the source that my author had been reading. In one case, this turned out to be really significant because my author happened to be reading a really bad translation, and a fundamental part of his confusion was easily explained once you realised that the translation he'd been working with sucked.) In the age of the web, this ability is almost certainly lost. We can, however, at least know from the citation when the information was current. That knowledge alone could turn out to be useful. Suppose, for instance, that it's necessary to refer to evidence gathered by the foobar project, and that the foobar project only publishes its stuff on its website. The URL of the website is certainly the most authoritative source, and therefore the most stable reference available, because it happens to be the only such reference. Now, if you happen to know that version 1 of the foobar project (call it wikifoobar) was maintained until 12 December 2010, when a fork happened and version 2 (call it openfoobar) competed with version 1 for being the "correct" version, then knowing that the reference was generated on 30 November 2010 will give you a pretty good clue about what version of the foobar project you need to go chase, even years later. RFCs form an archival series, and we need to use archival-series rules for references in them. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jnc@mercury.lcs.mit.edu Wed Dec 15 09:02:24 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79D13A6FA8 for ; Wed, 15 Dec 2010 09:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEoqoSbvPXy2 for ; Wed, 15 Dec 2010 09:02:24 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0AE833A6EB6 for ; Wed, 15 Dec 2010 09:02:23 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 268C96BE5A5; Wed, 15 Dec 2010 12:03:57 -0500 (EST) To: ietf@ietf.org Subject: Re: Wikipedia Message-Id: <20101215170401.268C96BE5A5@mercury.lcs.mit.edu> Date: Wed, 15 Dec 2010 12:03:57 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 17:02:24 -0000 > From: Andrew Sullivan > I find it slightly astonishing that the RFC Editor's instuctions on > URLs don't require a visited-on parameter. Just about every academic > style guide requires such a note for the obvious reason that the target > of a URL can change. The whole reason we have the citation traditions > we do is so that someone can follow the reference later and look up the > material in question. This is an important feature of any reference, > because without it the citation is all but worthless: it does nobody > any good if you include a citation and then nobody can check whether > you understood (or even quoted) the material correctly. Actually, as someone pointed out, in some sense dated URLs to Wikipedia pages are in fact _superior_ to most other Web URL references, because in Wikipedia you can go back into the history and see just what the page looked like when the author visited it. And as someone else pointed out, there's a way to link to _that specific version_. With most other web pages, there's no way to do either one of those... So maybe we should _encourage_ Wikipedia citations... :-) Noel From ajs@shinkuro.com Wed Dec 15 09:06:49 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C0628C1D5 for ; Wed, 15 Dec 2010 09:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3b+WLJu5HMY for ; Wed, 15 Dec 2010 09:06:48 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 65D5E28C1CB for ; Wed, 15 Dec 2010 09:06:48 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9B5C81ECB41D for ; Wed, 15 Dec 2010 17:08:30 +0000 (UTC) Date: Wed, 15 Dec 2010 12:08:28 -0500 From: Andrew Sullivan To: ietf@ietf.org Subject: Re: Wikipedia Message-ID: <20101215170827.GG87411@shinkuro.com> References: <20101215170401.268C96BE5A5@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101215170401.268C96BE5A5@mercury.lcs.mit.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 17:06:49 -0000 On Wed, Dec 15, 2010 at 12:03:57PM -0500, Noel Chiappa wrote: > Actually, as someone pointed out, in some sense dated URLs to Wikipedia pages > are in fact _superior_ to most other Web URL references, because in Wikipedia > you can go back into the history and see just what the page looked like when > the author visited it. Yes, but you can only do that if (1) the author uses the particular-version URL or (2) the author includes a visited-on note in the citation. It's lovely, however, that in wiki-based systems you do have this ablity, and I agree that it'd be nice to encourage its use. (Now I'm going to crawl back into my bibliographic maniac's hole and stop talking about this.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From julian.reschke@gmx.de Wed Dec 15 09:16:17 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0170128C1A4 for ; Wed, 15 Dec 2010 09:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.778 X-Spam-Level: X-Spam-Status: No, score=-104.778 tagged_above=-999 required=5 tests=[AWL=-2.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTSfyEtggS+S for ; Wed, 15 Dec 2010 09:16:16 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id A6AF428B56A for ; Wed, 15 Dec 2010 09:16:13 -0800 (PST) Received: (qmail invoked by alias); 15 Dec 2010 17:17:55 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 15 Dec 2010 18:17:55 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19jIYl0PuNjbYBC2eryY8IIbAXtEm9Ad8GQMrliWQ bMhcS7kuMzqWaJ Message-ID: <4D08F840.8000704@gmx.de> Date: Wed, 15 Dec 2010 18:17:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tony Hansen Subject: Re: Wikipedia References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> <4D07DD5A.6030400@att.com> In-Reply-To: <4D07DD5A.6030400@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 17:16:17 -0000 On 14.12.2010 22:10, Tony Hansen wrote: > On 12/14/2010 3:27 PM, Marshall Eubanks wrote: >> The problem I have with this is not the content (presumably the author >> of the I-D is vouching for any references they use), it's >> that the content can change at any time. > > The problem with referencing *any* web page, whether it's Wikipedia or > otherwise, is that the content can change at any time. So you not only > need spatial coordinates (the URL), but also the temporal coordinates > (date and time) for *when* the pertinent data was accessed and found to > be on that web page. > ... It depends. There are cases where you *want* the current version, not the one current when the document was published. For instance, has: > This is not an exhaustive list. Many more are supported by numerous > applications. For more examples, consult Wikipedia's entry on the > "about: URI Scheme" [wikiabout]. ...which I personally think is totally fine. Best regards, Julian From tony@att.com Wed Dec 15 09:22:42 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC3928C1DD for ; Wed, 15 Dec 2010 09:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.414 X-Spam-Level: X-Spam-Status: No, score=-106.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv4SGU4Hip-d for ; Wed, 15 Dec 2010 09:22:41 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id CD65F28C1DB for ; Wed, 15 Dec 2010 09:22:40 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-167.messagelabs.com!1292433860!44477144!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 5965 invoked from network); 15 Dec 2010 17:24:22 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Dec 2010 17:24:22 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBFHOdPG025791 for ; Wed, 15 Dec 2010 12:24:40 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBFHOc68025778 for ; Wed, 15 Dec 2010 12:24:38 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBFHOHdk024336 for ; Wed, 15 Dec 2010 12:24:18 -0500 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBFHOEVT024151 for ; Wed, 15 Dec 2010 12:24:14 -0500 Received: from [135.91.110.230] (ds135-91-110-230.dhcps.ugn.att.com[135.91.110.230]) by maillennium.att.com (mailgw1) with ESMTP id <20101215172414gw1004lkcqe> (Authid: tony); Wed, 15 Dec 2010 17:24:14 +0000 X-Originating-IP: [135.91.110.230] Message-ID: <4D08F9BD.4010700@att.com> Date: Wed, 15 Dec 2010 12:24:13 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Wikipedia References: <20101215170401.268C96BE5A5@mercury.lcs.mit.edu> <20101215170827.GG87411@shinkuro.com> In-Reply-To: <20101215170827.GG87411@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 17:22:42 -0000 On 12/15/2010 12:08 PM, Andrew Sullivan wrote: > Yes, but you can only do that if (1) the author uses the > particular-version URL or (2) the author includes a visited-on note in > the citation. It's lovely, however, that in wiki-based systems you do > have this ablity, and I agree that it'd be nice to encourage its use. This indicates to me that the one of the checks the RFC Editor and possibly idnits should do is whether or not such citations have a "date accessed" notation. Tony From tme@americafree.tv Wed Dec 15 09:37:57 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBCB28C10A for ; Wed, 15 Dec 2010 09:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.123 X-Spam-Level: X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkLz2IsbFOxA for ; Wed, 15 Dec 2010 09:37:56 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id A84CA28C11E for ; Wed, 15 Dec 2010 09:37:55 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 95FED96DD68D; Wed, 15 Dec 2010 12:39:37 -0500 (EST) Subject: Re: Wikipedia Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <20101215163706.GE87411@shinkuro.com> Date: Wed, 15 Dec 2010 12:39:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> <183DE488-730D-46F0-AFC6-92710EEC7AF1@americafree.tv> <4D08EBB5.5050105@tana.it> <20101215163706.GE87411@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 17:37:57 -0000 On Dec 15, 2010, at 11:37 AM, Andrew Sullivan wrote: > On Wed, Dec 15, 2010 at 05:24:21PM +0100, Alessandro Vesely wrote: >> On 15/Dec/10 03:02, Marshall Eubanks wrote: >=20 >> IMHO, whether to use temporal coordinates (where available) should be >> left to authors' judgment. Some authors diligently monitor the >> relevant Wikipedia pages. Dear Andrew; By some magic of cut and paste this was assigned to me, but it was = apparently written by Alessandro Vesely . I actually don't agree with that and think that "temporal coordinates" = (such as=20 >> = http://en.wikipedia.org/w/index.php?title=3DInternet_Engineering_Task_Forc= e&oldid=3D390092590 ) should be used for any actual reference*. I even wonder if URL = references should include a cryptographic hash of the content so that users can = verify it is in fact unchanged.=20 Regards Marshall * I can see that it might be useful in some cases to have references = such as to the URL for IANA port assignments, where the current version is what's wanted, but = that is not the common use of a reference. >=20 > It makes no difference whether authors monitor the relevant Wikipedia > pages, because you can't update the references section of the RFC once > it's published. >=20 > I find it slightly astonishing that the RFC Editor's instuctions on > URLs don't require a visited-on parameter. Just about every academic > style guide requires such a note for the obvious reason that the > target of a URL can change. The whole reason we have the citation > traditions we do is so that someone can follow the reference later and > look up the material in question. This is an important feature of any > reference, because without it the citation is all but worthless: it > does nobody any good if you include a citation and then nobody can > check whether you understood (or even quoted) the material correctly. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From evnikita2@gmail.com Wed Dec 15 09:46:13 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B770628C1AB for ; Wed, 15 Dec 2010 09:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJBaVSftxfnf for ; Wed, 15 Dec 2010 09:46:13 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id C7FA228C107 for ; Wed, 15 Dec 2010 09:46:12 -0800 (PST) Received: by bwz8 with SMTP id 8so2574454bwz.38 for ; Wed, 15 Dec 2010 09:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=mLrz+Q71J2loQ4Rfin38NfufTa5H9Oy9mbMz/F3/hsw=; b=XoOldLFCELxV+HVeqW3eraB1J1O9YDOghylNYKTMkNaXTgFK6QrDLgdiddxyDu0eQG 9i+bzDq+1bZ097U02jrxugEpG8nffWAUv6pqYS53buGx9JbLZsZgvJf+1/Y5ddq3So1L Qh2ARs1eMgGrJ6ePwreOmjOoB0CibguRGP0bE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=CTrprEQdOhHkdnikcTvC8Tt7EtVNY0oaySgZevK1swLJ3ykyOD3mdnW/w+sNmkTnCB eJKB3nkgleSXfbpGCfXWKb/4gRL4k88y4hcV/+d6TNmoVqMYw5LgOM37s3l3KCQuUuIi mIwwmnnuShYmXwnttmtROKkZ8ysiSrN0WPJXo= Received: by 10.204.77.12 with SMTP id e12mr7526733bkk.42.1292435274977; Wed, 15 Dec 2010 09:47:54 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id 25sm657808bkl.1.2010.12.15.09.47.53 (version=SSLv3 cipher=RC4-MD5); Wed, 15 Dec 2010 09:47:54 -0800 (PST) Message-ID: <4D08FF55.1040802@gmail.com> Date: Wed, 15 Dec 2010 19:48:05 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF Discussion , httpbis Group Subject: The new version of draft-yevstifeyev-http-headers-not-recognized (Last Call) Content-Type: multipart/alternative; boundary="------------050007030609000703040300" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 17:46:13 -0000 This is a multi-part message in MIME format. --------------050007030609000703040300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, I have recently made the new version of draft-yevstifeyev-http-headers-not-recognized including many comments during the first 2 days of Last Call. You can find it here: https://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/ Any comments and suggestions are still welcome. All the best, Mykyta Yevstifeyev --------------050007030609000703040300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello all,

I have recently made the new version of draft-yevstifeyev-http-headers-not-recognized
including many comments during the first 2 days of Last Call. You can find it here:

https://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/

Any comments and suggestions are still welcome.

All the best,
Mykyta Yevstifeyev
 --------------050007030609000703040300-- From ajs@shinkuro.com Wed Dec 15 09:51:34 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD8A3A7070 for ; Wed, 15 Dec 2010 09:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRWaaLrZYlLT for ; Wed, 15 Dec 2010 09:51:33 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 73AEB3A706D for ; Wed, 15 Dec 2010 09:51:33 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F04601ECB41D; Wed, 15 Dec 2010 17:53:14 +0000 (UTC) Date: Wed, 15 Dec 2010 12:53:13 -0500 From: Andrew Sullivan To: Marshall Eubanks Subject: Re: Wikipedia Message-ID: <20101215175312.GI87411@shinkuro.com> References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net> <208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv> <183DE488-730D-46F0-AFC6-92710EEC7AF1@americafree.tv> <4D08EBB5.5050105@tana.it> <20101215163706.GE87411@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 17:51:34 -0000 On Wed, Dec 15, 2010 at 12:39:35PM -0500, Marshall Eubanks wrote: > > On Wed, Dec 15, 2010 at 05:24:21PM +0100, Alessandro Vesely wrote: > >> On 15/Dec/10 03:02, Marshall Eubanks wrote: > By some magic of cut and paste this was assigned to me, but it was apparently written > by Alessandro Vesely . My apologies. That seems to be due to careless trimming on my part. It's nice to be useful as an example, though: if we didn't have a stable archive, then it would be hard to see what happened. As it is, it's fairly easy to see what I did. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dhc2@dcrocker.net Wed Dec 15 10:05:20 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A284828C107 for ; Wed, 15 Dec 2010 10:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXIa1Ic-ohax for ; Wed, 15 Dec 2010 10:05:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id B184428C0F2 for ; Wed, 15 Dec 2010 10:05:19 -0800 (PST) Received: from [192.168.1.15] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBFI6vtY005537 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 15 Dec 2010 10:07:03 -0800 Message-ID: <4D0903BE.2060801@dcrocker.net> Date: Wed, 15 Dec 2010 10:06:54 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Wikipedia References: <20101215170401.268C96BE5A5@mercury.lcs.mit.edu> <20101215170827.GG87411@shinkuro.com> <4D08F9BD.4010700@att.com> In-Reply-To: <4D08F9BD.4010700@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 15 Dec 2010 10:07:03 -0800 (PST) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 18:05:20 -0000 On 12/15/2010 9:24 AM, Tony Hansen wrote: > This indicates to me that the one of the checks the RFC Editor and possibly > idnits should do is whether or not such citations have a "date accessed" notation. As already noted, there are two different semantics possible here: 1. Latest version of ... 2. The version as of... We need to permit both forms, since each is appropriate for some uses. That said, there should be clarify about /when/ each is appropriate and which they are not. d/ ps. The thread has also had different comments about whether this is something to be resolved by the IESG or by the RFC Editor. pps. The actual documentation about citation rules (References) is a bit fuzzy, actually, but at most the IESG can make rules for the IETF stream. I would hope that basic rules are set by the RFC Editor, for all streams, with relatively surgical modifications and enhancements made by particular streams. While it might seem reasonable to have "specification" refinement rules belong to the IESG, note that there are plenty of specs not on standards track and not coming from the IETF stream. As an exercise to conduct for this issue, should "downref" constraints pertain only to standards track or should it apply to all RFCs? If the latter, what does it mean to have a downref for a document that is not on standards track? -- Dave Crocker Brandenburg InternetWorking bbiw.net From lauri.vosandi@gmail.com Mon Dec 13 15:46:45 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D033A6E13 for ; Mon, 13 Dec 2010 15:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxQRg3OPm-cV for ; Mon, 13 Dec 2010 15:46:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 0C1FE3A6DFA for ; Mon, 13 Dec 2010 15:46:43 -0800 (PST) Received: by iyi42 with SMTP id 42so20788iyi.31 for ; Mon, 13 Dec 2010 15:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=n1uhTUqm7UIIM3ZBRAg/ZkGN1+FLcOrREHY8Q5BFiv8=; b=eyqGZDyDt8SofTQo1c/kNM2UraM0TQfvpFVd800eu5zb+vc4sI5IQ5adJDNVptX0gy lNUrUxoENd2IcYrXDJwrDg1vXfZOSN2/BxHKmjEz+hdyKWBMtAXyiNdqVMOWiJHJLtNO vpB4NOLZUv0i6PpdRlQ8ZzJRKGv6MCcwBQvoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=qY5SllQspWxOrPu+xDU4fcQGa3W4r9rqRpo31P8hNJUcrGTLkPMC5VGrvWo7ABDHJx s18ZrF64gqYh3plPLj6KFYeUdB7+jRVWy7VWoUPw7bCZorsjx3Z759Rvb+WnrKfHaoae Rw4tR/qJNxlJtjhR7Ksu8TUtK+fxEls4SAA+c= MIME-Version: 1.0 Received: by 10.231.37.197 with SMTP id y5mr2481876ibd.180.1292284101975; Mon, 13 Dec 2010 15:48:21 -0800 (PST) Received: by 10.231.39.131 with HTTP; Mon, 13 Dec 2010 15:48:21 -0800 (PST) Date: Tue, 14 Dec 2010 01:48:21 +0200 Message-ID: Subject: Secure Shell UNIX domain socket redirection to Proposed Standard From: lauri To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 15 Dec 2010 10:12:49 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 23:48:05 -0000 Good evening, on GNU/Linux boxes there are many services which use UNIX domain sockets for inter-process communication. Most of them also support TCP sockets, but that needs additional code for authentication. There used to be streamlocal patch which implemented UNIX domain socket redirection for OpenSSH but now it seems to be dead: http://www.25thandclement.com/~william/projects/streamlocal.html Generally I think it would be good idea to have UNIX domain socket redirection in Secure Shell standard because the difference between TCP/IP redirection code and the one used for UNIX domain sockets is minor. The feature would benefit many LTSP deployments and other installations aswell. Blogpost related to the lack of UNIX domain socket redirection in Secure Shell standard can be found here: http://v6sa.wordpress.com/2010/12/01/gnulinux-based-terminal-servers-with-s= martcard-support/ --=20 Lauri V=F5sandi tel: +372 53329412 e-mail: lauri.vosandi@gmail.com company: Povi Software O=DC (http://www.povi.ee) blog: http://v6sa.wordpress.com/ From elwynd@dial.pipex.com Wed Dec 15 10:17:33 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D043A6FBF; Wed, 15 Dec 2010 10:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.276 X-Spam-Level: X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53x0UQDGlaDv; Wed, 15 Dec 2010 10:17:32 -0800 (PST) Received: from auth.a.painless.aaisp.net.uk (a.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by core3.amsl.com (Postfix) with ESMTP id 3A1F63A6F9B; Wed, 15 Dec 2010 10:17:32 -0800 (PST) Received: from 250.254.187.81.in-addr.arpa ([81.187.254.250]) by a.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PSvwT-0006w8-5F; Wed, 15 Dec 2010 18:19:09 +0000 Subject: Re: Gen-art LC review of draft-cheshire-dnsext-nbp-09.txt From: Elwyn Davies To: Stuart Cheshire In-Reply-To: References: <1290525315.4284.7622.camel@mightyatom.folly.org.uk> Content-Type: text/plain Date: Wed, 15 Dec 2010 18:19:53 +0000 Message-Id: <1292437193.17554.2809.camel@mightyatom.folly.org.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: General Area Reviwing Team , draft-cheshire-dnsext-nbp.all@tools.ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 18:17:33 -0000 On Tue, 2010-12-14 at 18:19 -0800, Stuart Cheshire wrote: > On 23 Nov 2010, at 7:15 AM, Elwyn Davies wrote: > > > Summary: > > This document has at least one open issue that I believe needs > > fixing, either by altering the scope of the applicability of the > > solution or fixing the requirements. The requirements envisage a > > protocol that could be used in an enterprise environment but it > > does not address issues of visibility and accessibility. > > The document describes AppleTalk NBP, and what would be required in > an IP-based equivalent. It does not claim to document all possible > requirements of all possible service discovery protocols. The second sentence is certainly true. My comments do not seek ocean boiling. OTOH the document seeks to be not just an equivalent for Appletalk NBP but a specifically zero-configuration related service discovery protocol running over IP and explicitly targeting enterprise as well as (generally simpler) domestic type environments. Not being an enterprise network manager these days, I don't know what their hot buttons are in respect of service visibility but I do know that controlling visibility may be a factor. > > > This issue is clearly related to the security requirements that > > have been discussed elsewhere but differs from the authentication > > and general authorization aspects that have been the focus there. > > I believe that there needs to be discussion of how the service > > discovery can be controlled so that individual users/machines are > > only informed of services that they might be allowed to use. > > The document describes AppleTalk NBP, and what would be required in > an IP-based equivalent. AppleTalk NBP would find you (for example) > all file servers on the network, not all file servers for which you > know the password. We do not believe it is feasible in general to tie > service discovery to access control. Nor is it useful: Discovering > there's a printer for which you do know the password allows you to > ask someone for the password. Discovering only resources to which you > already have access (and therefore probably already know about) is > significantly less useful. A paranoid (but literate) network manager will ask 'useful to whom'? Being able to determine all the resources available on the network with limited authorisation may not be seen as the most desirable situation. But I leave it to those with more current experience in this area to determine whether this is a genuine hole in the requirements. Regards, Elwyn > > > Nits: > > [refreshingly free of nits!] > > The only comment might be that a pointer to some publically > > available definition or discussion of the existing Appletalk NBP > > miight be helpful if such a thing exists. > > There is not, which is why I wrote this document. > > > Also idnits suggests that RFC 2462 should be replaced by RFC4862 > > which obsoleted it. > > Fixed. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org > From bernard_aboba@hotmail.com Wed Dec 15 10:53:12 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281BF3A6FB7; Wed, 15 Dec 2010 10:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGQHuLSOrbHr; Wed, 15 Dec 2010 10:53:11 -0800 (PST) Received: from blu0-omc1-s32.blu0.hotmail.com (blu0-omc1-s32.blu0.hotmail.com [65.55.116.43]) by core3.amsl.com (Postfix) with ESMTP id D99403A6EB8; Wed, 15 Dec 2010 10:53:10 -0800 (PST) Received: from BLU152-DS12 ([65.55.116.8]) by blu0-omc1-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Dec 2010 10:54:53 -0800 X-Originating-IP: [76.108.72.166] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: , References: <02a301cb8c14$a8feda60$fafc8f20$@com> In-Reply-To: <02a301cb8c14$a8feda60$fafc8f20$@com> Subject: Operations Directorate Review of draft-ietf-mpls-ip-options Date: Wed, 15 Dec 2010 13:57:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuMFKhywl2SvAUHSRalHNE1pTZy+gQdPwFA Content-Language: en-us X-OriginalArrivalTime: 15 Dec 2010 18:54:53.0194 (UTC) FILETIME=[8EE3D6A0:01CB9C89] Cc: tscholl@nlayer.net, jmullool@cisco.com, wjaeger@att.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 18:53:12 -0000 I reviewed the document draft-ietf-mpls-ip-options in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Proposed Standard This document specifies how Label Edge Routers (LER) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. This document is motivated by the need to mitigate the existing risks of IP options-based security attacks against MPLS infrastructure. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. Is the document readable? Yes. Does it contain nits? No: idnits 2.12.05 tmp/draft-ietf-mpls-ip-options-05.txt: -- The document date (May 2011) is 151 days in the future. Is this intentional? Summary: 0 errors (**), 0 warnings (==), 1 comment (--). Is the document class appropriate? Yes. Is the problem well stated? Yes. Is the problem really a problem? Yes. Does the document consider existing solutions? Yes. The document brings together existing practices into a single recommendation. Does the solution break existing technology? No. Does the solution preclude future activity? No. Is the solution sufficiently configurable? Yes. In a number of instances, the document recommends default policies, but allows other policies to be configured if necessary. Can performance be measured? How? Performance will be enhanced by avoiding potential DOS attacks described in Section 5.1 and 5.2. This can be measured via conventional metrics for packet forwarding and label switching. Does the solution scale well? Yes. Improving security and DOS attack avoidance enhances scaling. Is Security Management discussed? Yes. This document is focused on avoiding security threats to MPLS infrastructure. ------------------------------------------------ -----Original Message----- From: Tina Tsou [mailto:tena@huawei.com] Sent: Wednesday, November 24, 2010 3:18 PM To: Bernard_Aboba@hotmail.com Cc: 'Ronald Bonica'; 'Romascanu, Dan (Dan)' Subject: Request for Operations Directorate Review of draft-ietf-mpls-ip-options-05 by 2010-11-30 Hello, As a member of the Operations Directorate you are being asked to review the following draft which is in IETF last call for it's operational impact. IETF Last Call: The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ip-options/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ip-options/ Please provide comments and review to the Ops-dir mailing list (ops-dir@ietf.org) before 2010-11-30, and include the authors of the draft as well. A Check-list of possible questions/topics to address in an OPS-DIR review may be found in Appendix A of RFC 5706. Only include the questions that apply to your review. The status of Operations Directorate Review could be found http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates or http://merlot.tools.ietf.org/tools/art/opsdir/index.cgi/t=4904/welcome You could update the wiki page when you finish the review. Thank you, Tina http://tinatsou.weebly.com From bernard_aboba@hotmail.com Wed Dec 15 12:10:34 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A663A7061 for ; Wed, 15 Dec 2010 12:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxahD74TJVdI for ; Wed, 15 Dec 2010 12:10:32 -0800 (PST) Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by core3.amsl.com (Postfix) with ESMTP id 0ABCF3A6FB5 for ; Wed, 15 Dec 2010 12:10:31 -0800 (PST) Received: from BLU152-DS13 ([65.55.116.74]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Dec 2010 12:12:14 -0800 X-Originating-IP: [76.108.72.166] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Subject: Review of draft-zorn-radius-keywrap Date: Wed, 15 Dec 2010 15:14:57 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01CB9C6A.D61CF700" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acubr4otqoaots9gRG6vqicDzBLOnAA5SXyA Content-Language: en-us X-OriginalArrivalTime: 15 Dec 2010 20:12:14.0778 (UTC) FILETIME=[5D7D59A0:01CB9C94] Cc: "'Romascanu, Dan \(Dan\)'" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 20:10:34 -0000 ------=_NextPart_000_00B3_01CB9C6A.D61CF700 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit There are two major issues remaining in this document. One issue is that in a number of places, the document appears to contradict IETF standards track documents. Examples: Section 3.1 If the client requires the use of the Keying-Material Attribute for keying material delivery and it is not present in the Access- Accept or Access-Challenge message, the client MAY ignore the message in question and end the user session. [BA] Presumbly the MAY is included here for security reasons, such as preventing the client from accepting a downlevel key from a server from which it has previously received keying material described in this document, thus preventing spoofing in the event that the RADIUS shared secret (or MD5) is compromised. However, in such a situation the key material itself would be compromised, so that some sort of warning should probably be raised. My recommendation is that this be rewritten to state the considerations underlying the MAY, as well as recommended behavior in line with RFC 2865 Section 5.26, which states: Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. RFC 2865 is written this way to prevent the creation of proprietary RADIUS implementations that require the presence of vendor-specific information. Section 3.3 Any packet that contains an instance of the Message- Authentication-Code Attribute SHOULD NOT contain an instance of the Message-Authenticator Attribute [RFC3579]. [BA] Since the Message-Authenticator Attribute is mandated by RFC 3579, this represents a contradiction. My recommendation would be to remove this sentence, and require that the key used in computing the Message-Authentication-Code be cryptographically independent of the RADIUS shared secret. That way both attributes can be included without damage. Section 5 It is RECOMMENDED in this memo that two new keys, a key encrypting key and a message authentication key, be shared by the RADIUS client and server. If implemented, these two keys MUST be different from each other and SHOULD NOT be based on a password. These two keys SHOULD be cryptographically independent of the RADIUS shared secret used in calculating the Response Authenticator [RFC2865], Request Authenticator [RFC2866] [RFC5176] and Message-Authenticator Attribute [RFC3579]; otherwise if the shared secret is broken, all is lost. [BA] I believe that cryptgraphic independence of the RADIUS shared secret needs to be a MUST, since the goal of this document is to provide security even in a situation where the RADIUS shared secret could be compromised. Another issue is that there are a number of fields for which "the content of this field is outside the scope of this document." The document needs to provide enough information on these fields to enable interoperability. Currently it is not clear if this is the case. Fields which are not adequately explained include the following: Section 3.1 Keying-Material KEK ID The KEK ID field is 16 octets in length and contains an identifier for the KEK. The KEK ID MUST refer to an encryption key of a type and length appropriate for use with the algorithm specified by the Enc Type field (see above). This key is used to protect the contents of the Data field (below). Further specification of the content of this field is outside the scope of this document. KM ID The KM ID field is 16 octets in length and contains an identifier for the contents of the Data field. The KM ID MAY be used by communicating parties to identify the material being transmitted. The combination of App ID and KM ID MUST uniquely identify the keying material between the parties utilizing it. The KM ID is assumed to be known to the parties that derived the keying material. If the KM ID is not used it is set to 0. Further specification of the content of this field is outside the scope of this document. Section 3.3 Message-Authentication-Code MAC Key ID The MAC Key ID field is 16 octets in length and contains an identifier for the key. The MAC Key ID MUST refer to a key of a type and length appropriate for use with the algorithm specified by the MAC Type field (see above). Further specification of the content of this field is outside the scope of this document. ------=_NextPart_000_00B3_01CB9C6A.D61CF700 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

There are = two major issues remaining in this document.

One issue is that in = a number of places, the document appears to
contradict IETF = standards track documents.

Examples:

Section = 3.1

      If the client requires the use = of the Keying-Material Attribute
      for = keying material delivery and it is not present in the = Access-
      Accept or Access-Challenge = message, the client MAY ignore the
      = message in question and end the user session.

[BA] Presumbly the = MAY is included here for security reasons, such as preventing
the = client from accepting a downlevel key from a server from which it = has
previously received keying material described in this document, = thus preventing
spoofing in the event that the RADIUS shared secret = (or MD5) is compromised.
However, in such a situation the key = material itself would be compromised,
so that some sort of warning = should probably be raised.

My recommendation is that this be = rewritten to state the considerations
underlying the MAY, as well as = recommended behavior in line with RFC 2865
Section 5.26, which = states:

      Clients which do not = receive desired vendor-specific = information
      SHOULD make an attempt to = operate without it, although they may = do
      so (and report they are doing so) = in a degraded mode.

RFC 2865 is written this way to prevent the = creation of proprietary RADIUS
implementations that require the = presence of vendor-specific information.

Section = 3.3

      Any packet that contains an = instance of the Message-
      = Authentication-Code Attribute SHOULD NOT contain an instance = of
      the Message-Authenticator Attribute = [RFC3579].

[BA] Since the Message-Authenticator Attribute is = mandated by RFC 3579,
this represents a contradiction.  My = recommendation would be to remove
this sentence, and require that the = key used in computing the
Message-Authentication-Code be = cryptographically independent of the
RADIUS shared secret.  That = way both attributes can be included without
damage.

Section = 5

   It is RECOMMENDED in this memo that two new keys, = a key encrypting
   key and a message authentication key, = be shared by the RADIUS client
   and server.  If = implemented, these two keys MUST be different from
   each = other and SHOULD NOT be based on a password.  These two = keys
   SHOULD be cryptographically independent of the = RADIUS shared secret
   used in calculating the Response = Authenticator [RFC2865], Request
   Authenticator [RFC2866] = [RFC5176] and Message-Authenticator Attribute
   [RFC3579]; = otherwise if the shared secret is broken, all is lost.

[BA] I = believe that cryptgraphic independence of the RADIUS shared = secret
needs to be a MUST, since the goal of this document is to = provide security
even in a situation where the RADIUS shared secret = could be compromised.

Another issue is that there are a number = of fields for which "the content
of this field is outside the = scope of this document." The document
needs to provide enough = information on these fields to enable
interoperability.  = Currently it is not clear if this is the case.

Fields which are = not adequately explained include the following:

Section 3.1 = Keying-Material

      KEK = ID

         The KEK ID = field is 16 octets in length and contains = an
         identifier for = the KEK.  The KEK ID MUST refer to an = encryption
         key of a = type and length appropriate for use with the = algorithm
         specified = by the Enc Type field (see above).  This key is = used
         to protect the = contents of the Data field (below).  = Further
         = specification of the content of this field is outside the = scope
         of this = document.

      KM = ID

         The KM ID = field is 16 octets in length and contains = an
         identifier for = the contents of the Data field.  The KM ID = MAY
         be used by = communicating parties to identify the material = being
         = transmitted.  The combination of App ID and KM ID MUST = uniquely
         identify = the keying material between the parties utilizing = it.
         The KM ID is = assumed to be known to the parties that = derived
         the keying = material.  If the KM ID is not used it is set to = 0.
         Further = specification of the content of this field is = outside
         the scope of = this document.

Section 3.3  = Message-Authentication-Code

      MAC = Key ID

         The MAC = Key ID field is 16 octets in length and contains = an
         identifier for = the key.  The MAC Key ID MUST refer to a key = of
         a type and length = appropriate for use with the = algorithm
         specified = by the MAC Type field (see above).  = Further
         = specification of the content of this field is outside the = scope
         of this = document.

------=_NextPart_000_00B3_01CB9C6A.D61CF700-- From dworley@avaya.com Wed Dec 15 12:13:45 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E97928C0E7 for ; Wed, 15 Dec 2010 12:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or42K4T6ICzE for ; Wed, 15 Dec 2010 12:13:44 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 852D828C0D6 for ; Wed, 15 Dec 2010 12:13:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAqxCE3GmAcF/2dsb2JhbACYb4tBc6pUApkxhUoEhGSJR4JY X-IronPort-AV: E=Sophos;i="4.59,350,1288584000"; d="scan'208";a="255160370" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Dec 2010 15:15:07 -0500 X-IronPort-AV: E=Sophos;i="4.59,350,1288584000"; d="scan'208";a="556201491" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Dec 2010 15:15:07 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 15 Dec 2010 15:15:06 -0500 From: "Worley, Dale R (Dale)" To: lauri , "ietf@ietf.org" Date: Wed, 15 Dec 2010 15:14:02 -0500 Subject: RE: Secure Shell UNIX domain socket redirection to Proposed Standard Thread-Topic: Secure Shell UNIX domain socket redirection to Proposed Standard Thread-Index: Acucg/jGT/UIrM98TwisO7XpI487YAAEKSLT Message-ID: References: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 20:13:45 -0000 ________________________________________ From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of lauri [lau= ri.vosandi@gmail.com] Generally I think it would be good idea to have UNIX domain socket redirection in Secure Shell standard because the difference between TCP/IP redirection code and the one used for UNIX domain sockets is minor. The feature would benefit many LTSP deployments and other installations aswell. _______________________________________________ Identifying a problem that would be nice to have solved is easy. Who will = do the work? Who will write the Internet Draft describing the protocol cha= nges? Dale From lauri.vosandi@gmail.com Wed Dec 15 12:28:58 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164E73A7073 for ; Wed, 15 Dec 2010 12:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOK+27xTPZ49 for ; Wed, 15 Dec 2010 12:28:56 -0800 (PST) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by core3.amsl.com (Postfix) with ESMTP id 62F3628C102 for ; Wed, 15 Dec 2010 12:28:56 -0800 (PST) Received: by iwn39 with SMTP id 39so2595729iwn.27 for ; Wed, 15 Dec 2010 12:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GYKJNAgqaaOb2LCrCb574q0CFYvJVOv5TCanaiWtT9U=; b=SYFawiQpqnS7XlkSMiEkkbeFbUu+9Z1sDr/HQreB8U9Wo4JECn8Lu0SdsNGt9Nafnb 7nL6Ij3fESdkuoWwVfkC6F+uPqAD2KjusDwHz/0IU9DIgxYVO6DdisZZ1n5Mommz6vYd Nf1SVVmgc9gMil+sHd3v99PbPrSx4BN9RSer8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mu5Yj2CP7WcFFCwFK+0rjKri7ql9RsgZ42siIc1rSIsUtDACTrg08gyTLvwaIFGTlr Fn6PHSR3wncQv5w/Eej+ouu5/g/Ufx0eZh9+32qaX0JIYqeFrMrEpDtr1JRUa6MMUkl/ uOxvZtgSbdjw+vUTESpULP8f1zx8cTBhkZhDs= MIME-Version: 1.0 Received: by 10.231.36.205 with SMTP id u13mr5270531ibd.155.1292445039325; Wed, 15 Dec 2010 12:30:39 -0800 (PST) Received: by 10.231.39.131 with HTTP; Wed, 15 Dec 2010 12:30:39 -0800 (PST) In-Reply-To: References: Date: Wed, 15 Dec 2010 22:30:39 +0200 Message-ID: Subject: Re: Secure Shell UNIX domain socket redirection to Proposed Standard From: lauri To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 20:28:58 -0000 Hello, sorry for double-posting, I thought the first one was filtered by mailing list program. > Identifying a problem that would be nice to have solved is easy. =A0Who w= ill do the work? =A0Who will write the Internet Draft describing the protoc= ol changes? Currently I am not sure where to start but if there are some others interested and willing to help I can do my best :) --=20 Lauri V=F5sandi tel: +372 53329412 e-mail: lauri.vosandi@gmail.com company: Povi Software O=DC (http://www.povi.ee) blog: http://v6sa.wordpress.com/ From fluffy@cisco.com Wed Dec 15 23:14:32 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD0C3A6FE4; Wed, 15 Dec 2010 23:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmMAnvrSIa7y; Wed, 15 Dec 2010 23:14:30 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0DC0F3A6FE3; Wed, 15 Dec 2010 23:14:30 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH9LCU2rR7Hu/2dsb2JhbACkNXOlNJtXgwWCRQSEZIYXgxY X-IronPort-AV: E=Sophos;i="4.59,354,1288569600"; d="scan'208";a="233536542" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 16 Dec 2010 07:16:13 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oBG7GCuX011351; Thu, 16 Dec 2010 07:16:12 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Review of draft-saintandre-tls-server-id-check-12 Date: Thu, 16 Dec 2010 00:17:16 -0700 Message-Id: <58FE898B-BD2A-4C6E-B769-256008D8A58B@cisco.com> To: IESG IESG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 07:14:32 -0000 So let me start with I think there is great information in here and I = think it should be published as a standards track RFC however I do think = there are some issues with the relation with this draft and the = realities of what would help improve security in deployment of SIP, = HTTP, IMAP, XMPP etc.=20 There are many places where this draft makes choices to improve the = security from many current practices. At face value this seems like a = good thing but it's not always. The thing reducing the overall security = available to users of TLS is not if certs use CN-ID or DNS-ID, it is = that it's such a PITA to deploy a TLS server that people choose to not = use TLS at all. Everywhere there is a trade off between making things = marginally more secure, or making things cheaper and easer to deploy, I = think we need to seriously consider the cheaper and easier approach. = Yes, some things are just broken even if they are easy and obviously we = can't do those. Let me give an example of this. I looked at the cert for = the domains for the authors of this draft. www.cisco.com has 3 DNS names = even though as fas as I can tell one of these are for something that = would typically be used in a ftp URI and the other HTTP URI. This is = because it makes it easier and cheaper for them to use TLS yet seems to = go against the recommendation of this "BCP". Then I went over the = www.paypal.com domain which uses, gasp, a CN-ID. Do we really believe = that paypal is seriously compromising their security by using a CN = instead of URI-ID? If so, how? I'm pretty sure the paypal guys know how = to run a secure web server. With the exception of Microsoft small = business server certificates (which are outrageously expensive by the = way) it pretty hard to get SRV name certs. In making these = recommendations, did the TLS WG consider the relative prices of various = types of certificates? Lets say I had a certificate for the domain = example.org because I was using it for email and it has a CN because I = got it years ago. Now lets say I am going to go deploy a SIP service on = example.org. My position is that best way to encourage the use of = security on the internet is to just reuse the certificate I have. It = cheap, it's easy, it secure enough even if it does make you feel a bit = dirty. I think Jeff disagrees with me, we argued for years about this = topic and my understanding is his position is that it would be better to = say that all new deployments MUST not use a CN name because it's less = secure. Give the prevalence of CN on the internet today, I think it is = fine to tell people how DNS-ID is better but I don't think it's OK to = tell them they should not use CN-ID and I definitely don't think it is = OK to tell implementors they don't need to implement CN-ID.=20 I encouraged Chris to write this draft long ago and what we had = discussed at the time was forming a RFC with one or more boiler plate = pieces of text that could be used in creation of the name matching = section of new protocols that got developed. I was thinking of something = similar to the way we use rfc 5226 for writing IANA consideration = section. Instead we have a document that is creating a very complex = situations about whats normative. This draft is a BCP level, and it says = you have to do everything in PKIX and PKIX takes precedence. That is = basically elevating PKIX to a BCP without appropriate process review. = Next this draft contradicts the procedures in existing protocols and = says that it does not apply to the existing protocols but that it would = take precedence over any future updates of existing protocols that use = TLS within the scope specified here. I do not believe you have the = consensus of the people woking on SIP that the next time some = specification is marked as an UPDATE to 3261, that implementations need = to implement the procedures in this draft. Furthermore, I think that = would be counter productive. I think you should make it clear this = guidelines for designers of new protocol and people updating existing = protocol and that these protocols could make their own choices but would = want to take into account the information in this draft. When I read the = sentence,=20 "However, the best current practices described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so." I think that is exactly the right solution to the problem. However, that = not a BCP, thats a standards track spec. Furthermore, I think this draft = is going to have all the normal bugs etc of any other spec that defines = algorithms and such it should proceed through the standards track = process. If this draft is going to go as a BCP, that text contradicts = what a BCP is and needs to come out and the rest of the draft be = adjusted appropriately. My preference would be that this draft be = standards track. Its writing exactly the same sort of normative = algorithm text that we put in all kinds of other thing like SIP, HTTP, = and even TLS. They are all standards track. This should be the same.=20 Most RFCs today that use TLS have a page plus or minus that tells an = implementer what they need to know about matching names in certs. This = draft move that to 30 to 50 pages depending on how you count. Most = implementers are just going to ignore this thus worsening the security = situation. Think about why is the part implementers need to read 10x = longer than existing deceptions - this just seems wrong. Now it's easy = to blow off this type concern and say get over it, it's the same number = of lines of code they need to write. But the problem is when an = implementors goes to start doing this and encounters something that is = 50 pages long, they instantly decide this is a big task and down it goes = on the priority list of actually happening. The other problem is that = even thous it is long, it is still very confusing on how to do things = (such at URI). I'll provide more detailed examples of this later in this = email. If the document was restructured to have all the normative text = in one short simple description and the rest moved to an appendix, it = would be much easier to get people to take this seriously and easier to = review that it was correct.=20 My final big issue is the use of normative language. Lets say there are = two procedures A and B and we 100% consensus that B is better than A but = we still have to support A for existing deployment reasons. To describe = this, the text this draft would use is is MUST do A and SHOULD NOT do B. = Now reading 2119 it is pretty clear that SHOULD NOT means you don't = implement it unless there are real good reasons to implement it. So on = the things were we agree A is preferred to B but you need both for = backwards compatibility, this draft needs to say MUST implement A and = MUST implement B but deployments are encouraged to use B as we are = trying to move away from A. I think the whole document needs a careful = read checking for this issue. You can insert the usual rant here about = why SHOULD is a awful word in specs 90% of the time it used because = implementer thinks it means "ignore rest of sentence". For example, = section 5.4 discusses they this spec continues to mandate protocols MUST = support CN yet this draft continually use "SHOULD NOT" when what it = really means is MUST implement. This is going to confuse implementors of = IETF specification and be ignored by operators. Given the goals of this = spec it would be much better if it was clearly defining what IETF = required implementers of protocols to do instead of confusing that with = how we wish security was deployed.=20 =20 On to the nits. Take an applications like a web server. Is the preferred thing in a cert = a DNS-ID or a URI-ID. My reading of the 3.3 is that URI-ID is preferred = over DNS-ID yet the examples don't match that. I think point 3 in = section 3.1 tries to explain this away but I don't understand that - = clearly web browsers use a URI.=20 The rules in section 3.1 don't make sense for a CA. How will the CA know = if the cert I want is going to be used for a protocol that uses SRV? In section 3.2, in the imap example, you are saying that if I configure = my imap server to mail.example.com and it presents a certificate with a = DNS-ID of example.com that this is OK. That does not sound OK to me but = I don't know how IMAP works. In the SIP example, the cert should have a = SRV and DNS name too. As well as a CN if you actually want it to work in = the real world.=20 In section 4.2.1 you have a long discussion on how the information used = must come from a way that can't be tampered with over the internet. I = generally agree with this but would like to point out that protocols = like LOST (see section 18 of rfc5222) specially do the opposite of this = and actually match the cert agains the output of NAPTR process not the = input to the NAPTR process. The example just seem plain wrong in some cases. Take for example = section 4.2.2 where the SIP example has only a URI reference identifiers = and no DNS yet the section right before this has said the list MUST = include a DNS-ID. This text has been through how many reviews and Last = Calls? The problem here is that this draft is too long to review for = stuff like this. Even after the IESG is done reviewing it, statistics = suggest it will still be littered with bugs like this and implementors = will use the examples to guide them. If someone implements what is in = the example, it will break in lots of sip deployments.=20 There is a whole algorithm about matching various ID types, but the note = about you ignore CN if you have other things is off in "Security = Warning" very much out of any flow of the algorithm description then = pointed out again in some other section. It's not wrong, but it's a bit = weird from an implementer point of view.=20 Many applications do need to deal with IP matching as well as domain = names. The way this text is written here makes it harder to figure out = how and where to mix that in. I'd rather see it just dealt with than = instead of making it out of scope. Obviously it's not common on internet = but it is common on private networks and walled gardens where many of = the protocols were are talking about are deployed. Many of the "internet = of things" people I work with have no intention of using DNS at all. I = scoffed at multiple large service providers 10 years ago when they said = they were not using DNS with SIP but many still use IPs. This sounds = less insane when you consider the major OS don't ship with an = asynchronous DNS library.=20 I'm baffled on why checking the service name in a SRV record is a SHOULD = not a MUST. Could you add text explain why and when one would not check = it. If you were in a really good mood you could do that for all the = SHOULDs. Actually, when I read section 4.5 carefully, I think it = literally says that when using a URI, checking the domain name is a = SHOULD not a MUST. Surely check the domain name matches is not a SHOULD = level sort of thing.=20 Section 5.4. I have no idea why it matters that some major OS does not = support SNI. Even if that OS did support SNI, many many applications = running on that OS and the others would not support SNI. It seems like = it is the applications acting as TLS servers and clients that are the = important thing, not the OS.=20 How you process URI-ID needs work. I could not figure out how to = implement given the text in the draft as is. Even ignoring the special = tar pit the SIP guys dug for themselves with tel URL processing, just = the normal sip, sips issues seems unclear.=20 This seems like a long list of complaints delivered fairly late but, = once again, I really do like much of the information in here and think = it should be published as PS - it just would be significantly improved = with a bit of a re-factored and clean up. If this had been run through = the TLS working group, I would have caught all of this in the WG LC. = This is a draft that, as a BCP, profoundly effects many of the = protocols I work on including SIP but as far as I can tell has not done = much to gather the consensus of the people working on protocol that this = draft changes - I don't recall hearing about it until after it went to = the IESG so I'm pretty un apologetic about providing these comments = during IETF LC.=20 In summary, I like the information in this but I think it still has many = small things that need fixing and needs to be changed to get crisp about = what implementors need to do and drop the confusing stuff about how we = wish operators and CA might use certificates. I also feel strongly that = the right way to look at this draft is, as that draft says "practices described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so" and that for that reason it has to be standards track not BCP. If it was = not being written and pushed by two IESG members, I don't think we would = even be discussing if it should be a BCP.=20 From pekkas@netcore.fi Thu Dec 16 01:00:54 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F66C3A70AE for ; Thu, 16 Dec 2010 01:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSGP8YnwPh0K for ; Thu, 16 Dec 2010 01:00:49 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id B02F73A70A5 for ; Thu, 16 Dec 2010 01:00:48 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id oBG92LmM004908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Dec 2010 11:02:21 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id oBG92KIV004905; Thu, 16 Dec 2010 11:02:20 +0200 Date: Thu, 16 Dec 2010 11:02:20 +0200 (EET) From: Pekka Savola To: Stuart Cheshire Subject: Re: Last Call: (DNS-Based Service Discovery) to Proposed Standard In-Reply-To: Message-ID: References: <20101026145701.22996.35291.idtracker@localhost> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.96.4 at otso.netcore.fi X-Virus-Status: Clean Cc: draft-cheshire-dnsext-dns-sd@tools.ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 09:00:54 -0000 On Tue, 14 Dec 2010, Stuart Cheshire wrote: > On 17 Nov 2010, at 11:32 PM, Pekka Savola wrote: > The entire document is talking about how an app developer should use it. "It" > in this context is the domain name system. DNS-SD is not a protocol in > itself. It's a usage convention for DNS records. The entire document is > telling server developers what DNS records we recommend they use to describe > their service, and telling client developers what DNS records we recommend > they query for to discover those advertised services. It describes what app > developers should pick for Instance names and Service names. It describes > what data app developers should put into TXT records. If we took out all the > text directed at app developers there would be virtually nothing left. They > are the audience for this document. In a way, I understand that it could be argued that this is just a "naming convention" (also see the security considerations below). Practically, however, it could be said to describe at least the solution framework. In practise, it describes the functionality that should be implemented in a DNS-SD software library the apps can link to, or even some kind of separate sofware package. While implementing everything described here would also be doable in each application (no doubt some will do so), that would be waste. The point is underlined in e.g. how DNS-updates or related DNSSEC keying material would be configured, i.e. everything where there's more to it than just a naming convention. >> 17. Security Considerations >> >> DNSSEC [RFC 2535] should be used where the authenticity of >> information is important. Since DNS-SD is just a naming and usage >> convention for records in the existing DNS system, it has no specific >> additional security requirements over and above those that already >> apply to DNS queries and DNS updates. >> >> .. this is a bit weak. There's more stuff to put in DNS updates. See the >> referred sec-dir review from two years ago. The text is unchanged. > > The sec-dir review said "I find this inadequate" and "this document seems to > need more work". Can you suggest some specific text? DNS-SD is a convention > for how to name and use DNS records. Every security consideration that > applies to a client using DNS queries and updates would apply to a client > following the conventions in this document. >From my POV, the most important thing I'd like to see in Security Considerations section is description of that app developer will be able do the DNS updates, hopefully in a secure fashion. Some examples of what I wonder: - Is the expectation that you configure the DNS server so that certain IP's have complete access to do updates? - What does that imply? Is it possible to limit the update capability to some subtree? What kind of configuration would it need if it should be application-specific? (I.e., if one application gets out of hand, can it mess up all other apps or even the whole DNS domain?) - Or do you expect deployment of DNS security (e.g. TSIG, SIG0)? If so, how do you configure these in the app and the server within the constraints of zero-conf goals? Do the same DNS subtree limitations and caveats apply? To sum it up, I suspect the zeroconf nature of the goals of this work is likely to prevent the use of TSIG/SIG(0) in DNS-updates, or at least it requires major manual operations and/or it effectively authorizes one application to update every other application's data as well. But in some contexts it could be possible to implement it in a different way. >> Editorial: >> ---------- >> >> - IANA considerations does not explicitly mention 'DNS-SD profile' >> referred to in S 6 (though you can work out what you mean). > > Can you suggest some specific text? The minimal fix would be to change: This document specifies the following IANA allocation policy for unique application protocol names: to: This document specifies the following IANA allocation policy for unique application protocol names (DNS-SD profiles): ... but it would still leave IANA considerations a big ambiguous. It would be much better if the required checklist on what to report and how IANA should record it in its registry was in a tabular format. While it's not in tabular format, the bullet list at http://www.dns-sd.org/ServiceTypes.html describes this rather well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From evnikita2@gmail.com Thu Dec 16 01:19:59 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549213A70B7 for ; Thu, 16 Dec 2010 01:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qpXpjPJznNG for ; Thu, 16 Dec 2010 01:19:58 -0800 (PST) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id 153943A70AA for ; Thu, 16 Dec 2010 01:19:57 -0800 (PST) Received: by gxk8 with SMTP id 8so1678173gxk.27 for ; Thu, 16 Dec 2010 01:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=el+/P2SPu/Ia/pvmeXtjCII1lH6Qy7xslKXwUZ83z/0=; b=Dr1d+6Nx4Z6MyRxkKlm1bN7RxGaejhBIgQTPUb4nGf82So0Zp7Smyk0srrJSnqUw/i xGsfut+8DTD2OZ8kQz/WLN8uecyHeQd6oT5DAZVZ1DAQi6LUe7yPaxfPtoaJwklFttlJ q7c0ehnUvTTG20YLEcv2Zc1pIpUWK5moSoRlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SWh3p3Hzv6STmdUFQZkqO82N3aMbInnyqTLuxL0CH045RntmjI9VUWHiZVZu2leGfS 7F2x8n67Ti3LtuScO6nwjtKN+fQVm1Ex+XIq+Cuq60MujBK1iPhUxpRd2FvLGeu4U06C 5FiMdjfRJ3zQVRelD0O93DzMHcLd99SShXpDU= MIME-Version: 1.0 Received: by 10.150.57.4 with SMTP id f4mr563457yba.285.1292491297621; Thu, 16 Dec 2010 01:21:37 -0800 (PST) Received: by 10.150.52.19 with HTTP; Thu, 16 Dec 2010 01:21:37 -0800 (PST) In-Reply-To: References: <4D08FF55.1040802@gmail.com> Date: Thu, 16 Dec 2010 11:21:37 +0200 Message-ID: Subject: Re: The new version of draft-yevstifeyev-http-headers-not-recognized (Last Call) From: Mykyta Yevstifeyev To: Daniel Stenberg Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Discussion , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 09:19:59 -0000 Daniel, This topic has been discused before LC on httpbis mailing list and we reached a conclusion that discussed proposal can be used while debugging hosts and only ocassionaly - widespread. I think that is the answer to your question. Waiting for other suggestions for improvement. All the best, Mykyta Yevstigeyev 2010/12/15, Daniel Stenberg : > On Wed, 15 Dec 2010, Mykyta Yevstifeyev wrote: > >> https://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/ >> >> Any comments and suggestions are still welcome. > > I lack the (discussion around a) use case for this. Who would use this and > why? > > -- > > / daniel.haxx.se > From daedulus@btconnect.com Thu Dec 16 02:33:40 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4725D3A70C3 for ; Thu, 16 Dec 2010 02:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gihNT8yiwLYe for ; Thu, 16 Dec 2010 02:33:38 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 8191D3A70BA for ; Thu, 16 Dec 2010 02:33:35 -0800 (PST) Received: from host81-156-71-67.range81-156.btcentralplus.com (HELO pc6) ([81.156.71.67]) by c2beaomr10.btconnect.com with SMTP id BAO08116; Thu, 16 Dec 2010 10:34:04 +0000 (GMT) Message-ID: <00d601cb9d04$033499c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: References: <20101214132434.665a7a7059d7ee80bb4d670165c8327d.de7f0a456f.wbe@email03.secureserver.net><208308FF-BE04-4F8E-9A85-37DBB4A91FCF@americafree.tv><183DE488-730D-46F0-AFC6-92710EEC7AF1@americafree.tv><4D08EBB5.5050105@tana.it> <20101215163706.GE87411@shinkuro.com> Subject: Re: Wikipedia Date: Thu, 16 Dec 2010 10:31:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4D09EB1B.0188, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4D09EB67.02EA,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 10:33:40 -0000 I notice that the RFC Editor has a Citations Committee; should they be responding to this issue? Tom Petch ----- Original Message ----- From: "Andrew Sullivan" To: Sent: Wednesday, December 15, 2010 5:37 PM Subject: Re: Wikipedia > On Wed, Dec 15, 2010 at 05:24:21PM +0100, Alessandro Vesely wrote: > > On 15/Dec/10 03:02, Marshall Eubanks wrote: > > > IMHO, whether to use temporal coordinates (where available) should be > > left to authors' judgment. Some authors diligently monitor the > > relevant Wikipedia pages. > > It makes no difference whether authors monitor the relevant Wikipedia > pages, because you can't update the references section of the RFC once > it's published. > > I find it slightly astonishing that the RFC Editor's instuctions on > URLs don't require a visited-on parameter. Just about every academic > style guide requires such a note for the obvious reason that the > target of a URL can change. The whole reason we have the citation > traditions we do is so that someone can follow the reference later and > look up the material in question. This is an important feature of any > reference, because without it the citation is all but worthless: it > does nobody any good if you include a citation and then nobody can > check whether you understood (or even quoted) the material correctly. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From evnikita2@gmail.com Thu Dec 16 06:55:42 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54BE33A6808 for ; Thu, 16 Dec 2010 06:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyXjVAEFwEX3 for ; Thu, 16 Dec 2010 06:55:41 -0800 (PST) Received: from mail-ew0-f53.google.com (mail-ew0-f53.google.com [209.85.215.53]) by core3.amsl.com (Postfix) with ESMTP id 5F9313A6809 for ; Thu, 16 Dec 2010 06:55:41 -0800 (PST) Received: by ewy6 with SMTP id 6so1966304ewy.40 for ; Thu, 16 Dec 2010 06:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=scWT31qEc35B9jsGbksha5rQuiPIB6jU1P7kJEuAASc=; b=HZ5rD50vtbodZ792ULuKpqc3IS6HY5uJzsCV392U0LJgByqLGO2zxDqYB/lUUHqdig 8NRSUYq8wXCAL//oiL/4eVUnbMU5uiGcJCVGLk+FYTKQTPYCUoJwR8K7mmCg7eshjNse lBbe4LhCd78uoMAiu7g2l9HGG18K8vitLjgyg= 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; b=xNygl0BKEJWMiWXY/sBlRSOo8VOMhKN1s60SOaO0X2C45gh/SKVDR/0GgaZItChppD QNpVDcFnGou+myhk0Mq01QV6m5044bkn825w+vVHRXs4gxowldOPF7RzzJurM2+IXoxO McBnSsI0S971CLIppSyxi9I8ff+UPQ177L6y0= Received: by 10.204.33.74 with SMTP id g10mr3442000bkd.131.1292511444899; Thu, 16 Dec 2010 06:57:24 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id 25sm1325227bkl.13.2010.12.16.06.57.22 (version=SSLv3 cipher=RC4-MD5); Thu, 16 Dec 2010 06:57:23 -0800 (PST) Message-ID: <4D0A28DE.40105@gmail.com> Date: Thu, 16 Dec 2010 16:57:34 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daniel Stenberg Subject: Re: The new version of draft-yevstifeyev-http-headers-not-recognized (Last Call) References: <4D08FF55.1040802@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080806030207040501040108" Cc: IETF Discussion , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 14:55:42 -0000 This is a multi-part message in MIME format. --------------080806030207040501040108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Daniel, You may find some related discussions on http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/ dated from Monday, 22 November 2010 and Tuesday, 23 November 2010 All the best, Mykyta Yevstifeyev 16.12.2010 12:28, Daniel Stenberg wrote: > On Thu, 16 Dec 2010, Mykyta Yevstifeyev wrote: > >> This topic has been discused before LC on httpbis mailing list and we >> reached a conclusion that discussed proposal can be used while >> debugging hosts and only ocassionaly - widespread. I think that is >> the answer to your question. > > I'm sorry, can you please link me to those discussions? I've been a > subscriber to the httpbis mailing list for a long time and I must've > missed the mails you refer to. > > Perhaps I'm not alone. > --------------080806030207040501040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Daniel,

You may find some related discussions on

http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/

dated from Monday, 22 November 2010 and Tuesday, 23 November 2010

All the best,
Mykyta Yevstifeyev

16.12.2010 12:28, Daniel Stenberg wrote:
On Thu, 16 Dec 2010, Mykyta Yevstifeyev wrote:

This topic has been discused before LC on httpbis mailing list and we reached a conclusion that discussed proposal can be used while debugging hosts and only ocassionaly - widespread. I think that is the answer to your question.

I'm sorry, can you please link me to those discussions? I've been a subscriber to the httpbis mailing list for a long time and I must've missed the mails you refer to.

Perhaps I'm not alone.


--------------080806030207040501040108-- From stpeter@stpeter.im Thu Dec 16 07:20:37 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42F43A6887; Thu, 16 Dec 2010 07:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utvSYNI-a3XE; Thu, 16 Dec 2010 07:20:34 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AF6003A6863; Thu, 16 Dec 2010 07:20:34 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 73B104009B; Thu, 16 Dec 2010 08:34:52 -0700 (MST) Message-ID: <4D0A2EA8.6080709@stpeter.im> Date: Thu, 16 Dec 2010 08:22:16 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Review of draft-saintandre-tls-server-id-check-12 References: <58FE898B-BD2A-4C6E-B769-256008D8A58B@cisco.com> In-Reply-To: <58FE898B-BD2A-4C6E-B769-256008D8A58B@cisco.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020200010102060400040507" Cc: IETF cert-based identity , IESG IESG , The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 15:20:37 -0000 This is a cryptographically signed message in MIME format. --------------ms020200010102060400040507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your comments. My co-author and I will need to confer before replying, and that might take a few days given the length of your review.= Peter On 12/16/10 12:17 AM, Cullen Jennings wrote: >=20 > So let me start with I think there is great information in here and I > think it should be published as a standards track RFC however I do > think there are some issues with the relation with this draft and the > realities of what would help improve security in deployment of SIP, > HTTP, IMAP, XMPP etc. >=20 > There are many places where this draft makes choices to improve the > security from many current practices. At face value this seems like a > good thing but it's not always. The thing reducing the overall > security available to users of TLS is not if certs use CN-ID or > DNS-ID, it is that it's such a PITA to deploy a TLS server that > people choose to not use TLS at all. Everywhere there is a trade off > between making things marginally more secure, or making things > cheaper and easer to deploy, I think we need to seriously consider > the cheaper and easier approach. Yes, some things are just broken > even if they are easy and obviously we can't do those. Let me give an > example of this. I looked at the cert for the domains for the authors > of this draft. www.cisco.com has 3 DNS names even though as fas as I > can tell one of these are for something that would typically be used > in a ftp URI and the other HTTP URI. This is because it makes it > easier and cheaper for them to use TLS yet seems to go against the > recommendation of this "BCP". Then I went over the www.paypal.com > domain which uses, gasp, a CN-ID. Do we really believe that paypal is > seriously compromising their security by using a CN instead of > URI-ID? If so, how? I'm pretty sure the paypal guys know how to run a > secure web server. With the exception of Microsoft small business > server certificates (which are outrageously expensive by the way) it > pretty hard to get SRV name certs. In making these recommendations, > did the TLS WG consider the relative prices of various types of > certificates? Lets say I had a certificate for the domain example.org > because I was using it for email and it has a CN because I got it > years ago. Now lets say I am going to go deploy a SIP service on > example.org. My position is that best way to encourage the use of > security on the internet is to just reuse the certificate I have. It > cheap, it's easy, it secure enough even if it does make you feel a > bit dirty. I think Jeff disagrees w ith me, we argued for years about > this topic and my understanding is his position is that it would be > better to say that all new deployments MUST not use a CN name because > it's less secure. Give the prevalence of CN on the internet today, I > think it is fine to tell people how DNS-ID is better but I don't > think it's OK to tell them they should not use CN-ID and I definitely > don't think it is OK to tell implementors they don't need to > implement CN-ID. >=20 > I encouraged Chris to write this draft long ago and what we had > discussed at the time was forming a RFC with one or more boiler plate > pieces of text that could be used in creation of the name matching > section of new protocols that got developed. I was thinking of > something similar to the way we use rfc 5226 for writing IANA > consideration section. Instead we have a document that is creating a > very complex situations about whats normative. This draft is a BCP > level, and it says you have to do everything in PKIX and PKIX takes > precedence. That is basically elevating PKIX to a BCP without > appropriate process review. Next this draft contradicts the > procedures in existing protocols and says that it does not apply to > the existing protocols but that it would take precedence over any > future updates of existing protocols that use TLS within the scope > specified here. I do not believe you have the consensus of the people > woking on SIP that the next time some specification is marked as an=20 > UPDATE to 3261, that implementations need to implement the procedures > in this draft. Furthermore, I think that would be counter productive. > I think you should make it clear this guidelines for designers of new > protocol and people updating existing protocol and that these > protocols could make their own choices but would want to take into > account the information in this draft. When I read the sentence,=20 > "However, the best current practices described here can be referenced > by future specifications, including updates to specifications for > existing application protocols if the relevant technology communities > agree to do so." I think that is exactly the right solution to the > problem. However, that not a BCP, thats a standards track spec. > Furthermore, I think this draft is going to have all the normal bugs > etc of any other spec that defines algorithms and such it should > proceed through the standards track process. If this draft is going > to go as a BCP, that text contradicts what a BCP is and needs to come > out and the rest of the draft be adjusted appropriately. My > preference would be that this draft be standards track. Its writing > exactly the same sort of normative algorithm text that we put in all > kinds of other thing like SIP, HTTP, and even TLS. They are all > standards track. This should be the same. >=20 > Most RFCs today that use TLS have a page plus or minus that tells an > implementer what they need to know about matching names in certs. > This draft move that to 30 to 50 pages depending on how you count. > Most implementers are just going to ignore this thus worsening the > security situation. Think about why is the part implementers need to > read 10x longer than existing deceptions - this just seems wrong. Now > it's easy to blow off this type concern and say get over it, it's the > same number of lines of code they need to write. But the problem is > when an implementors goes to start doing this and encounters > something that is 50 pages long, they instantly decide this is a big > task and down it goes on the priority list of actually happening. The > other problem is that even thous it is long, it is still very > confusing on how to do things (such at URI). I'll provide more > detailed examples of this later in this email. If the document was > restructured to have all the normative text in one s hort simple > description and the rest moved to an appendix, it would be much > easier to get people to take this seriously and easier to review that > it was correct. >=20 > My final big issue is the use of normative language. Lets say there > are two procedures A and B and we 100% consensus that B is better > than A but we still have to support A for existing deployment > reasons. To describe this, the text this draft would use is is MUST > do A and SHOULD NOT do B. Now reading 2119 it is pretty clear that > SHOULD NOT means you don't implement it unless there are real good > reasons to implement it. So on the things were we agree A is > preferred to B but you need both for backwards compatibility, this > draft needs to say MUST implement A and MUST implement B but > deployments are encouraged to use B as we are trying to move away > from A. I think the whole document needs a careful read checking for > this issue. You can insert the usual rant here about why SHOULD is a > awful word in specs 90% of the time it used because implementer > thinks it means "ignore rest of sentence". For example, section 5.4 > discusses they this spec continues to mandate protocols MUST suppo rt > CN yet this draft continually use "SHOULD NOT" when what it really > means is MUST implement. This is going to confuse implementors of > IETF specification and be ignored by operators. Given the goals of > this spec it would be much better if it was clearly defining what > IETF required implementers of protocols to do instead of confusing > that with how we wish security was deployed. >=20 >=20 > On to the nits. >=20 > Take an applications like a web server. Is the preferred thing in a > cert a DNS-ID or a URI-ID. My reading of the 3.3 is that URI-ID is > preferred over DNS-ID yet the examples don't match that. I think > point 3 in section 3.1 tries to explain this away but I don't > understand that - clearly web browsers use a URI. >=20 > The rules in section 3.1 don't make sense for a CA. How will the CA > know if the cert I want is going to be used for a protocol that uses > SRV? >=20 > In section 3.2, in the imap example, you are saying that if I > configure my imap server to mail.example.com and it presents a > certificate with a DNS-ID of example.com that this is OK. That does > not sound OK to me but I don't know how IMAP works. In the SIP > example, the cert should have a SRV and DNS name too. As well as a CN > if you actually want it to work in the real world. >=20 > In section 4.2.1 you have a long discussion on how the information > used must come from a way that can't be tampered with over the > internet. I generally agree with this but would like to point out > that protocols like LOST (see section 18 of rfc5222) specially do the > opposite of this and actually match the cert agains the output of > NAPTR process not the input to the NAPTR process. >=20 > The example just seem plain wrong in some cases. Take for example > section 4.2.2 where the SIP example has only a URI reference > identifiers and no DNS yet the section right before this has said the > list MUST include a DNS-ID. This text has been through how many > reviews and Last Calls? The problem here is that this draft is too > long to review for stuff like this. Even after the IESG is done > reviewing it, statistics suggest it will still be littered with bugs > like this and implementors will use the examples to guide them. If > someone implements what is in the example, it will break in lots of > sip deployments. >=20 > There is a whole algorithm about matching various ID types, but the > note about you ignore CN if you have other things is off in "Security > Warning" very much out of any flow of the algorithm description then > pointed out again in some other section. It's not wrong, but it's a > bit weird from an implementer point of view. >=20 > Many applications do need to deal with IP matching as well as domain > names. The way this text is written here makes it harder to figure > out how and where to mix that in. I'd rather see it just dealt with > than instead of making it out of scope. Obviously it's not common on > internet but it is common on private networks and walled gardens > where many of the protocols were are talking about are deployed. Many > of the "internet of things" people I work with have no intention of > using DNS at all. I scoffed at multiple large service providers 10 > years ago when they said they were not using DNS with SIP but many > still use IPs. This sounds less insane when you consider the major OS > don't ship with an asynchronous DNS library. >=20 > I'm baffled on why checking the service name in a SRV record is a > SHOULD not a MUST. Could you add text explain why and when one would > not check it. If you were in a really good mood you could do that for > all the SHOULDs. Actually, when I read section 4.5 carefully, I think > it literally says that when using a URI, checking the domain name is > a SHOULD not a MUST. Surely check the domain name matches is not a > SHOULD level sort of thing. >=20 > Section 5.4. I have no idea why it matters that some major OS does > not support SNI. Even if that OS did support SNI, many many > applications running on that OS and the others would not support SNI. > It seems like it is the applications acting as TLS servers and > clients that are the important thing, not the OS. >=20 > How you process URI-ID needs work. I could not figure out how to > implement given the text in the draft as is. Even ignoring the > special tar pit the SIP guys dug for themselves with tel URL > processing, just the normal sip, sips issues seems unclear. >=20 > This seems like a long list of complaints delivered fairly late but, > once again, I really do like much of the information in here and > think it should be published as PS - it just would be significantly > improved with a bit of a re-factored and clean up. If this had been > run through the TLS working group, I would have caught all of this in > the WG LC. This is a draft that, as a BCP, profoundly effects many > of the protocols I work on including SIP but as far as I can tell has > not done much to gather the consensus of the people working on > protocol that this draft changes - I don't recall hearing about it > until after it went to the IESG so I'm pretty un apologetic about > providing these comments during IETF LC. >=20 > In summary, I like the information in this but I think it still has > many small things that need fixing and needs to be changed to get > crisp about what implementors need to do and drop the confusing stuff > about how we wish operators and CA might use certificates. I also > feel strongly that the right way to look at this draft is, as that > draft says "practices described here can be referenced by future > specifications, including updates to specifications for existing > application protocols if the relevant technology communities agree to > do so" and that for that reason it has to be standards track not BCP. > If it was not being written and pushed by two IESG members, I don't > think we would even be discussing if it should be a BCP. >=20 --------------ms020200010102060400040507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIx NjE1MjIxNlowIwYJKoZIhvcNAQkEMRYEFOkr6cBnNBjHqbadgmyXB2jaIJ76MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAqM2IG07Oi9nPkw1vdvUnt4EGtxGXuhNxa7XLI41rraC8MoV4MFRYTmjxZ cQf6nRq6xzrKtiXsfXpJbGQ5xfeYG0UVQ9Jf+BuPTsoX/d5sXbDR+R7oxYuEF6AqhVcd5qBw YErWpB+bIfTuL7CLMzUJXK4/Nt2edWxLdRApZ9pf6lUxfjihq6t2e9RhYoQaJ2dumQdq63ej 9E3L2DDF9rh4/1K9bNMMfmY7smvIiI5Jmsjn+S3ZfZNLep+h2SAcG6dNDIweCeoHeRBvxl8/ Y2ftLqNvYwbt8IDUKASYn5zhN9/tugzJFnEGV5IKMNoCsTGSe4DG0qUw5YdSPP0Am+tpAAAA AAAA --------------ms020200010102060400040507-- From evnikita2@gmail.com Thu Dec 16 07:58:17 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA1A3A6902 for ; Thu, 16 Dec 2010 07:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEWNZGKhAX-r for ; Thu, 16 Dec 2010 07:58:17 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 4455A3A68DC for ; Thu, 16 Dec 2010 07:58:10 -0800 (PST) Received: by bwz8 with SMTP id 8so3890360bwz.38 for ; Thu, 16 Dec 2010 07:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=KBNWOY+Z7x/q5QrfQdgHYB2IsorOgTqumox/TzssJWo=; b=vdQOmEkxgVONEf3RtXjXMKE02i1iTq4RwT9Vi07kxSj1bANExsKB103f2MpjFym6/C HvxSuSOni3IOPdtkc62a3iUoThJ+W0K4FblM92ae+rTlWwgMQMtGrlo27ew7OwBvXaUA s26nPJOHw+ql45YgeEm4e9LdS1BLRHH/pSW0c= 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=axIIoA+SFZ0tx9U6uSz0rNVHuxWapNZS9vZbKzSXJhXvxpxbNEZvR8o5b4ojDK6N/E j1c7h+V8SKx3oYDKS1WPQzWZGx5N/cTCQp5q8kq+zEMK11leDGG8zsEGQCaIw3E6kaFk k3umVa5yx1es+ASrdsQ5zcuHhGGsPtI0EAah8= Received: by 10.204.118.7 with SMTP id t7mr8661517bkq.87.1292515194489; Thu, 16 Dec 2010 07:59:54 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id j11sm1362240bka.12.2010.12.16.07.59.51 (version=SSLv3 cipher=RC4-MD5); Thu, 16 Dec 2010 07:59:53 -0800 (PST) Message-ID: <4D0A3783.1050801@gmail.com> Date: Thu, 16 Dec 2010 18:00:03 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daniel Stenberg Subject: Re: The new version of draft-yevstifeyev-http-headers-not-recognized (Last Call) References: <4D08FF55.1040802@gmail.com> <4D0A28DE.40105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Discussion , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 15:58:17 -0000 Daniel, I'll now explain that. Let A is the host-under-debugging (HUD). There is another host, B, which is debugger. Let there is some new HTTP server software on A. B's sending requests with different methods, headers and entity to test A for appropriate processing of headers. Let B is sending the request with header X-Foo, which is to be used or already used widely among the Internet. But A does not recognize it. But it is not easy for developers to get known this. If discussed header is used, B testers can simply analyze A's answer (as it is to be done at all) to find out the problem and fix it. That is debugging purpose, IMO. Hope I explained everything clearly. Any suggestions are welcome. All the best, Mykyta Yevstifeyev 16.12.2010 17:46, Daniel Stenberg wrote: > On Thu, 16 Dec 2010, Mykyta Yevstifeyev wrote: > >> Daniel, >> >> You may find some related discussions on >> >> http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/ >> >> dated from Monday, 22 November 2010 and Tuesday, 23 November 2010 > > Thanks. > > The only tiny piece of explanation I can find there is > http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0493.html > where you say "But aren't debugging purposes a weighty argument?". > > Does this mean that debugging HTTP clients(?) and servers(?) is your > primary purpose for this feature? In what way does this help you debug? > > I've been developing (and debugging) HTTP clients for over a decade > and I've not missed this header. I'm genuinely trying to understand > the use case and what benefit this header is to bring for that > purpose, so that I can read the draft with that in mind. > > So please, even if this is repeating something you've expressed > before, can you enlighten us (again) exactly in what ways you intend > to use this header/feature? > > (If someone else have any good suggestions, that'll do fine as well!) > From djsmith@cisco.com Wed Dec 15 12:21:41 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5133A705A; Wed, 15 Dec 2010 12:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8dAqcDGz4Uh; Wed, 15 Dec 2010 12:21:39 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E1C053A6FBF; Wed, 15 Dec 2010 12:21:38 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK+yCE2tJXHB/2dsb2JhbACkMHOoKJtRhUoEhGSJMw X-IronPort-AV: E=Sophos;i="4.59,350,1288569600"; d="scan'208";a="193307850" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-1.cisco.com with ESMTP; 15 Dec 2010 20:23:21 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id oBFKNLO6008573; Wed, 15 Dec 2010 20:23:21 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Dec 2010 14:23:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TSVDIR Review for draft-ietf-mpls-ip-options-05 Date: Wed, 15 Dec 2010 14:23:19 -0600 Message-ID: In-Reply-To: <201012100015.oBA0F47M011963@sj-core-1.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSVDIR Review for draft-ietf-mpls-ip-options-05 Thread-Index: AcuX/04EWdVH/YIUSqWxlVW19TxSPwEjYcNA References: <201012100015.oBA0F47M011963@sj-core-1.cisco.com> From: "David Smith (djsmith)" To: "James Polk (jmpolk)" , , "John Mullooly (jmullool)" , , X-OriginalArrivalTime: 15 Dec 2010 20:23:20.0984 (UTC) FILETIME=[EA945180:01CB9C95] X-Mailman-Approved-At: Thu, 16 Dec 2010 12:21:12 -0800 Cc: ietf@ietf.org, tsv-dir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 20:21:41 -0000 Hi James, Many thanks for the review & comments. We will incorporate them into -06 which we'll post soon. See our feedback inline below as well [djsmith].=20 Regards,=20 /dave -----Original Message----- From: James Polk (jmpolk)=20 Sent: Thursday, December 09, 2010 7:15 PM To: wjaeger@att.com; John Mullooly (jmullool); tscholl@nlayer.net; David Smith (djsmith); mpls@ietf.org Cc: tsv-dir@ietf.org; ietf@ietf.org Subject: TSVDIR Review for draft-ietf-mpls-ip-options-05 I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive.=20 Please always CC tsv-dir@ietf.org if you reply to or forward this review. Summary: This is a well written, concise and needed modification to MPLS. That said, I don't understand why the 1st minor issue below is present. Recommend (fairly strongly) adding the "Document Updates: RFC 3031, RFC 3032" as mentioned below on this first page of this RFC to be. [djsmith] ack, changed to ID updates RFC 3031 (but not RFC 3032). Changed ID header and Motivation text per below. Transport Issues: There are no issues minor issues: - S2 "Motivation", last sentence is "We believe that this document adds details that have not been fully addressed in [RFC3031] and [RFC3032] as well as complements [RFC3270], [RFC3443] and [RFC4950]. " I find it surprising that this document does not formally update 3031 and 3032, given that it is mandatory to implement, optional to invoke. ISTM, as an outsider to MPLS, this would in fact be the case given the impact of/to IP stacks not adhering to this proposed standard. [djsmith] ack, changed to ID updates RFC 3031 (but not RFC 3032). Changed ID header and Motivation text "We believe that this document adds details that have not been fully addressed in [RFC3031] and [RFC3032], and that the methods presented in this document update [RFC3031] as well as complement [RFC3270], [RFC3443] and [RFC4950]." - Section 5.2 is about Router Alert Options, and states "At the time of this writing ...". I wonder if this subsection is valid, or needs another review against this IntArea ID http://tools.ietf.org/html/draft-ietf-intarea-router-alert-consideration s-02 to still be valid in a month or two once the IntArea ID (currently in WGLC) is processed by the IESG and RFC-Editor? IMO - these two docs are progressing near enough to each other to each consider what the other says - with or without a normative or informative reference in either or both docs to the other. [djsmith] Note, the text relating to "at the time of this writing" is referring to the (MPLS) Router Alert Label not the (IP) Router Alert Option. Hence, this section remains valid given no existing standard for Router Alert Label imposition. This ID specifies that a IP RAO cannot influence imposition of a RAL (Router Alert Label). So we've kept this section as is.=20 nits: - I'm surprised to see the Abstract on page 2. I thought we collectively fixed the case in which the Abstract can be on any page other than page 1. [djsmith] ack, changed. I think you meant Abstract _cannot_ be on any page other than page 1. - at the page Footer, in the middle of the line, there isn't a "short document name" - which has been there on all previous well formed IDs and RFCs that I have seen (which of course is not all of them). It is recommended the authors pick a short form name for the subject of this doc for this location, such as LER Header Option Behaviors [djsmith] ack, changed.=20 - S3, 4th para, second to last sentence is: "First a downstream LSR may have not have sufficient IP routing information to forward the packet resulting in packet loss. " recommend removing the first instance of "have". The sentence reads better without it. [djsmith] ack, changed.=20 - S3, 4th para, last two sentences list a "First" and a "Second" reason correctly, but are missing required commas after each word (i.e., "First, ...", and "Second, ..." ) [djsmith] ack, changed.=20 - S3, 5th para, 1st sentence is lacking commas here: "...FEC, yet are forwarded into an IP/MPLS network without being MPLS-encapsulated, present..." [djsmith] ack, changed.=20 - S5.1, last bullet has this: "...MPLS encapsulation at a ingress LER ..." ^^^^^ s/a/an [djsmith] ack, changed.=20 James =20 From daniel@haxx.se Wed Dec 15 13:04:52 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179C028C0DC for ; Wed, 15 Dec 2010 13:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDKWZ+sjF1GA for ; Wed, 15 Dec 2010 13:04:51 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 9110A3A6FB7 for ; Wed, 15 Dec 2010 13:04:50 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id oBFL6YXn025180; Wed, 15 Dec 2010 22:06:34 +0100 Date: Wed, 15 Dec 2010 22:06:34 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mykyta Yevstifeyev Subject: Re: The new version of draft-yevstifeyev-http-headers-not-recognized (Last Call) In-Reply-To: <4D08FF55.1040802@gmail.com> Message-ID: References: <4D08FF55.1040802@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Wed, 15 Dec 2010 22:06:34 +0100 (CET) X-Mailman-Approved-At: Thu, 16 Dec 2010 12:21:12 -0800 Cc: IETF Discussion , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 21:04:52 -0000 On Wed, 15 Dec 2010, Mykyta Yevstifeyev wrote: > https://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/ > > Any comments and suggestions are still welcome. I lack the (discussion around a) use case for this. Who would use this and why? -- / daniel.haxx.se From daniel@haxx.se Thu Dec 16 02:26:39 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5853A70C2 for ; Thu, 16 Dec 2010 02:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.737 X-Spam-Level: X-Spam-Status: No, score=-2.737 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4JK7+A1BtWO for ; Thu, 16 Dec 2010 02:26:38 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 2E6753A70C0 for ; Thu, 16 Dec 2010 02:26:37 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id oBGASLPY007936; Thu, 16 Dec 2010 11:28:21 +0100 Date: Thu, 16 Dec 2010 11:28:21 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mykyta Yevstifeyev Subject: Re: The new version of draft-yevstifeyev-http-headers-not-recognized (Last Call) In-Reply-To: Message-ID: References: <4D08FF55.1040802@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Thu, 16 Dec 2010 11:28:21 +0100 (CET) X-Mailman-Approved-At: Thu, 16 Dec 2010 12:21:12 -0800 Cc: IETF Discussion , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 10:26:39 -0000 On Thu, 16 Dec 2010, Mykyta Yevstifeyev wrote: > This topic has been discused before LC on httpbis mailing list and we > reached a conclusion that discussed proposal can be used while debugging > hosts and only ocassionaly - widespread. I think that is the answer to your > question. I'm sorry, can you please link me to those discussions? I've been a subscriber to the httpbis mailing list for a long time and I must've missed the mails you refer to. Perhaps I'm not alone. -- / daniel.haxx.se From daniel@haxx.se Thu Dec 16 07:45:13 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839A03A6902 for ; Thu, 16 Dec 2010 07:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.003 X-Spam-Level: X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0crv9+mxvGZ for ; Thu, 16 Dec 2010 07:45:12 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 6A0D43A6900 for ; Thu, 16 Dec 2010 07:45:10 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id oBGFkrOK007362; Thu, 16 Dec 2010 16:46:54 +0100 Date: Thu, 16 Dec 2010 16:46:53 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mykyta Yevstifeyev Subject: Re: The new version of draft-yevstifeyev-http-headers-not-recognized (Last Call) In-Reply-To: <4D0A28DE.40105@gmail.com> Message-ID: References: <4D08FF55.1040802@gmail.com> <4D0A28DE.40105@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Thu, 16 Dec 2010 16:46:54 +0100 (CET) X-Mailman-Approved-At: Thu, 16 Dec 2010 12:21:12 -0800 Cc: IETF Discussion , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 15:45:13 -0000 On Thu, 16 Dec 2010, Mykyta Yevstifeyev wrote: > Daniel, > > You may find some related discussions on > > http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/ > > dated from Monday, 22 November 2010 and Tuesday, 23 November 2010 Thanks. The only tiny piece of explanation I can find there is http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0493.html where you say "But aren't debugging purposes a weighty argument?". Does this mean that debugging HTTP clients(?) and servers(?) is your primary purpose for this feature? In what way does this help you debug? I've been developing (and debugging) HTTP clients for over a decade and I've not missed this header. I'm genuinely trying to understand the use case and what benefit this header is to bring for that purpose, so that I can read the draft with that in mind. So please, even if this is repeating something you've expressed before, can you enlighten us (again) exactly in what ways you intend to use this header/feature? (If someone else have any good suggestions, that'll do fine as well!) -- / daniel.haxx.se From narten@us.ibm.com Thu Dec 16 21:51:30 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0EA3A6A41 for ; Thu, 16 Dec 2010 21:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.036 X-Spam-Level: X-Spam-Status: No, score=-106.036 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRz-ZwPoRi7V for ; Thu, 16 Dec 2010 21:51:29 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 0C5913A69DB for ; Thu, 16 Dec 2010 21:51:28 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id oBH5lE8R016539 for ; Thu, 16 Dec 2010 22:47:14 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oBH5r3KI114600 for ; Thu, 16 Dec 2010 22:53:03 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oBH5r2lR010206 for ; Thu, 16 Dec 2010 22:53:02 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oBH5r2FE010176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Dec 2010 22:53:02 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id oBH5r2IN017591 for ; Fri, 17 Dec 2010 00:53:02 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.4/8.14.4/Submit) id oBH5r1iQ017551 for ietf@ietf.org; Fri, 17 Dec 2010 00:53:01 -0500 From: Thomas Narten Message-Id: <201012170553.oBH5r1iQ017551@rotala.raleigh.ibm.com> Date: Fri, 17 Dec 2010 00:53:01 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 05:51:30 -0000 Total of 72 messages in the last 7 days. script run at: Fri Dec 17 00:53:01 EST 2010 Messages | Bytes | Who --------+------+--------+----------+------------------------ 6.94% | 5 | 10.97% | 57372 | cheshire@apple.com 5.56% | 4 | 5.47% | 28603 | chris.dearlove@baesystems.com 5.56% | 4 | 4.02% | 21014 | tme@americafree.tv 5.56% | 4 | 3.80% | 19876 | ajs@shinkuro.com 2.78% | 2 | 5.31% | 27779 | bernard_aboba@hotmail.com 1.39% | 1 | 6.12% | 32029 | flefauch@cisco.com 4.17% | 3 | 3.30% | 17262 | mnot@mnot.net 4.17% | 3 | 3.07% | 16077 | lauri.vosandi@gmail.com 4.17% | 3 | 2.83% | 14816 | julian.reschke@gmx.de 4.17% | 3 | 2.60% | 13592 | daniel@haxx.se 4.17% | 3 | 2.58% | 13511 | doug@ewellic.org 2.78% | 2 | 3.66% | 19143 | turners@ieca.com 1.39% | 1 | 5.05% | 26394 | stpeter@stpeter.im 2.78% | 2 | 2.44% | 12752 | evnikita2@gmail.com 2.78% | 2 | 2.29% | 12001 | hartmans-ietf@mit.edu 2.78% | 2 | 2.12% | 11079 | tony@att.com 2.78% | 2 | 2.11% | 11018 | dworley@avaya.com 2.78% | 2 | 2.08% | 10905 | simon@josefsson.org 1.39% | 1 | 3.19% | 16706 | fluffy@cisco.com 2.78% | 2 | 1.69% | 8848 | jnc@mercury.lcs.mit.edu 1.39% | 1 | 2.13% | 11134 | allison.mankin@gmail.com 1.39% | 1 | 1.84% | 9636 | marsh@extendedsubset.com 1.39% | 1 | 1.75% | 9151 | djsmith@cisco.com 1.39% | 1 | 1.65% | 8636 | pekkas@netcore.fi 1.39% | 1 | 1.55% | 8093 | gwz@net-zen.net 1.39% | 1 | 1.29% | 6746 | elwynd@dial.pipex.com 1.39% | 1 | 1.20% | 6292 | narten@us.ibm.com 1.39% | 1 | 1.18% | 6172 | l.wood@surrey.ac.uk 1.39% | 1 | 1.17% | 6122 | sm@resistor.net 1.39% | 1 | 1.10% | 5746 | vesely@tana.it 1.39% | 1 | 1.07% | 5622 | daedulus@btconnect.com 1.39% | 1 | 1.07% | 5580 | eburger-l@standardstrack.com 1.39% | 1 | 1.05% | 5468 | robert@timetraveller.org 1.39% | 1 | 1.01% | 5278 | dhc2@dcrocker.net 1.39% | 1 | 0.98% | 5150 | d3e3e3@gmail.com 1.39% | 1 | 0.98% | 5133 | gtw@gtwassociates.com 1.39% | 1 | 0.94% | 4913 | bortzmeyer@nic.fr 1.39% | 1 | 0.94% | 4898 | jeff.hodges@kingsmountain.com 1.39% | 1 | 0.88% | 4593 | mrex@sap.com 1.39% | 1 | 0.80% | 4167 | fweimer@bfk.de 1.39% | 1 | 0.73% | 3837 | francis.dupont@fdupont.fr --------+------+--------+----------+------------------------ 100.00% | 72 |100.00% | 523144 | Total From sm@resistor.net Fri Dec 17 01:27:18 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4373B3A6A8D; Fri, 17 Dec 2010 01:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.475 X-Spam-Level: X-Spam-Status: No, score=-104.475 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIDSg73o6W+y; Fri, 17 Dec 2010 01:27:15 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id A22693A6926; Fri, 17 Dec 2010 01:27:15 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oBH9Sl4r013325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 01:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1292578139; x=1292664539; bh=rZAUV6sIh4fGnA+1RQEajgKT1OuqzAfAM9FXAci/9ao=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=xQsPbT5BssCEwFMYKU30Ujgh81OABfgXClMEPb5aBjXoP2PCz/86ue3us79goTiN+ PvfRYyhJ8vV+sn9X5KUnQ7Ae5P0fDOTSbZk29YfLvsIo8mCRnuBoryek7NKwvaN/Qv vkG9q7HEdN88FxHPvhPapehvXHb5T13eiInCvzAE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1292578139; x=1292664539; bh=rZAUV6sIh4fGnA+1RQEajgKT1OuqzAfAM9FXAci/9ao=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=dR27l4+ZbzpFPydpbCZICUWc5BFl7Bfot2nHL2v+dGonWFneNuqXnwfbagTmS9APR 0sfVTHF/wLqmHi8SAyS2Ale7J0AssAW0pZRoMfjxRVBqIRHnvp8NuCiVRSCzEoKp62 35ucaWpC6rN22WObEwPROsVt2ZLp6+JyTBrameNI= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=rgM2sMOQrELKGqSr66YWrB90PjrPyHlxFYs5YU3JqixyPhpnhdB33Yq1CXnQGqIlX vrHeZUq4qmOvu4HxKNuGFvAPiobFflpzCFfYknWAhc5qUfAkVdh9vnLwtu7a/hKzbQF DqzNaCK20Eimn72S7Rnnsk5TZEwG2pC2rVyqomg= Message-Id: <6.2.5.6.2.20101217000432.0bd6aea8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Dec 2010 01:28:28 -0800 To: JeffH From: SM Subject: Re: Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP In-Reply-To: <4CFFD91A.2060808@KingsMountain.com> References: <4CFFD91A.2060808@KingsMountain.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, IETF cert-based identity , IETF Discussion List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 09:27:18 -0000 Hi Jeff, At 11:14 08-12-10, =JeffH wrote: >[ adding certid@ list ] I suggest following up on the certid@ietf.org mailing list and dropping ietf@. >I looked into this in detail earlier this year -- it was discussed >on ietf@ (during the initial IETF LC for this spec), and this >particular issue resolution was summarized here (by John Klensin).. > > Re: Last Call: draft-saintandre-tls-server-id-check > http://www.ietf.org/mail-archive/web/ietf/current/msg62601.html > >In brief summary, RFCs {1034,1035,1123,2181} do not define >"letter-digit-hyphen" DNS name labels in a concisely referenceable >fashion, nor particularly clearly. I'll go with John Klensin's argument for simplicity. >The IDNA specs have done the wider DNS-community a service by doing >so, and at present the fashion in which "traditional domain name" is >defined and cited is the best we can do. Given that IDNs are a >deployed reality, every (new or updated) spec that discusses domain >names going forward is going to need to reference the IDNA specs in >some fashion, and probably should simply use the LDH-Label, A-Label, >and U-Label nomenclature. (IMV) Agreed (in this context). >while I agree with your subtle substitution of.. > > "fully-qualified DNS domain name portion" > >..with.. > > "domain name portion" > >..however, I disagree with your further simplification of that >paragraph because we feel we need to supply the more detailed context. I'll comment on this below. >No, that is not the intent. We've further refined that paragraph as >a result of a concurrent discussion with Ben Campbell (on certid@) >and have this present working text.. > > The client might need to extract the source domain and service type > from the input(s) it has received. The extracted data MUST include > only information that can be securely parsed out of the inputs (e.g., > extracting the fully-qualified DNS domain name from the "authority" > component of a URI or extracting the service type from the scheme of > a URI) or information for which the extraction is performed in a > manner that is not subject to subversion by network attackers (e.g., > pulling the data from a delegated domain that is explicitly > established via client or system configuration, resolving the data > via [DNSSEC], or obtaining the data from a third-party domain mapping > service in which a human user has explicitly placed trust and with > which the client communicates over a connection that provides both > mutual authentication and integrity checking). These considerations > apply only to extraction of the source domain from the inputs; > naturally, if the inputs themselves are invalid or corrupt (e.g., a > user has clicked a link provided by a malicious entity in a phishing > attack), then the client might end up communicating with an > unexpected application service. That sound good. >You mean removing the parenthetical "(following the definition of >"label" from [DNS])", yes? > >In reviewing RFC 1035 I see your concern, tho we'd like to reference >a description of "label". I note that RFC 1034 [S3.1] seems to >appropriately supply this, so I propose we keep the parenthetical >but alter it to be.. > > (following the description of labels and domain names in [DNS-CONCEPTS]) That's fine to me. >Yes, but that definition (and term) appears to be specific to >underlying DNS internals, not to (pseudo) domain names as wielded >(or "presented" (eg in certs)) in other protocols. This brings us to the question of the DNS specific usage of "domain names" and when the term is used in an application context. For example, is the left-most part in "foo*.example.com" ( draft-saintandre-tls-server-id-check-12, Section 5.2) acceptable as a label? I'll react to some comments from Cullen Jennings. At 23:17 15-12-10, Cullen Jennings wrote: >So let me start with I think there is great information in here and >I think it should be published as a standards track RFC however I do >think there are some issues with the relation with this draft and >the realities of what would help improve security in deployment of >SIP, HTTP, IMAP, XMPP etc. The information in draft-saintandre-tls-server-id-check is helpful. It's been a mouthful to comment on the draft as it requires the reading of several referenced documents first. This in itself gives us an idea of the breath this draft tries to cover. >process review. Next this draft contradicts the procedures in >existing protocols and says that it does not apply to the existing >protocols but that it would take precedence over any future updates >of existing protocols that use TLS within the scope specified here. I That begs the question about whether this draft should be a BCP. I would feel more comfortable if such a document is carefully reviewed by people from the different application groups it touches on as it attempts to shape the future. This is not to say that there hasn't been enough discussion about the draft or that it did not get adequate socialization. If the authors are of the opinion that there has been that breath of review, I am fine with that. >In section 3.2, in the imap example, you are saying that if I >configure my imap server to mail.example.com and it presents a >certificate with a DNS-ID of example.com that this is OK. That does >not sound OK to me but I don't know how IMAP works. In the SIP example, the Consider an email address of "user@example.com". The IMAP service is discovered by the MUA by doing a DNS SRV lookup on _imaps.example.com ( draft-daboo-srv-email ) and the target is mail.example.net, i.e that's where the IMAP server is running. The certificate provides a SRV-ID of "_imaps.example.com" and a DNS-ID of "example.com". BTW, the reference to draft-ietf-tls-rfc4366-bis could be normative for the reader to understand SNI and not rely on the workaround for multiple identifiers. Regards, -sm From sm@resistor.net Fri Dec 17 03:15:06 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006E03A6AE0 for ; Fri, 17 Dec 2010 03:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.52 X-Spam-Level: X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2T2-3+WE8KU for ; Fri, 17 Dec 2010 03:15:01 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 79DA63A69EC for ; Fri, 17 Dec 2010 03:15:01 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oBHBGXIM021760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 03:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1292584603; x=1292671003; bh=zRLIjHUe9ATWyub57L5VCTRdUrAiff9vEvLEZ+mGtWM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=YoZFrPNOiyY902so4XIHhqr7wxMdZ74cMaX2ZBR37UxZWSQPgYaUpRrqg7H3XGlF8 IxI8eDB5skzBtoCOoenefeRvygHznkSJKOZaLquyr/iEjgq4l7HE5z1ceyqRqWO+Bt k+k67x4sUB+3p5o4PPTbSuPqF8uihgrURLLTY8Yw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1292584603; x=1292671003; bh=zRLIjHUe9ATWyub57L5VCTRdUrAiff9vEvLEZ+mGtWM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=zUJHKz/TB1IlXH9t/cFAOsLAzvMKI01y8s0RpSr9pyeY+DTJ5T7gzGvXh+DeINldk gI+KHj3+6//q0CMAD0B3Xa/riY24GT+GexC95FtM05z10lp95X0xHAjbYZ/+Utx19L 74yHi9H5Xk45jLijHR3DKl4OtQmOviI9BhiP8tts= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=JjLSG/HUmX0VoKV8hfrpWgXmIaygiO+OADzawd3J3Emdram3q7W9kR/SjG4haaWxo yW0cCWpkxt8osem42dsu/DTBbc6zTcm4gWpRtW44CYoXxxw2okzBwPffpivMh/H+VUX gQakSffHgqwCbc8JQ0wN087itHD1++zxVZSXLq8= Message-Id: <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Dec 2010 03:15:21 -0800 To: ietf@ietf.org From: SM Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC In-Reply-To: <20101213132808.2379.30041.idtracker@localhost> References: <20101213132808.2379.30041.idtracker@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 11:15:06 -0000 At 05:28 13-12-10, The IESG wrote: >The IESG has received a request from an individual submitter to consider >the following document: >- ''Headers-Not-Recognized' HTTP Header Field' > as an >Experimental RFC These comments are not meant to discourage the author from bringing proposals to the IETF. Version -01 of this draft was submitted on November 21. It's not even a month and the draft is already at version -09. I don' think that "commit early, commit often" applies to Internet-Drafts. As this is probably the author's first draft going for Last Call, it would have been helpful to assign a document shepherd for the document to help the author with the IETF standards process. As a nit, the intended status should be "Experimental". From the Abstract (draft-yevstifeyev-http-headers-not-recognized-09): "This document defines mechanism which allows HTTP servers to notify clients about not recognized or not proceed headers" Shouldn't that have been "processed" instead of "proceed"? In Section 1.1: "However, all hosts are not able to support all the HTTP headers." Shouldn't that be HTTP servers? From Section 2.1: "If the HTTP host receives HTTP packet which contains some headers which are not supported by it, it is RECOMMENDED for it to include the Headers-Not-Recognized header in the response." That could be rewritten as: If the HTTP server receives a request header field that it does not support "Intermediate systems (also called middle-boxes), such as proxies, tunnels, gateways etc. MUST transfer the packets with Headers-Not- Recognized field to the destination host without changing the entity of this header if the unrecognized header had been present in the initial HTTP request (i. e. request which intermediate system received before transferring it to destination node), but SHOULD omit it if Headers-Not-Recognized header entity concerns to header added to initial request by middle-box." What do packets have to do with HTTP headers? In his replies during the Last Call [1][2], the author mentioned that this header is useful for debugging. I don't see any mention of that in the proposal. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg64867.html 2. http://www.ietf.org/mail-archive/web/ietf/current/msg64838.html From evnikita2@gmail.com Fri Dec 17 05:51:57 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAD93A6B39 for ; Fri, 17 Dec 2010 05:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNuEXcB-XR9w for ; Fri, 17 Dec 2010 05:51:56 -0800 (PST) Received: from mail-bw0-f50.google.com (mail-bw0-f50.google.com [209.85.214.50]) by core3.amsl.com (Postfix) with ESMTP id 7528D3A6B3B for ; Fri, 17 Dec 2010 05:51:55 -0800 (PST) Received: by bwg12 with SMTP id 12so889226bwg.37 for ; Fri, 17 Dec 2010 05:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=OQcqloMQTxFTwzgkcojgFGOHepMa/ZhyRSWJz79SfvY=; b=ucutYc2Oc/GNsy05P6l23annVoTxUzjV9Hzn8XiRpCSRj0UUEPgR+rLQWzPvoR97+M UjxiW54vf04nP14rfp6RG+EhaqMiu57MLLESjtVt+RPZeAWzEvL8DWrBTn7NoI2g/KTK jYC5BvQlxUnrmexF8dI6HfgEJa+E1J81I1AqU= 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=C6gnWSzglkG4uf3Bcfn4NmaQ6wW2UgqU3O8dKj8wfWn45BANx5K1T+yF0l5gowaeMH glH8PSGIgk9tJNmFsqS+JUTdjykawNrr/ePfssHn+cUFlYhY4t9GEEQFN9KAh+DdJyfg AMVVtLiiyiOOcP1EuKVXsxIg/ojvDB8agus3k= Received: by 10.204.128.78 with SMTP id j14mr617680bks.149.1292594021580; Fri, 17 Dec 2010 05:53:41 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id b17sm1845375bku.8.2010.12.17.05.53.38 (version=SSLv3 cipher=RC4-MD5); Fri, 17 Dec 2010 05:53:40 -0800 (PST) Message-ID: <4D0B6B6D.7040001@gmail.com> Date: Fri, 17 Dec 2010 15:53:49 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: SM Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC References: <20101213132808.2379.30041.idtracker@localhost> <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> In-Reply-To: <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 13:51:57 -0000 Hello all, Some answers that concern issues discussed below. 17.12.2010 13:15, SM wrote: > At 05:28 13-12-10, The IESG wrote: >> The IESG has received a request from an individual submitter to consider >> the following document: >> - ''Headers-Not-Recognized' HTTP Header Field' >> as an >> Experimental RFC > > These comments are not meant to discourage the author from bringing > proposals to the IETF. > > Version -01 of this draft was submitted on November 21. It's not even > a month and the draft is already at version -09. I don' think that > "commit early, commit often" applies to Internet-Drafts. As this is > probably the author's first draft going for Last Call, it would have > been helpful to assign a document shepherd for the document to help > the author with the IETF standards process. You are right, that is my first document in Last Call. > > As a nit, the intended status should be "Experimental". I'll correct it. > > From the Abstract (draft-yevstifeyev-http-headers-not-recognized-09): > > "This document defines mechanism which allows HTTP servers to notify > clients about not recognized or not proceed headers" > > Shouldn't that have been "processed" instead of "proceed"? I find 'processed' more acceptable for this case. However to mind it would be better to mention 'not supported' > > In Section 1.1: > > "However, all hosts are not able to support all the HTTP headers." > > Shouldn't that be HTTP servers? No. It should be 'hosts' in abstract - that is a mistake. > > From Section 2.1: > > "If the HTTP host receives HTTP packet which contains some headers > which are not supported by it, it is RECOMMENDED for it to include > the Headers-Not-Recognized header in the response." > > That could be rewritten as: > > If the HTTP server receives a request header field that it does not > support That will be corrected. > > "Intermediate systems (also called middle-boxes), such as proxies, > tunnels, gateways etc. MUST transfer the packets with Headers-Not- > Recognized field to the destination host without changing the entity > of this header if the unrecognized header had been present in the > initial HTTP request (i. e. request which intermediate system > received before transferring it to destination node), but SHOULD omit > it if Headers-Not-Recognized header entity concerns to header added > to initial request by middle-box." > > What do packets have to do with HTTP headers? What do you mean? Packets have nothing to do with headers, there is nothing about this in paragraph above. Maybe you meant middle-boxes? > > In his replies during the Last Call [1][2], the author mentioned that > this header is useful for debugging. I don't see any mention of that > in the proposal. Maybe, I'll add something related to this topic. I'll let you know as soon new version of the draft will be available (maybe that will be at the end of Last Call). All the best, Mykyta Yevstifeyev > > Regards, > -sm P.S. Could you please let me know what is your full name? > > 1. http://www.ietf.org/mail-archive/web/ietf/current/msg64867.html > 2. http://www.ietf.org/mail-archive/web/ietf/current/msg64838.html > From evnikita2@gmail.com Fri Dec 17 06:18:31 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF06F3A6B52 for ; Fri, 17 Dec 2010 06:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2+B0nnNqsGz for ; Fri, 17 Dec 2010 06:18:31 -0800 (PST) Received: from mail-bw0-f50.google.com (mail-bw0-f50.google.com [209.85.214.50]) by core3.amsl.com (Postfix) with ESMTP id D76FB3A6B4F for ; Fri, 17 Dec 2010 06:18:30 -0800 (PST) Received: by bwg12 with SMTP id 12so919502bwg.37 for ; Fri, 17 Dec 2010 06:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=cN0YAdHZx+c4u1NuVChVCeJFUj+VryEuZUQKU7jFSVk=; b=sRU4ASbir6CoPHXIVcMdmcbLj4+BdmggZTHD2Cc042I7uifn3iTUDIbSfJ8n8DFiS9 rE9AqlvfP6vNThB8C3yRtQVdvSkBaXFa9XrJ4h4eoCBSI8uKwDwIJfLu+ByX7cOSTMqH heO7PlV0d7Ldjmk0eta8YGVuuhX3ZcCiBQ7KY= 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=U2KcxM25Wd7AYmMpp1hltwNMSGaw4EZUnXebMSqFtXO1r0ti3bCUn2BoDzy1rzBGTh atgq5uzzWQCIKBqM1GP1f/Z/fHmRR2VEcWfZn1pQaWfx1kwhS/QRk2TqBnjoc/26d4c4 paGptZRiUX6jKf57TrqEaNgVfiY4J4MJ76fMc= Received: by 10.204.119.15 with SMTP id x15mr635652bkq.56.1292595617057; Fri, 17 Dec 2010 06:20:17 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id b17sm1861678bku.8.2010.12.17.06.20.15 (version=SSLv3 cipher=RC4-MD5); Fri, 17 Dec 2010 06:20:16 -0800 (PST) Message-ID: <4D0B71AA.5060305@gmail.com> Date: Fri, 17 Dec 2010 16:20:26 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daniel Stenberg Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC References: <20101213132808.2379.30041.idtracker@localhost> <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> <4D0B6B6D.7040001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SM , ietf@ietf.org, httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 14:18:32 -0000 17.12.2010 16:14, Daniel Stenberg wrote: > On Fri, 17 Dec 2010, Mykyta Yevstifeyev wrote: > >>> What do packets have to do with HTTP headers? > >> What do you mean? Packets have nothing to do with headers, there is >> nothing about this in paragraph above. Maybe you meant middle-boxes? > > Read through your -09 spec again. You speak of "HTTP packets" in > several places, where they should rather be "HTTP request" or "HTTP > responses" etc. Maybe I meant HTTP messages here. > > I also find the use of 'host' very confusing in the document as it is > clearly used instead of the more proper 'client' or 'server' in some > places. In previous version there have been the 'server' and 'client' terms instead 'host'. However it is obvious for me that there can be as servers as clients that do not recognize some headers of another side of exchange. > > The second paragraph in section 2.1 combines both these mistakes and > make a blob of text that I cannot understand: > > When HTTP host receives HTTP packet with Headers-Not-Recognized > header, it is RECOMMENDED that it avoids sending packets with headers > with mentioned in it names or tries to change them so that it is able > to recognize and process them. > > Does this say that if a client learns about headers that the server > doesn't support, it shouldn't send them in subsequent requests? No, that just describes the behavior of the host after receiving the H-N-R header. However this paragraph needs improvement, and I'll do that in the next version of the draft, which will bw available at the end of Last Call. All the best, Mykyta Yevstifeyev From julian.reschke@gmx.de Fri Dec 17 06:27:38 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B963A6B3D for ; Fri, 17 Dec 2010 06:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.673 X-Spam-Level: X-Spam-Status: No, score=-104.673 tagged_above=-999 required=5 tests=[AWL=-2.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhNZmXBVsCfQ for ; Fri, 17 Dec 2010 06:27:38 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 8996B3A69C9 for ; Fri, 17 Dec 2010 06:27:36 -0800 (PST) Received: (qmail invoked by alias); 17 Dec 2010 14:29:22 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp063) with SMTP; 17 Dec 2010 15:29:22 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Z1hdTCXjZDt1+eAfS2izARYmn30NQEwMWiUx+Ks pkmTFdNbyapcnX Message-ID: <4D0B73BA.9060909@gmx.de> Date: Fri, 17 Dec 2010 15:29:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC References: <20101213132808.2379.30041.idtracker@localhost> <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> <4D0B6B6D.7040001@gmail.com> <4D0B71AA.5060305@gmail.com> In-Reply-To: <4D0B71AA.5060305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: SM , ietf@ietf.org, Daniel Stenberg , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 14:27:38 -0000 On 17.12.2010 15:20, Mykyta Yevstifeyev wrote: > ... > In previous version there have been the 'server' and 'client' terms > instead 'host'. However it is obvious for me that there can be as > servers as clients that do not recognize some headers of another side of > exchange. > ... But clients can't respond with the header, so there's no point in pretending this applies to them. > ... Best regards, Julian From evnikita2@gmail.com Fri Dec 17 06:31:25 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D1A3A6B62 for ; Fri, 17 Dec 2010 06:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPChIE8x2toE for ; Fri, 17 Dec 2010 06:31:25 -0800 (PST) Received: from mail-bw0-f50.google.com (mail-bw0-f50.google.com [209.85.214.50]) by core3.amsl.com (Postfix) with ESMTP id A374E3A6B55 for ; Fri, 17 Dec 2010 06:31:24 -0800 (PST) Received: by bwg12 with SMTP id 12so935125bwg.37 for ; Fri, 17 Dec 2010 06:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=cfLFFv4YUP/slLBNaDNuqKK9ThHqWoKmPmmZBKo+HP8=; b=mxz6JEEZsEJea8750Jjzog0+x1jPVHuvSC6/Zg0LrFXzvv4iKwnRvPnObqoLtv4yyq D4T4ST/Iz86yt1bTzx+fD3miO6ekih5oFRpIHKcm8G2DXQdBhYTQ67iM54xQlWqe5opZ /AFlPvs5JWJmUyilSoFhY6jS8T2FtqjWV7tek= 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=ngqsrd0WiJCU3TQd8WLnN8Wz5gt8Q0kovEQI1KKGB90CiagqTGyyXpimNfclXFRDGn ngiAtD8IFFC6y8djp6CX8kxAu9bEr/p9ZDwt6cdorC8+slZac4CxFO/0wjOJzPRAuHvI qKH8+T2YtmZgoFoQrHf4Jl8sp1PwfwLbNCNlo= Received: by 10.204.68.13 with SMTP id t13mr625491bki.164.1292596390944; Fri, 17 Dec 2010 06:33:10 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id s14sm1641667bkb.4.2010.12.17.06.33.08 (version=SSLv3 cipher=RC4-MD5); Fri, 17 Dec 2010 06:33:10 -0800 (PST) Message-ID: <4D0B74AF.9080102@gmail.com> Date: Fri, 17 Dec 2010 16:33:19 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Julian Reschke Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC References: <20101213132808.2379.30041.idtracker@localhost> <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> <4D0B6B6D.7040001@gmail.com> <4D0B71AA.5060305@gmail.com> <4D0B73BA.9060909@gmx.de> In-Reply-To: <4D0B73BA.9060909@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SM , ietf@ietf.org, Daniel Stenberg , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 14:31:25 -0000 17.12.2010 16:29, Julian Reschke wrote: > On 17.12.2010 15:20, Mykyta Yevstifeyev wrote: >> ... >> In previous version there have been the 'server' and 'client' terms >> instead 'host'. However it is obvious for me that there can be as >> servers as clients that do not recognize some headers of another side of >> exchange. >> ... > > But clients can't respond with the header, so there's no point in > pretending this applies to them. In my document the term 'header' means 'header field' since client are able to put any header to the request and I meant just it. Mykyta > >> ... > > Best regards, Julian > From julian.reschke@gmx.de Fri Dec 17 06:58:52 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F1F3A6AF2 for ; Fri, 17 Dec 2010 06:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.671 X-Spam-Level: X-Spam-Status: No, score=-104.671 tagged_above=-999 required=5 tests=[AWL=-2.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFxtuw2WXPtQ for ; Fri, 17 Dec 2010 06:58:51 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id DBF4C3A6AEE for ; Fri, 17 Dec 2010 06:58:50 -0800 (PST) Received: (qmail invoked by alias); 17 Dec 2010 15:00:36 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp066) with SMTP; 17 Dec 2010 16:00:36 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19ID7EtA91Ip4FYVKYH/6LAgxVCISsnxIZGQspPNW WDd+OWZ7ytMFtp Message-ID: <4D0B7B0D.7050105@gmx.de> Date: Fri, 17 Dec 2010 16:00:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC References: <20101213132808.2379.30041.idtracker@localhost> <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> <4D0B6B6D.7040001@gmail.com> <4D0B71AA.5060305@gmail.com> <4D0B73BA.9060909@gmx.de> <4D0B74AF.9080102@gmail.com> In-Reply-To: <4D0B74AF.9080102@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: SM , ietf@ietf.org, Daniel Stenberg , httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 14:58:52 -0000 On 17.12.2010 15:33, Mykyta Yevstifeyev wrote: > 17.12.2010 16:29, Julian Reschke wrote: >> On 17.12.2010 15:20, Mykyta Yevstifeyev wrote: >>> ... >>> In previous version there have been the 'server' and 'client' terms >>> instead 'host'. However it is obvious for me that there can be as >>> servers as clients that do not recognize some headers of another side of >>> exchange. >>> ... >> >> But clients can't respond with the header, so there's no point in >> pretending this applies to them. > In my document the term 'header' means 'header field' since client are > able to put any header to the request and I meant just it. I realize that you use "header" as synonym for "header field". What I was trying to say was that it doesn't make sense to speak of clients and servers in general, when it's really only the server who can set the H-N-R header field. Best regards, Julian From csp@csperkins.org Fri Dec 17 09:58:07 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64323A6975; Fri, 17 Dec 2010 09:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.158 X-Spam-Level: X-Spam-Status: No, score=-103.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLWrgH81ziON; Fri, 17 Dec 2010 09:58:06 -0800 (PST) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 16AC63A6941; Fri, 17 Dec 2010 09:58:06 -0800 (PST) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PTeav-0000lb-Zb; Fri, 17 Dec 2010 17:59:53 +0000 Subject: Re: TSV-Dir Last Call review of draft-ietf-avt-rtp-cnames-02 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Fri, 17 Dec 2010 17:59:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Allison Mankin X-Mailer: Apple Mail (2.1082) Cc: Allison Mankin , Ali Begen , IETF Discussion , Transport Directorate X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 17:58:07 -0000 Allison, Thanks for the review. These all seem like reasonable suggestions, which = we should incorporate.=20 Colin On 14 Dec 2010, at 02:56, Allison Mankin wrote: > TSV-DIR Last Call review of "Guidelines for Chosing RTP Control = Protocol (RTCP) Canonical Names (CNAMEs) >=20 > I've reviewed this document as part of the transport area = directorate's ongoing effort to review key IETF documents. These = comments were written primarily for the transport area directors, but = are copied to the document's authors for their information and to allow = them to address any issues raised. The authors should consider this = review together with any other last-call comments they receive. Please = always cc tsv-dir@ietf.org if you reply to or forward this review. >=20 > Summary: This draft is on the right track, but has open issues = described in the review. >=20 > The review below gives my basis for three recommendations: > 1. For long-term persistent CNAMEs, differentiate among the UUID = "Versions" in RFC 4122 > 2. For short-term persistent CNAMEs, allow IPv4-only endpoints to = generate a pseudo-random alternative to their MAC, if desired > 3. For per-session CNAMEs, provide some guidance for the random value = and the key, which are currently left underspecified. >=20 > Section 3 sets up the major requirement to be met, which is better = uniqueness properties than those of the CNAME generation in RFC 3550. = There's a hint in the last sentence of the section about an additional = requirement to afford privacy support. This sentence only mentions = avoiding exposure of private addresses. Avoidance of linkage among RTP = streams due to the use of fixed CNAMEs comes up later. >=20 > Section 4 sets up the CNAME types, persistent versus per-session, and = within persistent types, short-term IPv4-only, short-term IPv6-capable, = and long-term. The methods of generating these CNAMEs are distinct and = I understand from the WG mailing list discussion of their AD review that = they are to be specified as mandatory. On December 2, Ali wrote to AVT = that the next revision will change language in Section 4 from the = existing: >=20 > Other methods, beyond the three methods listed above, are not > compliant with this specification and SHOULD NOT be used. >=20 > To the following: >=20 > It is believed that obtaining uniqueness is an important property = that > requires careful evaluation of the method. This document provides a > number of methods, for which it is believed that at least one of = them > would meet all deployment scenarios. This document therefore does = not > provide for the implementor to define and select an alternative > method. >=20 > A future specification might define an alternative method for > generating RTCP CNAMEs as long as the proposed method has = appropriate > uniqueness, and there is consistency between the methods used for > multiple RTP sessions that are to be correlated. However, such a > specification needs to be reviewed and approved before deployment. >=20 > The second sentence of the first paragraph could be written better: >=20 > This document provides a number of methods, at least one of which > should be suitable for all deployment scenarios. Agreed. > My remaining discussion is about making this statement more true. >=20 > First, all the methods should afford some access to privacy support, = but as written, there is little or none for the long-term persistent and = the IPv4-only short-term persistent CNAMEs. >=20 > An implementation that wishes to > discourage this type of third-party monitoring can generate a unique > RTCP CNAME for each RTP session, or group of related RTP sessions, > that it joins. Such a per-session RTCP CNAME cannot be used for > traffic analysis, and so provides some limited form of privacy >=20 > The above statement implies that a long-term persistent CNAME = inherently cannot have privacy support. It's not necessarily so: if the = CNAME doesn't embed identifying information, observers get connections = among multiple streams but they only don't have a fixed host identity, = only a pseudonym. >=20 > Specific issues per CNAME method: >=20 > 1) Long-term persistent CNAMEs are required to be generated by an = adaptation of RFC 4122 UUIDs (the adaptation is to leave off the string = "urn:uuid:"). The draft references Section 3 of RFC 4122. It should = reference Section 4 instead because Section 3 does not detail the UUID = components. =20 Agreed. This looks like a typo that should be fixed. > Moreover, it would be good for the draft to advise on usage among the = four different versions of UUID that RFC 4122 covers: >=20 > + Version 1: generated from clock + MAC, or + MAC-format random number > + Version 3: generated from namespace:name > + Version 4: generated from "truly random or pseudo-random number" > + Version 5: generated from hash of namespace:name >=20 > There needs to be some guidance because the use of the UUID Versions = 3/5, derived from namespace:name, has the same problem with = non-uniqueness of FQDNs as the RFC 3550 FQDN-based CNAMEs. Perhaps this = document should advise against using 3/5. In addition, right now the = draft is silent on mitigating identity exposure, but it could offer some = guidance towards using the variant of Version 1 that does not expose the = MAC or towards using Version 4. This guidance seems appropriate, thanks. > 2) Short-term persistent CNAMEs are allowed to use a pseudo-randomly = generated RFC 4941 IPv6 privacy address if the device is IPv6-capable, = but are required to exposetheir MACs if the device is IPv4-only. Why = not allow IPv4-only endpoints to to generate pseudo-random MACs using = the specification of doing so provided for the Version 1 variant in RFC = 4122? That seems like a reasonable addition. > 3) Per-session CNAMEs are generated using SHA1-HMAC over the = concatenation of the initially-used SSRC, the source and destination = addresses and ports, and "a randomly generated value". RFC 4086 is = given as a reference for the randomly generated value. I think an = implementer would like to know how many bytes of randomly generated = value should be used; this doesn't come out clearly from reading RFC = 4086. Further, what are the requirements for the key for HMAC here? In = reading RFC 2104, the reference for HMAC, I end up with some ideas about = the key length, but not about how long/where I can use the same key or = whether there are problematic keys - to mention two questions that come = to mind. Keying would not normally be easy to under-specify this way = because a security application would call for some keying details, but = in this application there is no security use for the keys. Either it = would be good to add some guidance or perhaps SHA1-HMAC could be = replaced with an "insecure hash." We'll add some guidance in -03. Thanks, Colin --=20 Colin Perkins http://csperkins.org/ From hartmans@mit.edu Fri Dec 17 12:54:20 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AC53A69C2; Fri, 17 Dec 2010 12:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZaX7XGnXb9A; Fri, 17 Dec 2010 12:54:19 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 928813A6998; Fri, 17 Dec 2010 12:54:19 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EC778202C9; Fri, 17 Dec 2010 15:54:58 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3E21C4060; Fri, 17 Dec 2010 15:55:51 -0500 (EST) From: Sam Hartman To: Sam Hartman Subject: Re: Secdir review of draft-ietf-isis-trill References: Date: Fri, 17 Dec 2010 15:55:51 -0500 In-Reply-To: (Sam Hartman's message of "Tue, 14 Dec 2010 11:09:20 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org, secdir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 20:54:20 -0000 Hi. I've been asked by the trill authors to clarify what I meant by my secdir review. That's certainly fair. I think there are two issues. The first is that I think that draft-ietf-isis-trill does an adequate job of discussing the security implications of IS-IS on trill. I've read the security considerations section of draft-ietf-trill-rbridge-protocol and I think it doesn't do so either. However, it comes very close. If I understand Is-IS security correctly, the only attack that we would expect a routing protocol to deal with that it does not is replays. (IS-Is is no worse than anything else here.) The impact of replays is a denial of service. If I'm understanding section 6.2 of draft-ietf-trill-rbridge-protocol correctly, similar denial of service attacks are also possible with trill-specific messages. If my understanding of the impact of IS-IS security (even with authentication) is sufficient, I think this concern could be addressed by adding a sentence to the security considerations section of draft-ietf-isis-trill saying something like "Even when the IS-IS authentication is used, replays of IS-IS packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." I have a second large issue with the way we've handled trill. First I'd like to compliment the authors of draft-ietf-trill-rbridge-protocol, particularly on the security considerations section, but the document quality of other sections of that document I've looked at is high. They've done a good job of describing what they've done and as far as I can tell delivering what they've said they would deliver. However, something went wrong somewhere. We have some standards that we've agreed to as a community for the security of new work we do. It's my opinion that trill does not meet those standards. The document doesn't claim it does. I think that was wrong, however the mistake was in the review of RFC 5556 (the TRILL problem statement), which clearly sets out what TRILL was going to do. I believe I was on the IESG at a time when that document was reviewed, so I especially don't have room to complain here. So, actually even were I on the IESG, I would not hold up the protocol over this issue. Looking forward to future work, though, I think we should be more consistent about applying our community standards to work we charter. If those standards are wrong, let's revise them. No, TRILL should not have been forced to solve the ethernet control plane security problem. However TRILL should have had a security mechanism that meets current standards so that when the ethernet control plane is updated TRILL never ends up being the weakest link. As best I can tell, TRILL does meet the security goals stated in its problem statement. Also, my comment about document quality was never intended to be blocking. While I don't believe draft-ietf-isis-trill is of as high quality as draft-ietf-trill-rbridge-protocol, I did manage to understand it without the rbridge-protocol document. The authors claim that should not be requried; I think if I had looked at the rbridge-protocol document first I would have concluded that it was more clear than isis-trill, although I think it's also true that I would have been less bothered. Either way, I did manage to follow both documents. --Sam From Adrian.Farrel@huawei.com Fri Dec 17 13:22:53 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE16F3A6C2A; Fri, 17 Dec 2010 13:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.641 X-Spam-Level: X-Spam-Status: No, score=-103.641 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlMzLG2Qc64d; Fri, 17 Dec 2010 13:22:52 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id D44E03A6C1D; Fri, 17 Dec 2010 13:22:52 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LDL00J18CT30P@usaga01-in.huawei.com>; Fri, 17 Dec 2010 13:24:40 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LDL00EHDCT1U5@usaga01-in.huawei.com>; Fri, 17 Dec 2010 13:24:39 -0800 (PST) Date: Fri, 17 Dec 2010 21:24:38 +0000 From: Adrian Farrel Subject: RE: Secdir review of draft-ietf-isis-trill In-reply-to: To: 'Sam Hartman' Message-id: <010701cb9e30$d17a1990$746e4cb0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQEnHMNUQZgblglcEzvZ5LOribmVJgIlUz+ilNz8YHA= References: Cc: draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org, secdir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 21:22:54 -0000 Sam, Thanks for your work. Can I clarify. You wrote: > The first is that I think that draft-ietf-isis-trill does an adequate > job of discussing the security implications of IS-IS on trill. I've > read the security considerations section of > draft-ietf-trill-rbridge-protocol and I think it doesn't do so either. I you have one positive and one negative statement. I think you meant them to both be negative. Perhaps you could confirm. Cheers, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Sam > Hartman > Sent: 17 December 2010 20:56 > To: Sam Hartman > Cc: draft-ietf-isis-trill@tools.ietf.org; ietf@ietf.org; secdir@ietf.org > Subject: Re: Secdir review of draft-ietf-isis-trill > > Hi. I've been asked by the trill authors to clarify what I meant by my > secdir review. > > That's certainly fair. > > I think there are two issues. > > The first is that I think that draft-ietf-isis-trill does an adequate > job of discussing the security implications of IS-IS on trill. I've > read the security considerations section of > draft-ietf-trill-rbridge-protocol and I think it doesn't do so either. > > However, it comes very close. If I understand Is-IS security correctly, > the only attack that we would expect a routing protocol to deal with > that it does not is replays. (IS-Is is no worse than anything else > here.) The impact of replays is a denial of service. If I'm > understanding section 6.2 of draft-ietf-trill-rbridge-protocol > correctly, similar denial of service attacks are also possible with > trill-specific messages. > > If my understanding of the impact of IS-IS security (even with > authentication) is sufficient, I think this concern could be addressed > by adding a sentence to the security considerations section of > draft-ietf-isis-trill saying something like "Even when the IS-IS > authentication is used, replays of IS-IS packets can create > denial-of-service conditaions; see RFC 6039 for details. These issues > are similar in scope to those discussed in section 6.2 of > draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." > > I have a second large issue with the way we've handled trill. First I'd > like to compliment the authors of draft-ietf-trill-rbridge-protocol, > particularly on the security considerations section, but the document > quality of other sections of that document I've looked at is high. > They've done a good job of describing what they've done and as far as I > can tell delivering what they've said they would deliver. > > However, something went wrong somewhere. We have some standards that > we've agreed to as a community for the security of new work we do. It's > my opinion that trill does not meet those standards. The document > doesn't claim it does. > > I think that was wrong, however the mistake was in the review of RFC > 5556 (the TRILL problem statement), which clearly sets out what TRILL > was going to do. I believe I was on the IESG at a time when that > document was reviewed, so I especially don't have room to complain here. > > So, actually even were I on the IESG, I would not hold up the protocol > over this issue. > > Looking forward to future work, though, I think we should be more > consistent about applying our community standards to work we charter. If > those standards are wrong, let's revise them. No, TRILL should not have > been forced to solve the ethernet control plane security > problem. However TRILL should have had a security mechanism that meets > current standards so that when the ethernet control plane is updated > TRILL never ends up being the weakest link. As best I can tell, TRILL > does meet the security goals stated in its problem statement. > > Also, my comment about document quality was never intended to be > blocking. While I don't believe draft-ietf-isis-trill is of as high > quality as draft-ietf-trill-rbridge-protocol, I did manage to understand > it without the rbridge-protocol document. The authors claim that should > not be requried; I think if I had looked at the rbridge-protocol > document first I would have concluded that it was more clear than > isis-trill, although I think it's also true that I would have been less > bothered. Either way, I did manage to follow both documents. > > --Sam > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From hartmans@mit.edu Fri Dec 17 13:31:57 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE08D3A6C2A; Fri, 17 Dec 2010 13:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzMlGiFUoYXt; Fri, 17 Dec 2010 13:31:57 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3CBBC3A6C1D; Fri, 17 Dec 2010 13:31:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id AA0AC2016B; Fri, 17 Dec 2010 16:32:38 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E558F4060; Fri, 17 Dec 2010 16:33:30 -0500 (EST) From: Sam Hartman To: Adrian.Farrel@huawei.com Subject: Re: Secdir review of draft-ietf-isis-trill References: <010701cb9e30$d17a1990$746e4cb0$@huawei.com> Date: Fri, 17 Dec 2010 16:33:30 -0500 In-Reply-To: <010701cb9e30$d17a1990$746e4cb0$@huawei.com> (Adrian Farrel's message of "Fri, 17 Dec 2010 21:24:38 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-isis-trill@tools.ietf.org, 'Sam Hartman' , ietf@ietf.org, secdir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 21:31:58 -0000 >>>>> "Adrian" == Adrian Farrel writes: Adrian> Sam, Thanks for your work. Adrian> Can I clarify. You wrote: > The first is that I think that draft-ietf-isis-trill does an adequate >> job of discussing the security implications of IS-IS on trill. >> I've read the security considerations section of >> draft-ietf-trill-rbridge-protocol and I think it doesn't do so >> either. Adrian> I you have one positive and one negative statement. I think Adrian> you meant them to both be negative. Perhaps you could Adrian> confirm. You are correct. From nordmark@acm.org Fri Dec 17 13:59:51 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA7B3A69FC; Fri, 17 Dec 2010 13:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcklKfN9geib; Fri, 17 Dec 2010 13:59:50 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by core3.amsl.com (Postfix) with ESMTP id 80DDF3A69FB; Fri, 17 Dec 2010 13:59:50 -0800 (PST) Received: from [10.10.10.103] (70-36-183-22.dsl.dynamic.sonic.net [70.36.183.22]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id oBHM1Xft007102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 14:01:35 -0800 Message-ID: <4D0BDDC0.6060201@acm.org> Date: Fri, 17 Dec 2010 14:01:36 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101025 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Sam Hartman Subject: Re: Secdir review of draft-ietf-isis-trill References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org, secdir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 21:59:51 -0000 On 12/17/10 12:55 PM, Sam Hartman wrote: > However, it comes very close. If I understand Is-IS security correctly, > the only attack that we would expect a routing protocol to deal with > that it does not is replays. (IS-Is is no worse than anything else > here.) The impact of replays is a denial of service. If I'm > understanding section 6.2 of draft-ietf-trill-rbridge-protocol > correctly, similar denial of service attacks are also possible with > trill-specific messages. > > If my understanding of the impact of IS-IS security (even with > authentication) is sufficient, I think this concern could be addressed > by adding a sentence to the security considerations section of > draft-ietf-isis-trill saying something like "Even when the IS-IS > authentication is used, replays of IS-IS packets can create > denial-of-service conditaions; see RFC 6039 for details. These issues > are similar in scope to those discussed in section 6.2 of > draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." Sam, Adding just this sentence to draft-ietf-isis-trill (the code point document) seems odd. Your comment is really a comment on the security of IS-IS, and not specific to TRILL and unrelated to the code points. If we need to point out this IS-IS issue the right place to do that would have been in draft-ietf-trill-rbridge-protocol; we shouldn't make draft-ietf-isis-trill a random collection of (editorial) corrections against the IS-IS spec or the TRILL spec. I don't know if an RFC-ed note for draft-ietf-trill-rbridge-protocol makes sense at this late date (close to a year after the IESG approved it). But one could add a sentence to the second paragraph in section 6 pointing specifically at replay attacks and RFC 6039. > Looking forward to future work, though, I think we should be more > consistent about applying our community standards to work we charter. If > those standards are wrong, let's revise them. No, TRILL should not have > been forced to solve the ethernet control plane security > problem. However TRILL should have had a security mechanism that meets > current standards so that when the ethernet control plane is updated > TRILL never ends up being the weakest link. As best I can tell, TRILL > does meet the security goals stated in its problem statement. Do you have a concrete case where TRILL would end up being the weakest link? We designed the protocol so that ESADI can have higher learning confidence level that learning from data frames. This was to ensure that if e.g., 802.1x or some future technology is used at the edge to autenticate stations, we can give that higher confidence thus ensure that TRILL benefits from that additional security. I don't understand the implications of your reference to current standards. Are you saying that if TRILL was chartered today, its charter would say that it "MUST NOT reuse IS-IS or OSPF since those are not sufficiently secure"? Such a stance doesn't make sense to me, since we want to leverage existing protocols while we improve the security of those existing protocols, instead of prohibiting re-use. Regards, Erik From denis.pinkas@bull.net Fri Dec 17 00:21:31 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA023A6940; Fri, 17 Dec 2010 00:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPhkC2Ho1wMc; Fri, 17 Dec 2010 00:21:29 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id 2ADEA3A6926; Fri, 17 Dec 2010 00:21:29 -0800 (PST) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 34BBE138075; Fri, 17 Dec 2010 09:30:16 +0100 (CET) Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2010121709231323:56543 ; Fri, 17 Dec 2010 09:23:13 +0100 From: "Denis Pinkas" To: "ietf", "smime", "pkix" Subject: Re: [smime] Fwd: Last Call: (SignerInfo Algorithm Protection Attribute) to Proposed Standard Date: Fri, 17 Dec 2010 09:23:11 +0100 Message-Id: References: <4CFD6726.8040100@ieca.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 17/12/2010 09:23:13, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 17/12/2010 09:23:15, Serialize complete at 17/12/2010 09:23:15 Content-Type: multipart/alternative; boundary="----=_NextPart_10121709231114517662106_002" X-Mailman-Approved-At: Fri, 17 Dec 2010 14:56:42 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 08:21:31 -0000 ------=_NextPart_10121709231114517662106_002 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I have a few comments about draft-schaad-smime-algorithm-attribute-03.txt= : 1) The key question is what should contain the field signatureAlgorithm ? SignatureAlgorithmIdentifier is defined in section 10.1.2 from RFC 5652: 10.1.2. SignatureAlgorithmIdentifier The SignatureAlgorithmIdentifier type identifies a signature algorithm, and it can also identify a message digest algorithm. Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with SHA-256. A signature algorithm supports signature generation and verification operations. The signature generation operation uses the message digest and the signer's private key to generate a signature value. The signature verification operation uses the message digest and the signer's public key to determine whether or not a signature value is valid. Context determines which operation is intended. SignatureAlgorithmIdentifier ::=3D AlgorithmIdentifier Some examples are questionable: is RSA really a "signature algorithm" ? sha-1withRSA is really a signature mechanism, since it cannot be used for= encryption. If "real signature algorithms" were being used in the OID, then half of t= he problems mentioned in the draft would disappear. This case should be mentioned in the draft. =20 The draft should also recommend the use of signature algorithms using bot= h a hash function and an asymetric algorithm. 2) We come from a point where, 20 years ago, the same certificate was use= d for three purposes:=20 authentication, non repudiation and encipherment. RSA was the single algo= rithm used in practice. Since then, there are many situations where different certificates are us= ed for each purpose. We now should recommend to use "real signature algorithms", which mean an= OID specifying=20 a combination of a hash function and an asymetric cryptographic algorithm= . If a certificate is being used, then an OID specifying the algorithm in t= he certificate should be OID=20 specifying a combination of a hash function and an asymetric cryptographi= c algorithm. When certificates are being used, when the ESSCertID is being used, and w= hen "real signature algorithms" are being used then the new proposed protection attribute is not needed. The current draft does not mention this possibility. 3) There is another draft under discussion in the PKIX WG called: draft-i= etf-pkix-ocspagility-09. Although the field "certIdentifier" below is misnamed, the idea is to say= that for Elliptic Curves we need two parameters=20 instead of one. This is what the proposed draft is attempting to say: PreferredSignatureAlgorithm ::=3D SEQUENCE { sigIdentifier = AlgorithmIdentifier, certIdentifier AlgorithmIdentifier OPTIONAL = } The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of R= FC 5280 [RFC5280] sigIdentifier specifies the signature algorithm the client prefers, = e.g. algorithm=3Decdsa-with-sha256. Parameters are absent for most comm= on signature algorithms. certIdentifier specifies the subject public key algorithm identifier = the client prefers in the server's certificate used to validate the OC= SP response. e.g. algorithm=3Did-ecPublicKey and parameters=3D secp256r= 1. certIdentifier is OPTIONAL and provides means to specify parameters = necessary to distinguish among different usages of a particular algorit= hm, e.g. it may be used by the client to specify what curve it supports= for a given elliptic curve algorithm. Note the this draft provides a correct example for a signature algorithm = identifier: ecdsa-with-sha256 The draft proposed by Jim should consider the case of OIDs for Elliptic C= urves=20 4) The draft is missing a risk analysis or examples for real possibilitie= s of substitution.=20 For the above reasons, I believe that a new draft should be issued. Denis ----------=20 >From : smime-bounces=20 To : smime=20 Date : 2010-12-06, 23:43:50 Subject : [smime] Fwd: Last Call: (SignerInfo Algorithm Protection Attrib= ute) to Proposed Standard -------- Original Message -------- Subject: Last Call: =20 (Signer Info Algorithm Protection Attribute) to Proposed Standard Date: Mon, 06 Dec 2010 14:35:04 -0800 From: The IESG To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Signer Info Algorithm Protection Attribute' 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-01-03. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attribute/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attribute/ 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 _______________________________________________ smime mailing list smime@ietf.org https://www.ietf.org/mailman/listinfo/smime ------=_NextPart_10121709231114517662106_002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =
I have a few comments about=20 draft-schaad-smime-algorithm-attribute-03.txt:
 
1) The key question is what should contain the field signatureAlgori= thm=20 ?
 
SignatureAlgorithmIdentifier is defined in section 10.1.2 from RFC=20 5652:
 

10.1.2. =20 SignatureAlgorithmIdentifier

   The SignatureAlgorithmIde= ntifier=20 type identifies a signature
 &n= bsp;=20 algorithm, and it can also identify a message digest algorithm.   Examples include RSA, DSA= , DSA=20 with SHA-1, ECDSA, and ECDSA with
   SHA-256.  A signature algorithm supports = signature=20 generation and
  =20 verification operations.  <= /SPAN>The=20 signature generation operation uses the
   message digest and the si= gner's=20 private key to generate a signature
   value.  The signature verification oper= ation=20 uses the message digest
  = =20 and the signer's public key to determine whether or not a=20 signature
   value = is=20 valid.  Context determines = which=20 operation is intended.

 &nb= sp; =20   SignatureAlgorithmIdentifi= er ::=3D=20 AlgorithmIdentifier

 
Some examples are questionable: is RSA really a "signature algo= rithm"=20 ?
sha-1withRSA is really a signature mechanism, since it cannot be use= d for=20 encryption.
 
If "real signature algorithms" were being used in the OID, then half= =20 of the problems mentioned in the draft would disappear.
This case should be mentioned in the draft.
 
The draft should also recommend the use of signature algorithms usin= g both=20 a hash function and an asymetric algorithm.
 
2) We come from a point where, 20 years ago, the same certifica= te=20 was used for three purposes:
authentication, non repudiation and= =20 encipherment. RSA was the single algorithm used in practice.
Since then, there are many situations where different certificates a= re used=20 for each purpose.
 
We now should recommend to use "real signature algorithms", which me= an an=20 OID specifying
a combination of a hash function and an asymetric= =20 cryptographic algorithm.
 
If a certificate is being used, then an OID specifying the algorithm= in the=20 certificate should be OID 
specifying a combination of a hash fun= ction=20 and an asymetric cryptographic algorithm.
 
When certificates are being used, when the ESSCertID is being u= sed,=20 and when "real signature algorithms" are being used
then the new propo= sed=20 protection attribute is not needed.
 
The current draft does not mention this possibility.
 
3) There is another draft under discussion in the PKIX WG called: draft-ietf-pkix-ocspagility-09.

Although the field "certIdentifier" below= is=20 misnamed, the idea is to say that for Elliptic Curves we need two paramet= ers=20
instead of one. This is what the proposed draft is attempting to=20 say:
     PreferredSignatu=
reAlgorithm ::=3D SEQUENCE {
   &=
nbsp;    sigIdentifier   AlgorithmIdentifier,
&n=
bsp;       certIdentifier  AlgorithmIdentifier OPTIONAL
        }
   The=
 syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of
   RFC 5280 [RFC5280]<=
/PRE>
   sigIdentifier spec=
ifies the signature algorithm the client prefers,
   common signa=
ture algorithms.
&nb=
sp;  certIdentifier specifies the subject public key algorith=
m identifier
   the client pref=
ers in the server's certificate used to validate the
   OCSP response. e.g. algorithm=3Did-ecPublicKey a=
nd parameters=3D
   secp256r1.<=
o:p>
   =
certIdentifier is OPTIONAL and provides means to specify parameters
   necessary to distinguish among di=
fferent usages of a particular
   algorithm, e.g. it may be used by the client to specify what curve it<=
BR>   supports for a given ellipti=
c curve algorithm.
Note the this draft provides a correct example for a signature algor= ithm=20 identifier: ecdsa-with-sha256
The draft proposed by Jim should consider the case of OIDs for=20 Elliptic Curves
 
4) The draft is missing a risk analysis or examples for real=20 possibilities of substitution.
 
For the above reasons, I believe that a new draft should be issued.<= /DIV>
 
Denis
 
----------
From=20 : smime-bounces To=20 : smime
Date=20 : 2010-12-06, 23:43:50
Subject=20 : [smime] Fwd: Last Call:=20 (SignerInfo Algorithm=20 Protection Attribute) to Proposed Standard

-------- Original Message --------
Subject: Last Call:=20 <draft-schaad-smime-algorithm-attribute-03.txt>
(Signer Info=20 Algorithm Protection Attribute) to Proposed Standard
Date: Mon, 06 D= ec 2010=20 14:35:04 -0800
From: The IESG <iesg-secretary@ietf.org>= ;
To:=20 IETF-Announce <ietf-announce@ietf.org><= BR>
The=20 IESG has received a request from an individual submitter to considerthe=20 following document:
- 'Signer Info Algorithm Protection=20 Attribute'
   <draft-schaad-smime-algorithm-attrib= ute-03.txt>=20 as a Proposed Standard

The IESG plans to make a decision in the = next=20 few weeks, and solicits
final comments on this action. Please send=20 substantive comments to the
ietf@ietf.org mailing lists by 2011-= 01-03.=20 Exceptionally, comments may be
sent to iesg@ietf.org instead. In either cas= e, please=20 retain the
beginning of the Subject line to allow automated=20 sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-at= tribute/

IESG=20 discussion can be tracked via
http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-at= tribute/


No=20 IPR declarations have been submitted directly on this=20 I-D.
_______________________________________________
IETF-Announc= e=20 mailing list
IETF-Announce@ietf.org
<= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ietf-announce">https://ww= w.ietf.org/mailman/listinfo/ietf-announce

____________________= ___________________________
smime=20 mailing list
smime@ietf.orghttps://www.ietf.o= rg/mailman/listinfo/smime

------=_NextPart_10121709231114517662106_002-- From karlheinz.wolf@nic.at Fri Dec 17 00:29:47 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609C63A694D; Fri, 17 Dec 2010 00:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.429 X-Spam-Level: X-Spam-Status: No, score=-9.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de6MSDcCVzOJ; Fri, 17 Dec 2010 00:29:46 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id E5B193A68FD; Fri, 17 Dec 2010 00:29:44 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.46 ; Fri, 17 Dec 2010 09:31:29 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.722.0; Fri, 17 Dec 2010 09:31:26 +0100 Content-Class: urn:content-classes:message Subject: AW: Gen-ART IETF LC review of draft-ietf-ecrit-lost-servicelistboundary Date: Fri, 17 Dec 2010 09:28:27 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB9DC4.CA42FA4D" Message-ID: <8BC845943058D844ABFC73D2220D466506876FA7@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: Gen-ART IETF LC review of draft-ietf-ecrit-lost-servicelistboundary Thread-Index: AcuTybiC/+hqNiudRUOFZK+8ttfUZgJ+qg7k References: <4cfa61a4.eaecd80a.64b7.ffff8243@mx.google.com> From: Karl Heinz Wolf To: Roni Even , General Area Review Team , X-XWALL-BCKS: auto X-Mailman-Approved-At: Fri, 17 Dec 2010 14:56:42 -0800 Cc: IETF-Discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 08:29:47 -0000 ------_=_NextPart_001_01CB9DC4.CA42FA4D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB9DC4.CA42FA4D" ------_=_NextPart_002_01CB9DC4.CA42FA4D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni, thank you for your review and please apologize my delayed response. I agree to your comments, the 2. one is really a good catch! Thank you, Karl -----Urspr=FCngliche Nachricht----- Von: ietf-bounces@ietf.org im Auftrag von Roni Even Gesendet: Sa 12/4/2010 4:41 An: 'General Area Review Team'; = draft-ietf-ecrit-lost-servicelistboundary.all@tools.ietf.org Cc: 'IETF-Discussion list' Betreff: Gen-ART IETF LC review of = draft-ietf-ecrit-lost-servicelistboundary =20 Hi, =20 I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = . =20 Please resolve these comments along with any other Last Call comments = you may receive. =20 Document: draft-ietf-ecrit-lost-servicelistboundary-04 Reviewer: Roni Even Review Date: 2010-12-04 IETF LC End Date: 2010-12-14 IESG Telechat date: (if known) =20 Summary: This draft is ready for publication as an Experimental RFC. = There are some nits =20 Major issues: =20 Minor issues: =20 Nits/editorial comments:=20 1. In the abstract the document starts with LoST, Please expand to = Location-to-Service Translation 2. At the end of section 3.2 in the note, I think that the first = "getServiceListBoundary" should be " getServiceBoundary" =20 =20 =20 Roni Even ------_=_NextPart_002_01CB9DC4.CA42FA4D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: Gen-ART IETF LC review of = draft-ietf-ecrit-lost-servicelistboundary

Roni,

thank you for your review and please apologize my delayed response.
I agree to your comments, the 2. one is really a good catch!

Thank you,
Karl



-----Urspr=FCngliche Nachricht-----
Von: ietf-bounces@ietf.org im Auftrag von Roni Even
Gesendet: Sa 12/4/2010 4:41
An: 'General Area Review Team'; = draft-ietf-ecrit-lost-servicelistboundary.all@tools.ietf.org
Cc: 'IETF-Discussion list'
Betreff: Gen-ART IETF LC review of = draft-ietf-ecrit-lost-servicelistboundary

Hi,



I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at <http://w= iki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



Please resolve these comments along with any other Last Call comments = you may receive.



Document: draft-ietf-ecrit-lost-servicelistboundary-04

Reviewer: Roni Even

Review Date: 2010-12-04

IETF LC End Date: 2010-12-14

IESG Telechat date: (if known)



Summary: This draft is ready for publication as an Experimental RFC. = There are some nits



Major issues:



Minor issues:



Nits/editorial comments:

1.      In the abstract the document starts = with LoST,  Please expand to Location-to-Service Translation

2.      At the end of section 3.2  in the = note, I think that the first "getServiceListBoundary" should = be " getServiceBoundary"







Roni Even

------_=_NextPart_002_01CB9DC4.CA42FA4D-- ------_=_NextPart_001_01CB9DC4.CA42FA4D Content-Type: text/plain; name="ATT00001.txt" Content-Transfer-Encoding: base64 Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklldGYgbWFp bGluZyBsaXN0DQpJZXRmQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lldGYNCg== ------_=_NextPart_001_01CB9DC4.CA42FA4D-- From daniel@haxx.se Fri Dec 17 06:12:27 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F413C3A6B47 for ; Fri, 17 Dec 2010 06:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG+Sl+1Ke4dg for ; Fri, 17 Dec 2010 06:12:25 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 5C6AD3A6B3D for ; Fri, 17 Dec 2010 06:12:24 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id oBHEEA16011922; Fri, 17 Dec 2010 15:14:10 +0100 Date: Fri, 17 Dec 2010 15:14:10 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mykyta Yevstifeyev Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC In-Reply-To: <4D0B6B6D.7040001@gmail.com> Message-ID: References: <20101213132808.2379.30041.idtracker@localhost> <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> <4D0B6B6D.7040001@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Fri, 17 Dec 2010 15:14:10 +0100 (CET) X-Mailman-Approved-At: Fri, 17 Dec 2010 14:56:42 -0800 Cc: SM , ietf@ietf.org, httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 14:12:27 -0000 On Fri, 17 Dec 2010, Mykyta Yevstifeyev wrote: >> What do packets have to do with HTTP headers? > What do you mean? Packets have nothing to do with headers, there is nothing > about this in paragraph above. Maybe you meant middle-boxes? Read through your -09 spec again. You speak of "HTTP packets" in several places, where they should rather be "HTTP request" or "HTTP responses" etc. I also find the use of 'host' very confusing in the document as it is clearly used instead of the more proper 'client' or 'server' in some places. The second paragraph in section 2.1 combines both these mistakes and make a blob of text that I cannot understand: When HTTP host receives HTTP packet with Headers-Not-Recognized header, it is RECOMMENDED that it avoids sending packets with headers with mentioned in it names or tries to change them so that it is able to recognize and process them. Does this say that if a client learns about headers that the server doesn't support, it shouldn't send them in subsequent requests? -- / daniel.haxx.se From daniel@haxx.se Fri Dec 17 07:02:03 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD193A6B59 for ; Fri, 17 Dec 2010 07:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hze239gL7WXY for ; Fri, 17 Dec 2010 07:02:02 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 6B40D3A6B4D for ; Fri, 17 Dec 2010 07:02:02 -0800 (PST) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id oBHF3nDM010010; Fri, 17 Dec 2010 16:03:49 +0100 Date: Fri, 17 Dec 2010 16:03:49 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mykyta Yevstifeyev Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC In-Reply-To: <4D0B71AA.5060305@gmail.com> Message-ID: References: <20101213132808.2379.30041.idtracker@localhost> <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> <4D0B6B6D.7040001@gmail.com> <4D0B71AA.5060305@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Fri, 17 Dec 2010 16:03:49 +0100 (CET) X-Mailman-Approved-At: Fri, 17 Dec 2010 14:56:42 -0800 Cc: SM , ietf@ietf.org, httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 15:02:03 -0000 On Fri, 17 Dec 2010, Mykyta Yevstifeyev wrote: > However this paragraph needs improvement, and I'll do that in the next > version of the draft, which will bw available at the end of Last Call. It might be a good idea to just post your updated versions of the paragraphs discussed here so that we can iterate over them faster and without you having to issue new drafts all the time... -- / daniel.haxx.se From fluffy@cisco.com Fri Dec 17 15:42:58 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9840E3A69D2 for ; Fri, 17 Dec 2010 15:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.563 X-Spam-Level: X-Spam-Status: No, score=-110.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+n4mJU4JM8l for ; Fri, 17 Dec 2010 15:42:57 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CD68B3A6915 for ; Fri, 17 Dec 2010 15:42:57 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI6EC02rR7Ht/2dsb2JhbACkM3Ojaps1hUoEhGWGHIMX X-IronPort-AV: E=Sophos;i="4.60,190,1291593600"; d="scan'208";a="637772867" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 17 Dec 2010 23:44:45 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBHNiglx019419; Fri, 17 Dec 2010 23:44:42 GMT Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <20101213132808.2379.30041.idtracker@localhost> Date: Fri, 17 Dec 2010 16:45:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101213132808.2379.30041.idtracker@localhost> To: The IETF X-Mailer: Apple Mail (2.1082) Cc: httpbis Group X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 23:42:58 -0000 I'm pretty surprised to see this in IETF LC - its not at the level where = it is ready to have a WG start working on the idea.=20 It's unclear what this draft is for, who wants it, or how it would work. = Consider a HTTP request going to something like GAE. First some front = end web gets the message, call this server A, it probably forwards on to = separate web server running the python system, call this B, this pass on = to a framework like say django, call this C, which passes on to end = application call this D. It's really unclear what software is = responsible for knowing which header each of A, B, C, and D supports or = how the proposed header would get filled out in the response. It gets = even more unclear as you start adding in caches, TLS accelerators, and = such. It's not clear to me what the client would be able to do even if = it had this information.=20 I don't think this should be published until it has actually been = discussed in the appropriate WG.=20 On Dec 13, 2010, at 6:28 AM, The IESG wrote: >=20 > The IESG has received a request from an individual submitter to = consider > the following document: > - ''Headers-Not-Recognized' HTTP Header Field' > as an > Experimental RFC >=20 > 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-01-14. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > = http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recogni= zed/ >=20 > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recogni= zed/ >=20 >=20 > 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 From hartmans@mit.edu Fri Dec 17 19:44:22 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074C63A6A25; Fri, 17 Dec 2010 19:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.819 X-Spam-Level: X-Spam-Status: No, score=-102.819 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je7mDA3J24w6; Fri, 17 Dec 2010 19:44:21 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 571933A699C; Fri, 17 Dec 2010 19:44:20 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4A37A2013D; Fri, 17 Dec 2010 22:45:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 49D1F4060; Fri, 17 Dec 2010 22:45:54 -0500 (EST) From: Sam Hartman To: Erik Nordmark Subject: Re: Secdir review of draft-ietf-isis-trill References: <4D0BDDC0.6060201@acm.org> Date: Fri, 17 Dec 2010 22:45:54 -0500 In-Reply-To: <4D0BDDC0.6060201@acm.org> (Erik Nordmark's message of "Fri, 17 Dec 2010 14:01:36 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-isis-trill@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 03:44:22 -0000 >>>>> "Erik" == Erik Nordmark writes: Erik> Adding just this sentence to draft-ietf-isis-trill (the code Erik> point document) seems odd. Your comment is really a comment on Erik> the security of IS-IS, and not specific to TRILL and unrelated Erik> to the code points. I don't care much where the text goes. I'm happy if you provide an rfc editor note for draft-ietf-trill-rbridge-protocol if you like that approach better. However, as I read draft-ietf-isis-trill, it defines the interface between TRILL and IS-IS. In my mind, that's where the security consideration appears. You're re-using a component that isn't up to our current standards--we know that; we're working on it in KARP. However in doing that, you need to document the security considerations for your protocol. Since you have a document that specifically is the interface between your protocol and the component you are re-using,that seems like the best place to do the documentation work. however, in decreasing order of priority, I want to call out my concern that we need to be far more careful about what we expect in terms of security from future work we charter and that we should document the specific interactions between IS-IS and TRILL. While I have expressed an opinion above on where I think that documentation should go, feel free to put it where you think is most correct. From sm@resistor.net Sat Dec 18 13:57:39 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C164B3A6BF8 for ; Sat, 18 Dec 2010 13:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+RhUMnGov1R for ; Sat, 18 Dec 2010 13:57:38 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 58F903A6BF6 for ; Sat, 18 Dec 2010 13:57:38 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oBILwRvs027428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Dec 2010 13:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1292709563; x=1292795963; bh=anJPiIloaqs42vFQ7Fic1FOds8XfF8+84IjLkT1WIu4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=B8fYQwtxmbCyXjl8dyOrIUu55+k2Cd+9LDydvOf/D7H4Q9jApYJoeyMEBVP7u99tI ta4sniVfvVkT9RdqBC9cFJH+DetEV/GQIvpypUldZBR225EHVS89HA/n0UptCiz9Eg E3aAGveiy20MmrJr/dZJHFxXNFbPkdXXNE+aCh4Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1292709563; x=1292795963; bh=anJPiIloaqs42vFQ7Fic1FOds8XfF8+84IjLkT1WIu4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=NLqt2gZVffR+O3GXIA+cK5DsR+c2XFZ1hnq47F0sjgntV+fbf2y2WZme3l5qPu4Qw f/6nx+4fCiCETVQulwH0TTnb5S5S8V1n4CeR2KCSuNWp299ho8X8mYqw68ccVPbsFt dZ8MSsheBIgWaEkNuGGkGSX5teLzERkWUw6fiNJ4= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=KAkKPYGcUGYJl9pgi105JDhG6xD45GUDg1nt8fgD61hbTwOGYV+MCqkQ632PMO4+h YFaMRj6SuFWTugifNYjvanjFwhX0CXNuVAtVCPl7bjBbjBEf8tP5GLgwZw8AWvL8R3x dVa6m+BSdB924kFLUUhF/ntN0KDhZi8xP5XGbKc= Message-Id: <6.2.5.6.2.20101218074702.09f0fa80@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 Dec 2010 13:51:44 -0800 To: Mykyta Yevstifeyev From: SM Subject: Re: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC In-Reply-To: <4D0B6B6D.7040001@gmail.com> References: <20101213132808.2379.30041.idtracker@localhost> <6.2.5.6.2.20101217021213.0c3125b0@resistor.net> <4D0B6B6D.7040001@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 21:57:39 -0000 Hi Mykyta, At 05:53 17-12-10, Mykyta Yevstifeyev wrote: >I find 'processed' more acceptable for this case. However to mind it >would be better to mention 'not supported' You could use "not supported" if you find that better. >What do you mean? Packets have nothing to do with headers, there is >nothing about this in paragraph above. Maybe you meant middle-boxes? Daniel Stenberg already commented on this [1]. The term "middle-boxes", as used in the document, lumps everything in the middle together even if the "hosts" operate at different layers. As the proposal uses a "MUST" in the third paragraph of Section 2.1, the compliance is dependent upon "hosts" which are generally not part of HTTP infrastructure. >I'll let you know as soon new version of the draft will be available >(maybe that will be at the end of Last Call). You can ask the sponsoring Area Director if you need guidance. It is assumed that you will have done some research first before asking for help. That includes learning how the IETF process works. If people argue for a change, that doesn't mean that the author of a draft must make the change. The author should keep in mind that the strong discontent in such a case can hamper the publication of the draft. It is also good to take into account whether you want the draft published as a RFC or whether you would like widespread implementation of the proposal. The latter requires that you convince implementors about the merits of the proposal. Obviously, they would not be convinced if their comments are ignored. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg64887.html From d3e3e3@gmail.com Sun Dec 19 10:15:18 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EAB93A6870; Sun, 19 Dec 2010 10:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.154 X-Spam-Level: X-Spam-Status: No, score=-103.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6gy5eUz5IDD; Sun, 19 Dec 2010 10:15:17 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3F8C73A6866; Sun, 19 Dec 2010 10:15:16 -0800 (PST) Received: by wyf23 with SMTP id 23so2182647wyf.31 for ; Sun, 19 Dec 2010 10:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=0DxuJl7/2JjuG+i4bXEM5ULhXwpvvAK+f3LdomLTADU=; b=bB8JNYlUA0ivFTVggVYQii3LTVzVQ9Ptvbe4mBricrT9xyfFR6LPdFbBsg3E6caXZs BrhH8B9UP2olQAZ51k+DJnZFbqH9xi4dCXNB/kRyhhK5ORbeDoeqhcnqjuJCvPkxErIP BATfrpLpeCxYUiv86NUk82FVloldmyj2CpnfA= 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=xIyNwRP38vi6KfvlNUkwIu0Ayv9fJf2MiRBcA1BR8x9DOLVoFC/1GS3OA4oMz80WIx O4wK6uLutBTNn93jKyDduHGPhjne5skLLs8Ahj4FcVrGne1LYToHy13VrdY15SglF3Pf K+CQI4t+GvUwjB54EbhB1oU8lP+o0+4iVS5VI= Received: by 10.227.134.82 with SMTP id i18mr2037827wbt.50.1292782627449; Sun, 19 Dec 2010 10:17:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.196 with HTTP; Sun, 19 Dec 2010 10:16:47 -0800 (PST) In-Reply-To: References: <4D0BDDC0.6060201@acm.org> From: Donald Eastlake Date: Sun, 19 Dec 2010 13:16:47 -0500 Message-ID: Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org, secdir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 18:15:18 -0000 My apologies for responding slowly, I was traveling. If it is tolerable to people, I do not mind adding the two sentences requested by Sam to the isis-trill draft. Thanks, Donald PS: It appears to me that the same considerations apply to draft-ietf-isis-ieee-aq. On Fri, Dec 17, 2010 at 10:45 PM, Sam Hartman wrote= : >>>>>> "Erik" =3D=3D Erik Nordmark writes: > > > =A0 =A0Erik> Adding just this sentence to draft-ietf-isis-trill (the code > =A0 =A0Erik> point document) seems odd. Your comment is really a comment = on > =A0 =A0Erik> the security of IS-IS, and not specific to TRILL and unrelat= ed > =A0 =A0Erik> to the code points. > > I don't care much where the text goes. =A0I'm happy if you provide an rfc > editor note for draft-ietf-trill-rbridge-protocol if you like that > approach better. =A0However, as I read draft-ietf-isis-trill, it defines > the interface between TRILL and IS-IS. =A0In my mind, that's where the > security consideration appears. =A0You're re-using a component that isn't > up to our current standards--we know that; we're working on it in > KARP. However in doing that, you need to document the security > considerations for your protocol. =A0Since you have a document that > specifically is the interface between your protocol and the component > you are re-using,that seems like the best place to do the documentation > work. > > however, in decreasing order of priority, I want to call out my concern > that we need to be far more careful about what we expect in terms of > security from future work we charter and that we should document the > specific interactions between IS-IS and TRILL. =A0While I have expressed > an opinion above on where I think that documentation should go, feel > free to put it where you think is most correct. From pekkas@netcore.fi Mon Dec 20 05:13:40 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5353A6897; Mon, 20 Dec 2010 05:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpMCs7Bai6xA; Mon, 20 Dec 2010 05:13:38 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 3678D3A6851; Mon, 20 Dec 2010 05:13:37 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id oBKDFKvM026505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 15:15:20 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id oBKDFIDV026501; Mon, 20 Dec 2010 15:15:19 +0200 Date: Mon, 20 Dec 2010 15:15:18 +0200 (EET) From: Pekka Savola To: ietf@ietf.org Subject: Re: Last Call: (Datagram Transport Layer Security version 1.2) to Proposed Standard In-Reply-To: <20101130132359.32419.3777.idtracker@localhost> Message-ID: References: <20101130132359.32419.3777.idtracker@localhost> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.4 at otso.netcore.fi X-Virus-Status: Clean Cc: tls@ietf.org, tls-chairs@tools.ietf.org, draft-ietf-tls-rfc4347-bis@tools.ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 13:13:40 -0000 On Tue, 30 Nov 2010, The IESG wrote: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > - 'Datagram Transport Layer Security version 1.2' > as a Proposed Standard A bit late to the IETF LC, but hopefully these are still useful. This is an ops-dir review of draft-ietf-tls-rfc4347-bis-04 (DTLS 1.2). This looks good, but the text seems a bit unclear on IP fragmentation vs packetization. ICMP notifications passing up to the app is only a 'should' and this begs the question why. IANA considerations practicalities could also be spelled out (not sure how detailed IANA wants these to be). In more detail: If I understand correctly *), initial DTLS exchanges will typically use fragmented UDP packets due certificate sizes etc. The likelyhood of getting fragmented IP packets through firewalls and other devices is significantly lower than getting UDP packets through. The spec would be more robust and the protocol likely more applicable in the face of these 'network effects' if it tried to do packetization itself in such a manner that IP fragmentation would not be necessary. *) S 3.2.3 and 4.1.1 appear to be somewhat contradictory on this. See below. The document does not have a "Changes from DTLS 1.0 (RFC4347)" section that is is mandated or at least strongly recommended for update-specs. The document does not describe how DTLS 1.2 will interwork with DTLS 1.0 (if it will). The TLS 1.2 spec (RFC5246, Appendix E.1) does have some that will apply, but there are likely some DTLS specifics as well. specific comments ----------------- 3.2.3. Message Size TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to <1500 bytes if fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length. 4.1.1. Transport Layer Mapping Each DTLS record MUST fit within a single datagram. In order to avoid fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. ... these seem somewhat contradictory. Maybe I'm missing something. The latter seems to be saying that DTLS implementations should try to avoid IP fragmentation, but the former seems to imply that it's de-facto mode of operation. If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in DCCP Section 14), then DTLS record layer should inform the upper layer protocol of the error. .. is this too weak? I've have thought that it would be natural that if DTSLS record layer gets this notification (which, in the case of ICMP and omitting information, is not necessarily given), it MUST pass this information up. Note that the refusal to send could also apply to UDP if packet is bigger than PMTU and DF bit is set or IPv6 is used. What is the alternative if it doesn't? It would be fine if the alternative is that the DTLS record layer react to that information itself, but completely ignoring e.g. ICMP packet too big would lead to communication failure. 7. IANA Considerations This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS. ... this may be inadequate. I was unable to find from the registry (tls-parameters) which of these parameters this applies to. All of them? (This was triggered by S 4.1.2.5, so at least new Cipher Suites must indicate this.) If I understand what you mean, 1) you should actually be asking IANA to reformat the registry so that there is an additional column in all the tables "DTLS-OK?" or some such, and possibly 2) modifying TLS 1.2 spec IANA registration guidelines (i.e. what should the IANA requesters know about when they're making their request), and also possibly 3) asking IANA to ask future registrants about DTLS-OK feature if the requestor fails to do so on their own. editorial --------- ... For the completeness, when referring to PMTU discovery, in addition to RFC1191 one should probably also refer to RFC1981 (the IPv6 version). [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress, October 2003. ... this should probably be rfc5406? [IKEv2] C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. ... remove the latter 'reference' (edit glitch?) From fweimer@bfk.de Mon Dec 20 06:48:12 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B5F3A68B5; Mon, 20 Dec 2010 06:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKdK1GCaQWqn; Mon, 20 Dec 2010 06:48:11 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 88F9E3A6897; Mon, 20 Dec 2010 06:48:10 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PUh3o-0002Et-8l; Mon, 20 Dec 2010 14:50:00 +0000 Received: by bfk.de with local id 1PUh3o-0003LK-45; Mon, 20 Dec 2010 14:50:00 +0000 To: Pekka Savola Subject: Re: Last Call: (Datagram Transport Layer Security version 1.2) to Proposed Standard References: <20101130132359.32419.3777.idtracker@localhost> From: Florian Weimer Date: Mon, 20 Dec 2010 14:50:00 +0000 In-Reply-To: (Pekka Savola's message of "Mon\, 20 Dec 2010 15\:15\:18 +0200 \(EET\)") Message-ID: <8262uo5wiv.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-tls-rfc4347-bis@tools.ietf.org, ietf@ietf.org, tls-chairs@tools.ietf.org, tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 14:48:12 -0000 * Pekka Savola: > If there is a transport protocol indication (either via ICMP or via a > refusal to send the datagram as in DCCP Section 14), then DTLS record > layer should inform the upper layer protocol of the error. > > .. is this too weak? I've have thought that it would be natural that if > DTSLS record layer gets this notification (which, in the case of ICMP and > omitting information, is not necessarily given), it MUST pass this > information up. Note that the refusal to send could also apply to UDP > if packet is bigger than PMTU and DF bit is set or IPv6 is used. > What is the alternative if it doesn't? It would be fine if > the alternative is that the DTLS record layer react to that information > itself, but completely ignoring e.g. ICMP packet too big would lead to > communication failure. ICMP packet too big is typically handled by the stack, not the application. The stack updates the stored path MTU, the application tries again, and this time, the stack produces smaller fragments. AFAIUI, requiring ICMP processing in applications prescribes an implementation model based on connected UDP sockets (in the terminology of the BSD sockets API). This is not always desirable or possible. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From radiaperlman@gmail.com Sun Dec 19 11:55:47 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80D03A68BC; Sun, 19 Dec 2010 11:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5k3rvbgX8KR; Sun, 19 Dec 2010 11:55:46 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BC1293A68BB; Sun, 19 Dec 2010 11:55:46 -0800 (PST) Received: by iwn40 with SMTP id 40so2694092iwn.31 for ; Sun, 19 Dec 2010 11:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+ZEGy+OgJCGKXblBvElHIhNYeABHXgHyQKtzAcSN/wY=; b=v6stuT8Ly3jMpBT2FMiF7kbmRKuaPPvxYZh9Nk/WODM6k3wYwWF2nQ+V0bRADcwtlY nNpJXvkXdcfA34cCyE3aGk7hjOg87YX25ncHlZOSl6kSWZttjPg5x5+OZFz+HeTc80I9 jTG/NbXonfvLnAkTLy4THOGc3gs0EWQfz3ed4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fByNJUOWRewKtgwFPFrORnNvtFI25kC1z/7tJK3FdYn4+RuykrL7U+oR+tBguPayPa c1e4Ld0WgYdyRUe1XHTHj2cAkil/N2puOnQ61V+wpUJ5AoRXP2j8ucB+6RnkwIJa7iuI XdPiyDdnsSPre6/XmgmzPRJApM2IvHjDqU+s0= MIME-Version: 1.0 Received: by 10.42.175.70 with SMTP id az6mr3284518icb.428.1292788658545; Sun, 19 Dec 2010 11:57:38 -0800 (PST) Received: by 10.42.220.199 with HTTP; Sun, 19 Dec 2010 11:57:38 -0800 (PST) In-Reply-To: References: <4D0BDDC0.6060201@acm.org> Date: Sun, 19 Dec 2010 11:57:38 -0800 Message-ID: Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill From: Radia Perlman To: Donald Eastlake Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 20 Dec 2010 08:28:18 -0800 Cc: Erik Nordmark , secdir@ietf.org, Sam Hartman , draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 19:55:47 -0000 No objections. Radia On Sun, Dec 19, 2010 at 10:16 AM, Donald Eastlake wrote: > My apologies for responding slowly, I was traveling. > > If it is tolerable to people, I do not mind adding the two sentences > requested by Sam to the isis-trill draft. > > Thanks, > Donald > > PS: It appears to me that the same considerations apply to > draft-ietf-isis-ieee-aq. > > On Fri, Dec 17, 2010 at 10:45 PM, Sam Hartman wro= te: >>>>>>> "Erik" =3D=3D Erik Nordmark writes: >> >> >> =A0 =A0Erik> Adding just this sentence to draft-ietf-isis-trill (the cod= e >> =A0 =A0Erik> point document) seems odd. Your comment is really a comment= on >> =A0 =A0Erik> the security of IS-IS, and not specific to TRILL and unrela= ted >> =A0 =A0Erik> to the code points. >> >> I don't care much where the text goes. =A0I'm happy if you provide an rf= c >> editor note for draft-ietf-trill-rbridge-protocol if you like that >> approach better. =A0However, as I read draft-ietf-isis-trill, it defines >> the interface between TRILL and IS-IS. =A0In my mind, that's where the >> security consideration appears. =A0You're re-using a component that isn'= t >> up to our current standards--we know that; we're working on it in >> KARP. However in doing that, you need to document the security >> considerations for your protocol. =A0Since you have a document that >> specifically is the interface between your protocol and the component >> you are re-using,that seems like the best place to do the documentation >> work. >> >> however, in decreasing order of priority, I want to call out my concern >> that we need to be far more careful about what we expect in terms of >> security from future work we charter and that we should document the >> specific interactions between IS-IS and TRILL. =A0While I have expressed >> an opinion above on where I think that documentation should go, feel >> free to put it where you think is most correct. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From hartmans@mit.edu Mon Dec 20 08:41:03 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5393A6A63; Mon, 20 Dec 2010 08:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.792 X-Spam-Level: X-Spam-Status: No, score=-102.792 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhuiRXVwF0tn; Mon, 20 Dec 2010 08:41:02 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C2ACC3A6808; Mon, 20 Dec 2010 08:41:02 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3C4CC20239; Mon, 20 Dec 2010 11:41:43 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C219B4060; Mon, 20 Dec 2010 11:42:32 -0500 (EST) From: Sam Hartman To: Radia Perlman Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill References: <4D0BDDC0.6060201@acm.org> Date: Mon, 20 Dec 2010 11:42:32 -0500 In-Reply-To: (Radia Perlman's message of "Sun, 19 Dec 2010 11:57:38 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf@ietf.org, secdir@ietf.org, Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, Sam Hartman X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 16:41:03 -0000 >>>>> "Radia" == Radia Perlman writes: Radia> No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. From ron.even.tlv@gmail.com Mon Dec 20 10:15:18 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AAB13A6A07; Mon, 20 Dec 2010 10:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=1.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGJevEXM-CKF; Mon, 20 Dec 2010 10:15:12 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1661C3A685C; Mon, 20 Dec 2010 10:15:11 -0800 (PST) Received: by wyf23 with SMTP id 23so3120607wyf.31 for ; Mon, 20 Dec 2010 10:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=88gZCnQwxb+ZeSxu3EEP6abUCzUvdOgv/rR4j/8Akjs=; b=gpOaxwMmdFJ+7yC7ztV86Tpe9Rvok5THWHoyQ3KlOlf3CmePr5MoPkpwvcWz6YPvu+ Dw7X3EmwOgOoWxnuSnC6Ep4qU2ZPxXhsjE4mB3+i4Gw4c6LLRvP5Xf16lNLda1BeTQLj WR30NwSr6H/qR7QoZn3Zi4YVO1p/fIKbEODUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; b=MZHhPy0RjOcoF5pZ2chhsc1Qy/uIoXYaUVUWKApkP6VqoAHFqqmTWPUeKcjcjGuxph RhbGoRbkSMBYhu7H7vX5FGZss5La1i02xp4ByAkidtsuwjvkZLbP4oSn9B9luWaavwp5 5WcEACB9VLHiPlTJFtVzhCuGvAWJrfkWEJ4PU= Received: by 10.227.72.203 with SMTP id n11mr2817966wbj.93.1292869025691; Mon, 20 Dec 2010 10:17:05 -0800 (PST) Received: from windows8d787f9 (bzq-79-181-13-182.red.bezeqint.net [79.181.13.182]) by mx.google.com with ESMTPS id f35sm2916912wbf.14.2010.12.20.10.17.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Dec 2010 10:17:04 -0800 (PST) From: "Roni Even" To: , Subject: Gen-ART LC review of draft-ietf-roll-routing-metrics-14 Date: Mon, 20 Dec 2010 20:14:07 +0200 Message-ID: <4d0f9da0.2308e30a.48c5.ffffae42@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0139_01CBA082.774DA140" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acugcau90kzrJPsqQ7uRnf3VV7ambw== Content-Language: en-us Cc: 'IETF-Discussion list' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 18:15:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0139_01CBA082.774DA140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-roll-routing-metrics-14 Reviewer: Roni Even Review Date:2010-12-20 IETF LC End Date: 2011-1-5 IESG Telechat date: Summary: This draft is almost ready for publication as an Standard track RFC. Major issues: No Major issues Minor issues: 1. In section 2.1 after figure 1 you specify the different fields. Please specify the size in bits of the flags field the A-field and the prec field. 2. In section 2.1 in example 1 how is it known that all nodes MUST be main powered. Do you need to provide a value to prec field? 3. In section 3.1 and throughout the document when you define the different object you have "recommended value=xx". I think that since this draft defines the table and create the initial table in the IANA consideration section these are the actual values. So maybe say that these are the actual values as specified in section 6 (6.1) 4. In section 3.1 the flag field - how many bits, specify. 5. In section 3.2 figure 4 shows a flag field, how many bits, what is the value. 6. In section 6 according to rfc5226 "IETF consensus" is now "IETF review". 7. In section 6.1 you should say that the table has the initial values and add which numbers are available for allocation. 8. In section 6.2 what values are available for allocation. Also say that currently the table is empty. 9. In section 6.2 is there a reason to create an empty table. Why not do it when there is a request to define a TLV 10.In section 6.3, are there more values allowed, can they be allocated. If not why have it managed by IANA. 11.After the table in section in section 6.3 there is a request to create another table. Maybe it should be in a separate section. 12.In section 6.3 "New bit numbers may be allocated", how many bits are available. 13.The same paragraph in section 6.3 also talks about the registration policy, is it different from the one that is common in section 6, why specify it again. Also look at comment 6 14.Comment 12 and 13 are also true for section 6.4 and 6.5. Nits/editorial comments: 1. In section first paragraph "object" should be "object" 2. In section 4.3.2 first paragraph "wich" should be "which" ------=_NextPart_000_0139_01CBA082.774DA140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am = the assigned Gen-ART reviewer for this draft. For background on Gen-ART, = please see the FAQ at <http://w= iki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 

Please resolve these comments along with any other = Last Call comments you may receive.

 

Document: = draft-ietf-roll-routing-metrics-14

Reviewer: Roni Even

Review Date:2010–12–20

IETF LC End Date: = 2011–1–5

IESG Telechat = date:

 

Summary: This draft is almost ready for publication = as an Standard track RFC.

 

Major = issues:

No Major = issues

 

Minor issues:

 

1.  = In section 2.1 after = figure 1 you specify the different fields. Please specify the size in = bits of the flags field the A-field and the prec field.

2.  = In section 2.1 in example = 1 how is it known that all nodes MUST be main powered. Do you need to = provide a value to prec field?

3.  = In section 3.1 and = throughout the document when you define the different object you have = “recommended value=3Dxx”. I think that since this draft = defines the table and create the initial table in the IANA consideration = section these are the actual values. So maybe say that these are the = actual values as specified in section 6 (6.1)

4.  = In section 3.1 the flag = field – how many bits, specify.

5.  = In section 3.2 figure 4 = shows a flag field, how many bits, what is the value.

6.  = In section 6 according to = rfc5226 “IETF consensus” is now “IETF = review”.

7.  = In section 6.1 you should = say that the table has the initial values and add which numbers are = available for allocation.

8.  = In section 6.2 what = values are available for allocation.  Also say that currently the = table is empty.

9.  = In section 6.2 is there a = reason to create an empty table. Why not do it when there is a request = to define a TLV

10.In = section 6.3, are there more values allowed, can they be allocated. If = not why have it managed by IANA.

11.After the table in section in section 6.3 there is a = request to create another table. Maybe it should be in a separate = section.

12.In = section 6.3 “New bit numbers may be allocated”, how many = bits are available.

13.The = same paragraph in section 6.3 also talks about the registration policy, = is it different from the one that is common in section 6, why specify it = again. Also look at comment 6

14.Comment 12 and 13 are also true for section 6.4 and = 6.5.

 

 

 

Nits/editorial comments:

 

1.  = In section first = paragraph “object” should be = “object”

2.  = In section 4.3.2 first = paragraph “wich” should be = “which”

 

 

------=_NextPart_000_0139_01CBA082.774DA140-- From d3e3e3@gmail.com Mon Dec 20 10:41:31 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14333A69B2; Mon, 20 Dec 2010 10:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.175 X-Spam-Level: X-Spam-Status: No, score=-103.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zs0+CgOe9iL; Mon, 20 Dec 2010 10:41:31 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8D2983A6866; Mon, 20 Dec 2010 10:41:30 -0800 (PST) Received: by wyf23 with SMTP id 23so3149111wyf.31 for ; Mon, 20 Dec 2010 10:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=YDpZMdDPYeB74CedfD5uWe6qtrlgeCd0QrW6oQnHFE8=; b=jCIoEIAzW/R86DYQZXTzNvctGdwPPq03SW2l6d+hvtNSm65A/XDGircKWExpefkYPS EO3ykgkvqbq45xMPQ6B8mkgihkU0ZjY1PON4ewrqKVnf16xH7fLNaqfVLr5KButgIcfK ji4i8HjshxIAHueyGTWCFh4y3YJhUVUlKbXuU= 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=vvahxom6GKCw6nqAi1RQ/Js9xYBjibNA5qA1eAzUbNeV0pehrijitZMzegPxh1ndQ4 ctEP0zB4EfR0STtgEFm/kS6DDhyUbl9eN4WAEqQmtff/PJasYwn0CUNwSyIwkHcwNftt 58tKClrTc74TlhCx5j4Ga9uTmQ6uxyzGflF3E= Received: by 10.227.183.71 with SMTP id cf7mr2877594wbb.195.1292870604020; Mon, 20 Dec 2010 10:43:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.196 with HTTP; Mon, 20 Dec 2010 10:43:03 -0800 (PST) In-Reply-To: References: <4D0BDDC0.6060201@acm.org> From: Donald Eastlake Date: Mon, 20 Dec 2010 13:43:03 -0500 Message-ID: Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , secdir@ietf.org, draft-ietf-isis-trill@tools.ietf.org, Radia Perlman , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 18:41:31 -0000 Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman wrote= : >>>>>> "Radia" =3D=3D Radia Perlman writes: > > =A0 =A0Radia> No objections. =A0Radia > > > Can I get someone to confirm that the text in the proposed sentences is > substantially true? > I think so but I'm not an IS-IS expert. LSPs have sequences number, etc., and are idempotent. I think only Hellos have the potential replay Denial of Service problem. So I would suggest changing to: "Even when the IS-IS authentication is used, replays of Hello packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." Thanks, Donald From hartmans@mit.edu Mon Dec 20 10:49:10 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8A73A6A95; Mon, 20 Dec 2010 10:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJGZhOJt19Lc; Mon, 20 Dec 2010 10:49:09 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4DAAF3A687A; Mon, 20 Dec 2010 10:49:08 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5887420239; Mon, 20 Dec 2010 13:49:51 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F1C254060; Mon, 20 Dec 2010 13:50:38 -0500 (EST) From: Sam Hartman To: Donald Eastlake Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill References: <4D0BDDC0.6060201@acm.org> Date: Mon, 20 Dec 2010 13:50:38 -0500 In-Reply-To: (Donald Eastlake's message of "Mon, 20 Dec 2010 13:43:03 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: ietf@ietf.org, secdir@ietf.org, Radia Perlman , Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, Sam Hartman X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 18:49:10 -0000 >>>>> "Donald" == Donald Eastlake writes: Donald> Hi, Donald> On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman wrote: >>>>>>> "Radia" == Radia Perlman writes: >> >>    Radia> No objections.  Radia >> >> >> Can I get someone to confirm that the text in the proposed >> sentences is substantially true? I think so but I'm not an IS-IS >> expert. Donald> LSPs have sequences number, etc., and are idempotent. I Donald> think only Hellos have the potential replay Denial of Donald> Service problem. So I would suggest changing to: Donald> "Even when the IS-IS authentication is used, replays of Donald> Hello packets can create denial-of-service conditaions; see Donald> RFC 6039 for details. These issues are similar in scope to Donald> those discussed in section 6.2 of Donald> draft-ietf-trill-rbridge-protocol, and the same mitigations Donald> may apply." Based on my understanding your correction is accurate; thanks. From stbryant@cisco.com Mon Dec 20 11:03:13 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588E13A6A61; Mon, 20 Dec 2010 11:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfgYH18Qd3Ua; Mon, 20 Dec 2010 11:03:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 398283A6A63; Mon, 20 Dec 2010 11:03:11 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG83D01AZnwM/2dsb2JhbACkF3OjWoJMDgGYWIVJBIsBhgw X-IronPort-AV: E=Sophos;i="4.60,203,1291593600"; d="scan'208";a="195249130" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Dec 2010 19:05:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBKJ54Qt001607; Mon, 20 Dec 2010 19:05:04 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oBKJ51806392; Mon, 20 Dec 2010 19:05:02 GMT Message-ID: <4D0FA8DD.2040704@cisco.com> Date: Mon, 20 Dec 2010 19:05:01 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Donald Eastlake Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill References: <4D0BDDC0.6060201@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, secdir@ietf.org, Radia Perlman , Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, Sam Hartman X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 19:03:13 -0000 On 20/12/2010 18:43, Donald Eastlake wrote: > Hi, > > On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman wrote: >>>>>>> "Radia" == Radia Perlman writes: >> Radia> No objections. Radia >> >> >> Can I get someone to confirm that the text in the proposed sentences is >> substantially true? >> I think so but I'm not an IS-IS expert. > LSPs have sequences number, etc., and are idempotent. I think only > Hellos have the potential replay Denial of Service problem. So I would > suggest changing to: > > "Even when the IS-IS > authentication is used, replays of Hello packets can create > denial-of-service conditaions; see RFC 6039 for details. These issues > are similar in scope to those discussed in section 6.2 of > draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." > > Thanks, > Donald ... as I recall from discussions with the ISIS WG the changes that were made to ISIS for TRILL make it more vulnerable to a hello attack than vanilla ISIS. This I understand is because there is more work to be done in processing a TRILL hello. Is that correct? - Stewart From d3e3e3@gmail.com Mon Dec 20 13:57:15 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F9F3A6B04; Mon, 20 Dec 2010 13:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-wK8qOn+0tN; Mon, 20 Dec 2010 13:57:14 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2E3FE3A68F9; Mon, 20 Dec 2010 13:57:14 -0800 (PST) Received: by wwa36 with SMTP id 36so3352786wwa.13 for ; Mon, 20 Dec 2010 13:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Wn0JvXue1UlMetIM2Y/7Ypthqsgg+6aqQ3xMoouhAB4=; b=nva6qpSOkBh+ACc8JpR7JUUX+HCzikgGtxzHQrN9EBZw0OghfgufmFksjcMHpF1Ln+ jlJ8XLzY0i9LecCm1vMYszudxvD5Mo3Xp9/exSQKlwHnLdjjrfrBWzcc9iEigMVPeGKV 5+ctfL/+2HjtNYtRBOKz3SqdYmcBBI+oi/IeY= 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=LsKzz4nxl47bsXTflBkYNGCHotpnZ/17JtCsEoITTaxWa2mEbJYv/xoQXrebnxQhGt CqTNuatMa9thXYgtDgPvVdKa7VArJ1ccPbBFKCusxQkjNii0/wuGsmX7a5TWwAV81U3D nkdF2ZunrgZRYc46nSMwOTICE0u5mXch0yCk8= Received: by 10.227.59.208 with SMTP id m16mr2883466wbh.224.1292882347982; Mon, 20 Dec 2010 13:59:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.196 with HTTP; Mon, 20 Dec 2010 13:58:47 -0800 (PST) In-Reply-To: <4D0FA8DD.2040704@cisco.com> References: <4D0BDDC0.6060201@acm.org> <4D0FA8DD.2040704@cisco.com> From: Donald Eastlake Date: Mon, 20 Dec 2010 16:58:47 -0500 Message-ID: Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill To: stbryant@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, secdir@ietf.org, Radia Perlman , Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, Sam Hartman X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 21:57:15 -0000 Hi, On Mon, Dec 20, 2010 at 2:05 PM, Stewart Bryant wrote: > On 20/12/2010 18:43, Donald Eastlake wrote: >> >> Hi, >> >> On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman >> =A0wrote: >>>>>>>> "Radia" =3D=3D Radia Perlman =A0writes: >>> >>> =A0 =A0Radia> =A0No objections. =A0Radia >>> >>> Can I get someone to confirm that the text in the proposed sentences is >>> substantially true? >>> I think so but I'm not an IS-IS expert. >> >> LSPs have sequences number, etc., and are idempotent. I think only >> Hellos have the potential replay Denial of Service problem. So I would >> suggest changing to: >> >> "Even when the IS-IS >> authentication is used, replays of Hello packets can create >> denial-of-service conditaions; see RFC 6039 for details. These issues >> are similar in scope to those discussed in section 6.2 of >> draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." >> >> Thanks, >> Donald > > ... as I recall from discussions with the ISIS WG the changes that were m= ade > to ISIS for TRILL make it more vulnerable to a hello attack than vanilla > ISIS. This I understand is because there is more work to be done in > processing a TRILL hello. Is that correct? I think we are talking about Denial of Service due to replay of old Hellos screwing up the state. This is unrelated to the work required to process a Hello. It is true that some processing is required for IS-IS LAN Hellos. One reason for having a protocol like BFD is that you can send BFD messages more frequently because they take less processing than Hellos. But I don't see why there would be that much difference between the work involved in processing a TRILL LAN Hello and a Layer 3 IS-IS LAN Hello. > - Stewart Thanks, Donald From julian.reschke@gmx.de Tue Dec 21 08:41:41 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B393A6A35 for ; Tue, 21 Dec 2010 08:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.669 X-Spam-Level: X-Spam-Status: No, score=-104.669 tagged_above=-999 required=5 tests=[AWL=-2.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK7Fv-b9aEmJ for ; Tue, 21 Dec 2010 08:41:40 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 20CBE3A67E3 for ; Tue, 21 Dec 2010 08:41:39 -0800 (PST) Received: (qmail invoked by alias); 21 Dec 2010 16:43:33 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp062) with SMTP; 21 Dec 2010 17:43:33 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19R5o9lWKZREqrT74xVB0dOWimriiY66cuRR7ymuG FqKPLGd6z9WEWd Message-ID: <4D10D92A.8000508@gmx.de> Date: Tue, 21 Dec 2010 17:43:22 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Presuhn Subject: Re: Automatically updated Table of Contents with Nroff References: <001b01ca0512$2c6be860$6801a8c0@oemcomputer> <4A5D9DBF.7050605@gmx.de> In-Reply-To: <4A5D9DBF.7050605@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 16:41:41 -0000 On 15.07.2009 11:13, Julian Reschke wrote: > Randy Presuhn wrote: >> ... >> No need to manually edit. >> >> Use the macros or awk / sed to spit the toc into a file which can be >> inserted >> into the correct position by the .so nroff directive. This will result in >> a table of contents in the correct position. There is the possibility >> that if the number of toc pages has changed from one iteration >> to the next that the page numbers will be off by one, but that will >> go away the next time the process runs. >> >> For editing a document, particularly a largish one, the availability of >> .so is for me nroff's biggest advantage over xml2rfc. >> ... > ... Randy, I've been spending some time looking at the feasibility of using NROFF for IDs while retaining features like automatics generation of the TOC in the *right* place. Funny enough, googling for this topic leads me back to this thread (and nowhere else, it seems). So, I do understand how generate the ToC at the end, and I'll probably grok .so, but what is needed to extract the ToC into a separate file? Is there anything in nroff supporting that, or were you just referring to a set of homegrown tools? Also, as far as I can tell, the generated ToC will already be paginated, so do you post-process it again so it can be inserted properly? Best regards, Julian From turners@ieca.com Tue Dec 21 09:12:20 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DE23A6B29 for ; Tue, 21 Dec 2010 09:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zyc+u8l0+XeR for ; Tue, 21 Dec 2010 09:12:19 -0800 (PST) Received: from nm23-vm0.bullet.mail.sp2.yahoo.com (nm23-vm0.bullet.mail.sp2.yahoo.com [98.139.91.224]) by core3.amsl.com (Postfix) with SMTP id 8F85B3A67FA for ; Tue, 21 Dec 2010 09:12:19 -0800 (PST) Received: from [98.139.91.70] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 21 Dec 2010 17:14:13 -0000 Received: from [98.139.91.13] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 21 Dec 2010 17:14:13 -0000 Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 21 Dec 2010 17:14:13 -0000 X-Yahoo-Newman-Id: 750990.55181.bm@omp1013.mail.sp2.yahoo.com Received: (qmail 35459 invoked from network); 21 Dec 2010 17:14:13 -0000 Received: from thunderfish.local (turners@71.191.9.162 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 21 Dec 2010 09:14:12 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: yTQ1ZTYVM1k6ZPMHbssnxSC008fL7O6chq.Cq3Qi1llDwYb tFzGXp6hQTYkJfoOtSwnXAdMH2EGlSGSBSDee.q.DuEQvA_YfvUzJBzX78bM 2x8ey57Lo2dXWBhGV_zLvq_aOVIcG18V29EUI7EpRtwZ_u_8OYWs2rWdh3H. ab0ZTQ5Oka.vrtFeLqiL_4w2qB9USpv75LuW1icZ..r_WcMC44TJVMHAw5Aj eA3sco7NkH07USRxeMR43RnatPJcRG3qnP3YW3biSyYoQAHrJEQyp67jV7Jk q7HXqsgDGjHgbjwfF18QhJeXVoiUihZEHm6S2Sec- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D10E062.7000901@ieca.com> Date: Tue, 21 Dec 2010 12:14:10 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Eddy, Wesley M. \(GRC-MS00\)\[ASRC AEROSPACE CORP\]" Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC References: Your message of Wed, 08 Dec 2010 14:08:03 CST. , <201012082333.oB8NXhhe067090@givry.fdupont.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Hartman , Francis Dupont , "ietf@ietf.org" , "L.Wood@surrey.ac.uk" , "wes@mti-systems.com" , "iesg@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 17:12:20 -0000 Wes, I'm sympathetic to your concern, but I also think we need to specify that this particular use needs to be "in-line" with the protocol (as noted by Sam). How about the following changes in the introduction: OLD: [HASH-Attack] summarizes the use of hashes in many protocols and discusses how attacks against a message digest algorithm's one-way and collision-free properties affect and do not affect Internet protocols. Familiarity with [HASH-Attack] is assumed. NEW: [HASH-Attack] summarizes the use of hashes in many protocols and discusses how attacks against a message digest algorithm's one-way and collision-free properties affect and do not affect Internet protocols. Familiarity with [HASH-Attack] is assumed. One of the uses of message digest algorithms in [HMAC-Attack] was integrity protection. Where the MD5 checksum is used inline with the protocol solely to protect against errors an MD5 checksum is still an acceptable use. Applications and protocols need to clearly state in their security considerations what security services, if any, are expected from the MD5 checksum. In fact, any application and protocol that employs MD5 needs to clearly state the expected security services from their use of MD5. spt On 12/8/10 10:01 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > I think a published update to MD5 security considerations should clearly say what it's still fine to do with MD5, in addition to what it's not safe to do. This would mean adding a couple sentences, and that's about all it would really take to be clear on the issue: > > "Since RFC 1321 was published, MD5 found popular use in checksuming large file transfers. This use of MD5 is still reasonable, as the level of collision resistance is of less importance in this application and MD5 may be significantly more efficient than cryptographically stronger algorithms. Communications, networking, and storage systems prone to errors (e.g. due to faulty hardware, drivers, bit-errors, faulty NAT/ALG algorithms, etc) do not implement the known MD5 collision-finding algorithms, and MD5 remains highly effective at detecting such errors." > > > ________________________________________ > From: Francis.Dupont@fdupont.fr [Francis.Dupont@fdupont.fr] > Sent: Wednesday, December 08, 2010 6:33 PM > To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > Cc: L.Wood@surrey.ac.uk; wes@mti-systems.com; iesg@ietf.org; ietf@ietf.org > Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC > > In your previous mail you wrote: > > The logic doesn't make sense in this position. "Crypto modules > can't use MD5, thus no protocols at all should use MD5." > > => this is a silly/bad/... consequence of the crypto label > attached to the MD5 name. I understand you are not happy with > this but what do you propose? > > Regards > > Francis.Dupont@fdupont.fr > > PS: BTW I'd like to apply the argument only to *new* protocols. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From Francis.Dupont@fdupont.fr Tue Dec 21 09:53:16 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C3B3A6B39 for ; Tue, 21 Dec 2010 09:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ81ocTMI18H for ; Tue, 21 Dec 2010 09:53:15 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 63B4E3A6B23 for ; Tue, 21 Dec 2010 09:53:15 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id oBLHt9Tn017296; Tue, 21 Dec 2010 17:55:09 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201012211755.oBLHt9Tn017296@givry.fdupont.fr> From: Francis Dupont To: Sam Hartman Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC In-reply-to: Your message of Tue, 21 Dec 2010 12:24:40 EST. Date: Tue, 21 Dec 2010 18:55:09 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "ietf@ietf.org" , "L.Wood@surrey.ac.uk" , "wes@mti-systems.com" , "iesg@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 17:53:16 -0000 In your previous mail you wrote: I'm OK with this text. I tried to come up with a way to briefly discuss how error detection is very related to things like protecting against substitution of content (the internet mirror case) but failed to come up with something brief. So, I'm fine with what you have. => can I conclude you are in the "they are security considerations so don't talk about not-security uses" side? Thanks Francis.Dupont@fdupont.fr PS: to summary the issue, we can do 3 things about new not-security uses: - not discourage them as they don't raise any security problems - discourage them as they can raise operational problems because some crypto regulations banish MD5 by itself - write nothing Note the last option solves the issue only for this document, i.e., each time a document will propose a new use of MD5 the issue will be re-opened. From wesley.m.eddy@nasa.gov Tue Dec 21 09:57:31 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE733A6B23; Tue, 21 Dec 2010 09:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.255 X-Spam-Level: X-Spam-Status: No, score=-106.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPQZWS1rqRTW; Tue, 21 Dec 2010 09:57:30 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id BBEE93A6AF1; Tue, 21 Dec 2010 09:57:30 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 0570D1083BA; Tue, 21 Dec 2010 11:59:26 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id oBLHxQRJ021486; Tue, 21 Dec 2010 11:59:26 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 21 Dec 2010 11:59:26 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Sean Turner Date: Tue, 21 Dec 2010 11:59:25 -0600 Subject: RE: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Topic: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC Thread-Index: AcuhMn7eN66GDxF5S6+mVDulA5SnPAABjprw Message-ID: References: Your message of Wed, 08 Dec 2010 14:08:03 CST. ,<201012082333.oB8NXhhe067090@givry.fdupont.fr> <4D10E062.7000901@ieca.com> In-Reply-To: <4D10E062.7000901@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-12-21_07:2010-12-21, 2010-12-21, 1970-01-01 signatures=0 Cc: Sam Hartman , Francis Dupont , "ietf@ietf.org" , "L.Wood@surrey.ac.uk" , "wes@mti-systems.com" , "iesg@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 17:57:31 -0000 That looks good to me. -- Wes Eddy MTI Systems >-----Original Message----- >From: Sean Turner [mailto:turners@ieca.com] >Sent: Tuesday, December 21, 2010 12:14 PM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >Cc: Francis Dupont; wes@mti-systems.com; iesg@ietf.org; >L.Wood@surrey.ac.uk; ietf@ietf.org; Sam Hartman >Subject: Re: Last Call: (Updated >Security Considerations for the MD5 Message-Digest and the HMAC-MD5 >Algorithms) to Informational RFC > >Wes, > >I'm sympathetic to your concern, but I also think we need to specify >that this particular use needs to be "in-line" with the protocol (as >noted by Sam). How about the following changes in the introduction: > >OLD: > >[HASH-Attack] summarizes the use of hashes in many protocols and >discusses how attacks against a message digest algorithm's one-way >and collision-free properties affect and do not affect Internet >protocols. Familiarity with [HASH-Attack] is assumed. > >NEW: > >[HASH-Attack] summarizes the use of hashes in many protocols and >discusses how attacks against a message digest algorithm's one-way >and collision-free properties affect and do not affect Internet >protocols. Familiarity with [HASH-Attack] is assumed. One of the >uses of message digest algorithms in [HMAC-Attack] was integrity >protection. Where the MD5 checksum is used inline with the >protocol solely to protect against errors an MD5 checksum is still >an acceptable use. Applications and protocols need to clearly >state in their security considerations what security services, if >any, are expected from the MD5 checksum. In fact, any application >and protocol that employs MD5 needs to clearly state the expected >security services from their use of MD5. > >spt From johnl@iecc.com Tue Dec 21 10:57:17 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D78E3A6998 for ; Tue, 21 Dec 2010 10:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb+cggQKCYUO for ; Tue, 21 Dec 2010 10:57:15 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 70F693A6B15 for ; Tue, 21 Dec 2010 10:57:15 -0800 (PST) Received: (qmail 49938 invoked from network); 21 Dec 2010 18:59:11 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 21 Dec 2010 18:59:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=8e5a.4d10f8fe.k1012; i=johnl@user.iecc.com; bh=EH2Gg76aAsChyeRD4Fs4tfyvy67xSMZ/pRl5M7KW4kg=; b=ZLnZVc0255orRuytDcCDFo+Jlv9Kn9GMtAbV+reE9QWJ7anmX5XiIJj2a/z8twCKeDSYbX7mS1tiF7WKji0AHQaAyrwXu4dwuf0ptlXJL+vcxeqjwkPvXUHMHaQa5PWaD1cffzgx18HRxOxkL8hIkaHoYexsztkZfjEBDYkx69c= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 21 Dec 2010 18:59:10 -0000 Message-ID: <20101221185910.36441.qmail@joyce.lan> From: John Levine To: ietf@ietf.org Subject: Re: Automatically updated Table of Contents with Nroff In-Reply-To: <4D10D92A.8000508@gmx.de> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: julian.reschke@gmx.de X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 18:57:17 -0000 >So, I do understand how generate the ToC at the end, and I'll probably >grok .so, but what is needed to extract the ToC into a separate file? Is >there anything in nroff supporting that, or were you just referring to a >set of homegrown tools? Nroff isn't a document formatter, it's an interpretive programming language in which one can write document formatters. Everything is either home grown, or borrowed from someone else who homegrew it. As you might expect, there is a great deal of folklore in the nroff community about the ways you implement stuff using the stone axes and chisels that nroff provides. (I guess I qualify, having been using it since about 1973.) The usual way to generate a TOC is to use .tm directives which write the TOC to the standard error, which you capture in a file using the usual Unix shell redirection. Then you rerun nroff using .so to include that file up at the front where the TOC goes. Rather than trying to format the TOC as it's generated, I always write out macro calls which will be expanded as the included file is read, e.g.: .Tc 2 4.2 12 "Efficient lossless packet compression" In this example, this is second level heading 4.2 on page 12. It's easy enough to generate whatever sort of TOC you want, and the usual nroff page break stuff does the pagination. Now, of course, this means that the TOC in your ouput is actually the TOC from the last time you ran nroff, so there's the possibility of version skew. It's not hard to have your script or makefile compare the old and new TOC files, notice that the current TOC is different from the one you used, and tell you to run it again. If this all seems like a gross complicated crock, well, yeah, what do you expect from something designed to run on PDP-11s in the 1970s? That's why we love it so. R's, John PS: When I write books, I write and proof them in nroff and use a little perl script to translate it to docbook before sending it off to the publisher. From randy_presuhn@mindspring.com Tue Dec 21 11:19:00 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C903A687A for ; Tue, 21 Dec 2010 11:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_82=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTWEkOeHwA1h for ; Tue, 21 Dec 2010 11:18:59 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 9E14D3A685C for ; Tue, 21 Dec 2010 11:18:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iwEvoxxO3NALQvK9jrrownrgj7UG7WjP2KgH+5LBeMp6ivxZzCmNAR7swb75iG+v; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.95.109] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PV7lX-0007bJ-Gq for ietf@ietf.org; Tue, 21 Dec 2010 14:20:55 -0500 Message-ID: <005101cba144$5ef73b20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "IETF Discussion Mailing List" References: <001b01ca0512$2c6be860$6801a8c0@oemcomputer> <4A5D9DBF.7050605@gmx.de> <4D10D92A.8000508@gmx.de> Subject: Re: Automatically updated Table of Contents with Nroff Date: Tue, 21 Dec 2010 11:22:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888d26d9b9edb73dbfb6dd82bddc2b424eb14b99693db0f4d05350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.95.109 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 19:19:00 -0000 Hi - > From: "Julian Reschke" > To: "Randy Presuhn" > Cc: "IETF Discussion Mailing List" > Sent: Tuesday, December 21, 2010 8:43 AM > Subject: Re: Automatically updated Table of Contents with Nroff ... > So, I do understand how generate the ToC at the end, and I'll probably > grok .so, but what is needed to extract the ToC into a separate file? Is > there anything in nroff supporting that, or were you just referring to a > set of homegrown tools? Also, as far as I can tell, the generated ToC > will already be paginated, so do you post-process it again so it can be > inserted properly? Here's one incarnation of what I used: Along with the other macro definitions (for six-month expiration date generation and so on) I define a custom ".Nh" macro for section headings, which just turns around an invokes the ms macros for section headers and for table of contents entry generation. .\" **************************************************** .\" * section numbering - built on the ms macro * .\" **************************************************** .de Nh .in 0 .NH \\$1 \\$2 .XS \\*(SN \\$2 .XE .in 3 Then, at the point in the document where we actually want the table of contents to appear: .\" .\" Table of contents - we cheat, using the table of contents .\" file generated on the last pass through nroff. .\" .sp .ne 5 .ti 0 Table of Contents .sp .so toc.ms .bp Then, at the very end, we spit out the current table of contents: .\" .\" Table of contents here .\" .TC yes To process all this, use the following script to invoke nroff, and peel off the most recently generated table of contents from the end. This means that the table of contents that shows up in the formatted document is actually that from the previous run. Running the script twice resolves pagination inconsistencies. "Bootstrapping" the very first run (empty "txt" file) will start out with an empty table of contents, but it will be fine the next time around (for a single page ToC, second time around for a multi-page ToC.) This also handles the FormFeed insertion. # # Files used: # document.ms = input # txt = intermediate table of contents extracted from previous nroff run # toc.ms = table of contents data (updated) # stdout = "real" output # # # extract table of contents from previous run # awk < txt 'BEGIN{skipping=1;} / Table of Contents/{skipping=0;} /\.\.\.\./{if (skipping) next; print; printf(".br\n");}' | sed '1,$s/\.\.\.//' >toc.ms # # now run nroff using that old table of contents # nroff -ms document.ms | awk '/FORMFEED/{DoFF=1; print; next;} /^$/{if (DoFF) next; else print; next;} {if (DoFF) {DoFF = 0; printf(" \n");} print;}' | sed '1,$s/.//g' | sed '1,$s/FORMFEED/ /' >txt # # Strip off the trailing table of contents and we're through # awk X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280713A6AAD for ; Tue, 21 Dec 2010 11:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.643 X-Spam-Level: X-Spam-Status: No, score=-104.643 tagged_above=-999 required=5 tests=[AWL=-2.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gumEUzyJ94dT for ; Tue, 21 Dec 2010 11:36:21 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id D198B3A6A8B for ; Tue, 21 Dec 2010 11:36:20 -0800 (PST) Received: (qmail invoked by alias); 21 Dec 2010 19:38:15 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp045) with SMTP; 21 Dec 2010 20:38:15 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+qPvcAclGqLqFcd9+TjrbuneTveaRdNuFLe2eIeH QQ+iezncLYAb8z Message-ID: <4D110223.3050104@gmx.de> Date: Tue, 21 Dec 2010 20:38:11 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Levine Subject: Re: Automatically updated Table of Contents with Nroff References: <20101221185910.36441.qmail@joyce.lan> In-Reply-To: <20101221185910.36441.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 19:36:22 -0000 Hi John, thanks a *lot* for the explanations. More below. On 21.12.2010 19:59, John Levine wrote: >> So, I do understand how generate the ToC at the end, and I'll probably >> grok .so, but what is needed to extract the ToC into a separate file? Is >> there anything in nroff supporting that, or were you just referring to a >> set of homegrown tools? > > Nroff isn't a document formatter, it's an interpretive programming > language in which one can write document formatters. Everything is > either home grown, or borrowed from someone else who homegrew it. As > you might expect, there is a great deal of folklore in the nroff > community about the ways you implement stuff using the stone axes and > chisels that nroff provides. (I guess I qualify, having been using it > since about 1973.) > > The usual way to generate a TOC is to use .tm directives which write > the TOC to the standard error, which you capture in a file using > the usual Unix shell redirection. Then you rerun nroff using .so > to include that file up at the front where the TOC goes. That's what I understood from previous threads, but I had no idea how to get that second output stream (I was staring at ".open" earlier today). > Rather than trying to format the TOC as it's generated, I always write > out macro calls which will be expanded as the included file is read, > e.g.: > > .Tc 2 4.2 12 "Efficient lossless packet compression" > > In this example, this is second level heading 4.2 on page 12. It's > easy enough to generate whatever sort of TOC you want, and the usual > nroff page break stuff does the pagination. So is .TC plain nroff or in some package? > Now, of course, this means that the TOC in your ouput is actually the > TOC from the last time you ran nroff, so there's the possibility of > version skew. It's not hard to have your script or makefile compare > the old and new TOC files, notice that the current TOC is different > from the one you used, and tell you to run it again. Understood (been there with Tex a few decades ago). > If this all seems like a gross complicated crock, well, yeah, what do > you expect from something designed to run on PDP-11s in the 1970s? > That's why we love it so. And that's why I'm so totally excited that people seriously consider writing new code to *produce* NROFF output, instead of simply formatting directly to plain text. > R's, > John > > PS: When I write books, I write and proof them in nroff and use a > little perl script to translate it to docbook before sending it off > to the publisher. Best regards, Julian From johnl@iecc.com Tue Dec 21 11:48:17 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E16E3A6A4C for ; Tue, 21 Dec 2010 11:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.586 X-Spam-Level: X-Spam-Status: No, score=-110.586 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oed2tgVNqBb0 for ; Tue, 21 Dec 2010 11:48:16 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 221B53A6892 for ; Tue, 21 Dec 2010 11:48:16 -0800 (PST) Received: (qmail 62790 invoked from network); 21 Dec 2010 19:50:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=f545.4d1104f4.k1012; i=johnl@submit.iecc.com; bh=x5k4wqUlA0ipMuQG1LzJ8wyAONzqxWzNE6enB9QmXss=; b=Vb+j+tam0RH1JZZLwNZA/V20M1NBFhdp4U1EZgnAi5GFYuexOAzMjwUtYfwVKDfqi6k6DFSRRU6fkprX244YEIlHtKGlOJ8ndmrwz3ElWIRB/0J/MRx65l11X2/nHWoGdAkoR5ysudc/vq3bFBlbGqQIZz8OTxBi89kk994wwKc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Dec 2010 19:49:50 -0000 Date: 21 Dec 2010 14:50:12 -0500 Message-ID: From: "John R. Levine" To: "Julian Reschke" Subject: Re: Automatically updated Table of Contents with Nroff In-Reply-To: <4D110223.3050104@gmx.de> References: <20101221185910.36441.qmail@joyce.lan> <4D110223.3050104@gmx.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 19:48:17 -0000 >> .Tc 2 4.2 12 "Efficient lossless packet compression" >> >> In this example, this is second level heading 4.2 on page 12. It's >> easy enough to generate whatever sort of TOC you want, and the usual >> nroff page break stuff does the pagination. > > So is .TC plain nroff or in some package? It's a macro. Plain nroff formatting is all very low level, e.g., skip a line, switch to font 3, set line length to N picas. I have a bad habit of writing my own nroff/troff macros so you're welcome to whatever I have lying around, but I doubt it'll be directly useful. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Tue Dec 21 11:53:28 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9373A6A4C for ; Tue, 21 Dec 2010 11:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.605 X-Spam-Level: X-Spam-Status: No, score=-110.605 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHgg5eORckFc for ; Tue, 21 Dec 2010 11:53:27 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 98D953A6856 for ; Tue, 21 Dec 2010 11:53:27 -0800 (PST) Received: (qmail 64285 invoked from network); 21 Dec 2010 19:55:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=fb1c.4d11062b.k1012; i=johnl@submit.iecc.com; bh=IrWS5ukEV4mkf+ROqOLY/fde3msCpCoERxSY8A/DqkE=; b=Atg6CJaeOR9RzU2OP7e2pBZkHv6AI1NbW+fZOpFsNEJsrWKDX2rniMTLncTNJ9tycQOMYklT9EivuPabpnaWZhm++7CynTDL9gElOO8l5iTa9N7tCS4DP7Co9C5yY5vzm8JNQoHL7dSpZDVxdsTKGTGPP+7h+CJzwELpcyJkUlk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Dec 2010 19:55:01 -0000 Date: 21 Dec 2010 14:55:23 -0500 Message-ID: From: "John R. Levine" To: "Julian Reschke" Subject: Re: Automatically updated Table of Contents with Nroff In-Reply-To: <4D110223.3050104@gmx.de> References: <20101221185910.36441.qmail@joyce.lan> <4D110223.3050104@gmx.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 19:53:28 -0000 >> The usual way to generate a TOC is to use .tm directives which write >> the TOC to the standard error, which you capture in a file using >> the usual Unix shell redirection. Then you rerun nroff using .so >> to include that file up at the front where the TOC goes. > > That's what I understood from previous threads, but I had no idea how to get > that second output stream (I was staring at ".open" earlier today). PS: You could use .open and .write but they are a recent (circa 1990) addition so I haven't gotten around to using them yet. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From julian.reschke@gmx.de Tue Dec 21 13:16:10 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EB23A68A5 for ; Tue, 21 Dec 2010 13:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.617 X-Spam-Level: X-Spam-Status: No, score=-104.617 tagged_above=-999 required=5 tests=[AWL=-2.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq65kHLIM1c3 for ; Tue, 21 Dec 2010 13:16:10 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 39A503A6888 for ; Tue, 21 Dec 2010 13:16:07 -0800 (PST) Received: (qmail invoked by alias); 21 Dec 2010 21:18:03 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp067) with SMTP; 21 Dec 2010 22:18:03 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+8zyQpJku8q0A3ULjrQ4gqiTnFDmtk7WuSjScaWe 7abi77kcGf5j6f Message-ID: <4D111987.2090509@gmx.de> Date: Tue, 21 Dec 2010 22:17:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Presuhn Subject: Re: Automatically updated Table of Contents with Nroff References: <001b01ca0512$2c6be860$6801a8c0@oemcomputer> <4A5D9DBF.7050605@gmx.de> <4D10D92A.8000508@gmx.de> <005101cba144$5ef73b20$6801a8c0@oemcomputer> In-Reply-To: <005101cba144$5ef73b20$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 21:16:11 -0000 On 21.12.2010 20:22, Randy Presuhn wrote: > Hi - > >> From: "Julian Reschke" >> To: "Randy Presuhn" >> Cc: "IETF Discussion Mailing List" >> Sent: Tuesday, December 21, 2010 8:43 AM >> Subject: Re: Automatically updated Table of Contents with Nroff > ... >> So, I do understand how generate the ToC at the end, and I'll probably >> grok .so, but what is needed to extract the ToC into a separate file? Is >> there anything in nroff supporting that, or were you just referring to a >> set of homegrown tools? Also, as far as I can tell, the generated ToC >> will already be paginated, so do you post-process it again so it can be >> inserted properly? > > Here's one incarnation of what I used: > ... Thanks a lot. This seems to be a bit less elegant compared to what John was hinting at, but it *is* running code. I'll probably try this. Best regards, Julian From randy_presuhn@mindspring.com Tue Dec 21 13:35:35 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D739B3A68E1 for ; Tue, 21 Dec 2010 13:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.254 X-Spam-Level: X-Spam-Status: No, score=-101.254 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM3LuWj-xWg9 for ; Tue, 21 Dec 2010 13:35:35 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 2C3213A68C6 for ; Tue, 21 Dec 2010 13:35:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GO1UWDF6iNoU73rhPhZo8dzwEY7zsmqZ3j/Ji3oddKeLeAuFpY/DXBdBPsc7WeD8; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.95.109] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PV9tj-0008VX-5C; Tue, 21 Dec 2010 16:37:31 -0500 Message-ID: <001a01cba157$74514160$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Julian Reschke" References: <001b01ca0512$2c6be860$6801a8c0@oemcomputer> <4A5D9DBF.7050605@gmx.de><4D10D92A.8000508@gmx.de><005101cba144$5ef73b20$6801a8c0@oemcomputer> <4D111987.2090509@gmx.de> Subject: Re: Automatically updated Table of Contents with Nroff Date: Tue, 21 Dec 2010 13:38:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888d26d9b9edb73dbfb69c4be2c563f7bc7d8d4a57a33feb8f7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.95.109 Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 21:35:35 -0000 Hi - > From: "Julian Reschke" > To: "Randy Presuhn" > Cc: "IETF Discussion Mailing List" > Sent: Tuesday, December 21, 2010 1:17 PM > Subject: Re: Automatically updated Table of Contents with Nroff ... > > Here's one incarnation of what I used: > > ... > > Thanks a lot. This seems to be a bit less elegant compared to what John > was hinting at, but it *is* running code. I'll probably try this. If you *know* you'll be using a more modern version of, say, groff, then writing to a file (and *not* instantiating the TOC within the document) is definitely more elegant. However, some installations of groff disable that feature, since it introduces additional security risks. Randy From juhovh@iki.fi Mon Dec 20 10:59:13 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C783A6A4C; Mon, 20 Dec 2010 10:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQp-9XNjr+Qx; Mon, 20 Dec 2010 10:59:12 -0800 (PST) Received: from smtp03.tky.fi (smtp03.tky.fi [82.130.63.73]) by core3.amsl.com (Postfix) with SMTP id 19F923A67F4; Mon, 20 Dec 2010 10:59:11 -0800 (PST) Received: from smtp.vaha-herttua.fi ([82.130.44.233]) by smtp03.tky.fi (SMSSMTP 4.1.9.35) with SMTP id M2010122021010409156 ; Mon, 20 Dec 2010 21:01:04 +0200 Received: from vagabond.lan (pyq1.kyla.fi [82.130.44.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.vaha-herttua.fi (Postfix) with ESMTPSA id 8084A1FCFE; Mon, 20 Dec 2010 21:01:24 +0200 (EET) Subject: Re: [TLS] Last Call: (Datagram Transport Layer Security version 1.2) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-29-1031850430; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: Date: Mon, 20 Dec 2010 21:01:02 +0200 Message-Id: References: <20101130132359.32419.3777.idtracker@localhost> To: Pekka Savola X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 21 Dec 2010 14:15:59 -0800 Cc: draft-ietf-tls-rfc4347-bis@tools.ietf.org, ietf@ietf.org, tls-chairs@tools.ietf.org, tls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 18:59:13 -0000 --Apple-Mail-29-1031850430 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20.12.2010, at 15.15, Pekka Savola wrote: > 3.2.3. Message Size >=20 > TLS and DTLS handshake messages can be quite large (in theory up to > 2^24-1 bytes, in practice many kilobytes). By contrast, UDP > datagrams are often limited to <1500 bytes if fragmentation is not > desired. In order to compensate for this limitation, each DTLS > handshake message may be fragmented over several DTLS records. Each > DTLS handshake message contains both a fragment offset and a = fragment > length. >=20 > 4.1.1. Transport Layer Mapping >=20 > Each DTLS record MUST fit within a single datagram. In order to > avoid fragmentation, clients of the DTLS record layer SHOULD attempt > to size records so that they fit within any PMTU estimates obtained > from the record layer. >=20 > ... these seem somewhat contradictory. Maybe I'm missing something. = The > latter seems to be saying that DTLS implementations should try to = avoid IP > fragmentation, but the former seems to imply that it's de-facto mode = of > operation. These are not contradictory. If a handshake message size and record = header don't fit inside single datagram, it should be fragmented into = several small handshake messages and each of these is put into a = separate DTLS record. The resulting DTLS record after encryption should = not exceed the maximum UDP (or DCCP or whatever) datagram size and = therefore doesn't need IP level fragmentation. I think what you "missed" was simply the difference of IP level = fragmentation and DTLS handshake protocol level fragmentation. Juho --Apple-Mail-29-1031850430 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM+DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGvDCCBaSg AwIBAgICC7kwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDEwMDkxODQ4MjVaFw0xMjEwMDkyMzA0MjZaMIG6MSAwHgYDVQQNExcyNzE5OTktNTRMRzc2dUow TXMwQWs4eDELMAkGA1UEBhMCRkkxEDAOBgNVBAgTB1V1c2ltYWExDjAMBgNVBAcTBUVzcG9vMS0w KwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEUp1 aG8gVmFoYS1IZXJ0dHVhMRwwGgYJKoZIhvcNAQkBFg1qdWhvdmhAaWtpLmZpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgecI8+NNG/D0e/PpHHJDPlVhR4mmAPZZUBA22yAf6OageO6 H9GUuuNq787QHvF87ySXb8uZMpC1EDqdkEweHdRMd8fPvHmhgLj4w3xO/pFG/d/ZUpQ3nUEF7yqm 94mgG1yW1ps3Q5eKuUE7m5XT3MKxDugb2GX/5u4LmVrC3YM6DDqdf7Fzof9F3I44EpeQfJx5jp8Y KerCRGEVTVfxcA8JxHT5ZAi3xG3lVBkYb45zHzKCGz32ol34L65IRkTt9wkNnkZYzDv3E8sweQpL 5U24kHUMxclWmGpvNuXyWdaFeg68bUXujoUfoTzSf3p1vx7PWMAHd4PnCuX5e4rAWwIDAQABo4IC 9jCCAvIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQOC6ocoJ57B8gH/dYfGyjmOl92tDAfBgNVHSMEGDAWgBSuVYNv7DHKufcd +q9rMfPIHeOsuzAYBgNVHREEETAPgQ1qdWhvdmhAaWtpLmZpMIIBQgYDVR0gBIIBOTCCATUwggEx BgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlh YmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTIt Y3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCunEi6zUK6IXC5vcyRBFVcZdpE QsYKVVKwS6T1NPxMVlLriKu27lG3tuxgwW4mR/FpyXf30RmP2/l3BMcrnBMVKqY9KQle7pzv1nDG Om2QSHUbgjMaOyvNeSwjkjP/2zfZ2gdot1S3K6PZl4SKx1H6tOqePPJAfCYb4WBj/vlIREmXzozd pzQu8G7fEuIni76Z0xIJVC50KDcry1lIsuZGUQ+fXuVkbNv7EO8tID6ylX/EWIMd2Pz/gq+0Jppz hIqo03Y03cPZAsqFtg+ZqukM/zdmapHK/ayVJaHsRbS7fvbC8aE6o0T6p5KwqQI0lcDyvugOw/pg FHSf/UgeAE2MMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kw CQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTAxMjIwMTkwMTAzWjAjBgkqhkiG9w0BCQQxFgQUO8iwnfERGfio6iB+//HaJdQf6G8wgaQGCSsG AQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgILuTCBpgYLKoZIhvcN AQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kwDQYJKoZIhvcNAQEB BQAEggEAabZLwXlnAFNLstdSWXQY6SEPIkb+By9JdvAVsnYGozGWW7MP+DWRSCPkmI1DrHzXiTKu KPxZnk73D3sf/oqRiClRkW5MCzUVkPpxREJqhDWdq47AbT0zjU5/5btTfnnkx75oRJhVQ6CpBQhf 44Yn9rt5Sg1UcS+lq415DlM4Qyb5ggzfUKpnGTcrZnP6xMEr8VXgY8cE1fvGpAldPyaNTQjz9G7U TC6eKQv8C3ZlwOC2j9aowjA/nMo+bTwU2nZgveNp/v3hsL6wWctQmlN61y6COj2VN/Wx2Tug2UYS f+aV5gD1GpCWaliPeVkU/rxq6hoUPJwI8/zVMCVCAl3ozQAAAAAAAA== --Apple-Mail-29-1031850430-- From hartmans@painless-security.com Tue Dec 21 09:23:06 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF35D3A6B35; Tue, 21 Dec 2010 09:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9HS9OX8Q8xH; Tue, 21 Dec 2010 09:23:06 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 24CED3A6B29; Tue, 21 Dec 2010 09:23:05 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 738FA200D5; Tue, 21 Dec 2010 12:23:51 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 118D14060; Tue, 21 Dec 2010 12:24:40 -0500 (EST) From: Sam Hartman To: Sean Turner Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC References: <201012082333.oB8NXhhe067090@givry.fdupont.fr> <4D10E062.7000901@ieca.com> Date: Tue, 21 Dec 2010 12:24:40 -0500 In-Reply-To: <4D10E062.7000901@ieca.com> (Sean Turner's message of "Tue, 21 Dec 2010 12:14:10 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 Dec 2010 14:15:59 -0800 Cc: Francis Dupont , "ietf@ietf.org" , "L.Wood@surrey.ac.uk" , "wes@mti-systems.com" , "iesg@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 17:23:06 -0000 I'm OK with this text. I tried to come up with a way to briefly discuss how error detection is very related to things like protecting against substitution of content (the internet mirror case) but failed to come up with something brief. So, I'm fine with what you have. --Sam From hartmans@painless-security.com Tue Dec 21 09:57:02 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F443A6A8D; Tue, 21 Dec 2010 09:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P25Usi1bp9xt; Tue, 21 Dec 2010 09:57:01 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id A492A3A6B0D; Tue, 21 Dec 2010 09:57:01 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 584A12016B; Tue, 21 Dec 2010 12:57:43 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2C49E4060; Tue, 21 Dec 2010 12:58:31 -0500 (EST) From: Sam Hartman To: Francis Dupont Subject: Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC References: <201012211755.oBLHt9Tn017296@givry.fdupont.fr> Date: Tue, 21 Dec 2010 12:58:31 -0500 In-Reply-To: <201012211755.oBLHt9Tn017296@givry.fdupont.fr> (Francis Dupont's message of "Tue, 21 Dec 2010 18:55:09 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 21 Dec 2010 14:15:59 -0800 Cc: "ietf@ietf.org" , "L.Wood@surrey.ac.uk" , "wes@mti-systems.com" , "iesg@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 17:57:02 -0000 >>>>> "Francis" == Francis Dupont writes: Francis> In your previous mail you wrote: Francis> I'm OK with this text. I tried to come up with a way to Francis> briefly discuss how error detection is very related to Francis> things like protecting against substitution of content (the Francis> internet mirror case) but failed to come up with something Francis> brief. So, I'm fine with what you have. Francis> => can I conclude you are in the "they are security Francis> considerations so don't talk about not-security uses" side? No. Especially for something like md5 you need to talk about it enough so that we can evaluate whether it's actually a security use or not. I sent a moderately long message to the ietf list about this. From ben@nostrum.com Tue Dec 21 14:12:09 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF693A6A8F; Tue, 21 Dec 2010 14:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.007 X-Spam-Level: X-Spam-Status: No, score=-101.007 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11tMlBcK-sEO; Tue, 21 Dec 2010 14:12:09 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id BD9033A6A8B; Tue, 21 Dec 2010 14:12:08 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oBLMDx4D057335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Dec 2010 16:14:00 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Gen-ART LC Review of draft-ietf-mpls-tp-uni-nni-02 Date: Tue, 21 Dec 2010 16:13:59 -0600 Message-Id: <6C0631D0-F9BB-42B3-BFB0-B62945BEAFD3@nostrum.com> To: draft-ietf-mpls-tp-uni-nni.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 21 Dec 2010 14:15:59 -0800 Cc: General Area Review Team , The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 22:12:10 -0000 I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = . Please resolve these comments along with any other Last Call comments = you may receive. Document: draft-ietf-mpls-tp-uni-nni-02 Reviewer: Ben Campbell=09 Review Date: 2010-12-21 IETF LC End Date: 2010-12-23 IESG Telechat date: (if known) Summary: This draft is ready for publication as in informational RFC. I = have a small number of editorial comments that I think could further = improve the draft if there is another round of editing. Major issues: None Minor issues: None Nits/editorial comments: -- Section 1, 1st paragraph: I suggest moving the expansion of MPLS-TP TP the first mention in the = body of the draft. -- Section 1.1, 1st paragraph: More conventional in what context? Useful for what purpose? -- Section 1.2, definition of UNI-N I suggest expanding PE in the definition. -- Figures 1 and 2: Is the meaning of the various line types described elsewhere? If so, a = statement to that effect with a reference would be helpful. -- Figure 2: I suggest expanding CP somewhere.= From tony@att.com Tue Dec 21 15:21:07 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D8B3A6921 for ; Tue, 21 Dec 2010 15:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb7kVKRnfwq1 for ; Tue, 21 Dec 2010 15:21:05 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id EC7713A67FA for ; Tue, 21 Dec 2010 15:21:04 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-5.tower-161.messagelabs.com!1292973780!20554649!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 5347 invoked from network); 21 Dec 2010 23:23:00 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Dec 2010 23:23:00 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBLNNK46029100 for ; Tue, 21 Dec 2010 18:23:20 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBLNNCx6028966 for ; Tue, 21 Dec 2010 18:23:12 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBLNMpcx017229 for ; Tue, 21 Dec 2010 18:22:51 -0500 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBLNMjsH016989 for ; Tue, 21 Dec 2010 18:22:45 -0500 Received: from [135.70.30.68] (vpn-135-70-30-68.vpn.west.att.com[135.70.30.68]) by maillennium.att.com (mailgw1) with ESMTP id <20101221232244gw1004lkpoe> (Authid: tony); Tue, 21 Dec 2010 23:22:44 +0000 X-Originating-IP: [135.70.30.68] Message-ID: <4D1136C2.3030206@att.com> Date: Tue, 21 Dec 2010 18:22:42 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Julian Reschke Subject: Re: Automatically updated Table of Contents with Nroff References: <001b01ca0512$2c6be860$6801a8c0@oemcomputer> <4A5D9DBF.7050605@gmx.de> <4D10D92A.8000508@gmx.de> In-Reply-To: <4D10D92A.8000508@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 23:21:07 -0000 The magic directive is .tm: .tm string After skipping initial blanks, string (rest of the line) is read in copy mode and written on the standard error. For anything you want in the table of contents, put in this line at the proper place (or include it in a header macro): .tm header level and title . . . . . . \n% Stick in a line that says .so toc.input where you want the table of contents to go. # empty out toc.input > toc.input # run once to get a sample ToC, but page numbers will be off nroff file > /dev/null 2> toc.input # run again to get proper page numbers into toc.input nroff file > /dev/null 2> toc.input # run a 3rd time to get the right output, ignoring stderr this time nroff file 2>/dev/null And your output will have a table of contents in the proper place with the proper page numbers. Note: At least on my linux box, this won't work because nroff is a shell script that calls groff internally and redirects stderr to /dev/null. So you have to use groff directly. Tony Hansen On 12/21/2010 11:43 AM, Julian Reschke wrote: > On 15.07.2009 11:13, Julian Reschke wrote: >> Randy Presuhn wrote: >>> ... >>> No need to manually edit. >>> >>> Use the macros or awk / sed to spit the toc into a file which can be >>> inserted >>> into the correct position by the .so nroff directive. This will >>> result in >>> a table of contents in the correct position. There is the possibility >>> that if the number of toc pages has changed from one iteration >>> to the next that the page numbers will be off by one, but that will >>> go away the next time the process runs. >>> >>> For editing a document, particularly a largish one, the availability of >>> .so is for me nroff's biggest advantage over xml2rfc. >>> ... >> ... > > Randy, > > I've been spending some time looking at the feasibility of using NROFF > for IDs while retaining features like automatics generation of the TOC > in the *right* place. > > Funny enough, googling for this topic leads me back to this thread > (and nowhere else, it seems). > > So, I do understand how generate the ToC at the end, and I'll probably > grok .so, but what is needed to extract the ToC into a separate file? > Is there anything in nroff supporting that, or were you just referring > to a set of homegrown tools? Also, as far as I can tell, the generated > ToC will already be paginated, so do you post-process it again so it > can be inserted properly? From evnikita2@gmail.com Wed Dec 22 02:23:25 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7DF3A69A4 for ; Wed, 22 Dec 2010 02:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwDHxANmAZs3 for ; Wed, 22 Dec 2010 02:23:24 -0800 (PST) Received: from mail-bw0-f50.google.com (mail-bw0-f50.google.com [209.85.214.50]) by core3.amsl.com (Postfix) with ESMTP id 850533A69B0 for ; Wed, 22 Dec 2010 02:23:23 -0800 (PST) Received: by bwg12 with SMTP id 12so5657107bwg.37 for ; Wed, 22 Dec 2010 02:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type; bh=r4IEaEgNZJZt7yqHd59ZHNeri5b2uAUsr1zFvsatSVo=; b=eZtO1I1gS7PeF0HPXka1vnUUV3tPnR/D77pwldYbAw6gdNMemiThcEL1w9zN57yMks I1kCQ1DnwRvtk/lyIcTKJheFm4gBgAIeVWEwwQz0kUmcQ69ohA3GgdmlOFxSTkdldGas Qcg/38avmW8reypK+u+btiXrNXA1PrDUjivB4= 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; b=nRqjHu8wctOR6RM4GZ+u/RQbJ0ZijGCTNiIdVpFA/WEDgF/r5MYSmnR9PoWMHxiixJ Kjz3KyF5BEJ67FcmwK8WE422cg4C6sMNxHsmDqF5XxoOucU1uCHNp4RWVLe94lXIYaye RBC2YDWhFrMFxxmLKGpm1Qs/VqV9Z68IlRYtk= Received: by 10.204.63.2 with SMTP id z2mr5799996bkh.66.1293013520626; Wed, 22 Dec 2010 02:25:20 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id x38sm3547685bkj.13.2010.12.22.02.25.19 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Dec 2010 02:25:20 -0800 (PST) Message-ID: <4D11D21C.5090909@gmail.com> Date: Wed, 22 Dec 2010 12:25:32 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF Discussion , httpbis Group Subject: Last Call on draft-yevstifeyev-http-headers-not-recognized - summarizing first week Content-Type: multipart/alternative; boundary="------------040703040709070502040809" Cc: Alexey Melnikov X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 10:23:25 -0000 This is a multi-part message in MIME format. --------------040703040709070502040809 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, This message summarizes the first Last Call week on draft-yevstifeyev-http-headers-not-recognized. The document have been discussed on IETF Discussion and HTTPBIS WG mailing lists. I include the most current entity to be discussed: > 1. Introduction > > 1.1. Motivation > > HTTP is one of the most widely-used protocols in the Internet. One of > the things which made it so popular is extensibility. One can easily > add any header field to the HTTP message. However, all hosts are not > able to support all the header fields. Generally, if a it host does > not support the header field, it is simply ignored. The another side > of exchange is not notified about not processed header fields. > > This document proposes mechanism which allows HTTP hosts to notify > another hosts about not recognized headers. > > The proposal is to send a response with definite header field to the > host if one or more header fields of request are not supported. This > document defines Headers-Not-Recognized HTTP header field to be used > in such occasion. > 2. Technical Overview > > 2.1 Model of Work > > If the HTTP host receives HTTP message which contains some header > fields which are not supported by it, it is RECOMMENDED for it to > include the Headers-Not-Recognized header field in the response to > the host that sent not supported header fields. Information about not > supported header field is to be put in this header field following > the rules of Section 2.2 of this document. The Headers-Not-Recognized > header field MUST contain information only about not supported header > fields - i.e. header fields which are not able to be processed > anyway. It MUST NOT contain information about header fields, which > are partly supported, not intended to be used or whose entity cannot > be processed while the header field is supported at all etc. > > When HTTP host receives HTTP message with Headers-Not-Recognized > header field, it is RECOMMENDED that it avoids sending packets with > header fields with mentioned in it names to source (for message with > this header) host or tries to change them so that hat host is able to > recognize and process them. > > Intermediate systems (also called middle-boxes), such as proxies, > tunnels, gateways etc. MUST transfer the messages with Headers-Not- > Recognized header field to the destination host without changing the > entity of this header field if the not supported header field was > present in the initial HTTP request (i. e. request which intermediate > system received before transferring it to destination node), but MUST > omit it if Headers-Not-Recognized header field's entity concerns only > to headers added to initial request by middle-box. If the > aforementioned header concerns added header fields partly, middle-box > MUST change the entity so that it concerns only initial request > header field. > > 2.2 Syntax > > 'Headers-Not-Recognized' header field has the following format: > > headers_not_recognized = 1#header_name > header_name = 1*VCHAR This is the fragment of the text which is planned to be posted as a draft nearly after 1 January (the half of Last Call period) if no *critical* comments will be received. This text reflects almost all the comments I received during the Last Call and found appropriate. However any other suggestion are still welcome. You may feel free to contact me at evnikita2@gmail.com for further information. All the best, Mykyta Yevstifeyev --------------040703040709070502040809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello all,

This message summarizes the first Last Call week on draft-yevstifeyev-http-headers-not-recognized. The document have been discussed on IETF Discussion and HTTPBIS WG mailing lists.

I include the most current entity to be discussed:
1. Introduction

1.1. Motivation

   HTTP is one of the most widely-used protocols in the Internet. One of
   the things which made it so popular is extensibility. One can easily
   add any header field to the HTTP message. However, all hosts are not
   able to support all the header fields. Generally, if a it host does
   not support the header field, it is simply ignored. The another side
   of exchange is not notified about not processed header fields.

   This document proposes mechanism which allows HTTP hosts to notify
   another hosts about not recognized headers.

   The proposal is to send a response with definite header field to the
   host if one or more header fields of request are not supported. This
   document defines Headers-Not-Recognized HTTP header field to be used
   in such occasion.
2. Technical Overview

2.1 Model of Work

   If the HTTP host receives HTTP message which contains some header
   fields which are not supported by it, it is RECOMMENDED for it to
   include the Headers-Not-Recognized header field in the response to
   the host that sent not supported header fields. Information about not
   supported header field is to be put in this header field following
   the rules of Section 2.2 of this document. The Headers-Not-Recognized
   header field MUST contain information only about not supported header
   fields - i.e. header fields which are not able to be processed
   anyway. It MUST NOT contain information about header fields, which
   are partly supported, not intended to be used or whose entity cannot
   be processed while the header field is supported at all etc.

   When HTTP host receives HTTP message with Headers-Not-Recognized
   header field, it is RECOMMENDED that it avoids sending packets with
   header fields with mentioned in it names to source (for message with
   this header) host or tries to change them so that hat host is able to
   recognize and process them.

   Intermediate systems (also called middle-boxes), such as proxies,
   tunnels, gateways etc. MUST transfer the messages with Headers-Not-
   Recognized header field to the destination host without changing the
   entity of this header field if the not supported header field was
   present in the initial HTTP request (i. e. request which intermediate
   system received before transferring it to destination node), but MUST
   omit it if Headers-Not-Recognized header field's entity concerns only
   to headers added to initial request by middle-box. If the
   aforementioned header concerns added header fields partly, middle-box
   MUST change the entity so that it concerns only initial request
   header field.

2.2 Syntax

   'Headers-Not-Recognized' header field has the following format:

   headers_not_recognized = 1#header_name
   header_name            = 1*VCHAR
This is the fragment of the text which is planned to be posted as a draft nearly after 1 January (the half of Last Call period) if no *critical* comments will be received.

This text reflects almost all the comments I received during the Last Call and found appropriate. However any other suggestion are still welcome.

You may feel free to contact me at evnikita2@gmail.com for further information.

All the best,
Mykyta Yevstifeyev
 --------------040703040709070502040809-- From matthew.bocci@alcatel-lucent.com Wed Dec 22 03:42:54 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA803A6B19; Wed, 22 Dec 2010 03:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.747 X-Spam-Level: X-Spam-Status: No, score=-104.747 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yku+7a4f0Lj5; Wed, 22 Dec 2010 03:42:53 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 797E13A6AF3; Wed, 22 Dec 2010 03:42:52 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oBMBimdg025564 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Dec 2010 12:44:48 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 22 Dec 2010 12:44:48 +0100 From: "Bocci, Matthew (Matthew)" To: Ben Campbell , "draft-ietf-mpls-tp-uni-nni.all@tools.ietf.org" Date: Wed, 22 Dec 2010 12:44:45 +0100 Subject: Re: Gen-ART LC Review of draft-ietf-mpls-tp-uni-nni-02 Thread-Topic: Gen-ART LC Review of draft-ietf-mpls-tp-uni-nni-02 Thread-Index: AcuhzaJdIYi8DTwYTlyXXkD9qq9gSg== Message-ID: In-Reply-To: <6C0631D0-F9BB-42B3-BFB0-B62945BEAFD3@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: General Area Review Team , The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 11:42:54 -0000 Ben, Thank you for your comments. Please see below. Best regards Matthew On 21/12/2010 22:13, "Ben Campbell" wrote: >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at >. > >Please resolve these comments along with any other Last Call comments you >may receive. > >Document: draft-ietf-mpls-tp-uni-nni-02 >Reviewer: Ben Campbell >Review Date: 2010-12-21 >IETF LC End Date: 2010-12-23 >IESG Telechat date: (if known) > > >Summary: This draft is ready for publication as in informational RFC. I >have a small number of editorial comments that I think could further >improve the draft if there is another round of editing. > >Major issues: None > >Minor issues: None > >Nits/editorial comments: > >-- Section 1, 1st paragraph: > >I suggest moving the expansion of MPLS-TP TP the first mention in the >body of the draft. OK. I have moved this to the first use of the acronym in that section. > >-- Section 1.1, 1st paragraph: > >More conventional in what context? Useful for what purpose? It is the convention to represent a UNI or NNI as a specific reference point between functional groups e.g. MEF E-NNI (Figure 2 of MEF26) or ATM UNI (ITU-T I.413), rather than to represent these as a span as in the original diagrams in RFC5921. I propose to rephrase this sentence to: "However, it is convention to illustrate these interfaces as reference points." With regard to your second question, I propose to rephrase the sentence as follows: "Furthermore, in the case of a UNI, it is useful to illustrate the distribution of UNI functions between the Customer Edge (CE) side and the Provider Edge (PE) side of the UNI (the UNI-C and UNI-N) in order to show their relationship to one another." > >-- Section 1.2, definition of UNI-N > >I suggest expanding PE in the definition. OK=20 > >-- Figures 1 and 2: > >Is the meaning of the various line types described elsewhere? If so, a >statement to that effect with a reference would be helpful. We have used the same convention as RFC5921. However, there is no key there. I am not sure that a complete key would clarify the diagram as the same line type is used to represent multiple entities due to the limited umber of characters that are useful for ASCII drawing. > >-- Figure 2: > >I suggest expanding CP somewhere. CP is expanded in the terminology section. From barryleiba.mailing.lists@gmail.com Wed Dec 22 09:19:40 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1E33A67FD for ; Wed, 22 Dec 2010 09:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57TYAXwSXYbb for ; Wed, 22 Dec 2010 09:19:39 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7BD4F3A67AD for ; Wed, 22 Dec 2010 09:19:39 -0800 (PST) Received: by iwn40 with SMTP id 40so5765648iwn.31 for ; Wed, 22 Dec 2010 09:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=dQ4Z4rjEQ7FQoenZTvKH5WKSOBGvK8/uZ23yfeHpUqU=; b=U0JQRszPiNM996T921KTNvV9kjnNOxo750Ioxx/f7vpRwsqhNAZfw/dZTXhhfIwjyF GHhXTNZ1ACk59350b/+OzUgKWAD11Tl3WoEd+OfLB2FJ757SoHwF7mVm7Y+8EjMhIMcI RWLW+pOPsdo8VBL408cXlCVf7G9tapeHacxvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=jBPyk2bJQJrW1qU6ocIx9s22nSxXbQEz5gwCDzQlRz5REnj1RQYE0OJqetl2Uc9pnQ 4jKUVs8UvT28HxZr3nxqIbNzy59PMP/CswrtklUupsxYDDWeg/BMeWTiMUhgUsGQqlLZ Laq7zcL8GOwB1x7SBI4f5VPOtjZmE1F5Ova1k= MIME-Version: 1.0 Received: by 10.42.229.6 with SMTP id jg6mr7252364icb.141.1293038497946; Wed, 22 Dec 2010 09:21:37 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.220.130 with HTTP; Wed, 22 Dec 2010 09:21:37 -0800 (PST) In-Reply-To: <4D1136C2.3030206@att.com> References: <001b01ca0512$2c6be860$6801a8c0@oemcomputer> <4A5D9DBF.7050605@gmx.de> <4D10D92A.8000508@gmx.de> <4D1136C2.3030206@att.com> Date: Wed, 22 Dec 2010 12:21:37 -0500 X-Google-Sender-Auth: pbSE6Z5OjCGC3QO0p6QmK-4IE4w Message-ID: Subject: Re: Automatically updated Table of Contents with Nroff From: Barry Leiba To: IETF Discussion Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:19:40 -0000 > # empty out toc.input >> toc.input > # run once to get a sample ToC, but page numbers will be off > nroff file > /dev/null 2> toc.input > # run again to get proper page numbers into toc.input > nroff file > /dev/null 2> toc.input > # run a 3rd time to get the right output, ignoring stderr this time > nroff file 2>/dev/null You know, this whole discussion renews my total puzzlement at why anyone would use nroff instead of something else... anything else. Yow! I know that not everyone likes xml2rfc, but I don't even want to think about nroff. Barry From ietf@augustcellars.com Tue Dec 21 19:50:08 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B27C3A6977; Tue, 21 Dec 2010 19:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBbNGiuw2yPv; Tue, 21 Dec 2010 19:49:57 -0800 (PST) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 12EA23A693E; Tue, 21 Dec 2010 19:49:57 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id E05F52CA09; Tue, 21 Dec 2010 19:51:51 -0800 (PST) From: "Jim Schaad" To: , "'ietf'" , "'smime'" , "'pkix'" References: <4CFD6726.8040100@ieca.com> In-Reply-To: Subject: RE: [pkix] [smime] Fwd: Last Call: (SignerInfo Algorithm Protection Attribute) to Proposed Standard Date: Tue, 21 Dec 2010 20:07:12 -0800 Message-ID: <005201cba18d$b6a97290$23fc57b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CBA14A.A88DACA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHosiQhqvL9r6pWYq4QUfBZDCsggQF9xKGJk2W8DfA= Content-Language: en-us X-Mailman-Approved-At: Wed, 22 Dec 2010 09:24:16 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 03:50:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0053_01CBA14A.A88DACA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Comments are inline. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Pinkas Sent: Friday, December 17, 2010 12:23 AM To: ietf; smime; pkix Subject: Re: [pkix] [smime] Fwd: Last Call: (SignerInfo Algorithm Protection Attribute) to Proposed Standard I have a few comments about draft-schaad-smime-algorithm-attribute-03.txt: 1) The key question is what should contain the field signatureAlgorithm ? SignatureAlgorithmIdentifier is defined in section 10.1.2 from RFC 5652: 10.1.2. SignatureAlgorithmIdentifier The SignatureAlgorithmIdentifier type identifies a signature algorithm, and it can also identify a message digest algorithm. Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with SHA-256. A signature algorithm supports signature generation and verification operations. The signature generation operation uses the message digest and the signer's private key to generate a signature value. The signature verification operation uses the message digest and the signer's public key to determine whether or not a signature value is valid. Context determines which operation is intended. SignatureAlgorithmIdentifier ::= AlgorithmIdentifier Some examples are questionable: is RSA really a "signature algorithm" ? sha-1withRSA is really a signature mechanism, since it cannot be used for encryption. If "real signature algorithms" were being used in the OID, then half of the problems mentioned in the draft would disappear. This case should be mentioned in the draft. The draft should also recommend the use of signature algorithms using both a hash function and an asymetric algorithm. [JLS] While I agree that perhaps draft should recommend the use a signature algorithms (which are fully defined), I don't understand how this can actually protect against the problems that are outlined. If an attacker can successfully substitute the signature identifier of ECDSA with SHA-256 for ECDSA with SHA-1, and come up with a case where the signature actually validates then there is no protection in the current specification. Actually the case of using rsaEncryption does provide additional protection since the internals of the v1.5 signature validation process checks that the digest algorithm encoded inside of the signature value matches the digest algorithm used to create the digest so in this case the fact that a full signature algorithm identifier is not used there is additional protection. In looking at the text from RFC5652 I believe that there is an errata that could be issued. The text "DSA with SHA-1" should have been "DSA with SHA-256". It is generally accepted that DSA, when not qualified requires the SHA-1 algorithm and thus is a fully specified signature algorithm. I would argue that the same is true for ECDSA. Thus of the listed set, only RSA can be considered not to be a fully specified signature algorithm, but it has internal specification of the hash algorithm. If new signature algorithms are created with random values as part of the input, then there would be no protection as the random value would not be protected. A number of changes to hash functions has been suggested where this might be the case. 2) We come from a point where, 20 years ago, the same certificate was used for three purposes: authentication, non repudiation and encipherment. RSA was the single algorithm used in practice. Since then, there are many situations where different certificates are used for each purpose. We now should recommend to use "real signature algorithms", which mean an OID specifying a combination of a hash function and an asymetric cryptographic algorithm. If a certificate is being used, then an OID specifying the algorithm in the certificate should be OID specifying a combination of a hash function and an asymetric cryptographic algorithm. When certificates are being used, when the ESSCertID is being used, and when "real signature algorithms" are being used then the new proposed protection attribute is not needed. The current draft does not mention this possibility. [JLS] The view you are espousing here, that certificates should be restricted in the algorithm that they can be used for, is not one that is broadly accepted in either the S/MIME or PKIX communities. Since that is the case I don't think that this would address the problems outlined. I do however agree that this can be mentioned as one way of addressing part of the problem statement. 3) There is another draft under discussion in the PKIX WG called: draft-ietf-pkix-ocspagility-09. Although the field "certIdentifier" below is misnamed, the idea is to say that for Elliptic Curves we need two parameters instead of one. This is what the proposed draft is attempting to say: PreferredSignatureAlgorithm ::= SEQUENCE { sigIdentifier AlgorithmIdentifier, certIdentifier AlgorithmIdentifier OPTIONAL } The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of RFC 5280 [RFC5280] sigIdentifier specifies the signature algorithm the client prefers, e.g. algorithm=ecdsa-with-sha256. Parameters are absent for most common signature algorithms. certIdentifier specifies the subject public key algorithm identifier the client prefers in the server's certificate used to validate the OCSP response. e.g. algorithm=id-ecPublicKey and parameters= secp256r1. certIdentifier is OPTIONAL and provides means to specify parameters necessary to distinguish among different usages of a particular algorithm, e.g. it may be used by the client to specify what curve it supports for a given elliptic curve algorithm. Note the this draft provides a correct example for a signature algorithm identifier: ecdsa-with-sha256 The draft proposed by Jim should consider the case of OIDs for Elliptic Curves [JLS] I need more guidance from you on what you think you need. The curve would be protected by the certificate itself. The signature algorithm would be protected by the proposed attribute. 4) The draft is missing a risk analysis or examples for real possibilities of substitution. [JLS] I am currently looking at this in more detail. Jim For the above reasons, I believe that a new draft should be issued. Denis ---------- >From : smime-bounces To : smime Date : 2010-12-06, 23:43:50 Subject : [smime] Fwd: Last Call: (SignerInfo Algorithm Protection Attribute) to Proposed Standard -------- Original Message -------- Subject: Last Call: (Signer Info Algorithm Protection Attribute) to Proposed Standard Date: Mon, 06 Dec 2010 14:35:04 -0800 From: The IESG > To: IETF-Announce > The IESG has received a request from an individual submitter to consider the following document: - 'Signer Info Algorithm Protection Attribute' 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-01-03. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attribute/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attribute/ 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 _______________________________________________ smime mailing list smime@ietf.org https://www.ietf.org/mailman/listinfo/smime ------=_NextPart_000_0053_01CBA14A.A88DACA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments are inline.

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Denis Pinkas
Sent: Friday, December 17, 2010 12:23 = AM
To: ietf; smime; pkix
Subject: Re: [pkix] [smime] = Fwd: Last Call: <draft-schaad-smime-algorithm-attribute-03.txt> = (SignerInfo Algorithm Protection Attribute) to Proposed = Standard

 

I have a = few comments about = draft-schaad-smime-algorithm-attribute-03.txt:

 <= /o:p>

1) The key = question is what should contain the field signatureAlgorithm = ?

 <= /o:p>

SignatureAlg= orithmIdentifier is defined in section 10.1.2 from RFC = 5652:

 <= /o:p>

10.1.2.  = SignatureAlgorithmIdentifier

   The = SignatureAlgorithmIdentifier type identifies a signature
   = algorithm, and it can also identify a message digest = algorithm.
   Examples include RSA, DSA, DSA with SHA-1, = ECDSA, and ECDSA with
   SHA-256.  A signature = algorithm supports signature generation and
   verification = operations.  The signature generation operation uses = the
   message digest and the signer's private key to = generate a signature
   value.  The signature = verification operation uses the message digest
   and the = signer's public key to determine whether or not a = signature
   value is valid.  Context determines which = operation is intended.

      = SignatureAlgorithmIdentifier ::=3D AlgorithmIdentifier<= /span>

 <= /o:p>

Some ex= amples are questionable: is RSA really a "signature algorithm" = ?

sha-1withRSA= is really a signature mechanism, since it cannot be used for = encryption.

 <= /o:p>

If = "real signature algorithms" were being used in the OID, then = half of the problems mentioned in the draft would = disappear.

This = case should be mentioned in the = draft.

 <= /o:p>

The draft = should also recommend the use of signature algorithms using both a hash = function and an asymetric algorithm.

 

[JLS] While I agree that perhaps draft should recommend the use a = signature algorithms (which are fully defined), I don’t understand = how this can actually protect against the problems that are = outlined.  If an attacker can successfully substitute the signature = identifier of ECDSA with SHA-256 for ECDSA with SHA-1, and come up with = a case where the signature actually validates then there is no = protection in the current specification.  Actually the case of = using rsaEncryption does provide additional protection since the = internals of the v1.5 signature validation process checks that the = digest algorithm encoded inside of the signature value matches the = digest algorithm used to create the digest so in this case the fact that = a full signature algorithm identifier is not used there is additional = protection.

 

In looking at the text from RFC5652 I believe that there is an errata = that could be issued.  The text “DSA with SHA-1” should = have been “DSA with SHA-256”.  It is generally accepted = that DSA, when not qualified requires the SHA-1 algorithm and thus is a = fully specified signature algorithm.  I would argue that the same = is true for ECDSA.  Thus of the listed set, only RSA can be = considered not to be a fully specified signature algorithm, but it has = internal specification of the hash algorithm.

 

If new signature algorithms are created with random values as part of = the input, then there would be no protection as the random value would = not be protected.  A number of changes to hash functions has been = suggested where this might be the case.

 

 <= /o:p>

2) We = come from a point where, 20 years ago, the same certificate = was used for three purposes:
authentication, non repudiation = and encipherment. RSA was the single algorithm used in = practice.

Since then, = there are many situations where different certificates are used for each = purpose.

 <= /o:p>

We now = should recommend to use "real signature algorithms", which = mean an OID specifying
a combination of a hash function and an = asymetric cryptographic algorithm.

 <= /o:p>

If a = certificate is being used, then an OID specifying the algorithm in the = certificate should be OID 
specifying a combination of a hash = function and an asymetric cryptographic = algorithm.

 <= /o:p>

When = certificates are being used, when the ESSCertID is being used, and = when "real signature algorithms" are being used
then the = new proposed protection attribute is not = needed.

 <= /o:p>

The current = draft does not mention this possibility.

 

[JLS] The view you are espousing here, that certificates should be = restricted in the algorithm that they can be used for, is not one that = is broadly accepted in either the S/MIME or PKIX communities.  = Since that is the case I don’t think that this would address the = problems outlined.  I do however agree that this can be mentioned = as one way of addressing part of the problem = statement.

 <= /o:p>

3) There is = another draft under discussion in the PKIX WG called: draft-ietf-pkix-ocspagility-09.<= /span>


Although= the field "certIdentifier" below is misnamed, the idea is to = say that for Elliptic Curves we need two parameters
instead of one. = This is what the proposed draft is attempting to say:<= /span>

     =
PreferredSignatureAlgorithm ::=3D SEQUENCE =
{
        =
sigIdentifier   =
AlgorithmIdentifier,
        =
certIdentifier  AlgorithmIdentifier =
OPTIONAL
        =
}
 
   The syntax of AlgorithmIdentifier is defined =
in section 4.1.1.2 of
   RFC 5280 =
[RFC5280]
 
   sigIdentifier specifies the signature =
algorithm the client prefers,
   e.g. =
algorithm=3Decdsa-with-sha256. Parameters are absent for =
most
   common signature =
algorithms.
 
   certIdentifier specifies the subject public =
key algorithm identifier
   the client prefers in the =
server's certificate used to validate the
   OCSP response. =
e.g. algorithm=3Did-ecPublicKey and parameters=3D
   =
secp256r1.
 
   certIdentifier is OPTIONAL and provides means =
to specify parameters
   necessary to distinguish among =
different usages of a particular
   algorithm, e.g. it may =
be used by the client to specify what curve it
   supports =
for a given elliptic curve =
algorithm.

Note the = this draft provides a correct example for a signature algorithm = identifier: ecdsa-with-sha256

The draft = proposed by Jim should consider the case of OIDs for Elliptic = Curves

 

[JLS]  I need more guidance from you on what you think you = need.  The curve would be protected by the certificate = itself.  The signature algorithm would be protected by the proposed = attribute.

 <= /o:p>

4) The = draft is missing a risk analysis or examples for real possibilities = of substitution.

 

[JLS] I am currently looking at this in more = detail.

 

Jim

 

 <= /o:p>

For the = above reasons, I believe that a new draft should be = issued.

 <= /o:p>

Denis

 <= /o:p>

---------- =

From = : smime-bounces =

To = : smime =

Date = : 2010-12-06, = 23:43:50

Subject = : [smime] = Fwd: Last Call: (SignerInfo Algorithm Protection Attribute) to Proposed = Standard

 <= /o:p>

-------- = Original Message --------
Subject: Last Call: = <draft-schaad-smime-algorithm-attribute-03.txt>
(Signer Info = Algorithm Protection Attribute) to Proposed Standard
Date: Mon, 06 = Dec 2010 14:35:04 -0800
From: The IESG <iesg-secretary@ietf.org>= ;
To: IETF-Announce <ietf-announce@ietf.org><= br>
The IESG has received a request from an individual submitter to = consider
the following document:
- 'Signer Info Algorithm = Protection = Attribute'
   <draft-schaad-smime-algorithm-attribut= e-03.txt> 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-01-03. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attr= ibute/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attr= ibute/


No IPR declarations have been submitted directly = on this = I-D.
_______________________________________________
IETF-Announce = mailing list
IETF-Announce@ietf.org
<= a = href=3D"https://www.ietf.org/mailman/listinfo/ietf-announce">https://www.= ietf.org/mailman/listinfo/ietf-announce

______________________= _________________________
smime mailing list
smime@ietf.org
https://www.ietf.org= /mailman/listinfo/smime

------=_NextPart_000_0053_01CBA14A.A88DACA0-- From johnl@iecc.com Wed Dec 22 10:16:19 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EF73A6B37 for ; Wed, 22 Dec 2010 10:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.656 X-Spam-Level: X-Spam-Status: No, score=-110.656 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrCzuVrzwREZ for ; Wed, 22 Dec 2010 10:16:18 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 761153A6A94 for ; Wed, 22 Dec 2010 10:16:18 -0800 (PST) Received: (qmail 80662 invoked from network); 22 Dec 2010 18:18:16 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 22 Dec 2010 18:18:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=7a5.4d1240e8.k1012; i=johnl@user.iecc.com; bh=ra0rNwryN1CVdJzUmCRBXX7qdBaVm7FKBvJi8+0LLNA=; b=SBXsAQ1s5ApdaVCkri2qFh/tIs9xReEmnG5Z8ZTEAwgHdwpXJZCxSvjo+TKTINR5mnlUxlZJzOEvmCnL99XEmeVQk/Cp6J1WcfNOFDcEZsrnX3EmSmpTuwn+KGvFOikycc5//XsWOZyZppEAXfT7LC7EbqZd3XZEdHsHRg6Zjhs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 22 Dec 2010 18:18:15 -0000 Message-ID: <20101222181815.1956.qmail@joyce.lan> From: John Levine To: ietf@ietf.org Subject: Re: Automatically updated Table of Contents with Nroff In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: barryleiba@computer.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 18:16:19 -0000 >You know, this whole discussion renews my total puzzlement at why >anyone would use nroff instead of something else... anything else. The good thing about nroff or troff is that with enough fiddling, you can get it to do anything, The bad thing about nroff or troff is that with enough fiddling, you can get it to do anything, R's, John From julian.reschke@gmx.de Wed Dec 22 11:24:45 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A3F3A68A5 for ; Wed, 22 Dec 2010 11:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.294 X-Spam-Level: X-Spam-Status: No, score=-104.294 tagged_above=-999 required=5 tests=[AWL=-2.295, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLe420DSyReJ for ; Wed, 22 Dec 2010 11:24:45 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 7596D3A67FD for ; Wed, 22 Dec 2010 11:24:43 -0800 (PST) Received: (qmail invoked by alias); 22 Dec 2010 19:26:39 -0000 Received: from p508FC76F.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.199.111] by mail.gmx.net (mp033) with SMTP; 22 Dec 2010 20:26:39 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18ZNflU2uQZnfirkSGclRXfW9tirdWVDyzNAPqjRG 0zkUNWkNumLbJw Message-ID: <4D1250E3.2020103@gmx.de> Date: Wed, 22 Dec 2010 20:26:27 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Barry Leiba Subject: Re: Automatically updated Table of Contents with Nroff References: <001b01ca0512$2c6be860$6801a8c0@oemcomputer> <4A5D9DBF.7050605@gmx.de> <4D10D92A.8000508@gmx.de> <4D1136C2.3030206@att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 19:24:45 -0000 On 22.12.2010 18:21, Barry Leiba wrote: >> # empty out toc.input >>> toc.input >> # run once to get a sample ToC, but page numbers will be off >> nroff file> /dev/null 2> toc.input >> # run again to get proper page numbers into toc.input >> nroff file> /dev/null 2> toc.input >> # run a 3rd time to get the right output, ignoring stderr this time >> nroff file 2>/dev/null > > You know, this whole discussion renews my total puzzlement at why > anyone would use nroff instead of something else... anything else. > > Yow! > > I know that not everyone likes xml2rfc, but I don't even want to think > about nroff. > ... Clarifying: the reason why I'm researching is that apparently some people think it would be good to have a replacement for xml2rfc.tcl that *emits* nroff (only - as opposed to plain text/nroff/html as the TCL code does today). Best regards, Julian From randy_presuhn@mindspring.com Wed Dec 22 11:34:15 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3F03A68A5 for ; Wed, 22 Dec 2010 11:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.927 X-Spam-Level: X-Spam-Status: No, score=-101.927 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqjcKkOR49pV for ; Wed, 22 Dec 2010 11:34:14 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id C40BE3A685B for ; Wed, 22 Dec 2010 11:34:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VlIlQz5tZmPgzWJWRkCON3YT+Tvcj+JfEPQprzJ5mHgKBFOEsu+Kc9ENUoG+3Rox; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.95.109] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PVUTf-0002rM-UE for ietf@ietf.org; Wed, 22 Dec 2010 14:36:00 -0500 Message-ID: <000401cba20f$95bea6e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "IETF Discussion Mailing List" References: <001b01ca0512$2c6be860$6801a8c0@oemcomputer> <4A5D9DBF.7050605@gmx.de><4D10D92A.8000508@gmx.de> <4D1136C2.3030206@att.com> <4D1250E3.2020103@gmx.de> Subject: Re: Automatically updated Table of Contents with Nroff Date: Wed, 22 Dec 2010 11:36:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888d26d9b9edb73dbfb08a525f04cda75b923adbb5e6e5860ed350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.95.109 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 19:34:15 -0000 Hi - > From: "Julian Reschke" > To: "Barry Leiba" > Cc: "IETF Discussion Mailing List" > Sent: Wednesday, December 22, 2010 11:26 AM > Subject: Re: Automatically updated Table of Contents with Nroff ... > Clarifying: the reason why I'm researching is that apparently some > people think it would be good to have a replacement for xml2rfc.tcl that > *emits* nroff (only - as opposed to plain text/nroff/html as the TCL > code does today). ... Though I happen to like nroff (I also like anchovies) please don't count me among those who think the replacement for sml2rfc.tcl should have nroff format as its *only* output format. Good luck with your research! Randy From ben@estacado.net Wed Dec 22 14:09:19 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0B93A6B37; Wed, 22 Dec 2010 14:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EMGXqyhm8-Q; Wed, 22 Dec 2010 14:09:17 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 4BFF03A6B2A; Wed, 22 Dec 2010 14:09:16 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id oBMMB4TZ026914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Dec 2010 16:11:09 -0600 (CST) (envelope-from ben@estacado.net) Subject: Re: Gen-ART LC Review of draft-cheshire-dnsext-multicastdns-12 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Wed, 22 Dec 2010 16:11:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70A16610-D605-4719-9C8D-3D1A678DB805@estacado.net> To: Stuart Cheshire X-Mailer: Apple Mail (2.1082) Cc: General Area Review Team , The IETF , draft-cheshire-dnsext-multicastdns.all@tools.ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 22:09:20 -0000 Thanks for the response. Further comments below. I elided sections that = I think have been addressed. On Dec 15, 2010, at 4:30 AM, Stuart Cheshire wrote: [..] >> -- 8.1, 4th paragraph: "250ms after the first query the host should = send a second, then 250ms after that a third. If, by 250ms after the = third probe, no conflicting Multicast DNS responses have been received, = the host may move to the next step, announcing." >>=20 >> Normative? >=20 > Yes, but in the English language sense, not an RFC 2119 keyword. >=20 This confuses me. The point of 2119 is to indicate normative intent. Do = you have some lesser class of normative-ness in mind? Also, see next = comment... >> -- 8.2, 2nd paragraph: "...the Authority Section must contain *all* = the records ..." >>=20 >> Normative? >=20 > Yes. Are you complaining that it's not clear what the sentence means = unless some of the words are in all-capitals? >=20 I'm asking if you intended this to be normative in a 2119 sense, which = would generally be indicated by a capital MUST. If you explicitly don't = want it to be treated as a 2119 keyword, then it's best to avoid "must" = at all, since case alone is a rather poor discriminator. >> -- ..., 3rd paragraph: "The two records are compared and the = lexicographically later data wins." >>=20 >> Seems like there might should be something normative there. >>=20 >> -- ..., last paragraph: "Note that it is vital..." >>=20 >> That would seem to imply something normative? >=20 > Yes. I believe it is acceptable to write a specification using = English. RFC 2119 keywords are sometimes useful for clarity, but I don't = believe there is any requirement that every normative sentence contain = at least one of them. I'm not asking for one for every sentence, and I am aware that there is = a great deal of variation between IETF documents in how dense they are = with 2119 keywords. But when you say something like "Note that it is = vital", that suggests to me that you think compliance is, well, vital. = As in the sense that it is "required for interoperation or to limit = behavior which has potential for causing harm", which would be = indicative of a 2119 MUST. >=20 >> -- 8.3, 4th paragraph: "A Responder MAY send up to eight gratuitous = Responses, provided that the interval between gratuitous responses = increases by at least a factor of two with every response sent." >>=20 >> Why the option? When would a responder want to send more than two? >=20 > The same reason TCP retransmits more than once: Packet loss. Sorry, my question was not clear. Can you give guidance on how an = implementer might decide how many to send? Why would it not be the same = for everybody? [...] >=20 >> -- ..., 3rd paragraph: "A client with an active outstanding query = will issue a query packet when one or more of the resource record(s) in = its cache is (are) 80% of the way to expiry." >>=20 >> What does an outstanding query have to do with it? Do you mean to say = a cached record? >=20 > See "Continuous Multicast DNS Querying". On your Mac or Windows = machine type: "dns-sd -B _http._tcp". Now you have an active query. = Press Ctrl-C. Now you cancelled it. We're talking about some sort of monitoring session, right? I guess my = confusion is with the idea of an outstanding "query", as something that = appears to span multiple "queries". The terminology is confusing to me. = (And that demotes my original comment to the editorial section) [...] >> -- ..., 6th paragraph: "There are no NS records anywhere in Multicast = DNS Domains." >>=20 >> Normative? >=20 > Yes. Actually, on re-reading this section this seems more like an observation = on reality than a normative statement, so I withdraw the comment. >=20 >> -- 14, 1st paragraph: "The option to fail-over to Multicast DNS for = names not ending in ".local." SHOULD be a user-configured option, and = SHOULD be disabled by default because of the possible security issues = related to unintended local resolution of apparently global names." >>=20 >> I have trouble imagining any safe circumstance to enable this. Can = you offer an example? >=20 > On an isolated network, or on some future machine that exclusively = uses DNSSEC for all DNS queries, thereby guarding itself against = spoofing. Some words to that effect in the text would be useful. >=20 >> -- 15, 5th paragraph: "While this kind of name duplication should be = rare,..." >>=20 >> Why should it be rare? >=20 > Because users generally name their devices intelligently. Over the = last eight years this kind of name duplication has not been a common = problem. Sorry, I should have quoted more. Why would it be rare for a multi-homed = host to discover the same name on two different links? That's more than = just a matter of users selecting reasonable names, as each link might = point to a network where someone felt they were being quite reasonable = in naming a print server "printer". >=20 >> -- 17, paragraph 1: >>=20 >> How does this historical note relate to IDNA? Do you mean to say that = IDNA is not needed for mdns? It would be nice to have some consistency = here. >=20 > Yes, IDNA is not needed for Multicast DNS. I think it would be highly unfortunate if we end up saying two different = flavors of DNS use different approaches to internationalization. But if = there are good technical reasons not to use IDNA, then it would be good = to state them. Perhaps the reasons you already mention apply--in which = case it would be helpful to state that. Would you consider IDNA to exist = to solve this "historical" problems in DNS that don't exist in mDNS? [...] >=20 >> -- 18, paragraph 3: "... specialized cases where the implementer = knows that all receivers implement reassembly." >>=20 >> How could an implementor know this? Can you list some example cases? = It seems to me that, unless we know of such cases in advance, it might = be better to just forbid this. >=20 > For example, factory floor CNC equipment, using Multicast DNS over a = private Ethernet network. This is a mostly proprietary marketplace, and = CNC equipment manufacturers know pretty precisely the capabilities of = their other proprietary equipment on the network. >=20 Okay (grudgingly--this sort of thing makes me uneasy, as the IETF = nominally designs for the Internet, not special case networks where = people are free to ignore all sorts of standard requirements. And = implementations intended for special case networks have a habit of = escaping onto the Internet. But this happens enough in other = specifications that I don't have steady ground from which to argue.) >> -- ..., last paragraph: >>=20 >> If jumbo packets are rare, why not just stick to the 1500 limit? >=20 > Some applications today need more than 1500-byte payloads. Maybe--but your last paragraph in section 18 seems to say that you can't = expect them to actually work. >=20 >> -- 19.1, paragraphs 1 and 2: >>=20 >> The first two paragraphs seem to make normative statements that are = redundant with the rest of the document. It's best to either state this = descriptively, or clearly attribute the requirements to the = authoritative sections. Otherwise if there is a conflict, it may not be = clear to the reader which text is authoritative. >=20 > Can explain specifically what part you think is redundant, and suggest = better text. I'm not going to be able to track each one down in a reasonable time = frame. But it seems like most of the 2119 normative language here = restates things from elsewhere. When that is true, which section do you = see as authoritative in the case that an error creeps into one, or in = the case that this spec is updated in the future? [...] >> -- ..., paragraph 4: "... it is *especially* important..." >>=20 >> Normative? >=20 > No. Okay, although this seems to fit into the 2119 definition: "... or to = limit behavior which has potential for causing harm" [...] >> -- ..., list items 4-7: >>=20 >> These seem to put requirements on devices that do not implement this = spec. Why would the implementors of such even read this? >=20 > No. Only devices that claim compliance with this spec have to follow = these requirements. No RFC can impose requirements on any implementer = unless that implementer voluntarily chooses to comply with the RFC. RFCs = are not laws. Let me try again: These sections make normative assertions about how the = "normal" DNS architecture should handle the special names. It seems to = me that such "normal" devices explicitly do not implement this = specification. They are not likely to have any reason to know ".local" = means something special. If changes to how unicast DNS devices should = work in the presence of mDNS are needed, then I think we need to do more = than mention that in the mDNS spec.=20 OTOH, this may be handled by the existence of the special-names draft = you mention above. [...] >=20 >> --, 25.2, "[B4W]" reference: >>=20 >> Is it reasonable to reference something as ephemeral as wikipedia, = even for an informative reference? Remember RFCs live a long time. >=20 > People objected to the apple.com reference so we changed it to = wikipedia as being more neutral. IMHO, wikipedia is a worse choice, as that link could change or go away = tomorrow. But I guess it's not a showstopper either way. >=20 >> -- Appendix A: >>=20 >> Please describe the conclusions, not just the arguments. >=20 > Arguments were made for and against using Multicast on UDP port 53. = The arguments for using a different port were greater in number and more = compelling so the final decision was to use UDP port 5353. Text to the effect of "...the final decision..." would be helpful in the = draft. >=20 >> *** Nits/editorial comments: >=20 [...] >> -- general: >>=20 >> I would like to have seen some general, non-normative, discussion on = how this all works together before jumping deep into protocol details. I = was fairly well into the document before I understood the = transaction-stateless nature of the mechanism. >=20 > The document is already long. Others have been asking us to delete = non-normative discussion. I saw people ask for that when they thought this was intended as an = informational RFC. But in any case, it's a personal thing--I personally = find the organization of the draft hard to follow, and would find a = high-level description helpful. My comments are not binding. >=20 >> -- 5.3, 5th paragraph: "To perform this cache maintenance, a = Multicast DNS Querier should plan to re-query for records after at least = 50% of the record lifetime has elapsed. This document recommends the = following specific strategy:" >>=20 >> It might be helpful to include a note about the difference between = retransmitting a query vs re-querying. >=20 > There is no difference between retransmitting a query vs re-querying. Trying again because you didn't see a response, vs trying later in case = something has changed are fundamentally the same thing? Weren't there = backoff recommendations for the first? [...] >> -- ..., later same paragraph: "...determined by the rules described = below." >>=20 >> The way things are organized, it's hard to tell where the referenced = rules start and stop. >=20 > It doesn't really matter very much. It is merely introduction to the = text that follows. Given that the phrase "rules described below" qualifies a SHOULD level = normative statement, that seems like more than just an introduction. >=20 >> -- ..., 4th paragraph from end: "name/rrtype/rrclass" >>=20 >> Please avoid using a slash as a conjunction substitute. >=20 > Can you explain what you'd like to see instead? >=20 For example, "name, rrtype, or rrclass" (or "and", depending on the = intent) [...] >=20 >> -- 13: >>=20 >> Seems like this should be stated early in the document, in the intro, = or in a scope section or applicability statement. >=20 > ? Section 13 states that something is out of scope for the document. It's = conventional to make such statements early in the document. For example, = if someone was trying to learn how mDNS is used in service discovery, he = might be disappointed to read this far before they discover he was in = the wrong place. OTOH, there's probably no strong rule about this, so its not a big deal. [...] Thanks! Ben.= From barryleiba.mailing.lists@gmail.com Wed Dec 22 15:24:13 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24883A6B97 for ; Wed, 22 Dec 2010 15:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.14 X-Spam-Level: X-Spam-Status: No, score=-102.14 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRqZZ2JWjZMp for ; Wed, 22 Dec 2010 15:24:12 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 124553A6B82 for ; Wed, 22 Dec 2010 15:24:12 -0800 (PST) Received: by iyi42 with SMTP id 42so4906789iyi.31 for ; Wed, 22 Dec 2010 15:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=zcQ6UNULd5wDwc1jptDwam0kViWpb89i1PA+omzLyS4=; b=LlwSTJZKH+Ov3tWZjyIY0S9ZsBnHoRhv89/QoxuZPbPMlRvWK6OTS4z0jV+O6zBBAE jccJSyEn1ZvSC0JsnskMw7FgB+49dWcIJ14VERwjBX1N4S1hUcMdJMDP46pn+8XPd8tf 11tJFBWF8V7AljCFGmTFDEb5iTGXi+OWCXwKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Rq3ZmfR+wVoTXY/CJoizTj86+zSZ8Tkk3YQzJKkEDK23PgEc3my4jYK0jQfjpqbgE+ qqKLWAtvjmL9bztiQRItl86XLM5tTT0y58X8jZcozqxqY32OIBDJgIOqCH/n3ovQKWFj 0wZEP0byiL4jBjDYPAHoKdakrk3L6ilV2Dz1A= MIME-Version: 1.0 Received: by 10.42.213.134 with SMTP id gw6mr7554926icb.476.1293060371179; Wed, 22 Dec 2010 15:26:11 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.220.130 with HTTP; Wed, 22 Dec 2010 15:26:10 -0800 (PST) In-Reply-To: <000401cba20f$95bea6e0$6801a8c0@oemcomputer> References: <001b01ca0512$2c6be860$6801a8c0@oemcomputer> <4A5D9DBF.7050605@gmx.de> <4D10D92A.8000508@gmx.de> <4D1136C2.3030206@att.com> <4D1250E3.2020103@gmx.de> <000401cba20f$95bea6e0$6801a8c0@oemcomputer> Date: Wed, 22 Dec 2010 18:26:10 -0500 X-Google-Sender-Auth: MFIR1rmOVDGRd_7L3eaf5IqtYMk Message-ID: Subject: Re: Automatically updated Table of Contents with Nroff From: Barry Leiba To: Randy Presuhn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 23:24:13 -0000 >> Clarifying: the reason why I'm researching is that apparently some >> people think it would be good to have a replacement for xml2rfc.tcl that >> *emits* nroff (only - as opposed to plain text/nroff/html as the TCL >> code does today). > > Though I happen to like nroff =A0(I also like anchovies) please don't cou= nt > me among those who think the replacement for sml2rfc.tcl should have > nroff format as its *only* output format. =A0 Good luck with your researc= h! What Randy says. Indeed, I understand why the RFC-Ed folks might want to have nroff versions of things for their use (manipulation/editing, archival, whatever). Having nroff output as an *option* is surely important. But the rest of us will always need the txt, html, pdf, and whatever. Barry From dotis@mail-abuse.org Wed Dec 22 15:53:20 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996833A691A for ; Wed, 22 Dec 2010 15:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi9IlE1tBLtT for ; Wed, 22 Dec 2010 15:53:19 -0800 (PST) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 8609D3A68FB for ; Wed, 22 Dec 2010 15:53:19 -0800 (PST) Received: from US-DOUGLASO-MB.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 3B9F0A94449 for ; Wed, 22 Dec 2010 23:56:08 +0000 (UTC) Message-ID: <4D128FE0.7080809@mail-abuse.org> Date: Wed, 22 Dec 2010 15:55:12 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Gen-ART LC Review of draft-cheshire-dnsext-multicastdns-12 References: <70A16610-D605-4719-9C8D-3D1A678DB805@estacado.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 23:53:20 -0000 On 12/22/10 2:11 PM, Ben Campbell wrote: > Thanks for the response. Further comments below. I elided sections > that I think have been addressed. > > On Dec 15, 2010, at 4:30 AM, Stuart Cheshire wrote: > > [..] > > > > Yes, IDNA is not needed for Multicast DNS. > > I think it would be highly unfortunate if we end up saying two > different flavors of DNS use different approaches to > internationalization. But if there are good technical reasons not to > use IDNA, then it would be good to state them. Perhaps the reasons > you already mention apply--in which case it would be helpful to state > that. Would you consider IDNA to exist to solve this "historical" > problems in DNS that don't exist in mDNS? The IDNA patch for DNS is not a complete or without problems. Although RFC4795 indicates compliance with RFC1035, the latest specification published by Microsoft, MS-LLMNRP — v20101112 http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-LLMNRP%5D.pdf includes the following questionable statement: ,--- [RFC4795] does not specify whether names in queries are to be sent in UTF-8 [RFC3629] or Punycode [RFC3492]. In this LLMNR profile, a sender MUST send queries in UTF-8, not Punycode. '--- Rather than making the same mistake, leave mDNS as is. -Doug From cheshire@apple.com Wed Dec 22 21:53:35 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354D43A6AA8; Wed, 22 Dec 2010 21:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.728 X-Spam-Level: X-Spam-Status: No, score=-106.728 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JklDp-DIyN+l; Wed, 22 Dec 2010 21:53:34 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 2F7C13A69B1; Wed, 22 Dec 2010 21:53:34 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id E59F3C1C6895; Wed, 22 Dec 2010 21:55:33 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-59-4d12e4552176 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id 3D.67.06193.554E21D4; Wed, 22 Dec 2010 21:55:33 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [10.0.1.201] ([173.164.252.149]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDV00EIA9SLH450@elliott.apple.com>; Wed, 22 Dec 2010 21:55:33 -0800 (PST) In-reply-to: References: <70A16610-D605-4719-9C8D-3D1A678DB805@estacado.net> Message-id: <4E22BCB4-6BA1-44A6-BBF8-47BC7F1B74D2@apple.com> From: Stuart Cheshire Subject: Re: Gen-ART LC Review of draft-cheshire-dnsext-multicastdns-12 Date: Wed, 22 Dec 2010 21:56:03 -0800 To: Ben Campbell X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: General Area Review Team , The IETF , draft-cheshire-dnsext-multicastdns.all@tools.ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 05:53:35 -0000 On 22 Dec 2010, at 2:11 PM, Ben Campbell wrote: >>> -- 14, 1st paragraph: "The option to fail-over to Multicast DNS >>> for names not ending in ".local." SHOULD be a user-configured >>> option, and SHOULD be disabled by default because of the possible >>> security issues related to unintended local resolution of >>> apparently global names." >>> >>> I have trouble imagining any safe circumstance to enable this. >>> Can you offer an example? >> >> On an isolated network, or on some future machine that exclusively >> uses DNSSEC for all DNS queries, thereby guarding itself against >> spoofing. > > Some words to that effect in the text would be useful. Done >>> -- Appendix A: >>> >>> Please describe the conclusions, not just the arguments. >> >> Arguments were made for and against using Multicast on UDP port >> 53. The arguments for using a different port were greater in >> number and more compelling so the final decision was to use UDP >> port 5353. > > Text to the effect of "...the final decision..." would be helpful > in the draft. Done. > Section 13 states that something is out of scope for the document. > It's conventional to make such statements early in the document. > For example, if someone was trying to learn how mDNS is used in > service discovery, he might be disappointed to read this far before > they discover he was in the wrong place. Moved to introduction. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Wed Dec 22 22:08:30 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE8A3A6BC0 for ; Wed, 22 Dec 2010 22:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMjpQPbWJbIR for ; Wed, 22 Dec 2010 22:08:30 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id A59753A6BBC for ; Wed, 22 Dec 2010 22:08:29 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 692EDC654F5F for ; Wed, 22 Dec 2010 22:10:29 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-68-4d12e7d415fc Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id CC.DA.06193.4D7E21D4; Wed, 22 Dec 2010 22:10:28 -0800 (PST) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_BSeJL8kv5NF1q0Jt0gaJgQ)" Received: from [10.0.1.201] ([173.164.252.149]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDV00F8OAHF1R10@et.apple.com> for ietf@ietf.org; Wed, 22 Dec 2010 22:10:27 -0800 (PST) In-reply-to: References: <20101026145701.22996.35291.idtracker@localhost> Message-id: From: Stuart Cheshire Subject: Re: Last Call: (DNS-Based Service Discovery) to Proposed Standard Date: Wed, 22 Dec 2010 22:10:57 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Cc: draft-cheshire-dnsext-dns-sd@tools.ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 06:08:30 -0000 --Boundary_(ID_BSeJL8kv5NF1q0Jt0gaJgQ) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT On 16 Dec 2010, at 1:02 AM, Pekka Savola wrote: > From my POV, the most important thing I'd like to see in Security > Considerations section is description of that app developer will be > able do the DNS updates, hopefully in a secure fashion. > > Some examples of what I wonder: > > - Is the expectation that you configure the DNS server so that > certain IP's have complete access to do updates? > > - What does that imply? Is it possible to limit the update > capability to some subtree? What kind of configuration would it > need if it should be application-specific? (I.e., if one > application gets out of hand, can it mess up all other apps or even > the whole DNS domain?) > > - Or do you expect deployment of DNS security (e.g. TSIG, SIG0)? If > so, how do you configure these in the app and the server within the > constraints of zero-conf goals? Do the same DNS subtree > limitations and caveats apply? > > To sum it up, I suspect the zeroconf nature of the goals of this > work is likely to prevent the use of TSIG/SIG(0) in DNS-updates, or > at least it requires major manual operations and/or it effectively > authorizes one application to update every other application's data > as well. But in some contexts it could be possible to implement it > in a different way. I feel a tutorial on how to set up secure updates would be out of scope for this document. FWIW, Apple's code on Mac OS X uses TSIG for secure updates. You enter the credentials in the "Sharing" preferences pane. What the user-interface people chose to label "User" and "Password" are in reality the TSIG key name and the TSIG key data. They felt that most users wouldn't know what TSIG meant, and it was better to have something familar (but wrong) rather than something unfamilar (but correct). Sorry. BIND allows pretty flexible configurations to control which keys are authorized to update what records. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org --Boundary_(ID_BSeJL8kv5NF1q0Jt0gaJgQ) Content-type: image/png; x-unix-mode=0644; name=TSIG.png Content-transfer-encoding: base64 Content-disposition: inline; filename=TSIG.png iVBORw0KGgoAAAANSUhEUgAAAxkAAAKTCAIAAAD63VKiAAACNWlDQ1BJQ0MgUHJvZmlsZQAAeAGt k79v00AUx792aAsoKqhBzO5SdUhR1AjRrSlOQtOiEKVGLTAgx3ZsQ+xYtpNChFD/AZYOsCAkfkgw dGBEMFAoEiwMCFSBkBAs/AEgsUBl3tm6hIGKhSed73Nfv/fu7t0dkHqnel5LBOC4oV8/cVxaOXNW GvmAfUghjSHMqFrgzdVqJ8llF/uxDYH9ejvFcn0q3/r88v7kevQ1E/x6Ont1lyAuj/o0ISBkSThk Jlxg3EhYYbwaeiH5WIw1S9WJrxBnfaUuEz8gHjUTfsS4kfArxl3NZLHviXOubruAuJd4RjcCjbhA rOuB5hDfI952nDblT7H8k5rnU2yK6VOsLtSTrfaAWVqzeGygrTwENoaAw+cH2sQGLXcLeHxtoH2z 4loJY1+CZn46TiekTWB4TxR9vw6MfAR2xqPo57Mo2nlOc98Btkpax+/GvrQR4TXwr3Gy5yQ78Ib2 QBaf0d85qUvslQPubgLL1Bao3VwDJm4AmXNArQAomxDzed6SGoLZftl2DUeV5ovx8P99nFaHzim2 A/RN22FFoX6M2oumX65zdhvVU5yNoLTEuWmXK5y9sNaP7VnKMtcvqAs1zm6ryu56nF83iiXOF9uL /bkM93Q/f9Bd6vvoanGR+/csucoZMmy4MOBAhYR5UJGSe0YeGD4IrI/TGxRvP8msMeVPC41L8fnJ be+yb5tWKM3RKzMkue14ndDws1LF1Y5kpelc7iiL+w3lmatev0uPWQAAIABJREFUeAHsvQmUJEd1 752VWfteXb1Nd8/0LNpXkDCSAFs8mUUGg20hgS0eIHaDjw0GYeux84GBZxs+4BnMYlZhQJYxgieZ TQJtIAQCbSNpZqTZuqf32quytsyqer+aKyV1ehmmWz3TXT0RfU70zZuRETf+EXHjn5GRWa5Wq6Wp oBBQCCgEFAIKAYWAQkAhsCIE9BVdpS5SCCgEFAIKAYWAQkAhoBBoI6C4lOoHCgGFgEJAIaAQUAgo BFaOgOJSK8dOXakQUAgoBBQCCgGFgEJAcSnVBxQCCgGFgEJAIaAQUAisHAHFpVaOnbpSIaAQUAgo BBQCCgGFgOJSqg8oBBQCCgGFgEJAIaAQWDkCikutHDt1pUJAIaAQUAgoBBQCCgHFpVQfUAgoBBQC CgGFgEJAIbByBBSXWjl26kqFgEJAIaAQUAgoBBQCikupPqAQUAgoBBQCCgGFgEJg5QgoLrVy7NSV CgGFgEJAIaAQUAgoBBSXUn1AIaAQUAgoBBQCCgGFwMoRUFxq5dipKxUCCgGFgEJAIaAQUAgoLqX6 gEJAIaAQUAgoBBQCCoGVI6C41MqxU1cqBBQCCgGFgEJAIaAQUFxK9QGFgEJAIaAQUAgoBBQCK0dA camVY6euVAgoBBQCCgGFgEJAIaC4lOoDCgGFgEJAIaAQUAgoBFaOgOJSK8dOXakQUAgoBBQCCgGF gEJAcSnVBxQCCgGFgEJAIaAQUAisHAH3yi99cle2Wq1FM3C5XIvqlVIhoBBQCCgEFAIKgfWDgJrH nbZQ61IOFEpQCCgEFAIKAYWAQkAhsGwEFJdaNmTqAoWAQkAhoBBQCCgEFAIOAmv2jM+xYJ6w1Jrh vGTqUCGgEFAIKAQUAgoBhcB6QECtS62HVlA2KAQUAgoBhYBCQCHQrQiodalubTllt0JAIaAQUAgo BNYQAfWumAO+4lIOFEpQCCgEFAIKAYWAQuBoEVBcykFKPeNzoFCCQkAhoBBQCCgEFAIKgWUj4Fqt vd7LzafZbC5qrK4vTu+WSr9oJkqpEFAIKAQUAgoBhcCqILDUvLwqmZPJBljf6ppnfMvlaqvVxiof hYBCQCGgEFAInMgILDX/bgAOtFrNesy51FJtsJR+qYotN/1S+Si9QkAhoBBQCCgEFAJHj8Bqzb8b mHspLnX03UmlVAgoBBQCCgGFwAmHgOJSv7PJjzmX+p0WzEuw1L6opfTzLleHCgGFgEJAIaAQUAgc BwQMwzgOpXRFEcecSy3FZ1dL3xUoKyMVAgoBhYBCQCHQpQgsd77u0mo+GbMVl3oy6KlrFQIKAYWA QkAhsMERUFzqdzbwMedSv9OCeQlUm80DRB0qBBQCCgGFgEJgDRFYal5eQ5PWW9HL5lJLYersz5cE xCJIhZ1DR5D0xJKM7VByysnnKJGybfsoU6pkCgGFgEJAIaAQUAgshYDbvTxK0Gg0ZAZn4xQBuV6v W5bl9/spgtlcJnRHkH3PzqGcJaVkstAqJ8HCU+tNszzgjtL6ebg4h45APoK7o3HAdTTzyqLN5mnk 0OPxLKpXSoWAQkAhoBBQCCgEjh6BpebZpb7V6fP5YE6saBDDk5jWvV4vk7LzrhgTuvAhRxBj5h0e vYXrNuUqcykAIlBbJ14oyFnQ5xQtJ6DTVDQDMax2UbBoqkX1TpstelYpFQIKAYWAQkAhoBA4GgSW 4kwyjy/MgfmXUwQIkyMjsL6FRvTEXCiHjtB5uDDbbtSsGpcSvJx4oQA6KB29rARWKpVyuVyr1YRa kSYQCCyK41J8WT3jWxQupVQIKAQUAgoBhcCyEFjqGR8rHYvmw4TOKVaneKgXDAaJWZeCkFWrVSe9 Q5scjQhL6ecl65bDZf8en5ChRavn8CRHIJlwVQSUnfpsNsspOQumrAoSaMhCobBo5kspl2r7pdIr vUJAIaAQUAgoBBQCCxFY7toE5IlL5DGfzONCp4jJHI3EjiAlOoeOsNCSzpRLnV1X+tVfl3IIkyNQ 4TaNeuLZnwisMxFoAxaoaAxIleACo1oUIAF94aml9AtTKo1CQCGgEFAIKAQUAkshILPzwrPOBD3v VLFYRMMs7KxORSIRHi7xxElSckrydIRF9RtgHl99LgVSYCfwdQrz9DzaQ0MLSTM4j2kdQRB34qXa EkLmpFGCQkAhoBBQCCgEFAIrQ2Cp+XcprsNqCCyKQHHMxWzXQUYgH4c8OYKY5Bw6AnrklRm8fq5a NS7lVElYlHPoCPP0wltB0AHRIV7OJZ3CUmuPS61jdV6rZIWAQkAhoBBQCCgEjozAUu94LcWx0LPM wVXEyKFQCC7FpNyZnpndmeU7S19K35mmi+QludQ86uNUyQFFEhCLQAKRiYHVkcHUkTv1DnXlQidP ZFqFzWvsXJO9UwcPHmQVMZ/PcyoWi7F+ODo6Go1GoVY8keX5oFk2Nie8rnoxXWlUgv0Nt083Z8JW ho1wmbt3Fu56oHDo0KH8zFyrmNzUe/KO7duf+keV3pi9ZXAym9vRv8nOpCu1fHwgnklVe3p6yJCu YJomq5QTExOzs7PpdBqTsJaNdX19ff39/fF4nKKplNA72bBFgnkV4VAFhUC3IKAbdsN2GbrP4/HZ dq1czWl6LRBwh6zoIT2Hv+yv9Zruvum4t99VPCuTvidxUsCcjDWyLZeRbYU8sQFXvewqp/Kh8mh+ lBE9Fh9j7+OFwQuJJ5ITIbNpVi6qevYlQnPR/GjV3F2PzPmil+n1h3MNX0XzDUR9Rn68kpkKJocq 7ljIzuXKlhaIe8MJcvBo9Yi7adiVqhHqFkiVnQqBrkOgkwMdjfEy3TNlMwNCoViXYppGZnLECUhw 8uSQPLlEhM78ZTKV9OgdoTPNOpeN97///csysRMFQHGudWQRiEUggcjzYvaec0ogI3YS0xg0CWxm fHx8z549JOvt7R0eHobHkH5ycjKVStFUsBneHWi/LOALaY2KVS/XW7pp636PN9wsV6b23X3Td/b9 4q7i5FjvYPzkp58xcsqoW2vlJ6fu+eXd3qAxNDrs8bqh08we7oA3Xy7HQnE4E60OUaNQOBwG0MAc DgwMQKGwcPpwQEnRUCg0pBdApHad4DjIKEEhsP4RaGmNZoO7IB67M6p58t7UjXbcqvm9AzHTLMf1 eNMTGivMaPlJ875f7XQl/S4rZDSKpVIg1jszlw4YzZi3Zbr1oMnHTbSCr8YmCleK3ZC1RtId010H 9ta27gjXq9Nx/w5PoOWJNkql3vT0w4lkL6MpMzvp1hqjW7fuHZ+uNvWoT4/29DZcRtEs81KKoTUh eF63YbuWvP1b/yArCxUCGw8BlkhYgJCYqZklCeTOanZOiyI7sSMIAeDQ0ThCZ1brWV4hlxLqQMUE Aid2BKmzc4gwL2QymcO4PY6dZEUavCpbqeBMrAmh3Lx586mnngqbSSaTNBIaaBYJaC3oFKtHls/f tMsNq+rxhcq1VnuFMTNx4Jc/Me+/M6lbp5265WnPu2D7pRdtO3PHkM8XrTcmD96bnR2vlQsjIyPe cKjUsBtuN/NGxBsolUpky9IURAo6BaXbtGkTpZNycHAQug37JnsshnVROqYK40aD5djmCMgqKAS6 CAGWWVtNjZdAbJu9DprXp7c0u1Yr79k185LXv/ILH/8/133t23v2j7/oyj+JN9Kf+qurbkyHXvan L/C32B6hJweG8rl8MuTWy5l009unu70+V1pr+n2RHpat3K0xs9TjseP+7XXrwK23/t8vfvEnF1x8 Ybkxk531nLIj2bTrmZnJ4U0DBbNSbRr+SJyPzbWsitXU8oUiX6BL9sT1VsOu10LBYM3+7f1bF8Gr TFUIbEgEZMpjWoRFScw0jdxZWdIsPHSUjkAaZDnsFDqvXc/ysm/yhDQ4sSM4lXQ0nQLyvEB6RwNw IqOEoORY3S+XeZTGihRsJhwOy0b1RCJx2mmnwWlYmkJDMh75NdwsGHqatu72+QK25rHK6cd2Ttx7 1/ZmdiC5aWDEY4cLpcoBV3vFsZQMaC+4+OSf/+qhgz+9aevWrYkLkjWr/Wgj5o/WalW6AtyI5Sjy l8d5PP3FHtgVhrEWxfIYGs7C8zADDZnSb2R1Ssg4FXGgUIJCoFsQaGmMI51B2e7GrvZNQqPe4PH6 a1/zplMvfdprPvjhQ3fu+fVDj02O7z03UtveH8hsO2U6nd8edBeKxUd/cdc5Tz2vljrkbVQi8R3N /EQ6W9J7t1ZMno6nGUG9sVGz+LC7Xgi6zVqleOdv9u5Pm0OD+hnb+qfzY1Yxta0vVqkWy+1BGrTL xYGY36qHzHIl6Pf5g6FcatbrMYKhsFmr83ygWyBVdioEThAEZPrGdRCYEIlllUGqv9ScKPP+hoFo 2VyKmgs0Al/nociin3cWcEXjCBw66TszYU86gSdrLERBbtgqIW9dkoZdU1wFm2FNiG1MkhL36/V7 yjyLqFtej99br+TG9wStzLMvOtMTClWjrrw106g0wp5wIFjzRptuT+uic7Y+vCeb2fOw59TT9Fhf q2rYuaruZX3KzcoTzEm2RrHoBWPjMSJNLq3OcpQYQDKWx2B79Bh5MigJMFIFhUA3IsCtI33YzVq9 S+PBNeOUgcAQazUr17zt7YNDQ88/45I3R3v3Vh7NTD7SG3XX6nVucrLpqXAwdObw9rnZOZdZ8Lob ubTd485XahlX65ymVQlH05OTY3PVZMTr2uRzh3zNl1z2oste9UePHZoIB2ZnH77b3n6W3zIzE/t8 iU2R5OaDs4VTB8Pm1O6CER/aNJhJzRqups9oRSPh6dm5aCzRqD3+rnU3gqxsVghsPARkZifGaQiR knWp9qzJ/dnhzekikIY5nZhDYqAQgXgDwLJsLiUQEM8TwKJTKdCIxok7iRRKQRChMzFKNiThpuFM eHO2T0FxOCQNz+BkrxJcCpnQzqFSdeneltUoN8pen+HRrUY1feaOvlZPwOXzGF72gZStSrqm1by+ uidhV9yuQfdAJe/ZPT092GzwyzWa1fKbzZbPBW0SY1gPY82JoimUolFiOQFL0LMYhoblK2IMQC8C iREIUh0VKwS6CAFGEj3XpbMk1X69ma/v0bE9Xk9Tq6bG9/f1JJpGa2p2rhFxJXrimVzK57K/+oXP 3vD5j5qlyoc//olLnv8CHpV/6+ufe/fH/iqsjSfi2hVv+epVV72yUd75n9/56kTrUEV/5IZ/ecVt 3/vAbY/8+tof3PKpz31oYt9D91/3w/tGX7S5Mf7Vj37U1LQPfPk/Tz3vGcXM3jOirY98+0ef+Od/ bFi1173yLx58cOdVr3vDhc96drZohjwbwe12UcdQpioEjoAAM6DMejIPEktw1qU4FBlBEktujiwC 8RFK6YpTK+dSVE9AFMGprZCJzlMiz4udywVEJz27lNCAPjGcCeICk0VJengMhFcWhyQBeh+bzsu1 gNtX0wzLqrU89UajuHW0JxcLDIRjgXB42Mc2WDZFWb64xsZ0n2+kvsuMhKNayg4Fw7O1mq/q2uSO TWrt713B1aBQPEwkZ0wS2oSSfoAZLEchyGKVMC2MRMOFCKSXShGroBDoMgTYcN7e5cDLGAaC3bTc HneyJ3l+PP63b3zTs1/4gqtf/W47mLD8dtYse4OhGz/5T9tP7f/i5z799Wuv/V/vevcPnnGJVqtG +jZ/9ds3n9V78ze/+c3P/OtXzzn7gj84pbhr97033Dw2eHHfN75xQ8D/iOF2j8/MzWUyZyd8983s +vfvZc7Y4frSF/7hv77/079969tuuv2XId2+4Yuf+Ni/3n7tN78R9+t33vrjB+57MBYJw/R8wUir 3v42oAoKAYXAekCgc9ZjKuSQWATHPEkjh8jOXOkInEJ20nepwA6JFYZOgCQLNKKUGOVhxZKRU3Bn ehaHYC0sShHLUiExSoJz6CRA6eddIasRC4Uj4XCz1bS5k62XvH6XvmnAiMe1QEjzB6P+QNBnuPxN LWDXoiHWmoa2jAZ8AcqtHc4hYfgwBuZEoB+QP7yNWBpY1qJ48IeGZKxO8fgPgoW8AXqA0wpKOJER YCywc5A/BhFv9BG8Hm88Eb/jR//9ofe87cff+e/LLvuzn9x2e0t3G16/2x844/cvvOmG/7zo6ec/ /3nPtSqlYqUWTQ4854V/snXLST6/bjcq5dmZraMnlyt5trH/4Ysv/8YN/73tlNM2DW3KF/L8qrk/ GAiy09Gc8T394m/91/fOPPOMCy54OqPu4NhBd8v69rU/ufL1bzrnnHMuePrTX3bFFeEgP+9VgUuV q+2lYhUUAgqB9YaATOLERw6dZpOy87Db5SXXpRyWIBUWgBatrSQQKirJFspoOgPJ2AXF8g/LSzzI YxEIAXZCoSSDtbDqA3Hh+RoP8tAgECOTjE3fslOKVSsuqYcSvPDjaQZx6Jtjfi11sGfTlvF68wzd 3QpqrhjZGQ2XX6uHmAZ4pDeSuk8bHb4zPVs9c1ulaG+PJouN8n2tg626n8zZBcVrCJROcWyHYgkK IkWtMZizsjxGoayN8XIfZnAKM5h4UGIwgVOLoqSUCoH1jIDPF2w12+9Y8MukvJFjWe6K2Wo13HdF z3r1X8Rf8ns73vGxz33sU+/3j37m9FPCpXRq8FWvOpjJBDIP+WdneSckVdR3JNO3feXv3vx5j7d8 y0hIC2qXBIsMqJoR7ImPnG4+NhUtPdIys8P+kzT7p5VirqGNNrTKqRc/J121o7V6pF7nRVx3xaX3 9lR07Vdp4zWBaDO1t1pJR/sHbW+0VDKDjWrT613PMCrbFAInFAJM2Ux5xMyPzJKsbsiELrM5SgKA EAujYGJFEFmUzuGiuJHnonrJYdFTa6Vc+brUPIudOotA3CnIoRM71zoaSYwevgIjoSVgKnAUVoBk QYjVIBarkGkMWaNCw0M3b6tuNGoeV8PrdpXMsq1745u2mq6A4Q9rLk+dJ351y+3i+aDu8bYMt6UN n1ytuxouTzSR1AxuoHmT082bB07rUjrlSunwJErBJMoRw7AQ2+guTj9wqoBhXOhUTQkKgS5CQHYf 0vm5nRCZno+XzGfnDo6Nx5IDH/nf/6Tl041atVQuu/yhcjYVYAHK62edtl4rxyOhhx56+B8+fvsn vvqFifHbP/TBt/GoMJNPb9t+yqGxqZ54sGVbiZ5kU/cUSmYiEg753JVqvdJytSp5lpJdbl+VRTHb 2jSQnJmdKda0C846xUxN181SsVgaOzRZqlreULShKyLVRX1KmXpiIeBMhTKbdx46MoiILIIAJOm7 Hawl16VWULFFMXJAXFQQQJ1THApDgsqwJgSRYkUKliNkVogUvh4uBZWB6LQXivhQZ7PhafLlJ80s VH1uX2zzaVP7mlMzpXh/JNDfo0V5MFfX6nxDWdeCHq3gn0gXXIFE7/Bo02VUKnyYyseOW0oRJgRt Yl0KA8if1wmRKUvQgEVRtNgmTyEd+7GQWsihJFaxQqCLEGAoMfS4SaCHM9B42D03N/fYY49Nlfef P+QKNVvfvf0OLTkQ8RnBaMx0h1xmhk9RVTRPXXeb5Vy5kLJNkyVZszh9189+/eGPfLxhPH0mO5bP 17ZuOfXggYfiobNT6VyEr0OxYFw3LTMfiiXqvp5eT71qFsq2VqjxaLEe8LaS/T1/8/eve9X/945k 6pWn9xjv+dC/8DS9rnndwVipUAi31O1KF3UrZeoGR8CZu53pj6lQZkOm1M6zTgJZtuBQEgCQaLod qVXjUoIUcDiQiQCsouSwMxwGvL3D31GiAVP4SnuxiccLjQZ0ClkenAmhkRUjUkKzZCu6v1nzu1p2 tejxh1gsKjfc3tiw1lM5mHqw7A4MRzQ/q1JYxYf/Wk0+oHNgb3Uqz+LVcCg5kK/qZrUWMljf8jda 7bVK8qdEaWPmFTQcStGYRLlMORSNSSilB0hFiJ26I6igEOguBOjSGEz/p58jE+jS3Da89y1/rWnV iKax5fvD/+ff/sdFv5ef3JnTwz2uGp9Ib/giZtO1ZWTQ76oN7jjpT19ywbuu+rOANvOut7zmw1/+ 5V9f/ZqffuNdpZw1fHLIMnMhX9AddDdd7ohPb5azpqc51wh5ChN+/czEpq1GKN7Xl8jMHjzpjKEX vOzK/73lkhv+7ePViOv6r376r973/4cTfWOTM5v7eu38dHcBq6xVCGx4BGRypJoyG+JGZHJEPy/g WNCQUiZZJ5kIXQ3U42+fHaEOUnNBxEnmHDoCtIOzHIKmE6NBL2nAV4AmRr979272S4GgPF6FmsCi OCQ9ZIVL8OMk4xYZ+sIpEnDfjMC6FHrSkJg0UbfN8lKhXA9GeyjYLBYiQT4yVban7/F5W/G4e3Ag HO8Jaa1GKpNJZ7L5VG+tZQSSQ97YQMU2KlXb7dJ5WtHSNagbtrEcJVZRopRCcdiD/U7gEGPoFqRB 5ipOkYwL0SCooBDoLgRYjqK3YzMC/Vl6PmPTGwzyQ3l6wzb80XLLk8umvVb29JHELn1refpAXLcH e/vGptO21gr7miGjvt/Y9NRAq1mtTwcH8vlcX2lK93knI4M9zVp2ZjzgdsX6NmUrfMSqZVQzI1FP bui8Qw/da5i5rVu2mbZma3yUaq5VTdvhM7ZEWTdOPbzv0HMve8W/fvvm4cHeQLPMr9Z0F7DKWoXA BkaAeRCPwYqDzIB8A3LHjh1M2TIPEktgrmRyJHAKNBDQOzEaEogeZaeAvGiQZIueWivlqq1LUQFY BUEEqY9oiPHOjiwCGgKAOnoOAUgYFYhDqni+RjuhkVMkRiawIiUEizRVfqOCr+C0ajwg8Hj9FM8z v0A4MXz+Jfn09PTMwYNTM7qr/R0pW9PrtvukbeewPYpfMC5VLC708xUrs1qvNQzf4183oBTalZ5B QZQuXQQjETCDenGWgKko0Yj9TtNyKHVXsUKgixDAJ8ooQ5DOj9C+k3Fb+VK1UKyPDPekpw5FI/68 ad9/KOMJexm6NSPw6MR0bzxSLuX5WNtsydYTBbsaHx9LTcVSA/0D1ZQR0H1aM1fKFr2BkCcYrlpN fsivUjbrNl+d8liP/Toa8Gv+oclsMRLylQpzuqd57649f/PXb3zLq68ozOz/0vd+dOmf/c8d20ZD bjvcsvjGXBehqkxVCGxsBGS+k0mQGB9CkElTpkg5hZKJFSg4lLlSBGKUzuzZ1VitGpcSUAQsiUVD fPSBC8Wnw2PAF5kGQCBIJghokLljluYxG0ag5fb4ArzOzYc7+fVTWoYHFb85kEoEQ/1bz4/zxU6W xxparalbLUNvBWrFnK1rVtOCHJE9jUt7UiIMSdobmYAxFMeGLVG2+8hh5nSYShm8h4gZpHFC28on PjflKJWgEOgKBLizpD+LE0TGZm5U2ISejPD7wrFIcsis2AOJeKmY8ocjnkRfc3bKbnrq/GiT1fDk Uo1y3hfucYeSVn12KtWIRPpSwel0cWKLpy+fNZsRy6dr07lC1BP2aHajmNIaVqR/c7rqStZmK0as ooWrFX4L0OThX6gnsePscz/8kY/lD+2KjZ58y01vtSODPkMrzIzrrmLL39sVeCojFQInCAIyNUss sySxTJqdp5AFEBGYKxGIUTqnuhqxVeNSgoiA4kCDsFRwYHUSiIYFJ1oCKkOMTECPjJd3uA6ybAmH bBUsfjtV51e77Co/9VXjjTtNN6x6PbZpKx+PShXLhYzp0QzNCDQMP6/vuZr1VL4a6Y16Al5ujlt2 xWi5eFWvarc/sE5x2EPm7acbh9/dgzNJuejFKuyhB6BEQIncGaQWKlYIdBcCPDpnFYohIK9WsPQr waoeagUTc9liUOfNu1R/b2i6Vp/LFLbprarLXTO8ib5+d2kqGg3VXW6TF+38WjTSk85ljZ72eAmF YnrTyNuHauVGT3KTbfhSs4dGol5XU6/U7HzVPdjk2wsBDz9zEI7ZuYNej14sFQPR2KUvuMhXe5bb zqfL1ejwyCN7H92aCHnNXKG7YFXWKgROGAScqVwE6r2ohulSTiGQAFk03Y7T45U5QjWktg46goIc QnFEcNKg6Qzo4T3EKBEIIqB56KGH+vv74S7c/gov4SxkFh7DPipuiHHl+Hd5kw6nLKTqCHbOO0Xz wId4HYldUBRHbhRNGonnJT7CIZmwNIVVmIdVg4OD8niYHwpEj4YX+oj5KhUpCcxGFCGBbKmRBGw4 Qinr/xRVWxQH2da2/u1XFioEFALrBwE8Km5fgkyl4jM3xrS6fnBeriWCP7OVTFgciobpz5FFIzlL SmKaknh2dvaMM84gMfM1yVAy/UkryzzI/Ij+8UnxiX9oaH1iCaifEB/feCOHlIiw3Bodt/Srti4l mDp2c+jInUKnXi6RGIzkFDfHqVSKNSH4k9wlgyyfzWRTW2c+v1Nm7idPRmwul+PznkKGiGWD7e+8 3EkAmeN3lLGEH+kjPnjwIOSJQNtThHBBLESGUWE2TEt6CInJhGSymkV/cvLsRmEpHDobtBvrpWxW CCgEjj8CvOIjnp95l9JlspRJ9Pgbo0p0EBBOIw1BA3FIAyEw08mhtJpwGmk1rkXp5NApzNM7h45w hGs78+kKedW4lNQWjCQIRk8c/XaPtqOZJzjpISWQD2ZuEtCQrCpxCuVyuQiciasgT6x+ZTIZhi75 CAdCOPoAQ6LHYAmf24HSJZNJCFM2mxW2Rw+jCGyjw9H/4E+kFC5FfPSlrP+US+EA913/xisLFQIK gXWFgEzGziwgtqFEs67sPNGMcfCXBnKqL03D7EZwGguBuc9pRBFIIEJnDk62IkhuC5M5xXWjsGpc SnARCDplB9l2IzwRSCCipHRilMjwFRaT4CUgDn0hZrGHR4HLwpeHejx+guJs3rx5fHycQygaC1Tw qmXlg0lYQo/hgSNWSZ486YPkoccqDMZCkvE8kQSwKwqFxqGnIE5xLfFy7V+Wkcch8RFwOA6lqyIU AgqBjYQALh2vKIF64S3F+eMtN1I1u64utAhtwRRGcyCEXDHqAAAgAElEQVSzIkCLEDN/oXGUTpNJ eqf5SCCyJECWIIcOGo5ynt5J0I3CKnMpB6PHIfxd/w63zuMPSqWdiFnp+eUvf0lz8g0qSAmtBRMi p2XhC/Vh6YjVqcnJyZNOOgkixaM6MlnBOgpLMjzgg9Vt27btmc98Jk8byYqcsQpGRYZki80UsW/f vttvv50qYLwYjPHSF1Euy/51mHhRHABhHZqqTFIIKATWMwJ4SDFPPCROkrtQ5mweHaxnsze8bTQE MxezFdNZZ0AjMxorCARwEL6FksBZ2k5kJyaNI4sgGgdDR4mGbuDou1RYNS4l9Xew41BkaQNiCSgR nNhJ7ySGAP3qV7+CCV1xxRVXX301+53JClJMGy8LYpqW9OTz4he/+JOf/CTdQkYppS83Hy4ht7vu uuvGG2+88847n/rUp3Io+RBjMESK26z9+/cTf/GLX+SsBAoigQQ8xbLKXW+JqREVIZ6HAw233kxV 9igEuhQBZzRtgKnlyE0gczb1xaXgQnHOBG7MeHRw5AvV2WOKgLQIjQJV4iEMr7HzlpU8jXEWCDBA pgMEJgUuIYggk53IYqeclZhejYBeBEcpKbs9XjUuJbh0wtcpy1liB3pH41woAo/J2N/9ute97qyz ziIH2IkMNs4uC2tYFCtGrB5BcRiiDF0IGatcK1uXYv/WRRddxGj/whe+wHsKmIQ99DBi8sQw3MHD Dz98+eWXUxBnCWIth/QbCcuyfx0mZl1qURzWoanKJIVA1yEgDhAP+YTDaP/vulocvcEsb+A2ccj4 VTZIIHAoG1uPPhOVcnURoBM6vY6FDGka5jj2xjAXC6miRKHCpDzChE4ycus0zzmUri6nROkU2pm+ u+RV41IOLovitSgoAqjEQCkX8nGBmZmZ008/nUtgxDQVLQojJiyayVJK2Ax0itWgTZs2Qa4ZonQF RqxQn6WuWqiHgXEVy1p0I+gdtglPwmAyxDxKocNhJBvSL7nkEmqBUp4uk1ubVR1+5IxmYeZdpFkK h+W2SxdVWZmqEDhuCIgbxDu96EUvuvvuu3nTBd+FkyEcNxuOZ0F4VCqIa2V3LGtR3PTiJ4+nAaqs pRBwZmQIEzfPBFLSXnRFnsDI1Eaazp7JoZObyEslkLNyLTKhMx8nk24Uls2lOnlop8xI4LATIznb iZRgh14CTSUtRBpaiKHFxAzvAUfZ2Y2eOxXScCFnuYoExBySRnKGx7CUxWiEeBHDb/BHwpoZn+Qj L6AJhUJG4H6IMYzMnRCbn5xhTBXIn+IQKA6B3FjTgkW1HxEf/uEhTiGQrRjAWS4hE7ga9gh7k34g 5mEqCQhWXQ+F3an0bCTip1LpVD4USvCzG76wu5IthbWKKxA13T7WuAINze+xc4U8/IyfV/b5/Nls PhwKW5bt9wfMcvu7VhSBVVhO/nA4tnMhgAP9Hsv5yAe7u0CSL3XVizWX7tJ0rWrxYUXuBA1+5LlS qza0aH/jkNbSUqFRw60lSjMgOhXoTzbay2wLA9VZFAeKW5hYaRQCCoFlIcD4xeEwxLjqggsu+MlP foKMo2DcEZaV1bpKjL/FTeFIcRTiDHGV+EkcKU54eHgYf44fljrKvICDdaog84JzqIRjjYA0xMIu t2XLFqY5Ztt9+/bRmswsNA0NSqApCTKbyyGXyzSKEoM5JHAKmSZGnlcL0bQTHQ7OJRzNS7meD3/b a5+klYKUk8m8w4V6SUDs4IVMIKUIMq7kLBoask1nDr9SxyFnJTE3cHgcaVfoFDKBhuQsDIZkNDMy QWT4FkyIwUzOXMUwpkQ0DHiUtD0CeggKF5IYJk4CMUbyIZbqyKHIThqKdjSdQq2GPbXeZH8qPYET 6e3tM0twPs90trUp6Hf5/BOP7j+Qb4yefBqbuYtTk/HhzdUaTK79KQcssWzL5/dXqm07MQl7cLXo qSNESgionGIxlo6OGfA8+KK76QqGI/VaNRaPzczNRj1Rs1xxe90er6FVjUOPPpaKh7Zu7W1Y9kOP 7Aqf+4e2a3H7KdGpYycODhqdlVWyQkAhsCwEGEeMZWYprjrzzDP5lPEtt9yyMeiUuAjHUSDgZuX7 Mngq8fB4rUceeWTnzp0PPvggfmz79u2nnXbahRdeiIznIY0kWxakKvEqIkCTMaHApQjtpYHDG2Zo FJleEWhWJzjlonHkDS+sGpcSpOZhJ4dO7AgkRpbQKaORQ1oLQWKUDCdhSPgaGo9bHKERMAbIEGd5 WY/BieuhUeFbnOV+iLMEOoGTGzIkiX5ADjxM5KOg0BrpGRApmBN6SBslsvZDYjgWsgxjyYSy0BAw z+lAThVII8nQzAuBQDRfSLdc9Xgifv9991933bfnZvNmqfa8y/788ude5M8VP/f5z46e+6xzn3ba 1P6JHds2mWZldnaGumBJIOBvMyfD5fd7MpksN3boYVScoi4sR4m7oa8LR+SQ6pOMs3R7rWGbZml8 8tBPb7/tKeedt3l0tFquGySamLjhhhuqI9OXXf7SViGPfIY98JxzRuZZ7hwuioNA4aRRgkJAIbAC BA47lfbSFNey87KTTuGUGHoy+laQ89peQr3wNNiAQBXkEE+Fu26vmtfryCRgHY7XergZxutyZ4gT hlfhzf74j/9YZuu1rYUqnbZjqqUtaDWmHhqOyYXGAhlpIGlc6cYo5RDB0UgH2MBIrhqX6oRMZGIH ykXPMoRED+6OTMMg41OI4SUk4CwCeloOt0ITstxCzgxC6AJMYmpqas+ePc973vNIQBtDgKAakjOJ kcVDIUPIyIFr4WQsaN16660sXQ4NDfHMHl6CEspCJpRFJsQkdtalsEEsIWfpEFKEc0gCKUjOzovL ZnZouC+dmb37F/d+7dprt2zedsVLXj43m73t3vvtS86v1avbtm1pao2D47nBeHTmsd1GbKS3d5Bf DIT6cw9g27XcdIolKDGJGGeEkSCAAwIKzAAWbKYubOqiFlhO3RstyyznLbv2gx98/5af3pYrlF73 +jekM5lowBUfGIBQliI8FtT5HcN8Pjc0PHyEKlAjaZROHJzqz6uvOlQIKASOHoF5zsShUzfffDNO ifHOoCMcfYbrJyVOA2OoIPaLA2Ftg4kZ34XLRcO3b+BSeLNnHA4IVJ9luZtuugnnfN5553VpxddP Ezx5S5jdmE1oNbgUMw5LEjQo0430W2lfpw9LW4ty3qknb8m6zWGVuVQnmo48D1M5ZAiRgJhxIimR CdI8zOjoaT9OkZ5DBh63KQjwBlmLgkURWBOmaVlhevaznw2B4Co4BClZHOZy4VLE6KFZZE4a+oRQ jUcffZQ+we4ivr3JN6ikdIojBwJpKJRr0SDLWccklGiIxUJiKY6UKBeGZsO1bx+/P+PxB/yQtZe+ 9KWjm08qFqpnPfMZfr3idrnrVrVpVXuS8XJuKuL35M1aKBRla7uhG8VSbmCg125UC8WMzxujFhBB WODY2BiMikNYFDQRU3FS+w+/t4gB2EPs0y2e39Xr1V27HulJJnc9smd2Jh0IhsghqhfAhJrmcsWw XTfNMneEzUj7qeLCIBxrIQ4CwsL0SqMQUAgcPQI4EIZS52hy6NSPf/xj6EWX0ilxjFI78e34JZwz DwRwJuzvpMr33HMPz/he+MIXPve5z+XuDleGQ0b/ox/9iM/1waW4ZCm/evQIq5RPBgH8P/Mm0yiL DswyzLy0CBomHVoKPbETKIgWR0lMkEMnfjJmrOdrV41LCVKCnQOfc+gIncmAXvSMMUcmAbLwAIlJ Q0MywCQNSm7U4EAwIb6eIBvioBSkwePQ0pAtZAJZ0dK0N7JwKfwRi1gwJASSMZIhE/v27Ttw4MBj jz0GnRoZGaGLUARpKBeOwiECRRPkFAIapyIIIqOnIDklys7YcPsHevortQLbvbGTpaNwqIct4I2Q P1NOJVnnbtlsh7r77p//19c+38yN//U7Plmp1KJRdscXvvq1L+986D6vzzj33LP/4Fl/NDo6+uUv f5lPM+B9gA5XC6F85StfiXkAwo3slVdeSb2oArHLqNqN1v0P7MSwS/7HJd//wc233nrHi//kz/yc KFQhUi2tRcq4m/uN9o8e2v2LdwmpWhuFBTh0VlPJCgGFwAoQYHhK6LzWoVOwiu6lU3gMmWupGnXE uwqXQhCPygcF8WMXX3wxa+rit/HDz3rWs372s5/t2rULJ4a77oRFyWuIAPMm8wUNR5tKswpFRn6i C7f/i1Ja3NGvodnHoejFJ84VFAxenVd1HorsxJ2CyAw2BAnSJAwzDonJE4EBxjoK+5loSJageKLH z8IwxiBYDD/aVfgTzADmREuTCdeSrTNc0ZAJh7QxF8KxnFPSLSYmJsiZxZ5TTjlFHgmTgKxYhRYb xDwxVWoqGjlLLMVxlZydFzfsZrVWyhfatdgyOvrZz372qede8IeXPN+qeZ66fXDskd+wKerWu+4a n0m96c1vvOeW733uc1+4+uq38VbiP/3TP8QSwavf8XY+v3L99d/iA1fXXHMNP4zDzdwzn/lMcPju d7+LrwEffnnw5z//OVXDMGIMoGrlSglOdvvtt7KX88wzz9q958Ddd99z4UW/3/K4YrbN3aF++C2b ifwEz7j5HhfgzLNcDqkdglSZ2MEBedH0SqkQUAgcPQIyshamd+jUD3/4w26kU1KveTMr7pqa4quJ 8VQEcc44WzwSStKjwcmQhhjvvRAZpTmeCDDVUhxtQdMItaVlaTin34rgxCTuPCWHG7sdV41LSbsC nwi/81BSEjv4dkIvU7VokCEotCW/3ALdgfTwVI5W5OaGQEHQCNntxMBjyQpGJTSIWNpeyuIQga5A MgKOiSEtW6/gHKxsce3evXsp5eSTT966dSsl8vSQlFIXssJUyYpYzHYE0iCThiDp58dNw6yUhjYN sXvpqqte9cD9D3/nv2665577nnPZi4L25i19vVRux47t//O1r/fWcxdc8Hu/fvi2crliNahN/dLn X8aiUSweeunLrvjIhz7DvRrfXucjNECBGbAf1pP2798PGrz+w2dOsRxPxDIsleINvkq1Oj4+dsVL X852q/Of9rRHvn7dwQNj207bbldscsePgQk4gA9kc4nXEH9bGyrYicNvTyhJIaAQWCkCeA8JCzPo pFPsXmAmYwASFqZcnxrq5RgmsrhfoU1s2OBrgtwZ8nxgYGBAUkKqcGjEnOKG1rlcCWuFAHMERYvz R6YdZT5FKW1K7IROI1F2Hm5geUkuJRAIOoLX7wRl0QRtcnGYDIngxHgEZAYV0zkX4hqgR3AaSIDc pnAWQegwzQbRYeyxCsUnSQ4dOgSNYHMPSsYby0jCeLiErMgZvbQ0udHwFIGGs3AjYjgHGhnPlAgX IUbDQ3rWeyAcFErRcgkCp7gKpezTEgvhYZwiKwxADzOjRALKRbtLq6G3mu652SLbzHlad/HFvw9h u+m/b/zGjT9Pxv8k7At7fPHtvSP1XJZvS9VmJpr1oOF2Va2ZfHF6cGBrudAo5Cdc3pyr0a9pnmRf 0OtrjY/NTk/PXXrpH7q8eZ54giF1x07oILXGNqqg17V7777Xq/t++IMfmrWG5vY23c1f3f+rkdNP K9UbVQue2mSINKyKVS7Y5Xy93v541cJA5oviAHQLEyuNQkAhsCwEcFw4GcKiV3XSKW578F0yty2a eF0p8Q9UDdeBwWIz3hLXzSeUxU585tlnn33vvfdee+21VJ+NFqzc83SPnVLsy4FdkUCczGF42lOG cyEZdhGnXFftsjJjAJ9WYMrjcgTahZgJUWSUNAeBQ5nTnVI4FJlTJHD0IqCRvjFP312HS3Kp41mN TtwZORzCb4iFCSGghCWwP5GWYJMTj6t4GMd9DPucsBP6IoE7GAYtLU16mocLCSSQPJG5nJxlNHJI ntKuECO2H0E+CKRhqJOhtDp5tnM5fK1jD3miIRZBZLKiINKIfl7sNjSzVIrFIv197bf5Hn30sWgs /JLLLv/RA18s5LKpuSYUkmU0s1zVWC+CuvncpVIhW5yGG+3Z8+gpp5zabLj5aGcqNcs7MNlsmgeF P/3pT6168+WvfLHLnfvet69jfW7btm3ivKiCVK1Rs3/94CMXPPP3zzn3qYWSyQuBWrOx+8HfTF/8 nKinvXPLZVv5Qr5Hf3yX2FL2S7YLcZhXTXWoEFAIrAoCeCQoFDGLzU6Gz3/+87/5zW/KYJQB7pxa nwJeFMMwlYD3IOAkucfDz1ALlMR8m3R6evq22277+te/zhMG7ng5C+XCV/MIgq2x3N9K7ZwZl3wU kTrOLc6cyIxJTIvQNMyMyAttoGkWKk8EzZpxqfaoOgy6xGAtgjAY+BBjjAZjsKGRAKsgDdM/RAE+ JHub2DvFMgwPudCTCaOUNuZa4QRCqmhyckAmIJCMs9zekQ/3QDzR27FjB2kYnORPoRAyUpIJpZAS GT2Ck8ax1rEZAVO5dtHuRXrdZYXDwXwh9+DO+/gY++jWzaTcs2d3byLW35fk3T4AwDp+mMpfrRfN Kl+Tiidi4fjItu3b2AXl8fgbrfTuvffyop/Xa1QqpXPPOeeuO74xMrKtr7ef9SZu4PBB5557LtmK tTgjELt712O2Efi9i34/yl73pBULhwYTkX/5l517Ht0zOEKNdbYSgkMPi10eD7BbbUsWCeR5BBwW uUCpFAIKgaNGgPElQa6AQn3lK1+56qqroFOf+MQnWIz/xS9+wcI8a/AQC5wY3uao817LhFQKU4X3 iBvHScqdHkpcCn6VSj3nOc+Rd5B5e4Yb2lNPPZXt5/fddx/P/tC/7GUvQ4lj5xIy5BIE/PNaVuzE K1umTmk+mkCextAQIEGjSOwIJx482ppxqYXQ0wzSEjAYGkwoMLJM4fAbmAGHpKEhUQrX4aU2+BD7 qITKOIvJJKAIYtHLVTQ8OTCSIV44pnPOOaevrw8lh50r53KtWChltS07HCiULoUo7kyUouEUpaNZ tBvNzk71JBOBADu0irfe+lOoPT6CbJ59+es39SXN9Bjftqrm8+lMrt+vxXr6NC0/MTl2xlkjL3zB C753w61f/crXmq58/6DnTW96T/+AP5svR6LuTZuGnnb+7xXypma0/RGlCx/C6YAVxIjdFQ/vPTh6 0mm2ZmT4BQCvkZrJh3zGjpFBvqcQPu0sbGD32blPeUp1tspn1r1efhKn/Z33hYF6AYvUl9jBYan6 LsxBaRQCCoGlEHBGFglkLeq6665j7+Pb3vY2XjdhaYqtnLgsBiweDJ/WLeMO34ivkBlX/CQelbs+ OBMfN+eUAAJz4q1ktnhSL/wYq1OQJ3D41re+9f3vf58V9ze/+c34NPKh7uJ7l0JS6Y8RAkwu5Cw7 a6WZuG/nkU5n1xX5GBmwzrNdMy4F6EDT2QxyyGhhzMClGGZM3gwbxh5KUrLmRBpalAQc0qisSMEh cDHSojJWaWC5REYd1zI4yQ0lGskWJYSDZ/aMWB4dwmwQuFzGtlhFerKS9kODMRySgGQoJUaPLCSD PKEv0uHkqs44HPFnMnP8oN4FFzz9vPPOp4IsCEHtZ2puw1WKhoMvveKKqq/HrDcqpdmB4c3X/K8/ nZ7bfeDgvnAo8Zdv/MtMpuTxVRK9+r7d5f0HxkMRVzI58IpXvGJk+KSxQw/jYF7zmtfw8XdoJUwR l0RNCbjdl1/58lqVl/nyetMuVMvlQqY/mfjLN/3leLM389jtl1566Wz4FBbS+wLB97z7PQ9VQs16 G+SFATRQLsRhYUqlUQgoBFaGAGOWC2FOb3/723E1//iP//hv//ZvLE19+tOf5gdVuP/BTQmXkpQr K+V4XiUeEmvFdYjZeHJ8Ds6KNTbcptiDMySIjHclJfuocK0khniJj5WzggAyeXYLDmJ5V8e0FJML X/NhLqCBaBcagiYgSFtI7RxNV1d2BcavJZcS0J2WkEPGBi0E+4Ew0WYMIeJOBkMTkpJ2hbUw9rhl gU5xCfc6xKRHTyZcRUxKYnKDOXEKGQZGbgTSEyiF9GxpJw3wOSOWlBQh15JYbBNLRJbR7sgIJINL Oa5hXmNUqmYwFCRNKp2yrWYwEK5rdi47U/EErGrKzk3F+jblXfVSvRVqlYMhfWpsn+6pBsM+3l10 u5Kloumu13KFdDy+o96smeXZmcpUwLf5wP6D/GhxT2+QbwfjZ1mfg1ZiGwGT2gYX0zBFt+4KBQMV sxKIxB8bm7RdnrTmGji8xf7A/gP8rE16Jg2wNV/Q31z8mw7CI6W+nTigmVdTdagQUAgsFwEZR/gH Lnzf+94nb7TdeOONb3jDG9761rd+5jOf+c53vgOlwCNJzt017jBbnBIuWpyq3Akfpk9B/IncheK7 8MPi28Xz8x7fa1/7Wt40woE7kDoOGRAcQJyzSjhGCHD/L2990UYgT2DGQSkyMeV2xsfIjHWb7Zpx KQd3ERgS0gzCeIT90E6yRsUIZLwxGkkM9WHIIZCGgMCwZPixZYoFKi5hpJGeUyjJk5zhAeTj5Cwl omF8Ss7y/B49iQkOH+JyykWDwOVkzikxQ3Im5irRkIwEmIdmYeB3Wqq1MkTF1f7qk4eNVfU6j8z0 6clDp/SH/MEABRVrpi+a5E2JufRkqHfArGZ57gejq7CuVGpzKW+gNTU94Q/V+ZK52/BZdatQrIbC Pn6smS352EZNeV5JjAGg0TYpP+dpWCSulkt1u9HTN1BrGtlKs9xq/8Cz28OPHLc/BuFrtBfh8tV8 0L/IdkJyOwIOCyurNAoBhcCyEBBPglP61Kc+xcYDSAYj7oEHHnjnO9/5+c9/nqUpvnvHq224Gsc7 LSv/tUqMC6Jox4VSQeGLrEuhxwOzSQMnjCBeVHy7XCKenJ8m5GkgCYCIIBlKdboLCrG5S2MmC557 wKUQaAKQJ5aJhhrRLlKvw010gt5drxmX6kS/s3sxojgFKcGVSJAGQ2bIMbo4C3niUFoUDQmICTgg KBSNDaFx8icZNIhDciZwyHAlsXAjaATdgvRkiBKZgD3kSSANhXKtBA7lrPQesursQFIQ+XRWx5Hd HipVY0XK7wt5PG6r3oJMsSU9FgkH/N561YWTYNM7K9oed9Pv8eZyWV+Qmzk+AdWslFLRSL/LKBfM bDgYr1slw2O0mi0oYDDAT8rUM2ledfGxzAZ/gkvhdzAV++GXcW8z4PHmC1l/OMZPxxycmPIFwlXL NrztH1eCpelBPovXYGNns9UMh8J2bc6xuVMAuidgaNNKB4fONEpWCCgEVowA/kce4TG45B4PN8jS lLzH94Mf/IABuOLM1+rCeU6SqlFNlOyIYhEdd00dt27d6tyC4mdII7E4GZasgAX7uUpuVp0816pS J2C57IThETOPOGSWJKY3MtVK0wggTv90hBMKqMdXgxbWWeAgnieQUpTEnfMrHIJDCcy1BJFFLxpk ETiFg+Cnl5zhwbBh7ueQx22/+c1v+NgBG8N5mwOuI5d0ttlCaxdqGJy0N5d/6UtfevWrX00mbNuE Wyw3Hy7he+IQlPvvv597KbZYsU2SzMkHR8A4p2i5idy3bx8vFV522WULjUGDc1xU3y3KpXCQ7tEt tVB2KgTWLQKOXxWugJPkppE5jKGHht1F+EZcjXCRdVuLozRMKku9uPFjkwZ+lbBc53yUZalkR48A bJW52JmtmPjYfUs/5GfKlspEmIBcwg7ms846Cw0LFuRDXyVwSgQ0TliooTNIIM0T4uOrFXKIAQhL mbHm+rWc4EF8ITTCovhg9x133PGNb3wDD4LM10ectd+jhAxmxnoygU7AIjmOCSYHtcIZHWUOkoxy 4WHIbJNktZkPKGAzd1QYL9SQhidz2BXf+cRadjYsmv/Cmi6abN0ql8JBub9122TKsO5CABdBEK9I jGPBWRGz2ExFGIDQDplmuqtei1orbhPPyR0pqx24a2LquG3btkXTO7P7omeVcrUQoF2gUzzxgEXx oAMqT+CQplmtIjZqPmu2LrVz585561JQE1wJdBUCBH2BnTB+0BDLzsRltQGjlPR4H3JgKZI8yZ88 hRgdfVbQLy7EKulMZIUxeDoOpQhxf2jInFKW4hYkOPpC12HKpXCgyuvQWmWSQqDbEcBjEHAy4meY 5Ah4G0K3V03s76yd1OsIVSPxxqj1Oq8FM1272x1Gm/6GtXQ/DtEvZTlnSSOTNasMsi4lvJ+rCJwS 4XAXfjxaqHH6gNPPnf4gpzDA0SxlzBrq13hdippLsxGLANehPaAvck/GFE4aJmxp16NHivYjK6Cn UckQ6oMGogPdPvpMpGjumWh4skKQfe7cKSJzVnoJ7IpsScBjRBIsmr/UbtFTXaGkCRbFgdvKrrBf GakQ6DoEcCky84jlHCJ0uyeRughBpC5UilgmbE4tdS/KjCAXqviYIiBrBKBNwOFLZyNeav6V5iMB AcMkPqYWrtvM14xLHQb/8Wd8yNIkwAQ74fE5h6wAQaQgMcziNDBNuywQZZcil5MPGTLl0xtgPOS/ rHwgZJhHLA+SGerI5Ha4s7XXq+Bq5MmiFNmS8gh9blnlrrfES+Gw3uxU9igENhICeMKNVB2nLk69 xGdyiOckXsrP42mda5Vw7BBgzqUVCExqxDSKtIvsDF5YLs3nKEUmFsHRnyDC8ojFKoIicB+G/bcR +cvDWggKazy868EhKz2koEWXVTpjEn5DzM5NtjEJLSMm22XlQ9GypkVWUDGoOpaQM0q6mnAsup0c cgqDF82fxIvqu0W5FA7LbZduqa+yUyGgEDh2CMCNcClyh4Yg7pFY1qsWlruUfmFKpXkyCNAiuHQa gkYBc4GdwyPs5SClBMp9QvwtwXoyxnTXtWvGpQT3eTGHNCSbzaEmbHyDl/CkD6YirbssZOFMXAj7 gffI8zh6A7nJoD36rBjzQqHIh0CedBcyQeAUOUvgkDwxeKn7J646+kLXYcqlcOj2eq1DqJVJCoEN jwCTtOM6ECRQazz/onXHzS6qV8rVRYAHL8xuBKOLcR4AACAASURBVEgVgWZCZv4VUrWwLM4+0Xq/ fbi0MNmJoFkzLkUDOPgi0yRySPvJEzQE2A+B1UXOLrX262QyT2BMkgNXsSgFxaEIeoOwn3kpj3zI 2hj5QJXgYaTkiSGHZM6rDXQ7OhlKNML2KE40C/Ncrv0Lc1hbzVI4UPe1NUyVrhBQCHQdAsKN8JYE x/njpZfyk3Kz2nXV7DqDZbbFbKZLfDtNwwqC00ALq9M5j8tZNAuVCy/ceJo1e4+Pj0jBbLZs2ULj yWM4GoABttS6TrdDLwRfOuXhzvb4CqowPGonHRfuiHORBN1eZWW/QkAhoBDYkAjgpbnnx3tD8pAR xGnjwDdkfZeqFBVnfYGnQKwv8AAHKNidzJMlgYXZnIAsAmedsFDD5CiBNE+Ij6+wyCE2ICxlyZrr 12xdih1RP/vZz66//noEAktHtArvxy21x23NkXqSBtCfnA7RyaXoUuQMiaT6sqwlZ7kbeJIlqssV AgoBhYBC4FgggK8m4NJx4MxfQhE4hGAtWtx6JgGLGnyUSqrPrE3tpqam+MjR+eefz48doQSco8xh wyRbMy4Fk/3Qhz4E+pAnOiKslvZggYp+uWHA7ayIrJ06IwrmRIA2CYticxggsDUeJRrWqHiG2Hm5 khUCCgGFgEJgnSDA1hEs4Q6ZmFkMgZkL977UNx3knnmdGL+KZjBh8WF0as3NP9PWj3/8Y1mdYkJf xVK6Iqs141KyMAiZgGQQ8wkoobe0R1cAt1wjGUuMNAIXUl+R23zq8HIU7ypCLlmcg87L0jFoLLcI lV4hoBBQCCgEjgMCTFu4dJm/ZOaiUA5PtPUYthFTZRYCmLZ4vsnH6/n9D5YDFJc6Dp3w8SLgECy9 QCnoiNFolBVCZDY4w2qPnxHHsSTqK/xJymxzqMPrUvIsDwZJp2QoItAjT8AxeRybQhWlEFAIKASe FAJMVbK3lRtgeAPrUhyKV180X04tqu92Jb8ww/QNAjMzM4DAigATOj9c2+31WoH9a7YuRReUb3LO zc3xbAv2AKsQsr+Caqz/S6DqwqWIqayMOgRw4BSrdNzlSKAupEG5/iulLFQIKAQUAicgAvJQj4rL YwRx46zQQCYWRQPfvqi+25UwJ5Y/mMFZmmI647eNCfIAtNurtlz714xLwetpALi8MFnag+6I9TTJ cuvQFenlaTokCWvpcwShUyxEiQC1l3sXRikgKC7VFc2qjFQIKAROQATw5DxJEI8NT8KfE4szXxQN Eiyq73YlEzdTG0HWQQYGBtg7xbQOFN1eteXav2ZcCqzhUrJhjVUZZDgEK1Ubdc+1cCNGIMEhUgjQ JjSMSYaiyCAjg3O5banSKwQUAgoBhcBxQEA8NgUhiEuXQpGPQ+nrpwiWAOCU1Jr1OeZxmdZlOWD9 GHl8LFkzLkUXZEUK6GXDkLz+wBbsjdoX4UlUGfJEBYU2sSAsgV6IgBJ2L61OX4TaH58eMK+UzvUw aQtiAibNSymHVGpR/YmmpCc7tFhamY5NYLWVUwQAoYlBEhnQOLUoRPQE0R9G/fFo0ZQbW8mgwCeA JDe+xPgK0ANMQF5XFcckphNiGo7xi6kELEezruw8PsZI9SWWEpfyG8u1h/5AtowHugF5IojzBPzl ZrUq6bGBUYwxWIXPpFtijwxqbFuVIroiEyorszYPmsCBwMwFJl1h/OoaufgEubplqNyOgID4Hafz MSYJDNG14ijMB+ILJMYMAuZh1RFqoU4BlwSAAjFkGpEYGXCQpVnRIECnlsKTmzzSk4wY2NvoP0HB TyiQ5WYXBGSTL7MUoHFIWFc40I7YxvxBM9HKTKgIaBDWlZ3H2hjaRfo2gDi9l0JXCwc+/0hW0gdk 7ACyDKtjXbVF86eOUs1FzyrlCYiA4lJr3Oh4B3EQ2IGPIOAg5KZnTSyjdMp13AQTg0wPol9oEgYv VJ6YmsPe9fFfpwIBECOgBCJi5xCBFncQnoeVZCKXcAr8CeuNQMyz+VgcUmtBj7qzxsNuDEoBltVa 51hFm2WZBIOdVsbydWjnKlZ50ayoPg1E4CytJv12tXAQbInJnCIQpIhFLTkOSrFk3sAU5XEoXRWx DhFQXGqNG0U8joxJhqLMuDKLrIll2IBJMtkjE8QYcZFrYlJXFCr4AJfjXg+D53Ke21ILNMSkJDjJ 5tUO3iAXSjJk7r9JQ4vMS7mxD8ENBKg1gNADOSSWnrmuKg5XoCl5tEHsNBlmY+26svNYGyP1pYGc ACCE1dqrwKNe4AVtCnLKolIypo517RbmL+VS2YWnlObEREBxqTVud/E4YkTnJLqGZmGScClZRZfZ AuUamrT+i8a/C0TSiNKsxOznIAZPgnhepgRJs2ilJD0p5SoSk0wm6UXTb1Ql+2NA6fAGDEte9UXm C8ud3HQ91J3RwZoZ7UUHkJmehkaz3uw8DlgBggTKkh57hH6+XHsYF05uIMzlHMpQWm5Wq5KeomWM kxuC5IlJq5K5yqQbEVBcao1brdPpOGMSm9ZqWHZyApkbZFJfCqa1snMpe9ZK7zhWBxBnXhGT0Esa YmTCoqYyZ8iFwr2QEQiyOrXoJRtSSZXZwQ0jkUfM7G8VYSnc1goEGgiTsJMGomUxQ5pvvdl5rPGB 6UoROBB8msQIq7UHnw9CAix9gIKIKYsiCMe6XkvlT9HS0JLgyIN6qUyUfiMhoLjUGremcClinK/4 X5lx18oscQp4CnGITGncZPPFCnzZoiaJzYueOqGU4IZvpcqHm7FNm4AOpw8J4DEHDEkgJY2071K4 8ZOUIC8slphMJJxoXIrP/fGKNX0PRkXd5UkfP3zGetW66lcyr0tL8aua2MaueWxeV0YeB2PopfRw CfRwYTz09tWCgiVJGRQyOiiCShEvNY6OdZXFY0spYsyxLlHlv84RUBuH17iBZOqV2DFlDQcnThC3 KE4KV8jUxQzBDwU4tilhUQTAygmgR+AQJEGPrR4y0zAZEGhrzi6aCcrJyUl+mxIGxiWkJL3MT0ul 36h6vjN35513Xn/99XfddRf8EsTgVUJW1lWVaWXswTyajJ/RoO1oON49XFdGHgdjpJdK9wYB0AAK OvNqFX3gwAHg5aaOglgF5P6E0UFBq5X/cvMRj0283AtV+o2KgOJSa9yyMukSEzBFhig3Pc7EPE+o uGoe1i0sbsj0ola1tXyiOvPhF13ynu89Vool3NWIr5idnv3uy199tWUlCs3dQduslFuaL1Eu+RMe v784pdmZVtTTtGpNzeUOJQoN71i63HAHDbfHLOaMZtWw9/m0Yqkcz7ZipjG9JXDo6gsv+Mk9ppH0 FI2Dlu3XKklvo+yrj7/zDa+/fVexbPv0etnQrFzTZYYTc/VSo5VOtLmEf7oSLGmhSMBIeEqGVirz inTT1nStWq+5DN1uNniDPBSJ6oanVQyWEnY2bPr5ledCoBmrpurjiUbC9pj+RijRdFfyD3sS7uly olRNePQZt54wK5MuLVMvuaL+hMtdsvjQSSUScRsztmF5Goni7kS9pEcS461ErTVXjCZMHr/UMmGf yxOImXWPq1xN1HIJo2C3rLwebIVileJs3G16jXqp2XqsGgy7aolmrdxMuPwJd/pQQjMzRjxb9TZD B10tj89KBDyzHs2mcnU9G9KS8USfz071lHcZuj8VT1aa5sy3X/aU8/7F6zs54Kob2rTZqhZ1b648 59cPxO3gbDXYCgfd6Qei5bm5eiLrT1Qqu9M3v/viP/i7Ce9Wy1PzNUNF3aqGxz15a98d//nmv79l NkjdDybMZqFSrsQmtYbltlxB3a/Vm4ZLb7k0s15p+fRWQE/UKh6z6nYFLVcsVWrWLTuoV4L1qRqV yvFJ3ETRVxyzx+KueDVTHfeP1a10rJjw1RKZUKvkOZSoW8Facyya3e9NuPWWr5Yr2L4GaHrq2txk QU/kvdVEywpVa6bfn3G5vfl63Dam6vW0riX89dhsKltOZAKJhpVPtDL1fC3nOhAqed2l0Fy4Wko0 otVANF1pundrjWI05GHvidvwmeVq1aomEpFKK/OLj77ipS+58rM37nzX+/7ZaGrVUDLv6wl4qq7Z hEerhROFNL+J7kvUW5VyfjZcTxw0SglfIlDwl72zjVA2UQ1HzEjWXypX/YmAZc3uMiOJtD8WMcyE V0vVEqa7GM1H/Wl/wV/I+XPuvMdfDcwF04fKVlzLGvmpbDORaSQSRi1YmzH9EU8r1ohkC55ExU74 jT3x5qReiLS8Bb1WKHl7G+7QQGXfO1727H/+/DfGm72Vuh1pYoedsyuJcvnaf/jov//3zdlgokWH mkvk4tXp8KxejXhLiYzL1kI0RtHiKa5l+etmy3YV9UROT1SqLk8pbedrASPg9viKtKzXlS9lgl6N 9i7piWxzqmI/6ip7gvWEmZvzR6stvyeVMO25UMxMZJqpZnQqUakFi95yxOthyGt8sy7mazHYcpqW tlpN28UwTdjex2zPo1Y5EfEn/JEDtcZ99BHdHdbcVq1M6yfqrgcK6Wagkag3Hik1E5HETFS39Fok 09pf9OnxRKJh72xGmz160q6NH2qMRcO9W92lV1127j98bTpH/v5mrZKOA6aW8FZTzcqsVYgUYrFa qqZl7blWs+rzeKaLiRJVbyVctbwRTHt8IaOslSpzVsLUNW/+h298xuX3jU9l+hP1SjNQbJZtyw64 A3bby6xJ4AaJcvHY8DkESCROWxYp13hGUcWvEQKKS60R8Cst1uP2WLbFIw+eFfEgjjFsFouPPPLI 3FyqVCx53G4W1QuF4l0///nEJI8bQr5Y1KrX8vnG0HCgWioGIlFyyKVzjHwy4We9WXk666RhltBx Cr3JXi536a7vfvd7s7MFj1fb1DsIx6vajWwxn8rOBQzv4ECoZWi61zMzO3vbzbfosKBSttmqG3or FomkU0zUg3XLgC01mo1gwGe4WvlsBtuYzg2PP5noS81mI+Go23Cz98HjdpnMA6nJngFfivm3yBzr Ndw8I3D19Y1otarfrZcrVS0YCUVihVymJ6JZdUtzk60VC/PJGZfubhXMci5Xcbl8Pr9eNs1YLMo9 sRaNPvCLu7/1rTtDQY0fjTIqZb/eSg4MZnP5ubnZWCzccPtsTzidybBpGDuzmbQXa3zedDrjC4Qi IV/Dsgr5bKFg0lbBULhaq1XrViwS4tGdS2vxVyyV3B6vWYEBG2A7M5sLxeN630AOWFNawBuqW+74 lr5EUqvXy+29HjU74A9s33waftiyzb4+Xz6fjmwdvf76bx84MBEOaG4jODDUGwx7e5OaS2uYhSLb QvgV9sSm4Z077/nuDdeVSlog4KtVq1uGhmem0h49qPl9pl33R8MsJ1JEMhZrlMvVbD6VKwYjUZ7O +rx6NBRI9vTk8kVfMNr0eOutmubl5y+Dw32jdtXsCQX7AwP0lJarZTW0aqXudYdLc3N80LhYaHmZ L2qmXTN7EsGpmdlaJpfoG7RatIJOwxVL6TKMzfCGwnygzwr4Y2BYn568997f7N13iH3zfp83m5rr 7U1G44Oa0YhEvVa9BaQ8Ojb8RiTSb7u8qXy5wblmMx6Lao16JnvIaFRv/PEdb/9f773p+5/7969f GwsHy/lyiI6rtVxJreF1ZfL5wWh/froQDHgbXr3k1iLecOpg2j8cyGaKjZZRruQtl2VaWigUSD+6 p39ggG+msiU6ny9YlXJvH/BC3lpuT6tebYQC8cimMM3TtI1NQ/0szbLsAe/A/tmpKV80ms1k+CoD erPET49rLt1wGW7uXOxG+yOiLJEwlDzJ5DnnnDM0PDS0yTBhhWXT5472JIY0zfrVb35x1113N6mk p57soV2rzZodChpmue7SA/UWJYF83ev3+PzeltZgHY6vjPHmYijojSdouIJuuOnc/OxZTzJJP8wX ij0BLRHwDfUNxqLhXKE2sm1074FDDS1klUp9Q149pvk9wVy+ArfWvG7bFWKA2w0bO1vN9o+m8bkm algqVW1L48agVmkEQ9pcig84MS75fVotn8voLs3Q4QpNvz8wujWZy2n+QNDr1gqlYr5Y5jZoMM7N W7U4q4UMBoU7nSqHQrFkT3Jioqw16095yhmhiDeoa7pN56+2uUddc3l8wUjcG3RXi5lo0BsKeNnd YHi8gUi8obmb3iAdKzU3WymXae1oJEqTR2PxGkNeBYXA+kZAcan13T6LWdew5TWW9i2RbrRXsGYz MKIa7MqlM6+3CVZubo6ZAGFm76Mjw4N208rkNXiB5vHmMoVkLJno6UmnUv39CZ5HHJjOJ3oSLJ4f /jGf9itIf/u3f7tz50486cGJg1CIGD5yoC8aitRyxWLKcge0mWJ2x+mnP/yb+0e2bRra3GfoVigW Sc3O9PXEc7l6NDbi50PVPJ7CHiYoreXz+nhtHJeZmikMDWxpWq561YpHI/Va2SxlT9o+otk1nxGK hnqrpZThaxSLzblUpVbP52YP4cHNcqMOq6gUbbMVCnqKda1WnpqdSAd8iVrDbOj1SHQonaoEgu1P To+NjY+Ojjazmbe89a133HFHmwvyXlV5zm1VivlSNJGED+Gvy009r0e9gbA/GEzNzQV9rI405sbH RraMVut2w7J1rRkd2sQDnEzWMsKRSs0KR726q4U+l83wpYJAIJgrFJst1vc8cX+5pzecrtasYiUc DIfdWl9ioKlFdH8NMpaIB8IBX9NqZuYqO3ft60mOegOt6dnZkd6BiQfue9vb3jk9lc4VNJ83PpOZ 0HQrm9USsWBPLGoWqh531Mxqr3rDlQ88cL3Pq5mlvC8Y2r37wGnDZ9s1PdewqoaeZ5GGHwjju/nV mr/RghlFBkcKVYuVv5mJ8YGe4M4H7k/2DmYKtTKdItaazhxsNH25bEVvVgy7XEpVi8Vc1Z6sWrlE bMDv7Qn3xJjPRhM7BoKaxyqEvfr0dPakU4aYfDOFstvP2mIktCkWS3h8vqju8tXsrFnJGBrzfdnr 973znddce+1XTVMrmcVEb0+5Yo5NFAxWO82MRw8FfHFvX8hqmGXL7womLN3ni8QqWFur6Y1aT8jj a1YfOljVg71Tc1p/f2+5kAoYzYiX7WOtaZdW82oDsS358WzSF2zYleTQ8P5SrTRd6B3psQ4eOn3z U0yzxTqjETVcgaTh1sKREH3AtlpWvU0L6rVqLq/Va1ohf8gT05sN3+REVmsvkZaD/r5SkedIFTcb yfnOZANC49cO/0pGKBBoWtbmQWNmmum+mU5lLVvL5Ep0LZ7zRGPBeirFo/DZ2dl8ob393NAayZhv 32NzsLxr/+tr73v/B92G5vGktVIm0HQblu72Qp4gl+FsoaXFvL6gr6W3iuVC3Sr398fMUt3v08ql NJ8BHRjsL5ZMeHxL0z1ef61uJxLJ1P4JP4N6OpVJlwa2+3bt3dW3aUvJdEVBuZAqj0+7XQG274f6 ouWWNZluf5vApbngYdwE9Pb2FouFeq0WCfv9vlZveKi/Z3PRNF163W0kqE1T12Lh0MT4WE+clWQL x5LJNmhybyBUyeeaWrNnZCuLWlYmEzDNkK35WmGt4fP7gjPTmVKpnEwGNbuczU/5qWq9VC/MDA0k PT49XWRQeUy7VW1qPq3arBa8MPimPZ1KG+FoqlTP1TWrUkrGIc+BdDoFmaUJDowd6tkEJVVBIbCu EVBcal03z0LjuDnGG7KZmYUl+BOTBHtdWfav1qps0cWts1McDoPb7unRSDw7MT402H/y6Oa+ocGJ meliOtvfO/ilz32Jm8ELL7roLW95e/sGnBt2l86qNes3XH7p8y8tFFtXX331psBwNAaPCs2a5s59 j/7Zn/zp2due8cLnPO+B3QdjwwMH9u298k9fsndsbzo3F/Ab//SBd566eXjYn7jssiuzhUYNXpKZ K5v5vkTIaNn/+R//8ffXvPvHt/z8vHPPD8d817zjGrdLt2q1vY/ueeGlz/N5Q+6w/1Mf+2ytrHt8 ta987dPvfc8/33vfgf7tg+edfsFnv/DFXWNzZ593wejQ2R/4+7+Znpz2xvpC3mIxXR4ePHnbKZvP eOpp6UxzcGDUakAXi4ODg2ysufnmm3cdmPj3z3/25MGTP/+Fzydd5UbFfPPfvCMQjCYT0Xe+4y0m i22Gz/AFWV1o2lYiEsTOb/7719/3/g/83Tvfc9bmobH9e7VS8f9+97s7RkZ80b6vf/O6FI8kpiZg hx98//u8yZ6+vjMuu/ylkzONUtXSvOYtP/nB5Ve9Ibbp3KHBgTe96i3j+8c0dzwYN375m19uHhkN B0/6+Ef/OcS61PbtBZ7k2Kbhbv7igZ9dc83fFVvae9/zgVOTp+Yy5ZZbGxzuf2jn7tHhfh6vffYz n7Vst9ev/fL2H775Te9luEbjkdzM9Ec+9OGgq2fblh1f+Y/ri7bN75XACFlIy87MRILBaibzlnd/ sGd4yxlnnn7pH/7BXbff8ZSnPGX3owdPO+eCk6N9PcOBa//jcx53pE1fPdarrnzJLd+767Wvff32 k0de98bLpybzV/75G4eGN8dHeu+5P1ecmvS7m3986XNvvfXW3sHTd5x61sv+/C8efDAV8gdzE49+ 8MN//7WvXFcxeeRZ/dldP37tVdckEtEf/eCmvfsPXPuFT55//oXXXffNps3yZ/pd7/1kpDeWHE7e 8dNfBb2xsd33/Ov/Y+8sAOwqzr5/rrvfu3fdNy7ESAKEJJAQHAqlUGiRlmLFXigUCwSKhRYrVqDA W1yKBQkuwRMggQjxrO9ed7fvd/eEbT6yoUAJtH3PoT2ZnXvOyDNzZv7z6D23LPzTvQuu/mNdy/C1 67c4nLZsJuWudq/6dOlN113ljwvXLLxlt9Ypn378wZrPll0x/6InHn28wt3yhz8vCMSCL7zw+ozJ e9lrDXW19fMXLlDZNNW2uuDGT35x9IHX33z70T8/ubapYve9p27uip511m9HjJiotbds3NiOPQXB mQwVMP2KpaLW7FJdeO6Jjz/y/LNPvy7TK1taqz96fy3TpqJxQqW78bHHnlUpgcu6v/zxuta6OrNd 39o49uFH3qiuhMtYcLSOevrZdyZO2c1d01zjrlu8+FU+SYvVotfp//a3x+rr61ubq//37ncmjHCF fFvOO+/khx5+KhVnfNp/9fN9Fz+5+PwzLrAbtXvMGL/mC6CJMZPyvv3ue7UNDcNHDN97zl4rViyv tqn7ezs+W75Ub7TI1brW4SM+X7UGbmk4igBdVhBkDdUmZIJrVmzYa/Y8mVI2Zbddbr39TqaHqoD4 3nvKyT9b9NSr115zm8zonHvg3r6QLJPN8iFX1VhYHFLp9BVXXHHllVeibiQXohvX99xxy/0XX/I/ hVLi3XdXT54yT6uXOeymJW++FgkLyN/6+vv3nL1XKMZhLG7XFhcuXHju7y+zOVXh7s4zf/nzJx94 btKk2ePH7+rzJBpaxg7EVi0IDotWr4zG/NpivKrGFfT3n3nOeZVtDRW1dcf++tf9vrhaXjBadMHe zltvv3X8LrvIbLIREyb5EhmVQvbbU37TbLO46kfPmLFne5efww887u1XQilHosC/FQUkLPVvNRzf vTHoOYOuyqKnAT/RQi6OwRNg67BDfnLwQfuv62pf9NILMrVabzT97d77zzvrvJdffP7FF158/PHH 77zzTmz0fD4fL3KwxlTq8ssvJ8jV+eef//SbbyEsQy7g0GquPPnXs2fOXPz4nYFez4N/f9SbjjUO a920ak2fPwQ3rLN9y3VX3/zc84veWrF8/mULijJlIpNubqm320whn8dk0FmM5gcefOToY0+8YsH8 axcsfPThB99/991CNi8vyk896beffbL06fuvuvOqP69Ytlahz1VWmx696/ETTjjnmacfuOScn119 7cLJk3Y/4ZQz3nzprw89cGsiGu4Lp/vaP54yY/r8ixcuX/3hmMkjDz3s1+EQfIIOo9GgkCM8Mu02 fbcKs/bwY49f/N57Bx90sFBIT5wwefGbH77+3rIVHy5Z/fGSKVMmelNCriSPxhMuhz0S8OjV8s8/ W37llddFk9lFr7zUOn7M/95152WXXfrUi4vXL1925oULnlv8Midsv6d3+rRdP3rlww8/en7Vmi8e fuwJq70i/Nl7B+93UHsg9fCzj7395htnn3Scw2JM5YXuZe8dvt/cG66/4u5bL7r5lpvWrNrU0xtT ag0oejgcjinjJh9yyCFuvfKII474+xtvwAUpyFQfv//8iUf+9A+XzX/s9vtuuvqKNV+sRbWtffPG 7s52oZRPBP1/Wnjtc88+88bHz728+IVR4yaYrLZILB4tS3gV1XW1nvbNc2fveef9j/357ntfe/3V ay6/ZPyIltWffjpml/EH/fTYJZv6Hnj4lj9cfe3FF16nU9u9/Rs/XfHB78+7Zvfpcx5/8obX3nh9 cs0Ildz+6uL7653mK6+41W5QZyOBvt7ek447/oKLLnnmqSdWLl92+EHz+rsFs03Z0bUy6E8q5LJ0 1htPeld80uEPeEeMHGa3GU4++7xbbvvzrNkz5Bbj3nNm9/uFDe3L/3rX1SceffLalV31YxvffP+V a6+68+0lbz+3aBEzsL2922Kxdm7cOGbanlOnTvUIwqRpMx969ZW6Skd3+/q7/3L7hRcu+Mvtdx17 9L6xcPCgA4889NCj2z9r/8ud19z4hz/eeeMTOq3c5lSs3/TZ/Iuv3WP6fvfdf5vP33HIiN3iifAT T9w7vNZy1533pVNCqSj0bdqIPbvNYg8FNyrUiUvPPO/F5995Z/HDM2ZO/tn+v/jNCSc889BtZ599 8nmn/TYQiKICz6A8/OSTHas2/uzwfU/59YmppKDTm+647k9H/urwc8+/5IuVHz/x9NOjRo3iw4P5 eudNNz7x9yeeffaZw34y7ZILr1z6uaCzyLb0ru3riylgrOZ6N25Y/ptfnWwz1b777mPZnOeJh5+B TdrVveJnPz/ugosXvPr6kkmTps6/5NJuCD6vuQAAIABJREFUb7S6wn3yr0454+xzVq9Zd/c991XX 1seSKa3eoNLqSzJFJgBVNu+331ETJ01f/snaBx6848oLL7vusgdRk8sXQ2vXf3zS8b8SiqZPPni4 o3v1Iw8+Z9Dr4Tp7++PcCSHPZ/7Xe/66dt16eKyKgvEPl14/Y8aEZCY4d/b+e+99ZG8o9PdHHv7t by+8/da/ICPesqW9q7uvUBIMZrs2F/n88xX2muZgTGBoPv9o6VkX/M8JZ15wzz33aLTavs5NFRUV doeCIx2gjWE16BRxX8+Y8RMXvfjSB+9+/M5773r6uvaYNjGTz4WDwZmzZ/35j9ddtOAyb0fs/oce tNgs6Who1ozdX/nw/XWfvrVx06ZFz72g1utjqX8v483vvkxLb/73UkDCUv9hY1tmPgky+PPIEQb8 1wnwk5JZobKyCpOvVDrLSVpbNsnWJMua3jmjVoZ6w6ovVs2cOcldW51IZa7/443z9prH0bmuvg6F qpdeeomi4GDBgjKaTOhVNDU3G/RKHpg1q81iNlNcJpM98Y5bTvnNSbvtMsWs0ZmdjkA22dnZqRfQ nIIPYvd5fLms0L5xrbvCNmPmBI1JKaiUqDFFwgFZMVtMJ/v7+t2VDc889+rPjzr42F/+VFbKmPS6 Qrbgslf9+rhTTTpXU4NF76xPo5tUDG/uXCWYap96+o1J08f96ueHBaPhu559+ZQzz5k2cWyTyej1 9BnszhUfv2wR7D85+JhgrP+Y43/2xYoOv69YW2NF7QYxU19fn7G2ZtasWeWVfWDn2PLxsnROcf2d D1U3to1orn30npuFQnLJRx/LVbo87xRyankJvlQ+m5kzb84VVy+cOH5Mz+qVN93wp2nTpo4cNToY jo4dMeyhx/6eScSGt7Qc/pNDW1ta3JVVzS1tmXyxo6fvg5cXC2rtTX99bO8Df9ZYVz13z4lGnUyN DlRN3eL33j/yp0cefcSRze76oN9X22AKJcK4N4+Ek8F4dN68fVVq1egxI/acUVMopuQqZHtjX3hz yW9OOm2vmbvVtjS1d2+RawS92tTX7THqlEh2a2vcqUSoo33trntOHN4yPJPMmY0MlJmNv5TPhKKB VR39f37479P3mutwOQ85YJ5eKXv37bfd7pZzL7i8xmbfe9bEP1x+/P33PRHwFytqLbG8MP/ym045 6fzxE4Y1NmsOOP7MK6+4cfTUEXPm7ertj6I9hhYPSOiZ19487LDD9pg2+fknHsx5NnZsSRdKcDnb MyizaZH+YEyQEooWjUZVW1s9ddpkDBYP2G/X8buMf//lxeFw4ODDTuz1d06YNFwo6n398a51Hxtt mj33O+ad115qqa+pq3Y47OWxM9ucmWh46ozZ05vG7jF1enOdraWhUiErqLSG515e8tNjf7PX8Kbn H3q0tnLY/GsuMFU5jzjy4Ksvu/j+q/6yuTsXzfWz5d54w91XLTh73OimXCp0wIkX/PnWGydP23XM 6HGrV61NJNDqU1WNaEO9Lxwq2RrMSz95fdaBx9195/17zN51n3l7CiXr+8uW7bvfvjNnzkS853Ca QR5H/uxIsJ0GjpZCrlYTvVjYsqXzz7f8ZcbUnxx59HEwQQFSSM3gBHMgmXfooY899vi+++43Y0Zz qYB4UZDrckaHtsLVplEgFhWCsfxfbn/hrjtua26p0KgSBqVBnhE+/eiZoqAbO36aUmnaddcZHy/9 zNPjL2SKmYTw3gcf6k2W/Q/av7K6FkV6Qa5EAE0C2eXSZSvNxurLLl/Y3FozY/cxC6++8NkHHvcG hIIy54ukbrj57zdcd21djaGt2aYuoZkXwa4FXFj2K5FOH3744dlsbvny5UZD4Z03lmUSynn7zXjr nZdkyobzf39tNBk8YN7cG6/7/R+vvWbjxi21tXXJdEauEjZ3dqvlGYfVurbTozAK2VwCVcabbr1z 3+N/M3XaBKMRzUM0HTP9felsKJpKFaIRJJPZZcuXc6i45c47K2uqW5vr77r1T4nEhg9WrOqCcR2J LbjhhjNOPU2vVY0d2aYU8trKip8cclCVuwIdu+bmFjqbSOW0etN/2DItNff/HgUkLPWfN+boIdFo 1nQ0nIqFIuyoCjvaSESxKGtQoTBF2mCzKcEzKtWzT/39qaefPeaXx7SN3TUSL3Mv+vr6X33jtdFj xjU3NvRuWYeMD/kgm0ECd4jY/lltJhOYisWrhNYO8kNUyPOlUuuYUTqNVnBXjx0+0hNGd9WFmm1B SBlMVaFQevzYiQ/ft/CMs88f2Vb/m1NOTWSS2XJLBFSDdZgdytlugWSmxuaaYimayYTq69z9vd3O 2uoNa9tHtO0yom3CwmsvSfp73Y66aKQX/fgRIyaD6GSqgqdrE7YyY6e0qvXmZDSYjcU1KmU4LSxf 9rpCULeMq5u9z6EnHn6aoLajnBWJ90EXm81ILwKbNmGYzREcpML/zGarN5p2NY4C4Gjk+eYKI0bb doctmcmh2IsOjc1myWdSqI3vOWu21WHIphJOm5Wuv/XKkyMb6qbP3nvj5i3ov6vkQvuWjWefeUZr a8u4cZM++3yls6ISNZb+Te1oOzlrqn1RYp6UDKqsz7s5nonaa5tbWkcFA1GhIBRRtClkuvuCerPK YK8tFTVY/JksduSqNrux11tAgSYWl1VVNTfV20rJcD4TT6XCFW4r4hVUkRxWdw7gotOdctrJ+86b deKJ58k0sjWfrlIW5LDXYPJpdJpkLhVJx1FTy6n0lQ0WpwsWQa6UTb63ZEl9Y4vObCpEBb0qZzcr c/4YBpSecC8Who0jJwp5s0xeDIYy1ZWto4ZphIwvke7P5YooBSPBbGhxos9lt+v8fV3j2+oEIVrC nFOW1hkFtcrITCvJksFwn8PaABqVq5XRaAQ1ajTZ16//oqmlMRRLXn7CmbtOPWSvuYejsY91od2J HlZh2Mhd8/GA26qLIqPN5xRqDZtuKFWQ6+2dWzamo+FK5NSpKHzNxtYRjlpnIClE1ywv+cJud2Nf QsjqFV09WxqN9pqcMZwuWGqNHQGhprY16BOsRpVZLauzNXNMQCWPMwN9cTrUqXQm2t2l06mNelmg +wuX27D3Xgdo1ajfBSurbQ2tE0cPawKS1jc0wNTt6/PXNTQ888wzLS7X1MmT33ztdbi/G9aHWtuG o901c/Ych8sN67e6Ug8rlO/ObDGPGTPGZpW3t29RKv2xSAhLr0jSu7lrvacvBZZKJyI5hYCo1B8U svnoqJE1skwh2O1f99lrQiS9//5HjJsw7Zz/uaiUU7Q2NReyspdffAbRXlNd9Zixk5h+YPdoPKkz GOAuKw3Gxa+82zpskpURxrZXiNfZjaFYl97uziiKBpvQ3Dw2HBCcNkVbvVmTLwGh+AT5ImBMwW1r a2vbZ+7cSy+9NBjovvC8BVdculAmyzz3wpNTp+xt0MvNDqNCKDpsFjiOgHS0rPLZHLyhkY1jy4pQ gaCgMcSwANEpzE5Bbjclbdp0JmQ0C3aHCWcgWsbe6lbKaagrEEvWNrWFE/S6xmCEr5oyqwuVSm1W ZYhkS75Usqq2LpaOZ1LRxmGVqCoUPb1XXDZ/7JhRY0aP/WLtWovVFo2noth3SJdEgX9vCkhY6t97 fLZrHUZ8WLgAgHDuOWC5lTeYTCNHjvz000/RmYUphcrwli1bWOLLCEZvqG9uCnh77r//bx5P//kX /N5qtVW7a8497dxkMo59UI8/+sADD7ATAMK4YFCFwmEsfSLRqAkjGs6J+TzF6jVq9ms2EmHzFnkJ /osWxeuOMl9KGw5nqiotWEXtf+BB/p61N95ywwtPPvruh29j/sWRFC5T2eStkAcBaHUGjQ78l7NY tIFAv8lk2LJywzlnn/fznx3X1xW87747nVVjABtmuwmj7e4eb9l1i7yI4ZDVWoWOGJwhrVpp0iCm KWLVM6y1RiNoA1t8nV0fr4utaO9+qbVFSKWj6IVgyYU6jKO2Vq3CKA/YV5Z1hiNxucroj7HTIwkt BPs7tUoUkJPot+OkWaNWhbz4WRAcdhusCNTFyAGRcLY+7axLuoPeQF/fylVrnnz8Jlp1x+23vvzy S0uXLu3s2jJ33jzIaHc4R7UMo7sdvXm9WY1VYDjQ60CJWqcIso2UZCqFWigKoSDK/g6DSZsXsglf FJVtuUwVCYYok8HU6uT8T6kyYUuFngrdtFlNkUgIsz4ZLnWLqkJOplbhBgHdkeKjjz6wZs3zxx06 98hDDi+k8zq1FsaDUq3Olh9SwMfyhBBUljvOuMmU8mlTp65duyGWwJyetzNKTPHlxkBAMDtMWqsQ yxQRXRkNBuBvPidbs1YQbBpBlqJdBeIxagwbt/itdicdrGxq2LBqORrd7goceBQI7FEqyhGcwVHr 7NyUy8oMRn0pn7XZrKjzI2XGphKzR1p8y0tvRtIrl338dDC3ZfLEBpUalxRxmVwvzyVluTR2bGD3 cDiKEFqpM0XSeYfBDHWKGQAoVlzZAhr/KoH9215dVWWydHT0ygwCjFer3ZwPxXQwu2za9p5Nw0fA ps2DjQAuimJJg665Vo0pK3Jq9ORpzwCTFWZJ2X7N0VQtk+d7ur0MtFqr8Ac88Vi2q8/PO2U70AEd 7WUffXTyby9++vXXV61cOf+SS/LJZFWVLZ3O4EDkw4+WRWIpvkSvLxNPxBnCbCbLeSYWF2pqatSa NCy6RFJQqEuw3RRyQy7D2GXlOhTILYyhVqc06gG6uWENzpEtbsFcvWr1Rp8nwozdtHlLJJzDDrRp xLhNmza/8tZ7Ho/3mmsXxhNJnV6PWWsC1msqM3W3mSvXbI7EGOVEOhmU439B0Hb2FVBt7w8IxZLK iFUcevbBbrNGi1I8HzhDrMFzrFodDkfmX3ppLOj97WknxlPJKZN3Q31+7j57ffzJKmwpMrl0qYh6 YQKj0VA4BLupDILSePXwCdFQV0cHKlwyjRDkbFMSdE5rkLte4Q+Gkil0/4oYYAgFWbGgyKSKGqM5 ns0LeWahPB4v6TTKeLC/kE+ninKt2V4U5L4AhrQyrUru39yukReuvfrqRYueXb1qVa+3b88998RU 1u7Ans+y3UIoZUgU+PeigISlfuTxgGkDWEFSgHANszvWOxoEptlRs7Q5Vy6nzyv1paJMlSmYjbZe mcxx8L6dz1y08uWnAmnfyu7C3bd3zZ0xqabGH/Vm3nhnWdDj23PsWANCC2N9Qm667Irf33b75bff +6A3FPN5+pe+97aGjZxdWoWcRuuGo5GpMBibF7/6RCYUM2YbNLqxYYs6A2NFZRdqdHHNRmUmK0sY Gqyji8qkQ9kVSSZX9nte/mBZOhOfOrYN+yilzpWPGK0Kk8usTinSYYOuG+txjcIRK0azpgyucTJy GfIPk7I72tET3xhT9P/xb59GQkt8vc91B+oj2TH1ps32IpLMsV8UJ0WjG5qLPaZYIqoa02HEb5N/ WDrcOOuqiLXjlAsOjm/RCR3GjjXLYqGoRdg3ih26tlgMenMyo72p5pl75m/56POCaqRtzJRGW/bp BYcLvWtW+xXHXPei3N44o6lSqamy4oYhFy+rmemdcZUTHpYlm3ZhIK+r/f31V919+6WPPLAgqtNg iLZ88Vp9useUbSgVkoLB8/zLq1996a3n37oXPRbTAUfqiv13nHrApi+6P/HmPm3v90VUvYkRNbmo jv01r88qzDqlMuXpVhUBKNZIpUUrjwCackJFtqTY+P4TmoRvU9jRJ5+Yiz0/xhkPpl1+cFkJiybY Ax6PdheDYll1MRnN1d//1vNrN3xuKVWNmNwKOvBlyopABrM5n05riqVxjY2tDu31v9i994O3vX29 737R/dEm76S9904lupYsulWj8S75THvKhU8df+zYGnNXV39FoVhtTL6BYb4sV7QJgl2rtFSymyoS +bRJFZfLfMW4YmRdw9VXnuJPdKzdnD7z5hfNs+dOr9yU9bXkE7uuev+qDV+8c8616668YYWlpSOe isl0I+yl5rfvu7ezZ2OXo1HmGLO/qeLiI5yfvuvX6qat/vBdIdnVF2rJZEc6s0sKMuzAVIQFBpkR 4gyBcCmj1MsdmxWy5oqsOREUDE0BdVspF7MWGaN+Ia2YOWcveeazp++dXwgGPvncduxVd9eePL5a sVaumoKXIqthSzLWn1BPj5VGqTJv4fTBm8OblVsV3NikFbpDqZzOZSnFhDj/pXMOjEIz1Uohp1Ml 5MVamb5SLcvoqhNqq1rwlULr+9J4cRPkYd/KwKYLLrzNZkmEQh/y2tkXzX/tzT8+99dbO7yRzZ+8 +cXyj9ZFDe1Fl1mINyrDmWS8Vz1GyBRqtAL+vaLJUoMmlekTlFVjAgqXkHvbromm5Lt3xlvUug3R XGTYvKfM0U8WXnrsFn/HhoD/0y+W4bcknPE8//qLHZ1Lhzc5a80WVTivjSnUSbxUFEqFmF6emT11 uFq2+qGH58dSqhUbxx11zn0TT957an00L4xMKLRW45pS1heX75eUTTXK3qxRqUJ9WzKqbEJrSMmc pXhxeq16VkX40ReFkUf8xD7WZtCNnNY2LZ/98P6/XS/Pud9asebcS2/ZY79d3LUWvTBaEHxLP7yh 69Pekfv8et0GdZ3RI097Ndq92gMyg6yrLR5Qp9RyWyGVsZjiFqs9HTPXR4rNw3TvmHR5i6JizPCG Ky75uUzRt3xNZMFt7wR0lXMb7U5LdnS1/fpjju976YPNwcjfV67ujBQsOOcIxbXR7LPvdTz//vL3 lzyuyaV64+5+V84h5JsA/dlYRJO34J0hUwwXsiyVP8rF+oxuBWJTFnAulE2x6GQBJy36CNxJ97Is YsCbPMck0hwSqIicHe0XUv4PRgEJS/1gpP5+Kspm02UrZWR7iIsy2WQyVVFRecCBBx133JFHHXkc rPupu7Vh337TzTcBzowG0+lnnt0wdpdKt8tqtZxyyklOp2XO3Lm3XIdG9fxhjQ27jB5x3733+Hwe OPNwQoh6wnkZrtexxx13y003jBo5Yv36dfCosN9xqPHFI8uG43I5Ks4yLMa9kVAcJ6DlP0qYAR50 8HEtrZN3mzLzyFNOHT92jKvChDOFnu7eVAoOmYIjOwd9NKQ5x6PMhHsbVh+WnosuuujZZ5+trq4O BELTpk08/benf/LpJ6xH2GrjDgdPVy6XiyeBmyiHoRrP+oXgEinMxImT77nnvtdff2PypMnDh7fO nTuHAzQCpnQyBW0UChWuIebtu583Etl79qzFL76OO9AXX1zc3dM7evToMaNH9fR0L178Ij1BohGL RlmV7K6KSCyGiRPyPhwfxOKxRDJ52GGHXzL/jCv/cFW11T5r5p4333R9VqGbe8Ch2aIwdtwuf7h8 wennnrXu0w9vvGZhY0vLoucWrV65co/Ro2aOG3Paaaeyxqk516txWSVUYUTZ19vaNgxrL2SRiXgs GgnbrPjHKjjr6888++xzL5rfVF/PCNDNxsbGrq4uCAWLAhnrunXrELnCicBQPxgKwSd68aWXd5k8 r6Fx0oWX3HHP/95l1aNDBzMog0GiWm/SOqseevK5efPmoS42duxY7pC3paXlscceO+OMM6qqqlAG +tWvfnX22WeD4KkO1iMSXrtL8PpClZWKTA6uh5CIZWurG2FKZnMFo92RSKU+eeu9Sa0tEydP8Pb3 33XnX5IlucZiP/Twoz5dvnKPKXsG+nvPv+qPof52GQ5Di8Wjj/9lZ7Z3n92mv/T88waj6blXX9ln n31mz55N7QcccMCSJUuomjFlKHf0Vag06mKpwATw+r3xeMzpsPf29Djt9rxc2zp6l5tvu/3qa65t aW6cN33KCSedcM1lF8JGhVFm0Bu6e7qhNh63U2l8ZGiR7eLtC7G43W4LBn1Ie3HUBAMMbqXfF5WV 8G9U6PcKeKfHXxsCQHGysUUxCnxB06dP32uvvX75y19OmzbtrLPOIoc0XKtjjz322muvxT4DoR52 AytWrICbJbo7Z9wZuGQ8azRo4FGplHr4edlsorZW6O/zUwIEp9c8A/EhAnxQTDuffvJvb7zx5sTx 4yYPazv6qKP6ens0Wt1Z55yz556zhg1rw9fJeeed43br8GWATjfOOHZEBw5jNI8B7e7u5vviS0GR jhr5YBHzRSMRGgApWDfgxV1+5SWC037UEYdXuV2b1q1paW178tEHL50/v8FumjNnDj29/vrreRc2 2wknnIBJCoyik37zG+YP87CspZnNjBkxxtPfP3gCZECplE5Bc9pAAl4aeOPhRx/FdVVDfc0B+++/ 8rMVr732ig2OosXy4dJlu07cdY+D56KV+NvTTkkn4of98hdGgzB6/Nhzzjn71HPPXf3uuwsuvFiL WyqNBuNctBcgMmNELxijAVWEHc2gnZvPGkVL+DyhDyMIBVhDdjaQYmrRK1BUf38/pKZGSEEOc2/n 9lYq/RtQYIfhLMRB4v6VBGWKmdyBw4NpptTg+YCJxSX+KeaLOaTFBD+tXr0aVdZv0ML/kkfE0wPk 4nvjIgE1uPgwWPsgC6CBxU6kD+sRDwzZ83xWo1DK2TxR84zFQiUha7WZCwgPsmm/L5bLqHVaG7HM dHpZvhjBs5Iumc/INN54QWVyuCv0fe29DU5jKR3ZEisDFD5IljxjWaHbi8k0CU24L5LEh6a5pDHR sBqn2awpZQJ9XZWt1nDIqQ6nkvmguQ0U1aRJqXuXrbdMMeCDUZFLBPrc7ooNXd6GllGbfNFqmT6e DLirjNlcFCUNq6XS703iLCCaCLMAobfOSsQSwGGOZoAbNLq8SqXp7fU0NbZFwgm8JOAQCEgkV6bY D2gbyyiPMXOgGC8mUl7caWnUumgkpVRqZXDVtEa1ShtVZLLRQK1Nn42FhJI8mCiEcyp7VaNb6MMl YDyV9QYjeUFpcVTgLCeDh0TENMq8Wp4u5XG4bvD4466qFnCCASXzRChdjFlclvWbOkzWmlAY2U29 sdgfi8VxGZ/DzY4gr6qp+2LdBndVlT7Zp7W4IgVVR38QAz2LRo41uKqQ7k43GtSFqG/FiObGoDet 0NmTypzahpuiSJ3TWYyGc7FomQ6CzJtMKQymCq0ayAj6QWbHOEI6SoNcdZX1GzdtaGioicaCJrMu mYoGQz6XyxFJ2Rh7VHUxb8T7gNmoj0fDVrPZGwEclOcYG6GIQVHD7+npgfjsgsw0cSNnWrInUUVP wDDMvsqPvZl1rtEiKH1LOHHHrXtkwl+0yG1N9U0LX3h85px9M6t6cHIer7fXJhO5fDaPq8tcJp0r qDUmrc5WEvCSncp80VdvqU0U82uEqKPebfJHXHm1R5alalrCDGfK0Ta6xhxgWIec5/IcfgtKOoMe GGe123r6e81WK69XGlUIVatr63r6vWqt3hsItbQNZ0pkEl12u7O3x1PpronHM8wfP25jrfZAeGNV VR2TFvFxVTVuJBEua+SKkqdL3TRiiz8SlMVnIu8rGZaq1bpCaKzC6GdrpIVELOGT5BNgyonfLK1l 9wKl1dXVQUO6QLV8qgjWoSG/MmT0kXQZocrXC7FdYbdFiq/bHfZCaEIqJZhqVshzrbxCIaBJKMAH yBCADOptmkAi543nEwUF9dr0ykLUA1fLkyri8qqqst5itnR39xmMWs40uVzKoJQPSYdSJg7CYMLg Yg24JraNr8ymFTJFBUuBTKkx6dSYARoK0YWXX7jg2a7O3lXFSNgkSxezKTxpBpP5glyjzMUYqaam JprKADEVmTzAskIwZmqs6k9GDThoxedoOOZsqW+P+u0KLTSBVpCIi8nGGYB5pVfnDEZzIBgulpTh aDIaS1XX1JcdZakCMGiVWTnsyHgql8CNi8WMn/5K78oiZhZES3DVmyzmdSu/GNtWr8il8UQMxYBT EI1OiSNCRdQ45PzZ2ZkMPW2AsHfffTffL2NKY8iBaDu1amYLtVAX9r8QWZyH1E7mTq13R4WL+xp3 Fme+5aeeemr48OGkRWpw5xKJQ4JGDl4Dv/x/ORQiXjzzZXJriB7xT9pAYkct+dHzpdjGP/oQfLsG qMrqPkVMz5hV2Oul08VQKIpOEq6YYVAJRa1Q4ryCT/MUOuNKvBSrVWi02J3mbEkWDCRUGqWfTVqv qnAaUY5Bl4nlIBzwswfDCopHwrFw1FnX1N7lMWn1TY2V3u7uokZu0BpkQXSWVUJRLShVhWwS34K4 25ZbKtSlArsBdnwtTU2bN2yormnAxUAVus3xvNGkTyZS0XgUfayyzoys1NsXwEM44An+BCdXNhJ2 EfYtjln0iBWyrXW41xuQy5RwmHA0GY2G6xoqAATiyY+lmd2U1ZMci8Xu8fhwVF7WLlfpUDxCiwX7 LIvBGE5E+/r9brtZTxgYfd6hMRdQS/ek1JqSzmjSpfNgIKNBhxIujD2HBeeErOhAsFI8k7c7XWgA JdCdjvjrm2v7+lOZdKGmut5qr87nvAr0wkxOGQF3qFgmcCzt6twybnhjMBjATxX6Inp7ZY0b+GlC ryns8Ve7bBpihBgUNmNDMByWqy2ZMiFysWDIajDjDt6GFrTZBmjA42pDnTMrlJTZHARhF6RfbBus ODAYSPf7+rEYj7OF4wksjb9sPGIjnpMZ5Dm1WaMScij9oNuE7nYRZ+6pIssZgImNEOMytvbW1lbS tbW1lCmudCz6JNj42SZhg1lqR8SDWa3WGSwVUSGz69yEPQumcWflTPfGy+ZYuTzcNHWpWNdQvSLh C+IpW69DuYpZVGFH/VyZTuLoquDrS48Z1lbwRORapVVQF/HUgHtJmq2WgUvY5mkA+xCzF+TK1gj4 GPIDwM8WeoFMV1kWJkRArVQwOZ02S0mp1sl1nf1+/GvDIauvdMa8XUwJXGgTCtlqtWNdgUdzYh5W VbliMbhBjUxCJgwsrr4+D5sOASeT0YTVXuMNkI/mXxG2qgZfXgpVoWzUMcC/KesLmgammQXiA00Y lI6ODgg4MN/K7DR2UAjIzKR20vQVs9amAAAgAElEQVQFItA1oD8TVatzYJRKMBmjxU2kH4zgbAah rz9p0iUZU17keTAB5fA64CkeD2RyebfLqdCZ+CkUCOnlpXQ5tI6qstICeu5DOowYzY5Pfy8DWtIa hqQDSJfJQ/l8U0AftqWtyENRyMRSequFyZ+IR+FY97b3PPD3l/5466JkOKEX8HgAJ1cNMxbHKYl0 hlnBPk1RJOgR3yxgkXrlRoJ2Y0SRVZkNuWiMADLdXV2CWcu3zHyj+6wnoEy+bjpF1yLxVEmhCUVi JpPV5XTCU0YrEe6azFjCeTxfoEFjNFh1nOllOg5taXtjSyxdVOZjlRV8IJlxw9uykSAxFaAwa4U4 OvSOkpnAXD/W5spYi3MYe2dOPpCa+Vwelx2cgWn593KJCH7t2rXMQ9KM7/dSrFTIv04BCUv96zT8 QUsoB2JAEZSTaTKLuYxOa4A9QA77dzSawJExcAhlZL1BF4sk1BpFXqHEZbKjwiwjqFkhb7aYooEU ICudRFpX9pCu06jYUDOpRCoRY7k0VtW2t3eoDSa5kE8l8marWYG/6FKhkmU/UwzFsyhI65UlfBdz QkwX2XBLYCmX0w1LQKnW51F+Rp4RT1ZbHYkw0VXyVrMTA6JEPK1Gc9xoQUuVNYhtlQWIO1sU6y+r sM1uiiJNjMSIYWEysbt3DxvW6veVw7GwYrI50UhOxtDa7XaDqAgy2NjQEg7BCSA+RpTwLlXVNcCF XDQ0rLk2HNRk8ZSezQOFSgUidhSdVgdM0WgMp8xO4AgiPMwSAZCpcHggfIdcqzdmE4lgOKIUUrU1 9QlVwY+9EjZpSj27bTQcdlhhlcW3dAaamhoAB4kYeuFBbCH7erpMRnx1GxV6IRCJYsGejkeTuQzH 8Z5+n9lmITy0oCJkCrjAoFbo8nL2iiIhSRgjeG+gQJysw2YkagcK1mV99QE1CHYv9nKEoWxO4A+d 0cD2ARcP20PMzrOUbzKD54rxNFtbPJrRoaOukWEtr9GR0OQSYcgFZmU7ZImnEO5QkhWf0gAK7EYk xE19xIgR3WmsCF1IaDS4OY/FK0radIz4cKEMukzp7K23/6VlzFh0lmsb6rLsoBa8xcvTqTSOTw1a DZMnm05p1XKFFn9hRm8opFfL0rl4Y407nEx6+nw2rRGeJZ70GXSGm32RcWSH5mBNG4b8fjKFTLYI 07A8TDQbrF/eOWQCeJeIPWaLDWcNjY0NaNZbjbog3h1KENiAnT82A8j7env7E/FEa2sbqtfQDWkM KArBFgI+GOgWsxYeXr5oMxv02SQu4wm7CGeSkHhlHRQqgvjw80iDRAEltBNywaRhO+dXLo7g3Plc 2NLAWCLAYopCWLALAAuX6BYDLuAJD2NWCMp8KRVLFOrrRiei6OVl2Xq5c4nlDBRYrG1oCuDQwtNL HBqtyhIJ4k8kZ1Yi10MjEeipymQzXm8Pzhn4cJM7oANeIYA1jDLk5aILkJdRJoCNEYs8RNioW2LQ l4rJdeZz518+Y8+psky8qs7d29luLqumwz1K1FbX9HRsBjhCeZhtNI+pyDcIWVg0EEBYrNYsdn2Z jMbusihLSZ2it6eXD5PHuMDH3Kmau8ZgiiczLndVLBpTqQrV7opgIFRX5faFe1DUr6iq9vsCMFXg iPcFfPV1NYFwjK5RdU9Hd4WzIo3yJbYbmNryT6nsvR2KsSawhjCL6OmQk+cHyOTDhBr0Ef4fnw8z gbbR8Z2N7eg+9XL4YfIwzZhs0IFh4voBei1V8TUUUCxYsOBrfv76n5jcgw+w1vDn9te2+dumWaSw Pht8/b8+wTcGcegmCS4SUIOLb0Dk07L88WGIBPya0wYqTbCTtbryvsjr7A1wfTi/Z7MEiZMhmECz RKVWhsPBgc2A8FcGJfFb8jkM96jToNcpCTkXihA7hp0JyUc56hYLk4ZAaRkWWaLoYdoGuEFoGIsQ pC+P1R6GOSFfnxYFELM1iQZNNmnUKMxG4lUYMfMjVBnNJoiXRsMukrSYTSa9Ng3Wy2ZYcWgYjHkY 0yaj0edHMFdiCRB3d7rAasj6zp0llT3SiNVPPAEPpK4ODgpaCGiGFWmMyJsB+bGgk2bV9np8+ApC cYQH4MNZbRY0kMA0LgeSrD4YTkZzmYuDzZJKJcd6KJMtx6lzuio8Xg+mjpVudxQDJbnMoELVnDOy IpEFjhhw4YgQhVWKKGZxbOmNWNUR2kVbLlCvK+YzFe4K2CFwBqmU6qideY+iEv7a0TPS6TlhI/wr mM1GuAtsIQQpM5pKeJNIZ/I+P8peepWanTgKtAW+oqMDNsKDDgE4OOgi8IDDyHJJT9lumSQQhxrY of0hjPYrtXodMIoa0UKDDQM0VCmUMPBoOROL6QX7n94ReM1pt/Eir4ssQAgOiGG5h/jQk92IgWDi MeXYACBpUp215LT5nDxhKMhlOZfKKQOiOzTMh2qNZdTUaXIrpC6YUwUmRoJIdrmMBg5lHgMBJp4i x+zJEnpFni2oi7ISfq3CsYCMALSprMXhkuO3zOdh12EboCWs/tQI3wJMzNCLX8RX7ioDEjyMCArY e8KjxDkFYgOC3OHiKR6N6JivKiW29z6fH36KAOOzADiLk4MDDChfVel2OB3wNcvC4nyOEMyxeJjm KQlnmaGDOEcIF/JoTxnzhaSpzFZhIhDAUM3D7Iu0CnKB8xgIAAHfI+QCVYAFxQSbPbXwE18c9ISG TGaGjF/JRxpltbgSyZBGiwqXNZkgwIqcCIzYOVI4vWYPFuEsb9FxaAIUJjQkXB271ZLPZSLhENa6 QAh4riwM2BsizTcawdnMOtB5Hj70kHRAkE2ZDLQ4vrSEIQZPIxpiqHmdc5eyzLfO213uqXvMFIr5 qgoH6ln0qIyz8nkmDHGdqqoqt2zZAh1oG0UxFSEFi3alwxVMRvMKGaNvUqgJmJylSK2KVQZAyZSD brxFAyAaa1oC5Whsd7N5VgWWPLTD9FoNXtbMVpvBYIQNJkPhUiHHEFIpl6G5yAmEiJDI120W/PKn QMbArGQ2reHrKxYpGdJBbc5g0I3JTM5XZs4P8ycEoXbqYgIg86WnIq3IoeM776JeBpQ51tjYyIiQ JgfQTJrED3/RX6YHd8aFASIyLENDGgpsTwpyBi+RRIN/7igh9kj8lTSJH76P37BGCUt9Q0L9q48x CcQlaXBaMPO4WPi+FZbCfhhFNT5dpivbODOSZRHZCl4EWcWAFKUSOunlDRgEw7Lb5fUQixTzbJNR z/YTDAXVOj0Aq5hOgKv4H3AKERUnUgT+WpRhi7jJsbCU476ypqaKtRVXy/B13E5dOJPLwnnAnbFK SIcCqIancnBRClazJZ3JljeDQIhtkjMsjArM5JEOsNfCNMLXHzyMQNBPgSBAugwY4vtnIWC7Yg3i jAUwcjldbFdksjmSoIM0m67xDNvw5s2b2X0x7Ra3MbPJCvsB1gtrPUXiHGtAY0GWiOAYAghk5vQM Iwo5YzQSNOo12fI5me6XVWKRzRGPz2AgbrJMls8TtLbIHqMs66DhoUA3cAZOlYq4GKBVcPsIDIKW Orw7QrQloxEjgcd08P8ilVVVm9o7LXaX0WJDhMf2g966RqUgVghbMhITPBxWOmz4YYqnQgqVzmKu QvemVEwVCjH8NQxw6ZSwRXQ6AsbxUtKANVkyx+AyVYAdzDlxe4ZWlbXVGzZuZC1he2XENVp9hasC L0e4pzKarcATrNyp3Wo2qpFEFrJen5/9jKJALZCU0sC1LMFs4dxFyjNJ2NqBbuVaLDJrthwrOqwK EfHQFDfkk/moJpKXq+1yPZb1/ZgulkqqcJKwz/5C0qYqJpGmyQGrhHAuQBGj1ZgiNqDCnMHoLhs1 6vE6asKyC55DP1JdUxlcgu3oGq1inlAvuy938Yv4yj2aiRFrsrwel335F+U4OADvoHONThjYolSk YiLg2eAyolKXLeg0WEmCrQlChz0g+xwuP0JALuRryOKQkZVDL+s1Kchd5OyB+JdQzlaEe6msT6tT gAyxu0ike4E7zEY+K1oIARkCCuTO7IF0TD9aRPuxn2D34mIm8yvbKsSEa8WvJCghSeBII5EzU8W8 EWU+JXZ82YTTXh3FCq1sf1C2wGKSczagFihD3GMaDyIliApfJWcYpN4wZIpwgDPJSCyAY0yHA7Fv Ip3Oq/HsJAxNB84wNI/hhs58KVRBm5ubm1E7o2HMW6SlLBScr5RafSSRcdsNQZ+Hb9DIMHl9fFOU UA7MTGjlAdRC9yEFbeYzpLXpSExh1KaLgOicGksVlRq3Ff5kjGiCIqGggDjEUIMaoWMqlUYgC0wk CjsDXyrkAfpYbxDuCUd2+VI5qCi+SPCcYjObMAioq6uJBEJOuxVOLQe/cDJuc7uy6Qzl006mEKSD 5txpobhnU+kPfDFvaQNkQf4LmBaxI22gSTu1JdCWjsMrFb9caDJYI+354S86S5PEjjPc/5exlCRt /eGn379UIzynRJIVNQ5XakBDb8C7DzFs8+V9kZi7xD7jGQMKQTpdMIS+USMq5UjZ4FQhG+JIx36M C0icIPi8nKn6OaeywsJQQTbn6e9DqxpXfsjcOAHC6cHuxxcIEKQetk4aLhEsrrJyD8yHglGjk8Oy Ucoph/2up7evsrIaCR3gDB4Ly6/X58WkDsOpcCiGNMNoNGQyZRkBmzpiETYhVlvutJOL+CHIZXRa PStseRuDT0a4vmyan/iTozxPcmc1505OIpkGug14e4cJVzZNYhEDmoIIYWthPaRAjokfIaIaa9X5 XArmDZICbKOSmOeV+TEaJAtQDc+fBXSPy7oinLSBZez0erZqs9UCnwktEqcTXRYO6nF0rHValVZB CFr0onPVVZjm9bcOawvjSxBDe4Oxr9+D7JW9Co02uGHUwuEbgz2YGigVEZ5Wq8d9lJz+0FCDTovW CEwh3PkQGwT7QfyzwwhkVWLDGLzTfsph1ADBrooKYn/gAIzRAk71efxGk8UXjuEJs9fjRwWXmvEP iVMwRTELB4VyWObAK5BLVH+BmOyIICdGgdW/pgY17Tj7AZtrKh9DYwwxGfwPJCdEpNUYbU4kvEp1 PpPFRE1v0POK0WrJJOKwHrPJcFWl06iDAZlGIwr1c18oqjFa8OtktWOiZQtHwlGvBzM6BhS2J3CB 9ogoip2e/YBKuXb0MVjtVrhGoGpayE7OLMD4MZNK6lUylQzqaZC64lktxqyUqzAmYJpBREAshcMW gcUH54rXmUMD1aGMBFuurOPCHJAJ8lQ6BlpGpom6MG7JUsmcRgNUK/M8mJ/QhwazX9JmdkoICGyC uwOc4ivjT/J5jDtdYAthmCDjwDS2iA+YjGYC0sFPUjMPU+AiPj1VKABtVex/dIqKSPMiF0UNHIgK nAeYPxijcrEtY5FBS8BVuJKHPxcIEeipYLVYyihnB3SAwgw6w82L1MKTfDjIvol2DXcJK75kIkFf aJA/hPcERcTXzyfMnPQApHDjJJPxKwuCKBqmBForcjEhHa2CYkaDkeHTlwFx2QiU6ipcLiaVCC94 nR4xVai6PLWyOQdnpGiU19GXKn9r2PNGI4yUyWz2EKKK01rZiWgM0Bwi2rrdHfaEa/FKGgw6nfYc Uk6HrdPbT1EUyGwRPw16R70QcEfzZ2fnQwGaxCAy+uI0puO0bWfXSy2MCDMQCkBkaocOJHZ2vVL5 /5QCW5kl2z/HCJHJ/SuJwUzyxYEceKQsUOdP8WKwucS0mC/mlPknAxc/rf43s+OL281qb1EZ7La7 MnGlNZquspiEaPCDlMGtLjXjVA+OfmV1BCXmmF9VSlcbUIJpZT3y10ebQBRrdRuLOk11rM6cFtqt 67FKc/XVKgTzGnlHNSX1os4hrJfBKDI5vWmULNZnA3wPFQG8Ons/1ypXb+r59aTpmlwoYMpFivqK UmWmCFu+zC4Wv08oJtI5nY/gtFkoqAkVkcQ8x2XzhT1KrbxGSIdl5rjCEqdJZpkCh0kaczCn4tBX q4ikMoW4tlYW6a0wxD56b21y7E/G1QuW4GaUGKLOcUj5jb51wKBudWNCtml4voaoXpu1UZtTptrc 7bDWd+vNFWFFxLBMpa2TRSxOsye4WZFS18mbNxuiTqYEzWNwWezoFEsqp2FWme0nFTms9UwBHh78 VZwVrBHkiJNt28TX5IszUJxmInF4keV1cEX7ygMiPSHp4EXOti0ZbJKUkCggUUCiwNdTgOWFlQQn yaNGjWLZAWezWJHz9W/9i7+KC93bb79NtHKKojoWQBLk/4slf7fXWUJpAHfwHCv//2U7vp078N9t eH6Ut6LBiMWsdla7kEK89vq7h//sCGyCaut2223abuf8zxkwlbOZBO4xCQaCsjNKSnqb7fNN7Qaz SzCoo4F+i8GcjSeQfXG4NxschFpT69C0KLgrarz+IIHp0GshGgOHcaPVGkHz2lUDrszmc4gh+P4A TZwU0XEGgnLiQW1WhAiDQGGQJsiGyvZNHPFNBg7fKO6gWIDeE8ZpRDxlTuNymmMlp2qP15/K5HFZ HgqA23Qenx++S6az66ijjvx42WftW3xKtDlkgsMsC4fKqkLoVDmsaCwZOLkaHWqbxerzeCtramkc pncD0f1QjimhRe7p7LBXOtUaAb/PnFyBIyJqoeWwiJB3gKgGG/yVBD0CSw32i4S4OgzmiH/SEfH6 Sj6liQ+I968UPvjTV/K/8tbgYyS2f1LKkSggUUCigEQBiQLfigISltpKLovWHPR3CKrsn66/8/DD j0nn43976K5XFz++/5z9Fz312JZN7U2NFm+/H+9N2WwhnUv4U9FhLZNCESHQu9k8qhKZSKu9UZb1 6EyyfEHltjcEA10KVRa/1m5nI+FYiEuC5YvL5sQMw+Ku8ESJd5bSlvnkYCPkS9ocKrsoTeCox1A2 jhIZeCLs2HbL16CFk0xi0ZPOli3jsBbOJePoj2AMjzk0Yg7MyyKhEHoPNmcF4g+fpw89XZQ1Kmsq kIRg2Y5yus1kdFe6CORASJmOnhiHm3g0CkrrxwESsI6AJjEhHAwB/giagaq1AXGFWqBduEPS66zu 5vrXXnrm00826DSIAsvx9hCjwOhGxgGrnztHtB3NQpELtW3vRLQ0mD/Y2W2xlPjMIK6i8G0BGX9u C48G04NtoKhtS9g2PfiMlJAoIFFAooBEAYkC340CEpb6km6pktmY+2zp69feeOfo8XPu/t/bDjxk 71HDJ9208MYVy97ffVojET3NRjtKF7CA1Dq8ocj8KUGlsTvaqiJrlqtlBtCE3oTSUTBBhKysUpDH lepMKo4/N3Rx0uhPGHUY++TwXFRMpXIFlHpV2KcE+7risQjaNoS4yhbLNu3o5iQiZUcAg3BhcO8H JWSTaJZnYEKF4xE8FaFljLcch14TJxAJQbJQB0F5leBXMnkgEg8nc/JizlBD3DGFN5iOJcvWbT1d HgUyQrXQ3++BjYRmktOBijdeQwk+j85RKZ8hHCw61Cqzzhj0+V12B9Y3FosQ8Eeq3PWpRKl/8/rf nX/6okXPZdPlF0FOQCj428j4aCGcKlSaviTrV//lea7te7dtDoWIr9EdMX+QFCJOgiBi/uCTPD/4 k0gu8c/B6sU/t78PPiAlJApIFJAoIFFAosB3o4CEpbbSTZ4qmayateuXKQTXBRddP6ytyRfscNmb ZJlSY42zq3N9OunfvL597KipI0aMwRnS3ffcWCoI3v5cKdp1+lnHP//s20cdcaLK1HbQIbPDgcIl Fy2sa51cUWXz9CVw2ZcrhE44+pg7brl14i4TiDI7c9asnr4+rUFfkAm33nT984ue6ff4AFLEHMF2 TK9V69VlUMIlwoJBPAEKScWTJoMJVVuFSpFKx9PJiEklf/uFRaMn7GrRqNtaWj/5eKnFaX/woYdO /59zFTqzSada/OD903ff4+MVq8pxRpNp1CPXrlqx54x9Ro/b/cgjj1yx4rNoXABRHXTQwa+++urP fnpETVvNgfvt39Xe0d3VaTWZP1n28cTxu1hsrjl777tpA/6f5J+uWNreFbz33nuGNY1/5ZVXUCSH iOAedE5pKppS6DvvaDoO9ugriGfwTzExeBeBF39S8uAzUGYwf4BO/7ht+8yO2iDlSxSQKCBRQKKA RIHvkQISltpKTJdR4+9e+t4HL7e17jp2/Mh+QlK4dD5PQifXlnLx2mp9Jh3aa9Y++8w59OmnFy16 8ZGrLr/sntuf02NIr06/9+Hnp585v6l1yisvXP356s8nt03AZu7Vl6+3OYRrr/ozortkxvfG669e d821+87d54EHHmhvb587b59IPKbQqPGJh6dBvLjg4iiTL2GeBl8qGQ0NjrGIqIAO4qWSKbG6i+DC Do/NuNHMJDLR0FknnXTcb057Z+X6p55d1FhflyhHuZd1dPdnBCKwRGqqKleu2wTbCr4UJmB1Nbbr fv+7w396+KKn7/9o2dpf//pXfb39+MlEz+nUow6YPGHis397EhWrVxa/XOmqWPnZ5wcddMBpJ5/y 1tsvjx8/+YRjzyjmhepqd2Wl8NOfHvHUU682NTWJBk2AGFHShwYirKnB9n8lwWP0aNtMQJh4kSli IhEPcR8EkV8BUjy2bY5YmkgosYTBOz99WfzQ/27bEiktUUCigEQBiQISBb4DBX4cB1/foaE7+5V0 hHAZgtGkQGxHLJYU5uuIu5TGdCycLgSKQmbJWy/H06E/3/xnOf4BlNUX/+6wCy9ecNJRB/V0rHZU CCeefdNPf7G3Q/a6wSjsd+BxC6+9vE750sxZU15e0UPYtkwu4jTbF9y68JijfyHvCdz/wAN7nfCT jZs31dYMR9yGZT4BqlJZQV4U8B6ELztLQZGVl40j6LUIEURgQRrFJaz6CcAry+IQr2w/nUvGMPL+ 8JMVhx4jn7LrJJssnfFsgIeDu3PMx/UaZSSXxVFSOJbIFkAxsv6+0ANPvzxj1mRN77JXXnpi6v4n EgXWYCV+mX/hXY/ut9/wYbkatOB9OEzo61/1+ecmnXGfufvg/G/2rDnnPv50wC80NNaOGlOHt98R w0c7FT7aiY4WTYUjhZ3wIAb6p0MmohvUreiX2FnxFf4EKolpSiPBMzwgPsmfpMUHtn2LfJFW2xe4 bQn8OngNlsMD0iVRQKKARAGJAhIFvhsFJL7UVroZNGzFxMRQbdjQ2dGJTVwxkgpo1ThLtFrMBpks t+Tt1w874OhEXCDCRi6fbqq1Y+gXCwo11c6uHmHEqImCSiCUiVYnjBwxVqshXJeC8HAmo12lBGSo Mqm00+Ho8+Eyu0gIJwGPyT4vXiFxvS2KrwacDpflWLiQTuJt5UtXJeADESKIGAUf0GCpstM8HHKW cKckdzlsD/3tr5+tXD17V6SHe61YsRydcXSY8KCYSAv4T8LXUbZQxKEwfh5xXKHCS0sR79V4PB9A JMXihg0bBsIyCATlQPecFo4dM5bWogD16cefoGW/z5w54yZPuPDCi3VGZyScJtQLTnZwIATWo53o wtNCVKbQQ4cjhQkhOf90OvLikNdAd//R5cE/vyYh1sUDJLZ/TPx1yLrI/KftlB6QKCBRQKKARAGJ Al9PAQlLbaVPWNPjS01vGffbWPG1T96+oyZVowyMklkKoVIoVrIW5GMm7HrIS28+ozEFctmoPOtE aTua1Mj1QiRfsLqFULAzHxHc6iT7eSYlS8XwoaA0EHs916tQCQSRMKllslSVWlmpNCs6fFuEUl29 a2o+GQ7qmx05bYs8kVZ3R2x5o9auSWgKcmJZbL1gwIAPYKWAVOD6EL1FZiLWXkSdLykL6lTB5JW7 9eP36ehfsnnJy5GPVy64+Q6v2ZGLCel1m6pxH5YvBnQWQSlYcuuM8f5oqTZlay4Wg8lMj0nf0N+T EczZ1uEOheAs5W35ki9DCDpXZ1j4IEH4FqF55Pjdi4Jyxee+zo6+Lz7u6dj0SO3wTSVTQ0ThDEQ/ tWTKWIqG4jUKNXb0paAm3ClM+XY07cTu8Bad4kUEgtxJD2KdQaYRmuxc5JMj3gd/IsFPVAG+FAsh QQ4k4hLfokwyxYs0mVzbliDWuKN2SvkSBSQKSBTYEQXERUn8VVxqWNm4dvT895XPqoXFNKscCc7D 3MXav6/ypXK+MwUkLLWVdASzczkrpk+bXl1Tc975511zzTUlobh+/TpCl/zud7/DcTC+0ZjBt99+ Ozyhjz766A9/uP2gQ/bV6nE2re3vJba8uboazAQ6ENLZuE4vEPMrEiFEfSSeEIiGgguD2+64bf2G 7p7enjPPOKNm3LimxgaXwxGORj5f+XlnewespACewj0eABOxacWdfvs7LtFQSwIi1FTX0B4+JJw5 LV26dOXKtYSqqKtqhFUUDPnzRXTMsx2d61Ys/2LW7vP0bmI4ZPAdBUeNuBbPLHocUzviYCxa9Gxd SwvQh7hdkSjR9woNNcN7unwGvYWwacTcmDRpnFGpuvSyyxD4WW3Wd5a8iwMHeHVmk/mRRx4JhiJo WRHg5corrzzrrLNolRgV5GvWlO17JOZsi3K2TW8PgMRVbNtnvkmaWhhp8U4Cug3eSUiXRAGJAhIF vjkFWOJY7lhGWFJYf7BiZjXm+uYlfLcnqZTTo7jAiivndytHeut7p4CEpbaS1GKxEcOkoqLyvXff O/fcc674w/zaOtfkKRMnT57M3CUuxLhx42699dZbbrkFYdYBBxxw9FGHXnHl6QRdgAtVUy2EI55I VLAY8XFusNq1Kg358gpnQ229k8i1dmuNWq956ZXFs6ZOnDBhPK5xH37wfrVC8Hv6jz3h+KXLlp0H XOvqGTNiNDF3s7lsqey8c+grFAoS1ALZIGG2CJZSVV1F4vTTT5+z+5zp0/ZUyNWnnnpqVYVr8uSx TY1VB+w+8vDDfnH7nX9N9gRMZitcHrmiEE/6+73te02ZssvUXd55592bb765rWVYR0e7w+6ES7Ru XXfd6N0AhUSwEEqF4SObnmn2xUAAACAASURBVH3ukUWLHpyy60SHU3/00cd0dfYSueyYY36hUMKs q/vwww83bty4du1awBlxJzgzIV78DlhqgG009I11iksEVYPQavBRyCSmxcTQVBtwRjwIpMQhF+HU 9/5FSQVKFJAo8H+HAiwjXEAcLhI7u+MsrVxiRRKW2tnU/lblSzFktpKLcF1Wiw0daj4HzhhERCdB mCqNthwgFu4LHBeUgQb0imRYrjnkKa+uLpcXajV9vZvWmUbOiiYFc+iDXFobNE8ggIoruZbga1+k 6twVuvzmN+dNOPD8exfPOXjPfNfnJSRXTWPjIaEp3xXPqjZ0bFnTvnHegQegA24mxBMRsYpCMJMY eiCJGqdU4fCpssKdiiX6e3urK6tguXQUYlVBo1zQK4ap+6Lt9WlirRd8VkdVQh+UpSvrnJvb29vs Dnk+2x3zFq26vKC39iXggSXqrH19vRNcLWmfL1BBuDlkkMvtxMBS1IGW6rWBYGdHsmpSKbClVNTh 97y61hyMbHI47CG/IhUzVOC7Si6HLHzhSPdIlwWRyST4Zsj289iQ+aClIfMBsuSLq8bg2kEC2Md9 8CcxMXgn8ZWLlY6cbUsQXxfzv/Kw9KdEAYkCEgW+hgKsbywdrCGffPLJ8OHDWb7YJrh/TciHrynt W/3EZkSlnO2R8SFSYIX8ATDcjloIBUQ6SDFkht7AdkS4/+J8vdYUjQJfgAJqoirV1FQNaFgbY7EE TKlBtmpbWxt4C7iQ8iU7g71lSOGN2C0NXUEM2Uo1luasvJQ2YncmFHI6ldXhNGmzhazdVJvMpbLF LMrglTbwkm6lJ+kw6X1dPSVzld3pMHh6VcTXVWszOBDPF90Opzw3NMswVyiizM7ExcxOr9E5nU6A C2FxNfmUtcaa8Ze6QzGDRaeWCelk2mozKzNCdYVzXXfvmMbGrnXrqxxWAAjhe2NJOQw2vkZgEJFQ M/hlUKv5Sgtp3ciq2kwili3mlcQ57u2217h9sYhBUax0V8plAmGVjUZgZbJQJPCMOo0H0GTS5XLx UfE6d+iDxBD1qSFnC2DrW+UPYjJK5kXxTkIshz/FnMHEkIVv++LgAz/iAjTYBikhUUCiwH8oBcQ1 hwUK0R4oik2B+84+m7HusfiLqyJ1DTKopNXsR59FEpbaOgQyGR+EQBj4WDwCwigJBQLMu/R2tVqL swDOHGAOEBUCLDgiwIV6oxMdpFwuZnM0oH1jNBbIT/pLeltlrhDTabQalSMXyMQNMfSulOHCzbfd PPmQOfG8QGC+XDZtM7vxgFDpcq4PJwulIi7Rc6k00iqL2YKitT8SQvw+5OSwWs1+n89kMKrRaS8W 5QpltliOVC9TZGIej1bjUKnl4VDIkMDTujuSLhhleV8gTgDBdm+/w2ZXyFUatSmVLAaDoWZHUzES MZnKeu6oZdN+DYrtSlUunZDJBXKMBpUyqY77QyqjiyjtKFQl47iNUIVCkYbG6qJJn4qjBxaBSwdB xDWF7xzqfY1/KRH6DNm1ITO/8vw/XTJ29MC3LWfIxkiZEgUkCkgUgAKsmdxZ9FhYuLPuicpSX1ln dgattpXxUf6OVrydUbVU5tdQYGgmwde88N/6UyRMWDolVmXxWBxDNFw3ccxIJsvR7eCjAlbQBILd wqfCV4RTg0Q0UyjFBDmK5bpUtBCJ+RTKgt5amYsUonFPMuUXitpinuh5eXxWWc1V8w7YN5kt4olT qVKEwyGNWlDKBSIDGyxmCtTr9HizUgiydBJ+TwFl9R1dIBV+AvfwCXHxAcM2Q1eJeDUaXZFfisVs haNCrzOXf1Qa9CaFIM8olGiFm7UaXcAfNZtcKoUJTlKqHIcYp5oyTOnoF8sB+pSFYq5YyiBw42X0 ovQmq9HiMuo16XTC6SRqskEmKI1Gi1KmRE8+FgtzFIM+3GkGVKIvlLMjphSTh4qGvMTubH8fnG9D /iRm8sz2v34lh0oHixpM8MxgWkpIFJAoIFHgG1KAtQ5MwzrMvoAxEKdHuPIszuTv1AshAHVREe0U 9wgWsR0pTnzDvkiPfS8UkPhSW8nocDhRntagNa7VAgjKcqsKl9/vBQbxqYAVWlpaenp6MOIDvnR3 d9caajK5XrPZEt0MOuG/OILjVCBLrGIizAAqigW5RmUoFvujsZhT1kQEPa1OLtfpE/EeeEsbfVF1 UVZh0PuFElCmQHCYRLKmpjaRIm5xFrOQIfd+2sqni+55JBQG8ihlcsCQ2WhCSF9SJXL5hEypzxey SAlTqaxGKYtFM/qMV6lXmc1Ggs8UYkWns3Jzj0dX4y6WUrxFLOLVEW9ZxhdN6w0GhaKQySXTmbhG Rzdlfn/UJk+qVLp4Vqh02AL+oFAy5fNF3GL19vcpVUYi3sjlfNdZKMb3TJtFnFdVVRWLxYacoDvq 15APD2YOgp7BBD+RpjQxR0wM/jn44rYJsWrx+W3L2fYZKS1RQKKARIF/SgEWOlY8cafgvM16ApYi k53in777rzwADwwAx0UhpKmRqmkJ6X+lWOndf50Cku75v07Db1QCGznnFeY9s1/8APgOuQBqXJjC zZgxgwf4FIEmAyyioXW0v1Fl0kMSBSQKSBSQKLDTKCCu5ICY9957DyVaePPogZDJSVs8s+20mv+9 Chb3Ne7sWSC8p556Ck180iLO487FpiYmxL1PvG+fQyHixQNfJrcKE8Q/6TmJf6/+b9MaSca3DTGk pEQBiQISBSQKSBSQKCBR4FtSQMJS35Jg0uMSBSQKSBSQKCBRQKKARIFtKCBhqW2IISUlCkgUkCgg UUCigEQBiQLfkgISlvqWBJMelyggUUCigEQBiQISBSQKbEMBCUttQwwpKVFAooBEAYkCEgUkCkgU +JYUkLDUtySY9LhEAYkCEgUkCkgUkCggUWAbCuxcZxjbVCQlJQpIFPjuFMDc+rvZA/OiWOt3e/27 t1h6U6LAfxQFBr+U/6hWS439d6GAhKV+5JHAlwb+pcQAdjjhxGEJDcLR1I/crO+jetH/LyuUuEiJ PkJwqUViW0cjojeRb9vlb/u82CGxDaQHE2LbxDv5gwmVquwtZmsXeF50bUJM5VKxNOBlXShRyFbX w+Ue4Yx14IWtFcll4n940hdzvnIvKYZmCeO2VWwbNQ6UV24DDVGpNF8pQfxTOYCUeHLwV14nXZDj Om7gVYEGD7RfKHttwZ39QLHlnpVfkg2QgliQO2iPLFeekFubxD+UMfCO6C1wsNLBBJ5kKJ+CqZ3/ BtIQjDhK5f4OOIcZKKD8QjmhFIamT7EwtO9BwkSWWzFwlQfgy8FQlMreC7e/CrKhYzERPpyLogZa Ue6fmEjj7H+oi15R1+BVfmHgFeIPDGZum1ARhmmoC/eOZJffHbiLCf5mOIZ6XCgMkGz7n9Q7KD9b GrocebG0taR/kL/ciIJi6AoKecZ9oGsDTRwY+HJq6N4KAl7xBgoqP/Pl/8tdVBQz2zf+R8xRCbly Owc6xb/l7gyMYLo49HwbmMvlL1Fs82CC6HvRaFQM9oD/JOJo4atTDO6eTqdxg4xTZX7FRzm/koP3 KbGEb37nE8NRExevQ148V1Ep84QllDQJqhAfIDHYsG9evvTk90sBCUt9v/SUSvsnFBCRk7iU8f1z ibsIiX/y5v//846e31E+b1Mpv4pVcxcTLExiweKfg5UUsqkyhAFwDHhYHdz4CuV1tXyJBRZBTOUu yUsFMXvgJzAWu+MAmirsCEsNYIvB6gYTRfbyclPKzaMsGlBuAy5eSzvw3UpDym3Zlnrl3bIgF0Qo Qwf4sVzcgAM8eUlV7lK5XwNN/bJjxaG3VAKPlX/h7YEitv5TLr+81w5xlcBw5eZsew38/SU2Gihq ALeQTamlobHLjrBUvpQvUxt3z8TZ5v0vqyJ8AOntr4Js6PIZLx7euvF/2TdyCI65fSHlnP8/mxfF 2gsD3d3+FbmwAywlYrWtBB0g7EAvGJHtCyGHcRzyym074Ns8sSPsRTN5Y2BoePof/xI8YZu3/5Es EOKz/Fd5Ln059iK1h26nfKAXZbKUv7DyJb79jxL/PVIEaBhsCHOUtHgXlENjqa0d+fKdwT8Dgf/H 3ncA2FFVf09vr7ftm00vhBJCb4oFRUQQxAaC0rsggoBIVKr6pypSVFBBeleUXqW3ECAhpGf7vn29 TC/fb94k65q8l48IJJvNXMLsnfvu3HvumZl7f3POuedkp06digAYt9xyCyCOB5sAoQCn4AYdUwKu QPB44C3Pe2ej+7u24XX/4loPnM2aNWv77bdH1DJ0AVCFlvG9DTLg6xIZlABOrXuxf745OOBjqc3B 9a24T0wBI6PHLObJ4TA1rJnRRn77/2VGJrV1KnoNrlPonXqX4DiSQbknX/EKXVBUSyhnER8RaATy glpmbTn+AoN486+3aOAarOzuV21NEOMiFFxeqw9JAABM/bWnEXaBeAjM8FYiNOWQoMGFc0yDdlx5 SW2t88aIIwAYjoi5CvzlwjAXSUF+5pGEKJA1HAV+Q1LhkgpK3R5Rc6SF0RmqBiJQpdaMOyx3IXbQ /uha/8l7w6/xYE3XtUUcKyzqeH3VGnFP3BK6AYawPRb8p+E1ObQGbmM43nJVWwrdPhu1Y1H1xwUw 6HbvjatGlztAl/X16wP6upXXjro2QJfPDcgkGq1va+lZizjcBt0eXchbL5lre1znR/e+10vuUOol xCYHm9ZLeFrqgzXa5UONLzjUeOIdR2OR0f3gvfZuqMvCGgnesSbWHF1xM+cZjge/wYfaN4bLjzV3 oAHfPHLX5yqQzfDwcCwWO+mkkwCqEN4UoinIh4ClvEswEYEnwEMu/1x5cH35aCN24HJcAqg0f/78 55577plnntlzzz133313NOUJulzK13IckxgKGzXll28aDvg3YNPw2e9lDQewBGIWwIk7ja1NOPXm hY/OprVL6bpXbPj7b2T2Gcl49T0UBXJQvuYnV5yDhRVyB3fqxYRbW0iBjWpTcW39QzlOsRbhJxxx Aeke3OSusd4/4j/fwaNpdZutl9BgrS/3anTsYiH3S9+lpF51dxGuUexRjc7XcLZ2Pa6qLRUIgwrs UVvkQCEkVrgMa0ltyUMFl1CoDuq2X6Ozhp9cOkaquFKukZPRGYAy97Q2OK9979RlSY1RXnfu7XNJ doc4+vL/bx7Yzlussb57Y3ZvT+N2PCy4frOIpVbr3mMernczoLqB6sxloPe7e5XXnws/nUZ8gMBt /U5RAtRae5JqnaPTtQui3fA5qdsM4Vj1+YYbU/cCV06GvmsYwkXb7v0HhVC+/ufbZvSFLjuQ3I8B F0WuGTNG3uA5sfGmoDoGWEtexm2QHFtLDEmz7vtpuS+WK7B1KXT/ecS7p/+d3He5lkZGN3IKoAME gwitkEvheQZygpAbSj3ALNTxPtL+B9We176HjSDWmjt37l577fXyyy//61//SqfT++67LwxCoPJD Qr+ojBkMwMvHUh7fNuNxbD3om5ERftebjAOYldzp7L9To7lsY6naAJby+vU6QuejT5EfndCppiN4 NICBm9ZMubUaru4MCUWYY7FwrVE3UVAZYXGybOiIcF3tN3eOdpevukOwPUOn9X6rdeLN7O6i7RHg NthgbaZMrGGYybHkuSsZusMl7nUQpICk2kqANmuCnNrCiGV0bavuAolVxO2NNEbpPkYTtYbMNYOo NVf7mabqr8GY2Gu/u8S4q9Tag+HaOdUYViMXCzSwCSo4DQQXYKR78XrJIGtqVQASF4y5YABjRCJr hobrVQdD6mNQC/3Wxr5m/GtOCGgQ128EJTUEBx7jV/fpBZNxr11WN9ANrXlo1mtrDYQFx9fc5BoX SMJswAezPjQiKLM+lnIxQr0EttX45JKM/3HAf7VUr3btruGhcWPn1kCvVxVXNJZL1b4C1rC0Njyw FPLRjRPH1CfmEyzVTXf07p2z3Fe2dhfc559twGcMHL2746kdRzIATMBJ0PShHFo2sAliKuAqACxc AnADfR9+AuKBaArR+pDfqASc5NnR4ipAqF133bWjo+OKK65AX3vvvbcH1yC4QkcAbR6o2qj2/cqf OAd8LPWJs9RvcEMc8CZlr8bo/IauqfebN8fV+6VhGS7xpsKRDKqixCv0LsNPmGbdckbyFh33FNOp N+lCfgPlFiohude6CidX5+RiKhfHYOV25+marMVbVlyxVb3k2WKv/wtWL7TrEeriBLdN9/8GSyRq WC6KqkWMR2u1NQJ4zoFtu7sI4DKXciAtyoEWxtU4Agq4I6s1W1vuat0RDeyKIHcDGev/B2P19Yl3 CXDFXaP+8xYhV+5l1DhdE5C5yM/lG35cY5azXltg6XplboGruHSBGFIN1rhDdPnkkPXpIZj6NvuO XZv63HsPbteegxpcBWZq0C90WK6RllsfvLMs24TdikU00K3YDW68S2vtaardZRzcvtGj3cDeC1LE ugm01C0H0qxbbuJ+1fhk13S77gPs8o2A0rdufZj/4VHEM4N/LqkYspvwONXHpowAPruDcYcEHtXG hVPHUOq2v7kKSZpxn3fY9OMRBCBH8gCjqdclCWDFHVAtoa43PrAOQKdcLkNuhOOTTz6JyPQAUqjg 6fiAb7xNNmAZLgWuGrHLrNvL+oWyLEPQhcZxeTKZBEQDJccee+zdd98diUR22mknIDkPSOFa5EHP +o34JZuSAz6W2pTc9vtyF3t3El+bMFPgtDZT1V8D1lZc9+/oRkb/hqZGn66T934d6c479ZrCxITK I5cblAC6XGsprK615a92FfQCmE9R4JahhIKSx11gKcbVp2GFJfAPF7o/j2ptHTJwiuvWL0QJTWCu R0LWXYnc9culAUKF+nIIx8Rih3US0MltEJVrNNTkNi6hILIGPIC23MUD7bjkrW0TnF+z7DUQn2HN 8exs0HZt0LWDS9wohR9ORyVwAxjTPbhtu827g6nCht1dvsAuLM6gpGYYBnlYA+Nqu0E5hAluMy6G dVuuDQesBqSsz09YZI2i7T/ZGpZySXP/96it0ak3kmO50MJlIOrjlkCKZ1oQP+A21u/XaIClPArc Tms9j2T02uP3H/rW5hqI5wg8b2ur/Ndfs/bg/VdR7URfo8IFx8CQNS+g9zCsXxkleB1wpxiSoUnX EApPIErwEOLhaVAfzy1+cQc0MiicbrRApm7rn1yh6gmmarMQ7qU7QvxxNeD1x4V7jc5x52uDcjMe LdCpQRoEe6k33njjJz/5yVVXXXXQQQf19fWdf/75xx13HKzFUQ34CTAIF3qQaKMGAVEWXjW0AFgG nIRG0B16hxH6ihUrOjs7p0yZ4hljAXJ5s81Gte9X/sQ54GOpT5ylfoMb4oA3N42u4U1So0s+Sv5/ mD68jnAcyaCjEXpGGvQyQ5WSK7qpJY8e70Lb9R2AKm6t2hyM+c2dZ2tYypXtI+Ei/Iw1pYYm6s/R jXwi0IyHpdypHbDHIwCtQdxVly2ODokDhZndm+VRH/MvKjvsmiUTtLkkuuYcQAMuyHNbqyVvCDVu oLx++1wNS6FrV5jlLqWuMAP/1a6qQ5FXjqOXgJ08JpRVGSU1SlxSatIAt4qhVOq0gvvSABuheKQd ZGpooIalDLVuOwRTX95A1PZXuhTUFtGRjNbAJwJPuxxGQk2PyVjkcK8prr4Sq5FPBI/IdTrFKZRB delvtC+vUfvw2VG3HUijRneNvEeDK2etlyBYwV1iGBY3CxzCE117sNcYRa1/BUnCyNotRrO1lmsH nK7dv7n+JZulhHdy3nuN3nE3WYZlOYyRSYRcldz6CfcaI8ERlWuvjstGlODuFwoF4Buo23CEZAii IwCgBx988Pvf/z4KX3rppe7u7v333x9m6agMNq7f+AZKgJ+8DYDoq3YLXJNztP/5z3/+4Ycfhj4R oArNol/8Cpv3DTTl/7RpOOBjqU3D562uF8w+GLM3oeLoTUPuStwgYapq8ItbPDKLjWS8ncAjpyOZ Ro00at+Itghylq4UKqaQZlqGSb4oK5X8wDBpOaYRlngYUihyFSot7AAyTDu1EbNWw8HWiKyvK6ny Ki+wslKlGGhxsGmQlqSwLGuUXn+urzfe2h6yhiJ/rHj4tyFu12vz45et718H/MG/NfuePnYHrsHv xqRGU1+j8pG2QTMYCAhVQ1EN+TxS/78yjZ5DLNb/VW9zn1DU+s+biwa893p96vANsH7hGCzRyTZV VYIBkbIMQq+IJN4ruTkRyTtMLCiEWYvUyoShuPCFZmEyiSEAROLoARpkMNWgJC4aWYXjLCcm92vF bDfbPp0LzGYWl1e8nbanZcs9hQ/+8stTnpu24EglaUZ1sVSVm5vD/f3DkWjQNFXT0gxTg0Q0KHYN Z/raO+KF0jCgEkUKps6ois2L6MT1s4IjnCzgAwkJDw/w04wZM5YtWzZ9+vRQKATIBSQHmIXyMcjt rYqkLeMF2KpuyfgY7DooCoPyShqNrtEag9nEu3YELY207DXlAbWROo16adQ+bDfx/c0LQlVhqrIy UK4OZQbk4kAwMsfQtQoWTduSZVcawYtw6EIOcyj6FJNQ1iDLVzWnZo/kmJbBC4quGxw/9Cn26je9 qTjQ6DlshFE2FV3r9rOxdOINWbeJMXmuOfhQkcvYAed6MLMCPCNxNCsGWEYzeBpSOndFxNsOmFNL brb2KTgyGq8ctlK2HaI59uabb86WFUAZTdOzQ/1n//CUfb9746SZ2XPO+ctKh9hj5932PGTCA1fc zPDU0FAB1pTpoSFewHcZVIt4zVVTy0O2VC5XLNPOZLICH6IISVEMsuY7F33hwQCcApDCEXngLYAn SDGBoqBhhHkW6uAURI5Q6Gc2Cwd8LLVZ2D7+O8VnHF5yjNOberzMBobdaO4euXCddrz6XqE32SHv TnsN5pRG7ZO2iVmN5QRTtgoVOT1cyQynWadayrzjmhdDukZSnv5FFHjMaLrUyHPQBga3ET+Zigr0 hKnZ2yin65oOkxWSMNjSRrTiVx2rHHA3CtRLUJ/WK95sZRtLJ96+zUbrxnRsOqSqathl524poeg8 zaJkqGzsPas1CCzFQXdaM+uDSBhTl+dwZNSUMjJMmJMbFaOkq5joAiyJDX2KInMc+9JLr+9/tNDU 1LTDDgz95qTTbrypaWYVV8EwK1coxKLhsqGiA8wtFEnznKirhiCG8oViICDoOtASQdEOkBZmGm8q 86Y1TF9eBt1BHAX1H/R6gFYox6TUaNLbGMb4dT8uB3ws9XE56F9flwPey4+fMAUgeZm6Nb3CRlhn 5MJ12hmZPpDx2vcyjdppVM660Vag8qLxaVlV4aXcCkjCxKbYRDFDMqJqU6wYgoIP7sgFltZVmSvW 98O0gaFt1E95keFYAZvzGNj8Eo6qlCjSDAYFRW7ZqHb8ymOTA64NXb3kGqGNpbSxdG4hUMplMSCI IEqGQ8kWPVDSVg4WVEqUq1U9wGFHAiYKmPW5Nwm3pPZ5ts5tQSFaKOQLTU3TGV05+uijn5q/NBaP Az+Zfe7kALgTiUinnnrqgYffOHfHOaGJOdEQVb0owWCAYyLRMCRM+EaCmSPcpDuWqakyRcFKkg0G o5BOoXlRguRpzVYYb1qDFg+domtYZUGOhYSO8I3nUQhgh/J16PRPNzEHfCy1iRm+FXU3Ancw5rqz 0mhejK48unydC9c5HV3Tyzdqp1E5jRgm8GVEsrpNIS4HNvbAlmJKV8c+nS02Kw1XTEKI0Bxt6VaA o3S53MKG1+/0EyzpZ1WGEGA7QzvwvU7gY5ckqkkxLhtjy57mExzyVtVUI8RUH2FtPtZsLJ2N3q/N N4KGPeMbhaMJmPoXTGJRry473QoBmVAOajSMGgNxx+JhQyBK73RtY5h/vATFm6GptKpAy5bL5SEl giwZiEdTCYEXNFVduWJlimiKRDCl0IXhAhvQU6lkpQILfTfyAMcJyJhudE/NtJhkIlUslmrfe3jN gbUgu/pPQufoFOc4ulCvJidbQ8cWhGHX8nC8/vWx1Hi9s2NiXN4L75GC/AZo+v/+OlLBy4wc18/U 7WXk8nV+dbEUtj7Rgk0y8DxgOQhuqwsssFWLohP93XYF2+AREFWlYyJhq+Ibn/IbQ5nuJn5E3qUs gseMr6B7a/p0uiW+DuH+6RbJgUbPobdAjp0hbSydYw0LNuIk4FItPA7BWabowNmlYmkyAvU4AsBK zTUCZFK1bSG4I7VdqPjrgpjRR5yGI+EBXe9qanp56dJJkyZCKAUEBFyVSHKGiZjELLbvSaJUrhCJ Vi4U5GipWizl0QxDI0SxoGuGu2MXyIhGNGpYEZiiEIJPqUBQhARK1aqeiwyvU4zFE0qhX4ighoaG 4A0BeUA3VEC/ntOERkP2yzcNBz7llWHTDMLvZexxAK86EugandkAmV7luhXqtoPJxWt8nS5q33Z1 mmnUPofPPFhFOQTMJmA/AckUHAkz8J4UIrCRSaeoCvxjOwQk7hwMKGxW/ZTFQ2KAdz2QA0sZBLbb k4SEDdvheAPNUJ2B+kVjmgNY/MY0fWuJ21LoXEvvR/2LN53G20UYhKlJ2CNLGTzcY5AW5o2anw4g KddbqyegogC7XNcnbvI68GYzbzJhaGY4nYZnqff75VwuKwgzTQXBhnVAnEBARKSXAWWgp7ufa6En RpqHi4O33fa3gw46pKO9i6bYJ594JhZL7L7bHoxgvPfu4tdfXXDcsScBPwk8LOFN9+Uf1S+6AwGY 8ZCQB5CCjRRMpkCSZyzlVfioLPDrfToc8LHUp8PXrb5VvN5IYMPozAa44lWuW6FuO+sXjpRsoJH1 f+JZ2kb8Dss2XLtPBsCFZZmAKNiOLJOSTA2pdJAWAppVUljC1vMp/dMVEA2KsIHgGCcAt5DwIG7T aY4p2MT09Sn3S3wOjB0OYJEfO8RsgBJ8MrGe+xX4t2VIHlHJbZ20YUKO4pr6rLaDz0VTEFNBOtzA XxdslWiOwn977LFHStQ/oAAAIABJREFU4fVFwWCI51lsuUN14JuIFJuz45y9ttnrm1/dn2gdKrzb s2LF8iuu+L8ddthxQudETdfvvPOuCRMmzd1xF0ZwXn75pf/79XXfO+JYluGgKnR0mWFhHB8YAXAe ioL8CRl4WkfX8AiDDX3QKkIiBdspnKLTDYza/2kTcOBT/sreBCPYyrpQRcNyciJZhkCFkhL5qhMh 5UR5IW8m4PCP5FXFDBt0jI5WFWqoogoxlg+QtAhDR4JQdM2kKUhWDH6NQ0hMHx7/IDqGgBqva0Al EevcloRYVSktXrqgt7/bYjknxilpmY3KhJiw0wm6NKByQ1RCxPzDhiXl3wk+3i8nhoQyoS2OW4kK E1D0Iex5I+2wTQAKFHRVsPSAQ5WSvD6g8WUqyhX7EnZlSAmWmVTIdiALN+kPJUsJkYmMusoUI2op wRurq5rBCVJVUTkOY1OAe/BZGRL5qCPJEctKhOlMKGkHiuLKEp8OFZM80RMkQowhUXRWNoYIOtU3 zFkBh2X4SqWEIPGymmU4syqX3I3HjpguUZrD66ZOkQrllCytxBCkLsMgXYJ5J29IvCKEGMJhwlUh lA+G8lwoN/To8IpcnxIqJQIcW2Lt0KAUUsXgypJiRkNWPJQlQgoXKhgBgw71SqFBLaQYIhvl8nQo b4QMzbEqt7+wMK1FQ8OsWgkIGSOkEyHDDJVLfJsejqZXdWofRs1hSydKclOE7wwScGhZmyw1h6ik Fz3/ymKZcH0kaBnv9qlGzs040EUSqlKxiSG1Wkb8W/zTa3784O4Z0i53uavi/37YqWr4OLffza16 e9UiYiN8Zrnd+MnnwLoccHe/bQn/oDevJQTG4fHtpFGiTnKKRakmtPuOZkECTRoObRKMRbIWxQLQ QM4EsAI5EIzKMWHi1HXpFOqIcBR8HHzjh/OeeOHlb+/UGS4X2NZ956eVrxzQjogvZurAe996QFFe V1as5oP2brvu29+X+8Ln94elVDAo3XPv7VdceUk4yjJU+NRTzly1elkgRAoSjOJpKPtYOgqo5Pnq RKeYnL3ecYSvqQULFrS3tyOSDKgCkPIVfOs+i5vp3MdSm4nx/2u3tRioULpjSoC2HZGY4NPN/PCD hSeecalJcgjU0dzMcjRVymWasAFX5EuqKRu2ariusJPxeLWYT0VDtlpFPHPMC5DlYIctMv39/Qh0 gPfWMGXSYQuFKpUM/+vRv39hj8+mEmFNq4TCEUM3REnENpWrf/2rF154Ac75SsUiLuF57pjvfOel l3pSgSa0VpWrDJALF+Q41ycTQ4uybESiEsMiDqygagaE5qahR8LBfC4bDom5nKIhwoVpY9UvyVpF RuR6x9IUSNWLVT0oieVSkefYTDYjiGK5UsFOl2K5Aq9Pw0O5XKaYbAdssotFBeIc+OiG/5iqDvsn jhfEgCQO9Q21N0VKwwNwdwmh+tBQGh9/6fRwe1s7OGIY9Z1N4+Yoil5WiWg4hO17ZpUQbEJJF6K0 BDz36isvfeuwb8BDTSGfVVUZKBVwxdCsiZ1NsLQY6ClHQwA0JgHfyHBBIxIBAaJ7ZtXqVakUgSCn uGuP/P3hn59yRSlDhPiULhss4zAcIYSIsvHheT+5+Oqrrrv44nm/+/2vL/v1lffd/9CyZatJIqir VZdWmKPns088/cR772VdAMSHQBuSwEZMq4KtPKwAURbci6aEQMh1lU6CETw0A2A4nphSuQrXmE7N HsQN5krxr7722o033lRU/Y9al41+2mo5gDnQBUrunzV/vbNGR8yfmDwBqvD96Wnc8C0KmAW4Uzfh p41KuBGe/AmtjdCQy+WefvppWGJNmTIFE6+n4APa8/2ej4Xn1sdSY+EubAQNEAThH3AUXiRsiQWO wdK4ePHCO+5/dEnPcFWz81ki098bYGmE5zCqJZsP2KwQiMVloBhNa03GtVI+zJIwloxGo9hJm8/n 4fMN2n28k+5e2yBVrdgCFy11L+6ckJyx/R5Dgxa27sL6ERgIPuUIw3jqqac++OADRbaampsheK5W qm++9dbg4MDinsXYjRJMBlz3SGSwVBmqVDOaStkmp6h5itG7Vw2rNeMkjmUG+3qGB/oefOBhKSBW VV3ND4qiYFJ8viJLCNhhq5AhMeFU7+pVhq4CS7nqN4aRgpDfAC1AyDTYFGsjLF4uFB1KCYdag8GW QJQr6WQwIRkEky+Ww0EJvoxZS49LYBeBXc/BQAQflpIYQHgHhMcIhUONWC+KEIQRSqVgVIqE4jTx RIqWrMFKSzMijJm777azphCtLSkEC4ZUXxIIiWNgg5EbLE5oDtmaI7mRXs1kM8UAw8I2w9CamptU nVjdQ0Sj4Xg0SAhTBBL1Vdqyo0FSVkuKNZCtLn/l8Tdee3X+ilUfvvTqv15+9Pb7H7hzQudUEAnh XM2RvOuxvH+wH0C25pdaZWqqFVMbtmDxWisiWb7syrEIimERYdXNwHwdGByqh1CAkF1TEbz2sKzH L9FoRFXUiODr+sENP229HMDst1as5rpEQN49NE74aMR0BCzlCYeAbAB93HmvQdpYzgKoQTSF/tGm B5VWr179xBNPwFhq5syZzc3NXndej8BbG9u+X/8T54CPpT5xln66DUKPTpGMZSLsJbZvyJCtIJyU olYIMhhOdkqBCM8Q06d02Jrc3726qSkOj286SVVULZ5I9Pf1atWKa8xsmUBR2A8C7IR3H0IpzAuY HQYHB0lGDgU4TWHCE6KFUl8uo3EM4nIpeIdrgm4GVgYBKYCAU5B5w0tKtVqBsAoyrb6+vpmdMwSE i3dBF+lYYqpZsiBCKloBATAiQ9Jye+t0h2IjsVA2k25pa37nzdfOPO6ITK4khqIp0YH8qWIxJCu5 HggqOQh7hhWyNRVPxaKFXBZCplw+zwtSsSpD8BSUdAoScTaqaMOl6iBJRrCnuFAZFqPJ3iGTE8lA MDQw0C+wlF4tBliE0hXgPMZBOD2MUFZESWIZZtmypY3uFmwaYIbqWEo8LJBQmA1W20N8hJDSg7lY WFq8aEEkTKSHem1TQYB5YCmRBTDKQezPITiuWuQZJxYPrOwuGKXBeIAoFzPgkqwRre3wwKDjqkSK DYeJjmZBIDVL0RKRMMMkOibs+Njzj77+2uu33PKH62+4kpAzJ518HALE1WLYs0BNblC+kMgFuEQy ArRGGFU3kIkhMxTB81EQDOGVux2JcH+EUg9jhMcs5KERgCjTgQowQHAEh9eeZQhNKWBPdjgSyddk Xo1Y4Zf7HBj3HIDs1jNL8o41H1LuAZimboKsCKZL2HmHXzGLYv4Ei3CsWxmFEF9tVAJIQoO4EDgJ iO2tt96666673n///b322mvq1KkgEj95UjFM4CBm3N+gsT9A/x6M/Xv0XxSSDoNIJtjYAWSDd02D 2IclRIklhDBBAQOpelUvZ0sANK3tXX/96/2tEbY9Lra1tfzzn/+cMWsbxL3FWn/vPQ/i4wayqNbW 1ueff76trQ27UZCfNGlSa/u0Jx9bAgiiZFYIATMgNCNIbqHcC509XKrwHC8XC7WJxo7HCc+xCr6Q INkClX35fnxLvfHSm7Nnz44nkwBI19/0f63N7ZUSGYnR1/z24qaWCVNnzt5z7y+kEvHl773zw3Mv h8Dlszvt8v3jTqQqw1ddeeWdDz16x30PzZy8+5wZM+9/8IlQ22SGtK+9+oodt98u1dS8z2c+e8/9 D7R1TpR166kn7zn3R/P+/eybk2dOmzl7zg033KUbgamzu9pDrZdcemmxZAHeRSNRRHiYNm2aFNv+ 8suu1BS4CeZ7ewe/+IX97rn7nuUrlre3t/0Xc0edwBm6XFEDEpPP9v/ttpsP3GfvHSbv9Pm9v1gt 57KZgR22m/Xyi8Xvfenzh379wL/deivwYjlfaYlL777+/B7bz/jSHjsd/s3DulcPJpqiIVq74dor Dv/2N/aZ2HnK6edBw2no0KJqjLj6pZdf+uzU4P5zOv76x1sKw9ASQh3XhZC73T29sNC47ba7mEnT Dvn6fpVKGRpAwob3K8IN2kZaVa2Sy6cNYCTS6l3Rf+7ZP/nhmWeddtqxt956XwC6QtcuSn1n8Yqf XnjRaWf++Ac/OPrSSy7Sq6UlC9+94Lxzzvj+qSefdfKl1/yxKhO82KRqGixBRo3bz/oc2Bo5AE3d aKxTC9niHiD+r5uAosAmTMKZTAaRhjEHYoZsLMZy4xNvVKpN78SyZcv++te//uQnP7n++uvR/umn nz5r1ix89ILU2pctiyOSR8zWeNvG0ph92f5YuhsfgRZZ1mEz6YpZBFGzEAVThvAEfkYgsihmhmfM brKzFJZdQQhd/fubzzv75tvvuXO7bbe76847jz/+mJAk7LrzLtf94a/zLrzwpNNPPfroo9PpdGdn J8RRiUTipptu2mGHHa69/NtHHnb4+x+82dHJGVYBUX3hgAlyKZDmbiNxCBgtTZw4ccG7Cx57/M0J RFq2pdWVV/v7+nZnuVQs9c5Ljxx22M++cfy35p3462fe+Onll/+q1L/NBRec8eHSty+ad9MT/1jG x4YWwqhaU6dO7vrGF7b9w8vZX177uy9uPyEqKvlc7rrrLtxpjwN/f82PXn/mnQt+9rNpB+80l6zC XfAtf/pjS0fX7ffcN+8XF+2652dnbjNlsTl8xy2P3XHLQ0/dc80r85/91Z/uufan1956869zRvXM ky478Euf222v+O+uu+72W1/8290PxJqzXz/wInzPff8H35o0aeoBX/3adttt19raAmsnWFbV5Trs vKJB9t3Csq999WuklPrhRRfutMMewwOZ5qb4UCz0+mtPP//vo4+/9sfS4PJrL//VxC/vPHPOtNde fG7eeaf+7Owzt52z69V/uOO8c395zY03GAOL7r/zz7+49LLw1NaBSgxCIt2Rm5PRoXeeu+C4u67+ 2w29y3qv/MWF++9/nAXb/lYi1UJoRWLxByv/8ccHrv37+4UCMbklghintGlToBRGZKRN8VBZKrjn RPfKS656fOfddtr/gL1Wruz5x4PPXXtV/qijD6G50sWX/XrKpIlHH3t8LCRZapULiDCg33v3XeZu 94V3h5948J+93d2l2DawydBISogAgvnJ58BWzIH/yKXwGWrbrmTd3ZroBpKpyxWIoABuAGLuvffe O++8E6cQDkEZB4F93fqYO+uWNyqEjTkwkyfxgqX5QQcdhG9CIDbUR1PoC3kPUeHz1cdSjdi4Kct9 LLUpuf0J9GXAATeNWAewhLEodx8vhBDI6tjBxRFWpq+bLIltU1rTxe5rb7r1hHMu32PHGRMndp55 6gl3/u229xcu3m7Obpf+33U77/2lCy64AMaSyWQSgmLsBDnwwAORhxXRpCmtXJA3NMKsDidSEsQh mE9CUcYoGNgNiBfYNIyBwcHHn3/tw5X9E5mMSUfj5jMVR8crnSlm5s+fj9ZOPfW0VIQ86qhvvrfw jYf+8vhJJ5whWzkmSLz6yoLDT9pd6Ip3tgv6u6WvHbD/Tf/+6wFf/ZIkZ4nyW+n00C4HH/brn/7m c9PeCqjsnx56ViFhtE19+5vfaGrr/HDFamxTzg6lg+FIT19e13KCkHp7/oJZLW92TA9dePm8m//5 5mH7GuVy/upf3NaWihXzubvuuY8LzJi27Y5FdUGppPz94X8ddNCXBYk49yfn0QwVjyUyw/lGWIqQ lZKmr1ixhFAKx597wXePPVSpEoGmVl3tsU1N0Ydv+McD03fJkivf+9N1L1fK+XR6SXrgQ7XUM3fb KZFIaNe5u712zW2lMhE0qlphoK9n1fZf3L2Za6ZlgrXoSrlA0BP+fO+9UMZuP7H0+6vuWLlq/n7f 3PWDXuwsSvN25fxzf/m5Q05pb+kCeFLUnE1aNNe8xsUN5UghKRSSIhSx4N/PM9HWrx9+dFIiOtqm Z/qrC958KxZgHn3k4db2zhNOOrmrNQr3o7SF22l0dbZP3nYOUSTKwUk0NQCPOIDHoiiZ2G6g26Kr 9/OTz4GtlAOueVQteAz+Ou6WRBgTutpynNTlCGzPIRAC1pkEWX5rK75FgaKAwOpWRiFUco1+qlsO cAaoBNUBWgZEwyyNCRYJ/UJOhkswFaNNVIM2EDO5V1i3Kb9w03DAx1Kbhs+fWC/YZ8JxDNQ8arVq ibT31sMMHd58wzDbMattUyeX0/myoRUVs3e4NGlyx2DPykSqbfddd739jjsP++7RlBDa/TP74VMG rx9eRXwAxePxO+6448QTT4RuftZkQ6/sB2MaRqQHh3qDgZnYHSYJrGxZeKXhjAAzCN7hMy+44MJ5 Z5r9PTYbi2hP7jz3LMi6k5G5r7322ty5c6E0tIpEOtO3y65zrv/Ns7DU6epsu/a3x596zMXzLl/4 nbMu/tmJ350tCZLAQe5dLKnxkETQAZjDd07fGfIwuVTAyq5gYzHFCTz7j0ceOfPs84AmYs0dtCDC c7EgChxrt7dOCMAQnHU0vUKwse22a5HVDwitopSyufTgjO06F3/Ya6n6rO3nEvaqALNNMBDGBmc4 vcNuG0HgYCYviHy10eciC2cPMIMgsXWuY/KEPjhYMMR4CymScUiz9t1rv0ScKJcK2CwngRgO3vnI 55/9F5Dtod8+mCGSJttJOE1wttnV0fzLiy/6+bxLr7vyol2Ou+TMY0+GPRjcFrRPO3TGpCmOOszx VjBI6+bg8p50pCViDxeeeubRvmWrr/39+bB4CkVgLAXPVq4aztXpEYSqKaVqCUfkFy96nw0eTAkw KHckgkQkwXI+k+lePrBqyXBWTKaisNBiHNiku0bpfb0Lf3/uOZaZoDqGBwbjmJexUVLFvkSVFHwg 9Ym9oH5DWyQHIOlZm2gHHlHwdrlGSMBS9b8xMFlBqA/8BHuGnXbaCfPYiJToExk/YBlAEkRQkH7h KxdTLqZfnGL6RUdeOQAWzF49CdYn0qnfyMfhQP0H5eO06F/7qXJgkqCYSjlvc2QkaWnVVmzj0yxO DxHkIguBx1MTVg0vJcIV1qQ7LXun4IpCieVCnRYVeuqZ57/w+c9wpEzp6VeeuVenE4wQDopUkC69 9eIjPzv/rCeffXlZX/XSiy6KEHpAJnJOu56YXRxamRCIQYLsYSY0hcWIlSMCsYpqJYyBXM+QGu50 +AKtzxkcXtXeuUQpmXvseOT8D97OamUmujrC796zuFWSsoyYF+3P7rfPDwuVB2+/5ZS7rjxvebfx IbPDcspJMIMT6QxDiYRkGJUJuuvZyebpiXABbBPvRULsh8veOP3Mc26/80/Dw4OnnvLDSLiFo+O6 IhbMzgrGiY89khBoWGvFzBwRYwpaiW5uwoflMEumIqHmo08+PF1auXxI7c++cvkVp4eiViDIwmYf YRxgJo8tdWGBJkzVMTUYbmN3JMOLjBhESGOYotkVOcUlCVmi+vVQ1Y4TBlSdGlcql3YaSsdInuD4 mEMPEswyuzRLqzI77Lq/HZvy5KLMQ+8v/eei1/7x4WOhBFGKTDjg4NOeevz9X159+Bt/PrvvXUI1 kuXE6ixZKsFEPJGqWEpOXhWM2q1NTVqe71BeuP7i33/92Cu0lKgItsQRRhmG5CKhl8NmlbEVjusk yuQObMlRCsKcA5yet+PYSOiiLCI3vDTVQUfbIq1TZzOOKVc0w3YCAgfvCQWd+OVN93bs+pUrbjrn N7+4voMbjrMrCWJqKDo9HEoHTBeo+f98Dox7DpD4djLhh812sAPEgt0CwjXxBCWsBVKQT/0ni1wj Eyh8i4bDcBaj4ZsEoAfVsL0Dcwq+TvFF+vET2kHLkHsBpUEEhS5ADApxBK7CEe87eke/QFSo8Kku On7jH4UDPpb6KFwaQ3XwWmGnFk2T2LyB1wxSBaNcdWD0YxvvvbdgcGAwny+88sprqVTz948++vc3 XP/kk0/ixbv44ovxNs6ZMwciqPPOO+/FF1/84003DqeHH3vs8Q+XLoPuDNv0ioV8f2/vaafNIwmj IhOhYFRTzebmGD7RVNlsbxYRsBN9EgwXjsbC4Ug8HquWynC1wHL85I6ubBZRFIQ5O2yPan/58825 XBH6vosvuuirX/0KxD/YgQLfTqtXdW8zaw62mVWqxQldcUkKQQC2etWq7h7IWyzsi+FpEs4cHJK2 KVdiaqtEJlsoGxBEBV74979vuPGG3MDKnu6VoSCha1BzVpNJIjucl7ENzdFa2+DvSu7smpgvFGuT j/HTn/70zzdcf9cdd8IR1MDAAMaI2QcqyOeeew70wGIU9ukQvSMWBKy+YcaJiQnffDBCxWcfwYUo UUJUmUnTps/7xS/efmc+5GT/fvHFJcv7OromV3UVMbwKZT3VMrGqW7KucVxw9rZziXzp5/Mu0VRL qer/fv7lChyCKsqjj7+LTXyp1EQi3DQ4BPYgtOoEBEYtFYn+/kwgmGDYoGlSmbQSCRFPP/t2oaQe euh3I2E+FoXfLwKE6YR2/sVX/f2Jl2xKtKR4mRAHqg4pRmfs/Bk7GPrDX+7rHSgvXtb9wvwlVKjT ljq6Zn9GYpw/XX+NWswsW9Xz7+delBisGAZtKlmFuv2+hypEoK9olmRioGytyspwhoWJwP/nc2Dc c8AVOGHXK8uRECfTCHkJn3TYKNvQW20jLDWGlgSflLHBAV/HNzbuw0emAlHFSZp1ZQiOBa8Ehgp9 Pts6aTrkFocfejBhldFSIi4+cPe9Z551lqaZxx9/PITAgFPYCfKtb30LiOeb3/wmtHvnnHPhFZdf SFrlyy752RFHHLHd9nO++51vw5PJjdecc/G5r+697y7zV18VDiQLhYU8cJrFDQ6WOFuNhLnhwQHN tPsGBmD23tIUhc8DTbaG0pmOzgnlUmmbWTOffuKxnQ/Y55pzzwGRPznnZyedeEY4IjU3p7bdboYU JOC94ZgTjttt9zlw4HnggV+/8dprP/elfWLNX869ekEsHudJQ8DOPYNVbXrqjFm8Q0yfvcNn95xx yKHfcijxR2dfeOOfbjvoa1/5YPGSluau5tZKsUJMjbZm0kAXZk9vdeLMjv7edFXV2jo64dXzxBNO CIRjJx/7AwIdy7kvf/nLd999N6TiZ511FszFgCnhx4EVAKUQOAaOjbEJGdyFRAwR+MBF7Hekpsyc ddPNt5xw2tnnn3oaECYRSVz9yF/KmulwVCBGVM3o4mVpWoikOlMkXZq1zdzf3vn3H551zss770TA 90Ak9uDLLy5dtmLeBVfP05eT8cG99z9lvy/z8N5pKZMJS4OWMCYm+1YuCUfaA1JCEkSYUb38xqpQ dFo4HKyUnZY2Epo8uPxS7fRAUclrDhxzYidgcsK0wQLM5olo66SDDz/sgQceePmyt7Azeur0OQDQ MCPvmLL9Wacce8MNN1z+8/OhFIBJx76777jn3G2Bbk87+7U999y7ZdI2f7r9/nDzNDHR4oghR6iN +CM/hH5FnwNbKAdMw2YofD/VHOYhBoxjQILrxr1EmD4/+Rz4GBxwI2DXvdwrx3GdDCp7hTji830k j+UZp15yP+5rOl2ceuVeCfJeBuULFy489NBD63Y9LgvxfYNRg12ANUjIgBtIkJTA0ghsgTdbCI08 /kCWiwp1+QDRAskKZdXkJQQfJ0itHKQMuZAuR7dxHUImY7apdq9clohEwqFQESIaze0Fvt1wBIyA 0BjyZ8iE08NVZBMxMZPpTyZTLBcYHCpKUjTED1ezEwaH89vsTClmtWdFsq2DU8iVajUZYEmBRFAV upDLEazERxIre9OkpDflzUTXxJxoLV66ZM+2mcWh9GCMCWllGBHBIgtHyMMpGshEU7VShDSdyASV DinFwRZBsVW1ajdViOZJxHwl3JWxgwJlS3J/NB5etDqvhLp2alMHe3oDoVi+qARCieFcmRdC8DLV xva8MRRvao7GS++EwuFF1Qkz2pjBhS9w4fZUR2dfd2+iqaVYlkmGRZjg3v6BuMRAJg9KwGQIqOCn dOnSpRMmTFB0U6IQJYdbPKy/1qOsTJdinL3vjtO2b+VEhn51QV9ZobhAHI7JSY4slMsI+bINxwz0 yM6UgGIQs8TskkVDWvM2TVrV9SXK8xXZgA7Bgv1XkCqWCT7cLeTbBVNTmVVEZGYmTYVpIhZ6J23O IU2inBuaMiFWKGb5YMJmOMjXmo3F+eJ0Jk4VCIcXSCtPpILmTttoHBFA/BgkeD5H+BcJAgQ3QCuB 8F2QKFWrqqnbTXG0TRRkIirhR52AiVu1AmUmXlRSQEQcOtu3KtDeJStKXAwUVPhCt6JhHqZYQ3m7 OVZr0W3VTz4Hxi0HqorNU/Bihy8m02ED73Xnnpm/HHENJqfYCa3JrlRYwgRlKK74inanDhLbeuol bybHdP3SSy9hh52nj0MhZldM9fWuGJ9l3rqGI77ZoPrAd92MGTOQh84EyxyOSJgXvUxt6VtzWL8E jXgJNdZm13DSOwUHkRmzfPTlUmP21tQnzI3N6frkhdzEJOF0k6B0ig+kOgmW1jQ6n83CK9zEidOV agkLPyytY1IMTzZgHBRwaBFwCu8/3vymOGM5erZQDMVTuVIFejzKoeDhMytrNFlp6QgsXfYh3JpP n8719JaDsaClyXwgqlRkuFdy4Yiqw995e3O8QGqJUDDX01tqC86aNoMYrkYiQTvGmxlTN8xkPIll PhQWTUtjWUhMbJHkDIYtaoVUU4SpkgwfKFesaBNB2+1w00kUC1IkRAuhYklrSiVtgR3o7Q6Fkwgy gwgwCA2DQILRsIDYL2qVnDY9OjCU6wq2gKpQzF4ylJvWNKlK8dnhbLKpOZPNiTAe51jNMKdNmgBH ERg+bEWh10MGr31XVxfeZweiKNsiaygfUyHeVXcKcE0T6LxNqA6lYkIlSLj9bJvQ7v5AsgMDPeFo alUeFl3EouWrO9unrHTgRhwBTQP5ArCLqMsK1IawrK+UTIYN8EHCKTmS1DGI+IgRSUQ8RKUTTtXx Lyg2a7bJipFSKs3WAAAgAElEQVRSReFEDlsIihbZMpHqzRLRFIxPLTEIm1bYeIgIcyyQHtxxJAoR A0s1mwyRJeGugpaCAFG1zdhmDUhhW7dlU6zIh0VLV2mBsw2dYplE+yRgLHi1kEuZaDhGwN25acD5 alMADkF9LFX/jfNLxxMHSFhGue8RApW7b7sNcwLX84GffA58XA74WOrjcnATXw/whOC7CKkC62gH LrRNW1GxHY/SrD4ExbQMbCsLIVhKsVjp6Gzu7VsdYgOekVBHR4cnGAOogqlQKhwPROIDWQtoJkDz IsurJXg2sNhASlFKgUB4QmwmFIIDfR9Onz69p7cQj0UBYDD70JxkQh5OIsSwhQ13ViSoV+R4S2uF loeGh2K2RDDsYH9P0OKi0djAYF9raxvagdlQMok2UrD36a+mKcGQuFBpSE9GW1tC7OoSbK1EVa42 hURVKZtAMkLYVJQQV62wAYqVbMATVYORViIerlTyUkAySkxVy7GCUi0iQqBEMZVgxLbhFz0WymSz eqEE1+ywyhwezgA/wW85dtth3w3EcoBK8CwKRAVMCTGVFIo41hrpqffFhE2RKB/U+SBHMIEQdkdC rdbR1Y4NPRCyAQ82J8KmWeZoaAeJtuaJEm6GQfABqazI4RiwGgRUdlsbt3TpIAR+papJ6oVEIGKQ jKJlJ02Wyn0wFU9Q7lwOwVWhoz06PKwGodSrlANwxx6I9GQILkDk8v24xQG7HYLAomaIHI0NfTCN h28ufJ1x0FoSlGMZsJuDuI8XosCpuqp7W/aAyUwBRvVuMjnBjXrDCq6DdKwhFtCiI0hhILBSIReO xlEHz1P9r+9aC/7B58C44UAVwQwIvIBwe0vq8GlrM9hoovkfEuPmBm++gfhYavPx/n/qGcZSmAsQ CcWxTVcETbMQQOiWE4Hrc8cWeD4YCBRLsExmsJktHI1USzI8FEDi4gWKgTADQAoleqGYy6gIT+DG wlMVNsIiUHFbMglJioVNcKKU7leam1ra2sJ9/csiUgdpYxu+BicnCAynyApUuJDpEJZhkxQivamF ItUiJBNxvTdvV0vRFJZ6RL4jg8GArkNgbk+ePCmTycIWiVKxd8aqKoUcDX1eqALDcdoMJfmyjPYc wBe5rJCBhE6yjl1lzUogGIdiOBSOQR6WzQ43NaVIwiwVc61SqreyGgI2iowIwbBudrt5IpApVSJR V4sHhAAfpLFIBNOmY+k0dG7BoFuHohAiFEcvFimsywnXjzwBeTQk0wAaslwdzmQoDpKwlEUxgSDC 2sFWlcgVzUmT+KE8EbPZSrXUFHZtWJvUuKaXklFCNNhEgk0PERMmBoB2igV5zg4thYJjOPGmBIAq gUjJLR0JPkRU+XIqFCrTbpuCFAWqidjB5iaiWgEUJmyJgal5UwvByUJYCtkFApqG/oFCTgiAtkCA QEzVXD4rCkIkGq1WFJKyEFaIrFpw8YBNALDlr1blUDBsy+6rDZ0khgzUCIYkk0CQcioiDQ/ncC9b W1osKzCct9zWRBGO9P+n59G/yOfAlsSBggnNOewDNQfzEisMFWTZoh0RGnB1SxqGT+vY44CPpcbe PdkgRbCSBmaCBYxpGjCZhuUQKzI65NTmAOQcNCmkh3KCKGEfX99AXyIZisWCkMegSTjPxV426LDg /w3W6CKUQNi2ZiP2cahccTe4xQC8KmXZCcaaghU5Hwx2ZjNlzVregjiaFdY2y1AsIlAvxWDrC8Mz NDbciZFQhaQAyFwJGSLYyXoSAUngYps2lLKKzYaATaVSAaox2FCJQlCWVd6CdIeNhgPYhofQeCwn 0AEnZxZMIimwrmcpRPKjWW4wW0yJsLHXdRh1l0sQw0EzBQ+l2JEnCnwiHiErTDDEAQgJkOHAjwKj lStKiogBW0CCBZcHcK3eNWFCJpOW4PyAhR8EBVgKAidYSmGwEM7B6x2OEPK7OniQQkMJ5vqVQU14 YC/IOV1fnkpM+HCpXKmq4WgYyPGDxaVweGax+qYQsODWgSYSA7klwQjVLyWwQVmAqyjLAA/jsVip kB8clAxdU8RYhVb0NBRt7XKwnFv2XoJuTmdnquJC7MgMR5sXvC8j4tZ772uRoFApZTP2ss7mfZes KBNst8hIdqErIoRprj9Px1RVkxVZEsVgMARPGOUlSwGSoI2E2Tx+QmRojlNhFQftpKplBYrAYDFk lEAeCRHd24tX4TRfMSUJgipnaX4QUVMhDMOFtpOTLDcmhp98DoxvDuh8M2OpjFEGlpJC0bxO6zYV cMW0PpYa33f+Ux+db3v+qbPY6wAL9idie76JyN1quuEsROljNZIrm/RQ2ezLVftz5WIFelPXfttP Pgd8DownDtQ+NmAKTblBYywLe3glOCwRxQNai7ArxccVDKVHxgvpNeqPnI7O+LbnHje8dQ1H3/b8 P8/N6AfFz/sc2Eo4AFt+jBT/sxQR4slUkKFsIYb9irSPpbaSR8Af5lbEAXzQQnALkIQMjAeQA36C 5NrbVuaKqGsJUAl/UWcrYo0/1I/HAR9LfTz++Vdv4RyAty4CfipgQkEhZjAhkHQCfoRNxsdSW/iN 9cn3OVCfA4BNwEzQjyN5AhV46mUt1itHCYCUl3D9CLqq35Zf6nNgLQd8LLWWE/7frZIDDuX6g8Hn KPyfcjQirjjww4mPUt11O+EnnwM+B8YVB2jYlLpWkcBSDryhYGzw5ccycPSHOPGuWyOgKG/AHpwC wBpX4/cH86lxwMdSnxpr/Ya3BA5QNMIXO9gVCQdO8FNAkTbE/yjhSNcflZ98DvgcGE8coGlsuXE/ k1wXbITlbuAlbNox1FFmUvjV/bwahavGEwf8sXxKHPCx1KfEWL/ZLYMD7jeqm/A9Cl/IJPYp4psV rruArraMAfhU+hzwOfCROYDgW+4L777ibnKjeMBlioP4n6y3N8j9cW2CpOojN+xX3No54GOprf0J 2NrHj8imAFL4B49cwFLAUDUZP+c6tvSTzwGfA+OKA+7rDajkjgmeUNYMDafeF1UNXRGesg+1RtDV uGKBP5hPhwM+lvp0+Oq3uqVwAHYT+PqEBTrJQL2HE8uNKUHCufyWMgKfTp8DPgc+IgfgUQ+C55Hk vuWO6wkdHntrgqo1xlIe3MLRQ1cfsXG/2tbMgc2Gpbx4h3hSEWcX3wHwIlgqlXAnxqutn7e91ntF sX8Ep0g4hf8SxNxFnN0pU6bAh6TrgboW9hgOyrfm53ITjt0zModSz0D8eJ/pm5Dzflc+BzY1B2hX FuWq9tyO1/71sliGkNy8g6CmUAa6ySvx8qOPWL/g1NeLZIzKWMXwK2ZyHLcq+IVVDLFNMWQPd+KI NJpRW09+s2Ep4AbE2UUcD6AH5HE/8NTi0URmXHLfQ04jbxoePiQUggPgA8YOEOkVoo4XjXhc8sEf lM8BnwM+B7Z0DhQQH8pxvC9/4CqsYpi0kWnk23NLH28j+rFkY9RYyLCEYe0GrMRyBpSJmKeNLhmv 5ZsNS0UiEbDeg/bgPvjrSWvGqzzGA+zeES+hl8Hzl8lkwATEM0EhTvEqAlmO16fNH5fPAZ8DPgfG AQfg3xPTNUIzAUZg0vbmc2TGq16l0S3zli0wAcsWjmAIVEwjUr1GV43L8s2GpfL5/Pvvvw8MAe7j NoRCIUArD1SNS0bjOfPeN290OEXCg+g9guAGEFUgEPCkUxBW1aLzjktO+IPyOeBzwOfAls0BCGOw YOFLeOHChYihDrkUpnfM50ASW/bANpJ6KDchkMNFGD5UnMPDw9OmTfNKNrKlLb76ZsNS8VoC0z0s hUcQoB5Yarw+i0BOI1gKrxxSDU3ZCDOMxxHJezkRj7ZcLgNiAldt8Q+XPwCfAz4HfA6MRw54ohes XwAQzc3NUGlhIYOkCmk8DrfhmPDxj5ULEgEsYdApeSgKzEFhw2vG6Q+bbcCwNIcsKpFI4AZABgOR KW4A0AbA/rhk9WgshQF6QApHvHt4ED27e+QBJcEKfOX4cqlx+Rj4g/I54HNgHHDABU01HV8qlQKW gibBKxmvNiqNbhmEAoBN3vCBq7B+eaqVRvXHcflmw1IQwOAGIAE/eQ8lIAUeROTHJbtHY6maWGqN XAocAKKHdAoDh2TOexWRGa98GJc31x+UzwGfA1sVB2CSgSndMzmHDgEZQAp8Bm9t6q0R2QdWLjAE p57tbzQa3aqeBwx2s2EpYAg8gkAVgFBAsp6mD3divGKIdbAUTpG84eOIOwGxnFeIzAio2toeR3+8 Pgd8DvgcGPscAFaAOAArFxKoxYztCQVGsMXYH8InQqGnSsIRIBJoEohqKwSUHic3G5by7gGI8MAT VFreQ/mJ3OAx2IgH2wGbMF4kZPD6IWHUsBJDBg+iB6rAGSBLCKvqjsKhyrFocqA/E5CiMMFCqE7T NHie08g8LodXX/wHvynogmbc95w1orpR0Yyi7cBIEAHRw4QtGgaiUlXwK4As+kVHgHFAtyDDuy/4 zMKHF8qBd0Ge2/LakJ91qVq/EE1hFJ7UDfuH0Q7yaBNIcf3K/0MJCIY8GVzCjIaOMBbkUQjFMTLg NszOcIp+MUa0jwp1e8EUAKowanAMswCeQ6SmpqZG2yDQF37CjAk7CbSPTQMoQXeN+KPQDk9QYZo3 ZVWuynwkSIekoiZHaR79gvneLQAB3tSMpurS6Rf6HPA5MHY44M2KoAezDeY6TB14lzEh4EVGGjt0 ftqUYN7zZj9Mie4iUUuY08CQT7vrsdb+ZsNSY40RY42eRi+kY/OaYnOs++rC4M99jglSUasUmUSY cwAC90LPmS+ebZ3IlrJdE1sHh+RUMt7T2zehozWTrnCca5UFeOEhCWSQsLQDncByy5OQYYJAIRAJ MsAWnkXXR+cSWkY7gBq4BNsM0DgQFWBHo3F99JZHauLtBW3gAJAfmsVbjLkM2lJUQB7l4AZmOnQN Ahp9LwI5gVS8/PjQBLVgi5cB8hvpaHQGNdEs+sVwkGlpaclmsxsYFD7WCNMazmQkhovEolVTqxYL JM/mcjm4BYE8HI14bQL24Z6C4NHd+XmfAz4HfA74HBj7HBifxkljn+//O4W2pCoEx7qmjlAM0gxB M4BOtsgj3rmuVotKpWDqVZLQacIkIIsSpMGhrChFB4eKsVhLb99QPJlgWAoIA0s4cACOABNoDWgD pyAMiAeLOlAFNqcAXQGgADdsLMG4CnAELQB2eB8rHrra2HYa1Qd+Qhde4wBtgCA4BdkgGKAEPeIn DAT5DX8hAS/iKg8M4RI0CxCGRhr1C3ZB9IUKkEvhKnSNhBYa1YcFQSQUDoZDJEtrlgltrsALjmGB MI94QDe0gxZwC5AateOX+xzwOeBzwOfAmOWAP3eP2VtTnzDSkWwLEhfIk02gKNMCYCKCgUi+vIwV is3tTKqNZoSSavTpziBKEGAuEkuYFjfv57867fRz/nLr7aqhV7UqNEoAN54YBsgD4hkIbyApAZIA BsJPEGJDToOfUPg/rPFANmgTKAHXAm2gHaAHD7LUH9jGl6JNQBCQClCCvoAOAQeRvEL8iiEgD9yz AWEPOADygLoggQOQQlPwGQMmbIAcdIFq6BdXAX16LTSsb1iqLDskwYqCaurQv4aDIdohcBUQKrpG BmxBU6AfBDdsx//B54DPAZ8DPgfGKgd8LDVW70wDumoiDBbm6boBoEDrGsylGNsSKbqrXIn1D9AD A0ylErOdDttuV7UmXgjJKvGnm+949bX3u3syX9jvK4jtaZEmxCHAH+gE6zc0TUAPwAdACcBYHgYC 9AEE8VRmEN40IKdhMaAGRDjQZKEG4AKO6OV/aKdRB0AeHqABAPKgHmATEnoBKvIwigcHgeqAqxq1 AyJRGRdisGACmgXlG1Booo4npcPQcCFGBOi5AQwksbxSlcvVik2TfFCywXCgWJL2dHygyuMwyACi 2gCdjej3y30O+BzwOeBzYLNzoKFuYrNT5hNQlwMkCU2Wo+qaZaswOXdsxjaEhYt6r77xSZg2lytl TdW8JRlG6C6kkJbKsvr+e4tSTclDDv3S7O3m5ktDobAgMq4LK+jgcAQggPAGLmsBKeDxC6jC02QB VQCaAGB5oKEuPRsobG1t9WQtHkwBSmtkhLSBRhr95IE/EAZSQSHgGhpHIVRvQEIYFE4BB71fN4BR cC1qevpBHJFH8tBY3a7BIsiQAOA8ROVZoG+gfY6ihUjUYSjFhDTLwIYATVEZwoVNYDVQIChEgyAY 6BaF4FXdfv1CnwM+B3wO+BwYsxzwsdSYvTUNCCM1h7QdHN19uBbPxRSNePiB5/bcb++JkyZNncoG A4SsEJpKCCIRDhGMSVx77c0UJRUKxe7eoaqsMSyTy2doKZ5MJqHPwvrtmWYDQwCRDAwMtLe3Q1iC wAjQ7gFOYb3HT0BCDQiqXwxM8Morr+A4d+5cADK0gKYAVurX3vhS4A+M30MekOigcaAiCHsgIgKG wxEwDuMCukJ+A1gHFbzO0SDIw+l999235557guBGRKGvBx98cNdddwX6AQ2ehq5RZce0nnnhhaau jglTJ8u6FmB5gWIt1d3n8sADD+y4446As2jBI8MTsDVqyi/3OeBzwOeAz4GxyQFfxzc270tDqhxS h0SKpCz4VQCWEnh3096zz7zePrtMRD7oqyzpLvWWyLQupbNm/9Lh1Y8/+eKTTz6N/aqnnnrG4MBw ICjA1rq5tRkgAIDp8ssvx4oORALAAVkLIiRefPHF/f39QCFY4CH18SQlgCkNCWrwAy48//zz582b h2s9mALpF1KD6htdjGYxBFwGZOOp+dLp9Pz586+55hrYMHnoEHAKQ/BkTo06gJwJMBEgBhkMGWjs hBNOAApsVB+tAW6izptvvokxogv0PgLI1r+KJqkfn3XWZZdfVlVkUZJqEj6KoWjgy1NOOeWdd95B g57EzhMBrt+CX+JzwOeAzwGfA2OcAz6W2sw3CKu4lzw6sDxjcUVqRBatSA6t6ZTDERMYmS5Vlw8F 7CXxqWkjkDNEk4r2D1QyGatvkMjLqb5C6u9/viptvjXr23tXOvftrkzNFWVBKMuVKs00BYuPvnL3 7e/1TV0RiDI8HcxWJkSW//XOFUVay5pLYolWnooHBY4hNVsNlrhg2WEIB46S7DjLOHIpGGA1SyYD FdWM2FRCo4oUL4tkgtdDEjGUZFc2tXHD8uyslgrGF0lWKWTGLaocYIqDVDRNJyTHlgzVEhOZspYg eiklNixVjYQdVcP0kGNGNCdBRJSEAqQUC7J0xaysirBqPBginDhBJygdltrDFSvHx2IFNaDqQiLs WJVXb/5zH5nsyBKlWLg9qgphK6eZ1TSRYCzV5sMDZtCUEqZcTDBVya7SFJUno21NsWJmsOAESMdq KS9sZuXB4CyCS4jGQCI8XHQYo5pIVJwAoXwQpHlGaFO7O+wSG27XhHgMjrpUudsMy1TCDmc4MWJU olIwA1cMtpFQSJ1XcjO2dSbN/rxhtxhGn0jIWjVY5kuT6O64mTSdaSoH1xRVp0I0J1qyxoAdcGxD ljQzSLOyY+UcEyxnVToQyVVogjbZRLkiFa0sk1BCdGnVLc89/FK3Fh9iJUfvD5KOHU70FPgEXxV4 xuISZSFhhas8mUmEEjbuKz3IOlI5lMgQVsxYlXCqOTlaoeNhsj9kJ9JSoZLIJqDmtRKrNb2fViLI 6wynVgmnyoWjZSNWUqKWTbGM63jCTz4HfA74HPA54HHAx1Jb2JNQ8wPnQIICur0j4BdkKvmqtWz1 4GlnnnPOuecvWrjQ1JXVyz98/aVn312RnrTtLhNnzdFJxqYgJaGgIYREC7v/OI7VDc12LIomSqUC /HtWqxVCN0xZD/JiPpPBrrJCpQy9l05RIdpMBvlwgMfOQVkzWCkymC1L0SbIVOCmrlSoSAJnGTro qsjAPwFaDDMUh12GkSihmDDSZgdyRMkwgWmiAu0oqsgzulxRNTvZ0uroJs9QDBmQiHgml47OTFar 8nB6gInAl6uUHS5ZutWUbFIMc1Vfr66X1HKZ5COpptbWZCKfzVg2EAdCGYYOOvArHy6/f2hgEI4h OJgo6YZukclUk0ATcGQAwVUywcuVSjQc0mRZgXcuMQDp3nB/L9SdHE+7+jdeMEwLerdK2ZSCgXyu 3JKMMIiDbrjbHmmHU3VdiMQgp4NUrLd3WBCF9NAgzxPFgpLPZ8ulImRvkPNB+AdNK8vxjR4vtZwd yvYFArBML4eDQVEIfvjhYHtqKlx2OhqEjnylqsI2DvFSM8WcQtHlnqF4MCxFw4TIWEFOtgjStN98 6vnvHvs9MC4SFm3TcCwLDlYndAW1YqlczOLd1lTbtmwdwOj93mgsGoZrBoLM51SapnBPEO4B4bPg jAtOyWiSYEgerK4Uc339xfa2VpGXNLXo0FyoqQUxS9NDQ4k4FYvSkK5VFX+/YaMb65f7HPA5sDVy wMdSW9xdh9ky9Hr/haVgfCOTQTqQ6pg8a3A4f9NNN/atXq5Xs/ffcUueSkyc81mhuauoO3wohP1s jmWyJKUbWLDhDRwe2C3gKgkwRoBpFLjBCwRXyRbmv/b6pK4JTe2tE2bOfHHBu5yaJeTs9ddeNXny lGBT6jfX3kCKEZOF+k4o5EttLcFyIcuz9OtvzN9tz33YwMTvff1b99/zWDzR3N1nnXHOeRde+qtk F2HyAq2W77/t5qsvndezaP4xR3773nvu+s73jqTadv7cPnsX0saqwWwkHvjLlVdPnzZrm+nbhcLk 7Xc/K/LxWDRx/nk/vf6Wvzz8xGOTJ6fmzoy98Payp57+d5hv7kimHvnnozKAhG394747jjz2j8GA 1BwW0n2rf3fDH4XURFEITG6aPDA4yLOMXDI5iqCwkZGkXntzfqK1c1JT/PRTTjzqqKMu/dXVxYpS LlUxImwFpGB1Vqn09KQDoeZUa3yXXXe47JJLBUZSNBMQCT4Oli1bfvQPfiCEkyccd8zCBSviEbG1 qenss340dcrkaHj7rxxwYO+AzPBio8dLCHOtbclFC9/+ydlniELrnrvvzXHRnuFi0NSbUq0nn/rj ZEdzV0frj390shQLqYKUijY99Y9/hZuTVEtHqDn2YXf3wjfnX3vhP22CnjNx6hFHHNWUiD1w712n nnzBY4+/3Tlxu4kdUy696DemqtAENTiQPuKI7wlxPkR3XXTRRQifjeFD3nfyySc/+OBj3zvyyKbm 7Q7+6iFDPYU//eG2eFdit722W7K4l3F4x8jNX7g0EUu1tU/4+tcPXrUik82o8BAbT6Yajcsv9zng c8DnwFbIAR9LbWE3HbIoCKLc4yi5FAylF60YLGrU3p/78uztd1y+YsUzTz/xj4fuJW1l9h5fDXfM 6iuoWVkNxqI2gf9siGAglcA/SKjQUqUKj+eiI5ctG3ZRfFiKBBj+7DPOOP2Uk99fuOgPf7012NwW JuV7b/3DT8//2f0PPvzmm4uu+N0Nt951f89AAQIYnmNLuUpnazPg1H5f/tL+Bx68rHvxoYd8w7IJ QJOJk+hJU6dddeXv3lpAcMFgPp0548Tj9/vMXp2zpi54c8HZp548e8cd337l75Vcz0N3P24bQZoz dLt4x233vfXaS2ccted5p14IiFbo6RlOp8877xc3/e2Op558aHoL8dUDjjrk4G8/+cCNZ574g9OP PUa16XyhQGrFNxcui4aD1eGer+3/hUt+c9Vvb/jDW+8ueOj+O2DSRBIOD5soU7V0demyZT847sQD Dvn2uwve+OYhB9338D/vfeDheFMzyXAmBDm6xjEKnBfss8+B3zjymHcXL7z48p/99trfXv7z34dj CcJE7B7iZ/Mu/O53vvPsI/e9/cZrhxx8YDGbH+zrnjF96tNPP/XM87fmi6V/PvZErlhp9HjZpJXJ p8/58amQez396N9yGSDgv3JCQrC19mjyiedff+G5+a+//NyrLzzW1dpUIGg4sD/9xJO/c9T33lv+ 1kOvvxiIRnacve0XdxElPn7ZjX/45c/nLVn0XjwSeOTee4448Cu33n7zFb8665orLl26aCFpE0P9 QyeecNL8l9/529+vvvW2W59/4WVRFMr5/HPPv3DaaaftvNNOd9xxzdJFb+0ze8+li/sef+Rvwahz 4QUXG1W7lFv+mf0PPvmMs5etXBWQxBOOPyYcEmQwRt1o+7lGfPDLfQ74HPA5MA444GOpLewmjmAp 0O3q+GrQKhAItrZNIkg+HE3O3Xm3RFPTK6+//vLrr/ASv8teX4QmrqxqhmNyIvasOSzD2SYUfAxc feYLWiCIACxOuVKsVIrwWUURwUJRNqAdq1Zef/klXdX22OuzTW1JQq/89JyLvrr/59q7JuUqyqSp M5965ln0j5W1tVmMBMWe5Ysfe+Rhi7BOP+tcMdb09UMPPuqobwgiV8gTh3ztwNbW+KMPPywQ5EP/ elYIpXbZZXdnaKi1OTjv15ed/qMfJds7gkK1d0V6YqdkkpUTzjxmj932m9A8JRk1CUuAOCTa1jzY 33/Akcfc8fCj06d1zTv9e0R06tvvLv3c5z97+Ne/Gu2Y0p+rQvdkVzMywVOO3f3B272rV15+5e+O OOH4WKJp1+2m8YIYDoWg0aMdwzE0GH2ns/nLrvztlPbUV76474nHHEnz4sreYVYMaQbwJREQjXvu usuy6Qt/eVmqI77/4Qf9/MKf3/u725ev7q1UFJqlrrvu90cffeQ2s2b85eY/EuWCrlQmtXf88LRT pk2d3NrW1tTSlsmXgtF4o8erJGvRWOK31/7u15detNtOcySBl1WNC5Dd774Bl6O/u+XObXacM3tq 1x1/+C0hsM+/8T7BslBTLl++HCbq2P3X0gKvqtxhhx1W1iqf+8Ln49HI9FnTh3pXE7b16pKV+35x /yO+eWBEZEjAZd3aee6u3/nudzo62xOpGPSP4VAYJvCwyW9pbr7kkkt+8Yuz/h975wEoSVHt/Z6e 6Z6enO1KGxAAACAASURBVO/ctHs3L0taCZIWyUlAQBRQJCMiKigZJDyQrPgwIOH5iEqUJBlBkLBk EGEJu2y++U6OPaFn5vv11DJv3Xvvqk/9nitTLH1rqqsrnKqu8+9Tp85ZsGCBVEl97ehTf3Dhf+66 34LPfHZGqSi57Z4nHrm1UKnv/+XDB0fGjjn6qDdefSU+lujqjrDJO1m/2ultCrQp0KbAp5ACbSz1 LzroCJ8mDE2J1Bp9KZTWaT3Z8Btsl2WHqrJbt8222+28+56GbJu58eZ7HfjFad09Ya+nuwNuq6Ey LlsaNgXHyQ2AlKyp2E1AKSfgwcBS1RPmcD6OkaV81bAqytNPPfnG6y/vvP2Oe+6yVyYhxUZHIh3q A08+N3fT+XvtsffiN5+31Coeu+n85P1FK+HZfpe2bMlHOy/YJdrrzlWkSqNYrGTi8QF82/SG/Xtu v81N/3l1ZtXyH/zs9pO/f6VFC1gUbfVAfvsddsgUctgE326bnmiwY+UyHN/kbrvlF1MDUyOBKU8/ /roUjFSruhQbcDrsfRvNt3k9qtUWtlWkrk27uqdJes4t19OjMcXl4lxfwClLDr9Nlnr8mtcmdUyZ /lF/YXq0069ikrTs0NSGUVYtdUu9+vHHS7fZcbe0XpdR9Fbk/tWri2Uj1BnRK0YmW+vt6alXU4ve fXf7HXYvGZJVk6uZ4Wi4Q8pJVpzyeHzlSj0UCudzBV+0I+jzSKptqH/lR4vfO+27350+bcZuu+3x 2quvYm4+ns5NNr1URxgLDAF/MB2PuRzKZpvMUezycCwX9NtTUtnZ2VexoGlemhn2SgVdcwRrhv6z G6576amn99tx1y1mbFTO1RuKNV4tas5wUa+Egv5ibCTs9269YHu75syVKqpc6u7wl/I5l+Z649U3 F2z/udAU3/fPPxcrV5h45Siif+qU91eO7rbbbv39wOh8kP2/ro2ikam1WlzzGgOrY9lE6cNFL0ha aMGue229zXYnff0ERZai0dDQcGI9e5eT9bed3qZAmwJtCvwbU6CNpTawwUVkAnpqqkut0ZoCS9mx VGm1zJvZ5Xe7otHOQ796RM+M2TZvYMe9v9AbsIddSl+nvzuM4jKq0DiIqyuqq1TW0RtasGCrl19Z OJZKoEMtNervvPNHKRwN9vTaXc7Ojo60nrz/zntWL1l5yXmXhju69Gr9a1/5Sq5YWDk8kqpWH7z7 Vz6l4XA4Z86YloyNejxOl8OOvCeJFrvdbXU0EunhQMDhdUp+1XL2N0/QK6tPP+rI/oK29e4HOyLq wFi6b3oonU17fV6bquRzHydjY9EO6e0/LTztjB8++ru3R1YUzj/nUKlS8tLsegEkpLiCaV1yah5L Pis5omPxnGRUXGhNN2Sn3xTTGYV0XXH2r14llbNZQyqUjd4+19tLl1mqBZfbnYjH/R5XraIrsgX9 sLf+9J4/IiuNSjoRW7p0qWJ34C2vJsm4eEFLvVpJbb/dts/84UWFU3CZMSXsio3FpMA0kFTZqCUR 2+Blz+UqxWN1oyLlkmws3n7rzffcfderr77Sv7p/3wO/aLEiAZxc97yiFoqNgDfU3RmVHNaqUfCH XG6/o9ow7XhlJdsoDmaKOVe9JJXxu6haIr752322kMm/+MDj1lThtJO+U7VKcalssap2h6pgft3j RDbWv2oVukx21OY9anxkIODx5DPZb5307Z132qVWaNx2+y1gcVwDzZoxK9M/4LNJq1ev9vt9GDXN pTPWOlBUGkusUrRqKNgZ8Wk7bDNPKtVf/+O76Wx+Zf+qTDqWSaW7u0PJdHYDe23azW1ToE2BNgX+ mRRoY6l/JnX/KWU3dc9NSAV6MC9gKcVmC3tdFkOa3hdEUIT5qJNPPeObp5yGb+GekOSQa04Fti2F /B5O7bEr53K7isU8QGTnnXd684mHXnnl5ZpRXfrhB/fdd+9GW20lO7XReOwPf3h2xeuLt9/6sx67 S5VseqV28aVXPPTI49def3M8nlj28eo3X32pXsrF4nFsLHVEQno2s8X8zVOFsTvveWjZytXnXnDW c8+8r9otidFsXc9tvOnGWwfnvP3Cu1vtvO+UjXyDcSnU2bOyPwEqLOrsbukBv9zb3VUFluSTRh0x WJZ9s++ffa9kt8ZiQ5ITk5vF0QQAif20vIxx8Fy1p8cjWTmDyJE2edWAhAlyDtpJJWNKb0/X9Kmb Tw0cd8RRDz75QUe08/VXXuLcnsftSsZjaF/Va8ZBB32xVtC33eHLd9x+64477LFk5eBee++DTA4r qDZFhZ4OzbrlFlu4VN89v3kiX8wt+eMb51940RcPPMThchaKpSmdXkxzJTkRpxd/fPWPNt92uzmz ZjIwNqvs0LR777v38QceeOrppy3ypLZwrbIrn6t6PYHEWCw/2A8OzBVSlboeiAYCXVNPP/9CtiCr evHS874fdmtTu8Ors/H7H37o4/c/nNvZG7LiydpmWC0zt9pczxeWfLwiFhurFbGDoFplSzIlVY26 noq7NLVeq+YgZCqNEfgPP/zosScewy4XE2YsPubzeTm2WC5zWlBizgS8cjZVAJf6AujXZ3PZImcw d9tle8npOfv7F/QPDKiK8uD9DwUC/sGhJGZezZnXDm0KtCnQpkCbAk0KTLrW/6vRB5NLrPgEzqLj cOPZZ5/dbLPNOJA/mflHa6amOB11xZoq5hw+LVtIRSLeVDruqAWtVks2l3K5TZcjqHGriobTEaxI YuBR2MumTKpDs4RTaqZO0kRBt5QxE57P5RWZ8uRauWJXYF01N/aXFHUsX5I1t1XWjDzmkuy2upQw qg4OpAV9Y6NDmAOgeKOKExglVzANSq1YsWL33XeHz+H/BEyAD5PJ7G5bPCVL3lVOVtzuYiKXc6uB qdb8ToHnLA6XGozawhG7jcKlOeHpbNdhzzLvsoVKkVlOuX/s45RzsWaZb637c9g9d9lHbfvu/rUt zxwZueqgA76PAowlsMkW+//6/n2c5YyRc11x1UVvLVmJQ5OOKdN+cOURNblw+DFfH43nzzvnxHNP A9IoO+7zhRv/++aQjU2vWqJYdLg/s8VOs08/ffTKCw5rnN/Y46i9t9lzr1p+QFHKidx8h6V+6o+P OvzYhT875YAZ1bhcN+KFmuSK+Eq5WU5bxjrl7dRndpY/dDQGZ87df+8vvHHskZs5XbaLLr5syUXX 7bnTLq++92bON3O+MrJpY0z1+l717L61+8Vc5qSGc9vVLjXsHdpCfT05al3t33+a+nxs9EhneNs7 fnfrqaeeeua+m5zh6KkW3X9c9WhAsltUS8MRyRe9Mzaa9cJv77vu2muvuvmBc6//FbbOQ7nFnXIl 7u2tqr7eKh3ftnP+Jtdc+4Pvfe/LP/ymKSvirN/ll27TY6wYKRXLdUtUzW0+t6dhdXi6pzz02O1+ y/AJB5957y2vTJ3nnzJn/umXXPPjH197zrmB6849RrVvqRRXBeS4Xe7N5rMeT9Zv70o7ebBas/Yb 1rklrafkUu1yMpwplMOb/OGR6489/tv7f/bqqqHMmD3/N0/+fl5E0pLeH373lFUJ7N3XeuZscfP3 T9SKRc/0A3fY/g/H7ToDC+zvvvvuksq7QVd6miur642Yur0lGKlLxWB4/qmXXM7xvQtuOPe44477 4uG7nbD/jo8/9rveHXdPqr0+Neuqx9MN76C/b6/OZZbcQMO2k1Tbusv9cTa3LDLztDef3mrXXQ+Y f/c1suSyaa6Fr23SO70LOwrIyiZ6LTCsMfHnGZP8b8rPu0BR5o520+IaEd5WXn/efeK8oVwJlEkG glgHiIhaxkcmrL2d2KZAmwJtCvxDKGAuVRMWJNK5rhMhs0jkyvrYigNx+CmCqdnatDfNT5EuUoiL COnvv//+fvvtN2HVEyaykooyubKGvvfee3vssQdrK0VNmF9ucOJfqpYairYGDKVyYwEPBoua2y7m KTizI5WKIWN1SZJtigR4ImBfgGJFmUArrApNWP4Lb7w4f7PNA84Ad8vlvN3ubmbjlFwVRCUrTuAG /3DqW86X7IodPl6rSZwRs6tyNpvxen2NOjKFnKYFPv744/7+fnyt0DVztyWXi0Qik7nXFTiPluPg BTUXus/13nvv7dx+V3ynEOAyOOCDFUExGl+ne5KUHku98vzvE4Orjz38MK8DlaGa7A5J1bzPUU/H hnK5oqwES3WPN9hZtuV9ihywSvmxYY/HGy+WchbFHgi5EyssVpvd5a3JaqpQLmOrSmVTzOKzFKkL DodmNGaZ2B3DdLjpaS7UaJSBqz6fQxoZWh7w2s845YLHHnzxsT891RkI14sln+bCQLk75I8XsuBZ p6UOtcEE9IgIAwEd+KmWXaUG9jU9dVujamA1tNgB1kykYmVq81ZKWb9XGxpYOr2vs6zn0P1akujY aJor2f9hh0cy3eopQd3akTecsm0k6PNnk6mwL4B+VWcwHBsaCfj8aTS7Go2ddtrplFNOOeyww+Df DAEkpVMYNKcB7IiRgrNCrtCzNtYf6OntX9Uf6p4yGE/pdcnpDzrZ74st0VzeXKk6ksr7Ono1r2fR 4v6NNpmiZdPI7Rgs/O7RLxrNKGNxnsIZ9GnTpjGgVDowMEAeJp7DlpFlVS/Xaw21WrNV6zaH0wdm 8JaWY2y02HDmDUbBYVeMWjnm0hq4paGbjDVfAhCNWigZGtIpWt7Z2SnQOd4DefuA6UY9VylLKors bt9A//CMWV0jowOBgDseM90y0jbGjtGkBCbh6OioV8MbDz5vbFbFU8LeaG9ocGTI7XVYKxO/dwLf jH9laM/4RFImw14CS5GBB2kMEYhDC+kgVfBU60EyELi1dvmkiJ+tyNp32/E2Bf5+CvCy8N49/fTT M2bMwJ8pi4P49p7sFfj7a/wXLIH3i/62rk8++eTcuXNpJ2yUN5S3kiDeXCLNt3bNpXnnz1IoRwRy fBJdw7vFT4ol8i9IBNGkDUYuxdoqllSoyQyGYQjEA90nJK6OGSCEJ5rFfKpulEt6wNNRyCbRqtYc GKUUqK6OkcPWPgwlMwMYYwpEj6S7u5ufExZOYg0Fbaw01UuqrBBpsB+TN5VyJIsmY69SL7sdJmgr lEh0oYpU1utYgwRIJZOpYDCQziTsmBRXNNgqhiJh1byNzEh+0juY7mSTRhABaog8PAIp5s+f/8Ad d5qwtVHnaB/cByhLCZAoJ2GsvIbhyo6wf4/dd+rs8KHfwyQHBmFxsQZ3D0bCHfZcoZ4vKZyAw8y5 Ua2OJTNBl9c8+m+Rp3Z3rojFu8ORHHYcc3nMcGMGQXO5Ghjm1st2tvEsFhYR6qJVcGKYOgyvUc4p slot1t9fuqJriuO9JR/e+9jDZ517mc/lpnEQKpPJhjujY8m4xtaU01HTC6oKNXL0AtTS2Rnu6KgX 8vma0ejpjS5f1e8N+nDd7NG0VDqn2TU3sr5GHlWqWGxk2rSZgwOrNbsCDaOd6AMlvJ4oxPf7uouN OkMQDtuzGRnvfYCnVCIZDARyhfx2C3bYe8+9eufNuvLKK2n8tttuC9SAnswohIKMAqBQ+HsGlIAU SQS1eMJT8not0js9m895PVCh3hn2LutfZde8iVS+q7sX0BfwulDnnjMlrMezdcM08slgiX5BGZAK 7QRgzZkzZ/HixcAdaqRqlmbuqm5nOlPgiB8qSkbdcHv92XwsEAimU6VwtKOYrvg8TqNeS4yNdYQ1 w9Aplp4yK5g5FEJRwCYxBFOnTgXacktMFbAamYvFss8bzGaL9ZoUCHqXL1sZivjS6ZzHA2KzkAGA y4yizOXLlzMzgfsulz+TSzsU0FWgkCsE/f5KVZ9sfkJAnh0f/hf5RVG0H8qIAokT6CO3xF3SRbz1 c3zV7ZQ2BdoUaFPgn02BDQZLCZ4Bz2MlJQgwwcIqoM94MhUVe61Y9NkVJBkORXVYVSOv67marOXY u/P6AEk21K9ZpdMZWLILo0Is2XARmBx8lI9yvvKphbrGF04Kx+C8Dm/VwAB0DUNEbn9YU6oj/YM2 bZrLY3W57dl8HnvWWbCU5ioWcjaLVq/Uy9VKwGRFFb8vBM9JZBJUB2LDBR5sGxZIB2mDkFtMWC/9 hS3BjwnEoQA8nu3OLeZtMhaLZTJp0wxj04uwyXVA8VaHYVRVTXF5HDNmTRsdGzbq1UDQb603nBqG rauGZMMCQq5Y8ng6nE55OKsjLHC43BgNh2ia04VGlNuuJFNw6FADo+ZVw+/zFkuVTDLjDwT1Ql58 n3GFXFRNs+lU2K0U8zqmz7s6O21qsWd63wWXX/L5fb6CWQaGsFozNLerf2Qo2tmJinYGpENDHShR 16AGkGJ4aAStdtmKgM/Wv3qgp6uzUMyHPH5UmepGDbTqapiCP9SDfF53jvN0gQ7FpuhFPVtYrllc ruD0zGgBhfq6jOp63WLLRgJBPoJiI6ORSLiUL1qs8uU/vLKQyy8dXH311VfvtddefE7h6VkIJmkA vQDxiJ+Cf4OozOkh2bH7UExl/T4kkQZW5EcGlvpVG6ZQHf7QSDJltcmxsUH2o4Bubjw62025EUMm BoUr44WsCJhCdbiRhmjcZbeawoGksaSOcdGijoTSVG6rlPOcPixkRxxu76qh4VCkV1Gso2MpHx58 bFZ0oTiYSYGUAJCiQGYF4IymkshPICDAdNWqVdTLLapwu/zVas3tdiL4UlQLAjW73YFtdOYSIExM OXAJ81A02O7wY9yhs6e7XKZDeaNaUSxKMVfwuoQgdt1JOhmmoYXrZm3+Xk9+bkF55hUREXgZiZAo ihJlilsiUaSsfeXuhPW2E9sUaFOgTYF/IAU2GCwFm1l7DWXpB/GQMtlaGUunuoJeA1dilYKkWN/7 0/tfOvSowdGkbsS97sAjDz8dCXdvtEnXso+Hp/Z15AoJj9vcXWLhFqyOVRsmBKFhdROS264oQDN0 lTF5WasY5XTyhOOOf/i3D2fqHWzrLVvy3vQZ0XIp63G6Wctzei1oRxqkOD0ufHF4AwGgk93hyBXL 2BqnC/BU6jXFHh4P4hD4osCO46umYXQcwAG3gwigFgJsr+E0go5IWI4KFshuDzk1zeEqmQIctjGT 2RQqYEDAcCTKCT68q2ASoVIp4mVFAlnY2OisZpJFuyqRzZDVfE7HFZwn6E0nY53hYM1qwSx4rWH6 RSnkc7JNDfg8lVLB1xSogDnoBU2i2dADnl3V027NX2SP1W7L5vJ2r/3gQw/JZdmpQ45nG02OdXZ3 R3u6AEBDAwOREJ7p2K6qmMKqkE1R7PioA0cxIopbkYr1Qi4jW2SnQ1u+YuX0mTOSYAV7I5fL03K3 y5tFc8jjq9YtdGZKb6RWUrL5YipXDNmdbLi67Gr/8FLNGoUgSAIpx+SuFstRxx27etUqbzAAMZHf YCYAAA2opf1s7QFuGBE2+yAyAaoSp4OpfDXgB73Rp0KtWuyKBi11A2FbLFENuN2lStnrc8dHR5x2 a8XQNcWBSx7KYfZSLCVQM9Ux0Iwa2GX27NkAHRpGT7mSR8JShdOdz2U8Nhcm6UvFQjDk14sFq5vD BUw6K6cdUZ63y/b4WDwUCWZSpv4Q02ZkZISJwXYDxdJO2k+bqYhKqb2jowOdPHYYgUQWySjzGYH3 wVKZGTI2GlNNMxl5HhfN41keZP4z+Uvs5Vk1dPzH4kPRjg4LXw6FytSuniR2wyYKdGSi5EnTBO6Z 8DYzitK4EkS2VuEikSsPijgR8rRyrqfYCetqJ7Yp0KZAmwJ/DwUmFrr8PSX+k56Fn4m1kvVUBNi2 udZPEqYHA7lUWq5XXS7H8PKln99vv30OOvij/uFYYsWVP7x4p122AQENrM7MnN0lWcuK3dT4AQEg EBJf52IvBoY3SfElPs2NcsXcpVPsPo/nzddef2Xhy4vefa/RGP7dU093d0WyybjdplgaHEMrBEJB RbWBPJIjwz6vB4EBXjgQBbl8QaqgLvZ62IKhj/yEEX7SxQn+ivyQgkB++B8R2LBuqVdsUlmuF+GU qHarVnBToV6xOu2pbCqRTpFLARLYtGK2NIKzknjSKFetNq1msdUsVjsbbQoKZmVrw3Bodg78906b VpXkdAa8WIuNDmAQXLIqyKngvrC4WrWMraZqqYBKDVIWsYsEaGD0icPSiiCjWrWgF+GGHZGIjgpO tdodDSCa0wtYRXLGUolitbx85QosuDvsUD5nytA0J2fQSqUqBwIcDhegaiw1GuoI0gZDL5Xzem93 b70h4ySulCv5PYGe7l7mgNvjqtarHDf0hXyFVLVWaUjWerQv6PRbStWiItv9zkjIHzBK5aA/AJbl CJvL61m6fFm0uwt60gX2c5lObG8xCiAJygTx0AswCtIphgGwCJG5ZbM0yrre1RnFUw3QJFcoYoAg kclN7Y2isGWV69lsCuRK3zWXE7LzCOOLoIjyQScgGyYYtVAaym2iRmoBvQGkIKBsl8tGSXWoNeRv Rh1Nu2qxYmvYRlJZvWak0knOKkZDfhz4uRzuSrmGfIsHKZxnaTPdAQbRYJrNfGYsAFKkUxGdYnqP jSYKBayBom7mSSRH83nOOvidTi/ZaBX5eRbgxV4tT9FyixXxpS8PsnRpPh+WN2qNaqV/xaoJpmYz SSCb8de/NX+rBGYUtBKBqU454lYr0vrZSvknLUHtYtsUaFOgTYHJKLDBYCmxUArcwBXGAJeCN0zW saFYWqk3MF+ZGxlcuPAF3LX94EdXgFNUrXrwlz//5UO+ePoZ3w1HfGeeecbtv7rx6GMPmTJlyhFH HAFDAsqAUSiWGgmTle9yONhBGxkcQt2XU01jI6OrxsZ45o8fxHbadatsNmGV6tf/7Oea5ol2TH/6 mSUoLeH69/RTv/fQgw9O6en50dU/PuZ4jsUl4MdIJq655prBwUEYBtWRAkeEQU4W4HDwTq4weAGn uHpUl8vmsNbkaqFS0w2FTRvDUsmXM6gO8/muopPkgVGWOOpeskzrnaWxCyWb2KhasyDFyRbyhUIG ZX3VKlXKpdFYvICrFYNtIDvgD7sDqweH2Q8slSvFJtqTpQYK7B3YiPT7YdtwYlia4MTAO7M94UC2 VAxEvA6XBpJAfBdy+woJ3aU5jErV7fXYOCOp2ECZvd09qbExm1UFHAKe2HviBCIDhQJ6Pld0+VxI /dj+UmWrDcvuitY/MIQil9PuK+eN5FjKqNZUNLHrlXQuoRs5h7WjWpZKlVzVkipUY7KCw5iG0giC 5DwuN8aW+vr6kNUsX7Giu7c3WyjQfjAEG6ygB8SBUBXpFMAavIuAkAnATBNXkBA9xR5VMZPAAXCx kMegQ16vaN6A0x8ZWPFRYniV3VqX8dIjg6XqBtI+zQ1OAjPxIEMGZaiCCSYgOwVCMeoC/QiimeNu KenVfN0UHZX4D7vlxVyFnWSb04X6G+qbzKvh/lUDq1bVMXygV2kn1KZwXgqKJdARXg3SKRbRFHdJ JCUajZKiaS72aqtGBWUwtkehdTwWxwICgFII3mgDzxLnEWZjrWErV1EONBxOtX9gZSI2ys61Ktsm m5wtDLRO5G/NT9WiBCK8F/RCBBLN1/ITRLVOLfwUD3IlQBMRaV/bFGhToE2BfyoFNhgsxUrKkiqw FNwI5s1nN9AHLjJh8DndHruWGOhHB+fZ3z9z+FFHcuSqAgSQyuiez5+/yejYEDKCRe//8YQTTvvC AXs99dRTDzzwACrnFM66T0UEWN2EhZOYSWfQgEbCgfxkbHhkn7332XP7HeZsvtmDD98/MDgaDPie evLxH/zHxcsWr+Ss+v577z+8cnkuk376qacuvPDCV9948/P77vfKq68tW74CgQFnEmGocHTBb4BW 9EswjPFXuCMtFOIo8pMB9o+oI9U/ais1wg5fwOYiYikYjprVb3NlyiVPOKx5fajDIymKRrpVq6Zn ywHzICEiBlNfHZOSOGiDNlZZwmASOkngORtcGIUa2cqpQzycdPf0EkcVndpNo0SmLxprOpUQbWZo aAlsGKIxNOCPrF6U7WomX47Fk163B8sRoDC3XQNI0Xi4O0iDHTF4IpDFiVaOP4BTG44eNpXZMSBF GQYHCYtlRFp5AGE+i4RMguw9vb2mBo0ho/qDPpbP6x8eHvL4XNgN1yu5ehkPObKqYWwrWzJS/oDL qFg4i4jSNEfqkeAUCwWe7pvWNxaP4aIYeAEBGWgazxxDGNMEHBoUYETIyU+BFIEXDJO1XpnS14sF cHh9kWOeDlc8lUPc2RFwT5/ahcl17FzAz90+XyKTl+0OUBqB8qEMVUAligVaEYRQikohKbUQAWlJ ck3VrAjvGuwf16WyXlWsGp5vMKIFrq9WwZcZj8vJ1ir7oWyoMhXFEABYKROVO4oFwCGvMolkGFQN aCMPGeidXWVDM0ZFlK+XOIKBbFJhEoAgyUw6EwyC8AiZAevAuYZk7orSGrtq83o9OruHmP+YJFDp hGGS7JN+q7QKgdBrY6m1V8NWnnUia+dpx9sUaFOgTYH/DxTYYPSlBMOAIqybXFnu+W7mCgeakEw1 l61eUUo1i6suZTOpno5ePRWzWd0w2RFOn3X0JPScWtfldPnW6+/bcdcvhdMrA1a7YWnE6nAY3WNV MUMZcXrzsnlOanxw+0OJbAFmk69mbD6fLsvX333X73//++OOO+6a//j5cy//8vGF9xdrU8//wQXu 0Aha5iNOY6O6Vyvbrrvr3kDP1BlV9eyDDrn66osevu628753xpnnnFsuVopVw+33K15brGiYuloT BSAGXJleE+AxZIETE9BANqRGrilLwCUL6c2zTw2X1dpAwxxTEHYZMJnWExiFKEocsDNLN/fXzL8E pWZRTLVzG4Yb+IdmT96uSOgaI1orQ4N81iQ01o3wqWK1wWBxjiwrmuCRzRJMntf6Kdc9JvdX8lZF Qj1dtUXMYqVkGUmBhSbYMKq5ZvIpVsyGSsU/079BBkWoVPNuyY12F421h9WCVJVU3MYkIE5FlSq1 nY3TfAAAIABJREFUiqn4Va4GfMFyloItXou3ak3YEN1UFamKWW8Jf82oqyke2qYZjbpit7NrS8ml oikhk8CiWDpt6p8JDAFaEliQ+cbgkhPaEqdrpJttcmiY6ASEgfvoLHYa2JENOJylql6qrvFkDCw1 8skOt1XSk2AyUQhXpq6JwpvCVAaRGhlNc+w+CUxpTdYghsp/0EnBeIFapdeKpGXNxjD1LS53gZjU cJnK7/Sr2SpJAv1QGqiadtJgkB93mSSiF2saD90M3FFLehGLnRzuVMDTqGmZ5005xclOsc5ElvlK oZ0E2qbZGHf213nNXJLiqpk6XaZbbB40WzEuiPlJMh0kiEjrOi77mtd5fHprIolCyCBSaJLILNYB ESeP+Ckigpzjs4mU9vXTTAFmNd3ndeAF4duDt4PZznvHIvBpJku7738/BdYsTH9/Qf//S2DdZN1v LbXrNCAVz7qt1WhHtJQcxqT1eZf9+OzLfpKv2Qq5mssTePHFVzaaO8+JMc9GZdr0briqkUD1JMJB sFoiEYiEixgF8HhKetli+gOeIMB1hGAMPAd3gQcjTNp///2HRt/fct6xr7/+Op/1bCddeumlL71x 69GHXqMCHjKG2+VDzRvlpFIu940Tj71k1y3veeBRuyfQO22Gzx8sjo5YG7V6uYBzEgkV4YkCfIIu T9briZ5op62PAlCS4WtxbhZZJhULLsM34WMtypONDDxIxBwU04zXBEFkG3+DBwX751YrQuFMp/GZ SZmsPRNm/l8k0k4RaAOBJvGTK4GmkiLKFIQicT1VcFfkb0XWk5laJry7dqWiDaLqCTOTSDlmu5tr Qisufk72SDv9U0gBPjnAT1z5kmGe8Loxu0Tip5Aa7S7/AymwwWApZvza3RarZFM6MzEP6w56M2Ox ZCrbFe747HYLyuUrzj7zjHMuulyWPA899Mxjjz7z2AP3DA0PON224dFlU4353Z0dK1evAsQEIx1W /JuhBVzHrZyzjOhmosB3DIs7ryXfNHzfcOUsWG9vL8ISbqGzsueee91+w0/YsNt3331zY10NZzWg enTd6Ozsxq+wokrdPaEtt9/k7IuvOPEbJ7kDkXQ2h6AgHR/xYIixUapg22miYLKLT8JE99tpfxsF hFiIhZXHwMdAFiYVV2g8YUFrpwscsGZmtsyU/flja+f/8ztrtHnIQDkUInK2BEjrZKZV66SIn0zC CdMnq1ekizYTJyLilE8zCCJRxCkZoCnyiIpEnOv6y+euyNCKTNhIEkW28XdpD7eoVGQgQlhPvYI+ ZBZdINIK4wtvp3xqKcBCLXYz+F4SM4QZLlI+tTRpd/wfQoENBku1VlKxmtN5sXqydE5IiFQy29cV ScfR0LXMnrfpo088efBXj/7vm29Ty1nZEb7jvoe32257XyPJHl20y+9wSWOr4yjilIu6aV27UsUh TAOrASialM0tofGBw2sAKbRSaBjKLuzuYaYI5ETOk0/80S677OLwFC64wH3ggQdmSmMueerrS97A aVrAH0HNxed32jvDheEl3/7OCSccfs1Ou+9d1rOoVndGugrZhN3WKOazVXli+z2Uvza3EA1bD48Z 3/J2ytoUAD8Bp1ofqaAodqnEFsDa2Vpx1l+ozU8xD1uzUbKssSfZyikiDau5Nzc+8KCJDppBFLh+ 3i/2JsaXQwHjE0mZLF28L61mtyIt1iI6yOMCRZHOI8RJp9hWsyd773hQ5BTd4RHxc8JGrj9RtK3V QkomLt768Q+K/opK166aR8Znbqd8ainAZgJTiNnL6k1E6EQCsD61BGl3/B9FgQ0GS62zJrJcildi spXa65QLeOJooINsqozM3WjeO2+/hX/7Tswj2TyOiJMbNaP2yJOPldBNcTi1WdPf/tM7NpdWbtRg rXypyLItV9Jx6TohrbGICN+Fx/AeIiI+9thjDzjgAJoUisq50S5/sIDw6azzjtzvwO2mzq6U0/Nq nnrEY3v1jTfKnZZEIV8cHnZFO/fp2WfZsu/ohdzyjz+kqBUrV3YEPejTuF2OsjExRqQxLAQtbjFh 29qJfz0F0LYGPAmsAKhiqUW+SGQy/QkxD8df0cqfsFJ8r0yYzghSCAhAgADyiDFlrk6YnyZNmL4e TLOe/FRNIEMrIvor3iYSaRWTmQjp60w28cj66xXltB4UPydsz2SJonxRF40hInLSqgkfEWRs1Uue teMTPtJO/BRSgPeLl523iRefYxl8EvMlDKL6X0zRTyH12l1eDwUmXqDX88D/1a2110rawNQXq+pk azrOhp2aw2rxcnLJyBewoO1zurCcxPEka8lUbsnkSj5/ZHTp69FZW8YrpUoq742GCxwWs8rlatHu 0DhJhm1u7INP2GXBZngnEWnw7Q4PxmUHXFmx5QynVK5geymj1Xs32XR2XVqJX5mCpSRh9tCjwio5 n+XsmipZcHCihNzWFbGsVKt4PW6nZrU7FMxLmhapP/GbsU7tdJxAr7lyq8Vj1snW/vlXUgBFN9ZW EAOAGGJykPO2224DSQud8fGFtAjeiog8DVMvfIJgGjGYKAik0kIJzVE1LzRmouyTpk02/8X7Mv4x US/ptF90QVxbGKWZ/D8wSzRsnXLIQ/o6ieLn2u9p69nJMvPIZP0VM5wHqatFpda0H1/1OuW0amxF xj/STvkUUoCFWlgQZN1mzjA9OPp66KGHtufJp3Ay/GO7vMFgqbWXb+JQgYV1PWurA8dyGDUoV7BU 6PR4EBok4vFQOCxV8k6ne8lwYW6XS08OR2dtZh7Vstq8US2XTHs4lG6TsQFqk22cQ7fL1sYk+lLA JtrAlVrgQ8ApXk4+dODKbg/+clW30ldIY14cQ+GK24fsS5McspRC/dxWtjtAbLWRvK+nc3jRsr5o R3xoBRYTVId9LJ23a86cgfuXifduqK4VBB24Ekj8x86MT0lp2JcCTnGoh4EjYLQThzzz5s1jak1I gbUxyto0/0Rusu5DgN51k5q/eVYMnBg7Mabrmc9MsAnLmSxx7XaunQf0T42kiNpFhKuQe7Wa1HpE 9FE8IhJFymTlky4yiB7xiPjZKnCdyGTlwOd4rcQokIcGECdlsvxrt3Dt+GTjuE4z2j8/JRRgbrBQ M9sJ7O/jLWDlypUIq9hk+JRQoN3NfxIFNhgsRf/XXiL5yRq9noXSysl407utt2QgMjDPfwOkMNVt US1YVAJIpfRaINjF6fhMIuEPhRAreIL+Utb0E2JzajiMc9nsHKnCc++EpAdFrf36ia0Z7PpU6qM2 w4M1dEMaBbThoKUmVWgK5/SlkZjUGR0tljqcmpSVrNHOnJ6aPXta/4oVkYAPu+O1uuTyBrBrUK01 fLaJ622xKEGBFk1akQlb206cjKMDpLgFimIugVcEC581a9ZkOuAt+UerQBFB1jhhwAb6hOmMF6GF DKidcrhOtsdHCycsp1XCOncnS2d2Uy+Zm/WvifATBiMSxYMiz5qufZKfDCKFa4sOJK4dxOOtbK3I 2nn+mrhQBxbSMlEmccJk9YqKRLMpvxXhkb+munaeTwkFWubWkE5h33/69Om86cikJ5tXnxKytLv5 91Ngg8FSLI4slzAbAmsrhgc/+OAD3gexzo4nBEAH9kMGFmXO2QmhEQJefo7PTApvFLfgZDyF1Le/ v58rzJUwYX58rzz3zO9x2OIM+Pi+8eGPNp5y4dtELiHbYBue3SJsqaP8hOQjX/hIVT1UYaxYToEf NTfs6Q7Z3mmqCS9btuxrM6bYFblcSDll2e13C/tA46uGDoR10imKREEfEYcsrA5cJ8MEzWL+h5Xy FGVyFZF1yudnwKIsNtKK3RnNAPi8q5QC9ir9g5kxj+mR2O2wp5Jxr8eDR2SrolmsNiObhdrQE+ZN l8Uo0B5NkVPpbKSrZ3X/IEbBMW5plIpOTS1VNVVV8Alkkesut1Yq5UvlAh5cpLoDKlEUDWYcsXvJ yFImJqk8qgPrnMmRMdbERD6r+NyGVVIrdUaQzMwT8C4BCkAKbKbjbbpukUIdEbzpaXZ7YjTWEQqX aqZZc+xZkJNuwnopzZxkFqvQgKqUG6od4kArTiGQqklyUqoEsZAlWZbUJG+j1gluZ1aZCYxmDYvw GMA0o5jnKmHLHSVXi2m2y3CQy1GVLI6apNtWOaSoZGhSRcrYcjZFdYLbC1JN0V1qoI5fPqtU1BNO hxvrpjbVPIhQq0qm2S2LVCwYTpf55gLgrLQKO6jlimTXGlaEmTWH6X25jEUqMhCMKoiNLnBUkB0N DFyZ6tuMMr3mLh1t5jIv/K4bVVpSLuZwjINVd3NOsCfdRHEYleI7BCNedRw2Yt6rYLf6zGfL2A1R LSr22GqYG5Wd5RpG9iWjbjTw2WjavhIF8BljsHdt1wplw2W3ITBm8x1nAJKF+8C4BkprYFp8l/MI xGYQmTYMNOosfKKYic1gDmvNwKWj+auGU+a6IeFpR8Uts1/CPlquLnXEJCjLVmmtLKm8vROOSxUb Z/RsPELFeBdNoMs2CFKvNCqAXBWSlnXEYmz4Y8C22RAswpsEakhZS83LYJWKkuZkhphkNyoSLpfa 4V+QAsAmZj6vAMu7OVIGHrvX58P+X7AL7Sb9a1KguST9azbtz1sFt2PSM/VJhjvC8DbddFPxVvx5 xol/kZNVWKzOE+fAXmGhwJvGXTJvsskmk6GKNY/rrMY2A0+5rNkwjErJpa7hXonEcN+06dts+zk8 yXi9oUwm5vNFUFGHwVM+qMIEVU0+AdSDzXOFkZvsu7ldyJU8f6H2cX0gvwjijoivzSnHPbFGxtDK Pz7D2inFdMbqg7XhV7dUSKfStoIX89tev2KpmL7y9DqaY5rDWcMdH+bV6yWOftEGvgJpA7yQOFSF dSVTiUhHdHCgf/q0vlyuUMbMOva1DQOHwUNDIxiCcLs1dmPrDbzXaeVSpZA3zZFDEK7gS4HMuMJN B/r7Ozz+KTNmlPL5QDCQKetwa5eiiUkCwUFdgDDgLAQvGTW3x8127OjwMObUOXbgcDoabMBNop5k ehlusIdbtwrubpo1hXXaTEaLrVM1qKclh1+xgo0awAV8IeJ9xwylKop68Gmwl6VW1Wv4oTZtizFr rSVMiOLUBjOZJTUtWzjwgFlOCnSCo5rlcgFIFfWK06E2AVMonlgVDvWZsk1DQDoMz+pen0OArWq1 odIF2DtFmVgIw7KWTJn+Knohi9dn2oO7GDzwEAGBY0peVc0DExCTFEgEPCVCqNbqCt4EiTVquBai 8cxJo1Z32gBGJrbA2XTFwBE2VtAtDYu1bkHaqtFLO5BI5iBH3W6lFxZJ1s2u436SMx9YVTeRlRUj 7g6bHV9+FO+02wp6CaP5ZlWcDbFi402XLZzxaDay3lTix/2yYdBI5owAUgKU89FiVWyaagc7YiCf jXLQG1MI6poQp6RLRk52d5gF4ZfSIoPyeJ8nHBfF+T/nZKmL+SlogkVSqYw3cIoAZvIPUGSrSHVc A1CoFQrzqgLl88x/UYLXYFsTl9ROKZ3J+vEmUFds9L4d2hRoU+DTRAGTM2wQgVW1JUqhwSx8/7P8 TdQBPmfJzx0YhuDoxHlkorxr0lrbHEKiw4NUOml+TYGFsGSSg49Y08vGJyEU6nI4YGMNgBRpHl+g ho9hq1UANWABazdXbtEeEjlRgiiL1tJOApUKaAUK+esDRa0TxLPrJI7/+Vdms6qwMA3G7fG4XB58 BQfx4gNsCvs8ONGFTlWjMTwSw7qpEx9wNVOiQKBrcGt6BEmpmrp8wQjeiyOh0OoVy4u5tOlRmWRF HR0bCwR9ndGO5nPYJ8eiOuy8Dn0oAYpRArfgrBAKzmqpNwL4nQkFM5kUiAxSAkVxziIANzkhL1ew FPUCxGsSNrsAA1Wvy23BWR4fo2ab1hq2T4ZP/LUxvFZkPfBNEhp6KU9jhLACWEQSUqIyFskRbYAa muNfQCTDveZmWT6DoESyOv02UyzShNtI4Ayc9FjdCjKvhM/F4YMmn9ckvVZONzLm1HRQRQ0gRVRI ngBSBQ5sW6nGvI9xHAGMEKHy0xSYWWmMVULeVAFR0Mu6x+7TJBdAKpVKQzfys5dIZtSNAFJQD0TC iDAWLSBlJuazjBJCKURvZkcpXFFMUGhDRoQd+UqjXsM9ooPTERbVwU0nSwfAx4RPBDAm5tFBVZLi kGR7RS+BKVSb1a6a5xhBM82TeGZW/ucMiDgeKyqCsMjsuMUrzm1gYjKRp3kMHA3jXeBjg3eTFCaD ALOIpsz8zRccQKWhk8hvzYPbQuRKBcCQiSqRJ5mgaMJxoVjGn6tAaQJI8cpjR1+yGpIic4Pm6AXz PcUcL1O9OQHop7lrK4AUjtBzuYzNHFBySTYreMvB+V/zRzu0KdCmwKeJAhsMloIrMC4seYJNgkWA HZNthJET9slazFqJcIIgUBGPE5kwIL1AakJ+KiJCTp6ihL84GWDs5NFgGXyD42K3XsXYAilNfiTF UnE+bWXZ1HaEMVAL8II4khLyEIGx0RGxlFOvgA6kU/XfFATvoUxq4UoQj4v4+KvIRh4eHP/s+Pyq E1dxyGgskkNNjwyW9AKSgJxeTY+OmFDSYu2IdmoOr8KWFlIKvQDzA85Sjugj1dE7OlupW8rVajIR 64mGoyE/nBMXf3q17vU6LXIjl8+gCI7UyeP2ceYSORDDQfM4VScGxXST3GiAqPAUCCeEyKWa4Q0G cK5XNww9WyC/6DgUZjSFUjlc0x8OokKHM75QKMx2W0dH1OPzlpsseXxn16Tgu7GMPAuMgucYt2Jz sF8GWojHl77x4jIEOnYJrKzAf3VDh3/KUg3HzzXD3Ct0e/0mH2/Um65cgA9mkVaru1CHN4MO3n32 xRiggUMKpONxL2ghP1hppVRDs65SKSf4NTqa5jYzudwoiw1HuL+iYqyZnVPzCsJsgGEkKZvOmEOD oMZsoCVdEkjddJ7I3UoV8zmNkl6hRRAHCAVJSScgi2VOkuj1+cu6jhkREmUVX9Fm42slHNGY01tW bJx9dTqQPIFgcApUbchYODSd2SD3ohlEyjq7XkBM8z0lxotEBHxUqzdoYrmG4AeXj/VSDpRZx883 VeD5sVzW7aoL0EVGpgcvHB0KhswW8p7yXhB4E82i6GY2a2v212V6TJKK4B4CaoZ1SaVuCGp10ZSQ 3cR577z4h9dXIi+ceFzEdOLKRGV6UBclQeo6HnXM/TlEd6A5yWGKoyRr3YoYDJFYJlegYXqx2XG9 4HM7mKhmG8wes2vpYXcvm4Fozb43b7QvbQq0KfBpoMAG8wnFqseSJ4aE5YwVsLXCTjhOLMHkh++S mcMajz/++MDAAPxVLJrjH5k+ffrOO+/c1dUl4BRMiAdhzIIbjc9f5che0+2dwtd42bBgYbNctaC4 wdLdXEqpG8AXCYQzetHlcNqauyoYMuFuPB4HDYgq6Bdfxvj3RbmKGkkUCKAlMxhf9XpS6G8riGyT 9Zd0qoOJtkrjwckykyeHmQergeKZlEze9atbjI2nf/6gQ7u8AYucWL18+dXX3rjNgp33228/Pxsf pWzE62o09c+AU1RBRQwW5ROHCcOU7IoNocfg0o97ZsxJ5MoANaQeqXgKsuBkFwBULJQYLEVxVKtl OCg6Z7QBVgehBMUcilqy2hKpBOXkSkXN6QgHw6MjI0iqGHe4MtkAqcQBr8gbUpWi1+70e7ylVKZS KCbHYoBC05nzJ5OqRQcRwUSrbGW3Cxox64BH6ApZgF42pXT/g/dceeELC196u3smIIFRRlHGHHQH u06t0CQs0CTgXoMDYK8em5Sr4gRw+VO/vfHLl1gHPrwj7LNkMsN1d6hmVSu51aXRjy+55JpIt5zM rSqV1VBgvtPdedrZx9vsTLc6O5amApm5x72mIohTaupQeQNBqVGp51MNxFQO1a/Z9aLk95t7fFj7 0Mw9RHTYFHNn0GaaIWCOidcH7L6mydU85zOsTYgPLMHbsU1pWDW7uaWHRfhyGVQB9EEbDHDkduO/ mbwmzgBj4fcIvOF0WCsl3EqbbXM4zWKZThWU4ZxOEBwKThwCMRFZA2LKCAaBMcTQkRINQGzmcjnx uMz+HcBRVUwn08LwD01lDjCOBDIbpYqkKcVaxdHcVbc78QBl9ouuVqwOUIyZaXTJeeeeXdz0iOdu OHvCcWHkmZZMEoZVrBXijQAx8rReKjs0pwFOBJXWVKdDSRaNoNPm85j9MkWRXJFMW9RiTnJ6qDOP tFVVgrTE63NX62OK3EGedmhToE2BTwkFNhgsJSACo0JEgKS/OEJCeg9Dff755zfffPMjjjhCfINO +OAbb7zx9NNPH3XUUSyvAlKsB0hRggBS9WxR9jphZ3osVbU0vPYgjJd/JlktslfTMpWqz4GNAwPo BEQAIdF+EANAATVqxC38ZB+K1RwNMIACIAD+gV6k2AScsKmTJVIULedKMOtvsnMRH/+IyEk6HIUr P9dP1YopdMNARL1RzC58/jlnNbPbvgfbNM2uuZ2p3EMP/tbuiXzlq4eUi+XUwEDU78zX8vSLwqE/ V8YCQEPHJU5H6pkwCvuxoXR89IGHHzvoa8frtZpHzkY7w0grhoYGUb2yqxqbhna4mMMOHxXsHyEK EUqDOOVswev3DidiXRE00rKY+UolEt29PdCQvoAVGGtYL3Hy85TmdVf0it2i1MvVrlnTR1cPoMCE xhsekscThxQ7EAh5igV2j/CnAue1WGwmhjHSfr8LyNs9EykPIKIGGsHYq1mIUUYYo2guUzyDWMci uZwae3FqI2+x19JZm+JzmX6EcRatFMPRrU1dHqnk8+GrWGUMAp6OROKjG27/5YKtpqT0ZR3RjW96 7tktttj7+G8d2Wu3N+xIekrAGsjo9QYRJ9Evh8NDeYWK5FdRCpdkwL2V0xVssoFmzBblC8mm1lQp m8t7PeZhVeYDY8EVmjA05PkETtWsdhOoDeVqIY+5Nwc4o0sgWLpjtZr7uaa2OBMGAFkr1a0afyGe Ckoy9xjLkEduFGyyL1Msg5U1xQrscrqaSkX1SqGmWqoVv1NVvCiSV8TpRnptVW3sQCLrEuftUCXn 8AFAirbxItBORpC3Q3zSMKxKuWFzq2Wp7rWC86RkPht0e5G8STVZsjusspKFklLZEg10RSO1jT9D gyccFzN9rUAV4lexKjkVxJAm+WyKDWlkMx3X4TaIxY9MKh0KIE+FypZGPub0RHBwXbckVVsAX9tG WbJ72CEUUum1KmhH2xRoU+DfmgImH90gAsiGVZW1lUCcpRaWQGSyxpMZXg4wIgNH6qZNmwZzBamw aE4Yttxyy6VLl8KtyW+KT6pVmBaFTFY+rIhbfExzrQ7GP7vFVjNmzOBBm+acOXfjm+64K1XQlw2P zp4z955HHmOHD+4PkKLNu++++1133fXaa6/Nnj2bJsHJ5s+f/61vfWvFihWUCc8gJ1/kVP03Bcgi 8lMIQcRJFD8nvI4vf8JsIhFOiUyhUmIXpmGz1F1OB5/z+aJRGBzA/ClqQHbNlUqDJWp9U6egbQ0p EL9BRtEjRAsInBiOMp/vdkcmnUL/57133jrrjLNBQoGIz+f3oEVm19RQKAguQKSIwE8HmaVSlEAb AEbEe3p6kFFBN4eqjgwPd3Z1jcRi2SJSAbSfG5mhMYGA8e3D8AnQMDg4yCOoRtlUpayXHIo9vngl 5/hQKSo19+MmG+ISG3zmlhwWX52mao4pfGHIcTHU9DjRkNL5PLrnCGIKNbZ1CHWAFKrQIB7075l5 ADHgBzJLbvmD3JJcQDR2Jiu5nN7IlaSCEWO6gQmKqPdIWjjS0TBKL7351vvvL3nwoXsdWuDrJ3y3 J6yO1Yaa8hsU/O0AqWwu4XL5oBUwYbSM6jqHyApSJsPElfSKeTaO+lDn0htNIGVu0nk9fvrKmTdG RLwXkJS5R2i2nFbUy9kEcxogRcs5WWGWBkJCjJpugCiawrBGqTBmdk4fgxgjCcNUi4IwNbYgK1It aWtCSqfTDpAqlvAcYC4vBmbWLGznSQApPR2T+FnKypojlimmmq8vb5JAMsViwYpcSwHHmFCYpjKB eVsppCWS5JQHPxlcxiDFcUq3NzuWMOFPtcDXC0DKJHApK2VGOeyQhqxmmGBcxJtu3muGZjZT4Z2S 4hnzV8nUfuMIBEVW6qVh6FCqSjm9BpAqZNMmXIVCdoWqOEUgN89xsuUIkGruGzOk7dCmQJsCnyIK bDBYCobKqipkLYwPyzSMmcTJxkpII1hyWY75wIUTw1l5ZDK4wNoKn4a1kI1ayMkjZF5P+dyqFnW2 bTj3VCoWb7zhRjYT3/3gw9PPOOM73zn5kEMOndIV3XW33a+/4UZKQRCFyARTC88999wOO+yAFArM 9Mwzz7DzeNNNN2EfEg4HQKS1FMvyTuRvCuIRwRhaV0poxSeMrF3FhBlaiaUKukLmAUMah8K4wzQ0 gIjHwBEzetwwIXZ8Mpl8tVJ97eWFW2y6MR2cOXPmL37xC4gJI4Qy+CuEpH0+76GHHYZWzcoVy448 6Sy3277Z5psfefQ387nsueee87Of/fTmW27u6u7s7u554smn2PPkkfvuuw/dfArp6+t78MEH8fFC dc889btLfnDJ7597dnp395ypfb/69a8BoJ/ZfPNoNPrtb38bqsKMoee9996L4U0mwBVXXYX6ejAa TSeTn1uw4K677kbbXagwTzbE4D+kLPH0sjPOPonSLFa5I7BFtarjibinp/v5JzObbrIZvTvj9Bsd KB2XMmCKxYve6ezqlK3KDgsWLFq6GlBSM+o/ufr7iiWIOYmDDjo7BXZq2BwYh1W19z8amTmnz2Lx XHzZj4Xmj6S5TammAU4oX3jheT3dU75xwjYc9O+wdsPRFZuzVGb7M/XFLx501923HX74Vy2yssvu B6wczWrsqXm9j95+u9tpd2BSwjHjiSdeocnVWumsc7979TWX/+SnP2K/0unogjIYdocgTMjnCzyi AAAgAElEQVTbb78dvEKAAnf/13+5fWGbRT374mv6syY4Wfr+olO/frzF0tUR8F/z01sBE5Vy/hfX /uQ/rzr/hhuuUS3RadPmLnzpNbYA2Rp8+63Xtpg/N+j2WyzaBRddnshi58IE33fffnNXZxR7a26L +5W333P4I/lE/KsHfsEh2/qmTXtp4R/NlwjIBDQTRwIl6ZVXn9tyq8/wAkLziy66iEHkNQRGf+Ur X7n55ps/u+VW4PQ99tpz6fBKr6QmirnDDj30kZvv2GJ6X7fbs+2OB7zbb6ian41AFJ4awMJJxqUF IimctYJ385xzzqFSi6VnWt/clQM5zW59/7135syZ7jLtD/X8/Jd3+RQp4LDm9TJmsu+46bqjDj5A UwNfPOjk4dEVp5/7XYvNGw7PWvIuKmH0qYm2J5tY7fQ2BdoU+LejwAaDpWCf8HVYFwsfoIrrXxwL ssEOWZF5FkYLzyClyTuQYpjnwriCnFiskVcRuMVP8BnponDW1slqsegwl36lw89OgOT6oyyPTpm9 Tz0a3WRG3/dO2PL5//7q6ife+eC5waNP3+r5dx75oN8sJugdefbORz+399f65pSDxUSjtFF9++3A cOhpnXDCCaIuwAq102w6SGfpsminaHDrp2gqV9JJFJBIRKiIZ+kFzJIgymmBKiKChqJfPCICPyEO T1EmKcShG4EIP0l0VFfZilbZ4qo5x3K2kRdfX/zqwiUvv/TIwy+vfv7Fn5SzyZI01+FJVpcv3Gmv Y2cfc9lbLxdfe/jiqy+84OKfvjpY9vWveujyi//j1gc+/OitRw4/5byYc2ZvIHTE1lNqddfPbnn0 W1//pkcflRNvnXXmtZfc8uLDv7/mO3tu9Y3DLnrHj1HTpcV0/Tf3P7182WvHHLD7ecdebJTDcXvO kXzo5l/d94UDf/jAL++/5cpvn3XmaTO23P1b59+28Naz7rzzzucXDwWsxZfuvvabJ33vkT+8/+Jz rzx49U+vu+13MfSjlMJJpx6tztrc3z2l15Q6TBKQNJUAPov33HKnH//w+Vvv618+lrrviROliqWn NuPF1367y75zr7/1t3f+7Lu33Pithxcr7HUZ/U9uv9kWl//87jeGF27at9FR+1+2kjI+furUM695 ZOFbSz5cdMnlx2gRIIm7T+/Mvnf73p+bcc2N1910/aVXn3/eK/HcMlC0dZaEpSRb55tvGz//xUO3 PXFJUU474c1FRdKttNVu97hzA6W3/3T4EReHNt3jhVcf2PLVR379k+EltNYyXEjqt72xaGX+wVu+ VNz/kBvRAleMV+zLHjjz9N9f8Ub1hY/uOCUKervgmGOOWfT4jy89fJcTz7nsZc5bWNNjlx781cve eurNN4de/unzV978m+v6y1Ls7t8d8eJtQ28NDz++/JndvnSgVKyotsfSix89/bzfnbcq+uYfrjnn yK799tnlkXfraSlnGTMuPOmB58dWvXrr4VddfOOHw3zkvPrUXed/9egbvnL6M28Ov7zw5V/3WCNS eemWn99s0LLNWytrv/jRWSftss/L6K1xSqSexK5AupyXSsvkoRXf+M5Vo4OLnrr7mkuuuOTB90Z5 bwP6yvSHC48/4aztrrxw8V2PdCxc/tl5+w8CwNJvFJcuPOD4kw+//Dev3nmt9sYje2+x+ypkgiFb qvacrzpvsnFh1MvSMq5YqZDKb+yz2fSrrnr8xodffW7ZS68++OA09fXk4js33fzrG3/t+peWv/nc XXef+Y3Dr7z2jYGY5La9v+T1p4/4+rUzdjrtmecvrzx3XXfnPisaX3r9N7/YsWv465ddkFXZAm3u sE4ys9rJ/7cUYElkTWMZJLB+suiJ5XGdlZZGkpNAtvHrJ0c9KmVTewHVQPQ/2Y6waW7Dosh5Trx6 Cmp/oTpqjXfZcM7aNTKUjVoabBdreilZsyRkJWPUcij9Ioj/vyVFu/Z/IAUmlev8A+v4vyqKF0a8 A7wMvCcCJwmxk/kajXtDwA2iqdz6y21WEP3rbAFpsLoSW4emj5ouyVcxJM1W2u5LR1htLywdHN5x 163Zwnnkv16bd+7GrnLxv3515zev+LEiOfVGNeQKpeOpXWfORNBCUzn4jZoUEZpKs0XLxXXtxjTv mJdWU2ktrzQPrp2tFecWmUVnSSTSCq08pIgCxS3SW6WJCOkYDPL5XLkMkBQLiY233np7LH11Z2W0 arjC7pfzVT0WG7NYpj/9zO8Cku/oo4+YFdUaoc3OP/+QM6+69NCv7e3zhDBy9M47r2/d3bnttlvr hYoWCuy+554PvH//jgsWWPR0Uf+AY4K9U6Y+88JvOmxvlBcO3frkM9m0TulfO+LQuqoZpY922XmX mx+6pFyqe1whoyb7O6Y8tfDZrYKVxe8VJfkX9zzx5N5bzvNlVU/Xrx0OUxL2gx9ctuOOe4cjIade Z+vwiSeePPa4r0zxBw4//HBp+qbxVGUKZJxsqFnllMjq155ZsmLsxl/effBBvbwqAW1LxdOZTGdC WvC3763YeIbq2y589iX/PTKcKU2t/+H3z6IK9Jn5n9G0sQO+sP9vH7x2OBML1A3NY3/55Rc+d+LR 0ekB5BUOtzuVT8v2WQs/enHjvpx/+9qp3/tRKZlQ+jzmVp+zKNVsxx930peP/OZWcxbYOH9XrGsc TGvOTgwfcRoRT0eXnnvFiWce5peGbvSg05QLmlpJ+cOO/Gp/BHRf15xBMMSy1dK82QFEQrM3nvfw ry8IGi9vccHJPzqtWCg2nNKqUz0zz7/zixhScGrOUy98sOvLV4VDHV3qzHw59/jjDx96zm4l3YhL o/1/fGfvz2+Jhrs5W3LWYrG2/+FfOePn52xVH9pq0577n7ng6aeemjdr1hb77bNFTVpU6f/sNp+T pN/pnNaLZc4957LNNv/WhRd8LmLNSZGNpFpg1UdP9a+Svn/BMXqxuPMuOzmka5cvTc23Ky6vrz+V 7EODXk9ue/CXNm/47LXE7DlzXE4VH5qI6qRAIJ4o3vnkCzvsuVVfMvfEo0/Ihx++aGj5fl1Ta4b8 8BN/+Nw+m/tzQ889e0N4l59+8IHUN7swfapjzIotg+qE4zLNF8mWskEUzKxS/MOlo6PZ39z+m92+ MJdR9k6Bi9bfeu5pNNsuPv/Qzewl66Fb3Zp785gTvnnKSW9JmVK0Qzrlh7886esLqgXF5/UdeOi3 L7nkxM2U2EY3/vcjgwOcwAxqQZNc7bABUqC1EtJ2ERfXVlfET747+VLlC9yoIjC2srOPOoXT5VI9 3kxdCoeiw5mxYECyaeGlK16OhrYoF7INi61v6rzh4SGPN5A18ghjnW4FTb92+PegwF+W7myg/WTG CxzAtSVcQQSFiEUEQBWhFQdz8IFCZ3kQ6PCXe40kQrabqiUoaMhWv8eFojJRDvSYajX5xpBRSdUa ASl6y2Vn3XHpMSmLtiyRe/vjlZ/bY0d2M+JjSUOvTO3sYRcS0ZTYgqSpBFqCjIqI6IK4Nu/8z4VE qqKdZKZ3BAGDWi0ngwhkEEFk+OSXOe4iRfS0FScDKeA5QRki/CSxXC6OxWATnJd3kPadb5/8zDP3 33X3Hfff/8D11103paPL6cRpaGLRoj/t8/k9ps8I5kvobNunTJkrFcfQTu4ITbn4gmN+cs3lC7bb +z+v/gl9S42Nhjs7aESpqHd1wMc7h0bGjjr6WE5C5vO5ObNnMRjYQy+mh+79ze2dncG5G2115ZU/ jEi9taqtkMfSZhi50pRpHN4qNBrmqcBZM6bnslJ2cATV9VwOA0VIL6VXXlm4zUad22y79apVAxAE 5XV66vV58WEdDqiIN0X3J7gCHippzeFHxXrmzJ6CbhqV8nt6S/mE2+OfO2/enFkOlUNp2UwxX+iK +jRH4MWXX0F0xO7eplO2OOLYw+02GfMQvs7ID6++8pKLz6MLV1x5eVyXislBf1fEOWO7jfqAQG4p nZjltat63pw8Tjpdvef2mz76cNV//uh6TFymdY4oAqRQDtLRbGKO1ZOJwdGRbbbd1oRP9fqCPWaX 6vGmHNV49P57pvp6vJ7NX1j4ISpZHmRgejWVr510/PGofXXYOkah+UYbmyqBdZesBqyqL2SX4rER WZWGH/71NlttF+rZe7Qx1NUV6Jamfe/kc/ZfsPcJ+y5wKLYHH3mbPTjJMyefr+0yf5N5lCC7MeJU KBRHhwdnOWd/9PTT86O7bhaZ+p2Tz5HkajoX80e2Sieko476EifhgICVhoFZcq/LWypIx371oK3n zZg5e9uiVCzpGZfXLVVSACnTwoHNvviF56Pdm7DheOTRx2BXPJuKm0KefM7r0zClbmI6O9JMSyO7 spTXG4liIq5bXUGTAg2H5ghKXtuKVbqkzVy+RDcq2cnGpZKvR7Qp5ltUBN16R2pSJBwQr72OOLIs 3ffQo5tuuTl2P1PGCGQMB3ptIcfij3l3g8uXSltuvXGqJjlcHYVSoWdqN0f6MIgR7QibhzMosza5 vJO77fCvR4FP1ktz9Ajip4i3fq6dWKqgDogNYY6DNLDmm0nEEmNDybEhzMBw+nd1fCgY8OfTUrlQ 9HsCuQxnWTisnbjpv+754N3EzTc+Ljd8bIqUqvFWFe3Ihk6ByXnJBt4z5j1cE5BBP9gyI06KACji leDKLREnAlzgO0Mkkvkv9r5hHoFSTBt96MLWavlsgfPePKb5KdZVafj5SOnbZC6Gbw7bdTef9NHC RUtue+CxQ48+wemDtVg7whGMg8cHB9nUE4f7UOCgeWgFEUikJaK167RZtJC6aSShhY3Ez7WbLbrW uopbrZ/kFymtB0WEAolQKSiKQISfJAaCHoBHLBbPZXU05qHu6GiBw3lAPrfbg40iNks7OyPzP7PJ 3U/8Wi/VFLekOSLDwzms/QyP9HeGZxz2xWNWr1x05Q/Ouvnqqz/46EPN405mM9liRscjXk1CDaVu wSCoY3RMmhKc+tEHi+qYjqroK1YuPv3MU5959qmBgQ8uv/xKNJy9Hg6BaZksj+hLV9ZsakNuqNVs PTYyCjbzdk1J9Q/MnDmHM4PI0r7whf3jFWN4ZGB4eOC5J2/zek1LGWowks1lkxnDNIM5WeDNwOxV w4EK8pKP3wk0taprBavmjsRTacx1o4lMGrzT73WkYslCpfjZbXcI2V2x+Ioy3UpmE5VnOzk6F+o7 +Run5HLpW276xaXfP++d9z50BnsGUomM7F+OhQXO71fKUiruALvSkpKUWv3KZZdfcsiXj+gOMb0k n4NTgflGaQxVHQSPAFs5GJAR5HjcaQwhyWq6HGsoqFRJy157/Lsnn3LTg4/UcsXjTjxVchh6DWPk /prVNbxyZY/ZzYysuStGIUan5XCuaNEaluxQxuf143fmsNOOScUGE/Vl2UblttsPx3i52xG59qUb ht588fRvH3zcIUct6Zf0eMHvixaG+kF1fJTIIdNX0vSpPR8n3vzKIQcfCKnztet+/ajsoZ7G6OqP o5Hggw/dNsWJNQTOQ8rgxgynGSXpuT+81miMcaBwJD22+y7TzKZJlhRewPlbLO+7/4EnfuekbKH4 0muvd4SCPpeWpdtGtX+kFOnqNTdFcrHRUtrStxFCK4vN7fMG86Z5TQRKgcFBtM4H5m7EyDSCbs3l rE02Lqoba5458+PJKY0mUhGbFB8bCoDTEByinGbz7vb5Axa/+1Y5J/mx/O5QsmlUApLdvWiH+TAy ny+OGnUpnzSNydnNAwW0PNfAxFmlub2Hmal22KAo0FpXxQop2t5aLdfuikjEAz2oGTtnbqfzsYcf 2mePXbffYcddF2x74RVXWxwqihd8jZoHfY3a9jvs9ZOf/9pixUFZ6bzvXxYbrp51+uUYmCFLtWZa 4GuHfw8K/NtiKdi/AFKMkzi4hLAHyRPX8YF08qMeRGZeFQEmRHyyYW7KoKycezediXm9fHlYag1z TS0PgaVuve3xcqPgDdvrALlg1+6b9Z1x9oWXnP3jo475OtL/nJThJKJdanR3+mkbQqnh4WFx9Awd WMRUCMwmq1ek00IirSuRtUNrCSDSQkVNaLTmIhDS2o8QFwUKLCV+ihTiJFYNLDZZ0Yb2+SNWGTOY hmq3BUMedKuhNHaPPF435t23237rTlfo2uuuGU2tXtWfvuKKaw/48p6z53YtXjTwzuuLs+mBbbfa WvYH0Pu2aurUmdMx0jg8NFzGn3PZ8IciA0MjWFDK1zL4p8lJSbeGz5lkuYqkKt+/evXxx5/ktXg/ /jgG3HN5etiemTHLWiimPa6gXQvNmdG3cvkSAFB0+ty3337H5facddYZ9/3m7ltuvSOdjqNz/bvn P6pWzCNgN//0muHhETTLW90UVF37avJmX6Rz6kbTp3ade94pz7z4ZjKlL3p7RSId7+jqLZYqIMvR PEraGraS7DaLS3XuuMtuGKA86Vvn/GnoT0al/MqjCFQs2eVL7nn4ASwVdXVEPBE3HmYypaQ92OF1 K26blMyslGbMbuAjj3WZGjXprbf+tGhp4qwzz+EkHQcbGBUMllo05cCtd/l/7J0HgF1F9f/n9d63 b7JJSAdC7wJKUEBQkCJFQAH9C4IoCoIogqhgww5YUURFlKKIID+KdBBFemjpyW627+u9/T9vj16f u+8uWYgm+7xDmJ177pl2pn3fmblnrvj6j2u/DCJtA/EctkmDPGCetFr0RWoGlbjOJl7CwEHwoZVP X/qFb5tyfZiYMptbMwVLZwibojhLxuxzWZMY8RjLZVvau83FTNBhtjkip3/qot98/aKf/uhWTBy8 uOLxRx7J+JT73rsf63/2Bev2S3u6ujDfFAgpV8usbDr38+uuu+eBPymb/6ovfSmVTr/7nYd0RyLm cqFYyPfn+n/1w5sr5vRooq+9Z99Pf+oLjz925xXX3pgYyfYPj/3xpifm7rL7gtnq3Ye+8/d/eiad X9+3fsPYcEnloo/86U9dnT3PvbKhkMymsooPM9du3HTjL341NDi4duXLXmrqsAf86uyPfXJDYu3Q +nUXfOnSSE/XsrnbYUWUHnLF1d+Kl6OpJ1Z/5SvXzH7rLtstoLJtLktkdHiNXrvA8fVvXnXcyefE h9V2u+89qyd8wmlH//mpp1atf/HBe9Yos69n0Q6mQure226rqsxrT6/88IfOP+aEw2qmEqJlrztU qsbQRXld7clCOZ1P1yYOt52vZs3cNkN4XH3GX8PNIAnUT5uvG44nklxQxRVigwOblm2/+JEH7xte +9ItN95ww/d++OSTz89p6+Hmg2BYffDDH161SjnDbdlcNhAMLlq0aP78+T6/j4mYGZdfoTNIPkZR p5ZA02IprdqMCvRSoCWgUu0wdp2rp2hYSiKCNrQU9AL8BE5g2wc9lN0RDqr+jb19w/HRaPp7X77h 0ouvuuCTH9x5Ll/EB5S346xLPt77wKOBVteeO89lkS4XUtn0aFxteunlv61du/buu+/+yU9+guEG isaRKdAVOQqC0XwC4gCIOEE8UjAZ9vK2vqjadABRCxOQR/x/JvkPFMWjRiT9+ozGObl/JY8UY6MJ jukjHk4JjIwOIsONG3u54Y5T/vFEdNGS+dde++3rr7pix13nb3/AIe9735mXXn5BpZqwmfxnnvGJ Hbef964jjj/s0EMPPOht6Xxu5z12W7bLzqe87+Sdtt8hkcFiVJb7dlgyS6ViW0u4U0WyyfiyHXbf feedjjn6vTvtfNi3vvVlq810zLHvjsaHMECNpc1VG0YqWEotmHyulv7e/rlzwplEZnh4bNmOO7H1 dtyJJ/z8Fz//1Ec+vOOyJUv23Ofyyy/npyR1+fZ3vnPbbbdSi5q9Kx2HLHLRmAp1vPDiSzsu2+7w t+8VCQffduDhqVxheCzGTXNgnHavvzg67MJCUpGdK9WydNmfH3zolp/fsNf2B3R1tB/87gPXDa8s lZ0nHntKyO4+/tjj33fSqXvts3PAGa44Au7sGvLm1pzSU8972uYki+UalipmH7zv2e06Wmb3hLxY grSqRIEP9C3p0czGNeu4aSWrKrmNqxYs6CyUsLJf2xErVJ3sdPXHCz1Ldjj+0OUnvv3w5csP//in LpsXzO/cM3ukkAhEusaGRmpX1iln1t0ecUVH0irodK1at6Y96LVUc6OF5L4XXv6tb1xy2SVfdIRm L9v1LV/84sWZqHrgvie7dt2JvdtPfvrqG357I1ZaVSUZDvtLJsupZ32Mm2S+8OXrf/nLX+65uGaG 8+ILz7/5t79Z1j1rdKxyxDGHnv6ed9x/x51HnXzWz39x9SXnnNzTuWBh+6JoLMk9AC9vWH3MkUce /a7Dvf6Fs3aes2Hdq8pcjo1Fucx644Z+e0v7t6/+2o+uvGzR3AXPr3jplJNP/MRJxz7//LNc5uIP hlb9/Zk9uhYcuPyQddGxW+78Y63xNmxYsGDO83/49RJHeK/9Dn755d5bf39DrR/nKg5zsDXi0GsX NZJ/4bkXRsfijtoOYuSOO+88+tB3Hbz3ngfuu8dBh76zL5rbd58j7vrdzeeefoLdtGDJ7rt+5Mzz r772q2UMjfq6MykTeimsx8bGSt2zQzbXuGKwkOUGyZZIaJQs0TUabkZJQJshpdTyqNVAeyvzJ3Tu d0gkktjB4zNVbnZnBnBaqtvN7vR3bWcpmQeHN4V83h9e8+tYNv35a85Zl0jazD6uDfjSlZ9t6bB+ 7arP2B2sA9yXNK7R1LIxAjNZAv84dDy5CtJptC6lBeCUMD6AQwvLB2VQcKL9kLDQhUJYe7VixQrM ZE/Od2oKazw54r/wwgvLly+X5X/qKHzB98gjjxx44IHAKcAKpRpHBrX5Vgov5eQo1cMPP/yOd7wD NhyaIVACDHpZFDAwaN7gVD213Ifu3mfXI1/atCBpWc+xiWUL3nL1Vd858Kjd1yc2zfF3peODnlK/ ef7JX/jYOz994VUxl2qxrC692te15MThjn41oObNm4cFgZtvvhkUxe4eajPKiaCkYPhSQSm2SICC QYQioEcKCadIWIrNKxxEqaYWRdKp54Eib/HJl5TlUcuXQMQ+1G+dn46lF3vSxXT2NXN32W7pqm7I pXra/Y8n8jtuMnUEvSu6EwNF0x4r26yVsZWRoVAw0jHQkhkZHNrbvmjTqleHgkPbFR297Xu6Oszl lx/ZLuQYcyxd3Vtu41hyR9LtyvSltudTu+3cj7SMupV996db8rvlV8ey2K7Egnzcmqg4LQtXx/LO xfnu3tzLrrCjxdoZW+NKO9dlOyPzTI78Gns2v7a0XdHpWGQbVbnBtUlHxdviyg50eFtG/BHQ0WJP rJBKxCM9bM84+p6temZRWWSO6KgmCJKutddee1WdZm6dK/SO2WeFU8WheDbnKUSCIc/4IexyIWMp sHVVyAbtfSrrSLjYyFLW+N+y0R7X3PbnR/6yk30XVXYWQ+xblYfimEeymKPr3G1zXyqrYKncZX81 n95+zJ7ptHMBnB3DkyOO2swaUSOq5Cin7JagK1pUfIRfUim2x9CAsDGc5bSUFdXViMqZis4IR686 86uVl/Noy9z8xlXPqNi8dYEglivmYnEylUsGWlyOGNZIVaxNBdGGvubLz8agJeiM23GCZSs31Q37 uXzF1MYmoasvPtaTcA04XTHT4JKWdlUtvmyyBVWiM+nujaZn9WCxf+SuT/y/T7fufvG7LjnJncrM 42x3Ze5wVbXa16q0V420vtC+aZnq6nMODqQTu6uFyDNnT2AyxDJiL7dUS32WUHdRldarwoIVG0cX Lk7YMz1xtyVQHcNS02jag3T5zrIY7U2E5lSK+VZLAsudfYVAu71oH3pu/s5vu/xPG/ff3jc3Gy95 givdTvbiAom1u3Zvd/Yz69+3oNOz0sZwHHOw/W7qyiaUaeOQcwfUwI3bhda29qVK3WgHq/mXTI5O lQql3fFCasTpnM9voHR1ky/fhbhjow9bLAeiLs3UhK/MvQU1q6Z7GlIjbapFFUfW2lrYn12k6Anx QfP27WwTplYpb005ZrhtUwLMisyNlI3D408//TSm/rR5j9lA5lUYZF6FIg5+mTzxLQ43xvYw9/vg vX9aOHfWrPZIfHTooQf/fNrFtz79/POt3a9tfO6VYw783OMv//qah376yIr9fn/x27kF1O/3DQxg Fa+D25q4OJyp3YJGeiY7JIM0NB+9wOLFi6mQfIouP8hZT7Vf5rU1adxNpmiy5b0WFtnII2EC26y0 agcGmtVJA8saSR2lhcSXKtMw8GhhXhEWikaXt5N9zhtyXoVf+xz8cLXN+cvatSrTXcKuDd2IDTr+ 5KLtfpZK5Q6081yJrVB5NgIVZ9TLKmad3TEU3/Sqf0N7zM8G1muvvYY9SXb3ODVFLwRRUTbKQzHE pwDSn+QROk5KJfOCXiejy8IpiEoSIQWYEYskKIkQlgQlHe2VlksiEauGucbEWUmP2DCOZHeVHeZS ohAIgCJMbPBgNBvVlLmAUaMqFrrDYW+HZXY0ni2UMjUIkjd1dc11Rsz+JIavzQNjareFC4pD64jo cnl9Zi4zjA+PjLJLiqqIq4JrV7sUldfmyIyymehxOsDBeZurUkqpQMiR5Mxm2enzW/tjY3O5CThn b281retNL+7EDGYpHHH0JrgGJOmq5FyuQNXjqmYrNaMXNkqo0tGo3WHDHDnyczidNX1NI4eZd/SN 9q4wV9a5PKgeaDePGlUjrtEWd5jbfTfl1BynSxU5q+OiwVldrSgeXe3DBbV9y1LFaaay4kxXJGVq C3gSWeUNtnCJyiyL4gt/Va3dStzJ5UPVuMM2n/xJwcrZbA5MlVosiIN9Yhu2KAfDym2y+Wpvxg2p 1wyGpoeVZ340r8KoL13tKr2h7FTDFrAUYMyM/fPamR8scHN0y4QIKzWz4hwJYvvPCiCrHTcaKY3O toYwmMkNyFWwGx2WO1tUNkBdK3xtmXGjckHvZmspqdFypdNrbfMBpDC7EHE9+8wLS2r42ucAACAA SURBVHvG6HktXreFw14cghrXAnHASM1SnZZO6hxyBkKe9pr1yiK3MbJeFN1BJ9a3gHmqnOb6YSqx w+JIojRod3MBEyeN0ijkIkFPTYypMZuvZswdk6rsW2IFtN1r4zcN2+iJBJcNmzq8QFy7lc8GxgeZ SsbTnGAvJzeq/BLfQqSUq3394VNcLp6z04T8a9wuRW/JXHRZFR9UtEa6QNGIzWyqhPz+bKlmHspn ai1zqXRlLBjprJnfZMPUX42qaKQjTB1H/P0uzstBTyVsoZbaUfNyDOsOINNNSnV52yAYbmZJgLlO m+4kLJMhtZBHqY4QuQZgfMFnoipxH0B0dORXP//Zt6++8e9/S7itDi4GPe6Y4z/58R+MpeIZVVkz NJCIF71+y2i0NxA2FUqD2Ot1OVpLRWu5anymMLO6iW5p/wUmJrBIr9L6kBaATcL4skLLI2szj+I0 5ROPQhcKYe3Vf1ovxbEYDnFTWo5Ff+tb39pn3Mm3aRNqKo9oI1BffeYznyGWKKXkCrCGzFuEiDQo D+XErVmzBpOSaMKQGCieV9ownpAX0tYoejwawzYYoMzSYf7RV/6pNpOdzf9cgUGQJC5Z1wcEWdIE 6AI5uEZvoSccdNBB0y0J1WkYRa+N9Oha2aShYRNX3+4NM5pAJNYEytSPeumTDr0UvR3RRTjA/V12 Gb+bpVGK081XS6O+aSAiT8lUfmDgP/HEEwsWLOjp6ZGmlOHJ7xCuEOAYCtdZaknVB0TfUE+RsCQy mf6Gyz8hKT15TmB7w4965ZxuvtNNR4//DVdkQsTpll/GnZQKXwKkqZeOMPBWAvzC+stf/rL99ttr U24tiX+ediAd+gnM5CIJ8kpmjLGqL2ArB82Ze35/02677nbBZVeOlZzf+MH1fmvSUlFDvZtOPeGk 2T09fYP9r65bw1HCS7/5tZNPPCng9qTG4m3+kLlUzqdAWdV87dPdGexEkppv6KVmcFvqFV0gETMp Jp4PO+ywe+655/rrr+d8tx4/r4488kiBXzKJs7LqMW9FuozzrViAN5m1Vn6ZlUiNcYh7k8m+4ejg ZikS0yUTK7iBAFa2p9v66P+mVQa9KlMYccJAWJLVApuZix6G0CvnFOmTFG+B+AwlrloihSmY9Yr3 uuUhTS3ZWocYd1CkwAC43XffnfsraS+GJ3Qo5MU3sBRJ7rVsmLVefRsyQyTbhq9kzW74qiFxuvk2 TOQNEDUZbmbc122XCeno8U9g0x71MKvGMCEw3fILspmQyBSPDHCpgvQiHuvPcmi5S2DCI8lqFC5j zKRTufRwe2fX727/wz333nf1z28u5XOj8VGP3dnR0fHAgw/WmG2W637x81fWrDrphBNAZOlUOhwK lQql5Fh0YGPf0089ddQH3jdFaY1XM0gCMxsUTyFo0S0JAzopfklzfwsTpd5cwBZbZ2cnb/m9y9SM okJTUE2Ri/FquhJgfsHREPisTxLWW8Cmm/gb4CdrHPMpJaHPkALtTh/AdOq0UtNba/Xo5NgwfZnZ pVQwUCpx4LyG/HpEvTVMr//rlRNpsOPMr3awFLpDIAJhBKXHL79DJpdKL192jaks/FqV5VFALXUn OyhkTcqbNm0ScyEUhgJAR5tIkaDDPzlTSbYhXY+fBBvy69W3ITNEPX7q2zAK5zUb0vX49eSpVy89 fr320iu/Xr9qWHiItGDDV3p02rchv0Dnya+knJIavhaQsTyZn/FV2+0fd8QVcTHbi15ciz4hIH1S UqvlAcSvVtrbWgdWD61eu8HqcEXThdPef2oxhw2c/C03/XaPZTtzECIWjXb2zKJzt7a0zO6Y1du7 IZvLuTi1jkkVm/XZF56/9PLPG1hqchvNUErTYimZ9JlzWRdlDeCAIfoGMFPDpmJ4MGsztABSMMgS ojexNkzBIG6OBJCzxsa8LJNU/VSlvf3vBJhbaXcamsVGAtzoR7eZ4hO/hgXTm7v1qjYFP1GY5SUi 4pLVS7plw6wbEtkUa0jXq5fe2slaTgFk1cEnjKNUems8m24N80WkDemSL5WV+moB1k6aRhAA6yuZ QsFiCB+6sg4KosKXlgL46qWvtwbrYQ49up58GlYKop589DCTnh5Uj18vX71+Qt9uGGW62EWvXzVM HGL9eK/n0aMLpqnnlLBeOaVdSA1H59ECk1MQCu1CE+OzQNC76Evc9YnwIRIXHklBAloi8qqeaDNV hgcHwq1tVqfn8Lcuf3L/g01Of6Rjdj4/5sNyRqHkYgnxeDLZ7NHveY8vHBwZGuTKb5cvYDdb04kE yrEjj37P0cce07hVtIyNwMyRQOMJbuaUX7ekDBWOd7ArIZOUTJHsCGijYkJMGPjij5kauoxJpvIJ PMbjFpSANnOJtPG3YOKbnxSLtGQtyzZzK7u9hPXmbr2U9cqv19/oig2TYm0gKfFhILpgl4bMUxD1 MJPemqqXFD/ZKQOjCZ9SMUwojx5QIBE97EIKDbOQtZAq42DQfH72RCIRVAhEpFFoEUpOGeSqJegU Azr8vIKuJ09p1oZZNyTqyU3K2TBKQ6IeBtLDCnrtosdPlRvmO13idOurxz/dfGm+hlGmKzfaRUSh +VNLhu4kPYqeI/ibX9fSwSjPhER4lA6pFRWKOBtfddi5f9tmd/uiyazL45szf2EmD0aq3cntcnmi wyNYimEwc2oqWyxw5QLq3Ggy7bQ7Aj6fw+7I53JOjyeVn56+WSuJEdjWJNC0WApBA6Tw+aHMPMto EdHrzVkwAKR4K6sFigo0B4Zeaov318lrEnMTuUyYs7Z4vnoJUh5anLbGMbey9AIUCEup9GJNpuv1 K701Q2/PjnwRhThykYkbfwr4MrkwUPTWJL0urVdfxgVJIRYWdZxUE0FNbkcphh4GRcgNyyn15ZVW ZQI8Uk7WJLLmkQDR4WREg6UQqayI4Dayo2ww68lTr76k0LA8enLTq2/DRCDqtbueHPTKo8evl/6W qq9ef9OTj54cpDUnv9Wrrx6dITk5ESjSLtJ78ScEJkdBnnSY2mgft3pDmBzp1ZPjSlKSQn0thLOY TgaCAX5pDI3FFyypqZyGBvsZr95IwGaxYuvObXO4XM5MPMZXVu3dXRYMzdnsfo8vEY9zAas/ELA6 7MlsZvyyjMnFNCgzTwLNjKWkNeQHK0OI2ZZhoPe7SiAXY4YFQyLWj5+Z17Dbaom1Nal+qtrqhZW2 ljWbiVXm1mmVSqvXhFh6dL09KWZ2CiOOpGTixmfqn5Dy1I/aj4cJbFRtAkUe9cpJOuROeRhB8BDA J6zXfHr1apgpRDABaRLQqiyPtAVF5S0ZEaD6ZAqR4amJggBYivKQqV6+evWVXCaXiiwmE6Hoyach M0StkBMY9NKfLv+EZLVHvXT06qvXT/TS0ePXCjAhoCc3vfbSy1dPbpK+9EZ8LTChGNojPYouRC1k wgcaMuJIROvSExIRuUmyJKIFPC47Z8/b2jp8wfBYPNXt8dksJuA/99IPDg5FQty5FRgcHOCmrAXz 5+crmFjJJ6L/2CchU/b+Klw/FQzms43PyWkFNgIzRQLNjKWYRmXE8uuBAaN3IkGaSiCXzBSMZ4Yu YfnVMlPackaUc/Kcrk1PW6X89BAaWvoJkyxTKo3O3DrdUun9jtdbS8ilYX2Rj+bqGaRn1lOmDpNI Q4ap16TJUZj3icLwocCkSUBS0Cu/3lqoV36Rj5RWKk4ZCJALOAmfRtF4JHd+FElAykPbwaaXr5R2 cr302kWv3fXok1MWil5/0MN20+XXK79effXKKZKf/FavvfT4J6cgFD256dH1yq8nN+RAUpRKEpQA vp58KBVZ0HvpXZxootsQEWaZAbRSSQBfAvW1FmI+l/WHwiNjmJm1YJEfpG/HrBSXrmODD92gw7Fm 9er2jo6SqgLakvlsxO7hDlYsmMXica/PGwyHR6NjWQ4C6gnOoM80CTQzltLagnH44osvgqiYIPTm XM5sLlmyhBlN7NYQV9YPLZEJgZLillZMX3N/BgdNMcOZcAQwLJIcSPq6fOPXgWRKNrc1nhoJeP0F TFVWfJVqwWGpFvIpuyNSzCubw1q0ZM05s6xSsqhzZotxS9YyhidkymO9bl+mDCYCiYKP06LImIci AYkozBDr09GiENCbg/T4oddyHXdaOuSol87kehFVi/jfDwgmwGeG5YAdHYDFmz6gV369Eur1Kz1+ PbomDU1QItvplkcvfamv3tvJdLolWWu5M5Rwk9k0il4/2cx8pdb45MIooO4MWy3x8cxryioomsDh YV3UeCYENLYJ9G3tcWqpTi6tnpynm87klP87FH60bJGM6uUgY0d8vcTpz/Qohjmn8RjmdEt+RePj iKKXAh0SJ2nCg7O5vKl07XtATC+Xcmmn1VsslR0uT+17YKspnct6W8NpTOZicNZsCbswistNobVe 6nBymWkxHo1aa8Z1t+bUJ9Ux/C0lgSbHUvyqZrANDw93d3ezu8cPEfn9MVl869evhw2Lf3J4lsWj fpRO5rdi9BmH/PI5bC07Av7hkfUmu6nLXwNS2VzR5a6d0Ap4I/FCwmP3MRA5RIt1ZIAUdKw6F8tV s6qd/KBILOSUbd26ddttt93IyIh8VwLbZMcwHh/X/zgUOT6ua57MBfDLmBe69ggRiqQmr7THCVm8 AfrkKJMpE3LZdh5ZhmkCUX7Q6HQY4CzigrLtFNIoiSEBQwJbRALMk8y3TFD8cCIMkGIGAHDrnTPb IpkaifwvSKCZsRRjhtHCsOGboJ133lm01tov7Amty9dbL7/8Mt/HsrLyShDJBJ4Gj4UUN8Yqi/Pi 88/99jU/z+WLymm6+ZZbjzviaM435nIFj99rtQRI0cS1KBxspzRVbPPwk0RZuGS8ilKqwE/JNWvW 7LDDDth0JszYJne935cgPN6KIy2qozleSeEpJ6+oO6+oNcxajSQKfoO6jJP0XpFUwyjwS/qShV70 hnG3BSIQFkEhbXaOECCAGyyLWQT6zLZQPKMMhgQMCWxBCchkJUsDsyWOPTgsC+JvwVyMpP4HJdDM WIrmZKgwbFgm5bcIylW9/Xj0EOgkNCig4YMp+kQ6rjx+LjSL/u2Jx6/9/k8eefjvOy7b7bXBV0Je X6ma4846LOSkUqUCyiuPsib7Hf5OQFUsVuQj3PFkq9nR3PjVc2Xug2QJ5zMl8kUpxW8mPa0YmIZX OCkhBRYHGqCyEHlF4rABEXBChKLx84ooU9Sr4Su9KCSrOclFytMwkW2QiJ4fiQGh5IcpBl2xj0+N DL3UNthYRpEMCbxJCfDbkiEvywEDX45Mvf/97yfwJlM2ov+PS6CZsRSLOuBJfoLQzChyAVLgqoZN DhtvGV2AEsLwgDlYUxsyQ2Qr3FMzueDK1c5zmNwevuK2O5xq+7lLcsAn8q5kv/uda8+/8DI24g88 5LiH7rj8T7f8/g93PTNrQc+ll3+4b+OLHW2LfvK96z7xpQtYtq+44opzzz0XXQgFAEgxsKc4T0Da GnwhINhFSquVmYDmpBbi18r1hrCUnhygU2acpD8F27b5imMTdAxxKPxRTC5btoydVr3vPbfNWhil MiRgSGBzJMAEyC9Mfq/y24mDU0y5zz33HIdlpzhytznJGjyGBJoZS7G6o5WhjTlpyBBitDB+BCdN bniwC2xEEfgFA1Ek+mRmKIWycnFa0VJxBpYuWcS19c6ddln2tau+e8bZ50ZcfBlb+epXvnDVVd/4 /g+uefcxpz6/Yo2yO0b6h+74/QMd23U8+MiDfPH9hU99/NqrfvPM88/cfPPNl1566dve9ja2lkiZ 8zpgKXJvmC90gAuvxKfA4gTN8BaoxFsC0CHySACK+MKA3zBxjW3yW70oQteykEd8oUxOZ1ujIG3Z /KVj0EPAtbTCrrvuqrfHuq2V3yiPIQFDApsvAaYmZkUmeRAVEz67e8wABAwstfkyNDgbSqCZsRQV RtXE4MEHUsjX3XprpLb2wyySErDSUGoQOZpcKZXNeVMxnfW1bb9uTf9HPnH2hRd97OLLvv/MUw8v W9JyzTXXvPe9x/y/D30gU1JvecsClXi4u6OzLzq2+vGHLfaiVQ3+4vqffv7Cr5Pv4Ycf/r3vfU8u t+F3EoAPLTTDWy9r6MTSikeAOmqwT7CU8ECcLpbSkp2Qu5bsBLrAJi13CqbHOSHiNvIoUyq1QOCc maDw9BD8qeW/jRTeKIYhAUMC05KAzPP1oxsK5yvkB9W0kjKYDQnUS6BpsRS/PGR4cIcXOzisjqz3 ONbO+vprYTCELKLwsLLyM6V+vGlsWqCgYnYrx6A42h1QZf56fvyjH5125nv33+/yj55z/q2/+b7b 5X7Xu4+oYDVBVGGWSjwa23/nt5WKymyvxlP9Novlsq9dNvS1UUmTw1LyCwnVyOteesX4FydQhrAU m0ccCUKhRviCbIQIfXJAq5EENIbNpxNFL9aERLbBR+kkopECxSJGfISG6LbB0hpFMiRgSODNS4Dd PXT/TPgEWBGYewm8+WSNFP6XJdC0psIEQzBaOPiCmQMewSgsmaidGjqwF4uoYAJ8wlNrfe0qmEhk a/x29vsKys5xcu8uSw757Q/PWvXEy4X0BpOz/+mnxwpVa1ltqC3LHn/eZhorZEaxLKXsFY8jXslf +73ruBNjcHDw7rvvluxYyylzDX7pOBhY5skXNsqMj2M6EJ9q8gpHQIhUlpREdwVFiPjwUCjoJAie oL5gR0QEpaEbT/VfO4OUQZxWHnLEwQadFKY7qOzFkNflK5nieYWFLRSJwZDV7y2kLTb7WNGesIeq rpC1mPKW41aTSpq8Zpu7UKqmkym/22VVVSwO52mGsjmnyhWbpVAtlyrl2i0k3MheUS6T1eN1J5Nx lH92BxdmWQvFPDfHIBjKKUAK/CpVgEIVplt+g9+QgCGBGSEBhrkcomDuYsbDNz7imxENt40Xctpr 3jZeH614ghUYNiAJAQqMH0CDYILJPss/KygggxQkLBoLLcEJAYYfBxiJQhZPPfUUZ544M86w/ON9 /9ezYB4XMB31nqO+fOWVd/7+D+VK/qGHVrFA9w/0Y72oLaxSqugyeU477YxzPnbOM888g+Zs1apV ZEfupEaAA/KkPIWrL8wUbK/7inSER0tQL4oALO2tJsDJKWhJTSsAtKPuJmxHmGpH3DghWq2ZJk7n C0WP15PJFKJjo75ICAAEcgwFbclENBT0R1paklwaWsG4cBpg5Pe5Q16/zWT2ucFOHvSR6XzWGwpm CrmNG3tnzep58cUX0qm02WLNZXNARyDltAppMBsSMCRgSMCQgCGByRJo2j0+bYeOFRqMwrKKkgIE gD9ZClCgg41gIIwPaJBwQ2aIIDPSBAZ1dHT09fWdeOKJZAR93pKuP922wWKtfvZzn8uN/e6UE07K FTMuNXt07KZAKNjW7o3FlT9gwmb6py++pJpoOeigg+RH0tFHH41BUZJCU8V3ZPgNs54AfeARyhSq IBiEDR6taoIXJa7mC1vDfIGk0IlONUUy4ten0zDiZhJJlKNKQCmLGTUTCLVULGXS2bEPfeLSj154 6Y4776CS5tzY6I9+8ANP95Ll7/1Qi9ueTMSweKGQNXYirNVgwBuPRb1ObyVXKFnMuUIBEMYFomOp RNVhm9c2b3BgcPasHuBqPlfgIi3uaef+GK5028wSGmyGBAwJGBIwJGBIoKEEmlYvJbUFIQECUBex HQYFgDW+J9bAY78clICDTXzBCg2lJjwkDpAifNRRR8m+O9aJXn551dxFlrzK+R2hq75+WSoWr1Y3 ZgobLLbIGWf9vwce+FlHgF1Ba75s8oVmXfn1L61cufLVV1+95ZZbKOfatWtJkH0ozkJq+EYvIAXT 3oJpGroJDIhCcxq/8JCgxjw5QKzJ/IgITugav5RqatEJzwQfO11AXvRSFjNg11xhD7OcyeRG/3j7 nYNDIw62RcGBxewTjz26as3aisVcLqQ8bls2nysDEK3WQqk4PNTv99isJnM6kaTJuRaLG6/QTvFN JdqpTX2DKCgtVq7iqvq8gdGRqN3hzue2zEUWE+piPBoSMCRgSMCQwP+UBJpWLwW4AZ3gWKHZMhsY GOCAIYCADfKGDcyFfWwFYm2It7DhE7chpxB5S7KkJniCR06O84VtSRWIjXXOwcRL7d7ZymwtZzMW s7J7uzPJlNvnHY0XIgG71dJRLIAVCtg67+/v50QXcATb66OjoyQomiq93OGsfyVopp5SHxZmfME3 GsqBgoOz3ucRYFQfXQvDRlwtOnATTh4FYNXS+vdSaRE3N8D+KnqpWnLWKmbhTVxVlSuWYsrmtNrs 3Hpld1hdNjeS9AVCHr9yFMuFfBrka3W6UObNm9VezSZUKTuWLoRaI+lMJhAM2LIZdgAReygcrhZq 1i64r91hd/Vu3NTe0T5+QArotrkFNPgMCRgSMCRgSMCQQEMJTAUXGkaYKUTgiFZUgM6mTZtWr14N rhKdk/ZKC7S1tQFo6ncAAQpT4AOwGm+FR1AXWI3UOPZjKal4Ybjdv6MqqlKhbHW1ZUeVy+EtVeMw AKTwU6kMh8gDrUFUWTxSMHw2GTmG1drail5KrgWEOMGBNYSiwZoaitHHMbwSzgk8Ex61XPTo9dnV l4EwUcQnEY1NS3AzAwCzcqVckzj7n1USrFrMpaopo3LpTC4PBrKZqyqTKrIzVyim8yqiitf99IbP XPGN9Fjy3aeces03vuwzF0qF1Gnnfu6uP9zB8fKbfnnj4YceNtC3af3atVf88lf7Lz/sA6efeNGF l11w/vl77Ln3JZ/97CmnnBIO+ePJkc0socFmSMCQgCEBQwKGBBpKoGmxFOhE1Ess81x1x64eMIWF Wjb7JsuCE9/ALzlvTlwwgUSfzCmUeqxGsqQPoiKiVVUwkRBwt1XU6mJxvsNtiRcHA5Egn9z6/YCt UiGfsTv8Xi+WzSsj0X4QGHFJkxzRlLALiQuHwxzG0sta6IJayFoetcCEWLDxavJbjSLpTIg1+bEe gxJXE04t6X86SQofB21yIlNQgIhcVggUNSlAE1hKWe0o9UrK3+5wuhJxLpAeDZQyfp+XI1WcUX/q r4996Yufv+pbP3z7kcc/+MADFqvFXK3sv99ekb0OeXrVK3f9/g8fOOP0Jx96ZFHPvLtv/t3vfnHj L2/+wy0337Vg/nza9uyPnLPLLrtRxrGxRO2+acMZEjAkYEjAkIAhgTchgabFUrLYY5+TAAgJoCOf v4oOaWqJaUBhCjZ29OSaEbFlwP4gzLWIVSvnocBM7EE53CpZKDrsnmyVE9K1xMrVuH2ckzB4weV1 FVK1c/FEB1ENDw+z5YcP/puinCCVWlp1TsBMHaFBUAM3WgAmDfRoada/rU9lMoNw4ksAZgIaW33c zQlz9zPSGa9YDYSh7UKWmBpV7NXa7S4nsnSYMyab1ZLJZksV1dHWOhxT0XiMQ+tvPeggbu9Zs+K5 Fetzn7v0HUWLWn7oIZd88oIN69YvaO/ujrQBcB9/7ImFCxeiTQSqfvKT549b8DLxKR/NtDnFM3gM CRgSMCRgSMCQgJ4Emvy0CKBEu7EYdIITUyLAF5wmlHqli0acOuDzOcvVfDpTg0GYo4I5X8LaWz6R LKJa4RiPpboQeOSz25xqlhMDSONYymKKVErOml1t0JalkitZAR+wQQDwsbvHYg/mo5xQGjrwCpXC gdtwEtbQzOQyk744LTWUZzghavykIE5jmxCQ7LQcyVf4SQdOEqQWUhHS5JWW8mYGSpZCsYzGyW8q knY2pxIDqULWvh22TgOVsjk17PA5R6vWSrDNbS13lQqdS+Zf/fXPXnn+Zxa3dX716m8PFlIgLz4E uPyDP9t79qL9lu5kMs8yW9+ebX9hrPuxSM/Vs+dEytWk1V5wuiulSsIXAKaliuXarqvhDAkYEjAk YEjAkMCbkUCTYynOP6E9YmlnyQcHsNjLiSh8HDAL2eGzegu8YAeQE+Uwg2m4yGUKyQKkLFiAdNd0 UFz3ksuVHVZOaDk488Q9MBDBQ+SL1op0arqrf+mSajiD/+VffRYaviFQT38zYUE8k/03k+Z/Im4N ItYQWLVSBWeyRUhz2VHpKVVMjg363I6N69ZFOjpXrt04OBavWu1mq+2EE0966aWXvn3ttdddeeXj jz+eRmGl1G233oj0emNPJhMbFy1yWpVz7ep1+Xyc5h7XRaHnyhCmUQQO/ifqYqRpSMCQgCEBQwL/ UxJoWiwlW2+0JfAInASYIAy+YR3VjkzJ6Sg2fYBT55133vve977bb78dBphRDoGKpugKfHNW08eU qqVx9VaxACyrFItp4Bq3jkvEGhwYN1tFFoCEf6TGN2rjwAp8x8mgCQ4cQLL4k9GPUHg1LTfddCaU 57/2CHhC11bDUkiW3VKwktXtdoUW9rR99vyPbly3enbPnJ/dcONfnnnhgIMPy5bU+t7Bv/3t6WAg uHjBfFpibs+cru6enRa2n3ji4Tffek+lYF2/bmMsqgaHYu2ts1zuIhCq9pVlqYQ+8oc//CG25oFT COe/VkEjI0MChgQMCRgSaFYJNO15KVkmAUkAGhz4CeQETIECTqI5CQBxMFbOKfLf/OY3KDY4Bo55 J5h5CxSrASB9Z7N5ay/BoiUAkcnn9fAxns3s4GAUi7Qow1i5QW9wkZpFmQBytSis30AlonKIisPW 42BnAjyinFKMGv+/Ozj/nfA6T2hfGnKQRUP6ViPWrCtYK3zMV8XagjKbMBTldjmsf/ztDe8+6vCF y3b3so/qsH/oIx8/6ugj+oeLo9H0Mce9P1dR8xcsOfiYY0KB0Oyujrv+788nnfeFU0/6YL7Ya7JY 7/nD6tlL272OcDS2CjFv2LAB210I8Jvf/CbVPPPMMwnXb/VutbobGRsSMCRgSMCQwEyWQNNiKRRC rJRAGdzQ0NBdd93V29vL2SYwBF/JoZbg4BTgCcDEpt6NN97IiW8+kt9///3lXzxBUwAAIABJREFU UDl0OPWACC1eTOVtHkdto65SLGdLFo7h5Mtml51YKLQEuhEdFEWmFCaTy5r5rr8W4R/OXAFLmWpK mH86Ckx0Vn3x/0n+t7+CEf+NNOUDaU75flt5WUNQZgvX6CED9vvQTGFcwmZxLZrvevXVV9b3b8yZ qrmqae6CHWLRbFvYNaf1LatWr+wMtveORf3bdedLOUx6tjoD3//BF82Fhe5gzMwBrFSby255+0FH nLjmbUV77SAazcFOHzZRwbs0NH1jiibeVkRjlMOQgCEBQwKGBLZtCTQtlkLsrJosliyf991339Kl S0844QRWU0E5opQStHTZZZcBqrCbgNKivrHAWCy0osSqp0vYVtOTqEo6Y/a4MSSZHRtTVZvLZScK +Yp1KLImOrtLv/71r4858XhbtcJVu/K1m6qwwVdFL6U5QI/mpsBS0137SUrLoj5AXvWPWni6WE2L +CYDGNiyWM0UFpMSYCkAVZmj6BYH9s6HR4eCrZ02vzeWSidiY6ayqZQoD6qU3xPIpjJtoWAsmUyX 8jYuknH7zMW+9ojaNFwMtmW5zNgb4r/W0V7lbavQEOgmceiiEItAq+nK801W04huSMCQgCEBQwLN J4HGG0DNUU+v14t6CZ0QRs8XL17M2skiylIKnBIkwTr6t7/97YknnsDg+MUXX4zNcdmek+qDh/SA VI2Bc87jn+7jp0f6dt9t17lz5nHoBywyZ84c0vnud7+LloujWlwRc9ZZZ2Fyu8zeHtxopvjDv8q4 JaW6IzuCpVjmCRCxoROezfdJraHTS6FWq63hsMaJZSkUUiaFXooTUKpYUOUi1+05zA5vxeaOpdjQ UwGva3ar31VOOdz+UKTV7XIDSaMjw62hSHtHdyyRdThy0REV9LU67JVZ3YGhTXGbmYuOFS3S3t5O 66AmpKE50wa02lrAcWsI2MjTkIAhAUMChgT+UxJoZr0UmAnNEOslJ6JAReiiAE8ACxAVOImllMdr rrkG/RMX6mHYCZilaSl4W2+Ns4H4xzfruIHXrCyegK9ULP74Rz8+cP+Ds7Y0+QLj3vOe9+y5554c eyLZ2o4he1dAKW2Lb1wrpD1p6QNxCAvQ0YhvJkB9G0bXatrw7X+fCIAch5njHliqqsrcKKNUPJWt Wp3RRDrc2VrIpYq5TH//hja/byhbGIpmImZb1VwOBQIYmvIoRzAQyjuqmZKyWwFPo4Wkp6Otu1La YDYXgdSYmOc8HN0ABSRbugBoWhnA2rCyenJryGwQDQkYEpgREtjW5r0ZITSjkJsjgabFUsARQAwO qMQBc/AT+qEvf/nL7Pqdfvrpu+++O3Dnnnvu4WrhBQsWHHvssSyx4B5WXNHivA6QQrQ1e9nRoivk SHG250lbvt8dWOrs8VuV1wsGqD6z4sU7Hrr/0N32VSnr3bbU7lF/qKP4KmbPr/ra7Rde+j2frXDn n+5avHxfWzQqyEnylSWcBR74RQbyqt4XBijaWwlQU0lBXoEgmTVwBBrSORcPJ6/q+WFGAiT433cW e6Y4jmpMyl4sULsS1jmVKoAE+RYgZLNVE7FxE+U2Z7ATYxUhJOCwJFDuKZND2Rw1xFhKqpLK7mSN RFM10+nzHQGVKMAbVJaUzVzrDGy/Sn3B1mJpTL4PEOnRAQDfbPiuWbMGv6EQ9LBXQ2aIet8QbK10 Zko5t5TcZnp99cq/tfrPTG8X5nnGPqOeX7ysBawLqKv5TcVyoCdqg25IYHMk0LRYirkGJMHCyTLJ OAElYAnz7W9/+49//GM+icdno+fqq6/mnDimEFBUYBRKmyZgfl3ZpeLKHc7F47k2v1NxX1xJDQ4M rhwJ2UsFx8jsuTt6BocGf3vzzZ/5xt5sJ+VrX/KhaSnf+NUrP/OFm1ZuKt5/888OPnj5M8PZrtpX gw0cJcfxQgLiy6NGrA8IKtLY5BVEjUdSq6cTNhyNTnPTW5AVHYbewjeY7AMKljXkY0jAkEAzSYAx ztBmvIOlGPuMd3CVMdibqYm3Vl2aFkuxQDJaGDOME3b00E6xRi5fvvz+++/ns76vfvWroCi0FAeP O76Wh4efKTQDmGNzsJQ3rAaTw+2RTpVHR2VtaXGd8qFT1Fl9mEj44kW3XPKVxS6ni7RIMJlIzPb3 5HMF5bJ/9zs3/eja76Ms2mWXnbpnda5b39e13b/uYK7vBJrGSDCQ5mvwSIrakK69krfyKIlDEbc5 dZQoze0LgEaqOCRDH6BjyGzbsOLMvA3pekTpVJPfbq10JpdEKNtaObdUeWZ6ffXKv7X6z0xvF+Y9 qgCiEidwCkTFSqEnaoNuSGBzJNC0WIpBwtLIjMMaiZoBLS5+W1vbueeee+GFFz799NMgra6urmOO OYZv43nF0MInClLbLJxRVq2+1pqI2RNL5NLp7B233PGOY3epfd3HXTK5v5gxN2lF4aG4gG84MeT1 OpJ9I62t5jPO/og6+7NuC0d1cuXaZXC6WKqW+LiTUhGkYBLGnxz4B/c//wjDP5/+9Vfom1XHf0Vq 2hDtjkDoJBIgzC4nYZT/W6TOW2qO3lLp6FVqS6W/raVj1FckYLSLyIEBzqKAj2PUQ2QmlIBeVzHo hgQ2RwLN/B0fvz/4wcE44fATAcTB+Nl1110xjsBKyRA6+eSTlyxZgnaqu7ub5VOOCsGjjS7CekJM JzgV5ciglOKDPocjFlMd7R3D5cJwIV07Mu2sXVyTSqcxO4meo6CK8VjZ19IxOFi57pofVKujI6ND jOVFi+fppV9PJymKJ66ePjmscRKof6tHr+f53wxrTSw/uEWXiRaTbtPQTVdKDROBuLXS0ct3Wyvn lirPTK/vlpLDtpbOVmwX+YFNAZAJPvOqBPSKZNANCWyOBJpWLyWQSLbDOWzIkSkWSxkzn/zkJ198 8cXZs2fzqR2giu+5OJDIiKo/dg0nlCkk6PFz7DnvRg2VUNVswutTuXwuYrGbLXYOQHPmOJ1KhYIh s0mNjY21OVs9HgvHqs4684SLLrpo0b6HzQ2USyN9GXe30jGuroEhAhIWX/t9yaPgAAnga47seSWO sB59itr977xCSlJZFJnIlnmWPkN/0Pv4YLrTruwhTpbn1kpnckm06jd8tbXKuaXk1rBSELdU+v/p dPTKb7SLnmSErtcuTIaIDh8GAvjM8/yC0uaBqZM13hoS0JNA02IpqTBj5h+YoloFUfEIHfz0uc99 joWTL7nAWDCgh2BEsYhqI+r1p6oq6ifLaKwYCdpMVa40dpFITJUt+WybmU9CuCy5QuLAMbYON+Y2 1srjcJ1xwaeiwV0P2G2HsI+v/dN3Pb9qXndYijrBl6Li1zt4pIRSKV5pAcJUQXzYKD+vpBZ69Ak5 /i8/IihEJxKgG/ClwP+yNIy6GxJoYgnIz1FQlMylMos2cX2Nqv13JNC0WIoRwgIJjGDkgHIENsmP FfRPmNPkrWzrwIkSAluOMCN0GWDiT9UG1pqFboBUcUTZWtoee+F55VowhhJINhMzI2d88Lx3HbaY r/QWdi8ojD21Cf1TxaFa2j585pknf+yikClhdVQ3qoBKRRvmQqlwvMIXMCRhIUq4fi7QAJPUAgap vpbCBDpveWU4kQDS0IRJ9wBObSn5bGvp6LX4tlbOLVUeo75aD9cTxbToM71dGOaihWIiZWnAx6GN lrVgWqIwmA0J1EugabGUZmwTLdSzzz4rX/MxinD19dfCL7zwAgbQDzroIDiJgjIJdMVRJ41hcsCs OiHaWvCWqdp1yaqmYuJ6YwCQez/8tm483MEqpLr4a+Z92NeifDWinwHcXszm/rkHB85jPIN4CIir cf27YyJ43TGvYQISqY89gc6ciINYTyd3Hplc6iM2R1iqJpWt1XncUTWEQEPwjSfNDeYGZGPSk/Nz PDZHxY1aGBIwJKBJgFmRGR4fIMXAx1DOpk2bmOf11gUtohEwJDC1BJoWS6FqAhIxYDC6eNhhh2GW 8/rrr+dolJ44eHXkkUfKKRnUErBNDaT00pkp9PHfYzWNlxSYgFCaEkhRR7GAX19HgVNooQRTAqeY ZPv7+7noGi1mc7f+TOmlRjkNCWxZCbAiaJMev52Y6vl1yq322MTZshkZqf2vSaBpsRRASjtLvs8+ ++yyyy7oG1g+GUsN2xhznZ2dnbxFISGXtQka0xJpGGvmEmVCQSACnvCh4KDM3EpNUXKZQ6mgBhYl wHzKz1N8HlFGcsRt0aJFfJdgzK1TCNN4ZUhg5kqAiZ1fVqLg7+3tXb16dSQS4XOTmVsjo+TbggSa FkuhxWWNZMCAjTh1zuPChQsxbg5maih3llL40fQCpGCQ8cbi2pC5CYjUF2BBRdDK4Ndg1DjOaFYs VY+JtToKfgI2UXcmU/A3W8NwLlu2TDSUTdDQRhUMCRgS0CQg5zcY5ox31oJZs2YxGxhASpOPEXjD EmhmLMU1fGzwyWaNbIejdWD5bCgsGDDaGQ7XjjwxumCrX30bRmkCooao9MTSBHWUKrB/B2pEOwVi pn2liak17c5Myiu0/cyt+ABokDcMTVN3oyKGBAwJiARkX4JfSgxwtFMy6g3hGBJ48xJoWiyFaOR6 WvmCjzEjwmIpbSg1GABSoppCS8GCKr9gGjI3AVHUUVREQ1E1fNG8AII5VCpIfaWa4qPep4ewxydI CxQFhqYz0AeaoJWNKhgSMCRQLwFN3yyb+KKNxue3Vj2bETYkMF0JNDOWElmgiyKA+kHOxHDEuKGM BHKxvrIhKAyy1jZkbgIi0EFDUVp1qHKzYohYLAZOYs8XR0CQEwCLyxmpvugg6SEAaLoKvtYNNOEY AUMChgSaQAKooxjjsi4wB/KzGYW0sc3XBC27davQzFgKJRMLJ/Jld5zlc+ovs2RoifqKpVSUE6y1 RNy6LfQfyl1DioKo5FEj/ocy3YrJgqWYNPkxKliKktC4OCj0E5pbHukAoCh4mlgUW7EVjKwNCWxd CQh4YiqgGIxxpnp+ReNkpdi6ZTNyn9ESaFosxTjRhgc37t1555187o7ShbEkyyS+FqAJuef4kEMO EaMJrKxEYZXVjFQ1auNyiZGozG6TQ2El26GqpUzZ6q6opF35sqWCy1rIpL1Vi3I5e81qFiM3XjWV TSpcKKu8RfkSfYW/zsm9vWgtAtcomPis6AT4kSQQR/PrA/XF1ugoWsYr9K9TPrzCQZSAKJw0NkGN k+sFw2QiFD19leW1P3/kh4/mMVeaeMWcHT38Y1+cu8euflM+Y1OepKnTZU8m+7OBRNZSDdsWpPpU 2fOC392TTdgdVovDXkgl4pZKyOv0200Pjfr2He61L3GpknljX8twNhlYmJ0/XIwH/YG0+bFiJeYp HlEqK0d4fTkf8dl6s0NLkpURS/CVgHv/tRtS7paBcqllVq6vz+artM4ujI7NKRbtpUre1/pyrvLr k/e/bfiwW9fcFHGsKve35Zwuh314TmHOSDGBiBC7bP4KdOZRTz4NhWMQDQkYEpgpEmCKYzaTWZSt PQJ6k9tMqZFRzm1BAk2LpVgOBUuBh+64446lS5cef/zxqBwAFiJ3GUua/+qrr95///0YGoGBuLLF o22uN2iqQsFqd5VUoZTLWp0uNZYw+e0JlQoreyqhvH77WHZD2LOgWFEmZcYipys/EAh09qmislu5 wq/iLcxxb1/NKkAbqzhaE7435OwOWQ8PD/NNPgfnG2Q6ySw75RfAREThlwpCx0GRR+ERBnklbydn MV16Nhf75XXf3e89Zy7qDt1w0w3f+91DV996zyH7LPZ4q16zNzqczFqtbmd3vhwvJsc6feG4uzUV L3a2RAYHovlcor09PNSXKVf8qXykEjKHu1RxUNl84Xw87bDYLK6iyxXIFhQ7ry1+98ZXsBZmSY4N Oy3+eLGKVIMdAYe3Y2Sw1NnmtXtddhVUw2mfx7cpHmv1+23ptHJ7h3s3tc/pcc3psJf9pqoqjSZm exaszaStAWvVZhyKmtwFDIohAUMChgQMCUxPAk27lrApLpIAD3G7MPalCAiwmCAhQQ+LFy9++eWX 5RW4hF8qoqiYwPyvR6ujXC2AbWpAKp58y557hELhiNtnMjl/fsM9a/vWhV3dA/2KxdqknNWK+r8b fzR3x3dZlE1lB7h9xmxq2ZTrM9kVe4sUgFNc4CcUzoTRislRaMKaGkkC+JQNV08XCnEpMFE0xyNE OKfltOgTAnqJKHNaqdKHz/7Ql77+1ceeeKJ11qK7/nBXZzjcZTX5HOZAyFdBX5Rx5nOusN2moqsK WVs42NHbm8X2hD/ozeUT/oDVZCl4gztuGO5PVPoq1mFl8gSsi90meyn6dCyb8UdUKm1NFUrtbRa3 U7W3BGwVc6bsMXtUwZTrHYh6HNZKMV7M9feuGcgW3apsw8hBYmS4UDX1r3xt1pyOcm4kFrRlHKZs Ss1p6TbHi+6SqVQsDWcM4+b/6tFGyJCAIQFDAoYE3pgEmhZLyWcaaH3AJaAotmxAVKh8BBMI/qj3 gR189ydH1EEzSFPbImwsWXblMJugrPnsaDGNVin23e9cvX5o7Hd33/DRc49bseKFWH5TR+2OGTYA KYDa74Bl115zfe3slSOrWlR0dLTLuYhvCikem/ej444wxeZaA3RUetilHkgJ3IETIsip/pVG1EtH jz4BQmmPevz5QswUsDu9zuGx0dlLlno93pUvvZQaiX7q/ae1eOyWgOm4U05ftTFVLvoLY2OvPnDr zsv2cVk9PbM7H3ro8XQqmcslvvO9r4ZanB7fXmd85MPR3GsPPPr7U4764Ghv1VwyDw+8uHTZ4j8/ GPe4u0ZHMu88/LjHHrtfmS2/+cVts7fbpb2rNdDqX7t2pJBVFlPqwftu+8YXv/27ux5ri7R/7ytX dLeG/vbcC/u9450mq+PMDxz9/VtfNPndfq/a9NyKd+9z4G+v/0U2m/GEGxsba9ziBtWQgCEBQwKG BAwJNJJA02IpQAD1BUUBUEBFoBNUTcAU0BIO5IHTAoRhAEtJLCLyCh8A0Uho47SiyhVyZmVxuOw2 t61YzM+dO6/FG3rLW/beffdDHn304f+75+6LP/2TL15xjdc/a8N6tbHvxXv/79HaJ4LV0W987JzH HnnmnIs/4QmbzzvvvJGREcjYEQXwsbWHmSvNGBIFEMAnAQE0gm+kYBIWev3besp/NJzNJE0WUyKT Cbd3PnDffWtXvXrce97pd1Tmb7fsiQfue+rRh15+5bnf/uZ2m8WKUYKzzr7kqKOOefb5Vff83+Pb zZuvTNUNG9d961tX3Xrrbx955NEzzjjdH/A4nOY7H7rdbjdnUoWrv/vjbGZo9aurUtHKpo2jjz75 0N5v2e0bX//62ed/7nvf/ckLK1d84oL3H3zQkc8/E7U7i72bVl57/Y3/77yL7rzj9mMOPeD5p544 4OB3HnrMyWvXr3z7fruFI2CwWm/v6pm9/KCDli9f3tbWNjg4KGI0fEMChgQMCRgSMCTwhiXQtFgK aCInuNH6ADgIo20Cpgg0GYdSNUWOBPBBWpyswpeTUgKqeNSVrE057GKSpFTIJCpVrhy3gLxWr3n1 739//C1v2RcjRV/56kW33nrbo4/c09Wl1m184fbf3bNuTClLaWh09QnHn5ZJqztu/9VNN9301FNP tbe3810u5aGEbERSHj0AJOWBR3NCoahQKLaGqHiEqJeOHl3A2WRfjz8caq2M5T/+yQs9gfBxJx5/ 6BEHf/Qjp1qr0bMuvSIye3Zrh33hHK/XUs2kVLpiyXvV008/ZbWZdly2fSiETsiUSmUGR6oD/UNz Z5tOPfx4czHwln2Xt/jsf3rwt75w+22/X2EvF3783e90RdruvfuBdx/xrtHU2LXX/fKDH7zs5GOP aQmVv/SF89pb5j7y8HObhntnze8pqPCjf//7TssW7rvLgpee/avF6f/Yp6+wOwLnnHHGO3fryQ1F Uxmlgt6PXnKRpzWcy+XniuZQt42NF4YEDAkYEjAkYEjg9SWgjxVeP+42zcFxHNmqAwSwf4eeCTiF BohzVDgouPowbPBr6ijCIJupasiBaBRXtU/4CvaQD6NF559/gc/m23e/I48//oQDDtx/LDoWDi54 9un7FyxYVC4pFCdjI+nFNbPqw1WV+siZ5/3suz895J0HvPWtb+WcFmVDIwWYo9icoKJslEeAkcAa 7ZH4ApLASeJ4hMgHaBKAEydsEOVx8/3JKEorQMNEoqOcl1LHnXDq1T/40cOPPfL9H3zHpJLl3OBR H7isY/GSgw/ed82Lj4bsRatJudtnf//261euXrHj0jmHHfaOeAIjBc7ddtnjuh9+84NnnxOZY7/w s+dFe23WanD/5dvf/8Svnnjm2XJl2QN3/mhw7coVT732mxtvOfX0DxTN1eF0qXdMVdKFkDcXG1vz tv3f8cCDT0W6Wl5c/dry/T4QaHeaVNZUTa565YV5C3fwt5iCwVZrUfVUXYGq1eFWvfEh29yALRJA OObclE1MxQxnSMCQgCEBQwKGBF5PAk2LpUTVxAYfx7oxaI52CoAiJg+QCfigXjI8crKqu7sbNAOc 0tDJBLb6KMpOIiqnshysUpVSwO874vAj7nr4kRUv3veDH34r6GojHewsxOIq4mmv5WYudnXOXlc7 62wejQ6cdNKpG8fGOInOLiQf8QGhyBQLWOCVNWvWQBQEM9mXsuHXAykea8hgXIsmUWrZjNtZkDLX pzOZUv92umGvN6zcwQMOWH70se9duGhhpCVQLacuvfSTf3z0ub+//OrKdU8fsNd2mbE+7ubZFE91 bL/TSy89+9iTT/b2bTj7Ix8p5IuxWPLk930gM5q/65efue7r3xnaWKgUHMccf8jtf/zDu976to+d 9+1li2ZbSvnzP/6JDWsH9thrT4vTmatYFmy/l5PPLfPRoM/6l8f/umTxTqlcNtDS+tqaoYpVhSOe fGywsz3Su2lwXa8aGcmZrS5vumzOcD5flVy23niq5KgZnsgnUiINwzckYEjAkIAhAUMCb1gCTYul 5OwRG3ai7MHH4gBwirNTON7iUD6BsXCcTwK+gH4AW4CJzZEmm0WFquKLMIxmq7JpMJ/f77DD9t13 l0jLwaEgqppnWh2uoVi/w09iTqdjIK2WpotrZ9ce549VYq+NcIlyWBX75lQzLnt1TSaTDnYlC56A Ldjpd6cT6wQqTfa1sgno0R7BjijSgGJCJyA7mNSR+pIOdChCxJdqCt5CFCIExDU5R6FMyA70Jm7A M19lYi3FF5Om5JDd4rJFvaUNHrelZeiv5jH7nfeW/3Bf4qmXVrmrype0/vmnK2MDqaUL55jUaPes EEbmsznPPQ88lqkmF3echL2IYe/64Zb48sXv2HHAosqZlg/5XK7uw07tefDZu87+/Jdzrrzf5f3M B0698Zu7PP7iI5lCzy9/Nri275mjTjEVx1oc8QNsrt8Ecn3pvM3cvTwyf0+VWnH/jZ8dGX7u7Eu+ 9qn71zva18wqpdzZOTffeuOrTz5SSvjGAjXEKXVHkggNSIpDmJpgjYAhAUMCzSQBhrxUh2mQIc8j k6TMcm/AZ3aVOZYZkvWFlGWqnOA3kwCNujSUQNPal6Jbi6FzNvIYIayXBGowatwS+mRZQId/48aN 4AkQFcOMNRW4MJlTKAAuN0My0KpSAxUMQhaLQb8fOwwtXsZSioiY8mzvaClXVCan3J5wLgt+yQ9H VadptCXS2dYeqo07mwsGt9vDFXAuh6OSSWfSRYfT4vJ4CjXtWC332p9/BuoftYIJg/BoRC2g0YVN UhBfXml0iaLxaylIABnWU5gp5DEeyzhdpng0ZTXZCtnsxpHBuaGWMz700Rt+ccmO+yyat3jZxz99 /tVXX33SSe+/45c3XP6lS9ddvI6G2GGHHU4++WTkvGLFiqOOOorEA2X7saedtscuu5WyeU9X1xHv OMo71t8ZiaSTG4459rhf3v7nHZYu7WgJp6ODn/nsJZVM9NBDDwXxgI+//OUv77333rSamFcFGLNb mssVjjryKHZdr7zyK5///JVnnHHqgQcvj8WiJlXNZbM//MH3Dz744G984yo2exOjg0BJeguOgMyA TI5aBetrTZjJdwLFeDQkYEhgpkiAcc0Ux9zODE+A4cw08gYGNZMYsUhBEmTqIE29xQXh6M0nM0Vu RjlfVwJNi6VYDtnEobuzfcYeH7YGWG7p7noS4ZMuFmaMPMmRKeEkzCBpGAVkMRRLtQUcyttRHusF D61bu2aPnZbGSipobVOV6Ib1/R6vw2wBSCmVizvsQX9wMBRiR3DHXNa0YeOrB++9m0qpZDbHmfNE POawmpwepzVXZqBncyXb+Edngmzw6wMS1ko1/rK25adRJgS0uPDIyMcnLBHrfSIK84QUeJRpgoiI VOYF8XfZeZ9n/r5i4dKlG8ZSLaG2qt0ST/T3zN91zaZVfcMDJp/T6vOce86H+OhxJDr63EtPjVWS nFqbNWsWyJUAx8XY00Ta3qS5MNs3Wsypslm53F/56Y9THttQ0O01pw844KBnn3km0j2vv38g7Lbm C/kvXPG1cy7+DqUCNi1YsGDlypVz5szBFutpp50Wj4/OnjWHs3CxePyC8y/4xHmfSKZSdIZguBOw ZbNa0sXC/ffeE2mJDA8O0kMC3tqNMcynCERAFfvCzLNEmSwEKFN0oYb8BtGQgCGBbUcCTF8yVcqE xjAngA82mlYh2cfg1xezJWsEMwZTBz/X9SZPUpZMp5WFwTyzJNC0WEr6N+OEvv7SSy91dnbyoRxE EFXDFuIL+Yceemj77bcXw1TwsKDqASnekooryK3JFVVI2sKdK9f3QUTTFKxJlKtlQhd85ptnXsD+ HxzK7Ay+59Rzjzg1zOkqlU3+4pZ7YtaO3pSaZQne+Ls7OEj90vCIKuVLuZzVbPIFw6W8KT9+kkcG J74WIAHtUQtD0RurEhFOGDQMREAwgSSlJagF4J/gJLqkwHzEW8K4bKabSmcCAAAgAElEQVQaDraN RXOmokqOpbnHzmb2JbLMMiMWe8UfdGVKOYvKB4IeF4aeLNawOYw6ClgjSJeLfTo6OjD9FeppH62m A1ZXyOkqDMUtpio6OpffVla2UsXENTKYqcBKWDgQjA+lM+NaMdKhsYBTPT09MicyIYYjrYODQ35/ wOupHT4DWoWCYbpBLpMqc7GPw9bV0VabBCvlzvZW+oOq1vb12ALGZ6tXQ9JUbYIE5FHq3vCVQTQk YEhgG5cAv5oAPRRSdh6YhXAMf735U686RGEqYNphzmTq0BzJ6kUx6M0tgabFUhpmYr3ctGnTY489 tueee/KJHMt2wxZ98sknUZMw0ngrw4yhwghpyFxHNCu7Lx0b8QRbBoZGwq0tKZPygqASJuUvO+0W Tk4F4E7mlNVicqk8A80aVlZHsazCILGMP5dJx4rZgU19XZF2v8vuMVvYeBqOJoOOAKOUqBq+kUeh 1BWgxjDFRKAlIuBAgwgTktUS10sKBuJq0RGOoCufz58rllLxROestkKpmk0XqxZ3oYxWrdTe1bZm wzpfKNjV2hodGbHanPHYqDfUgikvWgchoy+kdbBeAcxNp8bKZrRaruHRkTa3v2orl1NZ7H2NxrNB 4NHASEu7y242DQ0OBTz+Yr52+g0URYOCfjB0CorCrgRpplH05aBFCc+Z04NGH/vmyUzG4bB2tLWN DA9Fs1nyHR7sJ2uiFIolWpnoACnqCOoCn4GhNYHUi5rwZnSJCTGMR0MChgS2FQlo41cLTDHYpyg0 UwwTIHGZNwBnkhrTI+iqYSxZWRq+MojNIYGmxVKsjnRfujh7SVxafO+99z788MMsk+gkGrYcy/nR Rx+NuU7eEhGswDhhwOA35M/m8i5n7fdNJp1y+0IEOtpa8GsCLVWUNaKKjLSaXipfLjk8PmVWSb4h s1hV3qlMFru1klFFa6xcrJoxIgn0cHKTSom7ayycaPcEw+Z8bV+fxPC1AI+a02CNxqC9qg/wVjgl Ee3VhMfXpddnp+EtiEPDA7PnzFWpZGx0lAv02Eotlqz5vMnNefvBIZ/HrwqV0cERrG0hU08gBJZl 9gFLyRWE7MAyExFuD/uK6bzb6rZ67EkaoJhvbWuJbupv755bLJU72zooocPlsvv9Y2Ok5iQKXPg0 GW2NWpHCEAiGIm63F3TJD8cid/ZlaiCJrwsLmVgiOmJWlZZwsFIuoaDiX3R0xO0LgLpwRAddid4e K1+aelKTjAToGBMoxqMhAUMCM0UCzHv8XmKY4zPqmTGY4eWX4bSqwLTD/MOkgYqdH3UkxZzGxKg3 P2hz5rRyMZhnkASaFkuxQuMAQ/T4PfbYY968eay7KDAELU1uIUwnYMKARZQfFkRkWWWM4SZzCkWA FGFsFpnGzzbV6NUKBxrN1nFtVkWVVcWhTGbwE+tvXsVKA92eLmWz8MGa2Zr3K6fdGbaYs66i1eNm ZTdXcwAoc7ZcsvpcZk4OjQMp8QX64DN6axn98zCjBon0xir88GhsEhdfo2gJaq8aBurnCOJqv+p6 5nSPjg1EWsLskPX2bqyYiv5QJK8qiXTeH2ixmi0Opy02GmfyinS0DI9GOZGGbIeGhkBRtA5JcfIA NftYKupz+NOj8YrLYwt4iukKd7y0BQIvvLJq/nbzUsmU1+PmrNYY5ulDEY6WW01F4C86LcrPtEjD 0b7s5MZjCWY38BNtl83kOAthNltTybTdUrFbLaVCPptOMesB9Tj35QhZy2Y7VYOZGjGxEia1VCqF 8ux15dCQwSAaEjAksM1KgHmSGYNFgR9LTDvMS4SZMdBwT6vMteklmwVF8fXM2rVrwVJMZawdBKaV zrbGfPrpp29rRZop5WlaLCUNQI8XrABUYleIozmsow3bRn5SsI4CpGCATX52kEJD/ipnmqwOcI3d ao4m0iG/J8v5Hrs1Yy0ElE/FlfKrksqnVTKs2moWPauqzRMqqZy96uawVaoSs5qD1YIzayqmc+l8 LlcuFkzVislqKWZzfNzHPjz5CuLB1wIQJ6MfeduwnBpR49ECkpQ8amnWv9XiCqc8agwSyObTfFCc zSRKqbGWiD+ZL27o29DRPbtqcqRSWavJPDqIIsrhdvv7+oYdbpfYo6c5gDtMRsw+4KqaZa/CqLmk HBZbtmLqH462tvoLIynqH2lpBwz5fF6wEo0SDoUz+WK+WC4XsjQZFBRdtBpTIZMjU5vV4gZRJRJJ tkpRSfLVczQaY1OvlE1WzCaX08lkl0mnsa1KrCKXSdtq5kxJCixFjUhQVGVaNeuFQLgeU054ZTwa EjAksI1LgHHNTzjGPlMQQ55Jg6mPvX7g1LRKzjzGpEHE3XbbjQ9f+EHIVMbsQcoN0zHmjYZiaSZi 44ZvmhryswNlAwut/GLQ27iR+jLMBFHho+dgsE0hB5PVhqlJtq7gAUiVCspmdymrOaBqUExFap6t 4vAUzfxnc9XYPPyHG99P7zR3gtVygVwxV3GVbIGqnQPrRadztJSzO+1m7joZP6olEEcDOsSmbLVE /gmzJAwDhcdnxEqYRwEHTBwajwTE19KRR/jr304Ok9pkIhT0OiaHnd9iJk6YF4CAlnavsxpPURJ7 rdJll58KV4vljNtNZ6sVBhRFIZEw8w4NhJzHlUC2EnjTVuKgVScRYwlldUYBtRbFlX/Ecng8aPeS 6dqZfJtZcU4BVIRj/oJCK+PTyuywptJRPp90WEz5QlJxfM1nLxRTZru7physScdsdtrY0itVqsrq QmREpHYICp8EwVJQYMSf7ETOk+kGxZCAIYFtXwKMa4E7GnhivHMe4HUnwAlV4yc3cwWzHD6vmE5l RuVxuklNSNl4nKESaHIsxeI6vr7WlkZWSuCL3u8G2g81CT8vCMA8NZCCJ5VOeD3BclFZaohBWWsI CZRTKRZrhqkYUThAg2i5GKuSco1189ybH5B6aGDz8p/I9ebLMzHFGfuMKLasbGesJIyCGxIwJGBI wJBATQJNi6VQVAiOQd/ALwbwTa22OgpY6Qsa3BHcMDXwAkhlszmXq3a98dhoLhyRe445b17TG5Gj bC9SDLLWUpaMNsfXwy56q7jwa7Fg4zcTjxplQqZ66Uxg0x63VDpagjM6oCeNGV0po/CGBAwJGBIw JPDGJNC0WEpWO04XAmVwICrADfBCNLGThcX+N8pe2SoSEAbamBpOsT8Flkols+FIbZuptklkNVcr //hsXuKimpqc1+ZQ9FZrqtAw+gRsJI/4eulM4G+YZj1RT2565amPa4QNCRgSMCRgSMCQQBNLoGmx FFt7wAUUUThON9911129vb2AJABQw+ZcuHAhNrg5S8jenEAuwV4NmYUYCNRu1/P6akAqkYj5/UHO 2HBSh3zBVbK3SAD3BvRS08U6WjkBT8TFCcrRw0B6GEtLZ0KABCdQjEdDAoYEDAkYEjAkYEgACTQt lqJunC4ESKFquu+++5YuXXrCCSfIOeWGDY8xT/AWX4SKEgsIAuoSPNSQHyLn2qsKHgtf7/v9LYOD AzarMxwJAlOIKHopABlOL4Up6Hr6Hj1MI3QBUpIsKegxw6CHsfSKNN3yTBer6eVr0A0JGBIwJGBI wJDANi4B3UvctvFyb07x+HyPLTZgzcDAwOLFiwFSekopUttnn302bNjAniBh0A/QAX3SFLlgB7Jm iMruK5WzblfwsssvwnJSpKWVQ+s33XQTEYFxmCmSFKZOqmEuFKChAx41dBMSER5SGD8E38BrmMgU xIaFgagXZUJ5jEdDAoYEDAkYEjAk0KwSaGa9FAgGpRQKErbYAFLgJJQxerCGT/TZ4AN7EYWtQDgx oDCFaspiNsUTsYCf+5JNT/z13i98/muvvfZKa8ustetemzdvniilxP6bJDjdDgRMaRhFT58EphFV kKimNIijl07DxKcg6qWjV54pkjJeGRIwJGBIwJCAIYFmkkAz66VQL4GigEfgAFREKGegiIoGCmgD H9ADYALugLQkDA8BaeMp9vgwpxTwB4upvFkFLOkyJhFyuaQnYJuz665eZ9CaH1Dq73d+7RqQjXO2 f9ZRX1PZ8rN/va070lGjhEx337MaG5NZ15rbPrX3PXe8cvE111ld68zxSrzoKnjznkKYMjR0GG6g qJRZews6rH+ELriHjHDjJ+8tIB7CVEpqjRAkiobAoCAEbDeIfPDr0ycL0pzCSSyiSGEkcfjJkXzJ XSvAtjZ4qDVlo9ERBapE9oXB0Ni7ErlN9uGhdhgFxfQrFSQMD3WsuNyJIsZI49ZqzFG2pkYKIHKL J1tOlyOWUj6ZSQcjKbM7Ul5vy63vd0ey+SGzyVYqeMole6mSMlmTlWrR5YhUzbYiFvOryuf3x2Mx s4k7Culr5WQ5VMxWveWiz2pPl5zmQCSdLZszsdGK11+JhVSSQMYecWQHI97qSNlDiwDlcTQKYYpN BenPfGfKNxXDI4Mej5vyY8KD2pdLKpUtYKDf5bCbKkVLtcQd2xYrFr/MFVU1lSuWbDGCga5k1uP1 Vv2uMVu5YnJh0T+fTwT95lIhxp0/JjPXB3nitkrE4vZkK0mHKeux+gsmb64KkQKQHT6FoQ8jcH7e QKkWc+VS0eZw/n/2vgPOjeL6fyWtdqVd7arfSdfv3M4VDNiYbgwYCATTOwlgQgk98AuEGjqETmgm gOklYJqT0AnFP2wwuGDj7rOv36l3aav+X3lgo1xxIP/8gjGaz33m3s6+aW9GM2/fvHkP/gMoC2O2 WHVVETmWKjImOkmZ8rrixIVUnd5UNGfMslfREqIL/gzwE9Ckgi44PDqMkJgZryVPW5mIatfsHsFG O4pZkWMUC6dZRK7gdSoFs7o5J3vzNq8u9jC6Ka5n7LRLKHi1FFWgYQs/llcT1iz8EGVEm0XLpx2M GTFDqTCLxoMqOc1L62pOKni9OdrhVdtNmbZ22uMVvZlEFmTElRPeKWiUhkN/+ItM4xcG2/y0CT4A 8AfKmhnQU4ek2syyuiTB1ZE5n4cjNyxSuCCDNqtmJmfmi5SJyYe9Xit+5mFd1HNJhlJ4lobVfnQQ 3i41i83q8LgwaPmMpJkk2kE7vZJu8roEq5zCZMbkxEBj+pEpjZ8kpqg3786alKJL4fNZNmPp1Zm4 gzbJUSyPGAuMCKY9pgp+nmRKFzlGZ2lYIpY11WqByReznMw4aVYrpq2iK5LDLRveXdS9dlNBlTWv F87CkTdTgA8Hd4FiObdXoWg4yEKZaAlijDWagU6hPajRhAmcTnloWUlH7W5vmuJlVbPmI0pRZ+0s PEeYdUXA4s2wCgwcKyarSZctXG+B1RjBxVKCEuVMsm5mLBRtNTMwc1dUzZpsVgsmk2Yz60MbZN7W Fp9Ke7YnCmzPcqnSSv2taQCs4FgjyEaInY8E8pagIQU/dTK0gP/lGKsaZdKKVodIadnx4yeMHl03 adKU+x/+43G/PJNmGcoUePCaC6+74d3nn34huFtdOD2FslnCofC999679357XXbDKTfeeOMbr8/F ytvb23fjr8897KKjsJw5aUsul82FQ5Y8V7QPreuNNqNtiAlgwEabARivCEweSxm+DUYuJBhU+vbl N/XisZwIAx6NVyS78fijA7CjY60HRwX643wWm9Dq1atXrVq1cePGIfsCHEwkv9+P7aGhoQG8FxhQ 7A0ajCmDqSpd58TmYfX5q2U1k1ekmoa66PoVvLe2M0nV8HYqpFjBajCU0+kqZFUHL8biaafXns3F /d5gMipRNFgEnBqX/BU2NjV1d3XCVrvL5SxkizYLa2XYeCbndFaF+hINVX5atiVUOhvPunw+zsTC WZHD6exraxObpzKFQm9vL3gpdA3OkbCBAcBgobV2jqutqUMvwOV6PGJfXz/a31AXhN/oXFZ2bukg yFE0WVAdAkez2XgC/eQFB3Ilcym70yFn8jaYQzVZcnmJdwiZrAIv3RzvpkWxd8Xm4KhRmhyVcpLV 7kxGoorN0huOohnIjgKxfxNq4/dYkKVgbXVBkkPhCBgAu42xc3wyncXGytlps9WGfVSWFbNFo6ki zCIyNiEWSW1xDQQfQfl0Jqnpst9dlenpK1hheZWRYINfStBqnjLZ5CJvZ6RUxirwOd7NMTTVn6Pg RKjZLgYEvhBKmwtUVcATMRcTqUyTq57L28BNldxd01YrzFhzHBosla7r2j3Bqu41i+1VjeEY1eBk qYLJyYnVTtOatetramvyBXQoB/eOAhjxTBI0FJwOzA0H78ik0/lcTjJDkI0JZaLA+sFZpKLihw6k eC4bjUScfh/yZ/OU0x9I9fX7qr3dK1fWTth9RU+uaLVZGC4UjcGsC88LNqtFVqSejj4vqxctLAqV FTkZl1LRqFnO2PFsMsG3EkYZMxmNRwCAS8rWvGzz0sl02FczMrUpTRWtDM06OFcqX/IfgIC5gQbj LjPcBrS3t7trqlPZpNflAScdDofra2oEsb6/u1uzU9l00u92WaRCPJl2WhyiIGzuCbU4HRCMMxwd iYRFTMLeEPximSiTlWbxZYIRR0tQPr5A8MMBt+dghCqPGA93VgUaNvVFKVaw2h2iyKTiuVyxKDr4 vngCM1DTi16Pt4AJoKTpospbi4KdySVV2NtVixYry0jpOMiYyqAKuyg60umMBpvBBdnG/TtaqkP+ 5CuJFQp8Fwpst7wU9n6sDlhZEINJQozthAifkIgA6gCHoOEtVhOs7CSRvN06+eBVD7sIzdgofIz7 fYsWLTr34kvPO/v826+94ZN3+0V/9I8vvHnC2VcfffJxOWqThWLkSOqAQ4+jCgKYKihvvffXNfCM jPW+WDQffviRRx1zXCbT5bahDRaXzy1vyBdt/8TKGI0hTSXNLu8FEEq9+pYLJDBBQ0z6VR4bJQCT wCiZAEZd3wUAkwq08nq/S65tBwdzAzJL9B3LPVqFo94VK1aMHDnypJNOGq6R2Jk6OzuXLFkCFgTe aTBtUEgedt5tdlNRttLWdes2jJs0KZMrmhnb15vaR3idMk3JWRnG7SlFK2QLyzo7JweTLqERptex yQoOLhbr7e8P0ZTH7xXtjFUvlqbrpk2b4LMZm3pHV4/o9MAufFKmeKcrHO1vqA7EY1H4HcpbzM1V VQU4zTFlNTiBFilsh51ZhdaVpqYmMGRoJLYx6ALisb+/3+v14RFedNxu7Lj5dDrl93viiUSorxc8 BLgZE+ReqQxjpSHCwtRIJpIJVXPyDkxNyIIUXRbAClptNG9CV9AqnZJBQIfgZGguncolEvmRjY3d a9eZR/jBNFCazkHiwVuqhBK7gF8ZNmbs7thTsaFiy68OBDdubPN43G5RgIAVHB8Ntx5mi9PhjKV6 IXtx2n284JZN/XK+WNRgzl6U9TQEnj6fK0ap6XQ8WBPY3N7mY0F4RrDxLKVYFcrh4DLwIM7wtCXG ufEz09etWxXNBWrHuEdUjU10yUk1ZpP1gNudTEUklvI46xXZDD6gyEM8CWGRNZZIYlZYzOAXqXxB 7s31tTTXS2Y7JIRKTlOT6Ug+89FK04G710QSCZ/TbZOtdf7qZCwh+DxgnkLdvXD9mYhEQX/B4chk sw3B2nQhx+hqMhFDilY09UVivNPR0tyUyKbwO3IIrkgkWldVJWf6wNBgsHy+ajfNgSf2B2pYqzXU 3+fg7eAdRzXWUJqSl7VUAVyFCRyzi6uTMgmtqKG5mDmoGjF+lZifmNKYRWykEJKSOqV2LFvaMHqq nsppkimbKFhdTvA6GBGi5IC5sWHDBsz/vlgEYxcO9TO0ta6+TsoXwuGI3+fLQbilFq0aeE6FcQhp WVe1XIPHEYpm4OgJLtvhWBQm9sDzsYwV/HcyGcPEgyNUsJeYB1hh4NkJ63A62icKZk9N9eZNm90t O2UhjjMxPeEwuGR8McTiqUBNfXd3d1NTI2YmJgYKtPO0yaQmI32Yb/A6pUlqLBJprPWD84N6RiYL djpWHQiArXXYWBXS3UqoUOC/SIHt9owPP1osJUTUhG3S4BiQbgTQmcAAsMrjixmPgA3OYCsDEU9I nMNGwXcMJPaZLO+ufeKJ5xcs+iTbH7rkgt+aOXevZN7/6BOzCvzy6bacxvjED99+JRgMYKe8996H 3C43BOr4KId5qhOOPxk7F1Y9zinCx64k50Xn1hxtGm0ubz/aTJptAKQjhEMi/SJxeQfxlgSjzAGP BJmUDHhwAD7ykpgUYhQ1GHkbTMHmgQ9lbHiQPWCzxzIdiUR23313QofBMboAZgWOHbHQY85gE4K8 B1lgBgPmyIqqtn7dhvv++OBHnyyVcHWBtnlrgwUNh8hZgYPnPxWudmafduYF5/82EAyg3lQy43K6 4omSbTOIE0xmUzzcl03FIePBLl7f0KjqVCqTd/mqTFKEF+1Zis5put9pb1u5OFDttQpVPr8j3N39 5JNPvPPOuyKMdJjN6AK4AWyNMAKC5qFrGBHsZ9jA8ENob+8C4+LzVcFfIWtjNV3JZlNwJlbt8zg4 GwQABbVo40XGxumainMWSB04Ht4UHQrEQqai2WSmZLUQT6lwRx2Odvf2q0U6K6vw7RON9NnoLQ40 NP2mm25auWJFadrQlnA4hF8W6AyeAL/H5uZmstOjbSWBWdHs8vicgiMVCzPmog+MCBxXs6VjVtDE 5/NDZJXNZTEQixYuuvg3N+VzGoSCGIX1G1bTVsrrc0HagZ9PQSvmcVKfy+bTCUotWGxsOpOVcFZq KmRy4AEzZ541+95778ad2qXrvnKK8CUu2jk6J4UfevieN954W5NhKK7g9zvBECvIZaatrJ0XnBaG pVmbw+myucR4OplKxTnGTFMazdrPO/fiK664Lq3lCmoeUj9NknNwnYQqNVNB0ngryzM2mjLlMlld 0600Hc+ke3p7pWyKNptRA07r/MFazIdwqM8MpliWIIBsrPPiogwmxm233fb6668nk0pnT4jlHPFE qrunB8NKW3CSVVDy2Xg6L6s6i+M3CMaTsZI3T/hUZznMRpAdJYDgmAkgDmYChp7GyafDxjnsNXU1 J8w6Np1MK3mFtZS8OW1xW6mB0UFeMD1g4zC3IXTnGFtNdVDgHaFwGCd9Lq87loLrcAlsOqMmuzav veKGG39z9fX/c8ml119ybiiZZzh8EsQ9Tkc83CvyNlnCcZ7q8/ngMROF48eFnwlmIyzUYKo7HVx/ b0+2vw8HtEcccWR/OFWQS1QV7JyUl/3VQUmlMO3bOzsYxtTQGKSsnEWTfTbdAZ9VorcH/j9ltcbr 7OkPBevqEumUiTb7Ar5YMiLr+aw0tGPybXD9qTRpu6HAdstLYZ8jjBSGCtskfsMIECEQYECMdLIv AhmLCxYjrN0EHm6kXTi0h0QGx4Imq1nwUQq8GWs77rjjyy8+97cP/5aVpWQ+u2DRQqeVkrWMhbNE N3Vffc3VV155VV5WrrnmMuxP+TwlMqLd5kgmsOThnN8S7e1lbdZMJmG2DPtRhbYZAW0jMAGMRwMB QHn78YhukmC8IqwP6bWRaBQFZJKrvJxymGQxMhqlleNsyzAaTL6YsfdANoB9BfsQ+aZHpwYH9AVZ yISBPAA7BHLhux9bKdTNLCbzww898thzj9xx5x9xBJOTwFxpLqgUFVU7TVmokiFXhnemZKqrswus jNfrwLc7ykSNEBFBvc/psFtMRZ/HBYtlGK14MmXjBVmDdlIqkY7HZC0Pbap8Akc8D953f1a3ZDMa baX//NJLH3zwPlqSjES8jY04WyltV5CLJBJoJMQ/kKWhzdjYxrWOCfUnpAI4SKBDEEVDZQneqfs6 N0FvibVzUHkxMXZs9pSu6nKpd5BQxdOpcDIOxgjCn3wy7bbx+VS6sb5RFL0qbqzCdbXDYTGpkD+h L7Fw+KOPPsIuju7kkqmaxibQFlIoCA+wr2O3xtaOFOyvaBVEd5KiphJxj8il45FwXy/Yn6wMLS4z mp0CNyErYMXwgwUjgmItFrqjo7uq2h8M+gpSBodohZwqCn7R7efAAlrxg1RZ2HjLZRd8uvCThYvB 4YDVt9vBt1XX1dVwPOVyCfAdDgmR3c4VpNjnixes/GptPmfCpdx0vhdus3nRZbYy2bwUT6XBVKkQ IIUiMDrnLo0j+I+iGfIxi4XlnWnFDDa0rjaQT6cEm13OFXAq2tHbb+Z4Dy+kwlGv6HI5BDkPJSsf PpycbpeTt/m8bhxm5iS1P5KAW0/ezmZTMZxkYRXY1Blxud0YqY8/+njdunWYa1ATYswU1Obq6mpx 4hqOxqrqmsLxVNECNbsipFDoLHSJoGRm53kzY8fkxGwEJwoCgsJY+sCwYkrH+sJmmgX7BfHnF4sX x8L9lCZzjpJHXmQBhTHQwMdlZIwOHqHIhWNrwggCIZuHFEwzWXGsJlJSjilm8unQ/fff1xnLaIo6 79Enpk3edfHSVR6vB77eLbrM26wQbWICo3zCReFbEaw81lXE4BejibTHB2/v3o6OzuXLl2HcoYFl t+KgMut2ujNZOZWTI4lUc2OTKmfDneslxo2PNjkZysRCJoY3cQK+EtREt9NVlc5A1c+mF825gmTn OQaqaVucT2zLy06lbdsfBbZbXsoYKiwE+PViecKvurRGlIXyFCw9eDRyEV7KeBwMlJgUbBwmi5qI rPzs4zf/+jfIHvAd+OiLL++8026iSF9w1om3XXXJW+9+RFuc78xbjAYs/LzH5/X29XS/9dbbkGyj toya6emJmU10oDqInQMnHPiedLlFnL2gPd8roDlk4zcAPJbDKA3MJYkJABgIJJC8SDG4B8AkANnA /zbtH//RLwTyTGoEwRG+LXhb/49NGvs69g90Ad0EgKHHB/pwAScv2KjQU/SaTBLkwm7hsON4yZaM J16d9ypn9r317ruRWLpoZrWclOoPYZPPxqPQ11EKeXdtPeOvrg5Up1NpyCZx3IaJh11HVVSMWCYZ 521M2/r1Xo8nFAoHaup6+iO6ycK7zAU5JwRceU3nBea15x6/8g2S+cMAACAASURBVHeXd8cgW7K4 q6rffvvtW2+9FVrPTp8v2t6u4rRP09AX9A5tA6NGAOxhGzb0sAwfiyYgM4C3SIgtfD53OpMIBPxm qsja7JoJUiE6mUpD/dxht2YzOH6heJfTG6jKyVLpSizUoFU96PNDfkAzdvB5EGWls2m/39W5cRVE QPi5ffrpp7B8G43GOJ8P7B0ag3mAGBweqA1Sg3oQm+GxrQPHl27oMEEHCyrnnI2FmhIYBTABOOi0 c3aniweJkOuUU05etuwdTc87XfaNm1aqel5R5Wg0YaWhTMaEYknIpTCheYa22Zne3u6nn3lu7jPP KXLR58fpbem3oGpSd3eKZjSTWS0NVqLg9jju++Ndt9x8A3plobW83AVxFKRS4WicE0QojMngoSiT gCpxJyCd9Tn4fDJmMWm5ZMLm8amckI5F4n29OJiL9fY57HwBx6yj6rsz6Uw07ne6+zq7nQ6hdOQX CoGplRUlGQtDhtQfithFNwaLYWw4Yq8PVm3hYBiI4vATxZC9+f57F110EXyyB0TWquW9Arf665Vo j8NdFc9IVmeVw+XGXQFdBaelgw3t6+mCypdKlX7g4FbxA8S0xCxFDCETYoczKCmWTE6pHTHqq6+W TRg/2mpRtGwY8xzTGPgYkc7OTjC7yIURtKIyk6Ww5TIKLhxYoRzHMg6wguAZaZx6RhzQhmL42edf 8uADD7ww5xZKLkaT2Xg8Ee7pDPrcvR2b08kEjqdxTg1mDmw9+GZMADQPPx+IvpzBOp0V8gV17PiJ mzau33WnMbSS1bMxjEs0HIW+ORg3hhMyct5ms/j9YoyyyCZGk7KB2upYKpuW4PVcF+1KKq1BPYsy c2YaWcWSiqICPat/rOTb+gJUad/2QoF/7KbbS48G9gMbCZYSsnxjRxkuAAGvDCbgX/JSyVTJ+pSa SUEq0NbWdvzxJ9psThz9LFi97sG5f+IY6t4bbrz4rBNmHTiTZppPOP0qbELXXnnqL0//ZbC2bvz4 8VhQpkw520f7cLaD9RS7JpSRgy1N0EDVNMgJ0OShA9ppBGAQGABWQAQ0icSEClvSSlF5FlKukUJw yh8NGMDQjShLJfQk7BSKQr2g4b+kHmnethCjj+BiCduBbpW0YrGDMQy6MGTANoPPd/QayMiIGKIs zDGWpnmb/dV5r/C846qrrsXx3nPPv2Sx2gULK9Ls2uXLW5saIGG69IrLH37mmQRlgsTo2muv/f3v b4CsCOrNhUL+4Tlzrr76WtzaW/TpgoMPmgleav/9D+gLhYO1AezQt19+4eNPPn757+8eNWrMwvfe /MPNj0BWs9cOU045+TSc5Vx7zbULFiwIh6BBpGDbHtncDAFDY2Pj+vXrMRzYzBYvXoyDS6ScftoZ sWi8tjZYkgw5eMil4skYjpU/fvftaVOneAT7iNGtr83/u43jnT7v558umIpEl3viDpPWtm1sCNR8 9vln55519otPPdtU31BfVz979pmPPP5EIBjEdb9CPvPMk48+88zToNuxxx67bNmyYCAQbm/HDn3K Kae0tLTgbG727NkgOASBDzzwwK677gpKzn3qmVgiwdlt7SuXX3DuOV5vlYtjnv/zy9jjIZGCdjk+ MTANcSI5/435v/zFpYqaZmzaAw/e+exzT8yd+3hT46jG+nHLl26yQXHZJaAciFsKidiSL77421/e +ODP85obW6+79gF8KGFugpf66JN3xk2Y4nRbX5u32usO5HKZP95/35w5T2fSFDS+XnjpQdyGq29s OvmUX0aicY8XJ4wKABz3FTOSKS8tW7iwtb4Ggqurb7ju2ddfw3EvOK+gy/3lJwtmTp8h+sWGESNu vOcBXQTz6e5o23Thuec9NudP1//+uvpgzT7T9wFjdutN19t515ix4za1d6VzSm9/6KknnxDBcvoD XkH4y/y/YFwwZFdffvm8efNwgJeLdJ5x0lEvPv3YbTffhB5O23u/lW3deTPf1RuGPI8q6uhuMhZ5 8om577z7nozbMFbrs88+e/XVV/f09IDOzz///PTp00F5sbrm/b9/Zre7Csn0wQcfuGrVUnxEvP/+ a5deeilGavTo0eBrH3nkEXA8mPxow/IlS8eMGhWsCZ5z9tmzz5h9x113RuB2VJGjccoExQYTpizO 0cwpGce+pta6aspdhVNHB3S+RMcjD/1x6i6TR7S01ARqwJxhrcMH7CuvvPLoo48injRpEhjlC353 s2zhM3JxQ9vm0SNb1ny10suBi4y99MILtU21jU0tzbUNq9etD4VDTtHx/FOPHnbq78x2p702uGzh pwcefAhU/m2U/PlLj1555c1PPPGXUaN2uOCCy3BfAXdVPa5AIlWS9VZChQL/TQpsz7wUYYwg3yYE xSJucBUDGAjjFTBJLhJvZSSg2oQTGxpnBrzrsBNO6Ovv6e/riMWii1etGDsJqiVRSt5w1+03RHp6 oon45v63raJw9Y03hfrCKPnGq2+MxpZ/9dXDYSV82zPPTZkyDn5rcC6T6sddaA+kJFBKIS0cMkZr SYPLu0OaihQDIDDBQUwAknFLAf8QQQ14Sx4N/CGRDRxwUYSzIiWT2v8l9bZC2P/+K2w54JDATqHZ 2FFwFAWRCXRNhgzY4zdv3gz+gOTCSRYygghQSwE/NOfhOZMn73Tuuef6/cF773sAO7GekzavW7/f 9EMvuvCC9rY1U3abxnuhRW5yis7aOujYzS3pWhX1aCR66y237Dt9emfH5sMOPeaS3/zmyy+/bB3b On36vnkJ4hk+3Ndx1913fr502TMvvzRh3JifHzA6k05dN+exCy68AM2G+i104R24ZyfJsw6fdd6F Fy5fvhz7FvqFkfriiy+OPPLI0047bc2aNbgLduxxx/f1RdDNTW1tTpcTR3tQC/712WcdOHPmqo2d c594atyEieC+v1665PBZx1915VWr1q0dOXr0ueedu6Jt3dQpUz/9ZMG5F55z8403vv7a67tMmXr9 76/vCUUw+ps2bbz3nsdwrwIj+PXXX5fO8raIavfZd5+NbW1vvvkm+LljjjkGrCeUge6+++65c+eC /5vzyKPPPfc8svz1L/Pnv/7OooUfL/5qzYRJO7JbhMQQmIC2+FzBrxgK8tAZsnHmVDoajvRedNG1 r7/22rx5r8/Y9+CjDj8JHE8qBfFWWtcUm88zbmxr08jWg0497e23//6r2efkMgVRdP7pgTsf+dOD f3r0uoMPmXHh+VesX9eBPX7VqpXhcNTOUR9+9O5vL3/plb+89fEnn/zmN5fA7m5nVxeuKEI7Hkr6 uBbS39l98MwjL7joorZ1X0/aabKZ51K5HEtRq5ctnzlj5qEHHfzlp0tefGXeTVddeesf7y1Kss/t XfzZ5+de8OuG+vrX/zJ/6ZdfttTXpxKJ+a++UFtXd9Mttyqa7nS5oFj95t9eWPHV0qNPPBGjqaiK g+cxxyABxaUIRi98veSzX591odfjev7PL3X1R56b90ZeN/EOERcioSFW1FSB53D5dPXqNZIM7bfS XTzIBaGdDTEkpJXw94DheP3Fd1taxoKciQQOTuNZKKpr+BaIPvPMMwcccMD9999/55133nPPPWDE IRXD8eIB++9/9JFHfb18xV577fX6q6/hbg1jY3OFvChScj5HQfnPBIGdKZXNL/jkkxOPOn2fo46Z sf8eWADnPv4Y5sYVv7t89epVv7n0kt122w0tww8Kq8R11113/vnno6477rjjufse/mjRF7zTAwW1 SE9Hjd+Du4jvzp/3m4sufnLOkx988OFFV151yN7T+0NwJ9FDm6mOcCaSyhW6ukTB0bfqS1iG0Qvp bKj9mccfuuyya+6++4Grr74+FoOWvT+SSIqC57+/jFRq/IlTYLvlpbBOYBfB6GKV//zzz7FqIwV3 iKAAiy82I+ARaxbSF24J+KTGhx0+y7DIkqOcrc0PEA/u90pHfTiKCFZV17sFjw9ppaO/Ooo5gBLs QsDr5lwCDhlKV3RrnNWlH7mZarKzFNzMuNVxUWEqLXTWW+KFTEAXrbSUrzKNlpnSDjJkwO6ID0e8 wtpEuBwAeESx2FOJKIWwMniLdHQE+AhElEKygDIkFxLxCjjlwUAGGikTwnnAQwa8QkC9pFLgoApS OIDBrULKNhWwSaPNECzhi5yIMLGXIGVI4hM6Y6+C8gd4AnQQ4kao1gLfrX+wYNkXy9q4U86/TbR0 z/ntblpm1fNtMV9h0aJVS0KBSTMuvdUujjj5kEPOnjbNE80rmnTssQckE5uWLHzPy9W8+vJC3tO8 y/77Ll14PUeNmDj+HNkfmnhgfahvdN9qs5f7Xzbr2mOPWQ89++S0fXYTLP5TDj7JVGR3nr7L7js2 FOV+XECkbTizMSl5Kyu7l36wLpPt3XnXg9zBnczWnlWLHhML8s8OPLVbp084/pSlS1bgsEUqaE7Y +MlIumbGQRinOrrWJrLS2hkHTxY4H8vmv/rqqaIanLDPwZZI/KJZp3+5IJKRBTm8BhdYf/fg+8cd c/Ruu7Yee+xUSu/74MPnaYZ///0eRRm/86TJNnO41mm25exmSXtv4bMxSnns1VVNUyY0j2+ZddAM Ohl79t77dh6346gJUyhPQ53V9M4zy0yQv6hfpXRrKJsVAtmxI8d1mhNCbpRXk1L012mFq9JZp6W/ U3Zr0doaMaKnV43a44I5r6+ZNlmePYsxK/YewePQ41yk0+ZqzltEn7u459i6+sDE8TvuXe1dzavr tTQzer9ZT8z74OcTT7rhAA5nQUW9wWSTHP4etWDLxCiXoNpUasXyz8zW4j4HHZjSi3x1TSyX0YqS lQZPvOrdVSvjI3aefvb1VR7PLw/Z/cID9nDkVSg5dS/eaKNGHnP5nMBuzQdM7Hn9urPeu+bNJZqD cn1JmaP3PbrkjPNv3m9nqV7Ujjhh/t23v3noHuKx+9oXL09nKNZEfXTexbsHph0XpLOtdSqvt65d 6Sjwm6LUOtXcqOCOp4bLCNarn19w/vUPHb/n2In5Da1ua7gI9fo0zTnyZofNzlnlWC2nQM0vZ3dU O9bn1KVZecdsUqipzuUTaxZ8uCGsWeunjGoe2WDTewVuXVYKZ9P1bqo6SK2U5aPfauuYdpjnzEPH ehWxP+82O+Jt756dc+53+FV/8jRP+PXxu//6xBkdihCnq8Q83EJoCYaXizVZupqSUr89Ys+DDjts sUztM3EfsZili1/f/tDt+//ilp+ddrXT23DNhfvv4mDffmcVW8dpuV6a2vmVz9bPOGXcqYftM8Ga oZOCZJNsTIyiWvooe9bU8fQlD+168/xxJ528y0jt7iObdmgceeuT6y246Rh9y7beBfNdtmYHLYUo iuljTHGOCvJmim7925KFhxw5qbk6XctCB03WMzAXUfKUWgkVCvw3KbDd2kTAJgeWCNs8juoPOuig d95554knnsB5ynDExavDDjsMuYAADgMxNsvhkH+C6WAXtt5rIBjME+Grto6/jbwFLwUOCcwf2CN0 AZ/1GHeE4fqLV5hXaDzEUQjI+A1yUVzwwQc4c7n74fv//mQ42rkC19df/MOtl9x5ylfr2yZOGhUQ KTUepbyuUDYv2x2FghQM1hx3zGF/+tOjO0/ZAwKqSy65OJNJf7l0VZLSD/rZ/mn+c64K9gZ2r6qG 5+wCrlCN2aNF4ChsH5STT+TSNtbq91IwuKMquLsn1eI6A84eNdPTzz52xPl37LfvviPGHDnn8Ud4 Vl385RKGtU3epZay2mExoKa6NgGDQ0wRF9nA7kLohaOux5+Ye/DRv5oybv/anVrfeGF10G3925t/ q+Prp+8wQaAKwGK8EyAvyeU2gWlvaKiXbKg0yZqshx+499x7Hjp4t1n3zbn/0huurK6uktshJErg zpiialArFngWTVZlVVL1nkjUy3KQjCS+WjZuRA02RahV7zGtKadIOFZb8QV34H4H23zUnbd8OvOU UbgrAvJCB558nuC3DG1CtUgVQnEbw0+ZsqPPS5njTFGns1RKLuRhks3j820KQbhrEr2+cChUpyrp ZDGAg788nUpn9pg2pcpDFXsoGfXqUciw4rF0IpEZOQKGJqgqb/M9d1x/+uXX3HnP/cec9Itrb7gF elpOcMya1N/b1yyyX3z6icCYxo+x5Xt1nnfHMgV8qNXV11zz56d3n7qz4KYiyfSoqjqF3QihdEHK hnNJGBwTnRyEXnJSFwVTY1PQis8qxdTdHXJ7cWWNcnLee+/5w6WX/mKErdvT6olEa0eOEjSt6HH5 ofcNeQz0hjAzoZSNzxpdK07eZWIiEYe+OXSW8AhV92LpuA03SWO77FYFgZFuF/Ol+5YUboD29fbO f/XpQ2fdMX3S6L0POO2yO64YHaB4zgnTUhDv5aUMzDKNmLgrZ3e4HdXFvqTPU41zQ1Vl+vuynlqn x41rBRSVlOIJ6PgHCzlYJ/aAXy6Z7rRZ8FGHqfP6m+8fuOdO78178tDjzqWyJ1158eGb2mJTpRyM bUI4Lzicu+251wcffnjiBfvA9NWEhlav252TVwWctTql49opTrphdINnYYIVnYaNGHXzV0tUeaYV pHEIrWNHL13zdSa7n4UVaqud2WwxXIjAKiqmBPTxccEzI+sTDj7M72Y1pWjlGCmHewsapMxpLbuN LC+VZvx0KLDd8lLY8CBfIQMJX3u4YYdzGezx+M0OObo43IFGJN5CHAXBA4RYhBszChkyVyURPAcC CIsY0ikC/4h4KezWYIkwW6BTgvYDQAp6Aa2pIQcXhyCQ4WFukC4DE8ofkGk5upR7brv/iPOu33vP neqkTdb4ZPovn77wyotf//5XcYVau/ST8Pq21hqaioVwrpMpwKSlW85Kxxx97Km/OOPxxx7b3L7m 2OOO4Th28pT9XE8v+mLtZ3T9+mSmwOYnFnFTzuygWHsw6KUKVFc65s5Fs7qal1PhnngjrO97GwWH T5E1lqVwY2/HPXb89LP3Nq587aDDrrz6mmtfeuHS0a3ji6avv17eVzWpmurHtqU4BHsiGYWBA9yx h1kpGFQcO2H8mnVr16YW7jx15pWX3fLU3F/uOm3a3/78ybKO9mY1o6tcHx9w+6jkVwn4eMS9uhS4 EcUc4PyXnX7+fj875qG77t2wbtFeR70B7RgbLHfjcj6MAxRNTU1NZup9F1hAloetJ8pdVLI5b7V/ h133eGrey9GslsnAMm2Qd3UxsvfpJ5+99OvP738MR0RXtE6/3VcS9/I2WikkqGyuZF1KFHl/DWXN +Yole6gw1ETxecw6lqVNNqu5kM9SDg8ksWpR0mXF5RRtjAUK9clswckjnRNYc7iLclnM4VyRFjAO ZoH30WaOLhkioWy86ZSTZx9wwi/f+3DB6Weft/ue+86adQh0rFRZCVYHLPnuya0jnvnrolCXVi06 KYnN4VojQ3d0d8z82T7XXP+4rFO86E0n27qykg5hEU/XcqMYK8XAZAo0vu3uVBIa+n15heKEatg5 L0gJaB98+vGXd9728gvvLZ1ZU3zzy7/8YvaLCRh7p/OZhNLY5ISKF8WKEH15BNZuNcGcN+eqgvFP N0u5GEc4lcBdARZGKYtuGBQFg+oSYL9e6AolClTB7qDqGlqVfteiDz9oz+Ko7qz77przwiNXauGv 05m4hZHtAoNrfdC2olR8JnG4ophOl+4ZMKxr5Khp6lsbs0mNFWDSIrJ+fUeH2QlSxsNJ1e2E6lmo ZLhBo/K5WDyGzw+c/NpqXOvWrAn1xRtq3dDOstspGVY3JXnRkqUzzrqlzlebyyQ5m9XvMetmRxgG T83Fnt6ucdNqY/DrhfsKHIcro6JQNWVUfQBcaTjnLEirvl4+9YRZHm9VW960ccXHNP0bxuHOl6Sw apVToCiJsjk3r9mYjVOCAOoUVR33U2G0E6tQliput1vbkOtSJfEHp0DpFGa7DNgR8YWFroE3Imc3 o0aNwn7ZOkwAIwV8bKVgpJALmyU0YyqM1L+cG2AmjAC5FAIoj/AvM24jCFCKwliDk8YnMmGjwUVB MEn6MjiGGgrsTAIBWTCdkB1sN+bMF59tgozhgnPP3H367lP232/WmedcesbsWjX2wscrpx90qEWK Lnz7z6G+9lv/cPuzr75Ke12yBPOw1r32ng67iDf94aYzZp9dVxeAEc19DzghrPdecdX/JMM5SrZs WNcB60pFHZfA3f29Xby5UB9wsh63IxCkbVQmslGFx5eMFo9lcIMB4ivOYX31+cf7Q5vGjh7hcTlh Ign38nbfZ994IXv/ffd2bGpLpWJfrVgKI91OpwDeMQ/pRBoeXeyvzn8D4iKYOKqpb7RSMHRl2n/m AbjR9rsrLi9IsLFJffnlsnSmMKp19BY7olLOWoTRpEwsPcrfOG3EqLvvuevk839TPaZ0lwLmwi2s HRwgDFPPmjVLzWsnHnXqhtUbNm3Y/PEn/4u7YL8656x333/nkTmPxmC+vZD44qu1SrH4zrt/X/rl V7vsuEuV2x0Od7rcDrDoUgrWRXSegzlTAbxUNp/a3IvTcFM6ruWz/XAg4vU0F4uOojVHQyJjY1MJ WK8sxtMwk2puqKt54PfnyfmMamJSeSoP41+ZuFVVeEHMMW410QbxopSHAYotlrRoFfKev3+wyFzE xX/aAdV7Qcim8j2dXXiEqym4Rgm6nJlw34dvz/9ixZrb7374hflvwzQrjD9N2qlV0iJPPft0W3vf J5+vvufxp/Y49lBcB0wnTX1hCnruJgt6QUdilNdPw163FMk7nXU2XuvDXQGNgw53Nt2bzugXXnIN bmsmUhGX6Hc5grl0TldSkomDVSsvR+tSNq9S7aEkbOJbZQo32iCnYmBfIBKPhKIO0bX4s0Wdm/pu uX3unVc+XtvkT2Yo3Hh45cXXYfNAtOvNDTX5lCplcLeBj+LCH13QzRpjx7XBnMsh5lMUy/uTqE4t hKLZadMOS7UtvOjcU2656frDDjtq9fq+Qw49krNR+FVA3GSz26sw/UqiJ6q/r3/tmrVPPfVUId1b 5fUHfU3nnHnuY3+675VX37LSxXkvvrEpFG2dNKk73mWjTflkPBaC4Yg8bIviSHqLgyINZeKzBJal WKfz58cf/8yNv3vj1Q8LJubjxUvWb1698w6tOuxSOOsoqnPp0s/fX/jFHjNhRJeOdXe4Pb6+jBZ0 Ouv9EIEVe3r6YdHDV+VlcTNS+8ap/DayyFSa8VOgwPbMS+GDCUOIIxhyZgcY26Sx8Q8AwG9hK4WM AWhErFJhpL7XD4DQE8wHAMTfK+8PiIyrZJBL4ZgPZxYIYKAhv0T7CUc4OIbkEh2Egh3QwEVBAx0c CZR873r0uX333ZdWMoLNYhe9ckraceqUPVtH/nn+38eNab3ojFNuvPx3O0zdO1LQ995vhkWOwX2Z VFDTqeyRRx7FM9ypp/0iFO6jzJpNbPnr62+8NG/umNodxwTGH3fsATDQU9SFhEQ7BdGu5dKRPvjs 2/eYk8ZOGHf8/ruOGTMJN91qgnXpdAaeTAqF3G1/uHnyxFZf3Y6w/X3m2eek8lLTiDEfvPXBo4/N 2bl19IjRTWeedcbGjesw4WG/AI7kIEzs7Qlddd214yaMHzdmT9wsP2v2r0x6Efrmb7z01/fee3vU 2AnOkcH/+e2l7e1tfd0dNTV+vVjiPBgry9lF3JQ/fNZRGMEjjvp5X6g3Gglnc4W+aNzCOiAKwpHf O399ccPKpdOn7nrozw677oabIsnExZddetOtN51/zq8mjRszdeK4J5+cCy9tCz5ZtPfMGbTIP/zw nx9/eA6O2XEUhTMs2mJTFCqRhGo/qG3zBO0yHIQwfoHTLVSW0gVYfpDNSZjQhFWpDMRXMOsla7Ki zTxgf9bXMm5k40cLv0hqjOipYosFJ62ieVZfM8XnYCdBytOczZeFUpSebdu44eQTz6ipazj9l6dC kXyH8RNhI6kadkFhjUrT+2PSoYcceuvl5139q9P233PKup7Izw89kDPBf482cZcdn3j6wVt/e+G+ zSNPOP7sHXbe5d5HLhVEOp0wjx8xNpvvzxX6pZxl8rgxyWyHYk6xdeNo2m1hC1XVtgljdt154qjZ x/5s9NRdbr3jilRow4z998ym4W/F4uSdnE3Pmh0jRozMhDrhag7sT9GGI0MbC3P3RdXB2VPgGi2s r7b+xJNOXrbki33Gjfr0kxUX3HwmvD06nFQgUHPXHQ81jx+94+QZmpK4+fqb4F0QN1tcDqpogXu9 vENoKOphmHigKS4bzYysb3R6YZdC8I+etnzlYjUXe+fNN8899+JTf3ma11cNuZQDDhZFAVfzMskk tL/NvHD5OWfsvutuV//+rl9feNoVl12m5ExnnHrW0Uf97OKLTvP5/ZddcsOjTz01/YBdcbQn4iQP Fjxpi2hzQkdR0vJOtwCHP7iybLOy3b19RYY95eKL/+e8086ffWp9TcsJp19x3113HHrgjjisHL/r zPHV7iMP2f+oE8+65+4/8GZ7g98Tjcb5YIuWCkV7JBY8KsfDgEUcDYNPpx/Np9wPuPJVqv4PU6B0 OjNkkSQd8QAAyCQRMXYRA4ZQB48kYL9BIDBJJymACYBXuFpyyCGHDFn1VhKxyaFGxHD0MWPGDOxq W0EmryA5MM5rsHUMl4WoFaOFwEH5OMfBtor4X5b/byOQurAfI7S1tY0dOxbcGyiDluDVcO38t6v7 iWfEmIICZLqWA+CeceMMlAcjBRjGeB5//HFcRgNjNCTFMC6YIZh+uJV28sknw/QAHiHT4hQocdCx Qp4RHTbGmuzc3NpcJ7W3La3btTm7yaGn22VnKBKdHGRUmyfkrRH7uh12Dn5YxCrfxlVr6ke2dMfC RTjKKKgwMdDT24ebA5AOYSbA/riNtXGaNU4VLE6WNZnzPeG66kAvbEHqWVOmeXydHu1pZ8ZM3Nyb DKZXCSyTEFurzR2hXGsEVnrsG7yWHCc1ZmRrROtkNA57Exo6ZAAAIABJREFUIToYjUZwZQzHfD6f FywYnY+ruidHb5RVZ1BsSRY2cfZ1fOHADluC6VhnNbsygdGsXamjNka6MzFhF687V4gl9GS2SnBa bbaOeMRRHwjl0l6WkdeurJ+819chKpnp2b02ryblMDM20r4JVp2CNR6LWY3GwiNGjG3v6NRhm4rN 0bmxgWBIzm/gi7unCv3h3LIa34FR58aRyREU1bMRJMg2jBLWmMXUhuxUxtLdUBS7N26Smv1Wq83b L8Ow1yo9YfEIvmg3pdjjYnNB6q2T1riEuq/TTZw54/Sac1JEh69dTaCLUJzq4gQlZhdbmFFKKpTR NhfZqWY+VeuM9i8TsmwIlp/MrCORyeOOgVrIqLmkzyWECkyd0oYDxNVqQDVb3Zl1MAsZ4keb1Hgg s86km7qso1jepbR/1jy29SvFJceW70I3ZyI5pYlViuE6yKXi5lxTk5ZcU1fgdNq2joFBMXW0TIsu x4pEWys7cbPynm6dwKowvrQxi5NkoSHGtduSbC6bqautycEWk17yFeiAU2oVHg6lohDcFEp5eEaL bvaJ9t6MHpZZty66xvRt7uFbPMFU18f1VTvGQ2LBs1zPuCyexlRnfnSDFItsjFe3ikXK37ei3zUt a5Mzm5dPqh2TDKWjDVVSIjxWNUWhgiY0OeDgMLxh0vQj9jr7lpuuPMaxaVlYbPFZ4X0mAouuiiOo W+1KrKfapvYzLi6va9GUf0xjNBUOJ8P1gqcYSSsOV6/Fb+c3NKtSMTy+10uxrjWOHg/rULqygZpg bPFb8w879qkX1rwZEFeNVXbWs30rNKuvXrR2L6uqm9iZsuG+oDe9yCJNWMdFadFclaAtRTEkUByb qY73r4uNH91qCcfaS1ZKTKIJxgQ5UzzdyZidQ/5+/4OJ2Mvwlf7uu7gg2YItBmsI9gusDwj/wVq2 8aKwoqK/RvzWW29hbUGbsZxiySXfokQhFTBSjEBeGY8AtlCuFJXDpPvkFWAA2yxBtv9DZcJIYcMj 97MgSBhyMAjLhTlBRFPAATwkZiWxnAJg/sjjgFk+4LE8yzYFgw3CCR1EU+AwwNTi2G7y5MmwR/D+ ++8P2U5MJ0wkmJaGuSb4Nsa0gbIUFo4Yb2LkjBPeQTJZ1lXtrBmxtrvN66Tz3fHqZieVUjIZxtO8 U76wmU7HWAUmGGAbGp5S0sl4Eg3ohK8MlyMrF8yaq6N3E9y5yFkafvGqa9loLGsyeXMq9HGtJQPZ /gC0raIpnXe4U/Gk0+fI9K1we4SVPWk0mOedakHKZdRsMUbbTKJAdfanqmqEns29DS2tmuqwwt2v nenu6YJRBhxuQi4Vjyex6EHPuwATSpYiOLxEjOKgz1vUQlE5JSTHV/uhTJxUKRg/S+Yjvrpm6AZp fTF8/OPX0lOybxSqra/pWL+upaWpvben2elKtPfnLdWB2pr2DW/7eU8yFR/R1NzbD8VlDQYZg/W1 q9euqK9t4u1CTovl+qloT6ippSodpnC5LtBcn06irgxEX1ZzBrf/IaPKlo5Se0IFKhDMygl7bWBE RMhB/dpMcSbG4fcUw6kcjJ7D8/G6eJLjYE3dpsgFWN92c2IkEy7oxaDbI/WnGQtTW1cfU5I2O6yq U16hysFC65qKJ8NWLexxN5ecAVrtybwKoZiqyFCWcjtd0UgoZhvZxHmy0S67px6FqlmTgzUlCn0m V8Bu8pjkbI3L3b45PtZfH+tuZzym6obq2FcSZxbTcsguwM46WxWsXatkvT47G/PpZojRuup8PjHn iG5sa5jgk7rMtfW17WGYtUfDdVicSmYpt9+mFH3VgiMZ7nH7qrNFlubpXCLktcPfcyGXTsFkg18w JSURxuvra2ucJpaLlSwA4zAvGnU11DREOtLOKjFNM7VBZn2f3DrWLq3t8NR5+lXFandR1tpMJkrB SUt9vdbTw8KaqBZnOCbZFmud0rrv0WeMqquf84drYSfz8dnHbO5ITbWXbNCnEmE/VxInwSsOxRSr PG4p3qWYkmYTZH/1sc09Zl/R4TBrqiQKvm5FCgSoSEpOh/oEcXwkFKpxFVOpnF8wn3/BuZq+vHfJ Up7bD0ZZ8f1KJXNmOeUU67vCsZ0Cwa61X2venXmBUvOiXUoFa/z9hVxBUWvcvGJXu0Mdtb7qWtiE i8LpoQZSZFOmQg7qgBRj5of88VYSKxT4v6PA9sxL4YOWSJuwDIMLxmHfVuhIWC5yGkj01gHjywMZ t5Kr8mowx/lj4aLI2IF1hgASLBG0pHFyB9Zq+vTpO+20E+AhBxcsF+5VQWUKmwoEWojxiNPhflOh mbOy8ZxS0GKFGGz+2Kqr88XIGIe7f+WH1bW1rqpgBv5NCnYPnbWZshlegG8zHNvJ0F3CqYSVxn94 ui2meU7IxSP9vLnJZuVyuQg+8Iq6BcdaOFy0Uhb4LzFZuJxSVKJJgYcKecRno3H+ZWH98MdWUhSB cWnsqdjzCoVo3ub2eOOJSHPLpI6uPnsAnF4adokgfsXAoY8NDU09Pb1whAJexeUK9CbX21j4ooP9 bAsUkxkW1jcsiUSUY/0lfWswGLJZgeM6E9VotadUJSHlKFj7FqtjmVSt369EY7ALaurvhvFTbxMV jWcm19flQ/DizMciSY/bG8/0C24+FAn7/L5YNKLy4FZiLOVnRacipSVZ91T5+/OdZiu8XJaseNBm NICRc7i0JdGiJeCioFfOsLgWQHd1rAgG66xmZyGtZLkk+Chc84NTlZLWt1VPRJIiS2tWJR6LW5w2 mESCT5g6vycdjqXh9cTG6FQsm6P4IrwjJ3S6GjYuCqlOKw21Kq0/3Ov0BzWqqEgy/PH29XYKcLXi MoV6UlUuV4qxdvakmzkuHetnOKovEYAnP4elAM2qOn+d3B+G7rNoK2JcRooT0uE0TD5Fu9q9th3j fVGtWs9LsIBVFY0lnaO5WCYUyDu8VXXt8ZUOJZhPxdyeMZYcm4nmiqpsg9wr3mNScKW0ACd38Iic NgsQMwosm4h0YKrAhZ/VKa7tijkpWRBY2OZI6TbR5M4mwrWB0VzRns7k7EJLRqYUhs5k+6uqgutW SqNbGuPRVY76hmi/5FLswXqxPdUDu/JwqW6xFE20IktFWKJ/+bmn313ea9WpR+69d/LMI8IM1RAQ tZ7S94bHDj4VXFRJlJtRcNqbrXU4JM6a78q5eAy1GCn00LhaBwMKjN8p8Cs6qaZ6AVcg1fWUN+BO ptsa3XWy1HPOOWevXPm8sPMu+x76xyRDMdYt9zkoRXTYJQsbTayurQmsjcPXD8dZcfeCikXDZrfX 5eWiPWFLswvmTWHpnrHgGEGVTRhHjEwtzOjiCgLsxugQZ1VChQL/RQpst2d82CqMTR17xl//+leY kiLCQ7L9IzYAEBx7wMyZM4nRBEhroWsFTRosHPh2H3o4YpQMm4sUzcRUyhOOUkF8UVaZFzKyOcHs 2k5R4/Eus4lyNOMGNjQzCiplYz6nLFPbs1QjH6NgJcXc2mml6EgCqwAcnns9bliSlgp5fA1jG4Hl KvCCCBD8GM0mJ4BoD2l5OUC4wMFNNeRGA16hzAEp5BHsIwEM6hHAqHHIXNt+Iulvaci3iBvLgQH9 JY8EbXC/QA2DIKCVMUagM3lVHiM74cUHV0rGizSjPEaBRntQlCEJx74FNNSCgHoRjFzlNRKY1Evw EeMR6WQWQQJHMhqJJB3FknoHxEgnZRotIfhgQNEGkoukbGmURr5eBhSCR4IDAKWRmABIx6PRJANA dSicBJIdmAikO0gZEPBTHZBCHvFbHjIdRZF+kbffVjU0EYADhCHLQeKAHhn9ImWiwagLZMGIo1MQ kA9XTiX9x0UBTHiMaeWMDxMek5zElTO+H9cc/k6txUQ3hFLz58+HNhL8WkAIQVY6FEEWZSNeu3Yt jnWgAQME5CUnfcMyUsjvoRJamNGDjIdeveD94J4nO8xQUS1S/YX2WHtwh0YLeBJH1bq2ddbqFh9P CfjmLVn1pGp5MFcKE429/tr8xuMOabYx2ZQOJ307TpoQjURgUxN/UKSAJi3ZnEhTjWYPWNONdNIR IA8I/146ikVGo/ABZf4UHofr+4B0PJKAbZKQBY8EIJTHI6HkkI9INALJZbAL35S75R9eGWgEMFLK 6yKwkQJMgoaYNIMABKE8xtvyx3KYFEKyG20AwpZ2/RNXZKSUZx8S3kp1Bj5wQNIB1MBb0h4DzQC+ S5kGMgADH4BRZjlcjrwVmJRTXhopvJxWBmxUtJUCK68qFKhQ4MdIgaGFEz/GngxoM76bSQr4IUi/ YV8KgLHklSOTBQ4ac/B1QNLBxGARNyQE5cgGrPTkRYvNZaVya9pPOv6Uu+54FvZW7Obm9678wwm7 Tc9upnATKrZxw95HnvDRmtUaLvEmkFXANWb8z1NS5+b2886/0GSBnzAdmq28nSlqSqDa7yzZr0vC yCG+XxHQBjQG/JOxCpMUJBop6BQC+QgeHANtyDAYk6QYyEZPK8CQFAChSDqmCgIYdwSy/ePRyEJG Z3CM7CA4obaBDAB5SSHIAtjIWD5ew40RSTeKLa/CSDQKHAAYZQ4A0CQjpbwNJHt5C0mKgTwAwFsU RXAMgCTicXDAKxQOkuLTHwEAqWswJknB2yHDgGYYj8hlNKYcNhAGAMPVSwoZHJPsyAWAxMan0XBF VdIrFKhQ4MdLge1WXwondBgVHNVhhQUXheUYHBWWM2i6IL18pSOLHV7BQjrYFwBEKIXleyvjag3Y LaXTO4prqj/5hKM/X7UaT0VL97yPF67OxwvpOKU7unE1K1TYddxEq5zgXS7IpXIFycFxNOVSOEe2 ZDEG9wrz8VCfR+Da1q+FU1VY9MEmIkJ7N15qLQLaT/YV0hikGHsAeYV0pCB9K60d/Ir0enA69kuU ZqQTGPFw+AbmTwQgpDCogUcyCmCASCLhWkAN8ggEBMAkLgcMHAB4S2ICGHlJ4Ug0mCHyiiADBgJg I5SXb2CSt+SRlE9SACM7QnmiUZQBGG9RAgKZIUgkAWgEwCsARq4BAHllxAYwAM14RC2kYYiRSLqP 2EAYABC0AYlbeUQDytuAxgOZpAyZa7hXpVL+eezIIynQKBOPCOTnPGT5lcQKBSoU+FFT4J8W4h91 TwY0HisXUsBF4dYVuCJoB2O1xS2tLeKekrwHgQh+CAwE8FIkFzLiFeKtrN2wQJ2GkWEgZTL7Td/r xbmPyFlKzSVe6opTYv0Trz9HsdZPP12y28Q9x1gpvqNrzxmnmk0jL/3t5YvWUzDOB1fzNMUuXrLU 66raa9ouLz3/9JiRLVaLGUZ/4OwN7hFKS++3X7SohDwiRpMQDIA8/l/EpHZUXQlboQA2TswrIkky YgPAKwSCg9gAkEjKJClbsL6JMFeRnZRA8m7J9w8ehTwOzkjyI90ouTzjkLmMRADlbRgMG5gGKYzq BgCD85IUZEQhJDYAo7TBANgO/DBJbABb+WAYrt7h0o02GF0jwHD4W0lHRrw1shuPRhakoIPkJzy4 p5WUCgUqFNgOKLDd8lK4qQ41W6xiuGmFVQwwtFBxCQvLMQLhnwwAj1j4oL6KmAilCCeBx2HHGO5F KUvJsqfVusPUnSkqp0lUZ9uKpkNmnXfb7QuWfU4Vknc/OOey311jVqjTd5+489RdO7ve6u7tv/ve P1kprrO7V3B6Lvr54a8+9/Cvf3Xa03MfjYb7cpk0TDZA6SocjZLdlCzQqIQsxIjL12WDhUJHDHgA YGQcAAxAG/BoIKNqUuOwdPiJvSgfEUIcsmUSMpC3SCEsEWKk4JHEBmA8krxbeKeSg2oEApN0EpMy SV1GRjI9EA+Xy8g7GCAFGkWV1zUYNioyykHG8saQ0vDWAAYXYrwlOEZ2UhQh3YCYTEjyOyUxSRmA ZjwOWelWEpFxyMYMl4WMy+AYhZDekYwDHg18gmO0tgJUKFChwHZGga0dY/2ouwqbPWAI0AUswbBx ADkT2KlkMgnXH6Rf5ewCQQOzBTScBiILYDAoWAqHJYINvBQNnSzWaackrqWl4ZWXX2lxfzp12uE7 jNvt6dtu7dy8eW1XJ9dSu7q7/YMw9eBBP6utze2+x153P/95gTrc4/O3Jzs/CfXvadkwY/rer7zy iujg5KIFzrYykuJ0uS2wLbgloJ1kyyENJrDxCo0ctoVbXmARHxIBfRwynRCN1GUglFdqJFYAUACU IcGgJyE4Egl9DGAAuQy0b/J/y6AAzRiC8vJJOeWvCAxeykgEQAIyonzAyIW4vBzyiJTyRKANN9WN 7AS/PCYt/47lAI1gkph0x2jelpf/FBH6oHZCWFIXyfVPeN8+EPxvn/7xfytZyCvEBk0AD1fOcOn4 ARrlGACqH0BPo4p/tKwCVShQocB2RIHtlpfCtyy4IhzwQdIDC0CQToGjgskDpGP4BixteIRmFVyt QTRFFF2Bg9UQ6WR9HGLE05TX5ZM0ikV5qnTcMYf/7S/zPOaXj730/rHjq5Ob25964snxe+/R0EB1 tWfh0+CQfXezO3rzGWvz9PMslDWdywe4GhzlUYxipvT6upo8PN4wnA12rlzeUCQm2K2oHSt4eVPL 22OkE2C4dhpoA7qw9XTydjicAUX9BB/LKQPKI5AUAKDGloRvIqQjlCOQR4JGYoyykREp4B6QYjBn pCCkI5ByCDLKQYoxQ/BosB2ASXp5IaQWI2VLed9EKBBvy1MMmNRCakRiOUBgxOXAcOUY9RLk8qKM usoB/PqQBbUbDUBG0qlyNAM2ijVSCLD19hi5ACCgruHwh0sn/UJeUh0BSmVtCUZjtvTjm74YiRWg QoEKBbYbCmy3vBRYIkihoAIF9ggyKsRw9wGlqOHszeD7EkIpMFtgub7L6BZcXcViLY81FLwUH9hn uuuWux6klJ/dNNfW4urdi0/cfttL5895OlvMNBWiMPz3Svvm5loGLmmsFj2b6kn461LujUFmc7cs gttrT5tzFoE20ZyViUfDMCUMo5FYesl2gvZgZcZqTjYY0jyklLcTPCJJ2bKGf7OjA2G4PYCkowrg kIWeAKjRKAcp5TAeK4EIAg0iE4KAgIPlEIS25RQziIlXBMZbAAb9y5HLB25wUSQj4nLBZHmrjD3e qIjUUl6sUR1BNh7LASM7STRaQr5JymcRMMnnB8EckHFAvQO6DOQB+GQeokAEoz3IRcox8A3gO/5s jaLK20MKISlbIYWRtxwoLwfphD7lsYFsNNVIqQAVClQosN1QYOiP0e2ge1hbiaFzGEfAege5FACi XDJcDPzOzk7wW1j1jC1zOFLkKMkGbqYAz0NAKe4zfX/4fhgzqbW5xgnF9QMOOQipTXV1tSZH84iR dotw/q/PSqc08DjLvvyMFwOSpKS70y+/+GeoZ82bNw/mGMDkBQIBqHmhGUTTiyy+A2L0ZcgwAO27 PKKFQCMdJEB5rvK3BKcS/6coMIDO/6lif/By/pv9IvwKukyA8qrL4R+cJpUGVChQocBPgQLbrVwK rAk4EnxlQiiFMz6YSADXUv6NO2B0+/v7YS6BuKrFK4JJ1KcGYJLHImUpsSHgRYuUkszZnL6Rra1T dh7VH1YDfseYnSZ63u6evsdIeLso6sW3v/wicNixdcFqXYruP2Pvd99/t6ibLLzp2blPXnv+5Wjb 7NmzweF1dHTgiK+rqwviNDBMKB67AqnO2B5IOkksj8uZP4JMshsllCNvBTYqKs9o7FtbyVh5VaHA f4ECmIqYmUaMGo3H71X7953S3xf/ezWmglyhQIUCP3YKbLe8FDSliOYT+KFVq1YFg0FonSORXNMb PGzwVvvRRx+NGzeOGKYCArgTlDAYk6Q4qZKdqpJQSqGszlqKcn7++UK3gEM8WLVKHnvZxcdedFuW LVmgsjM81eLr3rwsnZKcIptOJVVFGzdmUjaRxqFItC8OZ3DgoiBIg58QCKXQALTTOEMhhw5goQiX MxwvVc57EUw0BECpPcMEYxPCPoFAHo2KjELIq2HKqCRXKPBfpQBmo1EfmbHkEbCRXg6U43+X9HKc cni4cspxKnCFAhUK/GQpsN3yUgbPBL6kp6fnf//3f6dMmQKpDyx2DjnYn332WSQSIRwMuCjIpcDE bEWOlSkojKnAsTaqxG45M+mQW6jOFiiLTNnEKi3fabEEYOCctevxWNjtHgkplstZ4rREp5M0gKbU ZDTGcTw4to0bN0JrCjVCBR6sFWDwNFi+kWIwSYTLIY+Du0DeIt3ggYbbXYy8KN/YjQhAsiAmwcCs ABUKbDsUGHLeVnidbWeAKi2pUOAnSIHtlpeCdhQYIzBDkPTAaTE8UH788ccQ+Qynowqp1RFHHIHD NUwCZAQTAxZnK2d8Lptny3QpaiocldMOoRqPPMRUJfUpc9EOr/UUX3KrarZ5RhR1Sk3FrU53Jp23 2uw4vsPNPotOeXihYLJCzRzMExi4aDTa3NxM3CpDbQuZwdMgJsDW+ZvheKmt7DEo0NiWDIDwaqQu o3bylrSkElco8ANSwJjPZPaiJQTAD3bIVg337WGUMyCXMecHpH9f/AHZK48VClQosH1TYLvlpaBs jgBmCIzRLrvsAh4FLAuYFcItDR5UcDM1NTUw5glFK2QkR4RbOeODmpSuwwOx2UJ/44heliSGNVES o7AZ3O1TJFWEFxq4r+dozcxYnSKlyQ6hZN0TQS7oWjZnZ8w4zIOmFCRne+yxB6qGshQYvlAoRORq xsoOgITh1nSDB0LhBJMAw+0xpUYMH1DC8C8rbyoU+MEogPmPyUl+BQaA1gw3z7c1XspouUHBwSnG qwpQoUCFAj8WCmy3vBQZADBDZKkCqwTVclyUM87+BowQ1lwsx2BrwEjhFdDAhCHvsOyUqaRQBU4q r+bMFCeDZbKD/5AombGyditltvA0BT/GLg4m0XMUIyoZylQqOZ2jHBzFWM2UIFJFxaRBgibBszJO GFE1pGjhcBicH7g6IBs8DQASSHcGNN7ABA6BBwCD8ZGCooBGCiQAyUWQy+Ehs1cSKxT4YSlAJjBp w3C81A/bwuFqH+5XPBh/OMz/1M9zQPn/qWIHd6SSUqHA9k2BHw0vRX7zxJYmTu7AGwE29MQHDxIY FMIVYXVAXoh8gEPUusEnYeUt/2AF24RHZIH2NymKaKkPWGjKa4EGrGIxQ1fKTnPRTMorihlFp4sc w+tmCrf3HKX6XIRf4WyyrNMCEtAUgSu1R8OHNP5TJXOgYNe6u7vr6uqgKYWuoQ2Qn4GrK+FvCaRe YCL8X+8ZgxdTVIoGkJi0pDwuJ2N5+rYGD3e2+2Np/7ZGz/9se0oz+9tpRgCUj6FBMH4CW1D+oXhO GmAk4oeDbxsEkhExeUQJBHNAjB8dfkoIpDrUsqU2M5YCgmn8EAhAkBETTMTIiCrII8lLMJEdryAR NxJJutHUAS0hj3g7JL7RngG5SH+RizQAMWkhWcpQFFIQSGNI1SSFoCEdKwwCFj3A5BWpguQicCWu UKBCge9IgR8NL4W1AwFrBGKsUziwa29vx1oAeMiugpECswW+BDjQQMICAUYKiudYQ8FL4RFrCow5 4cgPb2GiE3wMErHoYH0E44UlCTCyD7cHUwyNVygNTUKWPnMvGpfN5SxaKRc5IkSZqBRV9Pb2ErYP VZBayIqGKlAIApgnWHBA19BsNBgxShiyX8g+ZHolsUKBnzIF8FMi3d/yCytF5NFIH0Ac4wcIAK/w KyYAwUd2AEYhA/KWPwLNCCTdeDRKRjpJJEB5dgNGXd8LH8goEzFpJNpPHkmMYpFCqkMKAUhdRi7k RSCJlbhCgQoF/j8p8KPhpfD9BMYFCwFhXwCA+UDnifBpSCpgpQCfBMYIyw1YE47jkEK+F5EI2O/3 Y8UB2wTjUnPmzAF/Nn36dOgtkQM+vMJB23Dl57M5MD2aokLFnWGscKMHqwq5Yg6lEbkXqiNMG/ik 6upqGGFHMxBIU1E7AnpB3C0jF16RBREwcPB2yE6RJXLIVz9IIrrwg9RbqbRCgQEUwFTc8gsrmV8n AGJ85wxAI494BXwSkIKfm5FiIAyZcUAiShjwUyVlkgLLkb+pbJjfC37XaMB3x0e/UIVRC2kGSRyy HJRMlheSi1Q0ALO89gpcoUCFAt+LAj8aXgq9IisFWSjB4uCYD6sD4agG9xnpsNIJXgo4kAmBhUIK +BssOoghCoKMCg74oPSNct5+++2FCxeWXOG5XEDGcoO6IF5CXQAGF44Uq8Xi4HnIojKZrKqoNiuj FCQsySgNKxQC+DOgtbS0QP8JnBwYL5JOSiMrGhoDfgtVoDvgEYGAFDQVKah6yHqBMGT6D5W4rbXn h6JDpd4flgLGPCS/MsKaACZfJoPbhp+YkQVvCQx8wCQmWQanDCiKZESMXzQpBzB5LC+n/NWAEozH 74WPKtAFVGq0kCwpRopR7Jbm/EMzkqAhEQjIS7IbyBWgQoEKBf49CvxoeCmwOPj9k9N9Y9XYSp+B CT1ucCpgTf4fe+8BIGdR//8/2/fZXm6vJneX3huhhQ6B0IuoIKACP0ClRBAQRcQgooAgiKCoiFIV CyLypYM06RpaEgghPZere9vrs7vP/7U38Lj/u90jwSRczmc4nszOM+Uzn2fm/bznM/PMrFy5kg2c mNFj0g3WAmHCA52CVGGgwv+73/0Ou9HRRx998MEHQ31gUSQknOk5AKtqKTazRWLnBKNqNZkZBZNn JBLFD3sTCdva2tauXSu+yyM3wjX8EuhWeRU14gWAQ6SyxatGuSKTqiLpgboGdA1soQboccSsZBKi P4pAwumJlXc/NlvRMbmSs5aV8JCPFiLKHZqbKGvL45ODlice8VMUrd2qLLeyLiIhV+LXGrMNlVAP 0TWga2AYDew0XEpwC/o/oIADBWBL/IR2VK0e3AtWRATAYs2aNXvttdesWbO0mBiKBFvCFnXNNddw dMz8+fPxk7PGZiBbrLjip5aq0gNtikWjjHohXtixhLAVAAAgAElEQVSiYv0RjFJetycci3BkDdOF 3OKzQSgaAoh8BgQvD3yRSmSFh4pQNQgfxRFTVE2LUFmilmRo4KcYMoyon6JUetH/axqg44gq0yBx dCvhhteDlopopOJKKgLp9QPZfIg2w2QiKJeWj8hExCdQCxeeyrtD8xyI/mEttPi1kmg5k4+Io8Ws mk9loCia+FqSocLoIboGdA1slQaqE5GtymLHRNZWEdH/wQVoBygG8NUqHfsTZAsbD8YnmBOry6Es ZAL30qYFIU9sd/7EE0/Ah6699tr77ruP7+mIABOiCBETylW1iFKhaLfaPHUhYnIi8gknntgfDqfz 2br6+s997nOLFy+GG5GQmTuB6RRdCWcikCsRiKaxKKIhNqLW4ogjDf5GmjxVH5Ye+L+gAfqXAAS6 j/ALT626i/7IlQgCVbjixE/hEWlFnKr5CC7FLeKQRIupcSw8lQm1CJWB+GvFrxSjMklltuQ51FVG 0PInN1EQISJJZZ66X9eAroFPrIGdhkthZ4JngJUCXCpBoWrlsfRAU2BRJAFSsRVxhWBxJRyOBWGC Zt16663EOfHEE5nOg1oJBkNZJCchgYISVSlClXLZXEJKAEk+r7eQz3/v8suxfj3x3DNXXnkl59Vg 6CJn5hmhbuAXRWt4h/BkjsPDhCDhcCmKFh6KJj5yVin0o89zqt7SA3UN/M9qgL4j6k6fEo4ehBNj lapqEf1RcA46o8iBtESuvFZNqwWKTCrTCr8WLn5q8Wt5asUXklRNVZlE+IlWGViZSlAochM1HSbb ylS6X9eAroEt1MBOw6XgJcABDtoBHFA9UIOfwGWtqsK9mH2DMxGNuTasRz/60Y+gLKeffrqY0Xvs scdWrVo1efLkY489lnwEkQJ8+bYODgSLolCKq5q/1WAxuW0Fe4kv8cyxTKPNMqZ1jNRYd9r+E68O jYu7x6vxrha7ct0v7rr+xl+6Tdklf37o0KlHutQnf3rTxVNnXvzAU39/4qH7v3z8VxadctzN379o 5Rvv9nWtSlgaNkUUvztkl/KJLBt9VnEIKQBRoKFQAtegNZRV0mklZbBKBqtRUVW+BizyXijkzWbT wBullMmk+WMdiN1us+U5m5nXD3+sds9KBsVmN7EGLJctv0uqOg2m0afmF8+iavwRHogCqcUIF/J/ RDzRnCorKwZOVVuXeGraVXiEsVn4RdegleIYNVVmq/m1nLV+JHq6aBXkI5KLDElFfELABAzVAnMY aLGKgJ/cEpmIvsldhCcyqQgfBFC18ESAj0iiCUnpteILOTWZhQD8pGjWbjIeE98g0/HxIwPyYH1n 1SY/kRyZgUTCkZ8kaImy8DDkIyZpa9nj83FbNp9qGhssGbOxZF9RKmSVrNvjsWQ+PGZUE/7T9Si5 8m44Qj/iEQzAoBTJLnW76kpFZy7HtIYxyybLprwv4ColP1159dJ3eg3sNFxqazXNTBnQgAMaAAgw hSNi2PKAZeZsf3DbbbexVcEtt9wCZzr55JNBH86/I6aAJA1ANc/Q0lnJrrrN4e7eKWPGxCKburq6 gCefz/va319XejfbbHaHw/SLW66+9Q9PPfTUP1595A8Xn3Pufn/bt7FOjvRFvn7e1y/5/reOWNR2 xbl33PXMo2d+btGCeVNj2czmcIencbzNJCX6etkZfWihhCChEFJckVB4YrlIJpsxs2xdMvf3xtiQ PVhXrxSKksmSgWKV0sCliRlF1W4zWT0OTzge8fn8rJOHbro8no6Ojdmc6nCyd3t17jiMKqrKqQfq GtjeGqhsk3TebVIceWquMsPymshYjBWQAAV9H9yAcAh2wgtbQMdH72wz4SBPZfKP9VNo1ThbWy/i D8BeeTEDjmwJwcMVulkGAZOJioCHmOEZKxIiIlA6NAtHCIBZVRgCXW6D2+jq7uzwBjwuOZjMpJtC YzN8wmwp7/k5cpw/YMpk4tkMo0TJ6mDTvvIX2am84nVMKOQLKMViLhVLhTqXS5VUMNllZ4Nl3eka +OQaGLVcip4DyQAa0A3owE9GY/vvv/9zzz3HaXesjgINGaUtHHAbNmwAK0EckuAAIIjR8Eptamrq SHRPmjQp3dcHSMHGzlu8OJpMtkrSz+/52y677KJ2vfLg3x4+66zFACufB171izu71q63JjcWssVv XnDJkYccXhfYfLX625POu+CEo/Zd+9pTkmx3Wh35QirZ1xfgZGTsS9WckFAbCuMBColoC5jT/SWr bE/Fs35nyGZx9KzvbWpsKkpZu81eLHAEM7uPSlYDx90ovZGY7FMLxUQ6G01lwn5/sL4+yAxqJpMz marbpWphfTUZ9TBdA/+tBoZvb9wVETSPsEAMLVVE26pwLU8tLZ0OrGDqH7sUnZ0jCkAP1lYCL+yr AiNh5EY3FEYd/MQZsAQPLbZmiFbWoBiA0qCQ4X9CpMSCS5GhAAr82JmEpQo4wkMmeFAa8UUc5McJ eAEwa3HBbK7H6w3AzQySTSrKxqJsKJjDXXmnKzS8YDv4bjwVZjxpNHoMqkHJlqvFCliDwZ7udLq9 JqXYmy+EZaeFqQclZ/HJoYJafW/kHSy2XtzOq4Gt66g7UT2BA4APRAAg8AOFAArDSlaFX3LJJUuX LgUHsVQdf/zxAmK4K+CPXicwhcoKPKpaa8Z2Dpezu7vHqZbYldNoMH7rkkvyfs9PF1/AaizKXb9+ neww//RnN//0F7+zFpKSVc4nkmNnj+3Y1PW5E/d0O1z8rHe5xkyZnihKcaWgGCTVKJnMks/nCNiK vcnq41QBdpUiEcLPjt6N41on9XREg/4mJVl6+R+vbFy7/vVXX0uWN9KKEGXChEm777bH7NlzWtva WxrtmzMfJJKxQNCd50zmXPlE51LRYJQgcOUl87rTNfDpamCYrodg4i5XzUOfrSqwiDD0Vq1w8tHy rEwFp4Fz0JcYkhHOXieMvug1HKP5wQcfvPHGG1wxWRGHu1yFpzKHHeMHxGBIlM7oEZmF2GAdsgF3 0EGOJeWs96lTpxJIHCorRCUhToDJMKI6POaMknJ5/CaTo6dHeemVN1559d/dPb2d3dXt2cNktV1v GUw5qsbyMIaReDDC1YXqsMQftf9B02YGfEF/KR9nJ1e7RTar9iK7Pte0xG1XMfXMR48GRi2XAhcg NDiGX3QkIBJqBfbNmzePleYPPPAAIaeccgqYAhoy0AQly3xiAAq5JTwCVas+7TJUmayyQ3ZyO6sy Yzh12rQx82YrJ//tKyd8/v5X3t5z+ozNmws3XH/d7gcdOc6jdmdKapevN/zvQH1TZ2//PM9sJW5S FebfyoNaVsFjcU6lk2a7SS1kN/V223xtVcvVRBKox0/h/B5fT2ev297w9r9XPnT/I50bOmZMnXTW GWfO230GOy3ApT5YtfGBBx66+sHrp02dcfQxx07as9FmTcXjfYxObXZLJNJv4GhBY/l8Zt3pGhjJ GqDBI55o9sLDlT5bVeaPJQeDUol8tCIq72JtwvIk5sgw84AAjzzyyEMPPcTB5HvssccJJ5zABy7C PKbJVpl8eH8tOYUkw6etvKvFhyrhh0txlz1ZQBggDgxct27d3//+dyQ/4ogjdt99d1EukYHKAer1 4XLMyjwr/TmDKZYqQNhefOFf9/3p4YbGsQcefLjFZp0wpbky2qfuLxVZDkGr4BPpsieZlPr6CmwB eOef/io/nNv/wCmHHDLHaC71x1KsfJWtzuonkX3q1dAF2Hk0MGq5FGQIKAEZAQhwBDoFzIlR2oUX Xrhs2TL2lDruuOMAF7ZLACWJLIZlgAupuApUqoVxZSN/pMfX6E2E+9g/qr6hPgwnk6Qzzzzz7mXK lVf+4PZvfv6MM46+8OJv/t8/9l7V3ZOxyo2WIKJkJKPV4+uORpylfLGY81uNtmJezaTzqZTb0WCU Paac0WExZtTqrAapEInaaaCPh0B70VzMll7852v3/O6vs2fMu+SnF2Li8vg5z5lhMqvQpSnzx357 7jkbV2UefPDhH/zwmtO/ftpBBy8oKvFUIe32mJkC9HlD6VQBs/jO03p1SUetBkTvq1o9cUu7Ck+t florny0PFzlzBR+QBzM2p0UxrwcjAUbYnQ5swXGLXokT9KWq5MME1pJnmCTD3ELaQRkiMFQP4fns Zs8993z99dcffPBB1jawQbFY3sAtGJVAlVrKpMSU6vU0On9+ywPLlm044bSvjZ/UwFnuTc1SJNMz jDw7/pbFEBSH7PAVDqpwuA1jG9UxqmvvA8587NE3Hnnm0TUdm7900nEtDQ2JaMwg81X2jpdRL3FU aWDUcilhvoY/4YEwAXDYt+lUOH5efvnlhLMfASAIcAA0hAsQFDA0FIwGPfZYPO4P+Hv7eiY01G/q fBdL8sCSTZvBaDj7nLO//bXzN5y4x8knn9Jnaz3q8MNMuXjRJP3ljhfn7yav7epSrBZfY4PSZyyy 1iAV8xocBo9blgyJbEHirGTJzipyg706l9J4nsC7gQqVL+a0ddO7a35z0x377Xf4qad/LpFRxrRb 8nyt09Efaq6TjFJ3R0otWvz18v4LD2TTrfvuebqoWA84eI5VTvdHO8mWyT6TqTxBMKim4ifqqhqu B+oa2B4aoEkPk624W273H9moRHcYmkSQg6HhIuHQ8EEhWrYQDuAC6ABG+DQYIsJRCqeddhpTZiQR Rh3KwsFIBOAMymr4nySsGgFyVjW8ViCWM1gRuSGnFofBJH7kpxZ4kB/zPJOVfIjD2VmzZ8+GHdLx KYv64vDU0k8i77zqujuKBcdJZ5wfrJcUm8Si7Xc7e1zy1q2112TbTp5kYi22Qw6wkAxqLp/n00oq yGY4nb2xvY6Y5wj6X/zHS/f//Y1FC3cJ1Rky6S63SV97vp0exf9KtqOWS4EIAp7ANdYKMI8mcIQH y1weB7xoI0hQA6whGvFJRQRCBIThESFDm4PT4UjksnbZDjC1trXd/9f7VbY7T2fafL69957+Wken Y8MLfrlw9tlnn3TW122pzWmXzZGdYLSte/zZZ9dtmhmOx+ylwiv/evXNvGqJd5jy2ZDXJxVdWcli tpgLUrI6o6k4oFSIhISIzXXjyo13/uruA/Y66OCFh8fjkrvO0tWfMNlyNtncH46qJZPFbpNUazxd NFrNM+fOjiX999z1N6/fOnuXlnyu4PcHujsj9aExkkHnTEOfth4y4jRAm9e6wDYUTmQ7tNdDUBhO gCGQFXb3Zb3UIYccwgoBps8Yg/Gehk4BGgI3PplpapvUAnmwNiFAe3s7yIDYmNMYMVIvVjtAp7jF hzLICdlitQN0CvSDV4lBFNGoJnURRrhBInHriRfe6U9Khxy8yFMnRdISQ8C+/h63VyrERtYcn9sJ wZVSLLLny2QjY0lJyanppGIP9a3r6Rwzvn1G2PLiM0/7A+4vfGGX3nAXXygOqqz+U9fAVmlgp+FS ECBm4sA4rmAEiAD7IbBWbcECYopB5FtvvQUCHnjggSALwMHAkVSkBThADRzIwurRJ5988pxzzsFP OMgiwEWA49BSEmpW4rO4ko28yocYDwxPXUpxo7nNL6WkyPuSu6GTcFVymxTJE7KzBsvRG086jGlj g6VTLakF4+x1rFHIJPOSvc9UvzFNgVmHKcInuw6vXQg5tFyzPcS+V7JDCvd2uBwOs8FsMzuj/fF7 73x9xrSF02ZO8ngNqWxHg63puSeefu/9FW8vW5vNphYeuP/UyVMW7LZPNp235gwe1b3XpKY66ZBH 73xm1ynnuS3xgpL0BXyZnMXprG7sHqpqngVuqIQ7SwhPeWcRVZdzkAaGtr1a/bRW+KAMP/YnrYWs IBN8vscEGTNljMdYgSTMP4QTAScGNuSWLFlcmajFxEcntnfeXn/THX+5/Rc/4QR0jyHdvtvXv/uz m3adKTWVNktJTzRtVlrtoaiatSnhYszrsLkK5kJSKbncKasxle8NGbPmXlY1huIckBDYkIynnKlp kkcqWt6WcpMsqqyY3vU6p8U6JUewx5YpnXH6HhN3/+YNNywxq+tLecVhmZhUum2SHyERD9kYWAKe eADDQw899Omnn545cyY/MeSgWKoJ68oWHFaDtZRj27lUwdSbh2IZGzs6jfc/vXTunFkFp9qbzbkc hmw2ZylJpZTJIFX/Dq5UrP6KSRUtPjXjL62WrfYHHnvjW5ddZSpsLGYi+51y/YnfOjgQmmPtktrU pVde+KPPnvNrz972fcJ9j7+1/JIbf33xpVcvmD01HstY6k1xc9KZLlvahjo1V7aTlXu4KrF2Clf+ 8tAqZdM+s5qLZ1PFkNs1f/f7Xnxl9/ljp7sNyepb0JTnbcuJhzheQLxiUCkenjsqFW8c1n4MiTsS A3gh8n4UFgSqwHMXbXgkyrqTyFS9oY9A4ZmG48EPMJzyoXU4/FxriSrwgp7A5gVz5sz55z//+Yc/ /IHxGSMzEIS0kBUBjqINYatnoMnnftylbdHUGHqKb3ZqFbFV4TA28QKgUBANPyEULb5MplCAjOpQ tOB2taoGCvJpSkk1QG7IhxXrLBtdu3Z9pD+29z77sBw+lci2TWxZs3rdFUt+tHb96plzdy0o2fO/ /TWvOXTEoUffevPtPPK4lFMc9kDALzuc7763cuouARAvn2GacqdpD1ulfD3y6NYAvWl7V5Ai6KEM xtasWeP3+4VpB0QCKCha9FaumicWL/gbfNLmrqVvvnj4F8/tieTuuu+BqW2NLz/9p6t+8VbXpm7j zDrJrJYSUbM9yIgwlSkYbQab2ZBKxMu7ANvleCaVSudcvpCpFDY5Snyc62kxhtWMw+GzFSTVLPXE Y05zkWWRspPNriJmq5/95CxGE8YzZreQire7WgYJiQ2OS0qZCAI+QkgBR/iBRL5ufuedd5j108Zv RFMNWYPRhJVaUXJFFgeU615csWytL9RodXnyEiSvaLRwrjsUxcIXyIZirTnK6uFZ+I3V6HD6rvz+ D+++86lxux+4+GvXSJlV3zzrnucfu/bym19YtPuUV1/61+Nvv7hbqb/FGVrzQeKLZ5+330lnzN5r al8P21zJ4URM9ZmzLNeq5gZMUVVuRHMZNVdMpzLZksXhC5gd7mUr10yYV6eat64JCRinAPQLaKPq srZVVZDUKgWPsCCIlBAe+WkYOCEgb8YRJulOI85O8+6kpaJUOr+gQTRZHj9ttwwV1RwxGSLAqIjA iS7l7aA6OiBMsCUYEqiBMRw6Iig5mdM3GJyxkTEDTfY7IGf4DZngqZb9VoeJgsiNPBFJy5ayqAhy gm5UTUQgDq5qGexRjhkePsb0okGViopaUEtvvbVs/PjJjQ0tNgdzDbmuzkxTY/sN1/988tRJdo99 44a1v739tnvuvOuPD//xJ9fcvHF9r8sRcLnkhgZWzDf86/WlcxYck5MUxm980KeWqpdbVRg9UNfA p64B0ZVq9ZdtJR6lQJs2b968cuVKPvtlHTc502e1d+dAl/1Pt3W7fOGN64M280Xf/k4qp/zpkUcX 7rvAlIvOmXnOkae0y3VSjq3mrEmzK+QKyivW/6vNsytvsWIywVf8itFDB5dltuvNvbdWmlhvcBT7 49mEIe7KWPMuuzeXkwxmdUxdY0Fx5FJSOhmzmb2ZJN+aOKRkCnoEoPGutJvL8KgUynJKAzN3Zc8A igrwRFzAcNy4cW+//TZb4gkuJVBIMiZLmHUMnDuaL6olq9ORjBeW/vt9b/Msk8OTyKvZeDZXKi8c YC8Xs1KSCtXtN2qp+joqVmb2xvve+fezd//5r6HdjjhnyY/HtDpT/Q2/u37GV3/w+TUvvxxrn6LY 1Zw59VbHcldp9skXfUcaM/7AE0/uLUqUlk6pkXze7nSmM9XzNxiryxPJFY35YjyeT8Ol/HXOQP1r b713wPT97NbqOD9Mu0Jd4DYvFK68SnhfDKi9zFFGvqM9i9cQFaQi+Bkq8BLU2vPIr8JIk3Cn4VL0 cJ406tOICKSHdiD49VC1ClJC42aTYhCktZVFTW2sbSIETKQD0IAgW+RATyCQwRybI9CeQBl+clcY seBAQzP/ZCGIJKSqTI5dSjRlblFBrtzV6lgZU/gxRQ0wMc4WtCqsVZf43s+8+oO1+0xewDDW5Q25 nXJPf49NtrU0jy8o5aX348ePnz59eqLU3yC39fWFGUQ5HU6Dkvb5PG1t45595SFGlmpJYtUHZ8gU 8jqXGqp1PWSka2CYd942EZ0uSVfiTcPgBxMOQCH6MiGiaK6ahxJzStxhkvojkTdXrDn7W1cccvg+ 6XDKXshFiinZWuhe0zd+Yv7Gn9142aW30d+8DdJPblp20D4tbrnw/R/+wBWcarX6v/utc4JO6Qe/ 7PHsmwnZeksmx8UXX3rXfX+SElLQvu+by/+ULnY++8Qbi8/+YXfy7fHtEx554INYqXt8vnxQOkjC fpx2c8aimAqKlCmlHMYysoGE3EJOhMdRKRhAQ0MDXAogFVgnwMdgzHIau4mTskwGhZNiFEMqWerp TDin+VSrjRlIZgoxRclFTONsjVdig72qembwWDU8m061+nJvv79ScnqO+eKZasD3ygebJ7SOaZlk mDJv4r03X7/vPodG0zEpmZjaWHf3FVesXrHh3N/82j++/d+rIy02j5RKGpyWVDwvpaqXSxWrl4tB L19IF6UcclmN3vrmDUv/HU2pjdWnCj+0OA7NincHL5Hu7m64dWdnp3iJoF4axtDIIzCERoJUtF7R sLlCB3lXnnXWWSNQ2p1CpG1GFLZ3bXnqcA76v2isXNl6DtKDq1o0MUEHERm/gLmhMUU0CA1ziOyS QATM+PAqgZvbsGNQkKBKtFocP+l4ODqkcFA3KljG4/+/4WqQzDYrewYSrcTBFSzVMhktFoMtEc+M GzfW5WZf5ixIGQqF3G5DKmMzm2zpdLSgGO+++26L5Lj8u5fz7aFbdvV0ZmRzyWqztrSMVfIqaItx i3NvGGkPKk7/qWtA1wAa4N0DRHAFE5jjI0SAj+jU9FlCKnHGYualbXrng9XRorT7vvtv6so0uS3p rojc5Imt657a4uvY+Ibd7f77Q49Obm+67bbzvnzWRauW3m1KdWbi/Tf8dMmc/Y585OG//O66c8/5 0uL+xJ2ZyLJFhx29YnP6xl/+bMHc/Te/U4r0dqd73zvjtPOXXP7rRZ9r+dY3b/rM5056/t8/L27k m9yyMCyIYvafT4U5mJMzD9gyBVGFtMhJBFAI8sSVlyjf8YF74IaoyAAGMSeYY6aMozuVnJmlNQCF zea0ylYzy47UAgYrVTIVSgYlLwFtJmt1zlRer1TNBev8kfDal1971eT2Tpg2GzrmDjVv6F5jbFAn Hjj/zX++bLRYmehkFdYjN/3q3Xf+ePbVT7e0Tt3QGbPa7bF0ymezSGZDLJ2wl2ptslldHtaXYkOz 2g2ZogFTvNfvT5jtyfRW4x60A+3xDlqwYAEjVdAbdoVia72Pqung0wyjJfDoeePw9IUc0EH2+Pg0 ZdrJy95puBQoJviHICKonRHVMMrXmjVNhCTM6GGOIhPoC61H5MYtcoBIgR0iNwxXrIQgkBDY2zbk UrVEHWSXKqPYAJeirVdNYrEaGRAyCBwARGY8LSZQ3WxXikmLTbZb7JJJNZkNmYzEIYShkCWpuH90 9VVvvv3mhYsvOvLII/niKJko2GXZWGIHBCNbjfIRT4k1qWWrFEO5MpmrWu5oDRxQ42it3P9QvXZA u+XFw+sToBDogR8HnoiiuWoe9M7XbXyZUt/Sgp9FOaw3iid6Q15XrGR1202ymm3wOr98+lc7OzyG XJ9NSUtJt8XqaPTXbVqzau8jjrvx1rsnu3vkU4/78wuplatXpruXb+qI3njDnw878mCLIdvgNLcH XNffenWpkN9zzz2i0eWHHXHkhY/e/v7qdXs5HMAdtmdekchZPirQwip1CwsraeoaeIqWwc8yvSqV YIfAHbGpAsNIwgfO5cR0UeZbVtWSzJWXe3q9LjiTU2aVlKVUMMkcc8dmmHxHo1qM1uqcptZcG0zN KBlYkBUKBH1O1/o+iVlTp9ObdScDLY2S2b52dYerzS45zUtfe75eygcs/maPO5/JWW0Wu4FdNkuK pJqgW5bqnx+pNdZRscG5as3bDKyqxzhXNFmNAZ+PaUyqXLW3iGda9RaB3EU/vFlwsCg0OXz8Wvns +HCeNYVWoh+SY3OFHe54YUZHiTsNl6Kl8rBxosnS82m4tToAzwbgo33jEVexilygiWhGJOenYEvM 7l122WVcFy1axGabhNNDtuHCc8RAclGuaDf8pAj87NcAz4PVAcqIpMUhgog56AqGFBgn2qwlVjaR J6hSBIM87LdZplOsonLa8qVyXixKjUTyjzz94E233njyZ068+KKLSnmpmJMSyeT4Nl80zE4K5mx/ 2iG7QUaTXc4VcyZz+XOkQSWO7p+VaDK6azq6a7e92y0MQ5gc8GDwFgsMaDwiEN0igHBCzy3NDcZc fPmyzSbZ2hOJTSsfD2W0W03rksVJnmAxssZdZ7vy5l8tuew+nzE6vz0teU4HA6RouCHoD46b6W2w FxNKrGuNZAvJLouadLMTgdc9Rbb7CsrGQJOa7U+8/967st22z8IFdm9/Nm3nuNEi3/7Th4tlYAT8 ypSoDJgSOxyUCmXbvMAcJERy4QgBeYAgKkIIcQSXKnEOulmW8ny9qFqtA/ekMj6YpJzNXLJbLUXF ZDVDhiSL1WI2mhRj9VeJ0fThouZBzc9hMlslf3Nd/Ttv/UuJROus/kIkO2GMN5XrdsVVKaNObZ22 2vSWZDVf+r0fP/iz82698ifn//h7zfPb42w66pIT/f3QU4fNJivVOVAJSau5ooLA5pKkuExGhtSJ aNrjYF2ZqgHvoEToZFCI+CnG3qiON5GYHkWTADhj46rxR1qgeHUiMIKJ544GhnmfjjT5R6A81Rvi CBRUfMdHPxeAxXX4Bw+FAiBoJSShOvi5DiVrUjsAACAASURBVCIrwrwJm+EgCKa9WVgKl6J7aIiD f1upAkkoHWG05kvmOPoefI6eyRWZKZqqEUer5iBPgQ9rCnzPXCaCA7dYrwBftKczMbudkR4fB+Y8 HjOmN0aEdSErpziznd4pX/xieUWq1cqSc75B6u/HlmViaSvTiwxhGV2Wzz/mPOUaiwy2lRL0fHQN 7KQaEF2VjgmSaEuL6M68gXB0W+HRrgxJGPTMnD2bj25v/dWvy68sAyiU8gcai0rJZLO+v3zFkiU3 /PXRpzs393zv22dKBcYwnIdpVnnbGzH5DNiV/U6m0VJpPk+RfLamRMzEzF1ff3dB6uX7uV13mRdO ZuI94XXrl3f29r7wz8dmzJxFOQwjkRM7ywDkgCRlolcuf2A4h6hCWvATh59bHIEF+JDqPwCFycbs wDrFqX3gA1/pYLRWiumSkjGU8qySNyExohYV0tstiMOSqap/xfI3fkP+ouG0STLuMmdOqbv7A06h qJOCNos1lx5TsD/2y3vrJW/IaTE63UwmGsfUX/+H3/V3r11y9tejHeE6l1zKprHGu5x29uEcmvNH IVWFKRlYzFA2wXMSn+RzSYVcysKC00EgW/ET5VR1YvRLRPQGdAPjvE1QptDqyL9CAamXYH7UAr9o xlUrqwduiQaqDya2JOUOjiOaN20ULKPtAm2CTNQSA7yDoBCZK2zpvvvuYzMYCBk5MIsnAJE4fI9D 4G9/+1syvPTSS8eNG0egyBNI0gadQ0vJs1iJz2wk1Q1GxqKS16cCcwY1FO+LBEO9kjROylhyuZLN l1MlWeLju1hPocGPGVjK2PudbHWuWN7LyU3WpNFmkhXJkSjagUC3pWQsxdhZL6mW91Me6ox5g9fu xyhtccjpUpr9zrPGbF272tkZbWxuKxn4stpc4Agqe9bjtneEN8+d2T57WvvE9na2qsNIVzRI9WOl zZslFqArJilV+MAbTBbyqVx/prGhMRYLSwabpmpKB17RMw69DRVm+BBSEWEg9YceftbKp1Y4PZwc EANHciEbV0GRhxeg8q7Iv1IYTTwRjTwr4+v+nUsDlc0DyUU7wSPCt0ldQBLmwoAFIIJsxapK2pV4 LQm7Dn5eqMQscy93k2TJ3vjj65YsWbL4uIU33nijKRjcsHTVff98fs6sacV8kzEnORNvdW2Onf29 vzSk9sj2dSYnNbyhKHvZZFO3ZHPb15kdkvJmQJ7dFJw1sfHGy742a1Lj0+2z9nz8ybUH7BbeZe/T VOnOM8/73I+v/Wk+H033b0isbfazfVK+NSDnmXPLq5Po5cZiX7Cg8tENMvPupOOAh7z4QVFgEIfA BCI5EZCcfsFPj5211QkzFMpoSadMjLeC9u62QHc/pnyry+ExJlIFpchMpUuW1ER/r8lXY/F2jfVM oTZrJhLcbd/PT5394M3fPLTZ+NOJs/dIRqw/+cUpK1b2XPfrRzP+jC9ulZjFlNVk05G/uTt23tcv ++4pR9x290NtU+rfWZsI2NSxZileY1fjEkb68roFoFAqwGcHJjEAk3bJ0BXNmmW/mszbU/lmc6o3 36e6ZvK8akFQ1cZDZJEnHjQGtRJcqmrkERgo7AiDQI+2PQJF3VlE2mm41NYqFNSgfQMNtPh7772X o9HZGYFM+AlqcFejSpyoxSd+M2bMEC9Xxhkimhix1SqXvXThXOwj0J8IB7wcplD+8DjkMEsBf4JB JGMubrJxA0Yh3tHpdMyqNFikjem1Yx0N5TPJC5LDHkpJst+hxnv7pUJWLebrAq5YNIJp3SjbS3yS XMPRASgLpwnMV4rr/rVmj713tcqWXJFjLkzFtDmdTDU3Nt99zx2y2yNZpY0rusdOaFCSUjojNTRK 0U5Gv9KK95bP3322EXO37Ij2RzDZizwpQngQAY9wNcSpHgzEiEzElRw0T9UEPJeq4QSK0kUEMhGu VmQ9XNfA9tAAsMCgiwXaLChh5xS2RaBB0jKhULyhae1i3EWvBFhAHuJj9OV62mmnERMixS53CGY0 BcxGwysvPz9x/JyjDl106v87vSuW+fk1l1/+7ScPOGivt7seZ4qPoYPLCR20ud3NNvcKs6XkbXb9 9cG/wMkOO26h2dGSz6jvr/rbrvP2fO75x7/4xdPbx401G52FUrqrI1VSWUjq5KjybCbXVmfL5Ezp ZNZW5/Eay9+d4RhJYqJmPQO14As+JPzHP/7BFlNQQ96v0EQqgvxUjUrhkFl0PTCTo0s7+jaodfaC 2WkxFL0BP2aeaCxutsgBQ43v1wbW5Qx9IimyRWhv8MZf/eqOX9966aXfkdIAqlPy9txy/0v1dRON DslSwi4lqRYJ29euCxd+5xrj97559Te+c8lPbvnltBkNG3qiJVMuaKsfmjkhyQwfJxutBl5whpKK wZ7vlJmNNPV0dfpDTdGMVB+0xbr64uHO+bOmOKt/v1Q1Yz1Q10B1DYxaLkV1gQNAAaQD3ebOnctg Cz9vYkABOoWHOP8ccEDGqaee+uqrr4IaAj5IyLitus4GQoGIdCblkmWPu16KRfacveurG9ZIJouv qHzrzgcOPuG4eozIZdMVxwrztZ1qlcb090pjQyFV+iCRmOtplDoz/TZro2RNsQzc77YrmUR/icWt 1oDPv3bjOpf9P8dpVYohxBbjSMLBbuScNGnSBy++/vrSV3fdfRdv0JpMFl1uPlexrVu99ohFe6dS mZdfenX85Mn93Umb1ZlMpRNJg9lkf3/1+5lcqm18a561D5I5V1CojlL+ELCsGXFFh+KdUSnDlviF GsmEHLT4/ERy7WelpzJaZTiPTJOB5JWuMpru1zWwXTVAw4NL8a3WtGnTONUYLoXDqAMXoX2CMNwl DgMwQgTUYMQCRuAoHKYOoyICjTkeL02e3FwsSFi3/vq3vyUTERZ08yHcmadcmbP3u73KvXfe4zG2 FDMsfHIdffxZG466LsCmUf2RsXOm//bP91wfTpRkv8trLaS780p2v30PeOedZbFIChyy2ZiSM5q8 Db/69W22YCOdOKNKzDlZOCQhk0uy5MrtRgDWF1MLWBFLvpDz/fff37hx42GHHYbkGpeiIlSKLkx8 4gguRXLGbP94dOmUMZ6xbVOT7NNUyNoccmCsny1+ax9tXL2/Z2UWkjk6ujZOaW0/+9uXLjrpS/Vj J4QT2UZ/1lAcz0iVdVB1/ra7337L55uRiUsfxGN7HXv0gwuPY7k5Q75UVmod48sqki1ePf9QHavp 2behvEjDYrGzaAyFsBxC8Qdkp5QhoVlas2lVeNP7TdMW1Hs4BnWr7e7btb3pme90Ghi1XIoRGGDB 82CkBaJBnvCwV2dPTw+jMcCC4RcLpDiOCow79thj2TPmpZdeAjhEpxLwMfzjZN69IGVZA56JhCPh 3r/ee9/Uffd6///+fNxpX26a8vz8XccYOKdKktZvzo5vZk87SQ7xK5FJbPA0zk2UJI8cLKakvu61 JpM1nei3Goqs4ewOR+LJtNPbWExHq5aOeIJbwKKoBQJTEWo0a/70N95Y6q9379k8PRxJGIyyN2jz uTxd3V188FJSWVTFvJ7qdLH/ntUZsKx4ddNrS1+et+tsi91stBiTLEGw2XIKxvAPWRSZI4DGY6oK M0wggom75CCc+FlLsbXCP0r9ISGj+jiyEuINI4B+S9fANtQA7ZOOBtuAQgEsK1asYEjG7r5i0AXn 4K6IoxVKD6Wt0lBpw2JvTzpFY6OJNzrjC7urvEjZyvcg1gFPULLKgUh2ddA+htl4h8xmnpJNrmf3 TQDMFfBL+Vg2lQo0NnT2RqAZLkeDUkiSgdfDn588MTPjMv1RT6COTZ3SJbZPklgTaTR7MM04S2Yh KkMvzn6AUZUjZzJPPfUURqmJEydickM8Md9HdbgrhC9nOuCoNbvG7D8ruWHFqyY1PmvB3ilVCkfS hSybBhsDtY6zE2J9lIn2byaj2p0Gf2MopmQtdkf79BksInOYLTZ3QzRsMKmSr04K9xgCDU2JRNTp DloDY7J5Y85cstjY4kHKc7hNjn0nijZP9TXmyWR51xi7uzy7AGCARsxfYcl3umyZpMLZW10b1hcT XbvNGN8UcPicZg7u052ugf9GA6OWjNPzgTZQjCEjI0VwYe3atccff/w3vvGNRx55BJUxpnzzzTfZ Zo0h2uLFi8ERIpOE+NylC+IfXrMuC0ek240Gi9PrKSn5ca1j28a2HPu1sxhPGdjbzuRR162+7qpf zpo5zWNzPfUv1lDB7JSfX//j39519wWXftNlarzqwuvYNe6wo446/vjPcHyEWSr63a5QMJRK5ii9 lkNUAFrchSNSEbBvlz3m+EKupW+//u5765rH+bz1tmy00Dgm2NvTr6SUidOmsSLKE3JjKGN73vff Wf2vN18xWEqz5s2AS8kuOafkWa0VT6VrFbq14aix0om5D0K2Nh8qqyXReBWe4R+NflfXwLbVAAAC jMBC4EzHHXccm6dgncKoQ+MUBdEmGa3BTrTGSZsnsmAkIprgKAxS2BQXx37issMbSZQpEf/FY91+ +4S0krWVRzESZxiUFJmhmtM+8Nm/lXWSfK9ebArVQR8K5a8Jy0YXpvPKWRWLsSj5SHKgCVaVzuSc RgmOVsb38m6ZRsaWyM8vJBGzddTlgQceICE2e27hIFvgnsAWaiFYIEnwcIVHwgjnjG+0F+KdH7zT u2GlXc2PqXeMbTCGvFJRrvVXKspV/tpChqBLGtNkd3lcFtlmd9gxQI9r80TD2fY2vqwpn7He3jzW a3U3+z1sLJxOpuv8dp9XLhUU1ow311mcJtVrM1XNnEBrwMhiCv5UlxQrFqLFbMkhuRsN9T6pzm2y lxKr3vxnrHPVuJaA1y2bncNNQVB33eka+FgNjFouRc0FirE4gKEYo65x48btt99+a9asufnmm+FV sJDrr7+e8RnsCgNV5ZcspAVZQJnh1JcvKKUM5yeoSkKymJyyrbd7s0My3nH9NVIiNnPalFL/xj/e ddeSy7+z6oOV1/74skMP36d7rSTFlGhn8owzzvUFg489+Ztf/frythnzDj3+hMUXXshBEJHuzU6z Iby5wzewAhQ4G+oQCcEEuuEhApBNXWwu8x577ya7bE89/cQbLy8vxRmL8kmP5PT6MGdzEHP5C+ei FO1NLFv27jPPPBuO9eyz/56SqQSDyxfzfN+SyeXYtkEjLv+lB9kqHUKKn7WyHVrTQSHas6Duovpa iO7RNbC9NQANgicJqgGSMNMHsPz+978Xc2R0QG4xCwbU0Dhp5MgDZeFKy+cKFol+ip/N4TZu2oSH 45pSxbzfHUiwVYlJ8XgbMtmM0+IFlNm4JJFM8Xktn+tz/mYGW4rCcqJiIlH+HhkuxRw9x9RQkN9f Ps0mr+S8PtfmzZ3pJIzKCByxn1SKpZE4tiUoqMiGlz6FJIj67LPP3nPPPV1dXQsXLmS1KPDIOiok JAL8T8iMnz5LKuJzpSw80ya07rXrnGys96E/3bPstRecUqnOzj7sEmyk+p/N6Kz212SXAiyT6I2p maTLavbJpnq3RYmkZk9wlZLSpBbJjRaiiTqjvdlmaXGqY5xuUzLf7DSMD1nsxZzfprYGDfZSumrm BDpsfAJYzGcUi1FtCJnHNtt9HDpcLEmpxFv/fOwvv/tZPrL+oL3mzZg2ySLbOzp7qKDudA38NxoY tXN87EuLaQo4wBYCBDAsA+ZOOeUUQATgu/XWW8EU3EEHHQSUADRwKcARvAABSTXwvi4v8RY4UkXF paLViClaKZ+dYLPks5mvffUraz73+Wn15j88/nxzwGOUzJcvufaWn97VH+475NBDpGtv60tKDXV1 6X7TxRdedeUlXzem/r2rXLffT35w2kmfX/bq81ikOepUlgrM3RdT1Sf4EAOZBdIhKkiHeDhCsqX0 1BmTPR7HU48/+eCDf/vgvfdmTJtRXxfy1AcZ5PE5S8fmnlgsytYP7767gnmKWXPGT5o6oae3u1Ay xpN5dpggQwvLXHP/2XuQ4lAF4VyraGDYIOSsTIU+xU9yq5puS+iReChcybxqJnqgroHtpAFghF7G tyx0Or6D41OVlpaWBx98kE+A2S4caoV1Z8KECaJlVrZPrcGTAxCEeIV8rr6+PN8fTSQcbhersBXJ kMqlLQaPzE7fDLgi3V5/Q7FU3knYBMiU2GzdksvTcYxuN/tL0etN5WOM2YnAaMS8BHA5neWNi5ub m8oDKOxhsJ+iYrd82E2YACwM2JwYSb700kvLly/HmD1lypTDDz+cpZbUSJjThNlME5hw+qxAGDzC qMzqxXlzZlt9npfeemvpy8899+TjkydMPnD/A8dPm4AAVVwN5LCxSrRYMJlL7DwOJKSSSb+HrcPt zFu2B6TucG9zMGRwusO9eTv73xVzZoMVCClk+KTQ6HWbOAevkCw1eB01smd6lCEiI8Pyzi9Y1cLR 5Kr3V61fv375v58DmNqaGg9duLC9tQ1zFzuWN45rikfKk5660zXwiTUwarkUCz+FUkABHOyB71aA AzY+YDdOzE6wK97Kn/3sZ4kJkYJ4gXTAB4AC2cKgDU4RHyiprlyL2SCx3UrKYXJLfZtDobpzLvuu 3Nry+SOPwyJeRsTuDeMb3Gdf8JX8BQaXnGF/mLUdG2ZMqM8kpJOP+gKjyyAZZHqm7bJHQinli2zv YbSohmhft+zy54HtATv/0KKRCrDjSqXwUBFEJbrFZs4pGX/Q95njj9uwZv1rL76y4u3lDaH6kt1D TslUkg+Mstm0z+9buHAR05oNrd50JunxeVh4zrcyfDxcKjKQTbOxMYWSuSh6qGeoSFVDBO8hOR6u mkdD6kGpiDYopPKnyI0Q4RF5VkbQ/boGtqsGmP9i816m9sAHhls0Y85dOfvss1kngGkKgvLoo4/S yAnH0T6BDmIySIPrCBIGqhCCqcTucDDVnVUKHIebyef58/BtnaSkogaHxZ9M9PjrSv3xTpenIZ2x sIt5Nl+wys6+cIRuWyxw5FPeJduT2Sz78kJBbOWNjSzJVJxSwALVxCxYng2fsqkkkGKTnYlMzmiy OGxmbPBAHBQQuxrHnrBGioowU4jYwAgEEYsUOiQE0Cv32IHqEFIWe+AsP64ee3l3zAnjxjkCvvEb N65bu75z4+Z7b781H41X179anlgc6vLmfqPFxsL4jFLIZPOwQQ6niUX6LewzJWdVKWlQrZGeUijY orJ7QbGPLULZFcrmsORK2aySk10uo9kaTyTd+ep7MbD1DDSUcsWGCOiIFfcup2vWxDFNDQ2TJ0yo DwXymaRddrJMqyuSGO4MjaHS6yG6BoZooAZRGBJvZwwAO4A/oI3FlXyrwsJJ8GLy5MlM6mHfBinO PffcqVOngh2CjkBQ6G9AnsAUfhJeq+KsUeJMPCNryL15SbZsLCrBmfN33WePS8+Ze9Z+n1/VtSnv Lr2hJu687YljTz0kaSkb8ceQV1+vzVrXk315inSoJDUBql2JvimmBqM5ZzRkGXJJFnfO4o2zqUsp XLVoqiOgDVwTkE1IWU5DtrwJOhvPWdXGyXX7N+wL7jP67OjooDr1jiCwXkYTl4uxtdVqSORiJC+P iDHzMHJTSoz72HSGzAdQ9MO3goan5cgDVEZIJX5WhlSVdlAq4oD4XMlWXDXPMKquzJnK4gjZwviV aXW/roFPrAHaG8YbOAc50IZF86P1YqDCHLXPPvvAmYjALQJp9qKdf+LitnlCQAAHeaL7M27E4Ycz AXdaWaJnidEjfqBAoAE8kjiE4xLlw1mMnNzS6q8L2Z3TGppj02JUnKGpls9I8CA/DwKHMNSCuvPI kL+9vZ2f5ZqYzGxDD8izKN1t4iOekSC1LsNOrIFRy6XACKgDTwYgoMMAgmJlJRj3hS984fnnn29q auJ8OiIALnAsOhfxoVwM3crjv482UKj1bOmjDizo3pCU7CoVON1J8Xk8YM6ll17x4OPXffm0xY8/ evNJJx7xjQvP87Q+NndRy/ub+wMOq6Oo9ITZj8rPxlS5ZLonPXCaVdkIxbyVyaCyXYuaz+fyWckq FqBWKx6kFo6bmkfgoPgJSlJlMR8xfvx4EUgIHnGtTKjlgEeEizIHhQNAIlzAk+YnQ+EfdBW5DQrk p4gvMilD3Uekqlb8oTnoIboGRogGaLRYtYEUxmwAjuiD9BQaueAfI0ROxBD9F4GRDYeHrvcJCB+p NKgBZ8gWWgZaQlZGTmWFJBqdQkjgHQnxMLwU1dfijDSxdXl2Ug2MWi7FKASDE90JsOPzEzo8JEkA Co/qggsugGoQIh4bUIj9hh0TsF1hnCdQxMRfCyNgED3RZL3XJrkai/2bGOytW7tm19nTpDGzr7nu ysM+e9qv7p58089ul1LXHnnoAkmOSs66F/9y71777+OrD8X6Y42So2RzGuxSvYfPSDh6wCwZLHyx VuZU5ZMkynhXtUkBgsIJCT/6NZBsYH2oEJ7aYYLiLvkI+EMVmiMER0wiiKvmqQwUablFZGQUScik nHjAEXkYObk71Gn5aDngIZoQYGh8PUTXwEjWAKu2RQOmI9AlK68jSmwN+oS0n1g20d+1KgOhQCud d6RxR+RESAFWiEf1cQSCP/zEw1XU4r9UyCfWpJ5wlGlg1HIpzM7QIHoOfIjNYLBC8aEKgXR+rFAs FOVBQrYYWtHf6FesfnjuuedYRgA0iGc8/GALFiazyEEqSfmEJdC0an0HqTCXW4u2Qz9zUCy3wTOw 9uCm22+49Jqr5JCzP1Ec58a0k77l9t+Ygi3ldaRWxyub3l+adPjsstVk5XjNQkkyWy2y1cb25fls 2a4+1AkgIFxAgIYL1LSSKgmkADIqbfikIhxMwUPtxE9xJVz7iQcnwAgPBeEEB8JDTFGQuEW0cuwh TmQ4JPg/dimy4m45a51LDVWTHrKTaED0JoSlwYuWTM/C3lOr/X9a1QL6EAlHh9Ucwggc2HKpKnGG VECByI2ctzyTHRATqcTjQEIhp7hWjo1FBB1/dsDj+F8oYtRyKc3mBIiw5cGLL77IGTKYarq7u7my XBQWRRy+CgYdGFS99dZbnKsgjN7gCxBJJ9SAsnZTwIjkTkX7nL66rp6+QKhOKrgVNZlRzEbV7uL0 OznjdRcTOWmASJXS/d2O4Fhyg4DkFYM1yD7oJWtJNUscRWzlND2D0czhM7AdtvmrWugAHpYvGgQI FBOQgR+ZuYUjBEc18ZPVQNiHF/FTJOSqeUQ4V0K0VPzECWwSgSJE5EW4+DnoOny4lrnmqRV/ULb6 T10DI0oDoIfoPkhFYxadDo8WOEKkFUNErbsJUT+BbFSQVNROAwSBmejhE+S2XZMgpCYnBVFlnMAZ 4ReB21UGPfP/HQ2MuA6wrVQPPaKTQyxYBbVo0aInn3ySNVIACnslsBR9w4YNrKBiao/16VArOhjX z3zmM4QgAAmBDEYww8zxZbI5ubyZuZROJR3u8jeDjfV1ZeGt7kKpx+bwlPcBzhBhvWz3p9NSOi5x IKgjMI7sVVZ8E9HpTue6LPmB5dhF+BMWsjxzfOzQblDytbgF6AAQcC2X9ZHjJ6KShPrixF2BF/hx IglXUogrFSScnwP3P/SIuyKCuPtRCeV/RQilaEmIOYyclWk1v5YtaTW/lrkWTffoGtgpNKDZeyo7 BZILhjFyqsCaB63j0/fxC1er/9aSnHpRU4EzIo7IbWvtW7Xy31bhQh7qSIbiKnIWXw9o4eKpcaUW 26poPZ//TQ2MWi5Fn8HBMOj8HGw8btw4vmtj7wM+Z6ObwZmY4GMdIhBDR4JjgQ6cWsrqB0JICETC pXC1moUgUtw1cwwWx0cJp5Y4R4oszZKZz9XMfAWoJpLpeNA5i30yObCc/aiypYK94C7TGItUsNll Q5YDbriLRUpi8Tkr0DnHht/8rOEQuMadD8de3BUYgYdqaj9FoEguMFT4tch4UI72s7IUgbyVWYm7 W4vFlXkKv8A1IcnQu7VCKvGxVhw9XNfA9taAZvelINFxxHWkvZvBukpVbG13q0yLn95HBSszQQ+D 4ny6PzX9VwqJSIQLKOMqnhQIhkeL/+mKrZe+82qg5gt7561SpeSQIfHShUKxtByLlLYcSosG38JP TLoTlmqIFD+Z/oOEkbYWnVILOYPZxqiHdeKReMrvcWbSKbZIkVRbnkP6pKxJcRlTktGbZ1OTDNsm YItymqNSxG8MZTJFOWCKxfNpR6FRlmOlNCZzujYHJ/DFCcSM88yT+fLeAUOdqE4lQIgQYWPHL6oj AkkONRSZEILTIEPkoF0HeUiiFSE82jh7UEwt2lBRa4UghiaSFmdr89Ey0XLQPboGdrwGaLc0RUYg OK1NEojb8cIMU6LAASFh5XWYJFVvgTMkx1HfSl5CSNX4n1YgMCiegrhqYjBmrhSVu4JLaRF0j66B T6aBUc6lWHnNZB/zd0AJnX8okUJrGlsS/QqAoHdhoIJ+DaNTiBRG4Vwuy1lSTkeZr8DCONs9lUs5 beUVUQUDBzew18Eu+GXuD1Aav1Te7xgixdXpMFoVZ1TNpjlMwm7OKGkkSefLh8mnUuVt/Ygz1A21 AyE20bRw8ZMQ4SnD3kfLOES0qthBHO5y1ZLzUzhxq5Y8aJVolamGj6+ROS2VSFsZ/mHBA/9o9aoM 1P26BkaIBsTQBWFqdZARIqfop/+9MFo/pWOO5L6pofqgKmvya7CjhQyKqf/UNbBVGhjlXAoKhUMj vOABO4wrw6yRZF6PrQRE5OGJFHGwFGMahkjht5oteUWxDkwICrqGRZ2CRNFE4MtBsdkV/i10lexk C5MMiiY4jciHqwA+PMKJu4OSfIKf5EYqcd2S5Fsec0ty0+PoGtA1oGtA14CugU9dA6OWS2GOErN1 DByhEWLUOAyR4kkIIoVHvO+HJ14l1mCaMHfDqbBGmZRsDi5VUApmixmbliBSUCjoFCsJtpZIaTIM bR8fy4EGRaAumhO58RPPoGhDC9rCjHmXXAAAIABJREFUEJFbZeTh8x8avzLtUP+2knNoznqIrgFd A7oGdA3oGtgmGhi1XEq8s1l5DYvCwaiw+mLOrWWX5vs+dvWEgaFWQcJ4iw9Dp9hGl5gGjmxnVygm 7FwuDiFni02K0GxakDNI1ScwSpVzrrHeopZFWtRLMI/Kq2aOIs9Kt604CvmTVWVuSI4bXs5KSYb3 18pn+FT6XV0DugZ0Dega0DWwwzQwarkUBiFe8FAZXE9PzyOPPLJp0yZI0qC9KzVFc176/vvv39DQ INZUQhEE99IiDPIoyYzFObBtOlvz5fNm2V7MKybZxkpULSbMDBpXa+Zei1bVU8lOqkaoFVjmNQOO CPwLF4HZVEbW7lYG/jd+UQpXMqEsVDeoxMrMRbTKEN2va0DXgK4BXQO6BnZqDYxaLsVT4bhNiBSE 5qmnnpo2bdqJJ56obeA59JmxmSd86/TTTxdGLAgBrEtb8DQ0vsVVJlLFZMbkks2SJdUXhbE4ZBvc hRxgDHAyisMzTKFDs9VCatljtoSLEEdziAGzEY7MtXBCtLL+Gw9y4iiFnMlHy1b8HJozkYcGDhNS Kx+toGHS6rd0Dega0DWga0DXwA7QwEcbI+2AonZ4EXy+x1ol+BCbm0+ZMgVOU8sohWh77rknG3iK 3ZiERUr7Qqe64OxzwEopQ1mBye7w/Hnz2ltbecEzwXf11VcTiB9ChmOOr3oOw4YOUJQqF40MDfJo 3EKQD+2uMLORkQgROQrqo8X5bzxahsyH4gYVNzTnKlUaNmhoDiJkWOXpN3UN6BrQNaBrQNfAjtPA aLZLQYYwSkEyWLcEkYInwWxqMSQWjDPBB/ciCVOBxOSLvOFMU7Aog1RQFHPJ5vJ48Pz6V7/eb7/9 7n/84fPPP3/BggUHHHAA3ALDGAvPYRgYq7bqqUIwqsZHsKrhlYGD+Ae3SCUy5JagLlsrT2X+lf5K IiTCRUG15BR3K3MY3l8rn+FT6Xd1Dega0DWga0DXwA7TwMe/mHeYKNu8IMxLsCjoEe/vZDIJoSGE K44QwSqgOxAm+BNMS/iJg0cIM8wcHxshqNK6rNtSPg7GsNKQ7nV75jhb/WeduX9GdoW9rVIubDb0 /fC73zcYfHVm87PvSGvL9qlNd10w7V/33Hnc4lMtrZaLLrkvG81+ZUH7uQft35ezrjb4o6mYGl8l qdGoYupLFezuQCSeKBXyNkPRrmaVWJeU7jfks0bVEo0WzLZANJlN5hI2VykRzzscbhaCZ3MxzqGx WFgSbjSodkOqVzJZenMWmzeYjfbUWfLFfDZr8RSM61MJYykfdLkthWI6FrZaTQGLo9tZyISlYJ8a cBTiPlM67QhGzR6XGs6p6YIxn1Yojl1ErfmiPZO3W2xBRc1YHSaz1ehyO3PZvMPmspkcHkegaFAL JUqK+dzWbCqsKKl8IauoxXSOHeFt0VRK4fBBqyGtKCWjXFSdpmxnrpiPG+w5o82QS0qxnmwyG87K JrbcU9gi3pxKpmx2W0EqqhYpo5Yp8tY6njgPABIpeCQ/hUc8a35Wuq3NXI+/YzRQ+YyEXzw+rqL/ 4kES0aPp5jtGKr2U0aoBXgegBLWjLfHioI0NvECKvBp4s3CX9kY75Cru4tHd/6YGRrNdSiNM9AQa OpwJKxFXrdvTB4gjohGovVnxf2xrKMUko99hMw1swSlJ9CtVUjNS5tm77pYyWbYwl2zun1/y1Z// 5pFly1d88MqTB+46b133G+xFtaY7ftmXzjjiiot+/tsbrzj8h7fecuEvLzvLmIsFXdCjhNthd1nr NyZZcpX1epzdnRvr6+qS8Rj92Gw22dyBXDreVB94d+W6Me2TVq58b9KU9mSqb/2GTS5LU8emjmCd u2xUMxn7w/0Bf2NPd7/fYsDkFmxsXbnyg/mTW7vXrTK56swmcz6rNNT7e3uy3T1dwm7X09tndSfs UcUYbGK5l5JOZBL5jMfLxs6JaF/B1VZQ1Gwm7/MHjAZWl6uBgCscjisFxWJSIv39fNLocftKaokj Dk3xhMFWMBkNNpu9s7vH6/XHk0mYUDqb8XrrNndulAyKQ/aJh1IqpEwmWylbJoVkYbaaCDcby49D lu2peL+tbCwsQxiE2OqwW21WQorp8m71W+V4rAL1xJW0IGMtu1et8K0qUY+8wzTA8+JpijcfLYdO TdH0d5rNDpNBL2j0aUDDCvFSoJkJDyeSCT8vFOY6oFY0NkGtRp8S9BptiQZGLZcSPIl2D6oKbKXF C+MTgTi0QxwRjTh0DDqDCBR3h1ef0Sd1RtY0+etzCUmJ9ZL86GOPyjrXmlLS428smz53vJTvv+GG Oy699qf1jY222bOcpQ1vL13feJChM2O9/KpfnnLZmfn8q7+RvnXCHc8cc2Awt+b1zjXLx03aRenp 2JDJpf2TW2wRqZB2WIzpVMLucJRUQ3805nS5sTb1R6Itzc19XZunTZ7QF+kpGQqt4ybYip50JmEw lrCTRSNRr8ff29vb2NhiL/aaTN5wNDljxsRI5zrmMTvjZT0End4NG3rMJrmpObhq1SqX1eP1eON5 tcVtTxVzSjHvtLIpl12RLbF41G0zJgqAhckh2zd3dDFdWd8QisbDkrHgd3stVmsilnA6PalUJhKN BQMhE1FNmUgkms8ZiyXVnFM4Hqe7u7O5qWnjxk0NjUGlkN68eTOn+jCR2tcTa2rym0p2h78xqdrz 2XQpnQ44ZaMsJ7LZSU31veFwLB4PNTbkCoqkGuLxpMVirXlQYo3HxoMWD1e78pTZnRUSXDWFiF/1 lh74KWqg1nOhC2OL4mVGBNF/6ZKfopx60aNDA4KUUxcalSBP4gp5EsQ9FAqxMJdXDA0PXjXcVMbo 0IheixoaGM1citZPE2e0yvsSP22djjEIi/kpQughWHSEX2BxDY19FGyQmvwtOaloc2MuamNR1C3f uaV5L/Wrux1lodMRK6/UhUxfv/iC8797tZztbvJZ/S7JKDk2x6XzFh6flyS/Mdcm5Rt22Ssr9/RG IyefcuhZ53+30Vo67+LLD/3qD3bxdckuV380efV1Nyz+xsXhWOKPf3ngnHPPq3caYpHYTTfc5PP6 uiK9QpqTvnJau79ddlgSybDdYVbyyj33/DESTo4fP7kQW/vuxvC4OXufetJnld41D93/xwUHH20N tdc5+5a/kX344UdPPWu/7u6e5W+kjjvumGBz1NoRvuiWv5562pf2bi5ed93Ns4/78vTpU5+6bckb fU3NLU3JVCwU8i/YazePxyEZiqFQMM0HjEbjj398/aGHH7n7HgtgYelMtqRKy/71j3dWrPzS6Wfc +4c/7b777vPnzf7jPXd1b95UN2ZuKh0zmYszZkzeddfdnn/+pddfe+urXzm3Qe574B+vv75i/UXn neOX0n+487dmb8vBnz3NGFvDjOzd99y7vmNza1v7CV84iU0mvD5/Nh756Els0b88UxyNQdgqBHuG bmKT26L0eqQRrwEMovX19YhJf2e0oL35RrzguoAjXQO8FwSA8ELB0bTgT4FAQOyhI455BViIM9Jr osu33TQwarkUzV1TGgvPhfWV5i4QVmv0vFOFI7IYUohuQyAxhV/Lp9JTijDHJ5f4lo+1VUpq1aoN c+fOm7qr84wv73vQvvut7u2VXKENXcW//On+hcce72MmMLs5a2nuy6xx+RrXbuwdt2dAMhuYh4il Cg6Pr619PKaXeCy2cP/dnHar3+2cOm1qOpvP5JnaM0+cODGYSOdTqZaWMXVuS1NTwe2Qv/DZz+y5 915mlyOcTRtlu1uxsQ17PNFntRrZT2vTxs3nnXs+lZCL05rW9r745kpOTZ42e85r/3ymqamxccpM a3F9KsJe7eYpUyfAit4uRvfYY0Fn30v1WLKKRa/X19Jibx9Xz/ePbo9n9pzZ/audF154QSbDVJ3R H/BEor3BgLejc9OY8ROUQlHJ5efvssuY1rGS0Wy0WHN5ZXqr+5EnLl624t3Nvf37HnQIq6jGtbfm 4n2LFy+2201GU0EyFOyyvHz5yob6+lmzZhb63545c+a/39vEh5BtwRDwZAu0eL3ehvp2dq2/+pof rtuw6aofXbtq1eojjzrGZLE6xzRVPo6P9fMo0SQDR1qC+P4ATFyzZg2AWDUt8auG64Gfrga0njtI DDpsOBweN24crRdjJxZHHjeBPOVBMfWfuga2XAM0IRGZhscbocykBrgUA2+fz8f2zvwUGMJdMVTb 8sz1mKNJA6OWS2kPiZci41TBomBL9A16BY4I3MIRghNz3loqQugb2s+hHqNXKklJu1THP1Kp6Pc7 ent7JkqtS77/gx8/9uVTv/S1J26+ZMllZ552xunPzl0wKWhJdXeq9c3NwRbsNm65fBhyqlDKYNyy FJVIX8DlK1ncE2bukivkv3D8ol/e+sMDbrrSIrv/+uBtzOu1jh3jT6WlQire19lUP73O5Vyw5+53 3/GbSRPbmtyT4omUw+agRhidoT7xeP+1P7728MMXnXTSSd3d4aAtPb03848nv5xMJupntsH9Hn/8 8eObp7hNpfv+8Mdp06dMnTbxtddfXr1m1RtL39zrgMlP3XmXaoR1zW1tKvZD9Aym6bPnjiktuvXh nz/3/JPHHHN0JNK/+oPV2KiMRnt76+Sg0ZjN521Wa6Q/4vD2WWUn83mBumBTY+iYww/4+4MPHXb8 F5pbx5mU1IEH7P/og4+/8MLziw5dmEqnu7o3zZwxA7NQXikbxkNNTd7OpM/nHTNmrKwmmR90Wvwt LS3j/P6HH3l0wsQp8+fPb2pqtlhsY8e2p9JZs5oc+lCGCeFBw6LKWoJsDix6EO/aWrt/EX+Y3PRb n5YGRM8dWjoUircaRJyOzJWHy+Pm3aY/x6G60kO2XAO8CIhMK6LhaVwKP/wJyk4IzYwRGhEEsGx5 znrMUaaB0c+lwFYxkhDwSt+gJ+BED6EPEIIDi+kVGvIS8jFPOi0ZXXJ/JhGQ3VK2xBwf66xdklMa O/b3d9193Be/smLFUV/60pd75HG7zt9FSnSR20tvpvzepDGTdFuNG4tSs3lMxOPzRjaOmezNpyxR xaK66py+7DfO+WJHJPyVCy5Jx/rnzJt/7x/u87qdDUHfZ4896rofXNY2a8/bf37Tdy+77Dc+1yXf vszqcUTi6Utvunm3PfYrFLNmawmjFOufzl98EUPzumCdrPa1uxoPPPaU//u/h088dC86vGxyfPOc s63W9JzpR1xxxeXBunBDQ9Bms/7oR9cYru+cHqq78DtLZs/fc+ObD7VOmiZ765I5dc5uey25wrnk u5ff9dtbHR7/6af/v4ULD+3rDUNu+t5/o76p2efxXnfDDeUDCplXdbouv2LJuMnBRYcc/PcnXvj8 iSe7PH5D1nDookOMP4osXnLb739/l8GonHTKCUcccQSrDdwut90u+2Q/8zKo0W63TWhuOOSQg2/4 1b2PP33YH++5/oMP3v/B1T9FgbvM3+3II46yWWW7HRUObDr/MQ/pP7d5oNQdnTCgZGENDYCfvHRr 2aU+vgH8J2/dt+M0wNuramHQJvbmZY6Ph0sr4kHzfHnJVY2sB+oa2EIN8F4gpngv0PY0xzsFDOGu GJIRh5AtzFOPNio18OGXTUPrJloP10EeYopArrxvND9Yxk/haGE44RfhIgS/8HBr+fLlRx555NBy hw+hKVMi13feeeeggw4SlKhWEmISgYP2Xn75ZXZ+AltxIlBLwk8hJ+D7wgsvLFy4kC4BqQKRxfKp mkUkJMndIUkt4c5csKlDSnolVzAuRTyZHlWesjErtRZ7JKehoIa6MpJfijsdnu6U1OBMS2qvlG/r sElZacWE9NSSw2hYv8zgdmyyjl8XVVpz7zriq1TZ80Y44HU5TexqYDGUchm/W04nYmqpELU2uE2q rKTNhWwqm1kXjk7be7/uZEaOYKcp2OyGXD5FNRVFtZpdZpPdmO0ouhrzVi/7HpgSned/7YzTzrt4 0q4HJnveG9uwZ6GUNMrv33//Xx647707fntfJLnMqZRKbQsi0f496rO9vV3J+tnJVGJMfm130WK3 yel03mKWnQ5vPsfzNVjYlUHtT6TTNo4jtNp6ojHZ503wGaPJNMudW9URtteP74yV321SOuwqxs35 eMY5fXPnBofT5PU6WaIulUz5HLOrTkvm/aKrKV6U3TZz/+p3xrc0ru/LKo6GZmev3e4I9yeMZlk1 2GSnLxpNmS02uzmlPcQt8dDweKDpdFpbTIOWXnrppfb29qrJaRVVw/XAT1cD9P2qAoAt7LXLjrsw ciZfeNA8X3oxfblqfD1Q18CWaADcIBqvCRzvAsGl8AAjODyAG1deHwzMAA2o1ZZkOzLjPPPMM1On Tt0q2YRatOtjjz3G3Ag5oBx0xcsUh06ER2hPXIeGoEbhiPCR98P1Z+In2eLZKvF2ZOSd+MEPrybA VCwr5sG89tprXMFZVqeKtTJD00LOoFwHHnggjYDhLO/djzmT2E0eLfwfbLJJ0njJVc7SA2uS/Tzt 1vLHYeVlsGaDNKa8uNnD/w1OLizZbpNsAyml6fySMIm1TKXH+gspt7tQkFuK7kaa5gz3h3tckQbW xv8ue/la/r/sPsx0dpskZTJjGBHVDUhANMkrYoirxTsOVajp3rbm5t5edV0kbzDbmtympKHN7c8a DBa7fX48/MSq1UuLhq5x7eVuIEnRxnpjXHLYQuNtajLo4HCc8c0DNwIfFkJfEa80kMbr8HxYYlN9 iFg+a3mfiIjqrGsuL0WaFETUguQlTjkayvK5EbrClauiSs5J/DOQveqeMhMAG/NhWc1MtgVCvo8S FBtD4ss7TZSP7gz7LzBHPwT40AbrRgVVopPz3h02nX5z59AAPQiLrDA04qcXw6543Fx3jgroUu5U GgBDBCcAq/FoP3eqSujCbksNjFouVV6Ik8+DqqxfPuyww5544ok77rijrq6ulvK4dcwxxwj6Jcay ZWvK9nf0Q41r4+Enr3n657Ya31AXsmKMDjVEFbfffvvkyZMJaWpq6u/vpyxUxEbt2Ajb2soUZ7S+ ewSXgiLjQRtCybxxCdn+D1kvYbtrgAfK08TR4GnD9COuPOjR2p63u0L1AobVABAq4FoAuIbhwybS b45mDYxaLgWRAknFo8MiNXfu3I0bN8JRoA5Vnyf2CegFd+EcfJ0hzFqVmVRNtU0C6YcYPOmTXJFQ ON4N2yRz8sQUxwprPGTIXKf4XJwrcMDySTbAhEdS976+PipOlbdJuSMtE/SJngVzEowKPUOdefuO NFF1eT6ZBniaOLgUvZhnzVXwqk+Wm55K18AwGhBcigi0NOGGiazf+l/QwKjlUlAHhqS0eLiRYBKT Jk1i7VStOR36A/GhHfAJHjygLJZMbe9GwBtdFIEAgu6In1r4fykAHAJOyXQ+tAk/e6BzZSqEQFEE G2aiIt46aIaQ0WqnEVwKDVNBUff/j73zALCrKNv/nHvO7W3v3b6bTSEJJKELEamRgAiiKAr4IV1E QCyAgCj6+aGCSrNgA0EQCahgp0MoAUQ6GghJSEjP9r29t//v7MB++ZPdfAgYsnffEU/mzp0zZ+aZ s+c893nfeUcPloG/TYTl9G0BAX6KMLMkpli/5+BS5EnbQvekD3WGAPdbnY1IhvM2EahnLoV3FFYt barTblJYtaEso0JGBXiGXtXFW5ZqI7LWqPXfqULe8TTF5Ug6o1vWH9/+VYYbtn+j0xR//1AHlBj9 kRL4om0XGdZmeAPBJuv4GaEh1QPUsJB/p3B++zMlLbwdBJhKnWhk04mm8O00K+cKAoKAIPBmEKjn Bw1ECgiwYXEckR+gC6MmKkCk+AoJR9u5to61S4tDHHXmzczZv1WH9wqDgi1h1ONE/TOdIx/1D3cK 4XPUIdQhdOrfanx8VX4Dwm/4OL7GIr19AwL238/rEq/+6g0f31BfPgoCgoAg8A4iUM/vTg0TWhQZ ZCdIEsQC89ao8EG5qMnzdyR449Z5Fmty8x9VRyCFkCTMHwycPFBgwdRaFGPko87r46jg1HHhfxT5 OsZNhiYICAKCgCAwgkA9cym0Fi204EgOZdnyujxNubR8BeHAwEd+RLkZwesdz2yFdznMiW5Dm7gW XlN6CBocSvSQYVR8peu842PcRhocFepRC7eRDks33jwCMo9vHiup+fYR0L+05a57+0jWTQt1y6W4 10csVgREvvPOO7u7u3Ge4O7XfwYcRzJMZ0dHxyGHHKKDJkCkOAVuoVfzjTrZQwQ9sr/ADymH6qWq LuX2DxVUpPyKQagkgtpYuYry4vhKjZpaZmU6s/7A+vSL2wd2UgmVCxcrammgfxc7pJK3miaIOia4 TLXU2JtSvkgpbDheLRjbrXao7dVqozY1bSgWJbpyVGadnSvTt9bbMrnAJ7W+UHm+2/xIU00F+Fwp xP2usio35fG+sjIe5a+oslndoGpTHKayO51Iq1Ig22SxBbIaKNaanFXlMpc7S9vTq2LTKnelnDBn uFTWS8+61UCb8hgvBTI72r5VbkfJchJu3GRI+ZLyWkWH8dpSyVEx2pYKR/xmRu4KfSfoe2Bb6qn0 5S0iMPwHbf9gIDPyZ/4W25LTBIEtIsANtsXv5csJh0DdcikkpRFR6m9/+9vs2bOPOeYY7HcjfwOb Einyy5YtW7hw4fHHH08FztWWPq3ojHpTJNOVaMDMpWJev1MVS8ofyRSU4VCGP1BKKKftqQWRKiez VsgHs2qEsCQLCiKV71nmadsho0o+5VHEtswWf7/wz7sdcOj2npAaSjtVuKJY0a0K/3z68ge6z7pg X4N9aVIqEKKRIeWMJgtrjQ0Ro6m2pjLYVmtU8cKy5euSHWrqVPyeiHjpzqpcFIqFQS9X8ypDDSaq LWE7UhZczbL93AOQQEuV+wedzX6nodIlulayY396OMmvHGZIOdJsMdjXbYbaGw2VUU6bD4bc0KYC 5dSAIbpZ/vbaCkTalCQICAKCgCAgCExYBOrW95wVanpS4UMEpSS+FJkRIrXpfGtSReT7l19+WZfD pZAxsIJtWu0N+ckBcyje7w02KIfzm1//b5/LNRjPeJzwiw3/eHKJ19h3/eo+pXqDvlS2CHVpUs5q o1v1VOKetimqh/jo/hR1k2rwhcdPOunMSsmlSohjoaF8IqSC5ap67MlHLrn0u8P79zZCZar5aq20 rLZq0aTd50SmdwVbpm7X0rF6OeHOp3/uk2etfTo+WEgr0/6plC+Wkuy3nMgqnzGUT6mwK6tUP0Mh jlIRYcoZU4VKWVnN0T3nzlrwh4cDHlXK2H0p9Ko4rC3jR/jiP7MFsU2ty8YCapriNhkOd2UqR7HC lzigVcrFYt3ePW+YbPkoCAgCgoAgIAiMjUDdvg21YxCmOlzOYVF4BcGo+vv7WbNGgi29IeEjxbo/ 7aKuoyGMGINGRa9WzUYbkJXy1UTs4ku+G4lETz/t1FxBxUq5Az/4sT/f+uCkNvaQyRgqn01jmcP6 lhyKqwaTHUu6UX/irNyGUIVU427TH3nwmQafp5xNsOjQVCGbypSr7EvX1NIaS6pyoUxVh5twBulb b/xW54wDs5Vsbzz3wLNLOttobMWMDu/UFjPs9iujhpWwyUW8docK2D5SYY9fmQVYUJelkutWq6Zg sVQNKG8FOTI+dPNNNx504Dx4m9Mfgsm521SD6lABbyaLQIWStYENaxp9ke7aBtsQWaEXttqVycLN MDPaUXygf5IEAUFAEBAEBIEJjkDdcimtNsGi4FK89QlHidTU3NwMWyKhOZFGMuSpAJfSZ3FP8BVH WNdY94fp8KaG1mMxc4Tblce74KYbH1t4z29/deOXvnzloYd9fJ/93ZUShrL0D39wZUtT55QZ+3zt 9BO+dt4tmZxKrF929BFH3n33y62TZz10x93J5U8fsN+HVq6qWGGHqiV+8qMbQ1bHQR/Y69prrmlt bcFT3NbS2MbXlpx869evG9wYwF0p4PHMnDrdB8UxBtqnVNf3PvqFr5zZ7HZceM65PZnsq4nk8mf+ NTva7HKYTc7I40+uYyPmUFfHpad96A+/u3uvg/5r73lzVch/y29uXLrkJdS3v/3xD7/4/g0/v+Jf jjZ/0DCWL1PD8Q2Tfcuf/MDhR3c0zzj/5C+cefLJv//jH4AjGLTXRapyzQ5XNRY6Ui4ICAKCgCAg CEwYBOr2bUiIc0IoQUSIBQBDIo/aRDROLUcNU6kyeZ3hCDHA05yj9pTSpGoLbCGTjQejTcVsDAsZ btnv/8CBpx/38Qs+d8rNP3v8xz//ni+iTFf/dVfffM65ly2877Hrb/ruPXctXPLCGpdD9fSsvO/h v5xw5MmXX37tnvvsEggZhf7kjGlmrdD3o/8++9JLfrzwqZe/d9k3li7J9fX24i9uuixshMMp/PFj LxxYtSrkOvCJh19shPDhsNTWWHTXPnn8xweHeu+7594f/fLqfzzxzJxwaP36jdf+8toVvS+feuah X/rSN4ZP35BJr/vc6ed+8JCjfnbdj1VscNmSF1W1zAI/JKYz//v08y648PY/33bYYdtd9v1bB9DI lPOggz7gNNofe+xfe++3w3W3/PqBB+7PqbJb9wYTaq02JtPU/ZWjICAICAKCgCAwARB47S1dfyNl KxjNh9CWdFAl6BSR0Ef2kOFbnfTYqQbZQo7CGqjzMC0d/GlUcAw3caos0+tUhqmcRTXYc+YJn1jw yxuis4+fNgUVaRBr2AVn/+Ch33XvvVebO9j/4x9ceOr5uWpJTepqrqnaY88/ud1sbGjJ9UtfVd72 gT7V4I396obbL/32Hfu8J1yt7HzFpV8+67pS3l4P2K+imAvxYWqb8f5TFv656cSDv3DwgTsf8fkT b7781ypWTtU6Trjgmzd950SVyc2b+/6XlyxbP/+A+UcdqgYGEk2V2TvPHLq/PxlTLZF0Ornxc6df fM65RwWcuFQZlWIhn8t63Ma0QB99AAAgAElEQVT69Rs6fdP/+cpdro6M74w7TzjrwfbwsatfXrp0 fepfj/14FsOZ1XTaQ89sN3N7upGvlf2GpfBENx35asHrkL2BR71BpFAQEAQEAUFgoiBQt7qUlpow 8BGck4DmqFMwKh3ygLmFRW06w3zEs6qzsxNpCjqlXdQhUm+otukpPtNaH0uUlKOQz6haRfncJ/3X x2Gm615M/+W+NXidq+rKjqYun9lmOfA12tDbu8Fl+hw1FYv3I+e0t+vGyuEGnyqxiltZThVPqN13 fy/0yWUajppzoL/Pa0GhbI2IRXipakhl1YH7R9d1L/zVL87+6203/ewXd6rQ9FfWOA4+/ORYFTcs /9Sp03p7+7nicw88NW3K5Aaj7YKvXt3ePiVAVKl0D/LcCcedwgq8Gp7kQ4Ns9MyOyqxBZEu+jo7O xlaVVtlYellLa0MspzzucFeg2elQQ7b6NICbVDKVQpSyiRQL+mJxWgkJkdLTKEdBQBAQBASBCYxA 3XIp5CVUKAx20CM0Ko4wBugUvlMkviUhRMGxSIT8xrMKFgXZ2gJ/2vQ+gdy0h8Oect7tLKn00A0L bn885n44XTvuwOvO+uAJuZ45+eKctFrX1/us6SecgWdjpW0wtNoIqlRlksPoLJnELcDrKDrY1Oks qwb4kscoNqvB9amAve4v/bR3x1DLukiBsFIzcV9yZ1ONjiIeUxm1r/IETjn9O3vv8cll657GtTzq jIaKz7kdVZVZb5TXBL09nH7k0R+66JIr+2u13y44L9O/0QN1DGy3QfmXJhIs4vPCmhpr2XiHq1hy OVNVz9Q+Vc6ZqkU1Rws7l9PrvB4VTzsHK/05mBb3SHrjo39/wV9hzZ/Kp+x1fO62KOJbDROhJEFA EBAEBAFBYGIjULdcCtqkA50THAG3JwgTGU2kxjpSf926dTiho0th4OPG0ALVqHcIrCKdylNDmaFk Ivnp0z6/6PHHnKa66mdX96run13/lMcTPebo/Y4762N33vzPk8444exzL49GIks2ptpbWzO1FEJR nv8VaKRgqloorIrV6vTtGi797sWvvqIeffqxs7/4hUqpFNYGNMJW+YKFoaEH77v/qRdWKl/zS48t euaZZ5qamhU+YQ7D5oKsvPP40plcIBAcjA82RqPFQqEvNXTVlVcHgx7W3tWSKY87oIyie9iuW4gn 2to7fX5/Lh9jJ75QMJAbXp9nWf5UJl4qqlnb7xgNqyOOOP57l9+1784fiJXzqarNokyvK52BSdrJ ctStjVgPUI6CgCAgCAgCgsD/iUDdcik0J8iTFqWw8REiAY2KlXocR03sx4dw1dXVpXdE1p5SejXf qCDGMwpZivCY1XjP+Rd+7bhPHbXLzjtP8qiWWXv96pe/OO/rn162+l+X/ezG75533uc+e+xO03e+ /tr/jscGt+sIYrkjKkEcn3W4lF+V8qZpFdF4fI7Oq3983eq1S6fv1PX+eWeeePyn/F736g1EhFJ9 G/G+Uu5o2823/Hb+fvu5DPO9+3/ouOOO+95Xz2LBYTAQxNG+rxQnFjmL65yWZ1JD1/wD53/zG9/Y cerUww49cslzj370yC8b7kh8qOByD/uLF013ZIeNvX3ZfMHrmYwTeWM0gmUwo9LJtJqxw+QyTNLT tXTxC7vuOuM73/3v719+6dTdd5y8yyyiO7D9sdtv61yl1yN4jYqPFAoCgoAgIAgIAhMEgdc2VNl8 tNrUxfENGWrqQo74aI/k8U/io056rZzO63JdQn7kq5deeunwww/f/LpbLkFh4oocFy9ePH/+/C3o RnhKYcVDgoIPLViw4KCDDoInUQiRGvUSsK7bbrvtqKOO0oGpqENXt+B7/nojkAojPbgh0NgJSdmQ yncFlym165J1lVldg5X4Sqf7fcpplNWasz598vLUIQv+8NUOR7eKt6ca7NiZTvQdz1A+HfUEVDL3 Ssg7M9aP15Ny+noLqsUzHAgBxmLvSkx0hnKKCOR95XBLei2u3wVfW0+yNsUfVyhLgXa3yvhsapYr OnGyUo6SqsSS2ZZQMLu4x9iZtYBRJ8FLh/qr7R6HClZyyhhU5UlYEJPpVaFAy+CQPxK1Q3Iit2Vq ASKoByt9pcHBWtts4iMUVj3l326vuxe/OHenHekLJWa57IJVVap4oL8Oxfj796GHHpo1a9b467f0 eDMEeBQsXbr0gAMO0I8ILS2/ib/fzRqSAkFgoiLwFp6HvI75Wxs53nPPPUS9Bj9MJfwl8gdI4i2s M5SMpM1LaEcn6ryetUMBkfRHnRku2BYPdWujGeFM8KeNGzc+/vjjc+fOZQNjInaOOg9PPvnkwMAA bI9vNYuCCzLfo1a2C6sqm874QjhDFSBS/YN9ocaWpiAEqSlTq83pMrPK+Nuf7z730/vsM/+QB55d lIvnn179UAPEo9RfLbeVFK5TOB/hwGXYRCpeCTVMyRUGfYFGpwsOFXHh2q2MUsUmUoVs1e1zKFc4 l+61/GHl9+GpTksmgc5NtwqwJzF3m1cl4ircEK+lEvHUzHCH2RRiOxrl29nEQYp5jhVVpL1SS9rW wJRDNYTssVZUkO1plKcxqtCiimbMk1RsZlPgHq4F5++352Pr4kce+6kHf33NnMM+NGfOHIr5D1D4 86CDtXLJoAOSBAFBQBAQBASBCYxA3XIpDHwQI8gQXlBsWnz//fcvWrQIzQk/qlGnm1gJRx55pDbw aS0NWQtNi+Oo9dFwnMNMq2aYsaHB5saWTKlgOSEWDRYe4KnclGDzkR8/accZu7nDU07tLx/6/qaC VnCcEYfLYF/kDeWNnf4Ol+VC4As12FqPUfO7vQSryps1Z7Gc9Hls6kUyTMfwNnjKG2hNEUMU1Yhl h8FwkNV57OhSSHl9rawo9IYb2B6maFRnRjrsHWkKZX/AUrHupkg7Yda9kSCxztsaor3VVGsDRC5n Do8MRlRRMXa5sUwMhpgd2wdKuRa2ME6W7/3rwueKQ6vW93zrlNM75+0esbdxHnaZH+5VLpfx+uiB JEFAEBAEBAFBYEIjULdcanh9nhsyBDHac889p02bFo/HcbLWbGnzOSd0QkdHB8E89eI+bSIck0hx fi7v9OMvRZwmKxptjKVSkaCtNKm03/IWpgRDkJ5gaPpO+7lL1VCrI6SqKwqITFCmfI/ydRGIPGo1 qGyl5jChSslUbyjYii4aS2yMhNuw0Vl8qxDGbDblGpZ+KrUye/JFYDlOrltlp2FbAIXP+ezr2mHa M3bgzfZAGCdyH7vPtIRsshRp763EfGZE9StW6a0tLW10TmZhobLclZp9tkP5S+V4BUuiX3ntljkO b+wXDPo8we3Vhlm7zWnKBwslQjfY+hZyWSaTD/g9bs/o1lKuKUkQEAQEAUFAEJg4CNQtl9JTCBnC lEseqoRreVtb24jt7w1zjI0Wox6mK0gYX1ENEsa5Y9IpZJxKdWgoHmmOJnMFiFSmkCViU8ATxFqG H3gQXkJg8Gq+YkZsouMw4DtQKLfLRcwojwVpgSxVDNMsVYcCQfuiqEKRcHO+NOgxm6vVhMNC9XGk EgXDYQaClklgJ6MWrxKkgEtDhIZTIqHYf8/AWKeU31KpMkTKntSWkOpL1VqCRrYa8QVTtaIKwb5U yOmzCVZWVUIly+Utl4g3WnBbQRbuDScH0RKqoWKi2h/OddIQvvoFbHo15YbU1VSZzZYdVYgUlVk/ qM+RoyAgCAgCgoAgMJERqHMuhUUPYx9uUqhNeEGN+JWPOuU4uGlGxRGBCvo1arXXCp1WtVyONkeL VeXz2EzIts9pqcjyoSnZyXAocwa8g/8K5WDQmSzjrO3Ylc+1YsHt8tl7BuOB7sDiN5yxKYrT42TL ZDa7Cw+7balg2I1IVihUIHmOmtVQq+Bj5Qp2vGZdC09CezNrxRYoGilosXyRmraXfUuQwVueqhuf KztSea1UzgbNFtPwVAIEk8JNyg4QilGS/zvtrZBJYYob6JYjQFB2kltFbRukuwomXMjwwP1MOqZ5 5/Bw7WqSBAFBQBAQBASBCYuAdsip2+FDoaBEkCQUJkgAUtMWhgr/sPnK8FLB/4NIDbeCXMS/hVyu WqkWiiUuUS6yVm705LaihnI7TZs9YaojSqidGQ5QMPoJm5SijTEQChgIoyDPQNgSR1fR3+JABdeh hCGQQVeD8ZBnD2ZbUFLVXD7ltPwQqYHB7uHCTS7w/2fhSbRPI2T4RlNMMlwI3U73gTwZYnH9/6fK J0FAEBAEBAFBYMIhULdcCjlKTyacAFbBi5+P9uqzsROhz/WXuvKWiVepjMKEWbBSKxVclsPtgls4 DGtYHBrtErl8MpEiurlti3MYJrpXsVhyjA0/fdbWSerDn3SXRhpmIJo5UQ0WRUAHJDf4DUsRtacX ncc/jPqlMpTLzOWzLpcnX2CJYampsZ0tCkea2jwDm6R9WiPDt3SDqxB/izzsShMsBD8KdTTUzVuQ EkFAEBAEBAFBYOIgMPbLfJxjoMmHFm/gIpp5aB4w6sgId0k5DGyEhNk609g6ltMyWU5HBI1QQ4Oq FBKxwVgiZTtFjZG8nmg42FKuGKUSJM+B2XHkQqOeoYnUCJ0iQ4K+UBnmNHIKQ4NFjbBA9sDRDmGM FP8wTnFabmQmjISmwwVHsikg7u95W8F6kwnaBD+jw9SnWY0k2tgIqm+yHakmCAgCgoAgIAjUJQJb 0mnG9YB52cMk0FdIfX19d9111/r167F5jRUTYebMmfPmzWttbYWvwBiQZBBmtsC9ICPO14hTkcAE 4UgjjlOoPWOtbctmCj6/2zJdRfbDGzacBYOBUrnkHHZZ2hxquj1SCC9kLHSGI4WMgiNWSLqqWQ7l 1GGVIvxpxNMLHsnCQGpCoaIRyjNQLhQu9DDKRhrfPEOzJK1O8S2X0xZGWiZP0lIfjVMNlDZvQUoE AUFAEBAEBIGJg8D/vrDrb8wYv2AkyD8PPPDA7NmzP/nJT461iI+xE8wTvnXKKadouQUmAevSHGJU ZLJV5Xew0K2qChlVLi95eXnHjJ0sv81yRk0+r5tVfSQXMchrKl+wiY45to410ojmSVAlOkYh9EX3 UNvgNLvSlSFSZDS5ofNaSUoms7g+oV0Fg/7167qJbAsOPt9YlM9uSV9LG/j4iDhHa6+88squu+7K 5TRF01fRXM0+R5IgIAgIAoKAIDBREdiSPjHeMYFM8LKHD/X09BDYHiI1lijFSN/3vvetXbtW2wQh CiPGrLFAIEZAMo0OVVVuXy4VP+IjH/7bHXduwbM9z64tDmIgDDuCE67c1Cz2tcgGm19FkyRkJyx6 mxImzaggiIhDkB7UKfJkaAHdCK8mLRcx9ltuuYWxh8OBxqbmAw88KJ+rdPf0fuYzn12/fmMhvyWn d1gUV9Ft0ix9oOXddttt+fLlFOpy8KFc2/s277yUCAKCgCAgCAgCEweBeuZSvOnhFvAnbFsQKc2T KBw1JRIJDHwQEe3GBJ9Ay9kC94IEBQN4mhsq3uuNNPT29Myes+NYzKi88taOjqkb1iYJNZ5O24yL JXEcsb6NequhW9FzEiSGRM/fYG3UmpPu3le+8pXLL7+cdhgm5VAcOs8pF1100WWXXYZpcHBg6JJL LvV4TbfLQ+xSvz/gZk++sRPSFy1z1FXAhGYhUttvvz3Nah8yLgGkb+jV2E3KN4KAICAICAKCQN0i sKV36ngfNPIS9AIqwCsfXqKdeziSKEHs4agNWPAnzRLgEJw14nK+BRsfRrKCepWtfVV4sqr1tPuC Q+uCcKn1vzrv5M9/+4rbF4cMo9kw7l1WGyyoE/f6lDO5ZpcPf2Tf03/kDoL5C5dc8RkEntlG2x0L ewngiSHt9m985oFrfr7vYWdOec/eG1+8bXKo6UsX/ax1RmtHV/u+B16yzOGIqVdUcu2V3zpnkjGp tXXSvWu6s5br8Vt/eeuPfnTBBZc5QnP7s2Ysp6oOjHRZZ7XXX+vxlTbEDVUMWfPm78tFmjoXs/vx 0gcH95huGC7j/Cv+aYdVqDz98K9uNtwNdPeEo497cUA5zOdjy+7/xAGf/9GtfzQmNT/4xPOpNfdv v/s+qwvKVXD+4vOf/8eimw656FCjyfjmUV9YYi/vW6uy9zx8/z3h1u38hnHT9790xEFfeDqJEse4 +A8NrJa1czZkkgQBQUAQEAQEgTpDoJ651AhhgrXAn+BJOo2qS1FHm8+YYG3G2vJM59KqWB3eYQ+S YFkbEylIG5Y2h+X89U9/fP755z29aOHRnzji/PPPb3Crr3z1VNOlfn7tTV8570SnGrryK1+/8Wd/ Xrmy+9s/ueTYY4/sJ0iTZT3+xKITz/jc4YcfeuON1+NJlVOO227/29I1Lz799zuff/KJQlpFlPu2 73zrkp/e9I9nl37tq1/5yJ4752Jq7733et/7g3t85NQH7vqzo6IiXuKYM6fumsN1zHGnfOmCKz5z 0heIsx5PqmyhmM4Wcqp21HEn/c/3vv+TS79yxcVfXb4hoUzf8rU9Dz76+OOP3vHIX2558LFYmV2U G1v+8ve/fOOiiy7+3iVzZk5zEbI935zNFRzhYirZve+8k3aauu9tpDt++egLFVUrDa1ee+Ahh114 0f/0bPj7sqWvLnzw4S2jJ98KAoKAICAICAJ1g0DdciktOzFPMCpIEkcoFOLTCJHalFeRx2ill85x 4pvhUt6AijjY7RciYatKbQEkMF9eVZe+ujo0ebuFD967w/7z999v74HB/u6M2vWDh/UWd9p+zpTd ZhJZoP8PP7/z+I+e5wq3vefDe6YHV69atbaY768Y5asu+5/PnP7R9+4yJ5+JFVTx4UWPdkWmuKo1 U2W9ZTyzhq7/4fVnXvyjhsmB987d3d/g7FnR75g6Kdg5fda8j83bq7NlONq623LniynL03beRd++ 5sZr/3DTTxo94Wf//qybBYOGu6K81/7m9x85+qQzP7G/Sq922wv9PJ/9n/MOeO+Oe+4w5dgDd3/4 yRfyyrWxb4jx/e7WBecd/1lXtRD1msq1i8teP7iuXB289NxvnH7MN4468KiT3t9831PPZgzr6ht+ M3PXuZ8968Rg+7RLrvhJc2hS3fyFyEAEAUFAEBAEBIEtI1DPXGpEarIVo03CCsCWdAKakQxcitX+ fKTwzXApqqVUKlnJGgT4zGTYfWbjhg0u5Qg3t4Yao7tOUyq2LhT0pjOpBr8qDMZCnvflCoQi6Fbp FY2m9a0f/mzWbvtOn7m721fNZgdcnoahVGLu3nvjQEUPQn53Q2CXYBjDWHl6Z2eQHqFTsaFLSV16 zteDzZMPPfQDmTWDZimp4oMD2VLWHSmmbfemNNvzqVoqnYFDunyNnzzhtFKy59D5s4/88IcyyWx3 75A/2LrP/M4MfvDZDabKO13OeLb8w8t+axnW9PadH7vv+UBja5ldbZyesC+yw/Yz4yre2jkpnxxU uUg6hYCWWLthxbFHnTEljMGu31frHyxV0srqTmX32GceBk9VYXOaFodhx2KQJAgIAoKAICAITAQE 6pZLwY1GbHZ4SeMFRUJ50pk3HCmnvvaOgk7BpdCxmH5NrUa9D8oFAiLY+6jY34bDXo8nGo1mVKHm 8lhe70aiaUaC5WI2k03hI+RuiKbzfY6a8rEVn9M7GC//+bo7Fy95PFcczKV6dt5x+1hyXaAh2jOY CLDEjwZLpXg6NxS3N8dbseylsOWJEBC0kqTVL1/zs1ptbTw+WKsVdtltOnsBBkO+VCrhjZiVfCUQ huMYjdEmYp3j1p5JFw2Vu+mGX7Iq76477pm75z6ZbIFtAL3Kz9pDr9M1ONS/YsUrF1988VNLutf1 vHLEITslE0m3cjH8WDYGQfQr39CG1cNIVgx7O+ayJxheuWa9TdzcLmii5fY2qVbL6V6y7JUcEp0V XPX0M92JfhsWSYKAICAICAKCwARAoG651MjcwYfQpWBLUKXhSJP/e9i0ZIRL6RM1lxppZPOM5YaR eLzsdof/tuXs6Rvw+Qk45Ujki/lSeQpiVXLIMmtdk7sw11UMy6OeWrP8FbdqUdakT5567DGf+XAi Vojnk6tXvGqZZiTUWXV4w9EO/NAzuXLQE/KHfJGI6s29Ormrrbu8oR+/JnPymWefduX5p61aWl2z bs2K5Dp7RWAxn+xdne9ZOjRUMD1mLDFEV+lGX9/GG66/IeJzVVX1meefT5Yz791rv5cWv2w6zN5u lVVDeV80XapFIsFKZiiRXReNRP/x9HO/ue9FRznXn1sbDQdgVHYUB+WKdk7NVcismmwbETsGEw5f i9fenkZVYylvdgDf+uSpJ5z4r4cevPzyX19x6dc//LGPsKXz5ohJiSAgCAgCgoAgUJcI1D+XwkEK WQWqNJYopTUqKpAZEaL+Ty7Fxnp9hb4ioc4xZ6VT06ZOHhwYaMU65vK0dHTYsoyH9hyZbBrfc3Pm 9p/7r/ZPHjJ3pwOPUdWuL133k9O/fMzuUzxTfNNmzJy+fOkriDwDQ7l01g6b3uS1csliNhsngELQ 646nBtr8HSWX2lAbPPbbl33p5A9vN9uz59y5M8MzXlgxqALBb513xmO/vLRt2sy1/SlfCBeuSqmU a2ls+M7Xv+pwGq7Q9KM/9YXbb7mjvaPV5/V7ndbkNrpcTHrbraZJqlp+75yp75s8fUZ76L9O+/Ip 53zjT9/75uqli2N9G5GgUplsX8VeZVhweEMtfSteXVPIRTyBabFab86O8d5Qdc7ebbvtStmh3d/7 vt/f8Zcnn3hs0WMPXXvDNVmFqVGSICAICAKCgCAwIRCwNycZdaC6nOMbMlTWhRwhHCN54gjwUafh sAN23AGSLtcl5Ee+eumllw4//PBRL72FQhgPV+S4ePHi+fPnb9mxiZpUYKO9J5544oADDkCFIunC kUvwUfeTsEyPPvroQQcdBPGCBBElQbtPjXmJGmrTRofqMMDPeEXFonln41Cg0pFautS9o9ulpqle VS6usLqgR53Zpcr1bNz4RNL0TEZ5Glzsb9w5UVHBobwj4sliLKwVnUZVlTy9DuIOqIjv5aqajfYT UPhg5VVi+vqwalcFs2Aod1Jt8KUi2YSvKYRnVW2Dqr4wVD4ciyML+NyGTe1qlZRhelUua3cRvyhn pTWyIwsPvYGh5GA0FERsgr21rMiGIz7VqF5Q6Z0HHWbFl29KedY6VZNrUUBNUfEp2agdxMAoqAb3 yryaVFZue08+PMFqsX6jwpdNvcFng6E9fIhfT1cce0Et213ZR+/60/yPXv33wYd3CnlwmbfDmVoG XfHRRdveOdzEtnEgCvysWbO2jb5IL94WAvydLl26lD9z/YjgI4+aYdv022pWThYEJg4Cb+F5qN+n I8d77rmHsNgghi2Iv0T+AEmoGDpDyUjavIS/WZ2o83p22IVm2IOZEprVx21zRkaPFblt9vXf6hXh wllYxylMzFNPPcWRyOYE5ESmGrUdyBmU68ADD+QmYFkfRCqZTIZC0JUxku3Y1GF/Z0/xTCIWQGI6 KAvu+PrLuRXyMEOf7aNsFhYy/iNBpDiGsYM1cxJOVDRC2E8ieKrW1z7PRjCM2kWd9iGshtfFuYeJ SBNlQeWDEdnJ6FRmZ/T/N6kZ5vCXXrvzHYHXusPCQ5oM2dvMkGby/xn2hUm7QdmGiz20O9UuOcA+ RO2O2VVs9jPd7ujrKWJgfhxOrWoP/i2VN3Y3zJhtvP+g+cte2fDq0lU/ve73c0PDZ9j3l6192kSK tC0RKbs/kgQBQUAQEAQEgbeNQN1yKYgUlIjfpuFw+NBDD73vvvtuvPHGpiacskdPfHXEEUdo+oUu RaUtEanR25igpaV8oWPytPvuvdvlDWRytdbW7bafOUwBJygeMmxBQBAQBASBiYVA3XIpiBQWPT2Z KFJsJ7du3TqkSNjVqDPc0NDQ3t7Ot8hRkUhEy1qbNjLqWVKoSlVnMFgr5/bb79CqKhaKNa/Lba+B lCQICAKCgCAgCEwMBOqWS2GOxT0LSy3ciJgIfJw5cya+U3CmUWcWQyz1sQBCpKiAQKVdpkatLIUj CJSqZadyZfMlp4tNBl1upyOVzvn83mHT50gtyQgCgoAgIAgIAnWLQN2u44M8ZTKErLRNddpmR549 ekec2t6QgUVp1kU15CuOI7IWeUljIeB0u1h04A+EXE4v2/DgNBgMeM3XXAbHOknKBQFBQBAQBASB +kGgbrkUU4SnFEd2NeY4QqcQn0ZNVCDYJl+xoA/THqfoIxlJW0AAcx5xTqlQHPbptwOv1wql3MAW TpGvBAFBQBAQBASBekKgbm18I5OEFkUe2QmShBYVDL62AG6kgs5AuaiJIoVBUJdodeoN1eTjGxDI VYt+h6tQVoV81eVy+DxY96pO76bL/t5whnwUBAQBQUAQEATqCoF61qUQmfRc4UhOECmMfWMRKapp yqXlK61IkR/LUb2uboG3NxiIVKZSdVnYUh3lvHIQWatWruWJjSVJEBAEBAFBQBCYEAjUrS6FqoTj uZ5DHKfuvPPO7u5uHQRMC04cRzJU6+joOOSQQ3TQBDylOMXv948EqRrlXsjnlMeKVYoR02/vU0dy 8I/NTZM1FcJhKP+o8uy/FklMZabX/MpYUovNMSIqp1Z7ieJkR/jszql2RLCC6nWp1nxBea3nCBZV KLSm3GVDWXbMp2RMeX0JpxsDmh3OoZTOOgNeOwZpuZROOQNR2KJpf8xUlCtfKPjdwRqxzO3In+6S fWQlI72q4AJm981wZovVksPhtdggZpUamkZYrEQt5XcEQaqaW+moTe/xqbZMXHn8quKssItMeb3D CsZV2JNXHiJu2gGiPKkqQNrO5T42X85Zfu8ypbbjOx9qVA9BQAMrPRtnqI2FdIeb4ZmIVv0WEbLs IVcrqlApelwu26OqWBhwuQOliukkxLskQUAQEAQEAUFgfCJQt1wKSUlzKfjQ3/72t9mzZx9zzDHY 7zDz6ZnalEiRX7Zs2f3JmGYAACAASURBVMKFC48//ngqcK629OlwU6PPrIP4mA6v6UmVMkGnXxUr tUou46oFTFUqBvsLQ81e5zU/uHXe549tcg7HxCw6DN/w5sC1sk1DSipvpqtkHMQ1z/clVVdIVQsV h+lzu1VfreA2hqcmGFb5fNip8D+yqchgotwUMCx2Ga44vX46li2pkNOoZYum14RI5cslj+XMDA49 +shDe+y1T0NLh1kpu5xOg+0DVTUZj4caGoa5Faf64FM9PdmGdmeprKCdsdjQQ79fu+MXDmzzuPEy GyqGnc2QLE4sV8rEsR0+pZhRLodRrrpd7NRMqkAAy7H4kldfDM3Zo9Wb8hImtE952qySqhIlHVbm b3ATkj2dTAUIL2pV84WM3+0t5RTr/lxuhlCyhEjZSEoSBAQBQUAQGK8I1K2Nj4gGek7gQ0NDQ8SX IjNCpDadLk2qiHz/8ssv63K4FMLLiIlw08r/m3e5SiX8rQtuy1Hs79tnzuxgKBz0hmbu0PXgg73N oejal1d87WvfRL1qgjolh3JGC6IOcEMh7EZcymN62Ay5WiSqeXs0ZFMlh9unskPkoobfAd0gVTnD 7EnFiYFuc8Bgc8hSiXhMOTzKtDUiH9StXDZ8UVW060OkiJ/VEA7e+KMrn3z4ER8xCrx+w3INx9Ry sDkOdRzVklOVH7vrFivY3t4RamgO77vfMZlcbsOGdeece/ZQLKfYf8blDDawbzPJUPmM31LFqkpl qsplE7iAy5FLDdFWtYgepgbTlV333DOHrsaoHFkCwDfZMdv9aGb+BlUopyu1QiAUTA+yCKDsqNl9 cXpV2RbzvJlCpgJTkyQICAKCgCAgCIxbBOqWS2GhY1Iw1eFyDovC+QlG1d/fr3ffgy29IeEjxbo/ 7aKuoyGMmAhHn9xUwenEVma4DNPldQ0N9F9/w41L16475OD9P3XsMS+vXuOwfDXlzKdVv9qowu6y MwqJqFZ73UZ7PoWeQ7KVndWre55cthA20d3Np8bf//YPh33wHGhRk9PmGuxJo7zutiBi0rDzl9+l CvFwQ4Qz7ZOx1xWSbHeURaBaudRvuv+1MobIpDLJUC0/o6srjgOT3YrKlbHGKRuTaqmWTaQ3rDz+ +HNv/9Xvi8XyokUPX331j/wIcT5PrpapQu5KCWVa8C42KM4mU8rtRpOyHCrod2y010SSisFgpJxc 73AFk1UVae56ZXm6rYHtjvuVAyqm+stJU7nLNVUoKvZlNI1gOZP0e93YEb2e5nzGpn3pvN2Q1+23 AygMrwG0P0sSBAQBQUAQEATGGwJ1y6W02gSLgkvpiJ1ITc3NzbAlkg6LMJLhI8Gl4FL6LCaRrzhC vMacUJ8tC5XLBVXL4W1dKhZ23GmXyW2TLrzgS+V8pqGhqVx1xvOZRgJ/FpP//PUPv/GrJ4bKbA4Y v//Pt55xxjVpVUhXXz3/uG9O32HS+/b+0OTJu3S0q42rFn/y1C/fc/89zb7o8hcepfWFDzzX2DgZ OW2/vXd8FdqVRFayich/X3mNw/CEXK6fXXVpLA6fUR/9wAGFavmjnzr15M9+UdWKViE+ONB37kXf Ny3XUceeUIHWwKio53AagSavZRATfmP3egjTe2fvvfvu7bHkYCAI2bFWrHh5znZTpvsDX/3Wr7Ay +kLTlj/xRGdzu0knjNDq/vwGrpZLXHXeCfffe/d+B39wzo679nT3z561x7o+6F3+mbtuu+Kcnzz2 yDKTeJ2OSSuWVzwugMo/9MijnZOn+p3Rn171tc+cekpfP+5sNoMylLNaKrIRoSRBQBAQBAQBQWCc IlC3XIoQ5/l8nvc/uxTDkMijNqVSKS1HaS5FXmc4wrTwrOKoPaU0qeLjmPNq4kRdCVoNysDMlnea jiVLlz358rJ5+3/g7C+f3djgL1esiK+tkFXNrkBmYM2SXitvN5aqZavPPvtqppZ/8OG77/vjPbVy eWjolba2tgULnrIs91fPOm27rp3uevyZjpC1dMmLHz7quK9989uDPcvm7rz9rru9J0UD8e5vf/Mb 3/n25ff+49mXXnji51d9/+yzz15fUd/46tkVwzr/kstPP/d8FYnOmNL8qeM/lXf5/3zL9Y8+cPfd d94Fo/E4VK5YLsR7zdbOz5z2kS9c9LnjT/j0S+ufMy0VDPri8aGkin/64Pd/69sXn3fhhVf++Cd9 OZVPrR/s7l5w/XXZVS8df9pnP3zUsY0hB+7ury7916dO+Oy+hx39l9tvTA0Ougwvtju3auwZ2PDN 66/81Mc+9/ADN336hGM/f/qpDuX4x7NPHXPcSV//zmVPLf7nKy+/uOB3v8tk8wRPGBbnHJWKqFJj 3mXyhSAgCAgCgsC2j8DYXGHb7/sWe8hWMNpUh7aE/Q6dCTo1MDCAHxWJEtKmeapRf0SOIg/T2uIV lJNtalRa5eLoUsVC7uJvffvAObN6e9T++++LS1QilTdxabKFrXI5O7gx6/PaYCcKqeJQrGQZ7kWP PZDMxxYsuP2OO+5YvuTlNWvWtnTN2WH7OW53YK/dtwtsN/WuO+70hpu//MWToq1NV1z6P4hq9y5a iYfU9ddf9/Nbb9t97o5dO+18959/f/Nvbs5W1QEH7Yvd770HT99t1y41uLpWyRx70qd++N3Pf+QT H5o9tX3F0peGCmp9WnldljvEAkHzgm9/7/Zf3bbg5ht22WWPmxfcaxlsswMrNH7/j8eOOuG4gz54 aKlCbAPlCYb2/sQn3n/E4d6uyF6772SYTts0V6s0BH3nX/TVL375zPfMmYw3VblSRNRalXqmqaO1 yZjxUvcr8+bu9JGD9y9n4sVC8k9/+Vv7lBnHfea4Hefs8sNfXrPD1ClenxdwMWAadnh5DJdCp7Z8 r8m3goAgIAgIAtsuAnXLpbTUhIGPmFIENEedgjzpkAfMxogtT88MH/Gs6uzsRJqCTqFmUc4uNG+o tuk0IqaAXaGUV96oclrNTU1XXnVVplZ74P4rPnHY/KeWrGlpaY+nkn4flq+haIhVdi326eVup8MK h1tqxEhY8q8ZDTP++te/3nTTTUcefXRjI0EPnG631+fzp2zCUrj3vnsP+8hH8YVSlZK7KRpPJBa/ vAJ/b8KKRpvbshjtMrGujlYuMJhSZTyznFayRMwFIr77h2J9x5984hqcqsrZWdMnr1+7ugXVKGB/ m8oS1d2tyukjTzl4Y3fvwQfv95mTT97Q8yqDRkPaYYeZ/NPe0aHSGdzJ8Wxfeu+9sxoik62Or194 Xgm1jfZr1XVr1x74gUPJsqbQpapRd0MmraYFd1+2ckV71wzsd5jtCqnBYjbptByvrHh1zq7v4Zp2 1KlKOZNO1Qw+4V+lBnP9tKbcYuQDGkmCgCAgCAgC4xKBuuVSOJsnEgkMdtAjNCqOjY2N0Cl8p0h8 S0IRgWORPB4PnlWwKMjWFvjTpjNcsOmW8teCthN4xehNZTymz1FRe+97bNekxL133/Py0M4lZ4Oj n7gHU1dEs1NefAIlJmW137bivnBIBTPuA/b6UHH76oLbbrr/98/98YarTj/9fbgnld3uVPzxKR6W vzVvt9OUJU9cZ2ImNFtjQ+0+FTx0OzjHpEa/FVz3SIeRUf5Jzxc6la9hei0/kK0FwsFAkVAH+HkF WDbYsyG9PZ10h2P5WkNzh46eCQUMeg0Fg7HeW6nm2tv8t153vSr3/Ov5VzLZ99Z8Ld7BsDLWZtVz qhp2cY5zcL+PnXj6ZfetzcevvO5rJYJLwYA8fdGgM98bsBf6VdNFf62/lJ1qh9lalYuUhvzdEZzV a3PijmfjhQED3/QWa/26h6yCIgL9c6u618daDKIwQPNy6xq9zURRxTHNRlOSICAICAKCgCAwDhGo Wy4FbSLQOTOCIQ+3JwgTGU2kxjpSf926dTiho0tpA58WqEadVoIm2Yn1/HipV2vhSMO6dWsHB4vX Xn3z0FC6o7Oxrd2lShv9AYeqFJJx828LriBO5RU3/PhXv/hdNhvz+dVHjjhy0VP3/uhHtyx/te+l ZUv+9dILlUq2pmrJZHxwbcVtNRxz9DFLlix9+plnSqXq3Xff1du/Yc893qM83n332/+SSy7t7x/o 7hv44he/sOeee4RDnrYZO6T7+/713Ep7K0HliKdz0aamYf7kq1RrlunA7IghzQMZM73VXP6nP/1F IoEbeenmm28hUlVHR3tDQyiVjdvLA1WoVnOqaqyrS6V71syeZVWqBTUY//WNN7REQ4kYelh2Y9+Q y+WxNTPCgQJXNcZGfAhbDaHGXDZrq0zlSsekSbDWSkGdcsrJTz609PLLfvO1/7loj1l7Q13xQ1vf 2xv2dhG5wt6Begt+aXZ/JAkCgoAgIAgIAtsuAnXLpdCcIE9alMLGRzgANCpW6nEcNWE4Q7jq6urS OyJj4GPStPvUqLOXhgGQoCEu1BZHzWGeceYZk1qjF1109RlnnH3yfx2VTC1tmuLO55OoSod84FR/ m6/DCj7z+NJzvnzi9tt3JOJqx+nz7v7rA+ed+4Wdd559wAEH3H77H0wz/LGPftThqDVN8dxx15/2 2mufq6686rBDD3W5zFNOOek3v/5N11Rc3a1f/fZ3zS2t06fP6Ghrq5ZLC35zUwDy0jrpjLO/eNq8 vT/w/g9XU7lQS1c8kRqO5hkjvoHDgOhgjMNwB9eqOaJt3/vedxujbaYRufyyq66++se77rpLLN4f 8LstKmXzsYGsGWkYjKlApPODh3zs/M+d1NE59cD3H7B24Z/POPVC5e8INHVYLpfNmWregdjQ1Bnb V6pcIoTf1bQpUyjOE5Qzm2+INuEzNnPmzIf/cfvDCx/o695w+z0LCpkYlbtaW6lFPPYgsagkCQKC gCAgCAgC4xYBYyyTli7n+IYMI9WFHPHXHsnjn8RHnfRaOZ3X5bqE/MhXL7300uGHH/7v4obCxBU5 Ll68eP78+VvQjfCUwoqHBAUfWrBgwUEHHQRPohAiNepFYV233XbbUUcdpQNTUYeuakY1av3XCvO5 cjpuNbUXYkPuhihuQOWkcoZQgFKpasrjaPThF2TTl0zcE0kNqa7mRE4NlGLTQxGVKT3vd+4eS4NT PhQkNrmzUIi73Q25eN7t9KSrfaFgS7VWrLC7Xb4cDNq8KJetuY2kwxtmEkqFQr5cLVVVIOiDEVvl nqrVNoRRrqzCZk4VMsrThHcUo82m4h4ib74+jEohZzoqVdPfP9CD2zf7ukTCnZlM1mX5nG6CsCtP ZrXyN/fk/W12rHP8mWqv9DfPjBopY4XXnJFIqcbgCqUaCrGmckT5sxnlq2wYDOGH39a6ngvGBhuz oXKnE+FuoJxvInyU4e7OlvOe2rR8LX7/3+8+4RNXvrz4mVBTJpV6taNxZyJfVY2cgwChWz099NBD s2bN2uqXlQu+8wjwKFi6dCm/SfQjQkvL//ff7zvfEWlREBivCLyF5yGvY/7WRo733HMPUa8ZP24z /CXyB0jiLawzlIykzUtoRyfqvJ4d9qThHTWcaJZ/t1lwtaVqm+3eW+/YCGeCP23cuPHxxx+fO3cu GxgTsXPURp988klW+cH2+FazKDgO8z1qZQpz+YrXY2JxsyANtbI7YqsrzDNEilRRGaeRh0gV81WX 31VLVINm2tcQSJdUwGl6I/Ab5Q+2UdMXcLgVUT2xrXE5W+jxBolprgK1BpswFXGg8pXLRE6oVio1 r8+sFKhTpbrT7bGpTxEmYgfSVFbUUBWLKOou+uymY4Vsyetzpob6glHb7T1dsKkhpsliuez1Byul cmsLHTCKJRQ2rl6zg25VrBQB2f2TVDGPQLUxX+1wBVHnprTYd3BQBZMFiBRZPjawAUypFleQv8qS zsY5lHLd4lAu0ogvlG0qTBR6wp6mRL9KVF+c0nbIwQccmym9+MTTi799yS2dHXzv9zfaHUOjItop GUmCgCAgCAgCgsB4RKBuuRQGPrgB7AEvKDYtvv/++xctWoTmhB/VqPPU0NBw5JFHagMfJ0KkkLXQ tDiOWh8ilcvm3C6nw7Ty2azlwsqHBOMgpnfNLPKtx2hLpQeDnsZCouIOQ7tWms6AS4WH9zaGQqls seRz2ZEa3B7oCeTDYVkeaFm1VHJULYfTNTA4EGkg1qfyej2ZdMYf8CeTKZfTMlloZ7B9Xgxq6Bm2 s1XgI44aMQ08FaJ5wuYcA4PJpsbQ+jXdnZNagAIn+4Db5oUMzemy5SaumM3m+AHgYRtjHRJ9uNTm knliIwQsR6WJXhc9tWSx2syGyfQvH3KrxIAKN9ErNtlTAcNBx71WUF9VlbKuYCc6k9ciyIHT4w5m syrcjDt828aef7zygtdwr+rYuWt643uSaRUIlIxhymW6VDrVGwhi8pMkCAgCgoAgIAiMPwTqlksN r89zQ4ZgD3vuuee0adPi8fjg4KBmS5tPFKETOjo6COapF/dpE+FYROq10+09hYsBn88zvF+NXVir eP1oWa7qcCRvr2lLNKVKwW1HAFhVSUxnK2JfE47tZdiSzzU5U+gNe5rRmexwBLhnFYtOyBlRLFWR zW+aGpuGhmLRaGTjxg0dHZ2FYj4UskWhVCYb9Psgf7bgWUOvKhPcnEiZpWLS4w1V8knTE/I3hti/ ZdKUduq7X1fXcK7CGZySAnIXOx47nZBGPqJHQaryBUKVsssfLvMuVtxBo4ZUOZoKGA0hU9XYUDmV TwQ9tbDPVt9SVZQ2+pxV5ZCyvPlK2mvitWURl4FQBzWVyRUDIVc0ydrFih3NtL21rX3eFOWZkVQD kFn2b3Yo9j9mZ0BF6PiA+EwxDZIEAUFAEBAExicCdcul9HRAFzDlkocq4VpOePER298b5gsbLVoU ll1IGF9RDRLGuWPSqWqJHexgInk2/CWeeL7g97hhDYg/yXLMj9Wt5rG87J6nAlHCFKRqKm76VdC2 ftUM07bpJdLd4UB7uhL3mX622yNuuPM1U1cJfuH3Bwv5EkQKnzSIVLVWgThVKkXTdPkIWoWZbdhy nEomg+EwAagKptPnwlFrwPSEsxWFeGXTpHRSBUJFOyhU1cFaPnvrOzu5XJbNwGxDtoOViJizKfS4 XQ6Ha0gN+VxRvKRcLcMXCBvwpZQz5q5Ggx78tAxUpixhqhw2q7OXBrKjjIp7zcl2086IzZQirpJK B12tOZVwYiI0bYaFVJZLKa8n71UezJJcL1tNeoeX71k23kSyGl3/sy8iSRAQBAQBQUAQ2IYRqHMu BfKac9jBtTexZI06I9CpTZkWRGPUaq8VOux3P8oMG7OQbCL1egpZtmHO9ilCgMHryU5BQx0FpyAZ alf7H0tBpPg3YNo17DZsPqMT+o7dOA5RHFGM7CM7KDtfq/G/FWk3PHwBiNRrpxLwk9Do9odhU57t veWyqdJwESa54USLECmdf/1fLmRDFOV/DKXFdrniP7vPoeFC+9Qp+hQfX7+WuqBWXjXj9Y8+ZV+f sukcvWqS3ZSdbP9uLwKcijIk2yvdTjAz/tOJtZCSBIG3jgA/e0iPPPLIW29CzhQEBAFB4K0i8Npr 7a2eLucJAoKAILBNICBLMreJaZBOCAITEoHXhIoJOXYZtCAgCAgCgoAgIAgIAm8XAeFSbxdBOV8Q EAQEAUFAEBAEJjICwqUm8uzL2AUBQUAQEAQEAUHg7SIgXOrtIijnCwKCgCAgCAgCgsBERkC41ESe fRm7ICAICAKCgCAgCLxdBIRLvV0E5XxBQBAQBAQBQUAQmMgISEyEiTz7MnZBoE4QILiUz+dbuXIl UXnZ7YAtNQkXxxZS5MmwcxR7SbGrASXkqUMk3lFHTsBeovWy0zmbs3IuNdnBk7PGijZHRLpkMqmv Tp7NFWh/6tSpnDtq+1IoCAgCdYmAcKm6nFYZlCAwsRCIRCLsTX7ffffBnPr7+xk8ZIgEqYLcELCX zaNgRWxhSZ7CsbgULKqrq4vNLqnDXpns4Am74qx0Oj0qoFSDQlGTq7BHAjGBoXQnnnjiqJWlUBAQ BOoVAeFS9TqzMi5BYAIh0N3djZ7ElppHH300FApGxeDhN5AbRCO9+QGbfEN6UJhgSGPpRrfeeuvH P/5xTocSwbdogbM4hTZHRZPGuQR1IFKcxSk33XQTu3nqjRZGPUUKBQFBoP4QEC5Vf3MqIxIEJhwC mPCgMuhJHCFMMCHYEhQKAxxfQW4oJIM6pRnSWDY77ICoUFAoEKSOJlXkUadGxVTrWzAqneEUWoB4 jVV/1EakUBAQBMY7AsKlxvsMSv8FAUGA/SVNGIxO0BpNbmBC8CfQwQyHUEQdvsIqRwYlaVTU9Nbm cCkSxIj6en90Ghy1PoyNlrku38LkULw4hesKlxoVLikUBOoVAeFS9TqzMi5BYAIhkEgkYD+IT5Ab VCgoEUwIGgQEfIRLwZ/gN9RBsiKj2c/mAGnbH+fqClAoSrSmtXllSrSzFPyJK2p/qWg0OmpNKRQE BIE6RkC4VB1PrgxNEJgoCECVsOg1NDRAaGBC5KFNSFAcYTmQp0wmw6I8voIbUQd6NCo0iEycxemw KI4kSkhj1adBVCjkKGqSp00UL66l9a1RLyGFgoAgUH8ICJeqvzmVEQkCEw4BeAziEASIhXjwGKgV hAl+g7wEkeIriBQBCz772c+S/81vfjMW19HaFd9yLqSKBimhNc2TNodVWwz1JUbaHKvy5qdLiSAg CNQHAhKrsz7mUUYhCExoBGBIMB6OkCcykBvIEIhwhA/BchCWUK0IbUAFuA7SEd9STec5YgrkiI6F 2Y5vdTAqTh9pivpUINEUWpTOaMrFRxItkKjGFTlKEgQEgYmDgOhSE2euZaSCQN0ioJkTw9PUR1Mr PsKrMLqhHkGhoEewnN7eXqiVZlcUUkcv7kO4gkhBiSghTzucSDVaYDEgi/soQfTiI3naJ5HR2hVX h1rpPmAQ5CzKaUeSICAITBAEhEtNkImWYQoC9YyA5jHQHSgOR5yiyDBgPM1hNqeffvqqVauam5vJ 49v0oQ99iDos8VuwYAEZrIE60Dl8CKoEDaKQczWXQsp68MEHoVOcqNUsMri6Ex103rx55OFnMDBO Idny1HASLlXPd5uMTRDYDAHhUptBIgWCgCAw3hCAwECnoDWQGBIKk2ZXjAM3KUxvra2tcJ1169YR 1hwrHkyLQpQqjuhSnEg1SBUnQptoAV6lV/DxkWAHMCrqUJlGKIdLafEJEka5JnBkOIsWNI0bbxBK fwUBQeCtIyBc6q1jJ2cKAoLANoLAiC4FDdLkRpdgcYPZ/OAHP8Bst2HDhgsuuAD2c8stt0CJkJ34 CvbDEOBGLS0tmP/whdLSFI3QFEIUJ86fP7+pqYlq+lssg5AqKhD+oK+vj6b4iiMlJM4iwe22EWSk G4KAILAVEBAutRVAlksIAoLA1kAAKjPCbKBEXBJaAw2CUSEvdXZ2QrCgR+hP1GxsbNT7FsOooD7Q I/yf+Io8yhNHOBMZara3t6NgjbRMIXnSxo0bqUOGylSjcTIkLs3HrTFguYYgIAhsGwjIj6dtYx6k F4KAIPD2EBihLzoDsyHBkBCTUKTIY33jCjNmzECagj+xhR/MSbtAwau0dxSWO06HLVFTszFOh3Jp vqUdqnT7GAqRsnQJNaFQwxd87fD2hiJnCwKCwDhDQHSpcTZh0l1BQBAYC4EROjVCa2A50CCEJb3B y7XXXouMBA2CV+F7zrc4j8OfBgcH8UynEB2Lc/FYhyRBuaiMjY8S22437IYF/eJEiBcJmqV7wnWp yVFX48gpY3VSygUBQaD+EBg3uhSPNp50aPU8s3iKIa3ztNI/NOtvVmRE7zgCvFBH2uSdh/CgX5wj hZIZ1wigP0GM8BDnEcFAeFxAenhWIBdRAumBP/GRPI8ObgC+5chdwVncDJoeaTJEId/SIMZBiJQu pE1q0oh+EPHw0dY97iJ9aW34g5nxFXXGNZjSeUFAEPh3ERg3f/M8qniWMTwecyOD5EHJk27ko2QE gS0jwF2kX7H6LsI/Zsv15dvxggBkCBIDVUJkYnIhT4hDdJ7Cf2sImmzxYMH2BzODfukbhpJR24Fd UUHzJ61gcRYaGP0Ztb4UCgKCQF0iMG64FM8y/YOSxxZvRKQp5oM8qS4nRgb1ziKg34UcId+alL+z 7Utr7y4CSEF4l/NYwFoHH4IDUaJtef9WxxCZSJBsrS1xJNHaWI1wL5GQsjR1g8NxLoKWSOZjISbl gkBdIjBuuBRPKx6RPOYgTzwx+cgDjqdYXc6KDOodRwD+jWLBzcM7D0ZFQnhAP5gyZco7fi1pcOsj wGzyNGA2+cVF0j+xoEGa4rz5/ui1ftSnEe2HTrMoT2Pp39xC1IQ/UQ0ihZe6ZnJv/opSUxAQBOoA gXHDpXgXQp54RPJbk8cWv/x4HdbBBMgQtg4CvFa50DCJeu22oYT4QFvn6nKVrYAAv6+IXPDHP/4R aYoHBZyGNBYHGqs/kKE//elP2kQIhUJe4p7ZApfiEtA4jlyR33iQKq5ICTxsrEtIuSAgCNQfAuOG S+nHInQKaYoIxSxy5oHFw4vHXP3NiozoHUdA65qoFGTg4mgJ5Pv7+ydPnvyOX0sa3PoIwKI6OjrY HAY2w9X5xQWn4XHx73IpnjOcxQo+HizkedrQGncLt82og+JeIs4nLudcFwZGHfylcJxCrxq1vhQK AoJAXSIwbrgU6GvHYR5b7PdOPBitS/27Gn5dzqIM6v9EgPuE1x7V9PuVPLrU7Nmzxa/l/4RuXFTQ vueQHn5fwZ/08jp6/u/+1uL24FZBZKIpuBHPHFrTTgWj4kD71EHNgszxROK+4iMcXeugo54ihYKA IFB/CIwbLsWeWfzg4zHHT0aeU1pR15n6mxUZ0TuOgNYnePPpOwe9gTcfYYTe8QtJg+8KAuhGyNUc mWh+bjG5PBy0mP1v9Uf/QuMIJdLemdwzurVR24FvcTmoG/WpqSk71+XjqPWlUBAQBOoSgXHDpfjZ xwTwIuRpRSLPyEHW+wAAIABJREFUT0Cem6S6nBgZ1DuLgL5bRlQoVAfaH8tw885eWlrbCghoHYhZ 5lr6EUFePyj+raujS43UhxuR5wmzhfuEOvqmGqlM/U0bGWlNMoKAIFDHCIj7dh1PrgxNEBAEBAFB QBAQBP7jCAiX+o9DLBcQBAQBQUAQEAQEgTpGQLhUHU+uDE0QEAQEAUFAEBAE/uMICJf6j0MsFxAE BAFBQBAQBASBOkZAuFQdT64MTRAQBAQBQUAQEAT+4wgIl/qPQywXEAQEAUFAEBAEBIE6RkC4VB1P rgxNEBAEBAFBQBAQBP7jCLxr8aV0yBYi3elNG3TgKI46Tsx/fNxyAUFAEBAEBAFBQBB4RxHgJf6O tjduGnvXuBTBgok6TTw9YtzpeJsE1iO+sIS5Gzf3jnRUEBAEBAFBYAIjoN/dvLWhUPrdTYkunGio vGtcCkWKXa44MgGkEV3qLYQqnmhzJuMVBAQBQUAQEATedQTYRJw+bKpFCZfa2pOCHIU5Tx81jWU+ trDv1dbun1xPEBAEBAFBQBAQBMZGgA2UtCLFu1uzKD6Sxj6jbr9513Qp9v7EZYojuG+qS9Ut0jIw QUAQEAQEAUGgjhDAuKSZE+460ClGZjMp4VJbc4qZA50gsyNcisnYwjaiW7N7ci1BQBAQBAQBQUAQ 2AICUCjNnEaOE5NIAdG7pks1DKfN1/HBq7Ywc/KVICAICAKCgCAgCGwLCGxqWdK+OhP2Df6ucSlt Wx05cluQh9LiQbUt3CLSB0FAEBAEBAFBQBDYAgL6fY01ide3XjdGZmLSqXeNS2HgYwJwP9e4MwHa 2irr+LZw48pXgoAgIAgIAoLANoIA8gdvcI5utxuNivc4HfN4PNtI97ZmNyTu+dZEW64lCAgCgoAg IAgIAvWGgHCpeptRGY8gIAgIAoKAICAIbE0EhEttTbTlWoKAICAICAKCgCBQbwgIl6q3GZXxCAKC gCAgCAgCgsDWREC41NZEW64lCAgCgoAgIAgIAvWGgHCpeptRGY8gIAgIAoKAICAIbE0EhEttTbTl WoKAICAICAKCgCBQbwgIl6q3GZXxCAKCgCAgCAgCgsDWREC41NZEW64lCAgCgoAgIAgIAvWGgHCp eptRGY8gIAgIAoKAICAIbE0EhEttTbTlWoKAICAICAKCgCBQbwgIl6q3GZXxCAKCgCAgCAgCgsDW REC41NZEW64lCAgCgoAgIAgIAvWGgHCpeptRGY8gIAgIAoKAICAIbE0EhEttTbTlWoKAICAICAKC gCBQbwjULZeyLKtUKpXLZedwqlarlUrFMIxareZyubxeLxXIm8OJmvU2sTIeQUAQEAQEAUFAENgq CFhb5SrvwkVSqZTP54Mt5fN5mFMgEIBOORyOgYEBMoVCga8oLBaL5PW370Iv5ZKCgCAgCAgCgoAg MM4RqFsuhfjk9/vRpdLpdC6Xgz8hSoVCIVSqhoYGZo1CqJVWrchQYZxPpXRfEBAEBAFBQBAQBN4F BOqWS3k8nng8juxEBlKFgY88/AmxamhoSLMoSshg5cPGB9N6F+CXSwoCgoAgIAgIAoLAOEegbrkU OhOWO7fbnUgkFi9evHbt2r6+vt7eXgohTx0dHbvuuuvkyZO1TxV6FTbBcT6V0n1BQBAQBAQBQUAQ eBcQqFsuheaEmQ8JasmSJfhIdXZ27rPPPlj0cJ/asGHDnXfeef/993/sYx875JBDkKy6u7vhWO8C /HJJQUAQEAQEAUFAEBjnCNQtl8J4l8lkVq5cGYvFGhsbmaalS5eydi8YDO6yyy4wp1tuuQU6hflv 3333bW5uxvw3zqdSui8ICAKCgCAgCAgC7wICdcultC85a/Sy2Sxmvueffz6ZTM6bNw+ChUy12267 HXzwwX/84x9ffPHFWbNmoVdh+HsX4JdLCgKCgCAgCAgCgsA4R6BuuRQu5xjvli9fjlGPpXz9/f0X XXRRa2sr0tSKFSueeeYZrH64TOFKhSlwnE+idF8QEAQEAUFg4iKgF1FhhGlqasL3l48krC68/nAa 5rhpDEUEhba2NpZb4e5CfWw16AtUwzFGh10kYBBQ6qPGlNYmLrhvbuR1y6X0raBvDu6SSCTCHcMN AcEiJsL69esx6oXDYb2+jwBUm943bw46qSUICAKCgCAgCLz7CECVMMXwRkM4IMMrjxKoFd4seAP3 9PQsWrToySefhFQRJ4g0adIk6NQJJ5xABT5yZHkWJZwFx+JFObKwXd6Mb3J265ZLaRsftw63F1jA paBQMCfuG9ynMPyRyEC2KMHAx/FNQibVBAFBQBAQBASBbQcB3FRQB1iQjpkFOsV7LRqNojbhMXz1 1Vezhv0973nPOeecM3fuXEgS6ZFHHnnuuee+9KUv7bTTTscffzxL2iFS0Cbem7wNqfAGIYpX57Yz 2G2zJ3Ur3MGNuCG4A7gnuM/Ic2QO+IgKBZHiboNmQbYo18Rr25wh6ZUgIAgIAoKAILBlBHBrwbqn XVZ0/sEHHzzttNOmTZt2zTXXXHzxxayy4t3HV4hPLGA/++yz8RjGxnfuuec+8MADvAfhUtj44FKa SPFa5AVKIW/PLV9avgWButWl4FL65uC+4e4hbicZbg4KuT+g8Bwph0txe/GV+J7L34MgIAgIAoLA eEQALQpvYNZXDQ4O0n8Y1W9/+9vbb7/9vPPO23///YmnSCGUiApoV9qup0nVhRdeiH3muuuuwyzI 2izehlSDP/F+5LWo2ZVwqTdzS9Qtl2Lw3AeIT9w9UG8sx+T1/cTiPigUR244KBdMnLxwqTdzu0gd QUAQEAQEgW0NAegOLziYkJaUWFy1cOFC7HcY79jqg5XsdBgWBX+CdZGnvg5PvXr16g9+8IPQJrSr 6dOnT5kyhReiplO8QFEfSGS2tfFug/2pWy7FDcH9wX2DOW/PPfeEPHFPaFEK/sRtx1oGmDhTAgEX IrUN3prSJUFAEBAEBIE3gwAsijcdbzQEApzN//SnP7FQ/cgjj8THHCMMBAvH86effppFV7z7eCES ubq9vZ0XImoWFXbccUfKf/rTn7LanaagXLwToVC8HDWvejN9mOB16pZLcZdwb5GYYPg4R24Obinu GG4R6BQ3ELcdN4o28An1nuB/CTJ8QUAQEATGKQK8yLRSgHzAijx2+8C6p4MpYuBDSvjOd74Dl4JC rVmzhjjVDPOss87CZYrl7ZTAq1AfHn/8ccQqXoW8GfXLUYjUm78fxo3vea3s9HqixVK4VImUSs6w x7Ryq6PmmnAkncm86jLTqpz2eY2yShWd8bIv7ilW3H7P+sxgfzbZFG4qJKo1f7TXF4JRkeBY3CWw eO0vBceqVsoOQ8GxlOFQDsvtDw3E0w63L1gOFEv5ordgel1Wzu/KBU2f2efbsMrtbyhHg0PlajSx 0Zce6HY5U6GqLxatRdeXhpLegjfpj1rRpHcgHx6KFG3vd9OwqspdNfxOZ8hnerzFgicVS1thl8cT dJZzmXhGuayGaDEbj1Z7G0JWLjuUK6aLtZLldZYq+WDAqpaTUashU3ol744anqjbvd5X6y8nGxzh qlUyHEUV9oWy6azDMstGpWxV44VkVEVVLdTvWJxSve50NMiaRd/irBk1jaDPF3aYFV9AlSoJt9tR LimjFrB81UrV4bGiRslRqySiUbNYLpYqtomdv1LNOAENDGGlHFUh5TbKAY9lqGommw9GoqlCNVe1 ehNunP9NY9BZ7nMWilbF5/Q2FJyq7DHzJae7FvVVPD6V8biThVom5/AY1UK5lHe6XMVqLVcqWy5n rVqqlXJmKRd0mY5KuVap1pRZqlkV01dyeHOlqsNyul1Oj9NRymfKxUIgFC5WVMYdtZyusCPnLCZr pitZcdL7gJEPBaPJRDEYiMZiCa/XncnGvD5DOXIlT9BTSoYsM1WL1ipmtLbRU+5f6YvCsBHGWQvD kLXKzbOG54tZqyQTccvldri8yWzBYTqdlqnKttWY20lrnxz1rcUpiXQ2aPiiRqScMhJVK+PzV2im oIxqyaFq3GyFSi1fqiqHyVicRtUsZ8GzBhSmw+lyF6tGoWaVLV/Y7SxnkwGPWasWqqpiON2xDDBE K8p0uj21atnrNIvZtAI15s/l0VI/nec+53HAcLi3df7NPx2kpiAgCIwLBHjUaP0JbvTQQw/hZs4j iNXrPLJ4jvHt5ZdfjuHvrrvuuueee77yla+gPKFC8R4k8iIr+FjkzlMLzypcrOBeNILfC08M+BnD p6lxAcK728lxo0vlq0MsM3D7HJajVs0P9a1fXoiv3Jjc2L3o1VymOG3aLL+vYaBUqjjKltfh8TvX KJ+vs3lydX1TsLG49LGm9Dq1Zlljawv3EHcP9xARz7nDoAgsHEUOjQ97U9lOeZXKwMBgm8fd2txY LZfimVy4PZAo8U5MRj0dbqda3TsUaPNYfnfPqlhHq29wsNvwt7S3B4JulcpVarlya2tjNpdxumr5 RKoYNn1e2A/0oZpEJLO8pWoxW6lE/B6/P8DrtFIsJJMDLQGzs60tVvWt2/D/2jsPOEmKsv/3pJ7Q k+PO5r18HBx3Rziy5BcEJAtKOkQEBI4TRUTkAFFBJCgivGBERREFFAQF/uKLqHCkg8t58+zk1NOT e+b/2yspxw3H3rmEPZ6GT93TT1dXd3+7t+o3T1VXJ2Y1tSrRLf2btzldrqam9r7BXkzKjj7vWCIp mc01vH7odKQUoVIU7KaCS/LoDNq+ZLrd3i7nckPRsNfvlXOYq01j1Js0xno4GZNafG5zQF91VpKC ZNM6TL54rFrIR2bObs1mK5CRomjMZGWDTlIUWVfP2i2tBbmMt2JNZksqk8zJFZMoydoyZn5D+Bd/ sYjzgSGixxAQGrNNNJn7Bwd9fr/Vqu/v7TUYxIDHi1BgPJLyNLmz8bjL7wsPJnU6CKAivjeNw6HF NzksSjadTubsvtZcSTCaLEoq43QbtTodBrNpNVrcTEmyqNVaKpd3OF2JRBKIa+VKrVJ1OpxlQ12o 1TLZTHNzy8Dg0IyZszZs2jRt+sxwRslV5WJZsTmcuVLJYrRYRVs2EVIykc6upr7eEF7eRDXh8wX6 +nuaAv5EJhUINuXicrFSDTjtQkyx+NoxBT6uEUMy8YsNBqokhM1RJaHSSeUUfHEol1cMBqNkNtls UjQ85LDbjRotaOCJYn3HqIMgXCA3bQ47rqWUybqcNlHSq3pBWxfKasFoNZstErDjGfP7A2q1DIkm 6iE061BFbq97YDAk2Wwmg25Y3AvVaCpjNElyvmS1OeRcHo9N0IcfFUUoOZ0WQ0pzokeEwisUilq9 vlws2CQLtC9uFk4JNw6PPWpGnA/TWB9spUNHJwJEYHIJoDMOf+b4Y0c1FQqFEH+CPMKfPP7w8YMK P3qxigoN44YxiApOVFbo3UNtAOWEGROw+P3+trY2TF6NegPiCXsxIYXzRDmTe7a7ZWm6m266aZcv DLj5vuy3OzwjlkZ/o43GeO7cuXz3dzU0prJGV9cIpVopqS2F+tb+1aGNxHtfq63rdumqe3Y1OVs9 xYF12sJQKb6lHN+qJrvDW1/zioqjkDTGow61Vsym58zoyggGNI2Y8fzEE0/EZBuLFy/GQ4Y2BoPx 1BratYpGqGMSKlGvrZRLipyxu12lqizqEcZxKQrG7OkMCE0o6ZjOP80k6gQ5a9D4rG25cEpfKuqs JlNBiVXzJpPkkGzlfDZtNBVVvb2mU4tJxB1sDodGr9fqtDq9tlxBVENb0ZmcolCRE1lZkdyems5S xquFouhtaVfyhUoZ4SgJjSX+QiTJDsGh5lWjU5XzdoOgkcQhbUWfL7lVSU3E4sHmZrU+3L0t6g2V QlknaE06USPW8xoxXuzT1yxS2V4pDcrlrX73bI/PnkpnLJIZfyf1muD1BCAO8MeD1ryYr9vstly+ oDcJlWop6G8t5WsujxUCFJIO5eNPEX+67E+uUKmX1ZpOj58vmmFZ4HHrtbVkLFKuQeMBJW6ZLhwa dHpd0AROh7tYzEBVJGLhoqI4nF5BY1LrOgSKCvmS3e5MJhOVUkmPKVWrqsPprtW1IqbuRWAQkS29 1mwUcUeCTf7IQLfRaEqmUtB2uIqurq5EKtUcbCoVFLfNhBFwomRD6AaayetyRoaGJJtdstrT6azV JkF6II5dq9cgyFS15vD541tWZ5RqW6c/HEo4pUohl08Y/A61gPoFV4qfaKiAoKjw9OI5kWwOcHC7 XZGhkNkkRiLRpqZgRlbwKjHeFUXdxEYb4BCov7BXQa0ZqvXhWTe0tVg+FcskjVq9wyTlykVMoIcX JOxWCZiSiQSiUFa7UzCYC6VqOpOx2vCflIhGUOWlokNaiw3qG/N7IK6Wzyl+jys6NKCrs9nR9GBr NFvABP/hRWaAx18mKlbcL1Yt4u8LNw5/m+/6h0YZiAARmHIE8KeNygcLRBJmOsAX0vDGFWodVAKo 1dlWiC0YqHbQ34cGBW/w7b///qjNkAdxa9QVyI+Y1imnnILLR07sCD/sHVQdbBNSVHfYff369Tgu bJwJnNvP6N8JPHxhXr46nsFuBNvKzoR5PoTplOnjM4gu9PyoFW01XzZUa/louNlp9RmEQa2ccQmV DquwX0dtpt2xb6t9QZN1D8/cVmuTubh4VmCvoNVdV048dHGit09jtuIW4sc6Gki0i2gs2XSdeG4Q jsITgE3oJfG5HeVCTi3mfE4rNFQqmdqwctWmDRtrBl26UDbVtW/96a/9g6VyPZ1XQj3b4tuimZYW dK/pogNZwV3zu5rrFUMutGHNutde+tsqi8VZEcpGndZqMavVipLLVtVKsYIWs2h2Wgoo0GjS1uoQ I3ffcU9vz6Bkl5JKNZUt4OeEaBD1Qh1juyxGs85gyijlOsRODV1sdacVE1rUVrz8yiO/eU6EHjMb soU0gh5o0U0mM/op1VItLxfqBkUVVIcDgTab2SxY3OZVK99+5OdvoU8dCkbO5tSqBv1fmBo3k0mh 2Eoxh/NUCoLN5dy8rddmcyTjMWhGvGqLcDH0E/72YONHDFaBC91Tokmq1gTY+OtJpRJFJdfs97rs w5LObPapgqWls7WsynpdLdwflURLZKjX5tLbPPaBoWwhj24zo5wOGS3OTFYxGoxNPp/VaISWyhcr JRV6OQ716fN544lYJpsMNnmjg912mwmdik671en2BJuDG7b2WiRbMa9UceyBDbHI0JeW3/r5L371 pRdfLGZiQWgsjQlSOadk0Y0LueZ2e6ySvVzG3GNiJptweVzB1ta3e8rNbd5yLPHGihXRviFUInhI oKXwHij+kvHY4HoR00pmFbvTlc/JrU0+UVtv8vvS2ZzGMJwNlQhqJeREpHOYhlaLe4H+Sg2ks7b2 zFOPpWIht9OmM+iTWdnh8TjdblxCpaCUlKxBrzWazJEECsvrjSaPz4+QVU6WnQ5bpL/bYbOUqiWo 21A42toS9PuaspmM026xSnqryQAJi+7OcDyVVooiei7x3k2lCP2Hm4XaDQtOBtEyKEssH8I6iE6J CBCB/5IA6ijUzGjU0LUCDYQAAX7ust9RSFGbMRtb7733XoymuuKKKy666CI4ob2QQmbhBGBAUeEX IOourKLqGI4ybNdS/+XpfRR2nzJaqliQSnlJW3MZtV6zqamWNwp6r7FmG0qW++L5TUPpejyzJZHJ agw1s7VusiZyRbvX3zvQj4E26OuJyfmwUsnJKtPgeFbweCFF6wIPHsQSlJpBtFolk2jAQCGDRvXY zSU5ed0tty5csPioQ47ff9G+Aa/5rCVn66uFH95888q3tmWLkb7Q+qMWHZBL1wuFiKBTWn3T1HRP VdXX61ajpfL6m3/93HlXhPtqJrFUKNcTqWwynREQqNHVJDP6/oTerWtEmy1XrFtc3jVvrfzql6/y Oh1DobRkcZis9rrGIGAwTVaGDrNJtlAopjfZoaVkRdbUMaRGUEv5t9548777f5TIFF12qZCTTUa8 l+EPhyM69KNhCI7FbjaWdHWhjj8lgy0jC7VSYv3mTddc+y1/kxsdbAgFVcr18FDc4/EhKlcs56BR MHQslcqmcpXpc+YpxRI6niRxeCZciAnITfy94W9127ZtWIVh1Guq5bwZx/X7MaIJ3Uy+lo7BSBwq c/icBxXJ7hqMhhAkUnIZvzOgqRgtZlOxmq0IVW8An4Ky1KpljZAYimVcbpyFp2/L5kwi7rTZe3tD da3R7TDnsvGBwZ65s2cNh6/KRafXg59gsaEBq2TZsGlLfzTT2tlRrqoyhjEJqstcOfboI1es2TJv v0NFgz4R6sllMxWDJZmK+XyIjdXw0i+6C2sQmFWhhuAV7nQdnYKl2Z1iShZEh+uaq67asvptXBrq ETwkqFlwpZCPqIYQPLe7/YhCmYxiKjakqWJ2jbzD5c4VK6iMUJfh1x4Q4YmC1oR8gRRTMKrMoKuU 89+787a1q17TalT0UltdrmgyV0VEDg9DvWIz4/nIF0oVh8frsJp1GHmWzXa2t+HwtbrG429Ky3m3 E/G2UltLSzJR7O+LmDAwrlTOl4vZZAzROMQ5fcFm3O/evgGtpu6ymRG6x2nj/HHjECrDVeD84fko VGp0jUTgo0kA6gcXzvoNUBGhEoON6giVNhYYf/jDHzDv1DnnnHPNNdew2AH69VBFQHghMzKgrkAJ KAdOZiBFrAEpLTsmMGW0VL2qE+oi/tdoLIJgyRUEQakrRf1+7j0WuubMsXVpNJ5Wvbe5Zg8Uze60 JlPVyVWtYLRgSHkRkR2dkMTw9SY/eyzwrEBIQYNDS8GAUxRNpe2jSaAkCjmMGTKWlcw3b7r+nvt/ /sMHfiWH4qveWPXC26vOWnJmKRvpNOs8/i5XwDR9TnDDUKU54ERIqyYPVRRBY9MPxgWvE6OI0dNX 7mydM7NZqytHRGfQ6PA7PE2+Jr9QK+swUDvV/+N7v3X7/Y+lirq8XAwGmiCgxHq1o8lpNerj6TK0 hVbQOFzOahFnJLd3dijFWrmmYsQQRsmrJcECfSRZQ0OxutZczaQ9FnOkvx93tFqrOd22SFYWJGM5 E2qyi3K8qMglvVGoiSWtZBbMnkhkEDEv/Ok5nV4EwKqILAnoVsfI5sLvH//d0i98wWQ1dPeH0DWG oIZBW4NWgH5CYAaKAT96sODBwp+fWFVysZBTMqaS8WEBpzdv7hn0tndpaplyseSwY4iPYPc4dGIF XK0mQYswnN6iM2jQfwlth3OEoMVtqdb16WwpFU60NTV5MNiqLuy91/RsXi2lh6a1+exmbSIZrtTU TKGUUMqpUm3la68cd+zRbq8PY8Dj6QLGbrswasllF3Jhp8269Nqbzlpy1lFHHm4UMAurNl2sW22m wVD/li2b1q9fh5Fe/f2DbrcPckqWk889/+wJJ5/cLwu5fLWakefPnRt0O9lTgetlAR5IE/yAGx4i VsXY/Do60Zq87mHhrdehk7El6GZVD7KhhoJkQc2FHVE3+YL+cDRiMOqa/U6bWY9+YxSglMqixaoU inX0x9UqkFPo6UP/byiaykZ6XRadUVuLRyN1QVtUNWkMPrd5q/JQ0GU267RFpdTR1QXZVBT0RpfX 40BXoCUt55RSrQptptW7ELVKxlE54tnGc45zgChEhAw3bsd1AW0lAkRgihJAE4bmDJUPotEw8NsP Kgqr+PPHKA54UEGhHrjxxhsxuubss89GzYYfWtiKHZHihxZqPFRx2As/CFF1YF94sAlAmESbomTe t9OeMlpKp89hloOaVqlq8uVaTqkXkoVMQaf2bd4cDQ1kUnEh3I9B3JFIXyzUHe3fWi6Vt23ZbBLr 5UK8kA9Xqol4pq9YT+PBwlPCfq+jvcGzgucGuNH6YUqyKgZMlYp1tSLUqgPdW+//8e+W3/aD4449 SWNw+dz+2XvNPv1TJ9ua7R5tAf0nQ/HetRvenBNsUWQhHu/Di19XXna9s33/ea2zbrj9mZq25HTo hWI92S8YqrGDjz35oUef3NwXKhQr6O2q5BMb3/r7/97zh3tvunP6/AMQWIrH4mpR+ecLz8+fORsD 23/5q0dTGGFer7/9yssXX/iZlmDzOedepBSr+CqSfnu/nxEPuah3OV1eX1A0610GkxyO3PSV69BN tufee9/9wE9crc1ptWYXhe/cdNfesxYE7M5zzv9Md3hbQVuviDa3x4EBYR877PDf/hafEQik0wgL OSDQNm9cd9XSK5956nG/xR1LpkPhoZ5tW1uDAfyxLVmyBB/IhErA18UBDb1a4GbXV352/92/+umD Sy+/zONyXnTZ0nheHcrWn/3TY5decskP7vuDv2lOFN2EycFf/uIhjcXk889+e+X6Eg591FFXXPU1 m10IDW3dtOWleZ2dW7f1Ypj27bfeakbPnb/pj8+u0Is6r1138zWXv/SXZ6778tXNra2fX/bFeL7S Hcue/qmL3nj9tZaW1n+ueN3hNpdKZQz1Sg70XXveGWs3dl908hmXLP3GQH//aScd9/xzzwkYNmY0 7L33Xj293Z1dnRs3brrqqmX33HNvS3PbP/7xt9PPvuL1116f37z3qrXr9ZA42Ux0oB+vumDmujPP PBN1DfrIcLHLly/Htbc2t7658q1MOpWXM9d/+Yt/eubpjx1+RHDafNRTyIkqDJ2neMAeffTRpUuX QoD6tcZQOFTOy+g8Bfhbbl4etNsu/Oxns0rJIJqe/fMzi/ddKNqDc+fOefDBH7m9rqBdvHzJp//f M7+//qtf6Zw24/Krrx1KF+WaSV9K3PjlK3Um/aEHH3LeBZd9+sLLje6mWKGaTcWPPeaYGe3tVy77 YjSZwhsA699+7UcP3o/aE2MB8aoOhkfg3qGKZOrqfatZ6EBEgAi8bwTYbzn8jUMA4ScffveipWNS CdURKi6cCYw5c+agTuvs7MT4FowbhqKCckI21FQoAXshbM+UE8pBadgFO8J+3y5k6h5oyjBSazFB m9boZZ0kwO9jAAAgAElEQVS5qDGVBHNVqWUrYtm2R8C+Z9A6z19tNVbbjbKnWvAL5aA24LIHnOhG K3UEbF3NVl09Pa3DUa3G0eDhwWKKG4oKY2KYPK+qNavVZjaZIcfxbcd8NlNQZPQhH/KxI2XMGZvK u7ze3sG+kpoXkiFRLaADzuNzSFZ0mliLBXw7Wdpv3yP//PTzT/zpgafe2nTAwUfVNSpe8Wvy+H02 4YyTjtOYHEcef/Ks2W1KoQCthpfbu1o8hywQbAcc8cvf/sHpDUgWK9TRuUs+ufSyi39+x23Lb7gx lc7KWfnCCy7oaGvF6xWh0NAVS5dphwOxGCpYFjHASpahwBB/lXNCPp448uBDw/0Db7y24sc/+cnV Vy195Iknqgbtfd+57Vtfv/n6a65ft7Hnkss+1zmrqyjUJA96oORzzj0HRR3+sSOhdAJ+yKk0BlDv s3DBJ046qXPGvKdeWuFyezGO6uDDj7/u2i/jQ5gYqIiPDLCBQWib8XeI3zFCIdO3Zf3Fly5btHDB b3//x2eee+G6G7+BlwB1OvXhR3/5zNPPP/b4k0az8aFf/GT58m+t+0fvbTd896QTTsXPpaXLlj37 3F8iEcHvsz/ymwfnH3r03nvPuu1bt959150bX3/1zjvvPOPMT6bS5Xo2lo2HzvjkZS6n/eFf//r3 v/ndm2s22H3NV332k36v749PP7Nw0T6JZAW3T5azFpN4yYXnNLnN5y//+nlLLrLbrOiqxEUZJWFw sB/dXBgQmUomEaF59rlnbrrxZsiXmTOnf/6SU4Id7T944vczZ83B5AEep2vp5y/DU/Hzn//8qaee evnllxFt+upXv/qzn/3slVdeueGWb+LEMIedRcJAusSZ5yw5f8mSXz78a2gpyBdgwVt+eEX0rLPO Qq20atWqh557zmQ2i067z+c+84xLTSbjDx955M9PP/3yKyswRM/tct3wtesH1r96zNFH/e6xxwsl oZ5P69XCZRdfjIH29z/w4OOPP7li5ZqSRvf9O77xo/t+8cZfnn/opz/987N/2do7WNXqE0pp8X77 HXLwQW+sXReORK9YelUW73KGQnfcfg/ef77vvvuOP/54jAiEFsSvVTz5OMOpW1XRmRMBIjAeAYge DCpALYTefLyLgzk58foLqnf4oZNgsKoJc3hicin8SkQ1hd/D6FhA/QDNhMxoFrds2TJr1iw2GADS CmoMlQaOyBTVeIcmPyMwZbSUy9SG8da1mmQ0uwx6c3wglNzWbczI8U2D4VBsMJ7JJQrCFlm/KiVs kNX+cnTbG2peCYeyPf3hULRHMpTq0awn72WhTjxbuH6kLKqJFO+tp1LRcrmqqVsksUUvtLz+cjTg mJazlPSuermSqiTiLTYnpgMSMAWTzoTX3vLJksngQ0+XpSJs2bJqdUa44a+vztvriKOmqcdPly0m t2hqrRZ6P3fd3Y9HZv/05/fYjdlMeADzBmUqzoTiamnec5FV2uPjp82bH7SZ+63GSlo//acvhM5e dsHhR5SE7OGqbc3G/MPrI+ZFR3xJ9YVOOX+vNa/W08kCRtHg9axyuVhRc+iVw4hDk1Ho7//LKtm/ 9JE3XPvse/K+0s0f3//vP36oJxT6yX0vn7jktnOXX11ryX38wMWG9WKLKlQsv7/z6/etXLH+V795 LF8r+drdCHBIZsxDoAhK7bDjpqWsga6umfs4t77+0O0tzUfude2NC/yab375cpPF+tLq7jRmN9BB g1bthpom70toBr/4wIPnXHrjGQe3/PbyC1f9fnVUp3jlf1qFY+74xb3zD6k3Z5/+x/VPf+Oyn8Va Uicf68LcDX9bmV542CHl+itr33qwnJF+dr/5wqs+q5V7f3L/d5bccHfG2rZoptNX69uw9VVN2dAT 677wpp998eYfnXGQ4/wDXG/+aW0p4DjyiKCmdOBeCw9z+nocatFVM2ukctrePm3h2QaT/qT/aTts T2MAEzFl0ONpjFWFWWqurLH2V3WSJm3O4gU67y//763jPnnMgW3ORTMXmD0L5i/sajOpQj1c1ZZP vObrd9503xlH6M/Zb/a6NdWNoXV/fvi+b33he5pg2+kHTCvXzSu6UzUlnY2Fli3/9plLLv/4Pu31 lp502maru03Cn579/ZU24YAbr3/I2G445oiPtc80C8paqaBb8oU7ltz64PnH7HOvK/Pdt21Rbc9h xxxx9NGXOb3q4jaXGmtdXxH0lZaU2nv2zbd96esPLDnMu2z/1p7/ez2iW//YU8+e/YVXvAuOnrdw w4/vPaQQ67DLgq//qm6lesgR1+C10CMOCxZC5XIqbnMNYDDaijUbDz3qE9NnLNbr7DKCjlatpY7f IMMjTGkhAkRgNyOAYBLEEOQRBjxBD0FUrV27Fr+dsDAlBIW0YcMGqCh8VQaxah6pQlgBYxKgtPBD Ebvvs88+rMOBhbhYuAs/LHczXO/F5UwZLVVE8Gf7fOXDsRCNdjiKgxf+NfrW9naX0+3zIpqAQcC2 QLPHHbA5/ZIY8JmDQUfHdHvbdGtwutYeLOgddZObQ4TixvPH03pN63RihsZyoZgrlGXRK82e1zmY 2VbNK/jao9jZVhoeIq3xWD3oDixptEkF/Skt/aGIwYJuaSGfLtgtwgF7CzqjNa2UBb0pFcN8SLY1 q1Y+9uuHrll2md8XbPL5Mf2kIis+v9Nkxtilak3UCsWcw25UMZ4c785Vi13tQbPRgnmpcI1mEa8T Ds+fcPa5J82efsx1V97e2dHq9znwjlu5UsUMjQbJigDP8BwOZcGISajwqldCxYSNRpdnweLD3t6w xWCy2Ky6Yw8/eCCamC51CJhQ02AciKbCb2343v3f/dZtN5vMBp/fh7fxUsksXoMT6kahWMF7/phJ EjNpaR3Of65448QTTzDhpXudiLkJ8KPnxb++kM9VjaI+j8HkGO5UzhSqSmdXB0SmgDHy/gCMZBwR RFsggPfUBMlkNUruglq+4/vf/tgee8479ECD1VIvVbwG6aTDDvvnX18ciIV707FDD1ikpOMdLZ57 vvvdBXOajz3+dExJWcKrisUq7vjcmdML6PDEaCCjBX15mJIVo5EwUAjjvTBA3OGw4TcZao0Cno1g cDAkp+MJjNYSJYtRxCwBRnR0YgBWvlC0WCSn14eOXGegVbKYMcWlmh3+uHUmGSkXBQxpF7SGdDZ7 wL77QpBhTJrN6dywcWNzS7NBNFx907LF07sWH3Qk3h5ALyc7Ir694PfocgjpCSaDKGA6UczysGFj z4H77Wu1CjbJPtSXxEkJWnO+WDpo8T7YjonK/O2iVdTNCnY+95tHDznsY0bfgfd8/yd5BXE1Qcik 8KnIhfMXoJ+5pFaLmEJWq7PojZmwcMIxi5Ws4ILyUvWpnJxBgFHvwiD60087dcG8Pb5xy52oFpuC wekzZl637OrLLzqvtan9xb+siMcUDLnDjKDovizWpszfO/87JYMIEIF3JYDAEvQQuu0QkUIfH/oQ Xn31VQSnEXlCM4cFJSDFPHlYYEMqQV0h8gQDtfrmzZsxncGBBx4I8cT007sekTKMIDBl6lbMmqM3 DA+jk/GqeBb/5wcGwkOD0WQ6OxgaymYzuTTmG4rkCsloZmAw3ZvVl1J4B06oRQuVeEENpQuRTFEe fnVveN4LToHFMLFaLlX1OsyRXYZCy1cyQiUZaLdCJD360x+hf6SajuCFe0yGiD4vzBaATj+dpZSQ 81oDZmzC5EOCzeDKp4W1rySyhZoBXYt4I9DpzSn5fRfM+8KlF3znK8te+efq3u5YMNBsFg05WUnK qQLebKtVHUKhUqjorE4V78qbTUG3sGXTFrO1CZ09JUXX2jRXKaQ2rOqNh/tyhdxvf7s8HZehD/QG UyIto93GVJAQDLiLePvOVC9M9+lEoZzPV17f2LfHPgeVKiqmAFjz2t87nPZ0DYPRMdWBw9Xc1X7A 0Xd8e/nnr7y8p2cTvrkUi8XbWtvMRkdeqQmYOrOtDcPMLKJQSMvBzhmvrlhhxQEkh83lgfY85qgj 8KpftTT8zr+vtVVotcmFlAmzj0OvOF2DeB+tLrQHW3rCea/fUlYEg8bY3ZeqS+Kdd90WlgsbIn3r tm3ef/6CVqP9mgsvuff+Xy398pdO/dz5zS4L5rvMpRJXfP6ycr329rrVazZvnbbHIsFgTWey7U1u EbOUS47hScCrFbt+OKYIOSUahydryKSziGOjJ6tYKNSSCYdDdJptdpNUgDDWVC2SSVUwjBuTzmsw Kh+KvIIvXqdTLoetXq3k8cpmvS7p8DKdgLEGuLk6vanZ7dTjdRYtZs6sds2YMRAaxON35/LvRHCz 4wO9Q/2nnvoJm8+HUZyAkM0LeJ1PkcsYk6DWhZyimT1n30RmUK0JlUJ1VpcbE4EJokspVH0uS6Wk mO3GHB7lsrK1e+3Fn73481deXS9t/PZ3bnbaJbxPIHicmJTVbrLWKjX0F+ptmDy2rq8IhrKwcfWL DotQKwqhkOxpCSAOWzW02CXhhf/3HIa1ITL6xBO/wXt/etH0pWuvW7nixc98+vQLzjkTk6Ch48/i cMmVuoyZp2ghAkRgtyOAH4QYpMGiUKiUFi5ciImFMT5h48aNiFEh8oTqERM6or3DgrmpEazCSCkE nLAL4lWYVgrZMO0i/Kx9RDZAamwrdztmk3xBU6du1Qh4BR9TMdmsDkwOBKkiGiS/vxWRA7NkQVQK 0xlYzEa722bD23IdPptdtdrqTodosxickhlhALdVtGPay+0Lf0RgMI9W0OHrK1BZdkzcpKvGMiFX k/TZK8/43d13PfH4I/FCuqoX/v7iS4/+4tHYtr4Mhn+b5Ey27HS3CWoC+sVtbT54Tuf3b/1KMp0P RQp//PMLRVWr0RsQbLj6iosuvODkU48/JZOUc6ks3sUPOKWqRjB3TRvKF/MDGzGpANrKCkZCYQ6k aGGvWXuXajZBiOjrdjlRbw00XXftF3o2JYYG0xs3piRMTIDzQ0+jCXEPZzyZyMlJvL4WaG7x2oyP P/TTipxct7X/h7/548IDDm1v8Zz3mRPu+sFNf3/6j+Hunn+ufDNVqmCO8VBP8tTTTrji8vMPPujA NWtX223DEzGUS/VAe4dQMyG6E920pntTRiNKHz/902++/fKbf3shHE0/8rsnEvFEWzCAaQQwH7de qwn39VXSA63twa9ff8PGLdE1W7Zc/Y2vn3LGGUK+4m9flEj12M2YhUHTtc/HDzr+qMuu/uyLz75Q sxl7hwbLuXwplj5g4eIOu/7v//fiiZ/+ZDWfMUri6Sef8KMfPvi7J//h8gZ6BiOI3gja4dibmkti eNjw+4YGK/4xVhX8nELd0dOdQMc/pqPDTYTExFel0N9ZwgSW6YK+pskW8/aA+0/PPNX99qq95x8A dQJF1dfT29HRjonX8eUZyWww2puzqVQpNRgfUkSMWMuVMcVTLhbpHsgJhuEP2oRjsRnTZp5x5mlX fP3SV175O6qkt95aG4nEcR8RJ8dEmqqK0XIus9aVSReS2bTDNe3oYz+5ctM/77jz/kw8+9Lzq+PJ vKqxYlKMYiZq1hQw71akqq0mw81uO865UBXWb+l9/q8vbNqw2gEBp5ahhvRVjWTU4rMvqWoJWspl kK666LCvXXvBbx95eNmVX7n2hkdUnerrRLRrml0yfeuWm/HyKUZGbNsWwrypa9dvWvH6ygWL5s3o aDIZMLKrJGiFWXPn/uPV1zEGf5LrDyqOCBCBDwEBSCK0ZfjZj2GsUEX4+NVJJ50ECYV5OyORCCJS 6L9jrR4iWIj0MxWF0NSmTZuefPJJxLSQH7UZtBTq0sYLwl5MVzU6yR5N4D+ojd784fHoMd3hcJcM dEc1Ekn0dA+uW7ulZ9uggNfAhz/XppYVTNiN8U6YNsFsdPtETcGsq9pFrcdkdOMt/FoB32irxrYM y/J3evdwdXhQ8PQgyGHB9/HKCC0Y8dICvvynNRpcTf6v3HjDN2656YrPXTxjwZwZe84544RjEuGk 5A7UfT61ONji7ZTTNXObp29oU7B9zwe+/5NN6/62f8esvWe1v/HmasSlVI0OcSOLWf/97972Pyee cPqpp6DzyW23rt601dfcXsqpZ1+87O8/v2+625bG2+uiqZhPY8LyZDyVzZsMRkzAJC7a65Cnnvz1 88898T9HnTqztevar3xGQlAKMzOK+B5LPRmOIcAxfVpb95ZtJnfzw7946OEHvzejbfYRx51x3qVX X3Lp+ZlwaOlXr77krM9ces55C2cedua552wI9aPfr8Xhx5/NLbfc8smzz8RbYGyWbfRIhrYOqAbH /osPCPjtRx5ywG+eeOroE8+46/bvn3/CUe2z9vzazd/85cO/nDdnpt1kCA/04AN8mPTSIJlVyIRc 9bj9D9trryNn7b/ghuVfbHcY8C0Wi60S9AgYph8dzH7zvrsvX3bxhWdf0O4NfGzffVe9vcrZ0oL+ uWOOPWaP/RbOHB7waKtm5VvuvuvkU04+97zzJJd/8eKDXnt9XU1vb21ti/dvhgyQi6rZ0wzJrM/H P3HSJ3DvDl606Omn/4gRlggRoR7JZLIVi7k52OY0WKpK0eH3LLnic3fcddcpBy++6JLPBDqmYRKn 9unT1q9bZzTo61XMepFSapazMJY8F/n43jN/9djTVa2lo3OmRVBNDismITVarQ63eyA68LUbrr/n a3effOChzW0zTz7maMTDK/k8BhagnsIjA4BCyeT1mnxNdq0usMeehzz4v3c/8MNb58+Z/4n/OXLd xi2Zss5id9YKWZ8o9mNGTp1nr/aAuV49+6xPXXfTjQcdcWxzW3vA5zjykCMVURdobg33DKL7N1ut GDwuk1kSi/VLrvryZZedecPyy22WwP9+95vpXLR3UGhqmv/sM0+++eor07s6Or3zvnD11fj4YCSe PPKkYzVa94033fDt229Fj+jAQN/gtgHMHo9eSFqIABHY/QhAKuGXJAYeoBqEQoIewhsz+CpfV1fX 97YvqKl6enqSySRet0KTB0WFkeYPPPDA/fcPv/N7wgknYCjV9tePhmcbBh+0kkiZ/Nr9cL0XVzSu 5GQoh3XHdqbcYJTZKtQuM5Ci9w2rbEHMAAuzmZ95WO8s24SRcaeddtrELwml4SuueF/LjKhIqv/R H3zTrcYCFgzwseoD3v2OPQojgQZffS3osyXUpOrU2QrdZcFVLpkFuaRJyxiuvaKveMJFX0lb/Oyg eEqw4LlhUU2Ml8JobozpVmvoaMEXjnGyJXwqpG+bUjcW62I1mSjN7VxorGGAUxgzV2+zNs8om9Gg 9uoLbpujvqY/0N7VV88YDWopE3A5tNnCWp/XqSQ92Wza15INZ2Z4DQVzHcNcilp3M77Q5zNXKrGt WcN8iw09cb12s8su+qsYBCPkNKKSzgc0QsZuKUAjegKd4f5ySVuqGfKWjK4WGLQ791aSgkX3ktU6 Y6g3KE0T1MibVnF+b/+Au7WYr2K2hDklfOrYn9Fm11o1B/VHeuqmuMu1r85a6g69GrQeaqwNagzm eCbvb25NxPEhnLpJW0f7nZRNNt9mJR7Ipk2z9syvXDUwo3XfmtidLzhCg4MzZ81MxGIYBiWZjToN LiZtd9RPO3WfT537i6M/cXRv7s1aybigbd76dWsdLoNZ7xV1znwhI0olOZ/0u9s3r4s4m3VK2RD0 t9RTMbua0TZ540o9VLO6dKU2XbyWkqute23tld2lbl9Hx1slx9yCmq286LUvLpUkRf9GQbF5HbPk yhpvpaeonritVGnu6qtF/cYqonihXC3gM2Y3rA7NX7BvLpOTiwNun22wN+2U2t3qUK97lqxRZ6sh g1IJ1Vq1TlGqdKu6LjH8NnhFnHPRJTpd7a8XS1nr7KqotSpPWu0Hbcl4PU34OrWc6bWlghVjJG6d Pg/VjDW0GrOv5PxzN/am50g5jeTFjPbQ4qjMbDY7/iI2bt6MCcoNNa0B82MJ+trmPqPfssmIz15X 2guWNca2FvX/HMLMbfmWXO3VBXhlcsCnzJSC1VxSftNpOByfmlatr1VKklvcI5EdbC72ZO2tOZ3a bKpfcMF1b2b9zz93rzPXbdIKSqarN73a12HRlKZH4/1NrVFDcX6pvFUjeKwWn2gWoql+rw/Tygul AiZVHZ7JghYiQAR2MwKY8w9iCDEnaCO0XlgQI4B4woKxUxjiyeLoUF1oTPv7+yGqEMRasGABvtCH RhAjqzBwCr8Ph5va7SqKNZFYRW0Ge0xc8CMDUsTAEOtCGGz27NmwUSBrW2HgNJBigYcvoz3scEiR h9vsoGyVndWYp/FhcA6/zjYlFo1Wg7gUej3UUlnNFRAv0MnZ0GDfnJkuragPh8KYSLyoaGSjNlHW 5MqqvuYpCQ45ozWVjPpc3WC01j1NvUrNIPxrxkLcMNxOPEC4fNiYNRHf/4AAHO5vM5jwfGAAuFLM NTvsqtMykIu2z+wqy2o+U7S6JBzHK6rVcBFTfkrNermUnD5zTi2jWJowi2i5oGSK+BSb2xlPy6Iu aHF6KhrFbKnXy4pakY16MYdGW2McjOU63TPqWUxaWZPc/pKCL8HhU3Cys8ldEawOl5CKVjAO3agr DGzbqNdNa2m2dce2uWxz+3Obc+WKqQ7VVtRXUiZjMBrpbwnMSA+UZ8ztHIq+LtoDUGROiyAPbPC3 N29ZVZwxG/50tS6EI/3TWpqUbUJF0kWGorP3mLO1P9rS6o8MDtQ0Fa1JL6tWLzpSvfZithSR07P2 WpQfEkz1bLnumbf3XqG+gZaAL5OM10oK/riqlWquL929OuzS2IsJwWA3Nvnbtm7Iz5vdGi8ZNaWk xZDT1GyJAqJdklxKdwTbNJWIZHMOJOJGbdnsNFfjEa3WbasJibra5jKr2Cct4JvBgUCLYBCqGMNu d5pKJk0lbxAki81Zrlsr0MgWDeY5KEcFq2Qoq2XHcIBbty2esHia5Zo6f8GiZG/K6bNWRKk/NtTW Mq0QLmJoOMaMYwi9gs/WyIXmGeK2WFFbzWHo28zhqUGVgpyw4KPFca0L32HRaTbG1YXtgXI8pxS8 dqGai0Ud/o5kfRDfId6WquPzinZ8LTifj8YL7e1OTSKXiuZMtrJp+IvCdpPZNhTdvO8++ySiGZtY 3JIIQWp1ej3peK+1E3FKvyDXHZKAqTdzkYLLJ/hsc/ODPT7vNAWjATU1HN+mE9CnnDEZZaViVIVm X/DXN9527u33HnHS4jeeXJEXdH98O7Jube8hTdqqVsG9xkea1boMhRdsaR2Krmtz6qsGi6i3hpM5 g77iC9hr1Vw+JTd5Z2XpKzJTor6jkyQCO0MAbRk+XcWmiYKcQrvGRMn2IRD64447DiGMlStXIhsq S9gYnA5phQkRkAHjFqCWEM3C2NPhnpnto9S5fkI5sHfmXD6ieaeMlhoWtfgwG+RAXcWb+TNnzDak xT4laRB1uaKy6u3VmpKuGMk0B4MpXTFv01YsDkH0F2sGv2RGi26ECNe7FIvPVETr+e+uPXbb8YSh /YZQG/6GLuaoHp4gXPD6HJDIQjqq4A07g0YpFox5fdBtHUz2G/2YECHs9cxTk2UlH3E6XdUwvuVr KtQi+PpuZ3tHPFmGmsdgbX1dG4sNf3GvrORselVTrZiMllSlijcN84IPk1g2WcwDOVnjsmGkiwMf mDOYY9mM3mMvFeMup1POhkUDPvbXgrnHo1HFFzDXhlQMKowrhmpBsFokXV1nQbtrtPTF5YClJTkY 8zd7B7Nlg04wmwSbR9qQibS0dGajstvlxqvy+OYLvpjiNqI1N3a2z9jWE/E3B3CBGG/mkPTZxJDL p8cYfq/G7XF5Crp4OJZy6zz4tp8qaDEULNDUlIgNWUTMj65arNZ8vSBqLU/97jGHtD/aaEmyRDKD rd65lcGVJed8iwZv6KNLcY5Wj8HX+LpeEd8xtkmOCORJizdXTKcqyaoiux1+K+6Qas9m4nZ8ELqC meoFAZ8STOY6m/dMRwR8wUZrMcd7UzqrajBLqixU81nRosWgMYzvFnUiOmezSaW5vTleqGJSeGMh 57Ta8emYslSx2PE5T9WMtx31hhTEbkDS5LSWQGBwIOfwWS1li4CqI4GvyeRdTglz6ZdrGsFmLck5 m9NWQZVkMvqtQiwRn+d2FaMZU7MY64+6p3nzGYMST0lOp0k0JZOqTasNeL2ZUncsHm5pnhGOVNCb Nji0ymWZm5cRKJpeqxiEBLrvNDWDWMjXTRUzXkVUq3nREMzhVcRKGSPe8R1ofJCnUFbNqLg0QjQi iNM1NreznhSKqeyZn7qw7dRjI3LSfs7l+y8+Oe7CTOkeMRvCh6kxdWssnfZ0SPkifhVoWlvbgQjf QsabBCarVVNTErFBfMXR7/IW5biA2CMtRIAI7F4EEG2CfoKKQhQAqggpBBMCQogzYTgHtsJGFArj otAJiJzQTMiA2BXiCLCRH1ElVKQYw86VE4sGYRUL7N0L2ORfzbiSE/hwtO0Y/8PgTmzCDWAZkOKu YJUtuElYmM38zAObGdi0s318OC67ndgXTwbe4YIMx4MCTc0iTHhW2AJhhJxMmL/jG/4XfuSEHykW rDIPUuTHJUw+XSqRCBABIkAEiMBuSgBNJ1pkpNTHN2XiUky04Z5hgY7Gm1O4eWzOVni4NtoukP71 Vuf2vMOb2MJWIb1Z/nfcw//CA5G3mz7tdFlEgAgQASJABIjAe0hgymgpKB4mpwADNkKRCFdCETMN xPQQS5lmYnEmnjID+2IvpCwPUmYjpYUIEAEiQASIABEgArtAYMpoKXTSMeWEFH2FuFSmhODnl83E FvMzJ/PwFE42to7vAoPLrEYn2USACBABIkAEiAARmAiBfwuRieT+APNAQuHoiDwhRSwKAggeyCa8 lQBPo1pi2ojlRwa2CztzLrNYHrbXiE1slVIiQASIABEgAkSACEyEwJTRUnjLgA8V5/KIdepBEo0W SdIqZ+kAABKLSURBVIhdMSfLA5utMo3FtBQAcYNtnQgyykMEiAARIAJEgAgQAU5gymgpfsZQPywi BZGEBWPJsYlJIqTMYJmZzQNUcI4WTCiBl0wGESACRIAIEAEiQAR2lsCU0VIYFwUlBHmEgBNiVLhO hKngZGKIbWIpQ4Ax5kxLNabY1DjWCvmxwImU3uNj3CglAkSACBABIkAEdorAB6alhmNKWi0UDKY2 YPoGASTIIxZGGn0N3I+9GsePc/+IXVi8aoQTq0w8MT9kFlNao7ORhwgQASJABIgAEZhEAmi+hwMY 20MYrP1FikYc/kk8ygdS1JS/gA+EGh2UCBABIkAEiAARIAKMAGkpehKIABEgAkSACBABIrDrBEhL 7To72pMIEAEiQASIABEgAqSl6BkgAkSACBABIkAEiMCuEyAttevsaE8iQASIABEgAkSACJCWomeA CBABIkAEiAARIAK7ToC01K6zoz2JABEgAkSACBABIjDu/FJsBgikbAYmNhUEeI03n1Pj/BA8M+fL SmtcxcxSmE0KHja9BEt5htFGY/mjt472oMDRTvIQASJABIgAEfiIExjRIr8rDZafteyNKabLRlOO 1hkLGnRkw2IwGEa0v3CyQyAb7O3Z/53wre96Gh/mDONqqffipBuRgTtwsxnMMVcnbgmOiAk2zWbz mIceT8ON58eNGrMcchIBIkAEiAAR+CgTGO87H+O1m2igmTxqFFIAaLFY0ASjNDTixWIRDToacXgk SWJ4Gxv93Rv4+6GlGE2ewsD9AHqk7CMw0FW4JbgfhUJhPG3Eglijb8Z4t4rd+NH5yUMEiAARIAJE 4KNMYLz2dDwthXaZNakj0lgshkYcpWFBW4xQCJpylgerWAC5Md2Nmb/nWopzHOb6DlkY0FJYmJHP 50EftwRyit2GiRMfLz871sTLoZxEgAgQASJABD4KBMaLWYzXnjImo7e6XC7WarPmmzW7sGEwmxk8 3Y3Zvh9aCjegEStoYtXr9dpsNtg8HIVOVtwD1us3mjiyjXayosb0k5MIEAEiQASIABEYTYC1yKP9 o9USy4OmGcaIvbCKcBR6k0qlEj6SC32GsAj6+BCaYjmRcmP07qOPPqU974eWYkA5U2bkcrlEIoEP G0NR4TbACbWEmzGelmL3cuKsx3smJl4C5SQCRIAIEAEisPsRYK3w6Osaz49OJGRmWxtT9AkiCIIU jTgyYJgUVpF5vNDU6CPuNp73XEs13gB+DyB0nE4nBCwkrclkgraFkIK2hZBit2Q0X+QZ7YSH3eMx N5GTCBABIkAEiAARGEFgvFjDjmMWaMH5ggJhY7w5C4UoisIUFRp0BEqQYivLw40R57Cbrb4fWqoR GcMKTzKZfOutt3p7e+12O+4HIlJQS9BSuCWN+bk9nh/78jyNxnhj6BrzkE0EiAARIAJE4KNGYLzx UtBAY6KwWq3wo/kesSCW4fF4EApBA93U1IS+pvnz56PxZVoNmccsbbd0/mv6qB1cG4OClBm4B8xG 2miDKfPAyRd4EHxifuBmC7bCgyjUmPlZOdiEzLwcnB5WkcLPUm4gzw5OnjYRASJABIgAESACEyEA GcTUUqOBHZkqgpMtCHywbOjRgwEnPGyBDQ9G7/Cc8LMM8LO+P7aJp9wPAwv8zEDK2ne2yk9jIhfy /ueZ5LgUv+Z3vWzkZHnYLnxH5odUavSz1THpsPxjbiInESACRIAIEAEiMEECvNlFfmYzg682OnfQ +I7YxFf57rxAGLvHMmlaisFi4SLGi9sgxTxIITnH9LMMyMkzNPJluyBFNr47W23MRjYRIAJEgAgQ ASKwawQaY0KNNkpjzTecfGGtNvNzmxns6LAbT4OvjsjD/Y2Zp5w9aVqKs+OYGCBw50oIBhbmadzK dmEpyzOCI5zw8JQbI7LRKhEgAkSACBABIrBrBNA68+a40UZp8MPTuDAPyz/Cz5xsL2Yj5avcYE6s 7gbLpGkpDoUjY3T4Kgy+YBOz0RuKe8A5QiRhlUkl7oTBPVxFcaMxG9lEgAgQASJABIjArhFA+8ub 6UYbpcEPT+PCc+6CwQrkO+7a2X6o9ppkLcUkDgPEbKCHgYUbuH6+ylEyA5tYtvEYYUe2OzfGy0l+ IkAEiAARIAJEYOIE0P7yRrnRhhOFwNO4wIlVljI/9yAzbL7wVXYmzD/aZp4pmk6almrkAlJYbUwB GupnBFmWhzuZgWxYRtCEh5fAtiIzDKQjctIqESACRIAIEAEisAsEmDZibXGjjaLghKdxYdkaU2zl q41Hh5Otsq2sNG435py69qRpKQaLyyCscruRDsvGULKUAWUp10nc2ZizsRxu8wK5hwwiQASIABEg AkRgZwnwlneEgXJYU9vo54WzTXyVGyP8fJUbrNjGVb7vlDN2WktBeELxsAVX+47577HhjQiwlc8X BT+QYWElYJ4Jtu+IeaTYN2SQh+dHNtjjzS+F8huPyG1WAl8lgwgQASJABIgAEQCB8dpH+NFGI8P2 tvrf/UuYI4o5WQaeDfNLsdLgYQvbccQ8Urw05OE2dkTjjjHT8LD51tkm1uKzrUinyrLTWmrHF9aI CTYy85Rt4hmYH9Qa/WyVHYJlYGljORw0c+LesPwj0vH8I7LRKhEgAkSACBCBjxSB8dpH7uftMsPC m2Pub2yauROZuT2eMbrA3YP8pGkpRpYJHQaR26P5woN71qiKGE14oH+RYoEHKYriM5tzJzeQh+ll tntjys6n0UM2ESACRIAIEAEiwDXTCBTMz1pP1o4jAwzmR8qcIwysNi4sz5gpKw2bmMGOzlaZPXXT SdNSHAojiNVGXgDNhBHbihSrWEaA404YLA8LADZmY3lG79uYh2wiQASIABEgAkRgTAJokcf089gE b6lZtvH6+FAOcjYKKe7BjrwQ5mSrrEDYPAPzTPV00rQUQ8Po8JQZ2LQL80hhL66oGimP0FL8uI15 yCYCRIAIEAEiQATGJABxs2M/Gla2sGw7q6XYvlxjYZUdEQYKZFt5OuaZTDnnJGspFi5ijJgNgkwS cXAwgIn5R/NiW1k4iu3IymE5mY2UGyz/6HJYhtF+8hABIkAEiAAR+CgTYMpmNAH4WZOKlBvINkJL YRMrgacw+LJ917ETFMU2MIOdADzMmNLppGkpDmUEKYaJORvT7XJojD4+3A8UhZyQU1wwwcO1Edux cXXMG4Ddx/STkwgQASJABIjAR5kAa2dHExivj4+3yzDQOrMUu7M2HauNC8vAt7I8PGUHxSrPwDxT PZ00LcXQcImDVWY3IoPNFr7pHce/sDbSxCbGmjlxq3jhzM8LadyLbCJABIgAESACRGAHBNCejrm1 sdllrTOyjTDYKs/ZaPCcfC+emW9qNNg5wDPmyUwt57haqlG4cC4wWO8bu0hoWJYNKQsj8b1Ah6sf ONkqzwNPuVxGIeyOMrhsXz6PFCucOZHyeaRgs4WdA2xmUEoEiAARIAJEgAjsMoHx4lJsvigUyxpr ZiBlfta+s02sTed+vomdErbCw3bnbTeMxvml2Faeje344U/H1VLveuq4VM6CZWYXDyffBAMLL2pM mzn5Jr7aWDic7A4xJ1ZhcJuXTwYRIAJEgAgQASKwawR4+zvCYO0vyoSfLaz8d9b+JY+w2piHb+VG 41mxzI2eKW3vtJbi1w8pw2xmwObiZsQmDojvC8+IsBM28RFOrByk3OD5YYzw88LJIAJEgAgQASJA BHaZANNMrKVGyo0d+Fk2pMjD7R0YODe2tdHY5RP+8Oy4K1oKagYscA3cYNfT6GQyiHmQMp0E1lww sXvDSkAKP8vM0cDJFu5hR4STGTxtzEA2ESACRIAIEAEisAsEmB7CjrztZsZ4fX+N+qnRxl5s4U4Y jcUyG3m4E8aUXnZaS+Fqcf0QNIwCM/gq28pTnhkckQeCiRmwsQlL4+7cyTfBw538cMyzfQuNlGKo KCUCRIAIEAEi8N8S4IqHqxxmMD9Kxypb2JHgf8fxH3Gp8fysBF4OX2WlTel0p7UUwLELhprhNiPC VA6cfBM32C6N+ZnOZeEolo3tzguHAQ9zIuX7bvf9y8/ysF0oJQJEgAgQASJABHaZwHjxJ7S/rAlu NHAUtsrSRv3U6B9tsx357rt8th+qHXdaS7GzBx0YTOJwoTPCiQwMIr9glqGxBHggp1ACK42nzBhW TA0RLO7k2fhWeGghAkSACBABIkAEdpkA00PYnTXWvAXnbTfzjF6Fp1FLsRJ45kZjB4Xv8ml/GHbc RS3FTh2AuJrhNjOQIg+2MoPn59fM/czgq7gfvExkhn/0KvfwvXixZBABIkAEiAARIAK7QADtL9sL bStb+CoMeFjKDb76r9zv/LMDPzaxrSMMtjp10/9QKhO5DK5jRmRm8z9hK8vAU4SdkJOvcmPX/CMO ilVWzmg/eYgAESACRIAIEIGJE2DzPI2Zn+snbiAbm0cKBhNRzEA6XnxrB37sNXphxxrt/xB6/qu4 1JjXg4tngoltZavcyVe5wTLzVRhjFsv18phbyUkEiAARIAJEgAj8NwTGa39RJtuElBuNTnbQxk38 NJiTr3JjPD/PMLWMSdNSnAu0EbO5MSYRnn/EVmgmtuMIjcVWR2SmVSJABIgAESACRGBSCOw4ZsFa baSjDRx9TP8Ec07KyX+whUymluLiiRvs2kCTeZByg3Hnq9xgmbHjcNaxxqR/sLzo6ESACBABIkAE dksCu6ClxlNL4DN6E/ewrY2rU53npGkphgbqh9FhBtLx4kzIz/OM2JdtYiny8JwwRi80Xmo0E/IQ ASJABIgAEdhZAqz5HnMvrnu4gWxMe3EPN1jjjgzwcCcrlq9yY8zDTTnnpGkpxgXXzyFycNjEZRM3 4BzPzwphKfKPLpOVTCkRIAJEgAgQASIwWQTQKI9XFNs03Gy/8zYfcjauNvrZpsaUb+VG4+6soYdn 6i6TqaWYTgKLEYJpTDoM6OhN48Wxxss/ugTyEAEiQASIABEgAjtLYMftLJdB3ED53OYGPyj3jDbY jszP809pY9K0FEPD1CUAcZnJbO7hq9xo3AVOLGMC3XE/7pi7kJMIEAEiQASIABGYFAKsdd7eSv9r oilWLG+1eYZGATAiz5irk3J6H2wh/xY9EzwPzmiC+dm8U6MzjzfOaWfzjy6ZPESACBABIkAEiMBk ERgvljHefFQ7m5+rsck64fe/nMmMS03K2Y/HdDz/pByUCiECRIAIEAEiQATGJEDt75hYGp3vuZYa 7x5Mlr/xYsgmAkSACBABIkAEJpcAtdfvypO01LsiogxEgAgQASJABD66BEhLveu9f8+11LuewYgM 4/WzjshGq0SACBABIkAEiMD7QIDa5XeF/J5rqZ3Vs+Od8XjljJef/ESACBABIkAEiMB/T2C89ndn /f/9mXxoSyAt9aG9NXRiRIAIEAEiQAQ+eAI7q5nGy//BX8l7dgbvuZba2TMf7x6M59/Z8ik/ESAC RIAIEAEiMHEC1P6+K6ud1lI7y3Rn56Ma74ypv3Y8MuQnAkSACBABIvDhJ7Cz+uHDf0X8DLXcIoMI EAEiQASIABEgAkRgZwnsdFxqZw8wXv7dWJ+Od8nkJwJEgAgQASJABHY/AqSldr97SldEBIgAESAC RIAIvH8EqI/v/WNNRyICRIAIEAEiQAR2PwIUl9r97ildEREgAkSACBCBD4zAZL1z9oFdwM4fmOJS O8+M9iACRIAIEAEiQASIwDsESEu9Q4L+JQJEgAgQASJABIjAzhPQfARjcTtPifYgAkSACBABIkAE iMDYBCguNTYX8hIBIkAEiAARIAJEYCIESEtNhBLlIQJEgAgQASJABIjA2ARIS43NhbxEgAgQASJA BIgAEZgIAdJSE6FEeYgAESACRIAIEAEiMDYB0lJjcyEvESACRIAIEAEiQAQmQoC01EQoUR4iQASI ABEgAkSACIxNgLTU2FzISwSIABEgAkSACBCBiRAgLTURSpSHCBABIkAEiAARIAJjEyAtNTYX8hIB IkAEiAARIAJEYCIESEtNhBLlIQJEgAgQASJABIjA2ARIS43NhbxEgAgQASJABIgAEZgIAdJSE6FE eYgAESACRIAIEAEiMDYB0lJjcyEvESACRIAIEAEiQAQmQoC01EQoUR4iQASIABEgAkSACIxNgLTU 2FzISwSIABEgAkSACBCBiRAgLTURSpSHCBABIkAEiAARIAJjEyAtNTYX8hIBIkAEiAARIAJEYCIE SEtNhBLlIQJEgAgQASJABIjA2ARIS43NhbxEgAgQASJABIgAEZgIAdJSE6FEeYgAESACRIAIEAEi MDYB0lJjcyEvESACRIAIEAEiQAQmQuD/A3ZgcfMsfYZ8AAAAAElFTkSuQmCC --Boundary_(ID_BSeJL8kv5NF1q0Jt0gaJgQ)-- From pekkas@netcore.fi Wed Dec 22 23:31:30 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C973A69CE for ; Wed, 22 Dec 2010 23:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22JleLAGPXa4 for ; Wed, 22 Dec 2010 23:31:28 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id EB7E03A69C2 for ; Wed, 22 Dec 2010 23:31:27 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id oBN7XDK4012434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Dec 2010 09:33:13 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id oBN7XCDG012430; Thu, 23 Dec 2010 09:33:12 +0200 Date: Thu, 23 Dec 2010 09:33:12 +0200 (EET) From: Pekka Savola To: Stuart Cheshire Subject: Re: Last Call: (DNS-Based Service Discovery) to Proposed Standard In-Reply-To: Message-ID: References: <20101026145701.22996.35291.idtracker@localhost> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.4 at otso.netcore.fi X-Virus-Status: Clean Cc: draft-cheshire-dnsext-dns-sd@tools.ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 07:31:30 -0000 On Wed, 22 Dec 2010, Stuart Cheshire wrote: > FWIW, Apple's code on Mac OS X uses TSIG for secure updates. You enter the > credentials in the "Sharing" preferences pane. What the user-interface people > chose to label "User" and "Password" are in reality the TSIG key name and the > TSIG key data. They felt that most users wouldn't know what TSIG meant, and > it was better to have something familar (but wrong) rather than something > unfamilar (but correct). Sorry. > > BIND allows pretty flexible configurations to control which keys are > authorized to update what records. What I'm saying is that having to manually pre-configure the hostname in DNS goes against what appears to be one of the main DNS-SD goals, i.e., the host can invent the hostname or use it in a zero-conf fashion. I don't think it's possible to integrate DNS-SD with secure DNS without losing at least some of the properties DNS-SD was designed to address. So it would be unrealistic to require this from the protocol, especially given its background. What I would have wanted to see is more truth in advertising how in practise using security impedes the use of DNS-SD. Which usage modes of DNS-SD can be made to work and at what cost. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ben@nostrum.com Wed Dec 22 14:20:16 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A2B3A68F7; Wed, 22 Dec 2010 14:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.947 X-Spam-Level: X-Spam-Status: No, score=-100.947 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH52--CyCjEY; Wed, 22 Dec 2010 14:20:16 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8C8CE3A68C6; Wed, 22 Dec 2010 14:20:15 -0800 (PST) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oBMMM4dL069281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Dec 2010 16:22:05 -0600 (CST) (envelope-from ben@nostrum.com) Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-mpls-tp-uni-nni-02 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Wed, 22 Dec 2010 16:22:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Bocci, Matthew (Matthew)" X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Thu, 23 Dec 2010 12:13:44 -0800 Cc: General Area Review Team , "draft-ietf-mpls-tp-uni-nni.all@tools.ietf.org" , The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 22:20:16 -0000 Thanks for the quick response. Also see below. I elided sections that I = think have been addressed. On Dec 22, 2010, at 5:44 AM, Bocci, Matthew (Matthew) wrote: > Ben, >=20 > Thank you for your comments. Please see below. >=20 > Best regards >=20 > Matthew >=20 > On 21/12/2010 22:13, "Ben Campbell" wrote: >=20 [...] >>=20 >> -- Section 1.1, 1st paragraph: >>=20 >> More conventional in what context? Useful for what purpose? >=20 > It is the convention to represent a UNI or NNI as a specific reference > point between functional groups e.g. MEF E-NNI (Figure 2 of MEF26) or = ATM > UNI (ITU-T I.413), rather than to represent these as a span as in the > original diagrams in RFC5921. I propose to rephrase this sentence to: > "However, it is convention to illustrate these interfaces as reference > points." >=20 > With regard to your second question, I propose to rephrase the = sentence as > follows: > "Furthermore, in the case of a UNI, it is useful to illustrate the > distribution of UNI functions between the Customer Edge (CE) side and = the > Provider Edge (PE) side of the UNI (the UNI-C and UNI-N) in order to = show > their relationship to one another." >=20 >=20 WFM >=20 >>=20 >> -- Figures 1 and 2: >>=20 >> Is the meaning of the various line types described elsewhere? If so, = a >> statement to that effect with a reference would be helpful. >=20 > We have used the same convention as RFC5921. However, there is no key > there. I am not sure that a complete key would clarify the diagram as = the > same line type is used to represent multiple entities due to the = limited > umber of characters that are useful for ASCII drawing. Ah, I agree it probably would be too much to add a complete key, and on = re-reading, I see most of the lines are sufficiently labeled. But I am = still confused by a few of them. For example, in under the UNI column, I = see both a single and double dashed (equal signs) line under the label = of "Client Traffic Flows". Should I assume those to just be two = arbitrary flows where the line type just helps me follow a particular = flow, or are they somehow different classes of flows?=09 On the right side of the same diagram, I see 3 Transport Paths with an = outer set of arrows, and the lower two having another arrow between. = Should the outer arrows be interpreted as a "channel" over which client = traffic flows? >=20 >>=20 >> -- Figure 2: >>=20 >> I suggest expanding CP somewhere. >=20 > CP is expanded in the terminology section. So it is, right there at the top. (I could have sworn I did a text = search for that--looks like the search option in the iPad tool I use for = reviewing drafts is not reliable :-|) >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From cheshire@apple.com Thu Dec 23 15:15:03 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33A83A68BB for ; Thu, 23 Dec 2010 15:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.723 X-Spam-Level: X-Spam-Status: No, score=-106.723 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX8tXfmj1rns for ; Thu, 23 Dec 2010 15:15:02 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id EDBAD3A68B6 for ; Thu, 23 Dec 2010 15:15:02 -0800 (PST) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 3E10FC1F768D for ; Thu, 23 Dec 2010 15:16:39 -0800 (PST) X-AuditID: 11807137-b7bfaae000004d31-08-4d13d8576689 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id E2.67.19761.758D31D4; Thu, 23 Dec 2010 15:16:39 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.2] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDW008BELZQI730@elliott.apple.com> for ietf@ietf.org; Thu, 23 Dec 2010 15:16:39 -0800 (PST) Subject: Re: Last Call: (DNS-Based Service Discovery) to Proposed Standard From: Stuart Cheshire In-reply-to: Date: Thu, 23 Dec 2010 15:16:38 -0800 Message-id: References: <20101026145701.22996.35291.idtracker@localhost> To: Pekka Savola X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: draft-cheshire-dnsext-dns-sd@tools.ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 23:15:03 -0000 On 22 Dec 2010, at 23:33, Pekka Savola wrote: > What I'm saying is that having to manually pre-configure the hostname in DNS goes against what appears to be one of the main DNS-SD goals, i.e., the host can invent the hostname or use it in a zero-conf fashion. > > I don't think it's possible to integrate DNS-SD with secure DNS without losing at least some of the properties DNS-SD was designed to address. So it would be unrealistic to require this from the protocol, especially given its background. > > What I would have wanted to see is more truth in advertising how in practise using security impedes the use of DNS-SD. Which usage modes of DNS-SD can be made to work and at what cost. I see the confusion. Multicast DNS is intended to be zero-configuration. DNS-SD is not necessarily. I have added this to the introduction which should hopefully clarify this: When used with Multicast DNS, DNS-SD can provide zero-configuration operation -- just connect a DNS-SD/mDNS device and its services are advertised on the local link with no further user interaction. When used with conventional unicast DNS, some configuration will usually be required -- such as configuring the device with the DNS domain(s) in which it should advertise its services, and configuring it with the DNS Update [RFC 2136] keys to give it permission to do so. In rare cases, such as a secure corporate network behind a firewall where no DNS Update keys are required, zero-configuration operation may be achieved by simply having the device register its services in a default registration domain it learns from the network (See Section 12 "Discovery of Browsing and Registration Domains") but usually security credentials will be required to perform DNS Updates. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From narten@us.ibm.com Thu Dec 23 21:51:12 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7ADC3A68EF for ; Thu, 23 Dec 2010 21:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.116 X-Spam-Level: X-Spam-Status: No, score=-104.116 tagged_above=-999 required=5 tests=[AWL=-1.517, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9wRZUCwLXOn for ; Thu, 23 Dec 2010 21:51:11 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id 8A0913A68EE for ; Thu, 23 Dec 2010 21:51:11 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id oBO5fGVY015370 for ; Thu, 23 Dec 2010 22:41:16 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oBO5r3LE154004 for ; Thu, 23 Dec 2010 22:53:03 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oBO5r3Wu021395 for ; Thu, 23 Dec 2010 22:53:03 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oBO5r2fc021378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Dec 2010 22:53:02 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id oBO5r2U5030106 for ; Fri, 24 Dec 2010 00:53:02 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.4/8.14.4/Submit) id oBO5r2s7030056 for ietf@ietf.org; Fri, 24 Dec 2010 00:53:02 -0500 From: Thomas Narten Message-Id: <201012240553.oBO5r2s7030056@rotala.raleigh.ibm.com> Date: Fri, 24 Dec 2010 00:53:02 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 05:51:12 -0000 Total of 57 messages in the last 7 days. script run at: Fri Dec 24 00:53:02 EST 2010 Messages | Bytes | Who --------+------+--------+----------+------------------------ 5.26% | 3 | 40.98% | 280929 | cheshire@apple.com 10.53% | 6 | 4.66% | 31939 | julian.reschke@gmx.de 8.77% | 5 | 3.90% | 26757 | hartmans-ietf@mit.edu 7.02% | 4 | 2.88% | 19711 | johnl@iecc.com 5.26% | 3 | 3.68% | 25209 | sm@resistor.net 5.26% | 3 | 2.72% | 18656 | d3e3e3@gmail.com 5.26% | 3 | 2.57% | 17629 | randy_presuhn@mindspring.com 1.75% | 1 | 5.15% | 35330 | ietf@augustcellars.com 3.51% | 2 | 2.08% | 14237 | pekkas@netcore.fi 3.51% | 2 | 1.69% | 11615 | ben@nostrum.com 3.51% | 2 | 1.59% | 10869 | barryleiba@computer.org 1.75% | 1 | 3.30% | 22601 | denis.pinkas@bull.net 3.51% | 2 | 1.38% | 9447 | daniel@haxx.se 3.51% | 2 | 1.38% | 9432 | hartmans@painless-security.com 1.75% | 1 | 2.87% | 19646 | ron.even.tlv@gmail.com 1.75% | 1 | 2.29% | 15701 | ben@estacado.net 1.75% | 1 | 1.74% | 11899 | juhovh@iki.fi 1.75% | 1 | 1.55% | 10628 | csp@csperkins.org 1.75% | 1 | 1.25% | 8546 | karlheinz.wolf@nic.at 1.75% | 1 | 1.22% | 8359 | adrian.farrel@huawei.com 1.75% | 1 | 1.21% | 8285 | turners@ieca.com 1.75% | 1 | 1.10% | 7515 | tony@att.com 1.75% | 1 | 1.03% | 7053 | narten@us.ibm.com 1.75% | 1 | 1.00% | 6836 | radiaperlman@gmail.com 1.75% | 1 | 0.99% | 6770 | nordmark@acm.org 1.75% | 1 | 0.97% | 6658 | wesley.m.eddy@nasa.gov 1.75% | 1 | 0.96% | 6584 | matthew.bocci@alcatel-lucent.com 1.75% | 1 | 0.89% | 6072 | fluffy@cisco.com 1.75% | 1 | 0.83% | 5693 | stbryant@cisco.com 1.75% | 1 | 0.76% | 5195 | fweimer@bfk.de 1.75% | 1 | 0.75% | 5108 | dotis@mail-abuse.org 1.75% | 1 | 0.67% | 4624 | francis.dupont@fdupont.fr --------+------+--------+----------+------------------------ 100.00% | 57 |100.00% | 685533 | Total From fluffy@cisco.com Fri Dec 24 09:43:10 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DE63A6832; Fri, 24 Dec 2010 09:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIwzx3Aw8lPB; Fri, 24 Dec 2010 09:43:09 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 581033A680B; Fri, 24 Dec 2010 09:43:09 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACdrFE2rRN+K/2dsb2JhbACkLnOkZZslhUoEhGWGH4Md X-IronPort-AV: E=Sophos;i="4.60,224,1291593600"; d="scan'208";a="237425644" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Dec 2010 17:44:53 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oBOHiqsH015357; Fri, 24 Dec 2010 17:44:52 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: TSV-DIR Review of draft-ietf-mptcp-architecture-03 Date: Fri, 24 Dec 2010 10:46:05 -0700 Message-Id: To: tsv-dir@ietf.org, multipathtcp@ietf.org, The IETF Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-mptcp-architecture@tool.ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 17:43:10 -0000 I have reviewed this document as part of the transport area = directorate's ongoing effort to review key IETF documents. These = comments were written primarily for the transport area directors, but = are copied to the document's authors for their information and to allow = them to address any issues raised. Please consider these like any other = last call comments,=20 Summary: This draft is ready for publication as Informational.=20 This draft is easy to understand and does a fine job of explaining the = overall big picture of the solution without going into the details of = the the design. In addition to being an architecture, it is also a set = of requirements for the protocol design. It describes a protocol that is = consistent with, and meets the goals of, the WG charter. I raise two = minor issues which folks might want to consider but in my opinion it = would be fine to publish the draft without any changes to address these = issues.=20 Minor Issues: I was a little surprised not to see any discussion of OOB data. Would = this be support? send on both path? send only on one path?=20 I wonder if anything needs to be said about TCP options - particularly = the case where an application that thinks it is using TCP is actually = dealing with MPTCP and the options are different on the two paths. = Consider a hypothetical case like such as TCP Compression Filters. If an = application had a socket level API to turn this on and off and see if it = was working or not, and one path supported it but the other path went = through an IDS systems that did not support it, what would happen? = Perhaps all that needs to be said is that each option is separate and = just because an given OS supports a specific option for TCP, it does not = mean the option will work for MPTCP. =46rom a practical point of view, = when I look at the options in use today, this does not look like a big = deal for MPTCP.=20 Nits: On page 8 2n'd para from bottom, you have=20 as a significant deployment bottleneck for any transport that is not TCP I think this should by changed to say "TCP or UDP" instead of just TCP=20= From jari.arkko@piuha.net Mon Dec 27 16:04:09 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2483428B23E for ; Mon, 27 Dec 2010 16:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlkBtxAlMfki for ; Mon, 27 Dec 2010 16:04:07 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 83B5A3A68F6 for ; Mon, 27 Dec 2010 16:04:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 20CB02CC3A; Tue, 28 Dec 2010 02:06:09 +0200 (EET) 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 ES0dsbjEeF0O; Tue, 28 Dec 2010 02:06:07 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 88A5F2CC2E; Tue, 28 Dec 2010 02:06:07 +0200 (EET) Message-ID: <4D1929EE.6070509@piuha.net> Date: Tue, 28 Dec 2010 02:06:06 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com Subject: Re: Last Call: (Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment) to Informational RFC References: <19776_1293460120_4D18A298_19776_757068_1_94C682931C08B048B7A8645303FDC9F33C3E619705@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <19776_1293460120_4D18A298_19776_757068_1_94C682931C08B048B7A8645303FDC9F33C3E619705@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-arkko-ipv6-transition-guidelines@tools.ietf.org" , "ietf@ietf.org" , Lindqvist Kurt Erik X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 00:04:09 -0000 Mohamed, Thank you for your in-depth review and comments. I have tried to take your comments into account in the -14 version that got just posted. > (1) > > * Precise in the introduction section the type of networks which are > concerned with the IPv6 deployment models listed in the I-D; in > particular mention that both corporate networks and providers networks > are concerned. > > * Fixed and mobile networks may adopt distinct IPv6 deployment > strategies because of the differences between the two networks (e.g., > controlled CPE vs. non controlled handsets). > > * It seems services infrastructures (e.g., VoIP, IP TV) are out of > scope. This should be mentioned. Note that some service-related > discussed is covered in Section 4.4. We certainly did not plan on providing specific guidance to each and every different networking situation. Draft -14 tries to make this clearer. But by the same token, I'm not sure I want to single out the above cases in any particular way either. FWIW I do agree with many of your arguments above. Who controls what is one of the key factors in any deployment decision. > (2) > > Page 5/6, the I-D says: > > > " o The ability to offer a valuable service. In the case of the > Internet, connectivity has been this service. > > o The ability to deploy the solution in an incremental fashion. > > o Simplicity. This has been a key factor in making it possible for > all types of devices to support the Internet protocols. > > o Openly available implementations. These make it easier for > researchers, start-ups and others to build on or improve existing > components. > > o The ability to scale. The IPv4 Internet grew far larger than its > original designers had anticipated, and scaling limits only became > apparent 20-30 years later. > > o The design supports robust interoperability rather than mere > correctness. This is important in order to ensure that the > solution works in different circumstances and in an imperfectly > controlled world." > > and in Page 6: "These factors are also important when choosing IPv6 > migration tools.", but: > > * The I-D does not show how these factors are applied for the tools > listed in the I-D; a table with a set of criteria would be useful; > > * The first criterion is IMHO meaningless for IPv6 deployment because > IPv6 does not offer a new service compared to IPv4. > > * I'm not sure that having an open source for a given tool can be an > argument to RECOMMEND or NOT a given tool; Well, the document only says "these factors are important". I would argue that they are. Of course, as you point out, situations differ and maybe in some case you decide to deploy something regardless of what some of the factors indicate -- for good reasons. > * How "scalability" is defined (5th bullet)?? All the solutions listed > in the I-D need a NAT (l2-nat, ds-lite nat44, nat44, nat64), to what > extent a CGN is considered as a scalable solution? I have added a little bit text to make this part of the document clearer. In general, the document does not attempt to provide a matrix of various factors and benefits. We're listing a certain set of tools mostly because real world networks have used them or are at least giving serious consideration to them. > > * The last bullet is not clear: Do you consider that DS-Lite satisfies > this factor? FWIW, DS-Lite has been rejected by the 3GPP because it > requires specific functions on the UE. DS-Lite has been rejected in that particular use case because, well, its not needed :-) That's fine. 3GPP networks have native ipv6 to 5 billion cellphones literally at the flick of a switch. I don't want to say that its all easy, because there are of course serious problems on many levels, but one thing that 3GPP networks don't need is more tunnels because they already have that covered. Lets have them solve their other problems, like having more terminals that actually support any of this stuff, ensure that user's eyeballs are happy and not stuck in some issue, set up the core networks with proper IPv6 routing, figure out in which situations they can go IPv6-only, etc. But back to this document. The factors that we list are really examples from past Internet deployment, not necessarily something that should be taken into account verbatim. Version -14 makes this clearer. > (3) > > From the perspective of transitioning networks to IPv6, I don't see > the rationale behind including techniques such as those listed in > "4.2. Crossing IPv4 Islands" as a candidate solutions for IPv6 > deployment. This section can be removed to an appendix. Well, we could argue the philosophy behind this. Is tunneling something that moves things forward, or are we confessing our inability to change the part in between? But again we've chosen to include techniques that have seen world-wide deployment, and most things in Section 4.2 certainly fall in that category. If I talk to someone about their IPv6 deployment plans, techniques in this section are often needed. I think we need to keep the section, even if I agree with you that the ultimate goal should be native deployment. > > (4) > > (a) I have an issue with the following statements in the I-D: > > On page 6, the ID states: "The third scenario is more advanced and > looks at a service provider network that runs only on IPv6 but which > is still capable of providing both IPv6 and IPv4 services." > > and in page 11, the ID mentions: > > " The recommended tool for this model is Dual Stack Lite > [I-D.ietf-softwire-dual-stack-lite > ]. > Dual Stack Lite provides both > relief for IPv4 address shortage and makes forward progress on IPv6 > deployment, by moving service provider networks and IPv4 traffic over > IPv6. Given this IPv6 connectivity, as a side-effect it becomes easy > to provide IPv6 connectivity all the way to the end users." > > Taking into account the current DS-Lite specification, this > recommendation is not justified for the following reasons: > > * For Ds-Lite technique to be deployed in a IPv6-only realm, and as > currently specified in DS-Lite specification, this would mean that > DS-Lite AFTR(s) are to be located at the boundaries of the IPv6-only > domain. > > * This design choice would lead to non optimal intra-domain paths to > place communications between two DS-Lite serviced customers. > > * This centralised model is not suitable for service providers who > want to deploy DS-Lite AFTRs closer to the customers. You may be right, but I don't we're trying to provide perfectly optimized solution. These are transition tools. Also, DS-Lite is one of the tools in the small set of IETF-developed transition tools. We've had fairly large set of people interested in it. Not everyone, of course, and we already talked about the cellular case above. But I'm trying to convey the IETF and industry opinion about the transition tools. I don't think I can suggest other types of solutions. > > (b) The I-D states in page 11: "Given this IPv6 connectivity, as a > side-effect it becomes easy to provide IPv6 connectivity all the way > to the end users." > > This wording is not accurate; IPv6 connectivity is not a side-effect > of DS-lite but rather a pre-requisite for DS-Lite (e.g., DHCPv6 is > required to configure for instance the AFTR NAME option, dual-stack > CPE, etc.). Right. Thanks for the report. I have fixed this in -14. > > (5) > > * In Section "4.4. IPv6-only Deployment", add a sentence > to precise that the issues listed > in [I-D.ietf-intarea-shared-addressing-issues > ] > are still valid when NAT64 is deployed. OK > > * Page 13, change "SIP (Session Identity Protocol)" to "SIP (Session > Initiation Protocol)"; Right. I don't know what I was thinking :-) > > * Page 13: "One might position a web proxy, a > mail server, or a SIP (Session Identity Protocol) back-to-back user > agent across the boundary between IPv4 and IPv6 domains, so that the > application terminates IPv4 sessions on one side and IPv6 sessions on > the other. Doing this preserves the end-to-end nature of > communications between gateways. For obvious reasons, this solution > is preferable to the implementation of Application Layer Gateways in > network layer translators. > " > > (a) Why only listing the back-to-back user agent option (this option > is valid)? Why not deploying means for NAT traversal is not listed as > an alternative? In this part of the text we are talking about deploying a proxy of some sort. Later in the same section we talk about network address translators. The latter obviously may benefit from a NAT traversal solution. But I'm not sure I understand why NAT traversal alone would be a solution. You have something that converts packets in the network. The document talks about L3 version of that, as well as L4-L7 gateways. > > (b) "Doing this preserves the end-to-end nature of communications > between gateways": Which gateways? Imprecise text. The idea is that the communication from the gateway to the peer (which might be another gateway) is end-to-end. I have changed the text. > > (c) For the SIP case, still there is a need for a translator for media > flows; Yes. > > (d) Service-related discussions are not elaborated in other sections: > I would prefer to have a similar discussion for the DS model, in > particular issues in SIP environments to signal both IPv4 and IPv6 > addresses in the SDP offers; means to prioritise the use of IPv6; how > the SIP Proxy Server can determine whether there is a need to invoke a > SIP ALG/NAT64/NAT46 (e.g.., translator should be avoided when a DS UA > calls a IPvx-only/DS UA. ALG/NAT46/NAT64 should be invoked only for > IPvx-IPvy sessions), etc. These would be useful. If you have text, please submit it. > > * Add a reference to > http://tools.ietf.org/html/draft-ietf-v6ops-v6-in-mobile-networks-02 > Ack > (6) > > It would be valuable if the I-D describes some migration paths and > examples about the use of the tools listed in the I-D; e.g.,: > > * How DS-Lite CGN devices can be removed from the network since it is > supposed to be a transition solution. This would be a good example to > apply what is stated in the I-D in page 5: "The end goal is > network-wide native IPv6 deployment, resulting in the > obsolescence of transitional mechanisms based on encapsulation, > tunnels, or translation, and also resulting in the obsolescence of > IPv4." We don't have a lot of running code about that yet. Again, do you have suggested words? > > * How to encourage the use of native IPv6 transfer capabilities: > address selection issues, application considerations, etc. This too would be useful. (Text?) FWIW I think we might need another document or even a set of documents for this particular issue. Some of this is in the happy eyeballs doc though. Jari > > Cheers, > Med > ********************************* > This message and any attachments (the "message") are confidential and intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel it immediately and inform the sender. > ******************************** > From mrex@sap.com Tue Dec 28 08:15:19 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C4C3A6965; Tue, 28 Dec 2010 08:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.146 X-Spam-Level: X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Emy5Gw4Sxomc; Tue, 28 Dec 2010 08:15:19 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A85D73A695B; Tue, 28 Dec 2010 08:15:18 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oBSGH8lu018572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Dec 2010 17:17:13 +0100 (MET) From: Martin Rex Message-Id: <201012281617.oBSGH8HN000052@fs4113.wdf.sap.corp> Subject: Re: Last Call: (Updated To: hartmans@painless-security.com (Sam Hartman) Date: Tue, 28 Dec 2010 17:17:08 +0100 (MET) In-Reply-To: from "Sam Hartman" at Dec 21, 10 12:24:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: Francis.Dupont@fdupont.fr, ietf@ietf.org, L.Wood@surrey.ac.uk, wes@mti-systems.com, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 16:15:19 -0000 Sam Hartman wrote: > > I'm OK with this text. I tried to come up with a way to briefly discuss > how error detection is very related to things like protecting against > substitution of content (the internet mirror case) but failed to come up > with something brief. > So, I'm fine with what you have. The use of MD5 _is_ a security problem in integrity protection scenarios. When used for checksums when mirroring sites, a "contributor" could precompute a collision for a file he contributed in order to perform an MITM attack on specific downloads (substituting a trojaned package with the same md5sum into the download while leaving the file on the Download servers clean. -Martin From mrex@sap.com Tue Dec 28 09:25:00 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52893A687D for ; Tue, 28 Dec 2010 09:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.847 X-Spam-Level: X-Spam-Status: No, score=-9.847 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkkTpZ+sCNwF for ; Tue, 28 Dec 2010 09:24:59 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E9D223A681B for ; Tue, 28 Dec 2010 09:24:58 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oBSHQntH024377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Dec 2010 18:26:54 +0100 (MET) From: Martin Rex Message-Id: <201012281726.oBSHQnFu004377@fs4113.wdf.sap.corp> Subject: Re: Automatically updated Table of Contents with Nroff To: barryleiba@computer.org (Barry Leiba) Date: Tue, 28 Dec 2010 18:26:49 +0100 (MET) In-Reply-To: from "Barry Leiba" at Dec 22, 10 12:21:37 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 17:25:00 -0000 Barry Leiba wrote: > > > # empty out toc.input > >> toc.input > > # run once to get a sample ToC, but page numbers will be off > > nroff file > /dev/null 2> toc.input > > # run again to get proper page numbers into toc.input > > nroff file > /dev/null 2> toc.input > > # run a 3rd time to get the right output, ignoring stderr this time > > nroff file 2>/dev/null > > You know, this whole discussion renews my total puzzlement at why > anyone would use nroff instead of something else... anything else. Everyone who looks at writing I-Ds should seriously consider looking at NRoffEdit before deciding which document format and tool to use. http://aaa-sec.com/nroffedit/ It is currently the 5th entry in the section "Prepare Documents" on this page: http://tools.ietf.org/ NRoffEdit is an all-in-one wysiwyg tool in Java that maintains the TOC for you (within the .nroff source itself). NO need to call nroff on the command line (no seperate nroff tool), no seperate Editor and no seperate Viewer necessary, and a spell checker is conveniently included as well. One nice feature of NRoffEdit is the capability to easily convert a formatted ASCII I-D or RFC back into nroff authoring format. -Martin From julian.reschke@gmx.de Tue Dec 28 10:26:47 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23BAC3A68AB for ; Tue, 28 Dec 2010 10:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.592 X-Spam-Level: X-Spam-Status: No, score=-104.592 tagged_above=-999 required=5 tests=[AWL=-1.993, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0esRws3ThXm6 for ; Tue, 28 Dec 2010 10:26:46 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 95C153A68A6 for ; Tue, 28 Dec 2010 10:26:44 -0800 (PST) Received: (qmail invoked by alias); 28 Dec 2010 18:28:48 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp061) with SMTP; 28 Dec 2010 19:28:48 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/8Kax+vwf8DXHPlcBy/a6cwgAkLK5McIkWYnyRsK YN4Pwvp8MLv1Tl Message-ID: <4D1A2C5E.2000308@gmx.de> Date: Tue, 28 Dec 2010 19:28:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: mrex@sap.com Subject: Re: Automatically updated Table of Contents with Nroff References: <201012281726.oBSHQnFu004377@fs4113.wdf.sap.corp> In-Reply-To: <201012281726.oBSHQnFu004377@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Barry Leiba , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 18:26:47 -0000 On 28.12.2010 18:26, Martin Rex wrote: > ... > Everyone who looks at writing I-Ds should seriously consider looking > at NRoffEdit before deciding which document format and tool to use. > ... Everyone who looks at writing I-Ds should also seriously consider xml2rfc. :-) > http://aaa-sec.com/nroffedit/ > > It is currently the 5th entry in the section "Prepare Documents" > on this page: > > http://tools.ietf.org/ > > > NRoffEdit is an all-in-one wysiwyg tool in Java that maintains > the TOC for you (within the .nroff source itself). Which will only work properly as long the output isn't run through standard NROFF, and page breaks change. Just saying. And yes, xml2rfc also maintains the TOC. > ... Best regards, Julian From ron.even.tlv@gmail.com Tue Dec 28 10:41:44 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11393A68A6; Tue, 28 Dec 2010 10:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEP7gokBZpQy; Tue, 28 Dec 2010 10:41:40 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id D90443A68A2; Tue, 28 Dec 2010 10:41:37 -0800 (PST) Received: by wwi17 with SMTP id 17so9802702wwi.1 for ; Tue, 28 Dec 2010 10:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:mime-version:content-type:x-mailer:content-language :thread-index; bh=9o8QmRnQRItKBTh6BHGY9lYagnXHHc91rpbiTl0bZ/8=; b=I1GdckcSHyVZrVgVuTz1Aak3pmlEczSB71XiXUfTi/pqDqkqYXlGkZ7KeX7R166IPQ zL5Pb9WscJmelfem4B90Un8Rk975NSM1mNVFNihunYNeKwBHQogrPSsMv0NU7eMbagJQ /JMSWWKv1HtAhaOsVI6ycxYsEps+k9h7N3Uyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:content-language:thread-index; b=geGsPHvu/lNmOoiaKAJdOsDn7F5cL6PMc2ZwB9LijbHy48Y0ZTV6nFLoNDMFoIDxge H3LctVhF96MID2m+WuAllsE1gA3Q32M9pICl5BDAMwHPwTSsuUSa1y/AgltXEY8C6dS3 J8FUaH3velD9tSYgNfDvu4i6+BuipPs0TKZMQ= Received: by 10.227.154.7 with SMTP id m7mr8178658wbw.2.1293561820407; Tue, 28 Dec 2010 10:43:40 -0800 (PST) Received: from windows8d787f9 (bzq-79-181-49-158.red.bezeqint.net [79.181.49.158]) by mx.google.com with ESMTPS id m10sm9497632wbc.22.2010.12.28.10.43.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Dec 2010 10:43:38 -0800 (PST) From: "Roni Even" To: , Subject: Gen-ART LC review of draft-ietf-sipcore-keep-10 Date: Tue, 28 Dec 2010 20:40:19 +0200 Message-ID: <4d1a2fda.8a1ce30a.5ad7.58db@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018A_01CBA6CF.76E3E900" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcumvqsCWJU+PYLPQjiNraTwI5wq+Q== Cc: 'IETF-Discussion list' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 18:41:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_018A_01CBA6CF.76E3E900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sipcore-keep-10 Reviewer: Roni Even Review Date:2010-12-28 IETF LC End Date: 2011-1-5 IESG Telechat date: Summary: This draft is almost ready for publication as a Standard track RFC. Major issues: Minor issues: 1. In the document you mention that the keep alive can be negotiated in each direction. I understand the dialog case, is this true for the case of registration, if yes how is it done from the registrar. If not true maybe add some text in 4.2.2. Nits/editorial comments: 1. In section 4.1 in the first note "If a SIP entity has indicated willingness to receive keep-alives from an adjacent SIP entity, sending of keep-alives towards the same SIP entity needs to be separately negotiated". Who is the same SIP entity mentioned in the end of the sentence. I assume you meant "towards the adjacent SIP entity". 2. In the first paragraph of 4.3 and 4.4 you use "must" should it be "MUST" 3. In 4.3 in the third paragraph "it MUST start to send keep-alives" change to "it MUST start sending keep-alives" 4. In figure 2 in the 200 OK response to Alice the VIA is missing. 5. In section 7.4 third paragraph " When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the dialog." Should be Bob and not P1. ------=_NextPart_000_018A_01CBA6CF.76E3E900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am = the assigned Gen-ART reviewer for this draft. For background on Gen-ART, = please see the FAQ at <http://w= iki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 

Please resolve these comments along with any other = Last Call comments you may receive.

 

Document: = draft-ietf-sipcore-keep-10

Reviewer: Roni Even

Review Date:2010–12–28

IETF LC End Date: = 2011–1–5

IESG Telechat = date:

 

Summary: This draft is almost ready for publication = as a Standard track RFC.

 

Major = issues:

 

 

Minor = issues:

1.  = In the document you = mention that the keep alive can be negotiated in each direction. I = understand the dialog case, is this true for the case of registration, = if yes how is it done from the registrar. If not true maybe add some = text in 4.2.2.

 

 

 

Nits/editorial comments:

1.  = In section 4.1 in the = first note “If a SIP entity has indicated willingness to receive = keep-alives from an adjacent SIP entity, sending of keep-alives towards = the same SIP entity needs to be separately negotiated”. Who is the = same SIP entity mentioned in the end of the sentence. I assume you meant = “towards the adjacent SIP entity”.

2.  = In the first paragraph of = 4.3 and 4.4 you use “must” should it be = “MUST”

3.  = In 4.3 in the third = paragraph “it MUST start to send keep-alives” change to = “it MUST start sending keep-alives”

4.  = In figure 2 in the 200 OK = response to Alice the VIA is missing.

5.  = In section 7.4 third = paragraph “ When Alice receives the response, she determines from = her Via header field that P1 is willing to receive keep-alives = associated with the dialog.” Should be Bob and not = P1.

 

 

------=_NextPart_000_018A_01CBA6CF.76E3E900-- From mrex@sap.com Tue Dec 28 10:54:50 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABA83A68AD; Tue, 28 Dec 2010 10:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.144 X-Spam-Level: X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7tR2orbJLEe; Tue, 28 Dec 2010 10:54:49 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 61F573A68A6; Tue, 28 Dec 2010 10:54:49 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBSIum2e003786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Dec 2010 19:56:53 +0100 (MET) From: Martin Rex Message-Id: <201012281856.oBSIultB009851@fs4113.wdf.sap.corp> Subject: Re: [smime] Fwd: Last Call: To: denis.pinkas@bull.net Date: Tue, 28 Dec 2010 19:56:47 +0100 (MET) In-Reply-To: from "Denis Pinkas" at Dec 17, 10 09:23:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, ietf@ietf.org, smime@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 18:54:50 -0000 Denis Pinkas wrote: > > I have a few comments about draft-schaad-smime-algorithm-attribute-03.txt: > > 1) The key question is what should contain the field signatureAlgorithm ? > > SignatureAlgorithmIdentifier is defined in section 10.1.2 from RFC 5652: > > 10.1.2. SignatureAlgorithmIdentifier > > The SignatureAlgorithmIdentifier type identifies a signature > algorithm, and it can also identify a message digest algorithm. > Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with > SHA-256. A signature algorithm supports signature generation and > verification operations. The signature generation operation uses the > message digest and the signer's private key to generate a signature > value. The signature verification operation uses the message digest > and the signer's public key to determine whether or not a signature > value is valid. Context determines which operation is intended. > > SignatureAlgorithmIdentifier ::= AlgorithmIdentifier > > > Some examples are questionable: is RSA really a "signature algorithm" ? > sha-1withRSA is really a signature mechanism, since it cannot be used > for encryption. Call it "evolutionary heritage" (from PKCS#7 1.5 -> SMIME/CMS) From http://tools.ietf.org/html/rfc2315#section-9.2 to http://tools.ietf.org/html/rfc2630#section-5.3 there was a semantical change in the SignerInfo ASN.1 structure for SignedData in that the element "digestEncryptionAlgorithm" was respecified as "SignatureAlgorithmIdentifier". So for historical reasons, RSA-based signatures use the original DigestEncryptionAlgorithm sematics and the AlgId RSA / rsaEncryption (1.2.840.113549.1.1.1) while all other public key signature schemes use the newer CMS semantics "SignatureAlgorithmIdentifier" and a signature AlgId that includes a specific hash algorithm. I notice that rfc2630 section 5.3 lists "DSS" as an example value for SignatureAlgorithmIdentifier, but e.g. our implementation of PKCS7 uses id_dsa_with_sha1 (1.2.840.10040.4.3) --the only DSA-related OID defined in rfc2630. http://tools.ietf.org/html/rfc2630#section-12.2.1 _not_ id_dsa (1.2.840.10040.4.1) which AFAIK is used for DSA _keys_ in X.509 certs and defined elsewhere. -Martin From mohamed.boucadair@orange-ftgroup.com Mon Dec 27 06:26:40 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BCF43A6897 for ; Mon, 27 Dec 2010 06:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=-1.191, BAYES_40=-0.185, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWcwhu9dHkof for ; Mon, 27 Dec 2010 06:26:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id EE4873A67FD for ; Mon, 27 Dec 2010 06:26:36 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 868BF22C748; Mon, 27 Dec 2010 15:28:40 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6656627C046; Mon, 27 Dec 2010 15:28:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 27 Dec 2010 15:28:40 +0100 From: To: "ietf@ietf.org" , "rbonica@juniper.net" , Lindqvist Kurt Erik Date: Mon, 27 Dec 2010 15:28:38 +0100 Subject: Re: Last Call: (Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment) to Informational RFC Thread-Topic: Re: Last Call: (Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment) to Informational RFC Thread-Index: Acul0lojZZyqAfc8TyetVZqal8B+wg== Message-ID: <19776_1293460120_4D18A298_19776_757068_1_94C682931C08B048B7A8645303FDC9F33C3E619705@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C3E619705PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.12.27.133321 X-Mailman-Approved-At: Tue, 28 Dec 2010 11:27:25 -0800 Cc: "draft-arkko-ipv6-transition-guidelines@tools.ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 14:26:40 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C3E619705PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please find below some comments about this I-D. (1) * Precise in the introduction section the type of networks which are concer= ned with the IPv6 deployment models listed in the I-D; in particular mentio= n that both corporate networks and providers networks are concerned. * Fixed and mobile networks may adopt distinct IPv6 deployment strategies b= ecause of the differences between the two networks (e.g., controlled CPE vs= . non controlled handsets). * It seems services infrastructures (e.g., VoIP, IP TV) are out of scope. T= his should be mentioned. Note that some service-related discussed is covere= d in Section 4.4. (2) Page 5/6, the I-D says: " o The ability to offer a valuable service. In the case of the Internet, connectivity has been this service. o The ability to deploy the solution in an incremental fashion. o Simplicity. This has been a key factor in making it possible for all types of devices to support the Internet protocols. o Openly available implementations. These make it easier for researchers, start-ups and others to build on or improve existing components. o The ability to scale. The IPv4 Internet grew far larger than its original designers had anticipated, and scaling limits only became apparent 20-30 years later. o The design supports robust interoperability rather than mere correctness. This is important in order to ensure that the solution works in different circumstances and in an imperfectly controlled world." and in Page 6: "These factors are also important when choosing IPv6 migrati= on tools.", but: * The I-D does not show how these factors are applied for the tools listed = in the I-D; a table with a set of criteria would be useful; * The first criterion is IMHO meaningless for IPv6 deployment because IPv6 = does not offer a new service compared to IPv4. * I'm not sure that having an open source for a given tool can be an argume= nt to RECOMMEND or NOT a given tool; * How "scalability" is defined (5th bullet)?? All the solutions listed in t= he I-D need a NAT (l2-nat, ds-lite nat44, nat44, nat64), to what extent a C= GN is considered as a scalable solution? * The last bullet is not clear: Do you consider that DS-Lite satisfies this= factor? FWIW, DS-Lite has been rejected by the 3GPP because it requires sp= ecific functions on the UE. (3) >From the perspective of transitioning networks to IPv6, I don't see the rat= ionale behind including techniques such as those listed in "4.2. Crossing I= Pv4 Islands" as a candidate solutions for IPv6 deployment. This section can= be removed to an appendix. (4) (a) I have an issue with the following statements in the I-D: On page 6, the ID states: "The third scenario is more advanced and looks a= t a service provider network that runs only on IPv6 but which is still capa= ble of providing both IPv6 and IPv4 services." and in page 11, the ID mentions: " The recommended tool for this model is Dual Stack Lite [I-D.ietf-softwire-dual-stack-lite]. D= ual Stack Lite provides both relief for IPv4 address shortage and makes forward progress on IPv6 deployment, by moving service provider networks and IPv4 traffic over IPv6. Given this IPv6 connectivity, as a side-effect it becomes easy to provide IPv6 connectivity all the way to the end users." Taking into account the current DS-Lite specification, this recommendation = is not justified for the following reasons: * For Ds-Lite technique to be deployed in a IPv6-only realm, and as current= ly specified in DS-Lite specification, this would mean that DS-Lite AFTR(s)= are to be located at the boundaries of the IPv6-only domain. * This design choice would lead to non optimal intra-domain paths to place = communications between two DS-Lite serviced customers. * This centralised model is not suitable for service providers who want to = deploy DS-Lite AFTRs closer to the customers. (b) The I-D states in page 11: "Given this IPv6 connectivity, as a side-eff= ect it becomes easy to provide IPv6 connectivity all the way to the end use= rs." This wording is not accurate; IPv6 connectivity is not a side-effect of DS-= lite but rather a pre-requisite for DS-Lite (e.g., DHCPv6 is required to co= nfigure for instance the AFTR NAME option, dual-stack CPE, etc.). (5) * In Section "4.4. IPv6-only Deployment", add a sentence to precise that th= e issues listed in [I-D.ietf-intarea-shared-addressing-issues] are still valid when NAT64 is deployed. * Page 13, change "SIP (Session Identity Protocol)" to "SIP (Session Initia= tion Protocol)"; * Page 13: "One might position a web proxy, a mail server, or a SIP (Session Identity Protocol) back-to-back user agent across the boundary between IPv4 and IPv6 domains, so that the application terminates IPv4 sessions on one side and IPv6 sessions on the other. Doing this preserves the end-to-end nature of communications between gateways. For obvious reasons, this solution is preferable to the implementation of Application Layer Gateways in network layer translators. " (a) Why only listing the back-to-back user agent option (this option is val= id)? Why not deploying means for NAT traversal is not listed as an alternat= ive? (b) "Doing this preserves the end-to-end nature of communications between g= ateways": Which gateways? (c) For the SIP case, still there is a need for a translator for media flow= s; (d) Service-related discussions are not elaborated in other sections: I wou= ld prefer to have a similar discussion for the DS model, in particular issu= es in SIP environments to signal both IPv4 and IPv6 addresses in the SDP of= fers; means to prioritise the use of IPv6; how the SIP Proxy Server can det= ermine whether there is a need to invoke a SIP ALG/NAT64/NAT46 (e.g.., tran= slator should be avoided when a DS UA calls a IPvx-only/DS UA. ALG/NAT46/NA= T64 should be invoked only for IPvx-IPvy sessions), etc. * Add a reference to http://tools.ietf.org/html/draft-ietf-v6ops-v6-in-mobi= le-networks-02 (6) It would be valuable if the I-D describes some migration paths and examples= about the use of the tools listed in the I-D; e.g.,: * How DS-Lite CGN devices can be removed from the network since it is suppo= sed to be a transition solution. This would be a good example to apply what= is stated in the I-D in page 5: "The end goal is network-wide native IPv6 = deployment, resulting in the obsolescence of transitional mechanisms based on encapsulation, tunnels, or translation, and also resulting in the obsolescence of IPv4." * How to encourage the use of native IPv6 transfer capabilities: address se= lection issues, application considerations, etc. Cheers, Med ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** --_000_94C682931C08B048B7A8645303FDC9F33C3E619705PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
P= lease find=20 below some comments about this I-D.
 
(1)
 
*= Precise in=20 the introduction section the type o= f=20 networks which are concerned with the IPv6 deployment models listed in the = I-D;=20 in particular mention that both corporate networks and providers networks a= re=20 concerned.
 
*= Fixed and=20 mobile networks may adopt distinct=20 IPv6 deployment strategies because of the differences between the tw= o=20 networks (e.g., controlled CPE vs. non controlled handsets).
 
* It=20 seems services infrastructures (e.g., VoIP, IP TV) are out of scope. This s= hould=20 be mentioned. Note that some service-relat= ed=20 discussed is covered in Section 4.4.
 
(= 2)=20
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3>Page 5/6, the I-D says:= =20
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3>  " o  The ability to offer a valuable service.&n= bsp; In=20 the case of the
      Internet, connectivity ha= s=20 been this service.

   o  The ability to deploy the=20 solution in an incremental fashion.

   o =20 Simplicity.  This has been a key factor in making it possible=20 for
      all types of devices to support the= =20 Internet protocols.

   o  Openly available=20 implementations.  These make it easier=20 for
      researchers, start-ups and others to = build=20 on or improve existing
     =20 components.

   o  The ability to scale.  The IPv= 4=20 Internet grew far larger than its
      origina= l=20 designers had anticipated, and scaling limits only=20 became
      apparent 20-30 years=20 later.

   o  The design supports robust interoperabil= ity=20 rather than mere
      correctness.  This = is=20 important in order to ensure that the
      sol= ution=20 works in different circumstances and in an=20 imperfectly
      controlled=20 world."
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3>and in Page 6: "The= se=20 factors are also important when choosing IPv6 migration tools.",=20 but:
<= SPAN=20 class=3Dh3> 
* The I-D does not show how these factors a= re=20 applied for the tools listed in the I-D; a table with a set of criteria wou= ld be=20 useful;
 
* The first criterion is IMHO meaningless f= or IPv6=20 deployment because IPv6 does not offer a new service compared to=20 IPv4.
<= SPAN=20 class=3Dh3> 
* I'm not= sure=20 that having an open source for a given tool can be an argument to RECOMMEND= or=20 NOT a given tool;
<= SPAN=20 class=3Dh3> 
* How&nbs= p;"scalability" is defined (5th=20 bullet)?? All the solutions listed in the I-D need a NAT (l2-na= t,=20 ds-lite nat44, nat44, nat64), to what extent a CGN is considered = as=20 a scalable solution?
<= SPAN=20 class=3Dh3> 
* The las= t bullet=20 is not clear: Do you consider that DS-Lite satisfies=20 this factor? FWIW, DS-Lite has been rejected by the 3GP= P=20 because it requires specific functions on=20 the UE. 
&nb= sp;
(3)
 
From the perspective of transitioning networks to IPv6, I d= on't=20 see the rationale behind including techniques such as those listed in= =20 "4.2. Crossing IPv4 Islands" as a candidate solu= tions=20 for IPv6 deployment. This section can be removed to an=20 appendix. 
 
(= 4)=20
 
(a) I have an issue with the following=20 statements in the I-D:
 
On=20 page 6, the ID states:  "The= =20 third scenario is more advanced and looks at a service provider networ= k=20 that runs only on IPv6 but which is still capable of providing=20 both IPv6 and IPv4 services."= =20
 
a= nd in page=20 11, the ID mentions:
 
"   The recommended tool for this model is Dual Stack=20 Lite
   [I-D.ietf-intarea-shared-ad= dressing-issues]=20 are still valid when NAT64 is=20 deployed.
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3>* Page 13, change "SIP (Session Identity Protoc= ol)" to=20 "SIP (Session Initiation Protocol)";
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3>* Page 13: "One might position a web proxy,=20 a
   mail server, or a SIP (Session Identity Protocol) back-to= -back=20 user
   agent across the boundary between IPv4 and IPv6 domain= s, so=20 that the
   application terminates IPv4 sessions on one side a= nd=20 IPv6 sessions on
   the other.  Doing this preserves the= =20 end-to-end nature of
   communications between gateways. = For=20 obvious reasons, this solution
   is preferable to the=20 implementation of Application Layer Gateways in
   network lay= er=20 translators.
"
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3>(a) Why only listing the back-to= -back=20 user agent option (this option= is=20 valid)? Why not deploying means for NAT traversal is not listed as an=20 alternative?
<= SPAN=20 class=3Dh3> 
(b) "Doing = this=20 preserves the end-to-end nature of communications between gateways": Which= =20 gateways?
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3>(c) For the SIP case, still there is = a need=20 for a translator for media flows;
 
(d) Service-related discussions are not elaborated in other sections: I= would=20 prefer to have a similar=20 discussion for the DS m= odel,=20 in particular issues in SIP=20 environments to signal both IPv4 and IPv6 addresses in the SDP= =20 offers; means to prioritise the use= of=20 IPv6; how the SIP Proxy Server can determine whether there is a need to inv= oke a=20 SIP ALG/NAT64/NAT46 (e.g.., translator should be avoided when a DS UA calls= a=20 IPvx-only/DS UA. ALG/NAT46/NAT64 should be invoked only for IPvx-IPvy=20 sessions),=20 etc.
 
* Add a refe= rence to=20 http://tools.ietf.org/html/draft-ietf-v6ops-v6-in-mobile-networks-= 02
 
<= SPAN=20 class=3Dh3>(6)
 
<= SPAN=20 class=3Dh3>It would be valuable if the I-D describes some = migration=20 paths and examples about the use of the tools listed in the I-D; e.g.,: <= /DIV>
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3>* How DS-Lite CGN devices can be removed from t= he=20 network since it is supposed to be a transition solution. This would be a g= ood=20 example to apply what is stated in the I-D in page 5: "The end goal is=20 network-wide native IPv6 deployment, resulting in the
  =20 obsolescence of transitional mechanisms based on encapsulation,
 &n= bsp;=20 tunnels, or translation, and also resulting in the obsolescence=20 of
   IPv4."
<= SPAN=20 class=3Dh3> 
<= SPAN=20 class=3Dh3>* How to encourage the use of native IPv6 = transfer=20 capabilities: address selection iss= ues,=20 application considerations, etc.
 
Cheers,
Med 
*********************************
This message and any attachments (the "message") are confidential and inten=
ded solely for the addressees.=20
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.=20
France Telecom Group shall not be liable for the message if altered, change=
d or falsified.
If you are not the intended addressee of this message, please cancel it imm=
ediately and inform the sender.
********************************
--_000_94C682931C08B048B7A8645303FDC9F33C3E619705PUEXCB1Bnante_-- From hallam@gmail.com Wed Dec 29 02:27:37 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482BF3A68B0 for ; Wed, 29 Dec 2010 02:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFbUJ97py6gA for ; Wed, 29 Dec 2010 02:27:36 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id C9BAB3A68BD for ; Wed, 29 Dec 2010 02:27:35 -0800 (PST) Received: by gwj17 with SMTP id 17so6275804gwj.31 for ; Wed, 29 Dec 2010 02:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=poN4co4pXmlnxS5pCSZve7njTCBLp1yVU9Z+dgNSILU=; b=hwg4yJ/2JkWK4TNuK4vRjnNClTqE976KWm6sr0tbCxgOeA0q1zJKTz6oFrxY4yKn9Q ke+ZVKO58BToac/IW/X+zn8e7UMUFj58JmfBpM+OgRa3V00L40/L1FU2yKkt0rs0FTfo v1YkI4Qa0w7MUgugNk2VLstCayWkJUsQJETRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dX/7nXHxS+mq66w8E8+DEDbMQ9Jh7vTrNeSttAk9b+RV3QZi5/nWpT6K2g2OatJUvO iPfPqhMc96lygdNDt57EAEHs5F6wMXSS8uC7QF2nVYjz/TMVkqSc4Z+AH6Y1y33n4z+d 5EDLcBkq2A8pEK0bJ+kF9vnko1Ki2UVO3Y7BY= MIME-Version: 1.0 Received: by 10.100.228.14 with SMTP id a14mr6806587anh.239.1293618580554; Wed, 29 Dec 2010 02:29:40 -0800 (PST) Received: by 10.100.31.8 with HTTP; Wed, 29 Dec 2010 02:29:39 -0800 (PST) In-Reply-To: <4D1A2C5E.2000308@gmx.de> References: <201012281726.oBSHQnFu004377@fs4113.wdf.sap.corp> <4D1A2C5E.2000308@gmx.de> Date: Wed, 29 Dec 2010 10:29:39 +0000 Message-ID: Subject: Re: Automatically updated Table of Contents with Nroff From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=0016e6d27671f806ac04988a0b11 Cc: ietf@ietf.org, Barry Leiba X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 10:27:37 -0000 --0016e6d27671f806ac04988a0b11 Content-Type: text/plain; charset=ISO-8859-1 Gosh, we managed to have that entire discussion without a single person comparing it to emacs vs vi. oopsie. On Tue, Dec 28, 2010 at 6:28 PM, Julian Reschke wrote: > On 28.12.2010 18:26, Martin Rex wrote: > >> ... >> >> Everyone who looks at writing I-Ds should seriously consider looking >> at NRoffEdit before deciding which document format and tool to use. >> ... >> > > Everyone who looks at writing I-Ds should also seriously consider xml2rfc. > :-) > > > http://aaa-sec.com/nroffedit/ >> >> It is currently the 5th entry in the section "Prepare Documents" >> on this page: >> >> http://tools.ietf.org/ >> >> >> NRoffEdit is an all-in-one wysiwyg tool in Java that maintains >> the TOC for you (within the .nroff source itself). >> > > Which will only work properly as long the output isn't run through standard > NROFF, and page breaks change. Just saying. > > And yes, xml2rfc also maintains the TOC. > > ... >> > > Best regards, Julian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/ --0016e6d27671f806ac04988a0b11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gosh, we managed to have that entire discussion without a single person com= paring it to emacs vs vi.


oopsie.

=
On Tue, Dec 28, 2010 at 6:28 PM, Julian Reschke = <julian.resch= ke@gmx.de> wrote:
On 28.12.2010 18:26, Martin Rex wrote:
...

Everyone who looks at writing I-Ds should seriously consider looking
at NRoffEdit before deciding which document format and tool to use.
...

Everyone who looks at writing I-Ds should also seriously consider xml2rfc. = :-)


=A0 =A0http://= aaa-sec.com/nroffedit/

It is currently the 5th entry in the section "Prepare Documents"<= br> on this page:

=A0http://tools.ietf.= org/


NRoffEdit is an all-in-one wysiwyg tool in Java that maintains
the TOC for you (within the .nroff source itself).

Which will only work properly as long the output isn't run through stan= dard NROFF, and page breaks change. Just saying.

And yes, xml2rfc also maintains the TOC.

...

Best regards, Julian

_______________________________________________
Ietf mailing list
Ietf@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ietf



--
Website: http://hallambaker.com/

--0016e6d27671f806ac04988a0b11-- From dhc2@dcrocker.net Wed Dec 29 07:12:32 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F53128C0FF for ; Wed, 29 Dec 2010 07:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmAKbSiM-jsP for ; Wed, 29 Dec 2010 07:12:31 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 7252328C0FB for ; Wed, 29 Dec 2010 07:12:31 -0800 (PST) Received: from [192.168.1.95] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBTFEVYH026357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 29 Dec 2010 07:14:36 -0800 Message-ID: <4D1B5053.6000005@dcrocker.net> Date: Wed, 29 Dec 2010 07:14:27 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf@ietf.org Subject: BCP request: WiFi at High-Tech Meetings Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 29 Dec 2010 07:14:36 -0800 (PST) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 15:12:32 -0000 Time for a BCP? > The problem is that Wi-Fi was never intended for large halls and thousands of > people, many of them bristling with an arsenal of laptops, I don't recall seeing a document on this and the IETF track record has been quite good. We should share the joy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tme@americafree.tv Wed Dec 29 07:25:54 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA82528C104 for ; Wed, 29 Dec 2010 07:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJiJ-vGT6T6p for ; Wed, 29 Dec 2010 07:25:53 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id B158428C0FB for ; Wed, 29 Dec 2010 07:25:53 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 2F8879873EC2; Wed, 29 Dec 2010 10:27:59 -0500 (EST) Subject: Re: BCP request: WiFi at High-Tech Meetings Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <4D1B5053.6000005@dcrocker.net> Date: Wed, 29 Dec 2010 10:27:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <68D8EC8E-EDFE-433C-BA3D-E0D659A1FB02@americafree.tv> References: <4D1B5053.6000005@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1081) Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 15:25:54 -0000 On Dec 29, 2010, at 10:14 AM, Dave CROCKER wrote: > Time for a BCP? >=20 >=20 > = >=20 >> The problem is that Wi-Fi was never intended for large halls and = thousands of >> people, many of them bristling with an arsenal of laptops, >=20 >=20 > I don't recall seeing a document on this and the IETF track record has = been quite good. If you remember IETF 64 in Vancouver, there was a painful learning curve = along the way... Regards Marshall >=20 > We should share the joy. >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From ole@cisco.com Wed Dec 29 07:56:39 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C8B28C108 for ; Wed, 29 Dec 2010 07:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.554 X-Spam-Level: X-Spam-Status: No, score=-110.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShvaclB6nkbc for ; Wed, 29 Dec 2010 07:56:38 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 15B7028C10F for ; Wed, 29 Dec 2010 07:56:38 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0GAM7pGk2rR7H+/2dsb2JhbACWHY4ec6QPgk8OAZgTgwyCPgSEZYExhCJM X-IronPort-AV: E=Sophos;i="4.60,245,1291593600"; d="scan'208";a="308329611" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 29 Dec 2010 15:58:43 +0000 Received: from pita.cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oBTFwhGD008878; Wed, 29 Dec 2010 15:58:43 GMT Date: Wed, 29 Dec 2010 07:57:53 -0800 (PST) From: Ole Jacobsen To: dcrocker@bbiw.net Subject: Re: BCP request: WiFi at High-Tech Meetings In-Reply-To: <4D1B5053.6000005@dcrocker.net> Message-ID: References: <4D1B5053.6000005@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Ole Jacobsen List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 15:56:39 -0000 Dave, I think you will find that our NOC people have a great deal of experience and perhaps even a list of do's and don'ts for this type of design. In the end, this technology will not scale without bonds if we're talking about n-thousand people sitting in a plenary hall, but there are obviously a lot that can be done with a distribution of multiple lower-powered (configured as such) units that don't use overlapping channels, use of various 802.11 flavors (a, n, etc) and more SSIDs, all in the name of load sharing. While there may not be a document, and I agree that it would be useful to have one, there is certainly a collective body of knowledge on this topic (including a "never again use base stations from xxxx.."). Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj On Wed, 29 Dec 2010, Dave CROCKER wrote: > Time for a BCP? > > > > > > > The problem is that Wi-Fi was never intended for large halls and > > thousands of people, many of them bristling with an arsenal of > > laptops, > > > I don't recall seeing a document on this and the IETF track record has been > quite good. > > We should share the joy. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From hgs@cs.columbia.edu Wed Dec 29 08:01:57 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF7E28C10F for ; Wed, 29 Dec 2010 08:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxL9JdVnt3OM for ; Wed, 29 Dec 2010 08:01:56 -0800 (PST) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by core3.amsl.com (Postfix) with ESMTP id 1A1C928C108 for ; Wed, 29 Dec 2010 08:01:56 -0800 (PST) Received: from dhcp-10-52-4-159.rhod.uc.edu ([129.137.192.93]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id oBTG3rdY001418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Dec 2010 11:03:53 -0500 (EST) Subject: Re: BCP request: WiFi at High-Tech Meetings Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Wed, 29 Dec 2010 11:03:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72511209-CA49-438F-B415-48CD77D7F572@cs.columbia.edu> References: <4D1B5053.6000005@dcrocker.net> To: Ole Jacobsen X-Mailer: Apple Mail (2.1082) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: dcrocker@bbiw.net, The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 16:01:57 -0000 I'm curious what the largest *successful* deployment has been (measured = in number of participants in a single room/hall/stadium/...) that = anybody has seen, within the IETF or beyond. The NYC article hints at = the fact that the limit may be hotel fiber, rather than wireless, in = some cases. We seem to have more experience with dimensioning those than = other organizations. On Dec 29, 2010, at 10:57 AM, Ole Jacobsen wrote: >=20 > Dave, >=20 > I think you will find that our NOC people have a great deal of=20 > experience and perhaps even a list of do's and don'ts for this type of=20= > design. In the end, this technology will not scale without bonds if=20 > we're talking about n-thousand people sitting in a plenary hall, but=20= > there are obviously a lot that can be done with a distribution of=20 > multiple lower-powered (configured as such) units that don't use=20 > overlapping channels, use of various 802.11 flavors (a, n, etc) and=20 > more SSIDs, all in the name of load sharing. >=20 > While there may not be a document, and I agree that it would be useful=20= > to have one, there is certainly a collective body of knowledge on this > topic (including a "never again use base stations from xxxx.."). >=20 > Ole >=20 > Ole J. Jacobsen > Editor and Publisher, The Internet Protocol Journal > Cisco Systems > Tel: +1 408-527-8972 Mobile: +1 415-370-4628 > E-mail: ole@cisco.com URL: http://www.cisco.com/ipj >=20 >=20 >=20 > On Wed, 29 Dec 2010, Dave CROCKER wrote: >=20 >> Time for a BCP? >>=20 >>=20 >>=20 >> = >>=20 >>> The problem is that Wi-Fi was never intended for large halls and=20 >>> thousands of people, many of them bristling with an arsenal of=20 >>> laptops, >>=20 >>=20 >> I don't recall seeing a document on this and the IETF track record = has been >> quite good. >>=20 >> We should share the joy. >>=20 >> d/ >> --=20 >>=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >>=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From fu@cs.uni-goettingen.de Wed Dec 29 08:25:20 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4748828C11D for ; Wed, 29 Dec 2010 08:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNOEd-FFA3RI for ; Wed, 29 Dec 2010 08:25:18 -0800 (PST) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id 4F23528C106 for ; Wed, 29 Dec 2010 08:25:17 -0800 (PST) Received: from [202.119.57.51] (helo=[192.168.172.147]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PXyrx-0007yL-ES; Wed, 29 Dec 2010 17:27:22 +0100 Message-ID: <4D1B6172.8020002@cs.uni-goettingen.de> Date: Thu, 30 Dec 2010 00:27:30 +0800 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: BCP request: WiFi at High-Tech Meetings References: <4D1B5053.6000005@dcrocker.net> <72511209-CA49-438F-B415-48CD77D7F572@cs.columbia.edu> In-Reply-To: <72511209-CA49-438F-B415-48CD77D7F572@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------030309080100050701050401" X-Authenticated: Id:xfu X-Virus-Scanned: (clean) by exiscan+sophie X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 16:25:20 -0000 This is a multi-part message in MIME format. --------------030309080100050701050401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The best conference WiFi experience I had ever with was the SIGCOMM'07 conference room in Kyoto International Conference Center in Kyoto, Japan. It showed nearly no service interruption for my laptop. It might be interesting to learn from our Japanese colleagues how they managed to make it happen. Xiaoming On 12/30/2010 12:03 AM, Henning Schulzrinne wrote: > I'm curious what the largest *successful* deployment has been (measured in number of participants in a single room/hall/stadium/...) that anybody has seen, within the IETF or beyond. The NYC article hints at the fact that the limit may be hotel fiber, rather than wireless, in some cases. We seem to have more experience with dimensioning those than other organizations. > > On Dec 29, 2010, at 10:57 AM, Ole Jacobsen wrote: > >> Dave, >> >> I think you will find that our NOC people have a great deal of >> experience and perhaps even a list of do's and don'ts for this type of >> design. In the end, this technology will not scale without bonds if >> we're talking about n-thousand people sitting in a plenary hall, but >> there are obviously a lot that can be done with a distribution of >> multiple lower-powered (configured as such) units that don't use >> overlapping channels, use of various 802.11 flavors (a, n, etc) and >> more SSIDs, all in the name of load sharing. >> >> While there may not be a document, and I agree that it would be useful >> to have one, there is certainly a collective body of knowledge on this >> topic (including a "never again use base stations from xxxx.."). >> >> Ole >> >> Ole J. Jacobsen >> Editor and Publisher, The Internet Protocol Journal >> Cisco Systems >> Tel: +1 408-527-8972 Mobile: +1 415-370-4628 >> E-mail: ole@cisco.com URL: http://www.cisco.com/ipj >> >> >> >> On Wed, 29 Dec 2010, Dave CROCKER wrote: >> >>> Time for a BCP? >>> >>> >>> >>> >>> >>>> The problem is that Wi-Fi was never intended for large halls and >>>> thousands of people, many of them bristling with an arsenal of >>>> laptops, >>> >>> I don't recall seeing a document on this and the IETF track record has been >>> quite good. >>> >>> We should share the joy. >>> >>> d/ >>> -- >>> >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Prof. Dr. Xiaoming Fu http://user.informatik.uni-goettingen.de/~fu Computer Networks Group http://www.net.informatik.uni-goettingen.de/ Institute of Computer Science, Faculty of Mathematics& Computer Science University of Goettingen E-Mail: fu@cs.uni-goettingen.de Goldschmidtstr. 7 Tel/Secr: +49-(0)551-39-1720 23/20 37077 Goettingen, Germany Fax: +49-(0)551-39-14416 --------------030309080100050701050401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The best conference WiFi experience I had ever with was the SIGCOMM'07 conference room in Kyoto International Conference Center in Kyoto, Japan. It showed nearly no service interruption for my laptop. It might be interesting to learn from our Japanese colleagues how they managed to make it happen.
Xiaoming
On 12/30/2010 12:03 AM, Henning Schulzrinne wrote: 
I'm curious what the largest *successful* deployment has been (measured in number of participants in a single room/hall/stadium/...) that anybody has seen, within the IETF or beyond. The NYC article hints at the fact that the limit may be hotel fiber, rather than wireless, in some cases. We seem to have more experience with dimensioning those than other organizations.

On Dec 29, 2010, at 10:57 AM, Ole Jacobsen wrote:


Dave,

I think you will find that our NOC people have a great deal of 
experience and perhaps even a list of do's and don'ts for this type of 
design. In the end, this technology will not scale without bonds if 
we're talking about n-thousand people sitting in a plenary hall, but 
there are obviously a lot that can be done with a distribution of 
multiple lower-powered (configured as such) units that don't use 
overlapping channels, use of various 802.11 flavors (a, n, etc) and 
more SSIDs, all in the name of load sharing.

While there may not be a document, and I agree that it would be useful 
to have one, there is certainly a collective body of knowledge on this
topic (including a "never again use base stations from xxxx..").

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: ole@cisco.com  URL: http://www.cisco.com/ipj



On Wed, 29 Dec 2010, Dave CROCKER wrote:


Time for a BCP?



<http://www.nytimes.com/2010/12/29/technology/29wifi.html?_r=1&nl=todaysheadlines&emc=tha25>


The problem is that Wi-Fi was never intended for large halls and 
thousands of people, many of them bristling with an arsenal of 
laptops,


I don't recall seeing a document on this and the IETF track record has been
quite good.

We should share the joy.

d/
-- 

 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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


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


-- 
Prof. Dr. Xiaoming Fu      http://user.informatik.uni-goettingen.de/~fu
Computer Networks Group    http://www.net.informatik.uni-goettingen.de/
Institute of Computer Science, Faculty of Mathematics & Computer Science
University of Goettingen   E-Mail: fu@cs.uni-goettingen.de
Goldschmidtstr. 7          Tel/Secr: +49-(0)551-39-1720 23/20
37077 Goettingen, Germany  Fax:      +49-(0)551-39-14416
--------------030309080100050701050401-- From rbarnes@bbn.com Wed Dec 29 08:30:42 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07293A63C9 for ; Wed, 29 Dec 2010 08:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kuheuPb4+My for ; Wed, 29 Dec 2010 08:30:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8C7D33A63CB for ; Wed, 29 Dec 2010 08:30:39 -0800 (PST) Received: from [128.89.252.185] (port=62165 helo=[192.168.1.102]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PXyx9-0009s2-BK; Wed, 29 Dec 2010 11:32:43 -0500 Subject: Re: BCP request: WiFi at High-Tech Meetings Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 29 Dec 2010 11:32:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D1B5053.6000005@dcrocker.net> To: Ole Jacobsen X-Mailer: Apple Mail (2.1082) Cc: dcrocker@bbiw.net, The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 16:30:42 -0000 Jonny Martin did a nice little lightning talk on the topic at APNIC 29: = On Dec 29, 2010, at 10:57 AM, Ole Jacobsen wrote: >=20 > Dave, >=20 > I think you will find that our NOC people have a great deal of=20 > experience and perhaps even a list of do's and don'ts for this type of=20= > design. In the end, this technology will not scale without bonds if=20 > we're talking about n-thousand people sitting in a plenary hall, but=20= > there are obviously a lot that can be done with a distribution of=20 > multiple lower-powered (configured as such) units that don't use=20 > overlapping channels, use of various 802.11 flavors (a, n, etc) and=20 > more SSIDs, all in the name of load sharing. >=20 > While there may not be a document, and I agree that it would be useful=20= > to have one, there is certainly a collective body of knowledge on this > topic (including a "never again use base stations from xxxx.."). >=20 > Ole >=20 > Ole J. Jacobsen > Editor and Publisher, The Internet Protocol Journal > Cisco Systems > Tel: +1 408-527-8972 Mobile: +1 415-370-4628 > E-mail: ole@cisco.com URL: http://www.cisco.com/ipj >=20 >=20 >=20 > On Wed, 29 Dec 2010, Dave CROCKER wrote: >=20 >> Time for a BCP? >>=20 >>=20 >>=20 >> = >>=20 >>> The problem is that Wi-Fi was never intended for large halls and=20 >>> thousands of people, many of them bristling with an arsenal of=20 >>> laptops, >>=20 >>=20 >> I don't recall seeing a document on this and the IETF track record = has been >> quite good. >>=20 >> We should share the joy. >>=20 >> d/ >> --=20 >>=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >>=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From joelja@bogus.com Wed Dec 29 08:38:36 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3373A67D3 for ; Wed, 29 Dec 2010 08:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56Wfaiz04Gs3 for ; Wed, 29 Dec 2010 08:38:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 086BD3A67D2 for ; Wed, 29 Dec 2010 08:38:34 -0800 (PST) Received: from joelja-mac.local (c-76-115-175-145.hsd1.wa.comcast.net [76.115.175.145]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id oBTGe5Aw027838 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 29 Dec 2010 16:40:05 GMT (envelope-from joelja@bogus.com) Message-ID: <4D1B6415.4040502@bogus.com> Date: Wed, 29 Dec 2010 08:38:45 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: BCP request: WiFi at High-Tech Meetings References: <4D1B5053.6000005@dcrocker.net> <72511209-CA49-438F-B415-48CD77D7F572@cs.columbia.edu> In-Reply-To: <72511209-CA49-438F-B415-48CD77D7F572@cs.columbia.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ole Jacobsen , dcrocker@bbiw.net, The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 16:38:36 -0000 On 12/29/10 8:03 AM, Henning Schulzrinne wrote: > I'm curious what the largest *successful* deployment has been > (measured in number of participants in a single > room/hall/stadium/...) that anybody has seen, within the IETF or > beyond. The NYC article hints at the fact that the limit may be hotel > fiber, rather than wireless, in some cases. We seem to have more > experience with dimensioning those than other organizations. hotel facilities range from acceptable to godawful... The biggest problem by far is cochannel interference, and the best way to solve that is more channels. The ability to use 802.11a's 11 non-overlapping bands is the move effective method by far. It's doesn't work if you have to serve 8000 iphones but in a environment full of business class laptops, more that half your customers will move over there by default. joel > On Dec 29, 2010, at 10:57 AM, Ole Jacobsen wrote: > >> >> Dave, >> >> I think you will find that our NOC people have a great deal of >> experience and perhaps even a list of do's and don'ts for this type >> of design. In the end, this technology will not scale without bonds >> if we're talking about n-thousand people sitting in a plenary hall, >> but there are obviously a lot that can be done with a distribution >> of multiple lower-powered (configured as such) units that don't use >> overlapping channels, use of various 802.11 flavors (a, n, etc) >> and more SSIDs, all in the name of load sharing. >> >> While there may not be a document, and I agree that it would be >> useful to have one, there is certainly a collective body of >> knowledge on this topic (including a "never again use base stations >> from xxxx.."). >> >> Ole >> >> Ole J. Jacobsen Editor and Publisher, The Internet Protocol >> Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 >> 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj >> >> >> >> On Wed, 29 Dec 2010, Dave CROCKER wrote: >> >>> Time for a BCP? >>> >>> >>> >>> >>> >>>> >>> The problem is that Wi-Fi was never intended for large halls and >>>> thousands of people, many of them bristling with an arsenal of >>>> laptops, >>> >>> >>> I don't recall seeing a document on this and the IETF track >>> record has been quite good. >>> >>> We should share the joy. >>> >>> d/ -- >>> >>> Dave Crocker Brandenburg InternetWorking bbiw.net >>> _______________________________________________ Ietf mailing >>> list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf >>> >> _______________________________________________ Ietf mailing list >> Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf >> > > _______________________________________________ Ietf mailing list > Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf > From chelliot@gmail.com Wed Dec 29 08:53:44 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E243A6813 for ; Wed, 29 Dec 2010 08:53:44 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOOcoFk60RuU for ; Wed, 29 Dec 2010 08:53:43 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 211DD3A6812 for ; Wed, 29 Dec 2010 08:53:43 -0800 (PST) Received: by gwj17 with SMTP id 17so6370551gwj.31 for ; Wed, 29 Dec 2010 08:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=nRJG7g/xiMgs2YXBWKvv2j99xlozRsvFwJEgf9CZLOw=; b=YWdV5NgRR7W8i1Qzn7xQd3zSn8XensaT5mnaEy32fRSi+2P2ld1BCYmJp66dVOhF86 yzja/JLiNTF+rQtMCynn5B18siWp7LeI1m4Yp3DE9Jz7cbABJMpUR28WhejLCKYGzxjJ bBLY76Aame7QMOfjtiath/5iZKSRnllyyw87Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; b=XWeh/WLJ3U0Hnidq4N1kQFddVe6bYuGAqAW3inL47CyyK8LdnPK7CR53/GTH1z4vgo yI9ygHdf3rpa9nPbN4s9xdVD00rJLDI65KP/ZOJDCWKTdxJx1om1iX819ktH7h0LuSkB PUv8SjVSfL121XI0IVW6uxqxNJ6Xfm44bs+08= Received: by 10.91.51.22 with SMTP id d22mr5960378agk.175.1293641748306; Wed, 29 Dec 2010 08:55:48 -0800 (PST) Received: from [10.65.20.216] ([166.205.137.142]) by mx.google.com with ESMTPS id n67sm8205736yha.26.2010.12.29.08.55.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Dec 2010 08:55:46 -0800 (PST) Sender: Chris Elliott References: <4D1B5053.6000005@dcrocker.net> <72511209-CA49-438F-B415-48CD77D7F572@cs.columbia.edu> <4D1B6415.4040502@bogus.com> In-Reply-To: <4D1B6415.4040502@bogus.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <1126A907-D244-4C0C-B640-B356A1D1A48C@pobox.com> X-Mailer: iPhone Mail (8C148) From: Chris Elliott Subject: Re: BCP request: WiFi at High-Tech Meetings Date: Wed, 29 Dec 2010 08:55:34 -0800 To: Joel Jaeggli Cc: Ole Jacobsen , The IETF , "dcrocker@bbiw.net" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 16:53:44 -0000 On Dec 29, 2010, at 8:38 AM, Joel Jaeggli wrote: > On 12/29/10 8:03 AM, Henning Schulzrinne wrote: >> I'm curious what the largest *successful* deployment has been >> (measured in number of participants in a single >> room/hall/stadium/...) that anybody has seen, within the IETF or >> beyond. The NYC article hints at the fact that the limit may be hotel >> fiber, rather than wireless, in some cases. We seem to have more >> experience with dimensioning those than other organizations. Our network requirements doc at http://iaoc.ietf.org/network_requirements.ht= ml is somewhat relevant. > hotel facilities range from acceptable to godawful... The IETF has the luxury of getting donations of high speed connectivity to m= any of our meetings. > The biggest problem by far is cochannel interference, and the best way > to solve that is more channels. The ability to use 802.11a's 11 > non-overlapping bands is the move effective method by far. It's doesn't > work if you have to serve 8000 iphones but in a environment full of > business class laptops, more that half your customers will move over > there by default. I strongly agree here. Encourage .11a (5ghz) usage, disable .11n for the .11= b/g 2.4ghz spectrum. We also have the luxury of a large number of repeat att= endees, and many of you have learned the benefits of using .11a and will go o= ut of your way to use it. We facilitate that through advertising .11a-only S= SID's. So, yes, some of what we've learned would apply to other events, but some is= very tailored to the IETF's needs. Chris. > joel >=20 >> On Dec 29, 2010, at 10:57 AM, Ole Jacobsen wrote: >>=20 >>>=20 >>> Dave, >>>=20 >>> I think you will find that our NOC people have a great deal of=20 >>> experience and perhaps even a list of do's and don'ts for this type >>> of design. In the end, this technology will not scale without bonds >>> if we're talking about n-thousand people sitting in a plenary hall, >>> but there are obviously a lot that can be done with a distribution >>> of multiple lower-powered (configured as such) units that don't use >>> overlapping channels, use of various 802.11 flavors (a, n, etc) >>> and more SSIDs, all in the name of load sharing. >>>=20 >>> While there may not be a document, and I agree that it would be >>> useful to have one, there is certainly a collective body of >>> knowledge on this topic (including a "never again use base stations >>> from xxxx.."). >>>=20 >>> Ole >>>=20 >>> Ole J. Jacobsen Editor and Publisher, The Internet Protocol >>> Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 >>> 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj >>>=20 >>>=20 >>>=20 >>> On Wed, 29 Dec 2010, Dave CROCKER wrote: >>>=20 >>>> Time for a BCP? >>>>=20 >>>>=20 >>>>=20 >>>> >>>>=20 >>>>>=20 >>>>=20 > The problem is that Wi-Fi was never intended for large halls and >>>>> thousands of people, many of them bristling with an arsenal of >>>>> laptops, >>>>=20 >>>>=20 >>>> I don't recall seeing a document on this and the IETF track >>>> record has been quite good. >>>>=20 >>>> We should share the joy. >>>>=20 >>>> d/ -- >>>>=20 >>>> Dave Crocker Brandenburg InternetWorking bbiw.net=20 >>>> _______________________________________________ Ietf mailing >>>> list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf >>>>=20 >>> _______________________________________________ Ietf mailing list=20 >>> Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf >>>=20 >>=20 >> _______________________________________________ Ietf mailing list=20 >> Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf >>=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From lconroy@insensate.co.uk Wed Dec 29 09:20:04 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B91F3A6800 for ; Wed, 29 Dec 2010 09:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCmMIcNi3Owu for ; Wed, 29 Dec 2010 09:20:03 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id C12153A683D for ; Wed, 29 Dec 2010 09:20:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 04494B0FB1F for ; Wed, 29 Dec 2010 17:22:06 +0000 (GMT) From: Lawrence Conroy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: WiFI and authentication Date: Wed, 29 Dec 2010 17:22:06 +0000 Message-Id: To: The IETF Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 17:20:04 -0000 Hi Folks, whilst everyone is on the topic of WiFi ... Now that the meeting in the PRC is over, is there any intention to continue the WiFi authentication shenanigans? [802.1X stuff, entering the magic number on your badge, ...] That seemed to be another added complexity @ Maastricht, so I'd prefer this to disappear. If this business IS to be continued, why? all the best, Lawrence From dwm@xpasc.com Wed Dec 29 09:50:36 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78C83A6407 for ; Wed, 29 Dec 2010 09:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQernSNY-Nwb for ; Wed, 29 Dec 2010 09:50:35 -0800 (PST) Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id 28E6C3A6851 for ; Wed, 29 Dec 2010 09:50:35 -0800 (PST) Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 450AF100585 for ; Wed, 29 Dec 2010 09:52:41 -0800 (PST) X-Propel-Return-Path: Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.2.exported $Rev: 9262 $) id iz6UracthQE0; Wed, 29 Dec 2010 09:52:41 -0800 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id D244A100584 for ; Wed, 29 Dec 2010 09:52:40 -0800 (PST) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id oBTHqe6D024660 for ; Wed, 29 Dec 2010 09:52:40 -0800 Date: Wed, 29 Dec 2010 09:52:40 -0800 (PST) From: David Morris cc: The IETF Subject: Re: BCP request: WiFi at High-Tech Meetings In-Reply-To: <72511209-CA49-438F-B415-48CD77D7F572@cs.columbia.edu> Message-ID: References: <4D1B5053.6000005@dcrocker.net> <72511209-CA49-438F-B415-48CD77D7F572@cs.columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6UracthQE0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 17:50:37 -0000 On Wed, 29 Dec 2010, Henning Schulzrinne wrote: > I'm curious what the largest *successful* deployment has been (measured > in number of participants in a single room/hall/stadium/...) that > anybody has seen, within the IETF or beyond. The NYC article hints at > the fact that the limit may be hotel fiber, rather than wireless, in > some cases. We seem to have more experience with dimensioning those than > other organizations. The Apple WWDC I attended in 2008 had easily double the number of participants in one room as have ever attended a single WiFi enabled IETF ... as an individual I experienced no difficulty being online from the room. From fred@cisco.com Wed Dec 29 11:17:55 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1D53A6855 for ; Wed, 29 Dec 2010 11:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.467 X-Spam-Level: X-Spam-Status: No, score=-110.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkA9fpjGLDcS for ; Wed, 29 Dec 2010 11:17:54 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6B1E43A67D6 for ; Wed, 29 Dec 2010 11:17:54 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0GAOsYG02rR7Ht/2dsb2JhbACWHo4ec6Qlmn+FSgSEZYYf X-IronPort-AV: E=Sophos;i="4.60,245,1291593600"; d="scan'208";a="394922758" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 29 Dec 2010 19:20:00 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBTJJxOb026654; Wed, 29 Dec 2010 19:19:59 GMT Subject: Re: BCP request: WiFi at High-Tech Meetings Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4D1B5053.6000005@dcrocker.net> Date: Wed, 29 Dec 2010 11:19:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2A056EA8-5437-44F5-AAC7-F8C9BB2564D3@cisco.com> References: <4D1B5053.6000005@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 19:17:55 -0000 I would suggest having it written by Austria Telecom and WIDE.=20 On Dec 29, 2010, at 7:14 AM, Dave CROCKER wrote: > Time for a BCP? >=20 >=20 > = >=20 >> The problem is that Wi-Fi was never intended for large halls and = thousands of >> people, many of them bristling with an arsenal of laptops, >=20 >=20 > I don't recall seeing a document on this and the IETF track record has = been quite good. >=20 > We should share the joy. >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From mrex@sap.com Wed Dec 29 18:23:08 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B892F28C134 for ; Wed, 29 Dec 2010 18:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJJ3OqaaR6tq for ; Wed, 29 Dec 2010 18:23:07 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 0922E28C133 for ; Wed, 29 Dec 2010 18:23:06 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBU2P9VT026928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Dec 2010 03:25:10 +0100 (MET) From: Martin Rex Message-Id: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> Subject: Re: Automatically updated Table of Contents with Nroff To: julian.reschke@gmx.de (Julian Reschke) Date: Thu, 30 Dec 2010 03:25:09 +0100 (MET) In-Reply-To: <4D1A2C5E.2000308@gmx.de> from "Julian Reschke" at Dec 28, 10 07:28:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org, barryleiba@computer.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 02:23:08 -0000 Julian Reschke wrote: > > On 28.12.2010 18:26, Martin Rex wrote: > > ... > > Everyone who looks at writing I-Ds should seriously consider looking > > at NRoffEdit before deciding which document format and tool to use. > > ... > > Everyone who looks at writing I-Ds should also seriously consider > xml2rfc. :-) Only if he is in for a lot of pain and trouble. I tried to use xml2rfc once and gave up after 3 hours of getting NOWHERE, not even _running_ xml2rfc. I've been using cygwin for ~10 years (primarily as X-Server tunneling through SSH and a few unix shell utilities, but the subset of what I had installed wasn't capable of running xml2rfc. Trying to update my existing (>3 year old) cygwin installation to get the necessary tools hosed my entire cygwin installation, so I had to restore that part from backup later on). My productive Linux installation (~5 year old) wasn't capable of running xml2rfc and my Live distro I tried (Knoppix5) neither. With NRoffEdit I was busy writing my first I-D 30 minutes after downloading the software. It just worked intuitively and hazzle-free on _all_ of my Windows machines. Out of curiosity, I just tried it on my productive Linux machine. Starting it took me ~5 minutes (copying the stuff over from Windows, finding the java binary and figuring out that I have to type "/some/where/bin/java -jar /tmp/NroffEdit/NroffEdit.jar" I haven't figured out how to make it/Java use fixed width fonts on Linux yet, though (a problem that I didn't have on Windows). > > > http://aaa-sec.com/nroffedit/ > > > > It is currently the 5th entry in the section "Prepare Documents" > > on this page: > > > > http://tools.ietf.org/ > > > > > > NRoffEdit is an all-in-one wysiwyg tool in Java that maintains > > the TOC for you (within the .nroff source itself). > > Which will only work properly as long the output isn't run through > standard NROFF, and page breaks change. Just saying. Huh? That problem simply does not exist. NRoffEdit creates the same result as nroff used by the RFC Editor, so there is not going to be any different page breaks. With most I-Ds you can tell when authors are using xml2rfc instead of NRoffEdit, because the documents often contain awkward page breaks positionas within sections such as Authors and References and more typos. > > And yes, xml2rfc also maintains the TOC. That is a funny way to put it. I-Ds created with xml2rfc often contain stale section references because section numbering is "automatic" while section referencing appears to be manual (and the latter therefore regularly forgotten). NRoffEdit updates the TOC while you're editing the document and press and you immediately see the result in the preview window. Every xml2rfc operation is a manual operation on the commandline completely seperate from you Editor, and you need another manual intervention a to see the result (which you might need in order to create/update section cross-references). To me "xml2rfc maintains the TOC" sound like a slight exxageration of the significant complexity of the underlying workflow (an issue whose solution is left up entirely to the xml2rfc user). -Martin From randy_presuhn@mindspring.com Wed Dec 29 21:09:24 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757DB3A690E for ; Wed, 29 Dec 2010 21:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.994 X-Spam-Level: X-Spam-Status: No, score=-99.994 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_20=-0.74, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9oiOZXksYio for ; Wed, 29 Dec 2010 21:09:23 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 841353A6831 for ; Wed, 29 Dec 2010 21:09:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UgfkEWMO4bTYIWqsjASRP53ARvb+L8XA2oeH4l/fbqd7BjmHA4b0APDJGhee6W5d; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.49.198] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PYAnQ-000803-T5 for ietf@ietf.org; Thu, 30 Dec 2010 00:11:29 -0500 Message-ID: <001e01cba717$03bb8b20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "IETF Discussion" References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> Subject: Re: Automatically updated Table of Contents with Nroff Date: Tue, 28 Dec 2010 21:12:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888d26d9b9edb73dbfb115273ed30fcd0393c9ef3d9c3ea36e9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.198 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 05:09:24 -0000 Hi - > From: "Martin Rex" > To: "Julian Reschke" > Cc: ; > Sent: Wednesday, December 29, 2010 6:25 PM > Subject: Re: Automatically updated Table of Contents with Nroff ... > I tried to use xml2rfc once and gave up after 3 hours of getting NOWHERE, > not even _running_ xml2rfc. FWIW, I've never been able to get xml3rfc to run on any of my computers. Something horrible usually happens in the process of getting the TCL stuff working. So, I just use the on-line one at http://xml.resource.org/ Getting groff to run, on the other hand, has been fairly easy on every platform I've tried. ... > With most I-Ds you can tell when authors are using xml2rfc instead > of NRoffEdit, because the documents often contain awkward page breaks > positionas within sections such as Authors and References and more > typos. It's easier to control widows / orphans / page breaks with nroff, but I don't usually worry about them because I know the RFC editor is going to fine-tune the layout anyway. Randy From doug@ewellic.org Wed Dec 29 21:29:46 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345A728C133 for ; Wed, 29 Dec 2010 21:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF8-TfGv6AwK for ; Wed, 29 Dec 2010 21:29:44 -0800 (PST) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id ADD1A3A681A for ; Wed, 29 Dec 2010 21:29:44 -0800 (PST) Received: (qmail 11038 invoked from network); 30 Dec 2010 05:31:49 -0000 Received: from unknown (24.8.55.39) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 30 Dec 2010 05:31:49 -0000 Message-ID: From: "Doug Ewell" To: , "Julian Reschke" References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> In-Reply-To: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> Subject: Re: Automatically updated Table of Contents with Nroff Date: Wed, 29 Dec 2010 22:31:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3502.922 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3502.922 Cc: barryleiba@computer.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 05:29:46 -0000 Martin Rex wrote: >> Everyone who looks at writing I-Ds should also seriously consider >> xml2rfc. :-) > > Only if he is in for a lot of pain and trouble... I used xml2rfc (the online version, not installing it) to write RFC 4645 and 5646, including numerous drafts, without any significant pain or difficulty getting the desired results. Then again, I write code for a living, so writing XML by hand isn't my idea of pain. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ­ From julian.reschke@gmx.de Thu Dec 30 00:35:00 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B61E3A6860 for ; Thu, 30 Dec 2010 00:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.55 X-Spam-Level: X-Spam-Status: No, score=-104.55 tagged_above=-999 required=5 tests=[AWL=-1.951, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsnR+xNMn0uG for ; Thu, 30 Dec 2010 00:34:59 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id E14293A6830 for ; Thu, 30 Dec 2010 00:34:58 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2010 08:37:02 -0000 Received: from p508FA007.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.160.7] by mail.gmx.net (mp027) with SMTP; 30 Dec 2010 09:37:02 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19mg69o5X5mdz0M/JddzzS+Fl/Ap/VEEPbGY9PC0u vsZW+ltRd2MVp0 Message-ID: <4D1C44A9.7050401@gmx.de> Date: Thu, 30 Dec 2010 09:36:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Doug Ewell Subject: spec gen tools, was: Automatically updated Table of Contents with Nroff References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 08:35:00 -0000 On 30.12.2010 06:31, Doug Ewell wrote: > Martin Rex wrote: > >>> Everyone who looks at writing I-Ds should also seriously consider >>> xml2rfc. :-) >> >> Only if he is in for a lot of pain and trouble... > > I used xml2rfc (the online version, not installing it) to write RFC 4645 > and 5646, including numerous drafts, without any significant pain or > difficulty getting the desired results. Then again, I write code for a > living, so writing XML by hand isn't my idea of pain. We had that discussion before :-); not sure why it got into this thread (which wasn't about preferences, but how to generate what the RFC Production Center wants from xml2rfc source). But while we're at the topic of *running* xml2rfc: I always advise people to run it locally; it's faster, more easily automated, and gives you better diagnostics. On Windows I use Cygwin (*), which has been running xml2rfc.tcl flawlessly for me for something like the past 7 years. Finally, don't run xml2rfc until you need to; to preview while editing, just use the XSLT and open the XML file in a web browser. Best regards, Julian (*) Martin; yes, upgrading Cygwin is a pain. It's a one-time cost. Many people are on MacOS anyway, where things are even easier, I hear. From ynir@checkpoint.com Thu Dec 30 01:36:24 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E00228B23E for ; Thu, 30 Dec 2010 01:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.839 X-Spam-Level: X-Spam-Status: No, score=-9.839 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B73OheJ+6C8 for ; Thu, 30 Dec 2010 01:36:23 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 2C1393A68F9 for ; Thu, 30 Dec 2010 01:36:22 -0800 (PST) X-CheckPoint: {4D1C5313-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBU9cRi1001939 for ; Thu, 30 Dec 2010 11:38:27 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 30 Dec 2010 11:38:27 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 30 Dec 2010 11:38:27 +0200 From: Yoav Nir To: "ietf@ietf.org" Date: Thu, 30 Dec 2010 11:38:25 +0200 Subject: Question about Prague Thread-Topic: Question about Prague Thread-Index: AcuoBU+BIm7kAW+1R+OzY35dqwgj2g== 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 09:36:24 -0000 Hi The Prague meeting is still nearly 3 months away, but I'm wondering why the= re's only a date yet. No hotel, no registration, no details.=20 Some of us need to get the corporate wheels or authorization moving. Thanks Yoav From cabo@tzi.org Thu Dec 30 01:48:49 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FAC93A692B for ; Thu, 30 Dec 2010 01:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.425 X-Spam-Level: X-Spam-Status: No, score=-106.425 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U67xw5gf13s8 for ; Thu, 30 Dec 2010 01:48:46 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6D48F3A692A for ; Thu, 30 Dec 2010 01:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oBU9ohd1007167; Thu, 30 Dec 2010 10:50:43 +0100 (CET) Received: from [192.168.217.101] (p5489BC61.dip.t-dialin.net [84.137.188.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BC06ED49; Thu, 30 Dec 2010 10:50:42 +0100 (CET) Subject: Re: spec gen tools, was: Automatically updated Table of Contents with Nroff Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4D1C44A9.7050401@gmx.de> Date: Thu, 30 Dec 2010 10:50:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C3E054B-EE3C-4F7B-A40B-5AAD3A3738E5@tzi.org> References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> <4D1C44A9.7050401@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1082) Cc: IETF discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 09:48:49 -0000 > But while we're at the topic of *running* xml2rfc: I always advise = people to run it locally; One problem is that the "default" way of doing references in RFC 2629 = XML appears to perform an online fetch of the reference information for = each build, with no caching whatsoever. If you do have to look at the = ASCII (yes, sometimes tables etc. need some tweaking), this is a pain. (My markdown-to-RFC2629 workflow does some caching here, but life = becomes painful again when interacting with XML-only co-authors.) BTW, if you are on a Mac, get one of the package managers "macports" or = "homebrew", and do port install xml2rfc or brew install xml2rfc > Finally, don't run xml2rfc until you need to; to preview while = editing, just use the XSLT and open the XML file in a web browser. Indeed -- thanks Julian for this wonderful tool. Get it from . Just put the line as the second line of the xml, and open the xml in a browser. (The only caveat I'm aware of is that you cannot really use the ugly = vspace-999 hack for page break tweaks any more. Good riddance. Switch = to the needLines PI. That one appears to be acting a bit strange in = xml2rfc, though. It usually works for me with .) Gruesse, Carsten From julian.reschke@gmx.de Thu Dec 30 01:57:01 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB0628C0DF for ; Thu, 30 Dec 2010 01:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.53 X-Spam-Level: X-Spam-Status: No, score=-104.53 tagged_above=-999 required=5 tests=[AWL=-1.931, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH0nPZKnalR1 for ; Thu, 30 Dec 2010 01:56:59 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id DEB6D28C0E4 for ; Thu, 30 Dec 2010 01:56:58 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2010 09:59:02 -0000 Received: from p508FA007.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.160.7] by mail.gmx.net (mp042) with SMTP; 30 Dec 2010 10:59:02 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/po9MbfTXp59B5s/7RfI0b+0Ou7Xtuh+bgNW3pIF ROeY6n3QTr0GxI Message-ID: <4D1C57E0.9070705@gmx.de> Date: Thu, 30 Dec 2010 10:58:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Carsten Bormann Subject: Re: spec gen tools, was: Automatically updated Table of Contents with Nroff References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> <4D1C44A9.7050401@gmx.de> <0C3E054B-EE3C-4F7B-A40B-5AAD3A3738E5@tzi.org> In-Reply-To: <0C3E054B-EE3C-4F7B-A40B-5AAD3A3738E5@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 09:57:01 -0000 On 30.12.2010 10:50, Carsten Bormann wrote: >> But while we're at the topic of *running* xml2rfc: I always advise people to run it locally; > > One problem is that the "default" way of doing references in RFC 2629 XML appears to perform an online fetch of the reference information for each build, with no caching whatsoever. If you do have to look at the ASCII (yes, sometimes tables etc. need some tweaking), this is a pain. Yes, that's why I always recommend not to use that style. > (My markdown-to-RFC2629 workflow does some caching here, but life becomes painful again when interacting with XML-only co-authors.) > > BTW, if you are on a Mac, get one of the package managers "macports" or "homebrew", and do > > port install xml2rfc > > or > > brew install xml2rfc Interesting. Does this get you a current version, though? >> Finally, don't run xml2rfc until you need to; to preview while editing, just use the XSLT and open the XML file in a web browser. > > Indeed -- thanks Julian for this wonderful tool. > Get it from. > Just put the line > > > > as the second line of the xml, and open the xml in a browser. > (The only caveat I'm aware of is that you cannot really use the ugly vspace-999 hack for page break tweaks any more. Good riddance. Switch to the needLines PI. That one appears to be acting a bit strange in xml2rfc, though. It usually works for me with.) If you educate me what it's supposed to do (force a page break?), I can look into adding it to the XSLT (it would only have an effect for print preview, but I assume that would be ok?). Best regards, Julian From hallam@gmail.com Thu Dec 30 03:41:10 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EEE3A67F5 for ; Thu, 30 Dec 2010 03:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LPbsBLjrjOV for ; Thu, 30 Dec 2010 03:41:08 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 1A1A73A67F4 for ; Thu, 30 Dec 2010 03:41:08 -0800 (PST) Received: by ywk9 with SMTP id 9so4986012ywk.31 for ; Thu, 30 Dec 2010 03:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9CakraaGLUazr/TpHgEYKIj2zAwOq3YugoXtL+0vKkY=; b=ajCemIh8c6h90oyRJcnKasD5h97BbhY//20tgyNgn0NPM0LorTLsIk1S5aYeG2+3wl peuJPz8tGeALB0r/Z+UPAytqtH/ASmDhl4gw7rbJ35OoI5WAv/n/o4PgLo3tkgBO3gTa +e7VmZZ/adq3sPbyKhZJe3KtAABGhm+N3lyrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wKc1qN/ZF12RJpSE8G9YgyTH4JOuWlgZVWf08DkjRUIQBL8vu3bLJDJCTlf5eZ2amw dFYLg5ulG+wjV+VLllUJMbp7YzVfDRETWFQGMM/HLInxOTVg9P3n8xccb873FYG1YiA5 YBbdVqCDQv5s703Ds84NhoZ5k2GNf6dOGnQBM= MIME-Version: 1.0 Received: by 10.100.228.14 with SMTP id a14mr7692000anh.239.1293709392923; Thu, 30 Dec 2010 03:43:12 -0800 (PST) Received: by 10.100.31.8 with HTTP; Thu, 30 Dec 2010 03:43:12 -0800 (PST) In-Reply-To: <4D1C57E0.9070705@gmx.de> References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> <4D1C44A9.7050401@gmx.de> <0C3E054B-EE3C-4F7B-A40B-5AAD3A3738E5@tzi.org> <4D1C57E0.9070705@gmx.de> Date: Thu, 30 Dec 2010 11:43:12 +0000 Message-ID: Subject: Re: spec gen tools, was: Automatically updated Table of Contents with Nroff From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=0016e6d27671cecc1404989f3089 Cc: Carsten Bormann , IETF discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 11:41:10 -0000 --0016e6d27671cecc1404989f3089 Content-Type: text/plain; charset=ISO-8859-1 My personal preference would be for Google docs to change their HTML generator so that it preserves the structure of the layout (H1, H2 etc) rather than just the presentation. That way we could have multiple people edit the same doc without having to swap files about in email. As a document format, the XML2RFC format is terrible. It uses all the abominable features of SGML. Rather disappointingly for a format intended for use by a standards organization it is different to HTML in ways that serve no purpose other than to prevent the use of widely available tools. One improvement that we could realize with little effort would be to simply replace the individual entity declaration files for the RFC references with one great big honking file containing all of them. That way it would only be necessary to maintain citations in two places rather than three as at present. It would be much better if the references could be generated automatically though. On Thu, Dec 30, 2010 at 9:58 AM, Julian Reschke wrote: > On 30.12.2010 10:50, Carsten Bormann wrote: > >> But while we're at the topic of *running* xml2rfc: I always advise people >>> to run it locally; >>> >> >> One problem is that the "default" way of doing references in RFC 2629 XML >> appears to perform an online fetch of the reference information for each >> build, with no caching whatsoever. If you do have to look at the ASCII >> (yes, sometimes tables etc. need some tweaking), this is a pain. >> > > Yes, that's why I always recommend not to use that style. > > > (My markdown-to-RFC2629 workflow does some caching here, but life becomes >> painful again when interacting with XML-only co-authors.) >> >> BTW, if you are on a Mac, get one of the package managers "macports" or >> "homebrew", and do >> >> port install xml2rfc >> >> or >> >> brew install xml2rfc >> > > Interesting. Does this get you a current version, though? > > > Finally, don't run xml2rfc until you need to; to preview while editing, >>> just use the XSLT and open the XML file in a web browser. >>> >> >> Indeed -- thanks Julian for this wonderful tool. >> Get it from. >> Just put the line >> >> >> >> as the second line of the xml, and open the xml in a browser. >> (The only caveat I'm aware of is that you cannot really use the ugly >> vspace-999 hack for page break tweaks any more. Good riddance. Switch to >> the needLines PI. That one appears to be acting a bit strange in xml2rfc, >> though. It usually works for me with.) >> > > If you educate me what it's supposed to do (force a page break?), I can > look into adding it to the XSLT (it would only have an effect for print > preview, but I assume that would be ok?). > > Best regards, Julian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/ --0016e6d27671cecc1404989f3089 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My personal preference would be for Google docs to change their HTML genera= tor so that it preserves the structure of the layout (H1, H2 etc) rather th= an just the presentation.

That way we could have multiple peopl= e edit the same doc without having to swap files about in email.

As a document format, the XML2RFC format is terrible. I= t uses all the abominable features of SGML. Rather=A0disappointingly=A0for = a format intended for use by a standards organization it is different to HT= ML in ways that serve no purpose other than to prevent the use of widely av= ailable tools.


One improvement that we could realize wi= th little effort would be to simply replace the individual entity declarati= on files for the RFC references with one great big honking file containing = all of them. That way it would only be necessary to maintain citations in t= wo places rather than three as at present.

It would be much better if the references could be gene= rated automatically though.


On Thu, Dec 30, 2010 at 9:58 AM, Julian Reschke = <julian.reschke@gmx.de><= /span> wrote:
On 30.12.2010 10:50, Cars= ten Bormann wrote:
But while we're at the topic of *running* xml2rfc: I always advise peop= le to run it locally;

One problem is that the "default" way of doing references in RFC = 2629 XML appears to perform an online fetch of the reference information fo= r each build, with no caching whatsoever. =A0If you do have to look at the = ASCII (yes, sometimes tables etc. need some tweaking), this is a pain.

Yes, that's why I always recommend not to use that style.


(My markdown-to-RFC2629 workflow does some caching here, but life becomes p= ainful again when interacting with XML-only co-authors.)

BTW, if you are on a Mac, get one of the package managers "macports&qu= ot; or "homebrew", and do

=A0 =A0 =A0 =A0port install xml2rfc

or

=A0 =A0 =A0 =A0brew install xml2rfc

Interesting. Does this get you a current version, though?
=

Finally, don't run xml2rfc until you need to; to preview while editing,= just use the XSLT and open the XML file in a web browser.

Indeed -- thanks Julian for this wonderful tool.
Get it from<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>= .
Just put the line

=A0 <?xml-stylesheet type=3D'text/xsl' href=3D'rfc2629.xslt= ' ?>

as the second line of the xml, and open the xml in a browser.
(The only caveat I'm aware of is that you cannot really use the ugly vs= pace-999 hack for page break tweaks any more. =A0Good riddance. =A0Switch t= o the needLines PI. =A0That one appears to be acting a bit strange in xml2r= fc, though. =A0It usually works for me with<?rfc needLines=3D"30&qu= ot;?>.)

If you educate me what it's supposed to do (force a page break?), I can= look into adding it to the XSLT (it would only have an effect for print pr= eview, but I assume that would be ok?).

Best regards, Julian

_______________________________________________
Ietf mailing list
Ietf@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ietf



--
Website: http://hallambaker.com/

--0016e6d27671cecc1404989f3089-- From julian.reschke@gmx.de Thu Dec 30 03:55:27 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037FE3A67BD for ; Thu, 30 Dec 2010 03:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.567 X-Spam-Level: X-Spam-Status: No, score=-104.567 tagged_above=-999 required=5 tests=[AWL=-1.968, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvLfA2Iz4UHq for ; Thu, 30 Dec 2010 03:55:25 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 5C28F3A67A3 for ; Thu, 30 Dec 2010 03:55:24 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2010 11:57:29 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp023) with SMTP; 30 Dec 2010 12:57:29 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+XNgRhXAqXCkLtMb1QXMpreKpI3BsYAk1qILvtov eXByoSknrlcfVZ Message-ID: <4D1C73A4.8090207@gmx.de> Date: Thu, 30 Dec 2010 12:57:24 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker Subject: Re: spec gen tools, was: Automatically updated Table of Contents with Nroff References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> <4D1C44A9.7050401@gmx.de> <0C3E054B-EE3C-4F7B-A40B-5AAD3A3738E5@tzi.org> <4D1C57E0.9070705@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Carsten Bormann , IETF discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 11:55:27 -0000 On 30.12.2010 12:43, Phillip Hallam-Baker wrote: > My personal preference would be for Google docs to change their HTML > generator so that it preserves the structure of the layout (H1, H2 etc) > rather than just the presentation. > > That way we could have multiple people edit the same doc without having > to swap files about in email. And lose metadata, automatic checking of references, cross-references, etc. BTW: swapping files in email is indeed bad. It has nothing to do with format. Why don't you use a public source control repository? (svn on tools.ietf.org for WG stuff, or github...) > As a document format, the XML2RFC format is terrible. It uses all the > abominable features of SGML. Rather disappointingly for a format Sorry? Which? > intended for use by a standards organization it is different to HTML in > ways that serve no purpose other than to prevent the use of widely > available tools. It appears you're missing the benefits over HTML :-) > One improvement that we could realize with little effort would be to > simply replace the individual entity declaration files for the RFC > references with one great big honking file containing all of them. That > way it would only be necessary to maintain citations in two places > rather than three as at present. Could you elaborate where you need to maintain them? > It would be much better if the references could be generated > automatically though. Like just saying and then the reference being added at the end? It's certainly possible to write a tool for that. How do you decide whether the reference is Normative of Informative, though? Anyway, a benefit of an XML-based format is that you can invent any kind of extensions and write a simple-preprocessor implementing them. How do you do that with Google Docs? Best regards, Julian From rpelletier@isoc.org Thu Dec 30 04:13:33 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D783A676A for ; Thu, 30 Dec 2010 04:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxUHxPm9Difl for ; Thu, 30 Dec 2010 04:13:33 -0800 (PST) Received: from smtp187.iad.emailsrvr.com (smtp187.iad.emailsrvr.com [207.97.245.187]) by core3.amsl.com (Postfix) with ESMTP id 3FEF83A6768 for ; Thu, 30 Dec 2010 04:13:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp38.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id EE5D1348AB2; Thu, 30 Dec 2010 07:15:38 -0500 (EST) X-Virus-Scanned: OK Received: by smtp38.relay.iad1a.emailsrvr.com (Authenticated sender: rpelletier-AT-isoc.org) with ESMTPSA id C0B49348A18; Thu, 30 Dec 2010 07:15:38 -0500 (EST) Subject: Re: Question about Prague Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ray Pelletier In-Reply-To: Date: Thu, 30 Dec 2010 07:15:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5D41E230-D3BC-45BF-B228-AB28359954DE@isoc.org> References: To: Yoav Nir X-Mailer: Apple Mail (2.1082) Cc: "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 12:13:34 -0000 On Dec 30, 2010, at 4:38 AM, Yoav Nir wrote: > Hi >=20 > The Prague meeting is still nearly 3 months away, but I'm wondering = why there's only a date yet. >=20 > No hotel, no registration, no details.=20 >=20 > Some of us need to get the corporate wheels or authorization moving. Registration will open the beginning of next week with the usual hotel = details, etc. Ray >=20 > Thanks >=20 > Yoav >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From ynir@checkpoint.com Thu Dec 30 04:55:03 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D100F3A6778 for ; Thu, 30 Dec 2010 04:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.858 X-Spam-Level: X-Spam-Status: No, score=-9.858 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK5MxEEBiB+R for ; Thu, 30 Dec 2010 04:55:03 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 7E2B13A6768 for ; Thu, 30 Dec 2010 04:55:02 -0800 (PST) X-CheckPoint: {4D1C81A3-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBUCv6Ya007283; Thu, 30 Dec 2010 14:57:07 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 30 Dec 2010 14:57:06 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 30 Dec 2010 14:57:06 +0200 From: Yoav Nir To: Ray Pelletier Date: Thu, 30 Dec 2010 14:57:05 +0200 Subject: Re: Question about Prague Thread-Topic: Question about Prague Thread-Index: AcuoIQ+x30xx40h8Q8GyXMVILQzOww== Message-ID: References: <5D41E230-D3BC-45BF-B228-AB28359954DE@isoc.org> In-Reply-To: <5D41E230-D3BC-45BF-B228-AB28359954DE@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 12:55:04 -0000 Thanks On Dec 30, 2010, at 2:15 PM, Ray Pelletier wrote: >=20 > On Dec 30, 2010, at 4:38 AM, Yoav Nir wrote: >=20 >> Hi >>=20 >> The Prague meeting is still nearly 3 months away, but I'm wondering why = there's only a date yet. >>=20 >> No hotel, no registration, no details.=20 >>=20 >> Some of us need to get the corporate wheels or authorization moving. >=20 > Registration will open the beginning of next week with the usual hotel de= tails, etc. >=20 > Ray From cabo@tzi.org Thu Dec 30 07:01:22 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FF63A6812 for ; Thu, 30 Dec 2010 07:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.416 X-Spam-Level: X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KclJU5ni27la for ; Thu, 30 Dec 2010 07:01:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 028523A67FA for ; Thu, 30 Dec 2010 07:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oBUF3DKb004727; Thu, 30 Dec 2010 16:03:13 +0100 (CET) Received: from [192.168.217.101] (p5489BC61.dip.t-dialin.net [84.137.188.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 992A1DA9; Thu, 30 Dec 2010 16:03:13 +0100 (CET) Subject: Re: spec gen tools, was: Automatically updated Table of Contents with Nroff Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4D1C57E0.9070705@gmx.de> Date: Thu, 30 Dec 2010 16:03:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1917D10B-506E-4F40-9B18-6D95330DB9C1@tzi.org> References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> <4D1C44A9.7050401@gmx.de> <0C3E054B-EE3C-4F7B-A40B-5AAD3A3738E5@tzi.org> <4D1C57E0.9070705@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1082) Cc: IETF discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 15:01:22 -0000 > Yes, that's why I always recommend not to use that style. But hardwiring the references in the XML leads to manual updating (and = forgetting that). Having a tool for that is useful here (which is why kramdown-rfc2629 = does this). >> BTW, if you are on a Mac, get one of the package managers "macports" = or "homebrew", and do >>=20 >> port install xml2rfc >>=20 >> or >>=20 >> brew install xml2rfc >=20 > Interesting. Does this get you a current version, though? Both are at 1.35 -- not surprising since that version hasn't changed in = a while. One of the advantages of homebrew is that it makes editing the recipe = very simple, so in a pinch you don't have to wait for the maintainer to = update. And the really adventurous ones can always ask for the bleeding = edge direct from SVN: brew install xml2rfc --HEAD >>> Finally, don't run xml2rfc until you need to; to preview while = editing, just use the XSLT and open the XML file in a web browser. >>=20 >> Indeed -- thanks Julian for this wonderful tool. >> Get it from. >> Just put the line >>=20 >> >>=20 >> as the second line of the xml, and open the xml in a browser. >> (The only caveat I'm aware of is that you cannot really use the ugly = vspace-999 hack for page break tweaks any more. Good riddance. Switch = to the needLines PI. That one appears to be acting a bit strange in = xml2rfc, though. It usually works for me with.) >=20 > If you educate me what it's supposed to do (force a page break?), Sometimes, it is worthwhile to add tweaks to the source files to get a = page break. Method one: abuse the non-semantic element vspace, which eats excessive = blank lines when it causes a page break. =20 RFC 2629 2.3.1.7 actually recommends this:=20 "This allows authors to "force" a pagebreak by using an arbitrarily large value, e.g., "blankLines=3D'100'"." What rfc2629.xslt could do is recognize unreasonably*) large values and = do a page break instead of emitting tons of
elements. *) Some AI required. Maybe "more than 60". Method two: use the needLines PI, which is "documented" only in = http://xml.resource.org/authoring/README.html -- it is a hint how many = lines are needed to be able to continue on the current page (as opposed = to starting a new one). Those formatters producing continuous output = should of course ignore it, so rfc2629.xslt already does the right = thing. It's less clear what exactly a print stylesheet should do here, = as the concept of "lines" is not well-defined. Gruesse, Carsten From julian.reschke@gmx.de Thu Dec 30 07:08:56 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8717D3A681D for ; Thu, 30 Dec 2010 07:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.243 X-Spam-Level: X-Spam-Status: No, score=-104.243 tagged_above=-999 required=5 tests=[AWL=-2.244, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scOnrCVrUz4h for ; Thu, 30 Dec 2010 07:08:55 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 984083A6818 for ; Thu, 30 Dec 2010 07:08:53 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2010 15:10:58 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp025) with SMTP; 30 Dec 2010 16:10:58 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1955LJ8SXZ50EX6LQjdGS+kK1PROYZdahuTNRHQVp NCztiopjrdubPB Message-ID: <4D1CA0FC.30908@gmx.de> Date: Thu, 30 Dec 2010 16:10:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Carsten Bormann Subject: Re: spec gen tools, was: Automatically updated Table of Contents with Nroff References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> <4D1C44A9.7050401@gmx.de> <0C3E054B-EE3C-4F7B-A40B-5AAD3A3738E5@tzi.org> <4D1C57E0.9070705@gmx.de> <1917D10B-506E-4F40-9B18-6D95330DB9C1@tzi.org> In-Reply-To: <1917D10B-506E-4F40-9B18-6D95330DB9C1@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 15:08:56 -0000 On 30.12.2010 16:03, Carsten Bormann wrote: >> Yes, that's why I always recommend not to use that style. > > But hardwiring the references in the XML leads to manual updating (and forgetting that). > Having a tool for that is useful here (which is why kramdown-rfc2629 does this). I dislike automatic updates for IDs, because I may miss something that's important (such as a Section number of ABNF term changing). Thus I prefer running a checker for up-to-date references. For RFCs, the citations should be immutable anyway. > ... >> If you educate me what it's supposed to do (force a page break?), > > Sometimes, it is worthwhile to add tweaks to the source files to get a page break. > > Method one: abuse the non-semantic element vspace, which eats excessive blank lines when it causes a page break. > RFC 2629 2.3.1.7 actually recommends this: > "This > allows authors to "force" a pagebreak by using an arbitrarily large > value, e.g., "blankLines='100'"." > > What rfc2629.xslt could do is recognize unreasonably*) large values and do a page break instead of emitting tons of
elements. > *) Some AI required. Maybe "more than 60". I'm in the process of adding this; although I'm not going to generate a page break (it's likely to be a micro-optimization for the text output, right?). Instead, I'll treat these elements as a request for a single line break, so that the HTML output doesn't get messed up. > Method two: use the needLines PI, which is "documented" only in http://xml.resource.org/authoring/README.html -- it is a hint how many lines are needed to be able to continue on the current page (as opposed to starting a new one). Those formatters producing continuous output should of course ignore it, so rfc2629.xslt already does the right thing. It's less clear what exactly a print stylesheet should do here, as the concept of "lines" is not well-defined. Indeed. rfc2629.xslt *could* try to add CSS hints, but it's not really clear how this is going to help. After all, the generated HTML+CSS already contains the necessary data to keep things together that belong together (you can test that with the PrinceXML formatter). Best regards, Julian From fanf2@hermes.cam.ac.uk Thu Dec 30 12:24:06 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28673A6835 for ; Thu, 30 Dec 2010 12:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUJq+4WW8kvP for ; Thu, 30 Dec 2010 12:24:05 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id CF4663A6827 for ; Thu, 30 Dec 2010 12:24:03 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from [87.115.32.204] (port=52118 helo=[192.168.0.4]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1PYP4Z-00023n-Sn (Exim 4.72) (return-path ); Thu, 30 Dec 2010 20:26:08 +0000 References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> <4D1C44A9.7050401@gmx.de> <0C3E054B-EE3C-4F7B-A40B-5AAD3A3738E5@tzi.org> <4D1C57E0.9070705@gmx.de> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: Tony Finch Subject: Re: spec gen tools, was: Automatically updated Table of Contents with Nroff Date: Thu, 30 Dec 2010 20:25:55 +0000 To: Phillip Hallam-Baker Sender: Tony Finch Cc: Julian Reschke , Carsten Bormann , IETF discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 20:24:06 -0000 On 30 Dec 2010, at 11:43, Phillip Hallam-Baker wrote: >=20 > As a document format, the XML2RFC format is terrible. It uses all the abom= inable features of SGML. Rather disappointingly for a format intended for us= e by a standards organization it is different to HTML in ways that serve no p= urpose other than to prevent the use of widely available tools. Two key features that xml2rfc provides that HTML does not are automatic tabl= es of contents and expansion of references from a central bibliography. You s= eem to think the latter is at least worth keeping and improving. > One improvement that we could realize with little effort would be to simpl= y replace the individual entity declaration files for the RFC references wit= h one great big honking file containing all of them. That way it would only b= e necessary to maintain citations in two places rather than three as at pres= ent. >=20 > It would be much better if the references could be generated automatically= though. Tony. -- f.anthony.n.finch http://dotat.at/= From julian.reschke@gmx.de Thu Dec 30 12:33:04 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576733A6827 for ; Thu, 30 Dec 2010 12:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.51 X-Spam-Level: X-Spam-Status: No, score=-104.51 tagged_above=-999 required=5 tests=[AWL=-1.911, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AplP2oecehEA for ; Thu, 30 Dec 2010 12:33:03 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id DBD393A6825 for ; Thu, 30 Dec 2010 12:33:02 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2010 20:35:05 -0000 Received: from p508FA007.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.160.7] by mail.gmx.net (mp023) with SMTP; 30 Dec 2010 21:35:05 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18TZKtx7I8ToBj07NjcaoJNlprn9dMlOqIV24P+Os lTR+DzNZdbllM+ Message-ID: <4D1CECF0.1090404@gmx.de> Date: Thu, 30 Dec 2010 21:34:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tony Finch Subject: Re: spec gen tools, was: Automatically updated Table of Contents with Nroff References: <201012300225.oBU2P9cW026987@fs4113.wdf.sap.corp> <4D1C44A9.7050401@gmx.de> <0C3E054B-EE3C-4F7B-A40B-5AAD3A3738E5@tzi.org> <4D1C57E0.9070705@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Carsten Bormann , Phillip Hallam-Baker , IETF discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 20:33:04 -0000 On 30.12.2010 21:25, Tony Finch wrote: > On 30 Dec 2010, at 11:43, Phillip Hallam-Baker wrote: >> >> As a document format, the XML2RFC format is terrible. It uses all the abominable features of SGML. Rather disappointingly for a format intended for use by a standards organization it is different to HTML in ways that serve no purpose other than to prevent the use of widely available tools. > > Two key features that xml2rfc provides that HTML does not are automatic tables of contents and expansion of references from a central bibliography. You seem to think the latter is at least worth keeping and improving. > ... - (checked) cross-references - index generation - boilerplate generation ... Best regards, Julian From uyeshiro@ifa.hawaii.edu Thu Dec 30 13:07:09 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0693A684C for ; Thu, 30 Dec 2010 13:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 763lGeSzVjBT for ; Thu, 30 Dec 2010 13:07:08 -0800 (PST) Received: from hale.ifa.hawaii.edu (hale.ifa.hawaii.edu [128.171.2.6]) by core3.amsl.com (Postfix) with ESMTP id 744E93A6846 for ; Thu, 30 Dec 2010 13:07:08 -0800 (PST) Received: from XeonAL (xeonal [128.171.163.193]) by hale.ifa.hawaii.edu (8.13.8/8.13.8) with ESMTP id oBUL8cb3009722; Thu, 30 Dec 2010 11:08:53 -1000 (HST) From: "Robin Uyeshiro" To: "'Yoav Nir'" , "'Ray Pelletier'" Subject: RE: Question about Prague Date: Thu, 30 Dec 2010 11:09:36 -1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6863 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: Importance: Normal Thread-Index: AcuoIQ+x30xx40h8Q8GyXMVILQzOwwAQYgeA Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 21:07:09 -0000 Some brief notes on Prague from a visit there 2 years ago in October: The GPS in the rental car (rented in Munich) did not have the street information for Prague. Freeway signs announced neighborhoods, not = streets, so driving was confusing. Freeway construction further confused things, = so have alternative routes. Or head for the City Center and navigate from there. Don't be in a rush, and don't arrive at night if driving. The last freeway rest stop in Germany on the way to Prague is = interesting. Hotel recommendation: Hotel General. This is within walking distance of = the Bridge, the River, and a major brewery. Don't be fooled by the look of = the neighborhood. Also, don't bring a wide car. Once there, the drive will have been worth the effort. Also, breakfast is excellent! The beer in Prague is excellent and cheap. It's not your father's Budweiser. The beer in Munich was excellent, but relatively expensive. = Prague itself is a beautiful, if dark, city. Check out the Czech glass = ;) -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = Yoav Nir Sent: Thursday, December 30, 2010 2:57 AM To: Ray Pelletier Cc: ietf@ietf.org Subject: Re: Question about Prague Thanks On Dec 30, 2010, at 2:15 PM, Ray Pelletier wrote: >=20 > On Dec 30, 2010, at 4:38 AM, Yoav Nir wrote: >=20 >> Hi >>=20 >> The Prague meeting is still nearly 3 months away, but I'm wondering = why there's only a date yet. >>=20 >> No hotel, no registration, no details.=20 >>=20 >> Some of us need to get the corporate wheels or authorization moving. >=20 > Registration will open the beginning of next week with the usual hotel details, etc. >=20 > Ray _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From chelliot@gmail.com Thu Dec 30 15:48:22 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BCE73A686C for ; Thu, 30 Dec 2010 15:48:22 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSzke3o2Q7IA for ; Thu, 30 Dec 2010 15:48:21 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 717593A686B for ; Thu, 30 Dec 2010 15:48:21 -0800 (PST) Received: by yxt33 with SMTP id 33so5148998yxt.31 for ; Thu, 30 Dec 2010 15:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=jcMu6narmD2tfkE7o40Dwbnvlkt9u0S7y8jVT3y9yOg=; b=m0B4AJegpMN+U9f2owdjXyC+DvCnZpVuaxI/YY6GhGKPzXNibMzL1bsErtC3CoAlpl C8Qe8MclnJ5Uy9cpzNySwxaPWL3FYuugz7OiMokVfvLtR4tRu8vg0p134xcIMyNKXZbL 3MtRo6Re8xRulqUWAD+G00iFGLAje410cT+1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; b=Zx8Nn9ZSlWk+V/IojntsYX5xj0t2vN4gO1ywZC9WiBhH5BaBwmaXSexHwVwUden2Xn CeAmRz8AyAuNm25cQj7Seadt2EOycF+AklpV/ZDssvfN6BEW3rwzdt4LtxQsgsS5OX6n A63aC9SE2GxVIXwFeM4Wl8dXNPFYCNh8MhKBE= Received: by 10.100.249.13 with SMTP id w13mr9455040anh.233.1293753026340; Thu, 30 Dec 2010 15:50:26 -0800 (PST) Received: from [10.0.234.243] ([166.137.10.84]) by mx.google.com with ESMTPS id c7sm22652274ana.37.2010.12.30.15.50.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Dec 2010 15:50:24 -0800 (PST) Sender: Chris Elliott References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Chris Elliott Subject: Re: WiFI and authentication Date: Thu, 30 Dec 2010 18:50:14 -0500 To: Lawrence Conroy Cc: The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 23:48:22 -0000 Lawrence, The authentication on wireless in Maastricht was in preparation for Beijing,= where we had an agreement to ensure the wireless users were IETF attendees.= =20 I know of no reason to continue the authentication and I know of no intentio= ns of doing so for any currently scheduled meeting. I think we would only ha= ve this as a requirement for the network if we go back to China proper (i.e.= not Taiwan or Hong Kong) again. Chris. -- Chris Elliott On Dec 29, 2010, at 12:22 PM, Lawrence Conroy wrot= e: > Hi Folks, > whilst everyone is on the topic of WiFi ... > Now that the meeting in the PRC is over, is there any > intention to continue the WiFi authentication shenanigans? > [802.1X stuff, entering the magic number on your badge, ...] >=20 > That seemed to be another added complexity @ Maastricht, so > I'd prefer this to disappear. >=20 > If this business IS to be continued, why? >=20 > all the best, > Lawrence >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From narten@us.ibm.com Thu Dec 30 21:50:59 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20B528B56A for ; Thu, 30 Dec 2010 21:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.927 X-Spam-Level: X-Spam-Status: No, score=-105.927 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrVr6SiXxAiQ for ; Thu, 30 Dec 2010 21:50:57 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 88F6D3A6831 for ; Thu, 30 Dec 2010 21:50:57 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oBV5aIXa016771 for ; Fri, 31 Dec 2010 00:36:18 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id D78A54DE803B for ; Fri, 31 Dec 2010 00:50:24 -0500 (EST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oBV5r2qY193138 for ; Fri, 31 Dec 2010 00:53:02 -0500 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oBV5r2Xg012763 for ; Thu, 30 Dec 2010 22:53:02 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oBV5r1Yo012750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Dec 2010 22:53:02 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id oBV5r2kf014834 for ; Fri, 31 Dec 2010 00:53:02 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.4/8.14.4/Submit) id oBV5r14v014818 for ietf@ietf.org; Fri, 31 Dec 2010 00:53:01 -0500 From: Thomas Narten Message-Id: <201012310553.oBV5r14v014818@rotala.raleigh.ibm.com> Date: Fri, 31 Dec 2010 00:53:01 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 05:51:00 -0000 Total of 38 messages in the last 7 days. script run at: Fri Dec 31 00:53:01 EST 2010 Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.79% | 6 | 11.68% | 31928 | julian.reschke@gmx.de 10.53% | 4 | 7.80% | 21304 | mrex@sap.com 2.63% | 1 | 13.06% | 35684 | mohamed.boucadair@orange-ftgroup.com 5.26% | 2 | 7.75% | 21186 | hallam@gmail.com 5.26% | 2 | 5.23% | 14301 | chelliot@pobox.com 5.26% | 2 | 4.44% | 12124 | cabo@tzi.org 5.26% | 2 | 3.42% | 9337 | ynir@checkpoint.com 2.63% | 1 | 5.90% | 16132 | jari.arkko@piuha.net 2.63% | 1 | 5.65% | 15437 | ron.even.tlv@gmail.com 2.63% | 1 | 4.54% | 12395 | fu@cs.uni-goettingen.de 2.63% | 1 | 2.47% | 6756 | joelja@bogus.com 2.63% | 1 | 2.41% | 6591 | fluffy@cisco.com 2.63% | 1 | 2.40% | 6545 | narten@us.ibm.com 2.63% | 1 | 2.27% | 6203 | ole@cisco.com 2.63% | 1 | 2.18% | 5944 | hgs@cs.columbia.edu 2.63% | 1 | 2.07% | 5647 | rbarnes@bbn.com 2.63% | 1 | 1.96% | 5364 | uyeshiro@ifa.hawaii.edu 2.63% | 1 | 1.91% | 5230 | randy_presuhn@mindspring.com 2.63% | 1 | 1.87% | 5107 | dot@dotat.at 2.63% | 1 | 1.75% | 4778 | dwm@xpasc.com 2.63% | 1 | 1.68% | 4591 | fred@cisco.com 2.63% | 1 | 1.61% | 4392 | doug@ewellic.org 2.63% | 1 | 1.55% | 4235 | rpelletier@isoc.org 2.63% | 1 | 1.54% | 4202 | tme@americafree.tv 2.63% | 1 | 1.51% | 4136 | dhc2@dcrocker.net 2.63% | 1 | 1.35% | 3698 | lconroy@insensate.co.uk --------+------+--------+----------+------------------------ 100.00% | 38 |100.00% | 273247 | Total From evnikita2@gmail.com Thu Dec 30 22:10:13 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136283A68C5; Thu, 30 Dec 2010 22:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0D1FJelQIks; Thu, 30 Dec 2010 22:10:12 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6758A3A68CC; Thu, 30 Dec 2010 22:10:11 -0800 (PST) Received: by bwz12 with SMTP id 12so11818157bwz.31 for ; Thu, 30 Dec 2010 22:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type; bh=a8nDWlnxDT3gokduvSSO5c/mS9H6ciJhjvL7Qdwk2R0=; b=H9USPHq3oUtwn7lwdbGCAx//1ImIAkZoKgiO/UQnr93DmpiffaJtAbwv94J+a+6g/L eISNeS77MSGE7JEznSzKbJRBznHWKj3IUd6U2gRb9539amLThlCoAQ2zRYY8du7ETD4f Iffpw7TFixM893oXII80WxeQXwSLkKhSo+QVI= 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; b=f9xU4QZxQsMf2w3CdrK4x2gPHY4U5pxaNTUSPSOb2uxZ7Eg2nLkj1crgvevE9tjQTY DNKWXnUowk1zceoTp1ZBg2+7PAc+Murf4G0Rlio50nQyw145r7iT4LmR33iLVxf3yWg+ 9dYRMcig6FDUgwFdxssd35JfdDn9g24eDcQRk= Received: by 10.204.60.76 with SMTP id o12mr7463791bkh.3.1293775934939; Thu, 30 Dec 2010 22:12:14 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v1sm9600752bkt.5.2010.12.30.22.12.13 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Dec 2010 22:12:14 -0800 (PST) Message-ID: <4D1D744D.9010709@gmail.com> Date: Fri, 31 Dec 2010 08:12:29 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF Discussion , httpbis Group , ietf-message-headers@ietf.org Subject: First part of LC for draft-yevstifeyev-http-headers-not-recognized summary Content-Type: multipart/alternative; boundary="------------040108080200050301090706" Cc: Alexey Melnikov , iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 06:10:13 -0000 This is a multi-part message in MIME format. --------------040108080200050301090706 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, This message summarizes the first part of Last Call for draft-yevstifeyev-http-headers-not-recognized. The LC for this draft was requested on 11 December, and it entered it on 13 December. The LC period of 1 month has been appointed for this document. The LC discussions occurred on httpbis WG mailing list and IETF Discussion. Taking these discussions into consideration, 2 new versions of the draft has been uploaded during the first part of LC. The -09 one added the digitalized 'Model of Work' section that described the usage and behavior if senders, receivers of and middle-boxes transferring messages with 'H-N-R' header field. Also some typographical errors were corrected. The -10 version reflected almost all major LC comments. Among other: * replaced 'header' with 'header field' in all instances; * elaboration of model of work; * other typographical errors. The diffs of initial version -08 to -10 are available here: https://tools.ietf.org/rfcdiff?url1=draft-yevstifeyev-http-headers-not-recognized-10&difftype=--html&submit=Go!&url2=draft-yevstifeyev-http-headers-not-recognized-08 LC will last for 2 weeks more. I'll submit the updated version of the draft near the 10 December and inform you. Any suggestions are still welcome. Happy New Year to everybody! All the best, Mykyta Yevstifeyev P.S. Apologizing if you receive multiple copies of the message. Mykyta. --------------040108080200050301090706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello all,

This message summarizes the first part of Last Call for draft-yevstifeyev-http-headers-not-recognized.

The LC for this draft was requested on 11 December, and it entered it on 13 December. The LC period of 1 month has been appointed for this document. The LC discussions occurred on httpbis WG mailing list and IETF Discussion. Taking these discussions into consideration, 2 new versions of the draft has been uploaded during the first part of LC.

The -09 one added the digitalized 'Model of Work' section that described the usage and behavior if senders, receivers of and middle-boxes transferring messages with 'H-N-R' header field. Also some typographical errors were corrected.

The -10 version reflected almost all major LC comments. Among other:
  • replaced 'header' with 'header field' in all instances;
  • elaboration of model of work;
  • other typographical errors.
The diffs of initial version -08 to -10 are available here:

https://tools.ietf.org/rfcdiff?url1=draft-yevstifeyev-http-headers-not-recognized-10&difftype=--html&submit=Go!&url2=draft-yevstifeyev-http-headers-not-recognized-08

LC will last for 2 weeks more. I'll submit the updated version of the draft near the 10 December and inform you. Any suggestions are still welcome.

Happy New Year to everybody!

All the best,
Mykyta Yevstifeyev

P.S. Apologizing if you receive multiple copies of the message. Mykyta.


 --------------040108080200050301090706-- From fred@cisco.com Thu Dec 30 22:39:03 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F073A68C5 for ; Thu, 30 Dec 2010 22:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTGZI0lor1p2 for ; Thu, 30 Dec 2010 22:39:02 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4D41C3A6845 for ; Thu, 30 Dec 2010 22:39:02 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMJHU2rR7Hu/2dsb2JhbACkPnOlNZoAgn2CTQSEZYYfizI X-IronPort-AV: E=Sophos;i="4.60,253,1291593600"; d="scan'208";a="643378443" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 31 Dec 2010 06:41:08 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oBV6f7F5016746; Fri, 31 Dec 2010 06:41:08 GMT Subject: Re: Question about Prague Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 30 Dec 2010 22:41:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8D7FD970-B4E1-41B1-8E50-69406AE54FD9@cisco.com> References: To: Robin Uyeshiro X-Mailer: Apple Mail (2.1082) Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 06:39:04 -0000 On Dec 30, 2010, at 1:09 PM, Robin Uyeshiro wrote: > The GPS in the rental car (rented in Munich) did not have the street > information for Prague. It's not unusual, or at least it wasn't in 1997, for German rental = agencies to not permit driving to the Czech Republic. As stated, my = information is dated. The point is - check your contract. From tobias.gondrom@gondrom.org Fri Dec 31 02:15:05 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6D728C0EB for ; Fri, 31 Dec 2010 02:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.966 X-Spam-Level: X-Spam-Status: No, score=-93.966 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgwQ0mH54k6c for ; Fri, 31 Dec 2010 02:15:04 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 0383828B23E for ; Fri, 31 Dec 2010 02:15:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=oiRDA7owUakSNKdKoIRyJqt9XWm7xl/hwvgnqmnlW8f5GQFd/N5HcuzKWff2V4VWzQAMF2yQsH+P455kliCFdaVJd9F0rs4OANxn/xQVB0R1hq+Xu5wS8d9+VlC4izGe; h=Received:Received:References:In-Reply-To:Mime-Version:Content-Type:Message-Id:Content-Transfer-Encoding:Cc:X-Mailer:From:Subject:Date:To; Received: (qmail 32398 invoked from network); 31 Dec 2010 11:17:07 +0100 Received: from host86-140-250-255.range86-140.btcentralplus.com (HELO ?192.168.1.84?) (86.140.250.255) by lvps83-169-7-107.dedicated.hosteurope.de with (AES128-SHA encrypted) SMTP; 31 Dec 2010 11:17:07 +0100 References: <8D7FD970-B4E1-41B1-8E50-69406AE54FD9@cisco.com> In-Reply-To: <8D7FD970-B4E1-41B1-8E50-69406AE54FD9@cisco.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <05AECACA-06B1-48C2-B015-7D79307BF38C@gondrom.org> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148) From: Tobias Gondrom Subject: Re: Question about Prague Date: Fri, 31 Dec 2010 10:17:05 +0000 To: Fred Baker Cc: Robin Uyeshiro , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 10:15:05 -0000 Although Prague (Czech Republic) and Munich (Germany) are both in the Europe= an Union they are different countries. So when renting a car in Munich you n= eed to make sure (as usual) that you are allowed to take it across the borde= r and that the GPS has the maps of the country you travel to.=20 Btw. Prague has an airport, too. Though don't know frequency of flights and a= drive from Munich is only a couple of hours. Cu in Prague, Tobias On 31 Dec 2010, at 06:41, Fred Baker wrote: >=20 > On Dec 30, 2010, at 1:09 PM, Robin Uyeshiro wrote: >> The GPS in the rental car (rented in Munich) did not have the street >> information for Prague. >=20 > It's not unusual, or at least it wasn't in 1997, for German rental agencie= s to not permit driving to the Czech Republic. As stated, my information is d= ated. The point is - check your contract. >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From dhc2@dcrocker.net Fri Dec 31 06:54:55 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5BCE3A6934 for ; Fri, 31 Dec 2010 06:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlmyNt8QmV2a for ; Fri, 31 Dec 2010 06:54:53 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 0A7DA3A6928 for ; Fri, 31 Dec 2010 06:54:53 -0800 (PST) Received: from [192.168.42.82] (m352736d0.tmodns.net [208.54.39.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBVEuoLB015692 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 31 Dec 2010 06:56:58 -0800 Message-ID: <4D1DEF2E.2070506@dcrocker.net> Date: Fri, 31 Dec 2010 06:56:46 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF Discussion Subject: New Year's Exploration: Changing the Internet's Infrastructure Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 31 Dec 2010 06:56:59 -0800 (PST) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 14:54:55 -0000 Folks, Feliz Aņo Nuevo! One of the lessons of efforts such as IPv6 and DNSSEC should be that making changes to the global infrastructure of the Internet is extremely difficult. The technical details are difficult -- especially if the change seeks to work with an existing base of functionality -- and the administration and operation details are difficult. And the time it takes to achieve critical mass is quite long. However we continue to hear claims and see design efforts that are based on the view that changing the infrastructure is easier than changing end-systems.[1] The fact that the infrastructure is controlled by far fewer actors and organizations makes it natural to assume that this preference is well-founded and correct. But does the Internet's track record substantiate this view? So I would like to ask for folks to help the community develop some concrete information about this, by adding entries and comments to the IETF's Outcomes Wiki: [2] If there is a piece of work that was targeting change to the infrastructure or the creation of new infrastructure, please add an entry for it to the wiki. This will provide an explicit statement about the history and degree of success of that effort. Congestion control, mobility, multipath, multicasting, new transport, MIME, etc. Anything that enables higher-level capabilities. Some infrastructure changes are designed for the router level of things and some are designed for host-level. But they provide underlying services that can then be used for better performance, reliability, or control or to make new applications viable. My expectation is that we are going to find that such efforts are difficult, no matter where they are put, but I suspect we will find that the ones destined for the router level of things are the hardest. Prove me wrong by adding entries to the Outcomes wiki that show otherwise... Or prove me correct. Having clarity about this topic could make for a pretty good start of the new year... d/ [1] Serious pursuit of this topic requires some agreement about the definition of "infrastructure" and quite possibly agreement on "end-system". For now, let's just say that infrastructure is anything that provides services to a layer above. That makes TCP a kind of infrastructure service. But, then, the environment for controlling it is quite different, since it sits in hosts, not routers. So perhaps we need some additional constructs for the "venue" of infrastructure service?. [2] We might discover that it will help to add a column to the wiki's tables. That's fine to explore on the wiki's mailing list: Given footnote [1], an example of a change might be a column that notes where the service resides in terms of Internet architecture. Granularity that distinguishes more than just host-vs-router might be helpful, since the Internet's range of "tussle" boundaries has grown more complex, given the operational reality of PCs, servers, organizational nets, local ISPs and transit nets... In the absence of agreements to make changes, use the Comments column in the wiki, for recording information that might warrant a new column in the table. -- Dave Crocker Brandenburg InternetWorking bbiw.net From mohta@necom830.hpcl.titech.ac.jp Fri Dec 31 07:11:59 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE023A6812 for ; Fri, 31 Dec 2010 07:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb1JPvj2YtfJ for ; Fri, 31 Dec 2010 07:11:58 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 17FF43A6811 for ; Fri, 31 Dec 2010 07:11:57 -0800 (PST) Received: (qmail 32280 invoked from network); 31 Dec 2010 16:01:00 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 31 Dec 2010 16:01:00 -0000 Message-ID: <4D1DF325.5090808@necom830.hpcl.titech.ac.jp> Date: Sat, 01 Jan 2011 00:13:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: New Year's Exploration: Changing *NOT* the Internet's Infrastructure References: <4D1DEF2E.2070506@dcrocker.net> In-Reply-To: <4D1DEF2E.2070506@dcrocker.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 15:11:59 -0000 Dave CROCKER wrote: > However we continue to hear claims and see design efforts that are based > on the view that changing the infrastructure is easier than changing > end-systems.[1] Wrong. The fact that the major application on the Internet easily and smoothly changed from FTP to HTTP is the counter proof. It is a proven fact that upgrading end systems is trivially easy. Note also that IPv6 and DNSSEC require to *CHANGE* *BOTH* of the infrastructure and the end-systems and that many, if not most, end systems are IPv6 capable. Masataka Ohta From rbarnes@bbn.com Fri Dec 31 09:36:35 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8A33A681A for ; Fri, 31 Dec 2010 09:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdIo56jH9fPR for ; Fri, 31 Dec 2010 09:36:34 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E553A3A67C2 for ; Fri, 31 Dec 2010 09:36:33 -0800 (PST) Received: from [128.89.253.97] (port=50016 helo=[10.0.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PYiw3-000ByI-Gm; Fri, 31 Dec 2010 12:38:39 -0500 Subject: Re: New Year's Exploration: Changing the Internet's Infrastructure Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: "Richard L. Barnes" In-Reply-To: <4D1DEF2E.2070506@dcrocker.net> Date: Fri, 31 Dec 2010 12:38:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D1DEF2E.2070506@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) Cc: IETF Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 17:36:35 -0000 Hey Dave, I admire your desire for "clarity" on this subject, but fear you will be = disappointed. ISTM that the success of changes to the infrastructure depends on the = value those changes deliver to participants in the Internet economy -- = i.e., the pain of the problem they solve. Your two examples are = actually very appropriate here: IPv6 and DNSSEC both moved very slowly = until (1) people started to not have enough numbers to grow their = networks, and (2) Dan Kaminsky put the fear of God in people. So the question is rather how many problems there are in the current = infrastructure that cause people enough pain to do something. I think = there are at least a couple (improving BGP security, for example), and = the number will probably slowly shrink over time, but in the long run, I = expect there will ultimately always be a few big things that need to be = done that can't be done in end systems. --Richard=20 On Dec 31, 2010, at 9:56 AM, Dave CROCKER wrote: > Folks, >=20 > Feliz A=F1o Nuevo! >=20 > One of the lessons of efforts such as IPv6 and DNSSEC should be that = making changes to the global infrastructure of the Internet is extremely = difficult. The technical details are difficult -- especially if the = change seeks to work with an existing base of functionality -- and the = administration and operation details are difficult. And the time it = takes to achieve critical mass is quite long. >=20 > However we continue to hear claims and see design efforts that are = based on the view that changing the infrastructure is easier than = changing end-systems.[1] The fact that the infrastructure is controlled = by far fewer actors and organizations makes it natural to assume that = this preference is well-founded and correct. >=20 > But does the Internet's track record substantiate this view? >=20 > So I would like to ask for folks to help the community develop some = concrete information about this, by adding entries and comments to the = IETF's Outcomes Wiki: >=20 > [2] >=20 > If there is a piece of work that was targeting change to the = infrastructure or the creation of new infrastructure, please add an = entry for it to the wiki. This will provide an explicit statement about = the history and degree of success of that effort. >=20 > Congestion control, mobility, multipath, multicasting, new transport, = MIME, etc. Anything that enables higher-level capabilities. >=20 > Some infrastructure changes are designed for the router level of = things and some are designed for host-level. But they provide = underlying services that can then be used for better performance, = reliability, or control or to make new applications viable. >=20 > My expectation is that we are going to find that such efforts are = difficult, no matter where they are put, but I suspect we will find that = the ones destined for the router level of things are the hardest. >=20 > Prove me wrong by adding entries to the Outcomes wiki that show = otherwise... >=20 > Or prove me correct. >=20 > Having clarity about this topic could make for a pretty good start of = the new year... >=20 >=20 > d/ >=20 >=20 > [1] Serious pursuit of this topic requires some agreement about the = definition of "infrastructure" and quite possibly agreement on = "end-system". For now, let's just say that infrastructure is anything = that provides services to a layer above. That makes TCP a kind of = infrastructure service. But, then, the environment for controlling it = is quite different, since it sits in hosts, not routers. So perhaps we = need some additional constructs for the "venue" of infrastructure = service?. >=20 >=20 > [2] We might discover that it will help to add a column to the wiki's = tables. That's fine to explore on the wiki's mailing list: >=20 > >=20 > Given footnote [1], an example of a change might be a column that = notes where the service resides in terms of Internet architecture. = Granularity that distinguishes more than just host-vs-router might be = helpful, since the Internet's range of "tussle" boundaries has grown = more complex, given the operational reality of PCs, servers, = organizational nets, local ISPs and transit nets... >=20 > In the absence of agreements to make changes, use the Comments column = in the wiki, for recording information that might warrant a new column = in the table. >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From tme@americafree.tv Fri Dec 31 09:50:31 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3257B3A6855 for ; Fri, 31 Dec 2010 09:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBg0YC3ggwD7 for ; Fri, 31 Dec 2010 09:50:30 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 4A87C3A684D for ; Fri, 31 Dec 2010 09:50:30 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 1AA8D98B448A; Fri, 31 Dec 2010 12:52:36 -0500 (EST) Subject: Re: Question about Prague Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks X-Priority: 3 (Normal) In-Reply-To: <8D7FD970-B4E1-41B1-8E50-69406AE54FD9@cisco.com> Date: Fri, 31 Dec 2010 12:52:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <70FF1D95-D56C-4F16-8FE6-3E80D914AD36@americafree.tv> References: <8D7FD970-B4E1-41B1-8E50-69406AE54FD9@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1081) Cc: Robin Uyeshiro , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 17:50:31 -0000 On Dec 31, 2010, at 1:41 AM, Fred Baker wrote: >=20 > On Dec 30, 2010, at 1:09 PM, Robin Uyeshiro wrote: >> The GPS in the rental car (rented in Munich) did not have the street >> information for Prague. >=20 > It's not unusual, or at least it wasn't in 1997, for German rental = agencies to not permit driving to the Czech Republic. As stated, my = information is dated. The point is - check your contract. >=20 Before the Czech lands entered the EU (2004) that was very common, and = very strict. (In 1999 I was almost arrested for trying to drive my Hertz = car to the duty-free shop at the border crossing in Linz, Austria - by = the Austrians! - because my rental contract didn't allow for the Czech = Republic.) Now, you should tell your rental agency where you are going, = but the last time I rented a car and drove to Prague, we didn't have any = issues at all. There shouldn't even be a border post any more (since = December 2007, the Czech Republic has been part of the Schengen area). Regards Marshall=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From elwynd@dial.pipex.com Fri Dec 31 10:34:33 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70973A6941 for ; Fri, 31 Dec 2010 10:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVp0CWzE3VG0 for ; Fri, 31 Dec 2010 10:34:32 -0800 (PST) Received: from b.painless.aaisp.net.uk (b.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by core3.amsl.com (Postfix) with ESMTP id 930703A6874 for ; Fri, 31 Dec 2010 10:34:31 -0800 (PST) Received: from 250.254.187.81.in-addr.arpa ([81.187.254.250]) by b.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PYjq3-00036J-Tg; Fri, 31 Dec 2010 18:36:32 +0000 Subject: Re: Question about Prague From: Elwyn Davies To: Marshall Eubanks In-Reply-To: <70FF1D95-D56C-4F16-8FE6-3E80D914AD36@americafree.tv> References: <8D7FD970-B4E1-41B1-8E50-69406AE54FD9@cisco.com> <70FF1D95-D56C-4F16-8FE6-3E80D914AD36@americafree.tv> Content-Type: text/plain Date: Fri, 31 Dec 2010 18:37:36 +0000 Message-Id: <1293820656.17554.6074.camel@mightyatom.folly.org.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: Robin Uyeshiro , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 18:34:33 -0000 On Fri, 2010-12-31 at 12:52 -0500, Marshall Eubanks wrote: > On Dec 31, 2010, at 1:41 AM, Fred Baker wrote: > > > > > On Dec 30, 2010, at 1:09 PM, Robin Uyeshiro wrote: > >> The GPS in the rental car (rented in Munich) did not have the street > >> information for Prague. > > > > It's not unusual, or at least it wasn't in 1997, for German rental agencies to not permit driving to the Czech Republic. As stated, my information is dated. The point is - check your contract. > > > > Before the Czech lands entered the EU (2004) that was very common, and very strict. (In 1999 I was almost arrested for trying to drive my Hertz car to the duty-free shop at the border crossing in Linz, Austria - by the Austrians! - because my rental contract didn't allow for the Czech Republic.) Now, you should tell your rental agency where you are going, but the last time I rented a car and drove to Prague, we didn't have any issues at all. There shouldn't even be a border post any more (since December 2007, the Czech Republic has been part of the Schengen area). > > Regards > Marshall Driving into the Czech Republic shouldn't be a problem BUT you do have to tell the rental agency in advance and they will make a supplementary charge per day for the whole contract (not just the days you are out of Germany) if my recent experience is anything to go by (hire in Austria, drive to Slovenia). Its not particularly cheap either. Regards, Elwyn > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From john@jlc.net Fri Dec 31 10:36:38 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECB43A682E for ; Fri, 31 Dec 2010 10:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22zl8TbDL4-u for ; Fri, 31 Dec 2010 10:36:37 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 6905C3A67AE for ; Fri, 31 Dec 2010 10:36:37 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id D268933C76; Fri, 31 Dec 2010 13:38:43 -0500 (EST) Date: Fri, 31 Dec 2010 13:38:43 -0500 From: John Leslie To: "Richard L. Barnes" Subject: Re: New Year's Exploration: Changing the Internet's Infrastructure Message-ID: <20101231183843.GB19900@verdi> References: <4D1DEF2E.2070506@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: IETF Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 18:36:38 -0000 Richard L. Barnes wrote: > > ISTM that the success of changes to the infrastructure depends on the > value those changes deliver to participants in the Internet economy... > So the question is rather how many problems there are in the current > infrastructure that cause people enough pain to do something. Indeed -- _an_ interesting question... but perhaps not phrased quite right: in truth, there are an arbitrarily large number of problems that cause _somebody_ enough pain to do something. > I think there are at least a couple (improving BGP security, for > example), and the number will probably slowly shrink over time, > but in the long run, I expect there will ultimately always be a few > big things that need to be done that can't be done in end systems. Start from the end: there _will_ be a number of things that shouldn't be done in end systems. End systems _really_don't_ want to worry about the route packets follow -- at most they want to worry about delay, jitter, and order of delivery. But they _will_ work with whatever tools are available to ameliorate such worries. The number of problems will most surely _increase_ over time, not shrink. BGP security is a _dreadful_ example. It conflates weaknesses of the original design with issues entirely out-of-scope of the original design. And the original design was seriously flawed by defining algorithms instead of meanings. Nonetheless, the example does serve to illustrate a weakness of IETF process -- that it's much easier to get traction on small fixes to parts of the problem than on migration to a design which avoids the problems. BTW, I find it interesting to see how little of the work originating in the Security area has gained traction. I wonder to what extent this results from: - cycles being expended on cross-area reviews; - recommending IPsec whether or not it could be deployed for the use; - the inherent complexity of key infrastructure? -- John Leslie From scott.brim@gmail.com Fri Dec 31 12:28:04 2010 Return-Path: X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7C33A6822 for ; Fri, 31 Dec 2010 12:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.137 X-Spam-Level: X-Spam-Status: No, score=-103.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Uo8uIRq4bl5 for ; Fri, 31 Dec 2010 12:28:04 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id E42333A6821 for ; Fri, 31 Dec 2010 12:28:03 -0800 (PST) Received: by qyj19 with SMTP id 19so12966678qyj.10 for ; Fri, 31 Dec 2010 12:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9+iJ14fUbQPcM/tNwc5CaeZHZiTSkE2suBw7dRKP9KY=; b=TPil2GCbN9CeBBYDliqy5wz2ONLmzUmom1089xOs7a/7ntifwBS3Z5dBtXlBcmi/SI K3dljOlAQulQel022dbkauBwi8AF45rE/jqMJ+x+5kr9Ln8UmvVC7sSHBkidRGfdizzp /05vtX0GTGtaHxQrE2TbpAE61XSFFqwRE6Nc0= 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=kDInG4HaXdrrVQF1evfEHQH/X73xJMR2GJJKoPNy6ouH6/baDB524/CVA1wD2cd6Jz +PKdoXKiyNKxwjygN9c01uf9a4T/8ODlDev0dP/9Y2r9N2qZhIT09ZqG8JBBNwFBC9ci yGDGdEj2FkjDu1gf4TBEUHt8ciZtXHE54j0fI= Received: by 10.229.241.196 with SMTP id lf4mr15289144qcb.284.1293827409841; Fri, 31 Dec 2010 12:30:09 -0800 (PST) Received: from bxb-vpn3-760.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id g32sm10245905qck.10.2010.12.31.12.30.08 (version=SSLv3 cipher=RC4-MD5); Fri, 31 Dec 2010 12:30:09 -0800 (PST) Message-ID: <4D1E3D4F.7000905@gmail.com> Date: Fri, 31 Dec 2010 15:30:07 -0500 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Elwyn Davies Subject: Re: Question about Prague References: <8D7FD970-B4E1-41B1-8E50-69406AE54FD9@cisco.com> <70FF1D95-D56C-4F16-8FE6-3E80D914AD36@americafree.tv> <1293820656.17554.6074.camel@mightyatom.folly.org.uk> In-Reply-To: <1293820656.17554.6074.camel@mightyatom.folly.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Robin Uyeshiro , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 20:28:05 -0000 On 12/31/2010 13:37 EST, Elwyn Davies wrote: > Driving into the Czech Republic shouldn't be a problem BUT you do have > to tell the rental agency in advance and they will make a supplementary > charge per day for the whole contract (not just the days you are out of > Germany) if my recent experience is anything to go by (hire in Austria, > drive to Slovenia). Its not particularly cheap either. I've learned that in general it costs too much to rent a car for international driving in Europe.