From nobody Tue Oct 4 20:46:47 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3DA12943D for ; Tue, 4 Oct 2016 20:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRPzKQLZCDLS for ; Tue, 4 Oct 2016 20:46:44 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25CC128874 for ; Tue, 4 Oct 2016 20:46:44 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id ik13so26524586pac.2 for ; Tue, 04 Oct 2016 20:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=LzYKV4Swh5zuv9yttkR1yzCOxG6Fc/e7IT7PVOPbSV8=; b=ABnFA1ePdxXSYHMeXZWM3CUQgHe3VUVyVSmCJRjr8UE3Z7YJH4md8frQyJmY80DTRM ej6uf5yKNy6ocRQCCUEohq2O5GQ6tNbOTeOgUek4Fg5qYJEWB4TfS1kCdK+PyWP7pa29 VhE2oayJE5VV6QKe0O4DTbHXHecIgLaB74H0rphAb+5CHUaS70oC3tPN5q2p/HetKOQ2 PBAJ+LiIfajnmCu0lX7StcTrD5RCoMQHsVJkfhYfoPi7hOjTs56YVB7GK9MXscdTf834 RNFZZN5QMCd5p3+ImyoZ3gMj6euYcAbOWHxRQYnXnhDHvuz0rf3MlPB+zRGevoak9Rfc 1S2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=LzYKV4Swh5zuv9yttkR1yzCOxG6Fc/e7IT7PVOPbSV8=; b=nB5h5sOzIUns26MgcH/YHu282R7qnXNmraAx17pEQj00LzxcUnCG/z4FRwp+nREEQX 0EN/XILGD8ANzZWUJCE/ULOz/SdcHlUUxSpqZEsAlN62u7kmP+jQPFHcNDv88bhWx7XT 6FDmM0xcgNIqxgcarJJJbEu69rLaBHQ2UuvrMt5Q6/GqdnlzCYe9G+ImAd2TGPH44I85 NVa/AFJ+j/+/vcob5xZgoKgOXA+WXbPjz4iqlipJ9Ae20LAtn4dyRJw+yQu0sYD0umX1 2qfNidkIdLMMnGFtl6eJZQ/zFh9P/W830Dbm/IrLVlkxREOY6626YzaN1LatfOCjGyDA io1w== X-Gm-Message-State: AA6/9RnI6g8PzqrKv2RAHzKtZblNlaAPlebSIDcRY9j8PkF1+BYbaO7e3jOCGd2+9TOonQ== X-Received: by 10.66.222.169 with SMTP id qn9mr10102837pac.133.1475639204064; Tue, 04 Oct 2016 20:46:44 -0700 (PDT) Received: from [192.168.178.23] (20.23.255.123.dynamic.snap.net.nz. [123.255.23.20]) by smtp.gmail.com with ESMTPSA id p1sm9314292pae.12.2016.10.04.20.46.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2016 20:46:43 -0700 (PDT) To: Anima WG References: <80853531-a1cb-ec80-61d2-b31205865a5f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <536d0e69-4526-d187-8247-5e1d5ef9301c@gmail.com> Date: Wed, 5 Oct 2016 16:46:44 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <80853531-a1cb-ec80-61d2-b31205865a5f@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Updated the GRASP prototype X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 03:46:46 -0000 And again... I've updated the Python3 code to fix a couple of bugs and to add a "pretty print" feature. This allows the demo examples to produce nice output on a host with Tcl/Tk-compatible window support. There's a README file that points to the PDF documentation file. I've also added a folder 'brski' with demo code that shows how draft-ietf-anima-bootstrapping-keyinfra could use BRASP. If you want to play with that, it has its own README file. I advise downloading fresh copies of everything for consistent versions, and I would love to receive error reports. Brian On 14/09/2016 13:37, Brian E Carpenter wrote: > Hi, > > I have updated the GRASP prototype code to match > the -07 draft posted yesterday. Please see > https://www.cs.auckland.ac.nz/~brian/graspy/ > > Regards > Brian > From nobody Fri Oct 14 06:59:01 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8CC129822; Fri, 14 Oct 2016 06:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJXwujWgjNEA; Fri, 14 Oct 2016 06:58:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0295D12980E; Fri, 14 Oct 2016 06:58:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5DFF1200A5; Fri, 14 Oct 2016 10:13:14 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B567263AFE; Fri, 14 Oct 2016 09:58:52 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <2e343772-296a-b885-0193-ff7186f4b055@gmail.com> References: <12062.1476303921@obiwan.sandelman.ca> <34a6f1c3-9898-f1d8-70a9-60bfb59e21f2@gmail.com> <6843.1476370875@obiwan.sandelman.ca> <2e343772-296a-b885-0193-ff7186f4b055@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-signaling@ietf.org, anima@ietf.org Subject: Re: [Anima] [Anima-signaling] else clause in msg processing, or: where are the errors? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 13:58:56 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> I notice that we have no protocol versions in GRASP: I'm not sure we >> need them though, as for the ASA side of things, we ought to discover >> an ASA that speaks the appropriate version. > Yes, objectives have unique strings as names so versioning them is > easy. >> >> > Note that in a negotiotion session, we can in fact send M_END with > >> option O_DECLINE and an error string at any time. >> >> Yes, I realized that we could do this for M_REQ_NEG. >> >> > You are completely correct that this should be specified. >> >> >> I would rather (3), including the errant session-id. >> >> Do you have a preference? >> > I'm still mulling it over. I will definitely put this on the issues > list for the end of WGLC. Sheng is concerned that we haven't had enough > comment on the WG list. It's true, and this is one of the problems with design-team lists. For the benefit of the WG list, my opinion is that we need two revisions of grasp before it can advance. I think that this can happen by the end of November. I'm happy if we want to publish at this point, knowing that we will revise the document within a year, once we have a few more ASAs defined. Otherwise, I feel that there are unknown issues that won't become known (unknown unknowns..) until some ASAs do their thing. I found using CBOR for the encoding make life REALLY REALLY easy. (I used libcbor with C++ and cbor.gem with ruby). Not, I only implemented a very simple ASA. I've done protocols in XML and the like, and even with sophisticated XML library, it was never as easy as CBOR. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWADkmoCLcPvd0N1lAQKKfAgAqHd32pCC1xcxwJAqQuHhzhitGgndvJEk l6taRE3K2BAJvp7ziKysaajpOQvteohMj/Bp5MNVWxGMsdn6Ee9GTK7ZkhwMJJxO 7hNiE6SRPZRgCHwMMyMtDboVBAOFBqRruDAz/bxk6hnGecabYZXL2s5mP66Y9rTD qVpF3FlRsdYayepycMDDv3htC48l8lJYAH8oLAlgL+aQ6e5YstL+yNDYUY9lFrmL EgjF61iwQ1xhUWE9DhhDgyXTzJzuLOlaSGWwVMSAVgPoSQ1uOzV39PxnJUA8/SRf OfhIoTzHjrMRD3O0i8bQ9wnjqZCm2LBlJDf+QwerArUBeOqzxilWog== =ObEn -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 14 12:45:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C116B12950C for ; Fri, 14 Oct 2016 12:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrGQzbbGIHHD for ; Fri, 14 Oct 2016 12:45:01 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1501293DF for ; Fri, 14 Oct 2016 12:45:01 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e6so53473316pfk.3 for ; Fri, 14 Oct 2016 12:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RF7cU2yGxW2LtyzAR3ThM7J70x60gvPR1of5X0YukzM=; b=VUleHjLjqI632ben9P+/xlfNgpKFyyF0rokW3QH+2ItM7anbvlVcbYyaX15B0j08ce KSJ4Z/LiLvmgwKeDFxuH50NvXufGE1e3fWGpbRsyWoY7OkdF0w6cmska6QKQCX17cePL yVdYsrels/iOqgYZ4Ds6vMxhGawsg+Z4QiBzQ6be/fFl/6yuFqScsHoqb+6tPvDma66r LBnF31mAiEATs+gkMf8yAeqqk6CLNVralPZYAPpjGECx/WP5H/KjxxpBFq623cr4EJAB kWykAFbRjV0Td0l2ri4CbiPQhkmYW2s5go6Pfp6a5bA6WWXOrJvPaJyA1jeRWT3Fyu2J MPCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=RF7cU2yGxW2LtyzAR3ThM7J70x60gvPR1of5X0YukzM=; b=lzB7n2GRYTP90Gcv50PTUBbZF0JaOBiDY0GiKcblMDvLDiMg+upmevb4T/X+lPNbu5 A0BpwD3jqypECrnb/tIboMZS5Nwsj4evDFjAER5t3ptciZGzRclcrPSpnbvgn9SodwzF 5hLoy3TXJ5chvzIv/mtMoKqJ5zCOptupd+Lls9EuTsFepffvH7eAIwpMfPzGVCuXfEId pFBdNEdqqhKFGmH2C0slklhWz3oDt5YJpY66NFNlJjntFn2rc17yprFRwKG+rJmC7AF5 W9xlAatgi6DV85luP9U9oXdnuB1TlaggD5R4SNsmORkQfn65/gv/yBUEzfHs5xvrzc8j 8DMw== X-Gm-Message-State: AA6/9Rm+DEZ7VFqb23YjstA78OXAMSeJWtC3yD7y3hqjwVLX/8iQwUK4yB0sdhjzH5C6dg== X-Received: by 10.98.131.7 with SMTP id h7mr15165297pfe.86.1476474300799; Fri, 14 Oct 2016 12:45:00 -0700 (PDT) Received: from [192.168.178.23] (14.222.47.163.dynamic.snap.net.nz. [163.47.222.14]) by smtp.gmail.com with ESMTPSA id e74sm28547834pfk.13.2016.10.14.12.44.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Oct 2016 12:45:00 -0700 (PDT) To: Sheng Jiang , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927CC1FE61@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <63d9bdba-a0c3-98e2-98b1-0f1c38561c75@gmail.com> Date: Sat, 15 Oct 2016 08:45:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CC1FE61@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Toerless Eckert , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] WGLC on draft-ietf-anima-grasp-07 - Respond by Oct. 14, 2016 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 19:45:04 -0000 Just so that everybody knows, we have received Michael's excellent feedback on the GRASP draft on the design team list. Of course, after the WGLC, we will update the draft for editorial points and simple errors. Real discussion points will be brought to the WG list. You can see recent postings on the design team list at http://www.ietf.org/mail-archive/web/anima-signaling/ or https://mailarchive.ietf.org/arch/browse/anima-signaling/ according to which archive format you prefer. Regards Brian Carpenter On 30/09/2016 18:48, Sheng Jiang wrote: > Hi all, > > This message starts the ANIMA Working Group Last Call to advance draft-ietf-anima-grasp-07, DHCPv6 Prefix Length Hint Issues. This document's intended status is Proposed Standard. At present, there is no IPR file against this document. > > Please send your comments by October 14, 2016. If you do not feel this document should advance, please state your reasons why. > > Sheng Jiang is the assigned shepherd. > > Regards, > > Sheng & Toerless > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Oct 17 08:56:00 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841121295DE for ; Mon, 17 Oct 2016 08:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.395 X-Spam-Level: X-Spam-Status: No, score=-14.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdXYlR3ZXFHq for ; Mon, 17 Oct 2016 08:55:56 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66401294C4 for ; Mon, 17 Oct 2016 08:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56524; q=dns/txt; s=iport; t=1476719755; x=1477929355; h=from:to:subject:date:message-id:mime-version; bh=GenXlCPSY9/aP1Z7uU8CaV68aJvOk4NLlh7RoREkLoc=; b=MGsIZyC2bITi9c5l+HLkUQ5iQ4e2/sgqYXphnoU/Pqs5BA23sLIUlcQZ cr3kYudKW+YzMED53ZEW9492xGY1InxDUTQgNhnDjD2hcNCrLTkdrBS1J QmzaybfGgTCQS9aI4pznhOZU+UBs1nIzC2CA+yZUW/FVmQdHA4u9WBdPc 4=; X-Files: image003.jpg : 35229 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAQBR8wRY/4UNJK1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBgwcMKQEBAQEBHVeBA40tpiiBeoELgg+CCIgLOBQBAgEBAQEBAQFeJ4RoBSA?= =?us-ascii?q?IAV0BJQEBAQoeBRABDgwmAQQSAQYCBohEpX+caQEBAQEBBQEBAQEBAQESD4Y9i?= =?us-ascii?q?H8BAYV6BY56iHADghkBgTmDfgGKRIZpiROQcwcBHjZSgn4cgVOHU4EggQABAQE?= X-IronPort-AV: E=Sophos;i="5.31,357,1473120000"; d="jpg'145?scan'145,208,217,145";a="336068108" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Oct 2016 15:55:54 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u9HFtsbA004133 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Oct 2016 15:55:54 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Oct 2016 10:55:53 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Mon, 17 Oct 2016 10:55:53 -0500 From: "Michael Behringer (mbehring)" To: anima Thread-Topic: State machine for an ANIMA device Thread-Index: AdIojZ5+RoPPZJT2QIuzlWdhESGqAA== Date: Mon, 17 Oct 2016 15:55:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.134] Content-Type: multipart/related; boundary="_004_b8602f06445e4c369ddc6c7f2aa49d65XCHRCD006ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [Anima] State machine for an ANIMA device X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 15:55:57 -0000 --_004_b8602f06445e4c369ddc6c7f2aa49d65XCHRCD006ciscocom_ Content-Type: multipart/alternative; boundary="_000_b8602f06445e4c369ddc6c7f2aa49d65XCHRCD006ciscocom_" --_000_b8602f06445e4c369ddc6c7f2aa49d65XCHRCD006ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ANIMA WG, I=B4m currently looking at the to do items in the reference model draft. O= ne thing I feel would add value is a state machine description of the vario= us steps. It could explain how the various drafts fit together. I'm afraid = we're not all on the same page here. So I drew up how I see the state machi= ne for an ANIMA device, as a starting point, and how the drafts would link = together: [cid:image003.jpg@01D2289F.B21C35B0] The main states of an ANIMA device are "factory default", "enrolled", and "= in ACP". BRSKI takes a device from "factory default" to "enrolled". Once "e= nrolled" the ACP draft explains how a device (now with a domain ID) would j= oin the ACP for that domain. This draft explains how to get to the state "i= n ACP". Once a device is in the ACP, and (!) it sees a registrar (announced= by GRASP), then it starts the bootstrap proxy. The bootstrapping state machine is being worked on in the bootstrap design = team. Let's leave the details of that one in that design team for now. (I s= ent a mail on Friday to that list with another state machine, if you're int= erested). But my question to the team: Do you have the same view? (modulo the precise= naming of particular states). Did we all agree that we'll discover ANIMA n= eighbors through mDNS? (I thought so). That we use GRASP in the ACP to find= a Registrar? (Thought so, too). Also the separation between the drafts - does that correspond with your vie= w? Michael --_000_b8602f06445e4c369ddc6c7f2aa49d65XCHRCD006ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

ANIMA WG,

 

I=B4m currently looking at the to do items in the referen= ce model draft.  One thing I feel would add value is a state machine d= escription of the various steps. It could explain how the various drafts fit together. I’m afraid we’re not all = on the same page here. So I drew up how I see the state machine for an ANIM= A device, as a starting point, and how the drafts would link together:

 

 

The main states of an ANIMA device are “factory def= ault”, “enrolled”, and “in ACP”. BRSKI takes = a device from “factory default” to “enrolled”. Once= “enrolled” the ACP draft explains how a device (now with a domain ID) would join the ACP for that d= omain. This draft explains how to get to the state “in ACP”. On= ce a device is in the ACP, and (!) it sees a registrar (announced by GRASP)= , then it starts the bootstrap proxy.

 

The bootstrapping state machine is being worked on in the= bootstrap design team. Let’s leave the details of that one in that d= esign team for now. (I sent a mail on Friday to that list with another state machine, if you’re interested).

 

But my question to the team: Do you have the same view? (= modulo the precise naming of particular states). Did we all agree that we&#= 8217;ll discover ANIMA neighbors through mDNS? (I thought so). That we use GRASP in the ACP to find a Registrar? (Thought= so, too).

 

Also the separation between the drafts – does that = correspond with your view?

 

Michael

 

 

--_000_b8602f06445e4c369ddc6c7f2aa49d65XCHRCD006ciscocom_-- --_004_b8602f06445e4c369ddc6c7f2aa49d65XCHRCD006ciscocom_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=35229; creation-date="Mon, 17 Oct 2016 15:55:52 GMT"; modification-date="Mon, 17 Oct 2016 15:55:52 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAHfAzIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiuT1X4meHNJvGtWupLqZCRILSMyiM+jEcZ6/kaAOsorH8P+KtJ8TwyPpN0JWix 5sZUq8ZPZgfofyNa3mJ5nl7134ztzzj1xQA6iiigAoopqSJJnY6ttODtOcH0oAdRRRQAUUUUAFFc 54j8d6N4Vv7a01aWWOS5XcjLGWUDOMk10QIYAqQQeQRQAtFFc5Z+O9Gv/FUvh62lle/iZ1b92QgK j5hn26UAdHRRRQAUUUUAFFFc54H8R3HijQXvruGKKRbiSHbFnGFOAeaAOjoorM13xBZeHbSG41Bn Ec0626bF3He2cfyoA06KKKACiiigAooooAKKKKACio7ieO1t5Z5mCRRIXdj2UDJNZXhrxVp3iyyl utLaUxxSeW3mJtOcA9PTBFAGzRRWBoHjXRvEuoXdjp87m6tCRJFIm04BwSPUZ/mKAN+iiszQdfsv EmnG908yGESNF867TuU4PFAGnRWZZ6/ZX2uahpMJk+12AQzArhRvGRg9+KoeJvHOj+Ebi1h1eSWM 3IJQpGWAAIBzj60AdFRTY5FljWSNgyMAykdCKdQAUVzkPjvRp/Fp8NxSytqKsykCM7AQu4jd9BXR 0AFFYV74w0qw8S22gzySfbrkAoBGdoznGW6c4NbtABRRWN4l8Vaf4Ts4bnUzN5c0ohQRR7yWwT0/ CgDZorhh8XvDYI8wahGmQC72jBV9zXVaRrena9Z/atKvIrqHOC0Z+6fQjqD7GgC/RRRQAUUUUAFF FZmieILLxBFdSWDOVtbl7WTeu351xnHtyKANOiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKAK2pJPLpd2loStw0LiIg4Ifacc9ucVw3wi1PSR4ZTS4SkGq27Mt5BJ8sjPuPzYPJH 8vavQq5rxH4B0XxI/wBonga2v1wUvLY+XKpHQ5HX8aANtLG1tbi4u7e1iS5mA8x0QBpMZxk9+p/O vJh4n1v/AIWo1/8A8InefbP7K8r7F567tnmZ8zdjGM8YrpvDWpa5oXjI+FtfuxqMM0DT2N4QBIVB 5D/r19Pfhy/8l1f/ALAX/tWgDXtvFssPhy61fXtIutKW3kCeST5ruDtAIAHctj8Kx5PiLqqxm6Tw VrB08EEysQsm3OCfLxn14zXWa7rdn4e0ibUb9mEEWOEGWYk4AUdySa5b/hKvGl1++sfBeLZ+Y/tN 6kcmP9pT0oA2j4pF74UTW9AspdUEuNlujBHPzYYHPQjnP0rzzwJ4n1vToNaFn4TvL0TarNLIUnVf Kc7cxnI5I9feul+EDSP4Y1BpoxHK2qTl0ByFPy5Gaf8ACz/j18R/9hy5/wDZaAOg1DxNb6P4fg1L VYZbeaZF22a/PK0jD/VqB95s8Vzk3xF1ezjNzfeCtVhsV5eVXVmVfUpj+vFUvG0msz/E/Q7fREsZ Lm3spZ4VvAdiknazZXnOFGKv7/icf+WXhj85qAOw0vVLTWtNhv8AT5lmtpl3I6/y9iPSrdcp8PfD +p+HdGu7fVzbedPeSXCpbMTGisB8qggYGc8V1dAHm/jTSYNd+JelabdLmK50u4QnHKnBwR7g4Na/ wy1iS+8M/wBnXoZNR0lzZ3KMcn5fun6EfyNVtY/5LN4e/wCvCf8ArUGpZ8JfFa01AbfsHiBBazDg bJl+630PGfqfagDp/F+u/wDCN+F77UgA0sabYU/vSMcKPfk/kDXn/hzRW0Px74WguAftk2mz3F0z feaVyS2T7dPwrf1zf4n+JGm6Om2TTtIX7dejsZTxGp+nBx7nNO1b/ktGg/8AYOm/rQBveJPFNr4Z igM9teXU1wxWGC0hMjvjk8ewOa55/iRe6c6Sa/4U1LTbBmCtdFhIseehYAcD/PNb/ibxVb+HFtkN rcXt7dMVt7W2Xc8hAyT7Aetcb4p13xpceFNVjvvCcFvavayCWUX6MY1KnJwOuPSgD0xZo2gEwcGI rvDdsdc1xH/CypdSkkbwz4dv9YtYm2NcowiQt6LkZP6VXv7qWz+AiSwNtf8AsiJMkZ4ZVU/oTXWe FrKDT/C2mW9rGI4ltoyFHqVBJ/M0AV/Cvi208VWszQwT2t1bMEubW4TbJExGRn2ODg+1cB4B8ZQ6 P4abTrGxutV1V7yd/slsvKLu+87HhRXrKQRRzSSpEiySY3uFALY6ZPfFcJ8HrWCPwrc3CRIs0t7M JJAPmYA8ZPtQBo+HvH0era42ianpl1pOqhfMSCchhIuM/Kw74z+VX/F+vQeHtNtbi5sheLNdxwBC QNpbOG5B6YrB8cwRjx54Kn2DzTdyIX77QAcfqak+LP8AyL2mf9hW3/m1AHR+KNdXw14cvNWaAzrb KGMYbaWywHX8a5sfEt9RUN4b8Pahq6KB50sf7uNG/uhiPmI+lXfin/yTbWf+uaf+jFrc8PWsFn4e 0+G2iSKJbdMIgwBkAn9aAKPhLxhY+L7GWa0SaCe3fy7i2mXDxN6H26/l2qbxH4ntPDdvG06TXF1O 223tLdd8sx77R6Due1c34dgjg+MHilYUCBraB2A7sQCT+dZmsSeIbn4vXf8AYCabJcWmnIq/bg2E Rjk7dvOST37UAacvxI1DTds2u+EdSsLHdtkuVcSiP3IAHFdi2p239kPqcUgmtRCZw8ZzvUDPH4Vx 0o+Jc0TxSQeF2R1Ksp80gg9RitnwJoF34f8ABlrpOqtFLNFvV9rF1KliQOR0welAFzwv4ktfFmix 6nYxzRwu7IFmADZBwehNbFQ21rb2UIhtYIoIgchIkCqPwFTUAcd8S7maTQrfRbKXy7zWblbRDn7q Hl2+mBjt96s+CBfBvxNtYIYymm61aLApBwqzRLgA+5UDrySazNY8XW0HxXe4ube/u7TR7cwRLZw+ aBO4+djgjGFJXB71U8eeNbDxDoSiy0nXI9Qs5kuLWSS0KqrKRnJBzjGf0oA9frw/S9Pu7TQp/FOk qTeaRrFyZ0U4M1uSpdTjrjr+fpXsOhatDruh2epWzBormIOPY9x9Qcj8K5P4VIsnh3V0kUMjarch lYZBHy8GgDr9J1O31rSbXULRt0FzGJFz1Gex9x0rkvhD/wAiW/8A1+z/APoVVvDUz+C/Gdx4XuiU 0y/ZrjSWIG1T1eMHt14z/WrPwh/5Et/+v2f/ANCoATw1/wAlZ8Y/9c7T/wBF1V8cabb6x8RvDWn3 ahoLm1vI3HpmPqPcdateGv8AkrPjH/rnaf8AoujxH/yVvwh/1yu//RdAEvww1SSXQptDvdy6hosp tZVc5JQE7G+mBgfSug8T62nhzw3fam4DG3jJRScbm6KPzIrk9ez4T+J2m62u37FrQFhddBsk/gb6 cDP0PtU3iff4m8eaT4ej2yWVjjUL9exI4jVvx5x3z04oA5zQdHk0nxp4La8Vv7QvIbu6u3f7zSOh PP0GBivXHdY42dzhVBJJ7CuI8Q/8le8Jf9cLr/0A1Y+KWtPpPgyeK3d1ur9haxeXy/zfewOpO3PT 1oA5L+xLrxN4P17xRGGa/u7sXlgVOXSOBiEC+hwG6DJ/GvS/Dusx+IPD9lqcQCrcxByoOdrdx+By K43S/iNo+l6Ra6fFo2v+VbwrCv8AoJ6AY/vVB8KNZtlvtZ0OCG4toFna7soblCjiJjgjHoDjp60A emVwnxP/ANZ4U/7Dtv8A1ru64T4n/wCs8K/9h23/AK0AdzJGksbJIiujDBVhkH8K838Q6ZH4D8Ya Z4g0gG2sL+4FrqNvGD5bFicPjseegHb3NelVw3xQ/wBMtdD0qHm6vNTiMY7YXJYnvjn0oA6bXtfs vDunG7vmY5YJFFGu6SZz0VF7k1ys3xE1ezjN1e+CtVisV+Z5VdWZV9SmP68VS8bSazP8TdCt9FSx kuYLOWeFbwHYrE4ZsrznCjFX9/xO/wCeXhj85qANbVvG1nY+EY/EdlH9vsGZN7I+0ojNtLYx1BIB XrXRxyLLGsiHKuAwPsa4zwf4QvrHwpq2la/9lJ1C4mk2W5LRorqOACBgA54qLwNr40/wLdQ6tJsu NAMlvcCQ8hUzt/MYAxnOOM0Ab1l4lW/8XahokFsxXT4Uea4L8B35CBcc8c5z7Uzwlr0Gv22oyW9k LQW19LbMAQfMZcZfgDrms74Z6fNB4ZOo3qMt7q0z3k277wDH5Rnvxg/jVb4V/wDIO1//ALDdz/7L QBoeIPHVto+qrpFjZXOqawyhxaW4xtXrlmPA4+vaoNI8fNc61DpWt6Je6Nd3Ofs/nfPHKfQMB19q p/DlVuta8W6jMqtdtqsluZMf8s0wFX/PWu4kgimaNpYkdo23IWUHaemR6Hk0AZHiPxRa+HY4UaGe 8vbg7beztl3SynucdgO5Nc8/xIvtNdJNf8KajptizBXut4lWPPdgBwPesm+k8R3Hxc1lvD0elyT2 lnBDuvgw2RsN2F2+rE5z7VpXUPxKvLSa2mg8MNFKhRgfNOQRg9aAO8gniureOe3kWSKVQ6OpyGB5 BBqSsHwTo95oHg/T9M1B0e5t0ZWZGLLjcSACfQECt6gAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigCnq1tdXek3UFhdfZLqSMrFPtz5bdjiuLt9f8AiDp0f2e/8LW+pyr/AMvNtdrErD3B7/lXoFFA HHeHdA1i58RyeI/FBt0vFi8i0tbc5SBDySW7sef19sV/FGka7p/jK28UeHbSLUHFr9kubR5AhZN2 QVJ6HP8AKu5ooA4PV9L8ReNfBk6ahYwaVqUV2s9lAZQ4wmMb2GRzlumO1JFrnj++iWzXw1a2Fwy7 WvprpXjU9CwQc+4HP413tFAHHfDHRNT0Hw7dW2sxlbp76WXcSD5gIX5uPUg1jwWni3wTqmrR6Po0 Wsadf3L3cTfaFjeJ2xndnqOnHt1r0migDkPEXhvVdc07SdUt5orLxJpy+YgBzCXYDfGf9k4wD/jV KPxL49kUW/8Awh1vHcH5ftD3y+UD/e2jnHtmu8ooAztCXVU0qP8At2S3e/JLP9nBCKCchRn0HGa0 aKKAOS1LR76f4n6NqkVuWsbezljll3DCsc4GM5q1498Ot4l8KXNpbqTex4mtWDbSsq8jB7Z5H410 dFAHI/DvQb/SNHuLrWs/2tqM7XFznBK9lXI7AD14zS6jo99N8UNI1SO3LWMFlLFJLuGFY5wMZzXW 0UAcZ410TWH1rSfEPh6KK5vdO3o9tKwUSxsOQD69R171ka9N488V6DfWMWh2+jxNCwk8y5WWScY+ 4mOBnoSfXqK9KooA57SNCE/w/stF1aDBNglvPGSCVOwA8juD39q5bR5fHXg6yGj/ANhR65bW/wAt tdR3SxHy+ykHuP8AOa9KooA5/wALQeIh9suvE09v5tw6+Ta2/MduoGOD1JPU/SqXw20e+0TwxJa6 lbmCc3csgQsD8pPB4JrraKAOT8W6Pfaj4o8K3VpbmSCyunkuHDAeWpUAHk8/hSfEXR77WtFsIdOt zPJFqMMzqGAwi5yeTXW0UAc58QdMu9Y8DanY6fCZrqZFEcYIG7Dqep46A1s6ZE8Gl2kUq7ZEhRWH oQoBq1RQByek6PfW/wATNe1OW3K2VzbQJDLuGHKqMjGc03xZ4b1ObVrTxF4bmjXV7RPJME3+quIi clT6HnrXXUUAcIviPx7dqIYfCFtaTEf6+5vVaMevyrz+tdTEuqQeHCJ5Ip9VS3b541wjy4OMA9s4 rSooAwvB02uz+Ho38TRLFqRdt6qFA25+X7pI6Vr3ckkNnPJBE00qRsyRqQC5A4Azxz71NRQBzHw+ 0O60Pwwq6koXULqZ7q6AOcO56enAAHHFdMyq6lWAZWGCCOCKWigDlPA+lahoDatpVxC66dDdGTT5 CwKmJ+do5z8p65A68Unw70e+0XSNQh1G3MEkuozTIpYHKNjB4PtXWUUAc3448OP4g0UPZfLqtk4u LGTONsinOPocY/Wqnwx0nUdF8Ii21e3NvdtcSSMhKnhjnsSK6+igDktC0e+tPiL4m1Ge3KWd4luI JdwIcqmG4zkYPrRrej3118R/DWpQW5eztI7hZ5dwwhZMLxnJyfSutooAwPG3h8eJvCt7YKubgp5l sc4xKvK89uePoazPhxoGpaXp13qGv5/tfUZvMnDEEqqjaoyPYZ6967KigDk9Z0e+uviT4c1KG3L2 dpDcLPLuGELKQvGc8n0pL7R77VfiVp99PbldM0q2doZCw/eTPwcAHPAx1HautooAK5LxRo98PE+h 69o9uZZ4JDb3aowDPbt1zkgEA8/jxXW0UAFcX8StM1TULTRptHsDfTWOpR3TQiRUyqgnqT64H412 lFAHCjxR45uP3UPgqO3kbhZZtQRkT3IAyR9Kt+HvC+pvrS+IPFN3HPqSxtHb20K4htVJ529ySO/8 66+igDmPGXhm61kWWo6Pci21jTGaS1Z+UfONyN7EDrWUniXx7Iot/wDhDrdLg/L9oe+Xygf720c4 9s13lFAGdoS6qulR/wBuyW73xJZ/s4IRQTkKM+g4zXC+LPBmrXviudNOh3aTrnkDUXV1Xy/LbJJB 5JK9Md69LooAZFEkMSRRrtRFCqB2A6Vyvw+0e+0ay1hNQtzC0+qzzxAsDuRtuG4Psa62igDz7UtE 8QeFvFt1rfhazi1Cy1HBvLAyCNvMH8ak8d8/ieO9X9MuPGet6zaTX9lb6HpkDFpYBKJpZzjAUkcB ec/hXZUUAcd4q8OaqutQ+JfDEkf9qwxeRLbT/wCruYs52+xB96qjxD49vh5Nt4StbCUj/X3V6HQf 8BXnNd3RQBW09LqPTrdNQkjlu1jUTPGMKz45IHpmrNFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU 3eu/ZuG7GcZ5rN1We4luoNNs5DFLOC8swGTFGMAkf7RJAHpye1T2Oj2OnMXtrdRKR80rfNI31Y8m gC7RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRVXUNRt9MtTPdPtQcADksfQDua4+88aX0zn7IkdvH 23De3+Fa06M6nwozqVY0/iO6orzn/hKNY/5/T/36T/Cj/hJ9Y/5/j/36T/CtfqdTyMfrcPM9Gorz n/hJ9Y/5/j/36T/Cj/hJ9Y/5/j/36T/Cj6nU8g+tw8z0aivOf+En1j/n+P8A36T/AAo/4SfWP+f4 /wDfpP8ACj6nU8g+tw8z0aivOf8AhJ9Y/wCf4/8AfpP8KP8AhJ9Y/wCf4/8AfpP8KPqdTyD63DzP RqK85/4SfWP+f4/9+k/wo/4SfWP+f4/9+k/wo+p1PIPrcPM9Gorzn/hJ9Y/5/j/36T/Cj/hJ9Y/5 /j/36T/Cj6nU8g+tw8z0aivPI/FerxsCbhJB6PEP6Yro9F8Vw6lItvcoILluF5yrn2Pr7VE8POCu zSGIhN2R0FFFFYGwUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBlJz4sl9rJcf99t/hWrWU n/I2Tf8AXkn/AKG1atABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHnXiTUW1HWJRu/cwExxjtx1P4 n+VZNPlVlnlV/vCRgfrk0yvapxUYpI8ecnKTbCnKjSNtRWY+ijJptW9PlWF52bp5LADcVycjjIqm 7IlK7KpBUkMCCOoI5FJWnax208Mjy+Wu7efmbLA44GSc9fY06PyopxsjtijxMsZZsliU788c8ZOK nnK5DKorRjitzChZYghQEvu+bzN3I69MZ7fjRi1k+1v5KKICdgXOGByoyc+uDRzhyGeql2CqCWJw AO5oIIOMc9MVf0tYw0bsIi6zLuMjbdqeo59frU6LapHFKFVmDKxYkcNv5z82cY7Y/Ghzs7AoXRlS RvE5SRSrDqD2pFUuwVQSzHAA7mtW2S2ubqdphAqNMQfZfUZYYz6jPNNtYYEljn3RBQsRGXGd+5d3 H50c4chlngkdxRVy7dXtLfasfylwzL97O4nn8CDVOqTuS1YKPoSCOQR1BoopiPR/DuotqekRSyHM yZjkPqR3/HrWpXMeBlYaddMfumfj/vkZrp68arFRm0j16TcoJsKKKKzNAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKAMpP8AkbJv+vJP/Q2rVrKT/kbJv+vJP/Q2rVoAKKKKACiiigAooooAKKKKACii igAooooA4HxZpT2Ootdov+j3LZz/AHX7g/Xr+dYVerzQx3ELRTIrxuMMrDIIrmL3wPGzFrG5MQPS OQbgPoetd9DFJLlmcNbDNvmgcfRXSf8ACD3/APz923/fLUn/AAg9/wD8/dt/3y1dH1ml3MPq9Tsc 5RXR/wDCD3//AD923/fLUf8ACD3/APz923/fLUfWaXcPq9Tsc5Tg7BCgJ2kgkepHT+Zrof8AhB7/ AP5+7b/vlqP+EHv/APn7tv8AvlqX1il3D6vU7HOUV0EPg29mDEXVsNrlPut2OKf/AMIPf/8AP3bf 98tT+sU+4ewqdjnKK6P/AIQe/wD+fu2/75aj/hB7/wD5+7b/AL5aj6zS7h9XqdjnKK6P/hB7/wD5 +7b/AL5aj/hB7/8A5+7b/vlqPrNLuH1ep2Ocp0Uck8yRQoXlkO1FHc10sXga6Lfvr2FV9UQk/qa6 HSdBs9IBaFS8xGGlflj9PQfSs54uCXu6suGFm372iJdG04aVpkNsCCyjLsO7Hk1eoorzW23dnopJ KyCiiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDKT/kbJv8AryT/ANDatWspP+Rsm/68k/8A Q2rVoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAKth/q5v8ArvJ/6Eat Vmi6Flp13cEAiOWRsMwUH5vU9Kp6Z4oXUbuO2+z7ZDK8TlXJVSqB+NyqTww7D8aqW4o7G9RXL2Xi q6nW8uZLOMWqpAYAsvzlpcABuMYy3Xt6GtS11pXd4byLyLlJvIKITIpbarjDYHGHHUDnNSM1KKw4 9fuJbG2nWwXdesgtVM/DhlLgsduVO1TkYPbk84gbxVKBKy6cSltC01y3nAbAsjowXj5jmMkdM98U AdHRWJoE93PFqM94Pm+1SomJi42oxUALgBcADp16mqy+KJVto5vsRkiSzgup5TKFIEmeAuOSNvsP egDpKK5hfFF1bWMb3tpD5813PBEEkYqQjMMnCEjhccA59qg1XxLfXOlzjT7F4WEcDO8s3lsgkbG0 DaSDjPPGMg9eKAOuorAm8QjTtQtrCaFSGaKEsJmdw7YA/hweo5ZgT1x0y2TxQ8WlQ30lkFS6ZBbf vSd4cEgthSVOByAG6jk84AOhorBTxK7izP2LyluCQ0k7MiKQ5XCnZznGRuC5BHrxvUAFFVP7UsP+ f22/7+r/AI0f2pYf8/tt/wB/V/xp2Yrot0VU/tSw/wCf22/7+r/jR/alh/z+23/f1f8AGizC6LdF VP7UsP8An9tv+/q/40f2pYf8/tt/39X/ABoswui3RVT+1LD/AJ/bb/v6v+NH9qWH/P7bf9/V/wAa LMLot0VU/tSw/wCf22/7+r/jR/alh/z+23/f1f8AGizC6LdFVP7UsP8An9tv+/q/40f2pYf8/tt/ 39X/ABoswui3RVT+1LD/AJ/bb/v6v+NH9qWH/P7bf9/V/wAaLMLot0VU/tSw/wCf22/7+r/jR/al h/z+23/f1f8AGizC6LdFQQ3ltcsVguIZWAyQjhiB+FT0hhRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFQXt5FYWklzOT5aY+6MkknAA9ySBQBPRXPWniYPfTwTW91 ve58qCEQ4dQIo2bd24Lk5zj0pmqeKlS2mis4bkXYdEUeWpYq0ioXCk9tw4bHJHHWgDpKKydO1sXM l7HcQyW62cohM0xVVkO1Tnrween0pk3iW1t0/eK7yGeSFY48ZOw4Y/MQOOO/egDZorl7zxY81rdn T7S5ZUkt0iuERWDrLswygkc4fgH2rbn1KG0tGkcvK8YXfGgBcE+ozgfjgUAXaKwz4tsNissdy/7t pX2R58tUba5Y5xwR2J9s06XxPaQZ8xJXJlkjURIW+4AWJ6YABzQBtUVkx+I7SazmuIo7hhEVynl4 YhhlW5xgEc8498U2416GXw/dXtnKqypBMyK+Mh0ByMd8Ec4zQBsUVixeJbdrcF7e7FwdgWAxYeTc CQVGehCOecfdNK/iezWNXEdwyhC8xWP/AI91DFSX57FWHGfumgDZorDi8URG1kmns7mIrdSWyIQu ZCrMMg5x0UnnHpzQPE8aSXwuLK7iS1mihDbNxkZwmAADnOXA/WgDcorIfxJaxXKQTw3ELOuR5iAf Nt3bcZznAPOMcdajXxZZNCsnk3a7/LMaGE7pBIcIQPQnjnFAG3RWI3iizRJJZFlSOKFpJFKEupV9 hXA6kE9jUh8R2+Notrs3PmGP7MIx5mdu7OM4xgg9aANeisK68RRyeHl1CzcQs5jYLOAGVDIqkkZ4 GCeafN4r0+CVUk80AgMzFQAisxVWIJzg4OMA0AbVFZLeIbUsUj3mRZFjcFT8hMojAPoSTkeoGaqa j4sht7G9e2t7lpYVmETNFhJJI925RyM42k56YB5oA6GisaDXEhxbTRXstxFAsszeQAVBBxuxwCdp 4H8uat6ZqsGqxyNAHVon2SI+MqcAjoSOhB696AL1FITgZPSq11qdlZQmW4uYkQerZJ+g6k+woAqJ /wAjZN/15J/6G1atZekRzzT3OpXUTQtc7Viif7yRLnbn0JJJI7ZA7VqUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFeWf2hekkm9u+p/wCW7ev1o/tC9/5/bv8A7/v/AI12fU5dzk+tx7HqdFeWf2he /wDP7d/9/wB/8aP7Qvf+f27/AO/7/wCNH1KXcX1yPY9Toryz+0L3/n9u/wDv+/8AjR/aF7/z+3f/ AH/f/Gj6lLuH1yPY9Tpkm/ym8ogPg7d3TPvXl/8AaF7/AM/t3/3/AH/xo/tC9/5/bv8A7/v/AI0/ qcu4fXI9jtNDa51O2vItSt4vIMjKU2n5mz83foKuf8I7pfkmL7Gm0v5hOTktjGSc5PAA9xXnwvrw ZxeXQyc8TN/jS/2he/8AP7d/9/3/AMaqeElJ3ukTDFKKtY9DXQtNWMotnGqGEQbV4GwdBj2wMHqO 1T2lhb2FsYLSMRIST1LEk9yTyfxrzX+0L3/n9u/+/wC/+NH9oXv/AD+3f/f9/wDGo+pS7l/XI9jt P+EcxBJCEswkjB2URsOR0AO7IAyemMZI6GpF0J0heFfsnlvF5DAwn5kBJwee5Zs/UnrXD/2he/8A P7d/9/3/AMaP7Qvf+f27/wC/7/40vqMu5p/aK/l/BHo1jZy2wkWRofLdmcrGm3LMcsTz6ml/smxE DQ/Zo/KaJIWXHBRM7V+gya80n1S8ggkla9u8Ipb/AF7/AONEGq3k9vHKt7d4dQ3+vf8AxpLCNPl5 tQliXKPtOXS9vmekTaJYTq6vbjDyeadrFTuPUgg8Z74608aTZCJ4/s6lXCK24klgnK5J5OKxvBVx NPZ3fnzSylZgAZHLEfKPWulrnnHkk4msJc8VIoz6NYXN6t3Nao86srBjn7y9Gx0yMdevamDQdNEM sS2iBJWDsASCCOmDnK4ycAYxk1o0VJRn/wBh2H7jdAWEH+rDyMwHOeQTzz65q+elLSHpQBQ04pDo VtK0ZYJbqxCJuY/L2A5JqCDxBYXCo0cVyFacW4Mls0fzkkY+YDOCpBx0q3pP/IHs/wDrin8hWVPo U1zpsNrMiMo1J7iRS3BjMrt/Jhx+FN7iWxu5i83ysLv27sY7UOYo1BcKASF6dycCuaTQLuIXaFD9 naGWOKOGUKQDKWRRngDbgenarNrpd4mgQ2xhgglS6il2RhUARZVY528bsA9ODSGb2xf7q/lWVD4h 0uZJHDOqRxvLukgdQ6J94rkfNj29RUOlabPa69e3DWypDLuxLJsaRiWyMMOdvXhunygdKxbbw5qK WMlstn5MpguInmkuvMSQOrYCqc7PmKHgDgH2oA6OPXNPkt5ZiJY/K25SSBlc7jhcKRk7jwMdTT/7 Y0/aSWKkIr7GiYN8zFQMYzuypGOvFZyaJPapdq6PqKzRRYM8+2QFCfkDADGM7lPUEnkcYhh0bUxq EOpS7GuYIFRVeTO5d8hKE9N2xkG/1B7E0AdDbzW92jvDtZUkaNjtxhlJUj8wal2L/dX8qytLS5sb hrSSAlZZri4aUH5UDSZQdOpDH6YrKn0PUpPEhu1jjSDzHMkkbBXkjMbAANjfnJXgkAYBHSgDqti/ 3V/KjYv91fyrn9J0m4ttCvbaW1EPmghEhZElb5cfMy/Lu9D+dZk/hzUZNPtU+ywhI3l3W0ccIJ3b drsCNm4bWGQM4I96AOz2L/dX8qNi/wB1fyrk08P3ya7b3EnnyxqYSs26IyRhUUMrMRu5IYkLwdx9 TV3QNBl0iSyYIiYsvLuirkmSXKYJJ+9gBsHtmgDf2L/dX8qNi/3V/KnUUAUSoGuRYAH+jP0H+0tX qpN/yHIv+vZ//Qlq7TYkFFFFIYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFV76zi1Czktp92x8cqcEEHII9wQDViigDLs9At7O7F151zNPvZy8smSxZUU9sdEXgcVVg8H6d b3BmVpy2FUZYDCrIsgHA55QcnJPOTW9RQBSXSrYTXLsvmJcsHeKQBk3gAbgCOuAPyrHu/D0lz/y7 orLNJMr+YrEFzl+GUjB4xxxjrXS0UmioyS6XOe/sa53N+6X5zEWHnYVnjKlHIC9toBAwD2Aq9caR Dqdq4u4EglkcOzRYLZX7uSRhvoQRWnRQkOU01skY1t4WsLW2lgi87ZLDJC2W/hkYs2OODljUh8O2 RJOZeTKT8/8Az0UK36DitWimQZEvhqylgkjJlHmeXzuBwY12rwQQePUEUsHhvT7fS3sViJjdZV3t jeokyWwccfePStaigDHHhq3CE/arxpwyGOdpAZIwoYKAcYIAd+oJ+Y89Ka/he0eMRia5VWQxzhXH +kKWZiH47l2Py4+8fbG1RQBlzaDDLb3EC3E8cM8xmZAEYAnJYAMp4JOfr0xQvh+0RvkaZY90L+Xv yN0W3a2TznCKDzyB681qUUAYd54WtLm8kvVZxcEtIgJG0OUK5Jxuxg9M49qq/wDCJMthZxi7ma4i MAeRpOUSPnCHGeuSM5966aigDG/4RiyMTo7zuZEZHcuMtucOScDGSR2qr4g8NHUS0lthmklEkqNJ szhNow21sdPQ59q6OigDCOhmXQ0tru3t558Kj4wuUVtyqW28gYGeADg8DNVW8Ozfao7hYlEkYC58 xXLKpJC5dCQOSBggjuTXT0Umi4zSVrJnOro11595I1vbg3M8cx2yEYKEMvbpkZI7kmifRJbm28iS 1Xy9074Fwc/vtwYZx/tsfyroqKVvMftF/Kvx/wAzCuNMubn7Z5ttGftcaRybZyOEzjHHGc/41LoG kHSRcr5YXznEjsHB3NtA6AADgDoOtbFFO3mJzTVuVDWVXUqwBVhgg9xWTN4U0eWRZUsYoLiP/Vzw DZJH9GFbFFMgzdJurhnuLK+YPdWpGZAMCVG+6+Ox4II9Qa0qyk/5Gub3sk/9DatWgAooooAKKKKA CiiigAooooAKKKr3zvHasY22MWVQwAOMsB3+tNK7sJuyuWKTNV/s03/P7N/3yn/xNZcui3smti6S /kjjCgEjG5vbAGMVUYp7smUmtkcCO/1P86KB3+p/nRXsrY8h7hRRQeQaYiaa0nt1BljKjOOoOPrj pUOR61rz3Vs8zO7xPE0iPtjQhjg87uBnjNRm5jyN1xE0+1gswT5VyRjt6Bu3es1N9UaOK6MzcHaG wcHgGgAlSwHAOM1pTXkbqkaPHsSYOVdPlbhcngdMgn8aWa8QxzRLPkOUY5XIOM5AOB6jsO9PmfYX Ku5l5HrRmteC9t2vJXmdREZeFCADy8ngYU/lx9aC8SrboWjKvGm2IJzuL8NnHp70ud9g5F3MkAtn aM4GTjtSZrUu54R9oRnR3/eqhWPbtHG1enqD/jTkuIbi82YRl8xPKGwDAwd36460+d2vYORXtcyQ QelV7q+hsyvnbwG6EISPzrY1UOPIDEsoUgMybWY5ycjA9RWbJGk0ZSRQyN1BpNylD3NGXT9nGova puPW2j/UxtT1aC4szFbs5ZiM5XHFJperQW1mIrguGVjtwueKz9Qt47W9eKJiVXHXt7UafAl1exxS MVVs9O/tXzv1vEfWunN8PlufoqynLv7Kv73s/jvpzbenY9T+HmpQXcN7HCsxxIGLmMhR8oGM+vtX aVw/g+xuTp9yunXn2RUlHyeUrK3yj15rfzqkA/fvKwH8cKI4/LAP867qkZcz5mrnxvNT/wCXSaj0 vq/0NmismG4knbZHqieZ/ceABvyJBqz5GoD/AJfIT9bf/wCyqLWHe5dpD0qn5eoj/lvbH6xEf1oI 1L+9aH6hh/WlYLkNtdLY+GY7pwSsFqJCB3AXNQad4ltJ7O0a7uYUuLiLz9iqygJk8nPIAxgk8fmK vJYn+xxYs/PkeSXA/wBnGapnw9E8UsckzlJbBbFsAA7Ru+bPr81D3BbEn/CSaUIPOa7CqXEYDIys WIJACkZOQDjjnBq1ZanZ6jv+x3EcwTGShyOehB7jryOOD6VQh0KX7dHe3d4JrlZFclItikKkiAYy f+ejHOfSp9K0ddLKbZmk2WkNryuOI93P47v0pDCbXrCOea2S4RrqPIMeDwwXdtJ6A4xx1plt4gtH tbJrqVYp7iGOQqASqFgMZOMDnpnGapR6BdT3949xceXbNeG4jiCAkny1UNuzwOvBHbtTW8HxfaLa UTRv5UMMLiaIsGEf3SAGAB+oPagC1N4ltE1WK1jmjKbZWnc5GwIByD0IycHFSR+J9KlEhS5YmNgr J5L7skEgbduTwCeBWde+F5zbSCK685Y45xBAyBeZDk7m7kHp0/rVO08M3l9GRemRHilEqTXIy8jb SpDBZTkAEYO4d+KAOrtr+2vCRbTLJhVc7fRs4P6Gq/8AbmnkTET5WHhmCNtJzjCnGGOeMDPNJpNl Pp6NAxhFrGiJAkSbQMD5jjnGSemT0681nzeFRcJeLJcqqTurpHFGVRWVw4JG7k5ABwVzz60AaDa/ pyQJMbg7HJAAjYsMdcrjIxkZyB1HrV9HWRFdGDKwyGByCK5qXwakkEI823EkfmA/uH2OHKk5XzM5 +Qclj9K6OCIQW8cShQsahQFGAABjgdqAJKKKKACiiigCk3/Ici/69n/9CWrtUm/5DkX/AF7P/wCh LV2mxIKKKKQwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDKT/kbJv+vJP/ AENq1ayk/wCRsm/68k/9DatWgAooooAKKKKACiiigAooooAKq6h/x6H/AH0/9DFWqq6h/wAeh/30 /wDQxVR3QpbMtUUUVIzyQd/qf50V2B8CQ5OL+cAkn7i0f8IJD/z/AM//AHwteosVTtuea8NUOPor sP8AhBIf+f8An/74Wj/hBIf+f+f/AL4Wj61T7i+q1Dj6K6uPwVE9xLH9um/d7edi85FS/wDCCQ/8 /wDP/wB8LT+tU0H1aocfRXYf8IJD/wA/8/8A3wtH/CCQ/wDP/P8A98LS+tU+4fVahx9Lmuqt/BUU yuTfTDbIycIvY4qX/hBIf+f+f/vhabxVNAsNUZx9Fdh/wgkP/P8Az/8AfC0f8IJD/wA/8/8A3wtL 61TD6rUOQZmY5ZiT6k5pK7D/AIQSH/n/AJ/++Fo/4QSH/n/n/wC+Fo+tUw+q1Dzu10rfcNdXoBd2 LCPsPrRd6VtmW6swFkRgxj7H6V6J/wAIJD/z/wA//fC0f8IJD/z/AM//AHwtc1sLy8tvO/W/c9P6 7j/a+05ulrdOXtbt/W47wKc2V4f+mw/9BFdTWZomiposMsaTPL5r7yWAGOAO30rTrCrJSm2jOlFx gkyKa3huF2zRJIPRlBqt/Zvlc2lzNB/s7t6/k2f0q9RUXZdkUvMv4PvwxXC+sZ2N+R4/WlXVLcEL MXt3P8My7f16H86uU1lDqVYAg9QRRdBZiPIEhaQAuApbCDJP09a55vGMMdjHcSQIplm8qNTcJjO0 sdx/hOAeDWppckR0a0UyKP3CjhsEcVCNG0wRldz7y4fzjdP5uQMf6zdu6Ejr0JoaswTKi+Lo5EWW Oxna3EUcsspKgIrsVHGck5Xt2INNuPGNva3V1BJbszQRySBY5UZ2CdcqD8vtn9KnGg2D6lJdTzGV THFGqtMxOELH5ju+fls/NnpUr6Fo8kju8asWDrgzNtUP98KM4XJ5OO9IZBceJxZXdvb3lp5LzMql TOhYFm2rhQcnkjPpn2qpH4xeHSbO4v7OOG5ujJtj89VQqhGTuPfkcfWta50vTLy6+0TqrSbkY4mK qzIQVJUHBIIGCaadI0wxqis0YV2dDFcuhTd1CkMCFOB8o49qAGXviGO10+zu44HdLsBk8xhEqgjI 3MeAeelV4/EdwsGpTXVkiR2tz5MbeeoDjAOSSeOv6itG6s7O8tkgnmkMaDGBcuu4YxhiDlvxzUcm laXIJBgKJGVzsmZdrKMBlwflOOMjBNAGbbeLjcXDyC1H9nxWb3EsyyBmVkZ1YAfxDKcEdas6d4oh v7K+uBFg2cfmsI5BIGXBIww4z8p47cetTxaNpEKqscaBQsilfNJDq5JYMM/MCWJ5zyalhsbGG2mt /NkkimXa6zXLycYxgbmOOvagCjaeKRc3UUMlhcQeY6IWcqdpddyDg9SBz6e9R/8ACYW4nuYXg/eR KWRUlRy2HVMEA/KcuvX39K0V07TFkEgSMMrpIDvP3lXap69hxUA0HRgzHy1O5GjAMzEIpIYhRnCj Kg8YwRxQBSutdvbTVFeSym8tbJ5poN6fJtcZbPfjoB19qn/4SRmkEUFnJcSyXEkMaqVQfKgbJJPo f/rVcTS9MRGXCtviaFi8zMWRjlgSTk5PfrTorDTYJkljWNZEdpFO88MwCk9fQCgDKbxtZ/abeJYm ImWJjlwHHmHC4Xq3PXHSulrKj0jTIXiaBnhMQVQIrl0BC9AwDYbHvmtHz4v+eif99CgCs3/Ici/6 9n/9CWrtUN6PrkW1lbFs/Q5/iWr9NiQUUUUhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFAGUn/ACNk3/Xkn/obVq1lJ/yNk3/Xkn/obVq0AFFFFABRRRQAUUUUAFFFFABUF3C0 9uyRlQ2VILdOCD/Sp6KadtQauVf9P/6dv/HqT/Tv+nb/AMeqHXrt7HR5p4/vKUA5x1cD+tZWkyT2 lr4hv5GhlkS5mKkRkNhAcBjk5A6DpjmnzeQrG5/p/wD07f8Aj1H+n/8ATt/49WA3iDUIUjiuGsll mSCQShGEcIk35yC3zY2dcrnP5u0nVb698QRrLdW4tjbuvlrHgTMkrrvQ7u4AOOePzo5vILG7/p// AE7f+PUf6f8A9O3/AI9Vqijm8gsVraGZJZpJzGWkxwmcDA96s0UUm7glYKKKKQylaypDBO8hwomf Jx/tU6z1CO9nuY4kfbbyeUznGGbuBznj3A68ZqjeWk19ol7b2xAleZtpJx0fPX8KXS9GFgmqnyY0 e8uJJd0R2synpkjvyfpmqluKOxrgg9DRmuUsNG1GwS3mis4R9nuC4hDorupjKEsyqFJBOc4zj3p2 laFe2lxatd2tvM6xqvmiU/6OwZy23jJ3bh6ZxzUjOpyPUcUZHHI5rkH8O3zaJHbLawxyxSRmba6t 9s2qwZmDKVySQ3zAnjnkCpItBuo30srahmg+8blo5FjHmFsBQvBAPBTH8IPAoA6HUNQj063EkivI zOsaRpjczMcAckD8yKlubhLS0muJA2yJDIwHXAGTXKDwtLO7pNY2xt/tcU37/Y8jhXJYlguWGDxu yfep7zRtUmaa2jjhMDXM9wJmlwSHikULtx2LDNAHTQSrPBHKmdsihhnrgjNSVBZxNBYwRPjckaqc eoGKnoAKKKKACiiigCr/AGbYn/lzt/8Av0v+FH9mWP8Az523/fpf8KtUU7sVkVf7Msf+fO2/79L/ AIUf2ZY/8+dt/wB+l/wq1RRdhZFX+zLH/nztv+/S/wCFH9mWP/Pnbf8Afpf8KtUUXYWRV/syx/58 7b/v0v8AhR/Zlj/z523/AH6X/CrVFF2FkVf7Msf+fO2/79L/AIUf2ZY/8+dt/wB+l/wq1RRdhZFX +zLH/nztv+/S/wCFH9mWP/Pnbf8Afpf8KtUUXYWRV/syx/587b/v0v8AhR/Zlj/z523/AH6X/CrV FF2FkVf7Msf+fO2/79L/AIUf2ZY/8+dt/wB+l/wq1RRdhZEMNpb27FoIIo2IwSiAZ/KpqKKQwooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAyk/wCRsm/68k/9DatWspP+ Rsl/68k/9DatWgAooooAKKKKACiiigAooooAKKKKAEZQwwwBHoRSbFwRtGG6jHWnUUARvBFIhWSJ GVhtIZQQR6UCGFBGRHGoiGE+UDYOnHpWV4g19NHhVI1El1IPkQnhR/ePtXC3l/d38he7uJJCf4c4 UfQDiuilh5VFfZGFXERpu27PUPOj/wCeif8AfQpPOi/56J/30K8m8tP7i/lR5Uf9xfyFb/Uv7xj9 c/unrPnRf89E/wC+hR50X/PRP++hXk3lR/3F/IUeVH/cX8hR9S/vB9c/unrPnRf89E/76FNkkjkj ZBMqlgRuVhke9eUeVH/cX8hR5Uf9xfyFH1L+8L65/dPQPD0NzbLctf3RcmQhFZxjGeW/Gtnzov8A non/AH0K8m8pP7i/kKPKj/uL+Qqp4Tmd2/wFHFcqtb8T1nzov+eif99Cjzov+eif99CvJvKj/uL+ Qo8qP+4v5Cp+pf3ivrn909Z86L/non/fQo86L/non/fQrybyo/7i/kKPKj/uL+Qo+pf3g+uf3T1t ZEb7rKfoadXkifuzmMlCO6Haf0rotF8WT2kqw6g5mtyceY33o/cnuP1rOeElFXTuXDFRk7NWO5op FYMoZSCCMgjvS1yHUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAZOqCSxvoNUjjeSONDDc IgywjJBDAd9pHI9Ca0La7gvYRLazRzRnoyMCKpardXBng0+xcR3NwCzSkZ8mMY3NjueQB7n2qCHw josZZ3sY55XOZJZ/nZz6kmgDaoqgNC0wWjWosLcW7NvMewbS3rihdC0xLV7ZbC3EDsGaMINpI6HF AF+iqCaFpkdrJbJYW6wSEF4wg2sR0yKI9D0yG2lt47C3WGXHmIEGGx0yKAL9FUItD0yCCWGKwt0i mAEiKgAfHTNEOhaZbxSxQ2Fukcw2yKqABx6GgC/RVCDQtMtklSCwt41mXZIFQAMPQ0W+h6ZaiQW9 jbxiVdjhUA3L6H2oAv0VQttD0y0Lm2sbeIyKUfYgG5T1B9qLbQtMs3Z7awt4mZSjFEAyD1FAF+iq FtoWmWcpktrC3icqVLIgBweopLbQtMspvNtbC3ikwRuSMA4PWgDz/Vrtr7Vrm4Y5Bcqvso4AqpUt 1bm0u57cjBikZcfjx+lRV7cElFWPGm25O4UUUVRIVLBCbiQoGVcKWLMeAAMmoqsWNwLa48xmdcoy 7k6gkYyKTvbQa31I2gbeVjImA/ijBI/lTVjdgCqOQTgYUnNXPtwQMElmfdMkjM3BYAHg4PvTm1FX lHMqxeU8eAfulmJyB+NTeXYqy7kENk823nYTJ5eGByDtz/SoNjeWJNjbD/Fjj86v/wBoxh4vlkYR sDk4ywCbc/WhNRRbOOML86IqEbMhsHPXPGfpReXYLR7lN7d44FlcFcuV2kEHoDn9aiq5eXaTwLGj SsRK0mZMcZxwPyqnVRba1Jdr6BRRRTEFFFFAHe+DrxrnRRG5Ja3cxgn06j9DW9XIeFdDsr7TJJ76 0hn3SnyzIgOAABx+IroJdC0yeGKGawt3jhBEasgIQH0rxqySqOx69JtwVy/RVCXQ9Mmt4oJbG3eG HPloUGFz1wKH0LTJbaO3ksLdoIiSkZQYUnrgVmaF+iqDaFpj2qWzWFuYI2LLGYxtUnqQKDoWmNaL atYW5t1besewbQfXFAF+iqH9h6YbMWv2G3+zht/l7Bt3euPWgaHpgtDaiwt/s5beY9g27vXHrQBf oqguhaYto1qthbi3dgzRhBtJ9cUJoWmR2slslhbiCQhnjCDaxHQkUAX6KoR6HpkVtLbx2FusMpBe MIMNjpkURaHpkNvLBFY26RTY8xAgAfHTNAF+iqEOhaZBDLFDYW6RzDEiqgAce9EOhaZbxyxw2FvG ky7ZFVAA49DQBfoqhBoWmWqyrBYW8ayrskCoBuX0NFvoemWnmfZ7G3i8xSj7UA3KeoPtQBfoqhba FplmztbWFvEzqUYogGVPUUW2haZZyGS2sLeJypUsiAEg9RQBfoqhbaFpllL5trYW8UmCu5EAOD1o ttC0yynE1rYW8UoyA6IAeetAF+is+30LTLS4Fxb2FvFMucOkYBH40Q6Dpdtci4hsLeOZTkOsYBB+ tAGhRWfFoOlw3QuYrC3ScNuEgjG4H1zQmg6XHdC5Swt1nDbxIIxu3euaANCis/8AsHS/tX2n7Bb+ fv3+Z5Y3buuc+tDaDpb3RuWsLczlt/mGMbt3rn1oA0KKz5NB0ua6NzJYW7TltxkMY3Z9c0TaDpdx cm4msLd5mO4yNGCSfrQBoUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGUvPiyTP8 NkuPxc5/kK1ayk/5Gyb/AK8k/wDQ2rVoAKKKKACiiigAooooAKKKKACiiigAooooA5TxXoEk8h1C yQu+MTRr1YDow9648HPSvW6zr3QdO1By9xaoZD1dflb8xXXRxXIuWWxy1sNzvmiea0V3v/CG6T/c n/7/ADf40f8ACG6T/cn/AO/zf41v9ch2Zh9Un3RwVFd7/wAIbpP9yf8A7/N/jR/whuk/3J/+/wA3 +NH1yHZh9Un3RwVFd7/whuk/3J/+/wA3+NH/AAhuk/3J/wDv83+NH1yHZh9Un3RwVFdva+EtLlWQ sk2VlZR++boDxU3/AAhuk/3J/wDv83+NN4uC6MFhJvscFRXe/wDCG6T/AHJ/+/zf40f8IbpP9yf/ AL/N/jS+uQ7MPqk+6OCorvf+EN0n+5P/AN/m/wAaP+EN0n+5P/3+b/Gj65Dsw+qT7o4Krul6Vcav ciK3BEYP7yXHCD+p9q7OPwjpEbZNu8ns8jMPyzWxDDHbxLHDGsaL0VRgConjFb3EXDCO/vMZaW0d laxW8K7Y41CqKmoorgO4KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiisvWNci0ifTopACb2 4EIyfujB5/PA/Gk2lqyoQlN8sVqalFFFMkKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAyk/wCRsm/68k/9DatWspP+Rsm/68k/9DatWgAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAoopCQBknAoArWH+rm/wCu8n/oRqKXXNOhtI7qS6RY JJfJWTBxvyRj26Hk8cVWnF1caVdwadIEuJZnQSgjMQLYLgdyByBWTH4YvLa4htWeK609pllcCNYh HiNo2AUHnIKn6g+vFS3FHY6N9Us0ujbNOomB2lMHrtLf+ggmoTr2mjQ/7Y+1L/Z/l+b52Djb64xn 9KwrbQtTTUC0yK6RvtWUuMyIIHRWI9SSuffPam/8I1fnS/sWE8j7J5gjyP8Aj68vZj/dz83+9zUj OpF5AbpLbzV854zIqdyuQM/rTJ9RtbW8t7WeYJPc7vKUg/NjGeencVzo0LV/tS6r56C5jkVktNin 92o2+X5mehBLf7xq5r9rHcajC0syQqLWRUkJ5SUvGyMB3wUJP68Gi9hqLk7JG3BcxXSs0Lh1R2jY jsynBH4EGnpIkm7YwbaSpx2I7V55c211cJHJLKELGdmjgZHaKRpWYOpZlGcEYIyeOlWNYlKRKrS2 9wHvZmWGab926sMqSSQMgA459aXMu5fsqn8r+47WG8inurm3Td5luVEmRx8wyMfhRY3kWoWcV1Bu MUgyu4YNcRpNnZpAt1bzrvVrTyJGl52KVEp4JGSA2euRjtimWdpJBYNDHstpRA6TMLncLk+YpAGO R8ocAHH3sDI5o5l3D2VT+V/cehVHNKsEEkr52RqWbHoBmuOtLa2kv7czbbewSaR1tjcZEeUjC52k gjcrt1IyR34rT8SadcakY2htmu4TbyIsYm8vZK2NsmcjGACMjJGelCaZMoSj8SsblrdRXluk0LZR lDe4yARn8CKmrkpdEv8A+xmgkhllfz0ZI0ZGQgQop3BmAI3A8A9cGp10q++03J+zhLiSDbBdRzkJ APJC7APvEBwW6Y5znIxTJOmorkotGv0srlrK2axlRYmgiaUNumUtvbgkYZWC8+mccCmS+HtQi1i1 KvNJbxLAqSx7CybT8/LuCA3fAbgmgDsKguruOziWSbO1pEjGBnlmCj9SK5G48M3y6fZ7YmkffI11 HuEhck/IfnYDCjI68Z4FSy6Ffvc2xkt5bmRJLRlupbgKY0QpvVgDySVZsDIOetAHUvdxR3kVqcma VWcADooxkn05IH41MTgZPSub12KQ3uoqjeW93pZigfdt+dS+fm7Eb1P5nsaq20FvZ6p50FwBCty+ Mzs2IPIwQAT3l+bHUnnmk2kVGEpfCrm5beItNuk3xzuEMZlVpIXQMoGSVLAbuOeM1Iut6e1rBci6 TyZ1Zo3OQCFBLfTABzn0rl1lku9DsNPkiS3eyg2l5JkKyP5DRgLtJ4y3U4HGOtBt0S8tVzbz2RiZ 5Y2k27ZGiMbJj0Y4Jx05Jx3OZdyvZVP5X9x1MWsWk7QBGk/fu0al42TDgZ2kEAg4yRkc4+lXq5JL h7uKytC7PKdQSSGJ5BJIkKYLF2BIOCDg5OQV5JNdbTvchpxdmc1qPjzStJvXtb2O8ilQ9DAcEeoP cV59438Uxa/qlrLp7SCG2TKlxtO/OScfgK9R8QaFp+uae8eoR8ICyyrw0fuD/SvBX2h2CNlcnaTx kdq4MXOcVy9GfWcP4fC1W6qT547321PXIPifoht4zOblZdo3gRZAOOe9dRpuoJqdkl1FFNHG/wB0 TJsYj1x6V5x8M9C07UnuL27Xzri2cBImHyKCOGx3Oc/lXqVdFCU5x5pHjZrRw2HrOjRTut2/0Cii itzywooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMpP8AkbJv +vJP/Q2rVrKj58Vzkfw2cYPtl2x/I1q0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAc5/wm+nZP7m 7ODj7i/40f8ACb6d/wA8Lv8A74X/AOKrhx3+p/nRXprCU7HnPFVDuP8AhN9O/wCeF3/3wv8A8VR/ wm+nf88Lv/vhf/iq4eij6pTF9aqHcf8ACb6d/wA8Lv8A74X/AOKo/wCE307/AJ4Xf/fC/wDxVcPU sEPnM4zjajP09Bmj6pTQfWqh2f8Awm+nf88Lv/vhf/iqa/jTTJY2R7e7KsMEFF5H/fVckbGdT8y4 4OcEHBAJwcdDgd6bJaTRRCR0wpAbqM4PQ464pfVqXcf1mr2NvQtc0zRxOfKu3eRzhtg4TsOta3/C b6d/zwu/++F/+Krjkti9rJNuA29F7sB94j6ZFSfZYVdYZJXEzbeiAqM4I5znofSqnQpyd23cUa84 qyOt/wCE307/AJ4Xf/fC/wDxVH/Cb6d/zwu/++F/+Krk7mx8oM0RkIVmVhIoU/LjJHPTmqdSsLSe w3iai3O4/wCE307/AJ4Xf/fC/wDxVIfGumtjdb3Rx6xr/jXEUU/qlMX1uodt/wAJnpf/AD7XPb/l mvbp3pD4y0ojBtbnHp5S/wCNcVRR9Tpj+uVD0nSdUtNZikktonURvtYSIAckZ7Z7GtDy0/uL27en SuY8C/8AHne/9dh/6CK6muCrFRm4o7qU3KCbGeVHjGxcYx0p9FFZl3CiiigAooooAKKKKAEIB6jN J5aD+Be3b06U6igLjPKjxjYuMY6Uvlp12L+VOooHdjQiqcqoBxjgU6iigRl+JILu70K5tdPUG4uF 8oEnAUNwxJ9hms/QvA+l6Pp7wTQpdzTLtmkkXO4egHYV0lFQ4Jy5mbxxNSFN0ouybu/M5HQ/Ccvh jxM81gxk026jKurH5omHK/UdR+NddRRTjFRVkKvXnXlz1Hd9+4UUUVRiFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAYWsa3JDM1rZwzb47i3jlnUKVTfInBBOe VPUDjNNbxZGunR3rWU0cErFY2mlii3AdT8zD04HU9elXrnQrK7vRdSrJv3pIVWVlVnQgqxUHBIwO tNl8P2MtrBb7JEjgVkTZKyna33lJByQcDI9hQBijxNeNNdXdtaTXFsbi2ggTfGqskiod2Cc7vn78 cj0Nblzq8EVxBBHLG8rTrDIisGaMsrEZAPH3aRdAsI7J7WOJkiYxn5XOVKKqoQc5BARfyqW/sTcr AY9nmQSCRS+eoBGeOvU0DSu7GFL45gkt5m0+3+0SrtZE86P518xUYkBsofnHDYP5Grtlq0n9parL qRa0tbZ0iQyyxiMZRG55zuy/UnGMDrUSeG5khlhEqmBxgQGSTYmDkbRn5TkAgj7vbNXrPT7u0kci SBhK6tKzBiz4ULu5PXCgfrSv5F+z/vIgufFFraambOWNg2DtIkQliFLcJu3YwDyRimxeJlma3X7L PA07RFVlAJKSZ2twePung8j0qzL4c0+e7a4kjkLF2k2iVggYqVLBc4yQSKlOi2RlhkMR3QrGqHee AhJX8txpmZmp4xt3AY2V2sZG/ewXATfsLdem7t1I5AqzJ4ktodaXTpkKO7bVYyJydpb7u7cBgHkj HFS/8I7p3leV5LbPL8rG9vu79+Ov96l/sCx/tBb3ZJ5qymZV8xtgcgqW25xkgnNAFfU/FNlpsUMx ZJraRS/nJNGFwDztywLkei5P503UvEiWmlT3MFvJLIjzxIhwAXiV2OTnp+7NWtS0Cx1Yk3SSENH5 TqkjIJF6gNg8gEkj60x/DmnS3ZnlidyWdvLaRvLBdSrkLnHzBjn60AQy+I/s6K01jONkSTXOGQiB WJAzz833T93PSkPim3QytNa3MUCGZRKwXDmLdvAAOf4Tgkc1PJ4dspfLEhuG2oI3zO371QSQH5+Y DJ6+pqaTRLGWJY5IdyK0rbSx5Mm7fn67j+dAFJ/EvluIJNOuhdmQR+QChPKM4JbdtAwjd+KIfE0N 1AskUM0e97faJVGWjmbarYzxnB4PIx0q1b6DZ27rJ++llV9/mSys7E7WXkk9AGbj3pyaHYxoirEQ EWFV+c8CI5j/ACJ/HvQA2DW4ZRPLLG9vaRFlFzMyrGxVtrd8j5uOcZpj69Ckl23kTNa2isZblcFQ QgcjGc/dIOcY5xVi10q2s55ZYRIPMJOxpCUXJy21TwMnk0x9Es5LmeZ0cidSJYvMby3yu0krnGdv GfSgCm3iXy2WGTTbsXbSKiwKUYncrspyG2gfu278YqFfFn7y8kaxmFna2gnZwyltwaRWTbnnmMgY 449MVoW2hWltIkv76WZJBIJJpWdshWUDJPQB249zSN4e09kkTy3CSxvHIokYB1ZixzzzgsxHpk0A QHxGEm2S2FygRkWZiU/dF2wmRu5zx0zjPNM07XY4tBjuNQuFa48uWXy8qHkVC2dq8ZwBV250Szur 37VIJN5Kl1WQhJCpypZRwcdqJ9Ji/sS4062xGskMkalsttLA8+vU0AZ769LcXVjEkE9o73Ee9JQu WidJCp4Jxyh46jFI3jG0jluI3t5jJCMiON43dvnVPuhsqcuvDYP5Grll4es7RYTiSSSIoyu8rMRt VgoGT90b2wPc0xPC2mJJv8qQkLsQNKxCLvVwqjOANyKcUAV7rxdb2aKtxbvFc+Y0bQyTRptKqrH5 y208OvQ559jW1aXUd7ZwXUJJinjWRCRg4IyOPxqpc6FaXMrTfvopmkMhlhlZGyVVTyD0IRePar0a eVEiAswUAZY5J+p7mgBXcRoztnaoycDNYdx4x02KSOGHz5rmU7Y4jC0e4/7zgAfnW9Uc8EVzC0M8 aSROMMjjII+lAFPSrKa3E1zeMjXl0waXZ91ABhUHsB+ZJPetCsnSN9ld3Olu7PHAFkt2c5by2yNp PfaVI+mK1qACiiigAooooAKKKKACiiigAooooAKKKKAPJB3+p/nRQO/1P86K9xbHivcKKK0ZNHaN wjzKpyQxYdMKTxg5I4/lQ5Jbgot7GdUsM4hWTCAu6lQxPQEYPHerMenebIAkpKMgZWEfJySORnjk HvTp7FVijXeqzpHIWUKfm2s2Tn6Dj6VLlHYpRe4xtRJLlYVVpCzSHcTuYqVz7feNRNdsyyDaBvjS M+wXHP6VbfS/OuLho2WNBM0aDHAx6nPA5HrUGnWn2p3Z1YxRgbgCAcngf4/hSTha42pXsJHqdxEI kjbbEg2mMdG/vZ+tJ9sQssj26tMuMPvOOOnH0FPkgWwQefCkshkdCGJAG3HTBHXNSTw262itsjQt CHU+YS5YnoRnpjPaj3ewe93KrTiaSWS43OzA7AWJ2kn+lQVbWxDRoRMPMaPzdm08LnHX1p505BKU +0g/vfJBEZwX9OvT3quaKJ5WyjRVtbHKRO0qqJX8scE4bJB/l+tQ3EDW0gjcjftBYf3Se38qakmK zRFRRRTEdl4F/wCPO9/67D/0EV1Nct4F/wCPO9/67D/0EV1NeRX/AIjPWofw0FFFFYmoUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFAGUn/I2Tf8AXkn/AKG1atZSf8jZN/15J/6G1atABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAHkXmJk/OvU9x60eYn99P++hXq/2S3P8Ay7xf98Cj7Hbf8+8X/fArvWN/ unE8H5nlHmR/30/76FTtqLtgmZMjPzAKCcjByep4NeofY7b/AJ94v++BR9jtv+feL/vgUvrif2Q+ qNfaPLo9QeIAJOoAAUDIOACSP5nn3pW1KV4yjXIKnOckdzk8+5NeofY7b/n3i/74FH2O2/594v8A vgUfXF/KH1R/zHl41BwXPnI28lm3BW5PU89KhM6mMRmRdgbdjI69K9W+x23/AD7xf98Cj7Hbf8+8 X/fAo+uL+UPqj/mPL01GSPpOmMAYYKwwBgdajkuvOYNJMrEDGSw6V6XY2luUlzBEcTOPuD+8asG0 thjMEPP+wKbxaT+ESwra+I8yfUmaGOJZVVEQLwRzyT1/pTE1B42dlnXLtuYnB59eeh9xXpzQWSMq vHbqzdAVUE0JBZyMypFbsV6gKpxS+tr+Uf1V/wAx5h9s3IsbzBogR8m4dv5dTz70k90s88krOmXY n7wr04JYGbygtsZckbMLnOM9PoR+dS/Y7b/n3i/74FH1xfyh9Uf8x5R5if30/wC+hR5if30/76Fe pOlhHII5FtVc4wrBQTk4HHueKl+x23/PvF/3wKf13+6L6n5nN+A2DWV6VII84dD/ALIrqqZHFHEC I0VAeyjFPrjqT55OR1048kVEKKKKgsKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDKT/AJGyb/ry T/0Nq1ayk/5Gyb/ryT/0Nq1aACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii myOsUbO5wqjJPoKAK9h/q5v+u8n/AKEawfEC6tf6kq6XbK62AEitJMYg055A+6dwC5B6ffxng1ra PqFtdidbeZZGEjMQPQng1pVU01LUmDTWhydvcabNczzavalp7mRXtRLbs7hCi4VTjght3HHPNL4T 0aeEW97NHb24VJV2xxlZJdz9ZCepGOPqa6uipKMXU7AafZXt9pkTC/2SMpGWJLEFuDx1UVk3niGe XUQIrye3097gIJltsnZ5JYldynjcBzg+ldhUUltFLNDLIgaSEkxsf4SRg/oaAMrS7FdRtLTUNShJ vSqsS2R90kr8vbrn649K2qKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDKT/kb Jv8AryT/ANDatWsonyvFi7uBPZ4QnuVfJH5MK1aACiiigAooooAKKKKACiiigAooooAKKKKAGu6o hZ2CqoySTgAVz1541soHK2sUlyR/Evyr+Z6/lWT4u1d7q8awiYi3hP7zH8b+h9h/Oudruo4VSXNM 4q2JcXyxOr/4Tt/+gcP+/wD/APY0f8J2/wD0Dh/3/wD/ALGuUorf6rS7GH1mp3Or/wCE7f8A6Bw/ 7/8A/wBjR/wnb/8AQOH/AH//APsa5Sij6rS7B9Zqdzq/+E7f/oHD/v8A/wD2NB8duRg6auP+u/8A 9jXKUUfVaXYPrNTub2meJo9KSZYNNH72QuT5/Qdh93tV3/hO3/6Bw/7/AP8A9jXKUU3h6cndoSxF RKyZ1f8Awnb/APQOH/f/AP8AsaP+E7f/AKBw/wC//wD9jXKUUvqtLsP6zU7nV/8ACdv/ANA4f9// AP7Gj/hO3/6Bw/7/AP8A9jXKUUfVaXYPrNTuddF47UsPOsHVfVJQ38wK39N1ez1WMtay5ZfvIwwy /UV5lUlvcS2lwlxbuUljOVP9D7VE8JFr3dGaQxUk/ePV6Kp6XqCanp0N0gxvHzL/AHW7j86uV5zV nZnendXQUUUUhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAZuuQ27WHn3FybRrdhJHcDrG3Qcd8 5xt75xVGy1bXZoiZNEVgPuyGcRbx67Dkr9DVm5QXniW2hk5itYTcBexkJ2qT9Bux9a16AM4XepGz aQ6YonDYEP2kYI9d2P0oW81I2jyNpiicMAsX2kEMPXdjitGigDOS71JrSR30xVmUgJF9pB3Dud2O KIrvUmtpXk0xUmXGyP7SDv8AXnHFaNFAGdDd6k9vM8umLHKoHloLkHf6844ohu9SeGZptMWN1XMa C5Dbz6ZxxWjRQBnQXepSJMZtMWJlXMai5Dbz6Zxx9aLe71KQS+fpiwlUJQC5Db29OnH1rRooAzra 71KUyfaNMWEKhK4uQ25uw6cfWkhv9Q/eNd6asEaIW3C4D5I7YxWlUF5/x5T/APXNv5U1uJ7Ea3F2 ygizGCM/60f4Vmyanqqa0LeOxEkJUFhu+777un4VtRf6lP8AdFPqlJLoS4t9TyeV2lnlkf77yMzf XJplaXiCwbTtZnQriOVjLGexB6j8DWbXr02pRTR5U01JphRRRVkBRRRQBeS2ikt4nclAIXkcqMls PgD9aj+xbr5IEf5XCtvbjapGcn6Cq/mOF27224K4z2PJFHmPkne2Su089vT6VNn3KuuxozWsUbSX EaRtGItyoGDqGDAEHHsc0W7RSWrTSxWsf71VJZDgrg52gd+Kz0lkjx5bsuDuGDjB6ZpZbiab/Wyu +efmOanlew+ZDX2+Y2zOzJ25647U2iitCAooooAKKKCcDJoA6jwreX8OnzpZ2IukExyTOI9uQPUG uimu9SSCFotMWSRgfMQ3IGw/XHNQ+GdPbTtGjWUYllJkcehPQflitevGqtObaPXpJqCTM6W71Jba F49MV5Wz5kf2kDZ6c45oku9SW1idNMVpmJ3xfaQNg7c45rRorM0M57zUhaRyLpitOWIaL7SBtHY7 sc0Nd6kLNZBpimctgxfaRgD13Y/StGigDON3qX2ISf2Yv2jfjyftIxt9d2P0oF3qX2IyHTF+0b8C H7SMFfXdj9K0aKAM5bvUjZvI2mKJwwCxfaRgj13Y/ShLvUjaSSNpirOrALF9pB3Dud2OK0aKAM6O 71JrWV5NMVJlI2RfaQd/rzjiiK71J7eZ5NMVJVx5cf2kHf6844rRooAzobvUnhmaXTFjkUAxoLkN vPpnHFEF5qTxzGbTEidVzGouQ28+mccVo0UAZ1vd6lIspn0xYiqZQC5Dbz6dOPrRbXepSeZ9o0xY dqEpi5Dbm9OnH1rRooAzrW71KVnFxpiwgISpFyG3HsOnH1otbzUpZCLnTEgQKSGFyHyewxitGigD OtbzUpZttzpiwR4J3i5D89hjFFrd6lLcBLnTFgiwcyC5D4/DFaNFAGdbXmpSXKpcaYkMRzmQXIbH 4YogvNTe6VJtLSKEnBkFyGwPXGK0aKAM6K81NrsJJpaJCWwZftIOB67cUJeam12I30tFg34Mv2kH 5fXbj9K0aKAM77Zqf2vy/wCy08jfjzftIzt9duP0oe81MXZjXS0aDfjzftIB2+u3H6Vo0UAZ0t5q a3ZSPS0eENgS/aQMj124onvNTS6ZIdLSSEHAlNyFyPXGK0aKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAyk/5Gyb/AK8k/wDQ2rVrKT/kbJv+vJP/AENq1aACiiigAooqrf6nZ6ZG kl7cJCrtsUt/EcE4H4A0AWqKjhmjuIUlhdXjcZVlOQRTyQqksQAOST2oAWikDKVDAgqRnIPGKFYO oZSCpGQQeCKAFqC8/wCPKf8A65t/Kp6gvP8Ajyn/AOubfyprcT2JIv8AUp/uin0yL/Up/uin0mNF LVdKt9XtfJuAQQco6/eQ+ori73wnqdox8qMXMfZoyAfxU16DRW1OvOnsZVKMam55j/Yuqf8AQOuf ++R/jR/Yup/9A65/75H+NenUVt9cn2Rj9Uh3Z5j/AGLqf/QOuf8Avkf40f2Lqf8A0Drn/vkf416d RR9cn2QfVId2eY/2Lqf/AEDrn/vkf40f2Lqf/QOuf++R/jXp1FH1yfZB9Uh3Z5gukak4JXT7kgEg 4Xv+dL/Yup/9A65/75H+NeiWH+rm/wCu8n/oRq1Q8ZNPZCWEg1ueY/2Lqf8A0Drn/vkf40f2Lqf/ AEDrn/vkf416dRR9cn2Q/qkO7PMf7F1P/oHXP/fI/wAaP7F1P/oHXP8A3yP8a9Ooo+uT7IPqkO7P NItA1WZgq2Eyn1fCj+ddJonhFbSVLnUGWWVTlI1+6p9T6munorOeJnNW2NIYaEHcKKKK5zcKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooARmCKWYgKoySewoVg6hlIKkZBHeuf8d6j/ AGd4SvGBw8y+Qv8AwLg/pmneCNR/tPwnZSE5eJfJf6rx/LBqOdc/IdP1af1f6x0vb8Lm/RRRVnMF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFQw3UU81xFGS Xt3CSDHQlQw/RhSXl3HY2rzzbtq4GFXJYkgAAdySQB9aAJ6KjimSZSUPI4Ze6nGcEdjyKcjrJkoy sASDg5wR1FADqKrXV/BZwSyyPuERVWVBubc2Aq4HckjH1FTq25Q2CMjOCORQA6iimrIj52MrbTtO DnB9KAHUUVFdXMdnaTXMxIihRpHIGcADJ/lQBLRTUYOisvRhkU6gAopqSJICUZWAJUkHPIOCPzoV 0dmVWUlDhgD0OM4P4EfnQA6iiigAopvmJ5nl7l343bc849cU6gAoqC8u4rG3M85IjDKuQM8swUfq RU9ABRTXdYxl2CgkDJOOTwKbcTx2tvJPOwSKJS7sewAyTQBJRUcE32iBJdkke8Z2yLtYfUdqkoAK KKgur22soGmup44o16szYoAop/yNk3/Xkn/obVq1laQstzcXOpzxvF9o2pDG4wyxLnBI7Ekk49MV q0AFFFFABWPrljeXt1phspmgMU7s8yqrbAY3HQ9ckgVsUUAcPdabrEVpZQwrcxRxQujeSC5E2/Pm ALInB5IByOcYqG9mmn1qeN5bnKTlUlW4ZdzFMLGYwQMbmHOD78c131QmztmuRcm3iM46SlBuH49a AOaksL+W8tI5I7qVWtVjlDOyRxHYQxDK4BOexU+xFJpmkXkMFlH5d5HHaafsWE3RUG4Bxycnj0Jy MHp2ropb5YtTgtGT/WwyS788KEKDH/j/AOlNXV9Oa0a6W/tTbK21pRMuwH0LZxnmgDlbDTtZnmEN wt5DZNPEzbZmRiNsvmZJkZsZ8scEZ4IA5rrrtQthMozgRkcnPaoLfXNOu7meCC8geSAoHAcfxAFc eudwH1OKsXn/AB5T/wDXNv5U1uJ7EkX+pT/dFPpkX+pT/dFPpMaCiiigAoqK3uYrqMvA4dVZkJHq Dgj8xUtA2mtGFFFFAgooooAq2H+rm/67yf8AoRqjqt5cC/Szt52th9ne4eVIvNfClRtC4P8Ae9Ce KvWH+rm/67yf+hGi9063v9hmEiumdskUjRuM9RuUg49qqW4o7HKXniO6SRfs+ou4S23x4siBPL5j ptfI/d8qFOdvOTxWjqHiuCx8SQ2DzwJEmyOcM3zb5PuYHtxn2cGtWPRbCKOSMQZWWIwyb2Lb1JYn OTySWYk9TmpF0y1WymtfLJhn3GQMxJYt1JJOc1Izn7zVtStLe7+03RguPOjVYxbhykbTKm+PGd42 tyCCQf1tjUr+LwtqV27MZYElNvNLDsZ1C5DFDjHORjA6VfTQrBJDJ5TFiysN0jNt2sHG3J4G4A4H XFW7q2ivbSa2uF3QzIUdckZBGDyKAMS71C90KVUurr7assbSBmiVWQq8a4wuAQfM/DHeppvE0UFz exyW7BLNSzkuodsY6JnODng9KsroFiEkWRZpt4ALTzvI2AQcAsSQMgHiny6JZXE8stwkkzSKUIkl ZlUHrtBOFzgdMUAVZ9dnt1jRtMm+0sjyvD5ifKiYy27OD94cfX0ph8V2YL5SXCRG4bgZEIjD78en IXHXPtzVl/D9jJCkbCfK7vnFxIHYNjcGbOSDgcE9hU50mxLM32aP5oPs5GODH/dx0xQBj2/jGO6Q LBZyTTtKsSxwyo6ksrsDvzgfcOe449a0rDWotQvJLVIpFlhDecDj92Q20A/72CRjsOcU+DR7WAxn NxKY5PMQzXDybW2leNxPZjS2OnfZLu9uWZWkupA3yrjChQAP0PPvQBm3fi62sr65tpoTmFJGASVG dtiFyNoORkKcE+3rWhpuqG+lnhltZLaaIK5RyCdrZ2ng9flPHao5fDemTzvLLAzF/M+UyvtXeCHw ucDduOcdc5q22n2zNcMYzuuIxFKQxBKjOB7fePT1oA5mHxvFKdTaKW3mEcTzWiK/JVDtbd9Thh6g +1WtYl1TSLSKR9VaQT3EcTMtoGaME87VUHP0INbc2m2k8UMUsCtHB/q17D5SuPcYJGKrxaBYxyI5 E8hjYPH5txI4QjptDE4oAbot3eXECreQyH75Wdk2b1DELleoJGD0FZFrrd5L4ja2+0s4+2SQfZzb 7UWNVzuEmOWzjjPfpXTfZ4/tX2jB83Z5edxxjOenT8ahGl2g6QjPn/ac5ORJ/e/p9CaAMW28bWd0 szRxMwWPzI9sisWG5V+bB+Tll+92yexqWz8Ttc3TxSWUkYjWUkIyyl9io3ylTzw4GPXjtU9z4cgb T7i2tJJYhKm0I0rtGoyDgIThRxjjGAeMUzR/DxsVJuZFJVWSFIWcLCrY3bSzE5JAPXjHGMmgCG38 TXF5e6dHb2MbQXTSK7rcI+wKFOeD7nI68Uj+Llj0qG/ksXhhn+aPzp40LLjOeT19B3rTi0OyhaN1 WUyxyeaJWmcuWwByxOSMADB4wBTZvD+nzWsNs0LCKGMwoElZT5ZxlCQclTgZB9BQBHaa42oG6+yW cxihQESuyqHYxq6qBnPRxyemKzNO8RXEGi2cl1azz3MtqbybMifJHwSw7Y54XriugtdPtrKJ47eP Yj43DJOcKEH/AI6oH4VWm0CwmhgiaJ1SCLyUEcrLmPgbCQfmXgcGgCI+IrfyDKIpSouPs/brs35+ mKrx+Kg8KltPuEllSJ4ImZcyCQ4XJzheQc5q4/h7TpLgTNAdwbeFEjBA23buC5xnacZxT5dDsJUV WhI2RpEjK7KyqhyuCDkEHv1oAi8P3k97aXMlyHV1u5UCPjKAMQF444qt4m0C51i336fqN1ZXaD5f LmZUf2YA/rWrY6fb6bbmG0j2Rl2cgsWJZjknJ55NWaUoqSszSlVlSmpx3R4FrTaxBctY6zPdtJEc +XNKzj2IycfjS6I2s3Nytho1xdq8h3eXDMyL7scHA7c10Fxo19468YX09v8AJZJL5ZuGHyqq8YHq TjOPenWWj33gbxnZS3Pz2csnlC4UfKytxg+h6HHtXlezlz82tr7n3jxtL6v7L3fact+W2l7fn5bn feGtBuNHti19qN1e3bj5zJMzIvsoJ/WtyiivVilFWR8HVqSqyc5bsKKKKZmFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABVDW4Li50ieKzJ85sYAbaWG4FgD7jI/HtV+igDkd P0G4bUw8ttc29ibl5RE11k48qJU3YY5+ZW4ycYql/wAI/qt5cSJdWhFq7RtIvnH5nWdGJzvJYBN+ D8ufQHFd3RQBgWGjzWN5qxtFFtJczrKk7jzUZdqjG3cDnIP5jr2xtTS5kVV+0LJGLud3iDhyVdv3 Zx5idOf4uM9PTuKjNvCc5iTnP8I79fzpO/QqPL9o4U6ZbSpci4bz5Lh7SV53nClxGYxJuAbhvlY8 ZHoTXQ6rBd3enzrZyR3UBZAkUYKlVH3vm3jf9Mr9a2fIiBz5SZyDnaOo4FORFjUKihVHQAYAoV+o 5clvducbb6Dq0tm4uxKJYrWcW6rcFVWTzGMXAY8hduMk46Zqe50bVLjIfztoluZAFuNucoPLzg9N 3OO1dbRTIOSOk6nDpt1AI5ZlcwttecszHb+8P3hk7uxYA1LbaZrLeFbi0ndBK0VzGICMlg24RgPu O0AFeDn611FFAHHx6TerAQLG7W0DxedaG5DPKQrh2DbsYJMZ5K52Hgd2zaTqZt1Vre4eTyWW0Kzj /RH8xypf5ucKYxxu+4evfsqKAORk0Ka2027ggtLne19JNiNgyTKxZhkGRTgAjPI+YDqKUaBcq94F tnhku57WSSSC4ONi+WJEByDxtbtyD17V1tFAHG32malb6r51tC0VpDkGQSlv3IjIAyXz1xxt98mq KQXiaVZS+TeJFcG0V0N3lrh85dg27oVwOcZ6YHWu/wCtG0YAwMDp7UAce2kau1ncJEtxErwSJCn2 jDx5lBVc54IXvk/WoddtptMYxKpaze5zDDLclUYeWM5YsMfNk4JGTXb0ySNJV2yIrr6MMigDkRaz y+DYorO9Ty9qKnnrlhIsoLOXLkMOG4HXsTxVO4juZL+B/tTrGBGA8ciyMj72LtkyLgNx/CcDsMYr ujEhjEZRSgxhcccdOKQ28JzmJOc/wjv1/Ok7lx5Le9c5BJHN1e4vw8UN1F5H73A8vzlkl784+76/ KQODVfUdO+0WVyq3AknuXvElD3eQUYSGJRzgDJTp0/Ou3EEQOREmcg52jr0pPs8OMeTHjAGNo6da WpV6fZ/18jlriCET3klvMrKltFHZxm7ZVBO4Nxnrgjk+3I61b8ICeOG8Sd12GYNAgbO1Nqg8bmx8 27+I1vm3hOcxJzn+Ed+v505Y0QkqqqT1wMZp6ifJbS4OiyIyMMqwwQe4rGm8IaPJKk8VotvdRf6q 4hO14z7GtuimZmdpN3PIZ7O+Km7tWAZ1GBKp5VwO2cEEeoNaNZUfHiub3s0z/wB9tWrQAUUUUAFF FFABRRVDXL59M0O9vYgheCFpF3525A747UARato51SRv3wjRrOe1PGSPM2c/htP51nzaDf3AmuJD aLdyNHtETyIsYQONwYc7jvI9MUtn4nOWScC93SiKCWyiO2Y7CxABJxgA5OcfSraeJrR95EVzsCPJ G/l8SqhwxXnJxnuBQAltpF3bXE7mW3n88wu7yRcl0CqxwOBkLkehPtWlef8AHlP/ANc2/lVA+JbE RJJ+9KShjEQh/e4YLhfUkngd6v3n/HlP/wBc2/lTW4nsSRf6lP8AdFPpkX+pT/dFPpMaK39o2YOP tdvkf9NB/jVfUdbs7HTri5+0wMYo2cKJByQOBXlt1Yw3kTJIuPmJDLwQc1zV7YSWMoSQZU/dYdDV YuEsPHmtddzsyjD0swqezdRRl2a3Xkz0f4Za4j2V9a3lwiusvnKXYDO7736jP413H9o2f/P3b/8A fxf8a+eVQuwVQSxOAB1NdBpujrbYluMNL2Xsv+JrnwHPXSiltuz0+IcHRwk5VnUScto21/4bzPZv 7Rs/+fu3/wC/i/40f2jZ/wDP3b/9/F/xry+G1+0OUjjQkAsc4AAHXk0ktv5L7JEQHGexBHqD3r1f qa25j5L62/5T1H+0bP8A5+7f/v4v+NNkv7R4mVb6BCQQGEi5HvXluxP7q/lRsT+6v5U/qS/mD64+ x3Xh25eIXLahqELfvCqqZFx15b8a2v7Rs/8An7t/+/i/415eLVmt2nEQMSMFLYHBPSh7QxwRzPEo jkzsbA5x1pzwqlK9yY4lxVrHqH9o2f8Az92//fxf8aP7Rs/+fu3/AO/i/wCNeXRW4mmSJFTc7BVy B1NM2JnG1fyqfqS/mK+uPseqf2jZ/wDP3b/9/F/xo/tGz/5+7f8A7+L/AI15X5af3F/Kjy0/uL+V H1JfzB9cfY9U/tGz/wCfu3/7+L/jR/aNn/z92/8A38X/ABryvy0/uL+VHlp/cX8qPqS/mD64+x6z FPFOpaGVJADglGBxUlcr4EAWyvcAD98On+6K6quOpDkk4nXTlzxUgoooqCwoopKAForJsrRp9Ogu Jr67BeIOx8wAdMntVSLUdJnDmHXpZfLxuEc4YrkhRkAerD86qy7iuzoaKoHTgGCm/u9x6DzRk/pQ 2nBFLNf3aqOpMoAH6UrLuF2X6Ko/2Yf+f28/7+D/AAqnC9jcXr2kOszPcx5DRLOCwx14x2osu4XZ tUViWs+nX0cklrrckqRDc7JcKQo9Tx0p8JsriISQ6xM6FWcMLhcbVxuPToMjP1osu4XZsUVmw2kV wGMOpXThSAdswOCQCO3oQfxqT+zD/wA/t5/38H+FFl3C7L1FUf7MP/P7ef8Afwf4Uf2Yf+f28/7+ D/Ciy7hdl6kZQylT0Iwapf2Yf+f28/7+D/Cj+zD/AM/t5/38H+FFl3C7LNtaw2dukFtEsUSDCoow BSXVrBe27wXMSyxP95WGQar/ANmH/n9vP+/g/wAKP7MP/P7ef9/B/hRZD5pXv1LoGAAOgpazoI3t tVWL7RPKjwMxEjZwQyjjj3NaNDVhJ3CiiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAyk/5Gyb/AK8k/wDQ2rVrKT/kbJv+vJP/AENq1aACiiigAoorO1bVH042yQ2xuJbh 2RV3hAuEZiST2wtAGjVe+s4tQsZrSfd5UylG2nBwayIfFImtGlFlIsjeQYY2cfOsxxGWIztOQcjn HvUN34kuHsriK3smF5HHOZVEw/d+XgEqxHzHLLjp3oA3Z7OK4ubad92+2ZnTB4yVKnP4E1np4ZtY 94E11s2PHGm8YhVzlgvGecdyfaqOneKg91a2DQvK+I4pJASW3mNW3YxjbyOc/hWhquuNp07RRWpn 8qBrmYmTbtjB5xwcng8cfWgBj+H4hJp0cIX7NaTtMA5yy8HCr/s5OfwFaV5/x5T/APXNv5VyLahq txO+1X2T6r9nG272/ulVmAGF+XoM45PSu0ZQylWAIIwQaa0YnsMiZfJT5h90d6duX+8PzqH7Ba/8 +8f/AHzR9gtf+feP/vmnoLU8s9fqf51haqkt/qa28C7jGoz6DPJz+lbvr9T/ADp8FqginlA2gEE4 HLMen8j+VeliKHt6ag3ZaXObLsa8DWdeKvJJ27Jvr91zl7zS59P2zI3mIuCWAxtPv7V0cUgmhSRe jqGH41cXTrl1kzFjYm8hiOmQP61DFYSpFGIoGCMQEAHr04qMPhoYeUnTej6eZtj8zq4+lBV1ecb6 90+/oSWcyQSSM6hgYmUKwJBJ6ZqdNQHlAOAMyruRV48sDG0ZqCeyntrdJpU2q5IHIzketOubCaCX aqOyEgK2OuRmul8rPMXMiy15D5qGWXzwC5Y7OqnGE59+aY8ymyuGwGYylI3xj5W5PH4frVb7FceZ 5flNuxnGR0+vSlawuFjicxnErFVHfI9qVorqO8uxJa3Mcdt5MmdryfvAB/AVxn6g4P4VOt/Eygb/ ACmXesbbc+WMKFP5KfzqqdPuRCZDHwHEeAQTk9P5immxuRuzC4K9R3FDUXrcE5LoaEN/Alwr+dsC yK0jeXnzQFAPH1BPPrUM13C+mrEm3dsUFTu4YdSOMc/XvVN7WeOISPEyocEMffpQlrNJEZUiYxjP zDpx1o5Y73DmltYioqwLG5JA8lskbhnA49f1pn2abBPlNgZB46YOP61d0RZkVFWIrR3cowZGIbZk dWXqKr07hY7LwL/x53v/AF2H/oIrqa4vwidQWyvDYrav++GRMzL/AAjuAa3Pturx/wCvsoh7x7nH 6c/pXk143qM9OjK1NGxRWOurTE4aSyRvSRnQ/qKtLNfsoZYbVge6yn/CsuVo25kXqQ9Kp+dqA/5d ID9Jz/8AE0G4v/8Anxi/C4/+xpWC4uk/8gez/wCuKfyFYt7pt3PpmsQrHKr3F/HJGUI3FB5WWH02 n8q3bGJrTTYIpioaKJVY54GBzzVTStetdTsI7vzYI45nKw5mUlhkAZ9G5HHOMih7gtjOWz1CDU5E RrsWkYnEUhbzWUGOIqQWJJO/zMZ9MdMUyCHUH8K6hGsNyLlgREZHcvJwOdrsxXnPGcd+9b66jZOs jJd27LE22QiVSEPoeeDUkN1BcEiCeKQgKxCODgEZB49R0pDMeFbseKpSVupbcg/O5dI4xtGAo3bX 5/2c8nnisu1tbuPV8eRqDMuoTShZVX7OqOzgurDnO1jjJPJIx6dW95bRzrA9xCsznCxlwGJ68DrU T6rYRozyX1qqqwVmaVQASMgHnrigDmdP0S8jsoI9Vilu0bTBAEjVUaIjaWQ88ngYP+yfWhrDUr64 tbl7aV1t1lOyYKpuF3xECQD+IhWx0GVGeDXWNcwrndNGMHByw4OM/wAufpTkljkJCOrEYyAc4z0o AyLCZrTUblJoZVN/eF4uOiiBMsfQZXb9SKo6qNW/4SWBrOG48kTQ7mDsU8rI3nG4L6jBUt3B6Y6i igDn9BS8C3ouPtfI+WeYsGY89I2YgY4OVABzjHFZRi1j+zF8tL3YtwPNd2m8yVNjc7N+5fm2/dYD 2wK7WigDipIdc86zDXF5s8mMLKIZMh97btyBwOmwfPu6Z9a09OtNRgv7WaWS7YSzXPnrJLuVU3N5 YA6DjGCOfWuiooAKKKKAKTf8hyL/AK9n/wDQlq7VJv8AkORf9ez/APoS1dpsSCiiikMKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAymPk+K0LcC4tCqE92Vskfk2fwrVqpqOnx 6jbiN2eN0YPFLGcNGw6Ef55FR2I1OOQx3xtZYgOJo9ysT7ocj8j+FAF+iiigAqGa1huHieaMO0RJ Qn+EkFT+hI/GpqKAKJ0WwMDQ/ZlCNGkeASCFT7mD1GMnBHNRSeHNLltkgktA0a7uC7Zbd94Mc5YH uDnoK06KAKMejWUVyk8UbxugGAkrqpwMDKg4PAA5HYUt9pFlqLo93DvZBtBDFcj0OCMj2PFXaKAK q6baKVKwICsxnHtIQRu/ImrVFFABRRRQB5IO/wBT/Op4pFFrPEx2lirqfUjPH6n8q7I+CdMyTvuh k5/1v/1qP+EJ03/npdf9/f8A61el9bp2tqed9VqXOTkvkkLZhJDoUZiw3HkHqB6j07mpItVEMSKs AyChJBA+6c+mefcmuo/4QnTf+el1/wB/f/rUf8ITpv8Az0uv+/v/ANal9ZpdmV9Xq9zimlD2qRFf mQsQwPY9cirf9pgSmWOHDsUL5fIO0Y49OtdV/wAITpv/AD0uv+/v/wBaj/hCdN/56XX/AH9/+tQ8 VSfcSw1RHI/a4fJ+z+S32fbtxvG7727rjHX2pz3/AJsqSOjKyOzAo2OD1HIP+e1dZ/whOm/89Lr/ AL+//Wo/4QnTf+el1/39/wDrUfWaXmH1er5HJfbk3giAALKsqgEDkcHPHf2xTrPURaszmEOxcuDk d/XIJ/LFdX/whOm/89Lr/v7/APWo/wCEJ03/AJ6XX/f3/wCtR9ZpbWYfV6u+hydzdRGMpEpLPFGj vu4+UDt9RRFdxQ2kHylpo2kI+bAXIA5Heus/4QnTf+el1/39/wDrUf8ACE6b/wA9Lr/v7/8AWo+s 0rW1D6vUvfQ5A3aSNMJYiY5VQEK2CNowOcUs1+ZoZ0aP/XOZCQ3Q8Y/lXXf8ITpv/PS6/wC/v/1q P+EJ03/npdf9/f8A61H1ml5h9WqnLyXitfCZnDCKLAwMb2xz+pNZw4Fdz/whOm/89Lr/AL+//Wo/ 4QnTf+el1/39/wDrU1iqa7g8NUZB4F/4873/AK7D/wBBFdTVDStHt9HikjtTIRI25i7ZOcY/pV+u GrJSm5I7acXGCixrIrjDKGHoRmqz6XZsdwgWNvWMlD+mKt0VF2irXKX2CWP/AFF9Ovs+HH6jP60f 8TGL/n2nA+sZ/qKu0UXCxDazi7s4pwu0SoG2ntkdKxbLwyII9NWXyGNnayw5CfxuU+ZfThT+daEe lGGJY4767VEAVRuXgf8AfNP/ALOf/n/vP++l/wDiaLILswovCty6wJdGz2W6wRhUBYSrHIG3Nkfe O3pz9avaPoD6ZeRzb4sCOdXCLgsXl3g/gOKv/wBnP/z/AN5/30v/AMTR/Zz/APP/AHn/AH0v/wAT RZdwuzEm0e6u/EeoSLFAkEklsxmdDvxHhsKe4yMdsZPXpT4vDc9la2P2VLKSa3EqukgKo/mMCWyA TkY9O5rY/s5/+f8AvP8Avpf/AImj+zn/AOf+8/76X/4miy7hdmXa+Gnt76zmd4JY7e1S1ZWTmRQh BY++TjHpnmrHhbTjYaVmQS+bM5Y+d98IPlQH0O0LkdiTVz+zn/5/7z/vpf8A4mj+zn/5/wC8/wC+ l/8AiaLLuF2XaKpf2c//AD/3n/fS/wDxNH9nP/z/AN5/30v/AMTRZdwuy7RVL+zn/wCf+8/76X/4 mj+zn/5/7z/vpf8A4miy7hdl2iqX9nP/AM/95/30v/xNH9nP/wA/95/30v8A8TRZdwuy7RVL+zn/ AOf+8/76X/4mj+zn/wCf+8/76X/4miy7hdg3/Ici/wCvZ/8A0Jau1UgsBDc+e088z7Cg8wjABIJ6 Aegq3QwQUUUUhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFUNU1aDSRam4/5ebhLdfq3ek3bcqMXJ8sd y/RRRTJCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAxp/F2h207wz6lDHLGdrI2QQfyrz/4i +JLbVbuxi0y5WaK3BkLpnG8nj8gP1ruPFHg+y8RwF2xBeKPknUfo3qK8TkTy5XTIbaxXI6HFcGKq TiuV7M+ryDCYWrP20W+aO6e2p7VY+OdDmsYJLjUYI5njUuhyCrY5H51q2mtaffWcl3bXcT28Zw8u cKPxNeU+BfCkHiO6mlvJsW9sRuhXhpM9Oew4r1l7JYtMNpYxwQqqbY1aPKL9V4yK6KE5zXNLY8rN MLhsLUdKk25deyItU1iHSZLNZ0dhdTeVuXGI+Cdze3GPxpkuu20Otf2c4YMIGneYkBEAI4J9cHP0 FP1PSl1Oa1MrDyYvMEiEZ3q8bIR/49WVJ4UkltUR7zfOUk82V1yZHYxlSfoI1H0rc8k2BrWmmBJh f2pikbaj+auGPoOevNSW+oWl3NLFbXUMskJxIiOCUPuO1ZdroU/9qx6jeSwNMJXkZY0O0ExrGNpJ yOF/U0zQPDsuj3CmWVZkihMMLmWQsFJB+6WKjO0dAOlAG39qg37POj37/L27hndt3Y+u3nHpzUI1 Wwa4igF5bmaZQ8aCQZdTyCB3FZGseFf7Uv5blLp4S6KAFzw/Qtx6rx/nFSyaDN9tYQywrZSTw3Dq UO9WiCAKuOMHy17dz7UAWV1+ykvxBFcQSReS8rzLKCqbSgwfrvzV26vbaxjEl3cRQITgNI4UE4z3 9hWHH4VaGPSvLnjD6dbmNV8v5JHJQ5K56fKfcE57VrXuni8vLCZiuLSYy7WXOSUZRj0I3ZoAc+q2 EbwI95bq1wMxAyDMg9vWlXU7J7iW3W7gM0IzJGJBuQepHauePhCZXjxOksZQJNGzyxqwEjuOEYA/ fPXPSnHwjK8l0klwrQyify3LyFozKSThC2wfeI4HSgDSg8S6fNLdk3Nutrb+Xi4Mw2OWB4z7Yp+q a/Z6bZCbzoZZHUNFEJQDICQMj161lz+GL65nlvJLqBbp5kmAhDxL8sbR4LK248NnPsB0pJfClw1o baCa2iimiiSUMjSbTG5cFSTnkseTyOtAHU0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGX4kuprTQLtrWN5Ll08uFEGSXbgYH45/CuT8 O/DK2jsmfXMyXEi4EaNgRe+R1b9K9AorOVOMpXkddHG1aFJ06Ttd6tb+SPP/AA74evfB/i4RsTPp 16hjWYD7rDlQ3oeCPQ5r0CiinCCgrLYnFYqeJmqlT4rWb7+YUUUVZzBRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU Af/Z --_004_b8602f06445e4c369ddc6c7f2aa49d65XCHRCD006ciscocom_-- From nobody Mon Oct 17 12:28:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128211294DA for ; Mon, 17 Oct 2016 12:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPuELpDtFbcd for ; Mon, 17 Oct 2016 12:28:31 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D099F12948B for ; Mon, 17 Oct 2016 12:28:31 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id vu5so64707689pab.0 for ; Mon, 17 Oct 2016 12:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=R4OafktiK8NauG0naRuWgBY+Nx9/I4ZC9T92RulfNjc=; b=yS0dfwTAZn2UMxoJNIBdFfrSqoM0hqmbDBLR4GbCOOD67a/OHHGv7b+DVgHqCSGUo/ jDp/gDj3C7oyIVDVfJvHuL2o0DhVbjO2pqnD9KoYIm5kPPCecyZxzlxCdhLUOFykXrVy 3LT1IrsQHASurbn5W79si85NDb++6/uYtQxCswZMEUj5tqoWU2OCIV0LySB4gi+onM9Z k7CGe6+L8QfWVasjNF8ydHSQ26MR9mRjyn5SAQPNkXtJmUwFAyV2vvMP0uTCFhQrf/mC oD9dmYFD6SsZFz/sk+v2GVau4b8hOY/LpvRBhO+Ly2ga+6qCr0eY9XVpokNfzpPRdbbx IUeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=R4OafktiK8NauG0naRuWgBY+Nx9/I4ZC9T92RulfNjc=; b=kJwx6rwtJ91YODtw3E6rBulkka+S4KeOexrUhvvCtvn7WTOEBGPBsdI8EfwqyonKUb i1RdP4vVIMaKfpHgeclsjtXDCvBQjVJW5k+fpeU3/OE2iyuGGM3YiOewL0AtJ8edf9bZ phUGTtq+AI1dDwpDHRHZx7CwkUShRq2+vh3KsymqXICiKTRUWze64E8lBAVT6kpHWW4J N7cVqDKUsQv8axN4qQ9UcPdA0NNOrpHD9Hzp3GhyguM5vKcBVLrUhi8ns8sgGxTe8X9H vbqK/9mbB4O6OpTu+ssiM7J2lehpZT4G5XpYE4XKqeAtsReElW1ftH0uFGfEJFyMd1Kj Du5A== X-Gm-Message-State: AA6/9RnVQ+Yk9ALRciSv6ruD1633PWJ10rL9XymazGGU7PwMedMEkNjN2rW3QZeSDZIHSQ== X-Received: by 10.67.5.136 with SMTP id cm8mr32914096pad.94.1476732511412; Mon, 17 Oct 2016 12:28:31 -0700 (PDT) Received: from [192.168.178.23] (147.217.69.111.dynamic.snap.net.nz. [111.69.217.147]) by smtp.gmail.com with ESMTPSA id x88sm7440863pfi.74.2016.10.17.12.28.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Oct 2016 12:28:30 -0700 (PDT) To: "Michael Behringer (mbehring)" , anima References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <0b93070e-c3ea-754a-0a69-9dc61ee83688@gmail.com> Date: Tue, 18 Oct 2016 08:28:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] State machine for an ANIMA device X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 19:28:35 -0000 Michael, Good work, thanks. Why do you have (mDNS)? We plan to use GRASP discovery to find candidate = ACP neighbors, as covered in paragraph 3) of https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.3.2 In fact if you have a more detailed idea of that part of the ACP state ma= chine, my next toy ASA would be exactly that, to follow up from my BRSKI toys. Its description would fit in https://tools.ietf.org/html/draft-ietf-anima-reference-model-02#section-7= =2E3 I would prefer that section to be entitled "Specific ASAs for the Autonom= ic Infrastructure." Also of course we need detailed text in that section. Regards Brian On 18/10/2016 04:55, Michael Behringer (mbehring) wrote: > ANIMA WG, >=20 >=20 >=20 > I=C2=B4m currently looking at the to do items in the reference model dr= aft. One thing I feel would add value is a state machine description of = the various steps. It could explain how the various drafts fit together. = I'm afraid we're not all on the same page here. So I drew up how I see th= e state machine for an ANIMA device, as a starting point, and how the dra= fts would link together: >=20 >=20 >=20 > [cid:image003.jpg@01D2289F.B21C35B0] >=20 >=20 >=20 > The main states of an ANIMA device are "factory default", "enrolled", a= nd "in ACP". BRSKI takes a device from "factory default" to "enrolled". O= nce "enrolled" the ACP draft explains how a device (now with a domain ID)= would join the ACP for that domain. This draft explains how to get to th= e state "in ACP". Once a device is in the ACP, and (!) it sees a registra= r (announced by GRASP), then it starts the bootstrap proxy. >=20 >=20 >=20 > The bootstrapping state machine is being worked on in the bootstrap des= ign team. Let's leave the details of that one in that design team for now= =2E (I sent a mail on Friday to that list with another state machine, if = you're interested). >=20 >=20 >=20 > But my question to the team: Do you have the same view? (modulo the pre= cise naming of particular states). Did we all agree that we'll discover A= NIMA neighbors through mDNS? (I thought so). That we use GRASP in the ACP= to find a Registrar? (Thought so, too). >=20 >=20 >=20 > Also the separation between the drafts - does that correspond with your= view? >=20 >=20 >=20 > Michael >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Oct 17 15:20:18 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA9112947C for ; Mon, 17 Oct 2016 15:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW50et6sxUbu for ; Mon, 17 Oct 2016 15:20:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B0E1293F2 for ; Mon, 17 Oct 2016 15:20:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2FE842009E for ; Mon, 17 Oct 2016 18:34:47 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 21E0963AFE for ; Mon, 17 Oct 2016 18:20:14 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] Prefix management Intent X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 22:20:17 -0000 --=-=-= Content-Type: text/plain I read draft-ietf-anima-prefix-management-01 today looking for a model for how to define an ASA. I find section 5, and I it is reasonable, but I feel that there are perhaps some critial details missing. I think that it's pretty important to be more verbose than you might think in the early ASA documents, because it will be copy and pasted. For instance, I think that there might be a negotiation phase after the discovery... that might involve a number of round trips. I also think that there might be multiple negotiations, and M_WAIT, M_SYNCH or M_NEG_SYN might be involved, such that an aggregate prefix will be negotiated for subsequence division... ==== I then went on the section 6.x which details with quite a lot of ideas about Intent. They are interesting ideas, but I think that they do not belong there. I found it interesting (a self-comment on my clue) that I have no idea what eany of: RNC Site Gateway (RSG), Aggregation Site Gateway (ASG), Cell Site Gateway (CSG). I'm getting it has to do with 3G/mobile IP systems. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAVOm4CLcPvd0N1lAQJ8jwf/YeXtoKwMp7THqRhskCuSY8LCvWBJlXhT XYgfLflTOt1D4T2bkaDDR2Z183cq8w2f8csH6w0w8lHmCnkevYnU/AVmuqPakuvs rgMcfxnjz8SPSpKiRXv4JsSpDjkmpQaIwR9TyrmmMFQajfe1S4xekw5Cja7oS3Uh On8phsFvw23BSTfPYiKw4ZPIhl88ORtXAxTcG+JNdKLSmPRRMTg87dTs1naGz5B+ vNd6BCUJuAJDp74Mdqr6jrVLr7ZCE3Bjmi+jWgSfrTZVCPOMmA6+T2uZVn0U8KGA tyf41Gs7cRFR5x50D71V52a/Wnpqy+iBGpB5YK3+mH3ZUL2NIniLjA== =WPhB -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 17 15:46:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBCE129444 for ; Mon, 17 Oct 2016 15:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KUy4V2dRPfG for ; Mon, 17 Oct 2016 15:46:27 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DC31294E0 for ; Mon, 17 Oct 2016 15:46:26 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id ry6so65687451pac.3 for ; Mon, 17 Oct 2016 15:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=vGci1UjDq0PwcJ1KrwfVj8tWoa42f0aJea4mNeB/bGA=; b=kCoWVylPuxJg0QVReojPGXfysF38bQQ6nJnNMq10MKuO8wSQyv8P8zX8nTMpvOjuDJ azX+5mO1xOjoE2BnZN6Ik1z0hE8Wn/qL8qVGmSFllWvrjNBr0W888EqZNrgBHPOK0SSY ctiSveMnCzmb13L0QwXB3DVrmU/x5DFPbY8FLh1LPBcN1/pWTywlJkdJwObCuZ0dSgj5 tsrkPei/oIDsHIvKmsIuLecnHUuvsWnexL3jWTfJfY3sWmQFsPWy34ZZJuafB+LXbDaU sZQUpW3hbfBUTdkoXk2GxS45D02B0Gu4rFG96eIreT4X/vTr6NYKckFWSWwGS/ruWb4F xjdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=vGci1UjDq0PwcJ1KrwfVj8tWoa42f0aJea4mNeB/bGA=; b=f4NG3mmBM9YmzyT+KNfIHW3xqHsK2SiCNIJrzWUn3w3YRNP7hldaL2858s9Shxz5d0 lQYU1SuTG+g1zcLl0ibrRKBQhzR28W2gAKS7pvjmf2mJemMPq+gIgAmiSiUdEp/VuEz9 dQXCHGe2xRx9U2oCJj2ScM1rPeHhoC41ESdVf2O1n7ayz26y22IaWFG7Q2DzQ3f3JaZX TbRZvkI2WDeyIdcsEKpGLZiP3pyuG1Msf2uxuZcJY/zCPocn3pI3KrYF7fSiMtj6XmG3 hrjuTEnrXWz644Z+ZjDMSOJn53pWT2awWamTyuhbwgr9zRV7J3ZU/7MjMR3AMwUUJ6HZ Rf1Q== X-Gm-Message-State: AA6/9RlbtMZATExBjstQRrZPOB1ILAmSbEPBePfMiXQI0/U12RnnlqszCpcaM2n4TKQBOw== X-Received: by 10.67.22.230 with SMTP id hv6mr33930422pad.93.1476744386089; Mon, 17 Oct 2016 15:46:26 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id a9sm50447039pfa.38.2016.10.17.15.46.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Oct 2016 15:46:25 -0700 (PDT) To: anima@ietf.org References: <28099.1476742814@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <849fe80e-6b14-27b4-2384-cb2bf52eb693@gmail.com> Date: Tue, 18 Oct 2016 11:46:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <28099.1476742814@obiwan.sandelman.ca> Content-Type: multipart/mixed; boundary="------------0A7BFA24797DE84CB4696CC1" Archived-At: Subject: Re: [Anima] Prefix management Intent X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 22:46:28 -0000 This is a multi-part message in MIME format. --------------0A7BFA24797DE84CB4696CC1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 18/10/2016 11:20, Michael Richardson wrote: > > I read draft-ietf-anima-prefix-management-01 today looking for a model for > how to define an ASA. I find section 5, and I it is reasonable, but I feel > that there are perhaps some critial details missing. > > I think that it's pretty important to be more verbose than you might think > in the early ASA documents, because it will be copy and pasted. I'm sure that's correct. I think the best way forward is to code and debug a toy version of this ASA, which any competent Python programmer could do... not sure it needs to be me every time. Then it would be fairly straightforward to extract the missing details from the code and turn them into English. (This is also the motivation for draft-carpenter-anima-asa-guidelines, so comments on that are welcome too.) > For instance, I think that there might be a negotiation phase after the > discovery... that might involve a number of round trips. I also think that > there might be multiple negotiations, and M_WAIT, M_SYNCH or M_NEG_SYN might > be involved, such that an aggregate prefix will be negotiated for subsequence > division... Yes, there would certainly be a negotiation. This is the classical GRASP case, actually: negotiating a scarce resource. That's why I chose the money negotiation example way back in early GRASP presentations. Slide 14 from IETF92 attached. The only difference would be that instead of asking for $100, the initiator would ask for a /48 (say) and settle for a /52. > > ==== > > I then went on the section 6.x which details with quite a lot of ideas about > Intent. They are interesting ideas, but I think that they do not belong > there. Well, Intent is part of an ASA's dependencies. Where else would we document this? > I found it interesting (a self-comment on my clue) that I have no idea what > eany of: RNC Site Gateway (RSG), Aggregation Site Gateway (ASG), Cell Site Gateway > (CSG). I'm getting it has to do with 3G/mobile IP systems. And it shows another thing: ASAs will be defined by subject-matter experts, not by autonomics experts. Regards Brian --------------0A7BFA24797DE84CB4696CC1 Content-Type: application/pdf; name="p14.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="p14.pdf" JVBERi0xLjIKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nN1WS48UNxBWQkjYBsFCNg/Iy8fuSGNcL7t8jRRF4gbMLeREQiS0 i8Re8vcpd7u73bPLBiS4oFntlOyq8ufvq6rxaxc8uFA+9fv5WQeufM7/7TCxT5pdBPvOyQmH 4BLav/N/uhfdGOae/FENC3jdwWTXr+dn7rd99/BJcpYhsNuPQT5nlaxuB24XnFD0kbJLIXpA tz/r/uw/G3bsswbE/vNBQvhr/6j7fd897gxl1pzENYaGkBRGHG/fvQJcdhQbZDGkikzFbp3R oSZPK7KSEwOxQduBxwz9tWJwitx/UbZjTizQXx+CT0YfS//l7PlV2U85sOb+xrQYCPuj1Xz2 qvpGncPK8s0xWY7I/a0mx7PzAY1YRehvD0TkQ9CFrOTR/WdqPlqV4ihFSpfyoqjDwKOgT99F R2xFjCCVKtbo1UQEzF6jTlxdM8xRA8dUeAGfYmY0WsDb5TKW6wVPHFWkEDM73Jg4pARt2NG6 ahRhSnYelquCz8RkKFC9Hfy3HXzTSBEp1XOriTofduhZUhhPFk9Cko22aCdQpta3HoYxbzDc 2dQiQBq5FDEy9YDK92YQSEcGJamXOBF4PFKVmfq7DaBSIeV+xtuMeVxvQbfr6w3vrYFfT7dS XlSwv6pCCsyzCi0F5nw0sCeQEA9EsMpD6+kLIrCmDZZLREBLNkEEK+i3XWiFcCCCe9lBglaI s05Q2oVT02P2QaWtT10oPhg8W8MEaxjIdbd8F3cEjL7IQ6E6g4KXcQHHfZqOZJjSYUg4BUBJ e9q9+LVbptFiTGMWN4eRTUE0Wtohe+X4MtwHszXXokK2YgIbcAH93JV3hh0ZMLUiOC6kCghC HTsClOtgmpZLs+ZsHXHXeplCAKhj72D72OqCNeSitpVCANu8N1qsasUmnnOO0qY+mUwrohbH N1Y1mK0t+m/HcIqx/248RSzR92vM/TXmwXg4Ql5mYFrqg3lu0qo7K2Q/UhInXZ52NrllWpJY fagV5NQWLAsVDxP1ajE5XCKmfggxGScxjR7/MbUs22g5M8/RJdFJITkl6n8oHZzUOKuqF+JP 1jw/rmZz0MlFeMWeqkWFarUUuRtMP43VYBSYZTeN5Ue9venPC4DrQzL0hLmpm9tD8264VCyQ KrTmD9x5kOIi1ifWeb9c1nkP1sWLTUiSttOUEm+nKWlopykl2U5Tsp+Bw2mKItvWNhUPWxuV t61tD6tta4/Gu7W2/fB9pDlN9MnOabfG3L9iTrdv1ZfL0+ryZ+r7v63EIJbXKbMH/t/XaZRE abo3GNw4v5tEyVyZySuvr+zH3RsW8oaFZW5kc3RyZWFtCmVuZG9iago2IDAgb2JqCjk4Mgpl bmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90 YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQov Rm9udCAxMSAwIFIKPj4KL0NvbnRlbnRzIDUgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9U eXBlIC9QYWdlcyAvS2lkcyBbCjQgMCBSCl0gL0NvdW50IDEKL1JvdGF0ZSA5MD4+CmVuZG9i agoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVuZG9iagoxMSAw IG9iago8PC9SNwo3IDAgUi9SOQo5IDAgUj4+CmVuZG9iago3IDAgb2JqCjw8L0Jhc2VGb250 L0pCRUVJRitUaW1lc05ld1JvbWFuL0ZvbnREZXNjcmlwdG9yIDggMCBSL1R5cGUvRm9udAov Rmlyc3RDaGFyIDEvTGFzdENoYXIgMjAvV2lkdGhzWyA1MDAgNTAwIDcyMiA0NDQgNzIyIDI1 MCA0NDQgNTAwIDUwMCAyNzggMzMzIDUwMCAzMzMgNzc4IDUwMAo3MjIgNTAwIDI3OCA0NDQg NTAwXQovRW5jb2RpbmcgMTQgMCBSL1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKMTQgMCBv YmoKPDwvVHlwZS9FbmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZl cmVuY2VzWwoxL29uZS9mb3VyL04vZS93L3NwYWNlL2EvZy9uL3QvZi9vL3IvbS95L0EKL3Uv aS9jL2JdPj4KZW5kb2JqCjkgMCBvYmoKPDwvQmFzZUZvbnQvUVBIWURCK0FyaWFsL0ZvbnRE ZXNjcmlwdG9yIDEwIDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDMyL1dp ZHRoc1sgOTQ0IDU1NiAyMjIgNTAwIDI3OCA1NTYgMzMzIDU1NiA1NTYgNTU2IDI3OCAzMzMg NTU2IDMzMyA3MjIKNTU2IDIyMiAzMzMgODMzIDU1NiA1MDAgMzMzIDI3OCA1NTYgNTU2IDU1 NiAzMzMgNTU2IDUwMCA1NTYgNTU2CjU1Nl0KL0VuY29kaW5nIDE1IDAgUi9TdWJ0eXBlL1Ry dWVUeXBlPj4KZW5kb2JqCjE1IDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5n L1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMS9XL2EvbC9rL3QvaC9yL28vdS9nL3Nw YWNlL3BhcmVubGVmdC9uaW5lL3BhcmVucmlnaHQvTi9lCi9pL3F1b3RlZGJsbGVmdC9tL24v eS9xdW90ZWRibHJpZ2h0L2NvbW1hL2RvbGxhci9maXZlL3plcm8vaHlwaGVuL2QvYy9wL29u ZS9zZXZlbl0+PgplbmRvYmoKOCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRO YW1lL0pCRUVJRitUaW1lc05ld1JvbWFuL0ZvbnRCQm94Wy0xMiAtMjE1IDc3MyA2OTRdL0Zs YWdzIDQKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2NzcKL0Rlc2NlbnQgLTIxNQovSXRhbGlj QW5nbGUgMAovU3RlbVYgMTE1Ci9NaXNzaW5nV2lkdGggNzc3Ci9YSGVpZ2h0IDQ2MAovRm9u dEZpbGUyIDEyIDAgUj4+CmVuZG9iagoxMiAwIG9iago8PC9GaWx0ZXIvTFpXRGVjb2RlCi9M ZW5ndGgxIDI5NTA0L0xlbmd0aCAyMDk3OD4+c3RyZWFtCoAAACAIIDQAgAAAwAUCeUxeMoJE QAcQ5ESsYzaYThEoIb0pBACYjGdjoIH8MG88Ii3IIB20ZjgZzaw1MHYGAAQuIIBhiZzYeTNH AAHjxBBsZDQZTCZHI/H4xIIcwRERsaKSYQk7wsfYIDnZERIaDadKLHDidJAdDYbzGYaEVJYA A0toyeDgFBcBlbBAeEIiIDcYTaZaEcHxERCcDec7RHDk6L+cDkZTgOXMyIMAAeML4RQKjoIB SYAA/ogAHAHHw3BH+4dY5NY6H8Sn+/AKawAI38an+4AGE4je4JwoiJQAlgAnwAJAA8ACMQAw gAwAASgApgAQYWAI+RwAzwArwADgAeQCywABNyACIAFQABKAQ+AAEACMAAuAQKAEyAGyAAuA AOQAHKABwAAFAACWABvACCTlgAIoAI2CwAByf50gBCsFkQf5cv8AAFAAIYAFcABdACNgAimA AXxGAAkAEFgAhW+AAEef7qAvBB/maf5sRsTsCACEh/ljGAASEcwAAiAATgAP4AEiAEHjUABl NqsAADEABTgCPgAwyEIADAABFgIGgCEUf7cB2ABagAaoAiXNgACa8oCmwBM4DZKQAFGAL8mA f5vn+c4AF8AiBsJKJBAARD+AAWTpgEFwBiGApQAAEAABMAAegAJwALcwg9v8AIJueAYgH+E5 /iEf7+1EU4AHkAQVgEYwBgPJgARqJIAC+ABGgAULwgAawANgeoAgWAIagCToAlXaYAmiAJ3T yiMFjqAA9IPJLry6ABWAAXLnueAQL3U+j8AAFIACrcBHgAUtJAAWYAGhOYAiyAJgACYIBlKA oYH8H5/gof4K0Mf5/gAFQACxSLlGDZQAHoAIYX7apVgGEQBjoAgPAIOgChkfpAzsAAyAATl9 AAaNkQZAgAHqAB8ACFWdACcIBD8AQ/n+K5/lQf8CoIqb5hwAAogALQADeAA7AAO4AFE6bogA qB4gCfYBATn4BGeAhigKPQCngf5JSpToACFBQACfpoARZlpFxLe6dJ1ZNmAiAIQXQHAAicAI pACM4AkeAJLACXAAmzyABAMAQQgEOIBHUAZYAGZYBm4AgbAKAp/h1tsKg80j1iuAA0ABPo/U eAG2Xs95igAZIAgqAITACFuNACa3IACewBB2AQieQARR7GARvAGQoBkeAjbEMfxwH8dZ/H2f 5FABXj2u9idulVi53gCC3AACFIAjUAI5gCcexEgARaAGBwBggAYRgGGoBhBAGFQAYWQBiINS AMZAAxnAEDkAQVYBBtAFCSAUMIBRVgHDCP4Nw/hoj/ToIQiJAwDFDScAAFgAAaAABulsABQU rG4T6RsjaAw+AAZU940CU22KaFWAAnQv3cJxAAN0ABX2MkCBC8ANL7QAhtS+AEQoARHRSACJ kAIrGAgBGKAF3I4XiRfeKCIAUYgUACBsAIH4AghgCCMAIM4AhCxwAEJQAQ0ABDWAEOgAZqAx gDD+AMQEgABieAGLYAY2T1AEkUP9k8jQkAFEWAUU4BhlgHBQAcJABwxAIGYPwdo/QVD9CyP0 bw/gAD+A0P4LY/hLD+GCP4c4/wrD/DyQJGwLQAAuABDUQ6fj+rGXsvZ8p4hbAAGMAAZgABrx DiKrUAIAj9KBACBgAII2eIzBiAEH4AQjgBCTN4AITQAhRnGAEKs5gAhXACFqdYAQwkhACGie IAQ/gBEAAEQQARBgBEIAERoARK0AoEJiKoARSgBFSAEW1CgAi3ACihFCchvgBHMAEdQAVbLt AEANdQAgSgCBOAIF4AgcxqpMEcAQTwBBSpXG4AQb6XgCDgAIOQAg7NiFOAIWYAhcx3N+AMEo AwWgDDCAMOIAxMgDFcAMYQAxqADHyAQAQBAWAEBeAQHgBArAEDOAQQYBGyDRAINgAg+wCmlM 8GgAongCjCAMBsAwNADBVAMGoAwmADCvAMOgAw/ADgGAOFCTQBw+AHGoAcf4CDjF7GOAB8qc ChFCBeAYZ77wCgUAIHgAQ32XAAAwAMOABRDzmRs5SAQbABiOAGNIAoZgAjwAG4EbQARFADDS AMNY/xRgDjaPgAYbwAhWAEL8ALIDSg6AGUERgAB/rTAEz4egAhzgEd2FQAQ6QAgoAIJGhtL1 LuTIkAUad1KvAFMgfSZYOgBB9X+AIYoAxB3wH+L0AAOq1gBG/WsATMgQAEHAAI4FE2ACHAEJ ciIzgBBpAE3gLCaACj7ABEudgqQCh4nwAEHwAhEM6qcAQTyBH9gCHna9xi3gADNACEoAgJAB BepItM74AB+gBdSO0AIcUJ0AAAEAAIuwAjdccQIAIqABpeCYAIBk/gAiwAEA0AINybjNAHEm p6IgskSd4AJ3YUABDwAEFUAYvADDQf6AEgY0AADSW8AEAbGpd2RIJKYN0LTuUgV8hFlY0wAk QAwADAx2h6D+F4hhDSeZIJ+FCAOE4UgAGcC6AI9Dpm2IFQKxMQwACIC6UipAGAAhMS7H/Pdl qCU7mEPq49KwL1mq9PyQRKJ6gLRjXEsIghh0RDKReEtbDVXAMYX+ggAmtAACMAIhI6SZVTN4 bwy0LrWmXiSAMLW8TclAkEAISbD8ySWBePsAAcemC5AAB4n5qAoaqHZU2ABYGOGXicH8EjHe 8dLjLmeAArjpgfAASsFAAm8F4CWH+lbAwaUDAANGasZOER/4GCHfMAAUh/iDH+3gL4/xQj/Q CGdurRWINTH+pMGwABDgFCyAIKwBQVpoZo7kqG8BtgBbwvneFs30nxz6OoAHOETEEB8AUXYA BFAEmWixhAjB/jVAABVBAAARKRS4dY2AbQADuZqEgAZ1AZj+CcAIWI/wjWgTxZwKI/xTj/A+ AFEQaB/p9bmLxeoBz9w9IQB4Aq9jjJnDMAIznBF4PpRcQgLgBTlY7CEFUKgQAfg+B6DwHYOg cg4BuDYGoNAZgyBiDAF4LgWgsBWCoFIKATgmBKCQEYIgQggA+B4DoHANgaAyBgC4FgKATAkB ECADwHANAYAsBQCQEV/AKASjhAwWBFBGEYMAIBYAmDALAAgJgRhICR5v4wRgRhh+UCYMPzvo fS+p8f5oIPsCw+R9z6P0/i/H+uLAEHyfl/b/F+b736fyhA/GGb5vz/z/f+t9sID9z7QWD+z+ T9AAICAEDcYHjzYED4z5QZoIgEYEBx4LQKILECIWARsCALL5QdsCsC4JsDT5QSEDz5QBsDQE IEMBcBgDANAIj5QAL5IIr8gOwNARQIoMAIjzYAIWL3gIYEYIYMoBTzYAAWIBQBcHwIYBcIYW AC4EYOAWJQIHzJcJsJ5dQIoHQWI+oBABr6gWADQEYIkGQDMMEBcGSoAIopYWAKECoIoIgDcF ALLzYWAAIIYMYEYMQWA3IIQWAB4FcMsPIIcHEHQWAAwIYWAA8IEIQFgEANMAT7ZMwEAWIFgY ARQRgXAvwMQMAFYBgMgEYMgMILgLBzgMMOL4oWACIFcJkMEJgPQcgDELsVEVUHIFgWACQIYL AQ8GUWMJoIkVgcgDYAcGwDANL5UXgRQRQQ75QUECsU8VMXkX0N8XwLILMV8Wijz5ARQI0RwR j9AJYKYEEULJgQoLMUSKEUr5UM4WEMcMML0MAIoMoEYIsdAEoMANT5QBIEYIQEcGoNQMD8YD QRUPIKQPIEIWQDQDQIAXI3ouUeQRQKkCwEIWAH4DYEYLIMIIgDgWICjoEgYWYDIIAEADMhsh 4EciMicisi7zYWICACMJEJQFgWIBwB8l0lQBgBsmkmEm0JAMsl8mMmcH8nklUlkncl4JYKQL ENsN4EMUpwBzgEoEYJMAT8IMb5Th8CzJgEoHAEcrAMppgRQMYHEpUFEpZ3wFgJYWAMkNkRoB MQIRQCAHUpQCEpgWAAoEoCECIRRm8OYMAEYdodkQcusu4EEvIAEOYMMvsv5GcQkuxm8v0Bcv cA0BDcUx6d0yMBMOQFcVIFQFUJcREQkJLzYHwWEzbzYGrzYOwXAAQWEJ0A81IWEeUPIKEcsU gHQF8asFETkTwRYXAIBLbzciIQECs3IMk3ZTgMQDZSYIAF4FYLLJgME34WAYE4UTs4gXACoK s45SYQE5c5oAU54Fk4c3c3sTMkrzYWiWwggCoWABAE09c9s9k9wvoCwCYIoNAHUOYC0809Dp M90/s+E9k+U+gpM+59DzcbwEYJYKILQLEBgRUHEpUUoJch9BtB8OFAwKdBFBQLEsNC0s0h9D kpcHVA9BILUrD5wEsxYJMeMYYKVBdEyj0ugEr6wIoNIMAJALMscOQCcW4AYDYAUUoWFHYLAA UYFCIKkWoIYLlBdEFIEW0UIBlE9E4A04YpYXAA4BEZgAlFFLRwEbQCFGwEFL1GwLIBUFFCEO VJwLFKFLVKVKgMlK1LEUVNlLlMIXAf4eFMAI1O1PFG9MoENM8s1DFEkUQHQFdQFEdDQWAHdQ 1DtRFEtJ1JdQABi2tCT7gAVCQLUY4BVJFJVDdQD60bEbMCII1BwRQMNOwQAMUCMu4RQXIAYL FV4RQOEG8qs2Uw1OwXQRYDb8gRk5tL6eQHUlQ+oIQWKawRAKIWLHgRAKdBYXIvxTYREh4WSa CNQMAIQLIWIEgANY4LAXJTjHdaILFaYAVatYlbVcNaYEFcpBROco9aYBFcoLIDYXM3og9dCq deNegggQAMZx5R9aQAVeEQNa9fQgdfo+te4CFfM3o+tfo9Ve4IFeMacacOSNUh9R1T0OEsVE LLAloEIfxCQK4vwfYOgfQb9Z4m7OAjjZom4BpqAeTcRcJXg+ovxFwKwnYEphwAA/angACAQd gWYAYFQD4H4IICoAY2AMAAZDIT4AZAob9pw9IAB/Q2B/RAoH9qIOFpC5lrZ0gYAAYcIWYIoI oGQIAXFsAWYFYF1sts4cIWQFAFIGUhVr9twDQDgGQXtsAARcpJ4D5HIAYb4WQCwDduVv4bwW QIQIVwtr9w4GwHFxYAYbwWczgGQb4IIBVyIAAd9zKjZ56zhBNv1r4b4WYFFtYeAIIBtwAgQA Z2IB7Mx1QUAAaIhziIg+oIAAYbQWYEgEwGQT4X4AaZLNgZQAbhJlt0N4gWQBoCIGVy4AYY4A YW5toD6QoAZOF41v4WoWYB15Y7IOYAZYggdr5YjMhYg3xYi2BYg9QN7IpKF9gR99gV99g9QB 99l6ZWgF99gJ9+QAZjyHtzZewgd+he1/Be19Ze195ew9SAR8ogYNYAeBgAbIhKzpt6YRg1Lp I0gAYRYAYSeDF6YUmDjcN6YUWC51N6bRODuEwAdpoj+FQTeC4DWDITWEOFSpIj5Ct6YTGC+H AAYS+EI1d6YS2C+IAAYSuH+DIOwAZbuGN6YOmJWEQAd2IOYWQDwD4CAIID2EIEGEIGGEIhWL Yj+Loj924j4hQhIj7Ni+JPuFQWIAZPoiF6YNuNzcF44PoWQEIEdyAPoWYC4DIGQUF5orhzgr lr4rjMgrgAlv4PmO+PNuYAYPmPmP2QCoaGpziGtr6GrMiGo9WLoObHYAeTw+ohOTx/WT2LeT whQ32Ty2GUMwuUA6eV7MmVAAAQmV4SGV+KQhIAYO4AZKxeF6YROXtt4D9swAYM4WYHIIAGQH 4Xa5KW124M0jwDoGQR+ZooIgeaAWYBIBVti5ObQB2buaIBIB+ZeZowmbAAYMubQBmbudQDWa eYudQBOcANYIJ/AMYAAPYAefA+oCmfY5ef4Gmf4Imf74QMYWQEgF4D4XQAZUQNoqYIABwD4P 5oKPwAgP74IGAIhB134iAKAqZ1QCSoTcWiAFID4L4HjJ4MABIOABIQABJ/IBIEABIGABIIAB IKABIAt9aP994Ad6d/FrF/QL4AYAtOwYAWQA4HQGeo4IAI4A2pYSABYUABYWABYYABYaABYA sQgYDMYAwcAAweAAwAoEAAwGAAwIAAwKAAwMAAwOAAwQAAwSAAwUAAwBOugSAA87wBYOABYQ ABZ/IBYEABYGABYIABYKGrYD4A4AOQB6JLgm4AZLh/RLlrRLmW5Lg9S2BYQgeLbbmLZYWLpY V27bg9QhLbghJYR/RYTMjbg3xYQ/Z/QB5TYAe2mLu2jMm2g322g/YhO2m2Yhe2xMm4drW3O4 aEe39qe4eLe2+4e3g5u5G4ZJ4hI8mLo8g+o3w8i2G7B+46pAwAYgy2AgyjYgxJ6OwfiW1hW9 NdW9LLm9IhW9BAwAW9OUW+lqe++9rRu++95Mm+6Ea/+9LL2+pTe+7Tu9NiO+G+j+wE4YB9gW B9gUB9gSB9gIAHlotsoEXDACXDgL4EYL4EoL4FAL4UoAgN4EYN4EoN4FAN/EoJ4EYJ4EoJ4F AJ/EoH4EYH4EoH4FAH/EoF4EYF4EoF4FAF/EoD4EYD4EoD4FAD/EoR4JgV4JgX4JgZ4JjYIJ gN4JgP4JgAYG+o4WYWQFYGAGXL4WQEQEvMhHIWoWQDIDQGQG4B4IJ448QgYL4AQ8QT/O4AAb /PQhQD/PSkY8SNI8SmA8SqQV/PXP4vakYvaNIvalQvfOwvY/fPgveAIAQvfRQAHRxYPTA5PT w/fSXPfTw+oB/T3TXTghViIVgWWpYJ4IIJVvfTpcvPJcohSkZcqNJcvUvWXXQ8PWQhTJhcq/ /XZuXWXOxcoUHYA0nWXXHTfZd+hqGAIAZqF6ZqFrBqGohqFrRqA/YZ4AZ1lqB1nUvcGDJ1lr R1l+J1j4QLXancHcHTHeIVlvbRQIABoGICo+YCxCogj2oBGK9hQBm77Jw946zJzT/gwAIRPg abXhgEmiIJQBoe3iIX3iIQ3iIE/igARBI7TJwj/joAIEOxF1AWl1HV4BoFN1AINhRHZMYBrL QAHly8HlwAIdfmIADJxUXmgFgIACgEIBofPn4efn4ePn4Tvn4OPn4Hvn/lYAQio+fl8jfqAA QBZ1TJw5HqDFPqx3mxAD4BoY3rwK/rwG/r11AAITwAPjpt/tPnAoftggwDft6jAWgB4Im2gB LH1mA9vl4AIWQHmk01JSXv4D5x7j4HgIPwgAIf3vwI/xIfvvwT3xIfXvwSYD4XgAIfIAN1wg bs4e2hAcgD9owAJjIJJRQ0gALEf0vzgAJrpYCHrs45xYDjTs47GlI4zs4UnvwQP0J3ZQF1wT X05rAEQBH1ZYzfn1YT6cH4Ds5aX2X04TgWQFgMXxITf6IPPywAP4BGf1YS/6P0Bx4Sf6IRPx ISX6INnxIR4WQEvyLVHv1oYIJv7jTFn1efCj/14AIJnzX7P04JCbx14gAAD4BI6yFiJD64AJ FgyehIBIkGPMPIayEYxh4nWQ8QIfXgBEYAKABAMCAIfizkD5BCoBDoAEYBTUmDkwBElgYbAA lm8mBwBB4EnABBoAEVCkwIi0dhQGWgllT3Hi7AIlgQAetAWUOccfJIBK1XcQBJKyVYfaK5sl CWQfZ4shQlWwfZwjXYfYokhRWtrAuE3tq/uACAK1D6xEkqWFqJOEuavFhnD6tEa4wAfUuVwh ABYfT48FofTYjLQfTIlXGEtqBFi8pAfABtoFgzgfLIsHwfJg8s5G1EktpAHlxIAKD46EZyD4 53gfHEKJKzs4xvVsD4w1ACVdzFWJD4mytgtpVG66AQ1AAHAJ1IAsA50A5iA5WA5RA47A4zA4 tA4gA4OgODgDgoBAJAQCAEAcBAGAQBQEQeAwEAIBABAQAAEAoXB/nAIAVgAACSgoAwIQ+koD AJEoAAJEkQAACABRTGEUgAwkKAAJQAFgCYBiWAQlimIQAlgCQlgAJYqCEWAbhWJZcAOf4pFg HEmFgBAoC2LBYpIRwsykFZYAERCFAAKgsIUf8tACRxCg3IYhiwXMQACF5CkaDc4pIPk6iyLI AiWWBgDHIwxBAWB7Cm8IFCiLRYAKEYhAwAALDsH4MB+CQfAiHIjCJTNN07TVOU9UVQjBUFN1 MFdVVXVgVgxVtYVUDAOlgS0fiwWBVA7LoZVuWB/13P4jimEAuTgAQ4gEN4iiIXIBDhZVmCzO AAj1ZAiilY442qIk+WFYljTiEVn2ZOIeXJbtqFmo1sTgowAlnbosz+JlwWoJN2CIWIRBFaVq GEsl2sYAJhXlP4z3tOISWvZqRYZadnA8AASYFiYBA9gzUgDhKgXzfd+3SXIGRAB+BKBkeDFg Dl7FiEoS2YWIWZfdJYhvl9s5aG+UlXlmXZgEeZ4gAIsp3ioS6HjKSZ7mZYhRoNjwtm93BLCt 5Vjq+sazrWt65WIyiFruw67eAwm4MgxiKMoRiKMG1jLtu2FgRY7DQDBYEBQgQFiMhubTtdCg GEwwDEMY0cAEwwjKWBuBGMoiFgMgRiJvQw7RtQi8PwfC8PxJYDHxvHjDyRYgBtEyliMYgccW QwiAMIihGMNulmUw/iGJe/bZt24DAWBE7pu28BBvQhj/3PM8JwxYcDzo/9AWAh8lvRTdxy/k c35fEcUJfnlN0cjCL04l9UiJTCAU3YdleYpSCJYoSzCwhCyIdjFj+IslmAQFgUCU3jABsEIW QhAWAgHAHybk4A7BCBgPwGxdIoACKgAACwVpdAYo8WADYMP9TgC0IMHoHIoRRBOCosAHQYAf BtN4uYGQKgdBGEcFEugQgwBFR4AEPAYCKGkIkO4ew8h8HOIQdIhBzDoHUOoK4hxHh1DyIaVA QhTT+EZRauAeCwB4EUWAQFTJ9VZEiMEYE3hAAgL8Hgz1zhvB4H8HgjweGfFeDwAsSH5hYCAB IX4IhnrjC+CIN4Ig/giEeCIT4IhXgiANHR+gWBbHCkKO8EQAw6hZVUAEOklw6LMiXEiTUmpM hEiMHWIsQgARgDnGBVUYQVxJTeEEETpQBgtRaAOWIAEdyyBHLUGctQpy1AKAAYctRpy1HHLU ectUUCDlqJOWoo5aizmRLGWIRQMQ8kvHQFcKwAAYAGDIWYMAagyOfN0WYYQzTiFxOQKYWp0T kCKE6ds3geBBBkBidIMhZA/BmAoIID5uotF1P8ZU/xtT/HVP8fU/wCzdm7NSa0SVWhZDmAAO YKwAyrDrDhVQdKNRKBWHSi9GgAxFkvRVD1JqO0jiJRaSrXUQSnopROH1MaVKtorRSVaqqTKx iMqpD6HzCE1AAAUDkvwAADPSAAJosTCC7AEL4AABj0gCF+LKoYBDUi+FpUgBQB6sVPFqSUDI CADAFF/U9GlRwAgpAAAkAIawAhem2CsCA9geD9B4E4CA9AeBNrwAAH9dweAQH5YIGIMAQgRs SCWxIIQAgcRQPwEAAxgD8CBL8fYAAQAEGAi0eCHwB1lDQpIAAlwgAUCABgMAGBQAYHABhFAG LUgCDsAAQyNAHBBAmAENIAQg1tACKAo1are2/JvcIkKIB8AAAfbxSVvkSjyCAT8B4DwBAJMI AUBKCwBVIF0AEe9agkx3AcA4B4QAIg1BgA8P4DxIAPFAUEB4GQLnmBIAEclc69D0C6CuvoEB 2jkAgDywAPLAgRAkDkAKmisDtH4AEeqqrDgAC6AEOIXQJglBmBECgFgLAXAqCEGoPjzgRBoC cEx4ARAHHgAEJQIQJg8C4P4AQYAcAWq6CUDQJQhAEGOKEfYhw5A4A8AJlwAgOgxWsNwSgKgQ AeNhWkEFoBcgFtGAoABRRrhABQBYBrHQigNCBP7MYAQVAMACBU9QAgDABAGAkAubQCAMAWUX OYDQCAGAYA0BpCgOR3AOhgA+gQEADAIAfPSFgP5fAaVQTlUYJgBE+EABoBQAgGu2AZCIBc5g MAIVRfFSCbhmM4AkBM/tJADFeAO7pCh72pACD9FoGrmABDBfAB44J/APAMEA9QBwMgOu+I4k l+q9hxsGF0OI9gu19v5sgCA5gIV/B+D8HIL8B7ZHbtMOQPFNKawXgkQ4LgVgED6BAYm4Qc3V AfhMOWFdlByzSCOG1igagBw3vTNwuRbClH6MIAQdQ3ClH9fcegjh/CaACGYQAAxBD8EYAIUI /Qv1ARch8AqjQ1gAJqB8AQGKmACCGmWO5J8igeJeBwDxNQOkD5WAICgvgBjiAABfmZ6ebgK5 mEAC6FOVADAeAgDgFiXgfDgAEQAATCABARdZCwL1L7XC6M0aAzQXgvwQBcHOAB2juHYnPq/Y dsB9EOMQYgEOyjEsOBsIAG0E3VAaBABQHgEgfCgCEAwFQHgTAgBoCIGgNgbA4rMAwIUNDAFk CUGvhh/jAm+FgGnjPHArBd5Hw4sgU+L8OLMEAJvLeNFmBoD3n/EAX8140WQFfTjACAJcCAEw aANAeAvuQHt1hKAeEYCASQPBPgCA8K4EAqgUCwB4NQDwzgQDQB4OwEBAAEEOA4RQDxD9oAkI kDwiDRAPE2BATIERNgeFyA8XIEBegaFyB4ZYDxlAQGQB0ZQHhtgPGwBAdYDx0AQHQB4fIDx8 AIB8gOh8gPAWNTglgNgBAPgPCSQFEYAOgPOVgEgHAFANgEgLAOALgNgLEKADu3AKsOANgKg8 APAHgIAQAIOVgOARAIgIAKAIg4AIsFgIAHryjUhkr0GLgKABGLgPgOhSkPujukjCCFBaggEG QZgBgKsPEHrtgOCFB9AgNTwYgIgBBSgHL0DUgYBZgnwFgPDUh2LpgQLpgoAHB4AHABgHBTgQ A1hFFXq6gugMgNB+guh2gMANMAAIQ6MCtssDLBr+LBq8PotyACtzhiBDgugHAXFXhDxCBiFX EXB2gAgILOsARJRKRIxJxIRLPqg+hiAeADgeRPgeLDsLL+mrgAt3k+gQtEAKsOsQMRAbAbxY t8AAsPRXgagbAbAasTgFruhUh+h5guARAdgxB/AqgqgMgZgfAAhuiYhsAcgugph+h0gogcgU A3BzOvhjBrAngTgPgXgDmXAHgMAYBJgCAuB9hMBEAogCmXACAXAQgWAviiABASB+huESh/hy h/h1AChVACgmAAATgAhgggAlhFAJAAgJBHiSABAgAngahHjCAJAOjCATgBAWgJgcAJg8AJhM ABBvgBB/gBADgJl+AJAIAPgNgFAQgRAQyVIAJIyVAEgQgRgKSVANSagJAJQYwdgRAJARAKSd l+CFBRMxgThWAAgFNTOlANgNECgEtWQbQjAJApgIgIwTgYAIIyABgIENBwBaSrgBAqyvB/h6 BaLqyxyyh6BbM+S1BPAUvDoyAfgaggAUgAgQS7hQAUhwAUgBAUgJkMgBQbsQgQgYARAAhgTE ARAGAIEXgqgRQZrrTIENB4Diy3TIAMgUAwhRFXr9lVtlL/q8Amw8g4g5AVh7TQL/hzNqLArA ttB2txgVxCN0AAMEgAgclXlVgDsBsJgug5IxgUAEgJAMgJS7tZAcgJAnkbgJOKgtAJA3gAA1 AJA9AJBNgAhUgAiqBagJBlgAh9SFB3jCMKAAgumiA4qLA4pFk4yRBUBZgPAJAfgBPNsvFLkN B0BbOtAAggAOTkz7hZT+gJT/gNz/B/z8AMsFAEAMUChsMxsEgJALMEgBAIAKgc0J0EAJkNBs BZAF0LENBoUOUPB/h8BagKULL0AcqOlWKLlYKNGiAugBrHMTMUARgRvFgKgRsVu8obMFgKAL gLAZgZsQgagZgZRZAagIsU0aANgAg4ABgegOASgoAXgAhsAYArASALASB+BBANgTAngYB/AU AXgr0sgdgegdgOgdyAB+ADw0A+gPgVGXAaAQA5B9hEgCAiB+Be04U5AS06A5NVAigWAJgEq0 gkh/h2gBhEtVAAAZAAAegBgkuQuRo7AQAftKAGyx1MAJgJyxgKgNgDgXCeAFxegqgSs91NVT gAAGAZzKjOSdyxgZgLVO1ZENBvBaTHVbSzAgO9TJgZ1U1ZAcgD1ggqj9gXS5AQThyxgXAZgA APACAUgWAYAaAGQo1TVrAOyKgq1rMESxgGENBqAgO6AJVvtPA/gMAArZVvAqrZVtSxgMAIAS gPRQAWEUAXh2gfh2xHAVgusEgXlWOrB+sEAcgchqAVhmk52EWAFWBgBgBulVOzhqBmrDlVO2 A3gFgOBFAZgBSqgbSFAQDlhAAfhUAEhbOdAJAVgJA+gAA+gZrbhFgFhFgagDAO0IAdAIAf2R gCAEgOAmSAADHMAigRAmAdAgAfhEgOkGgHD+ijCvglgFAkgFgkgaglgbghgdAkgegrgFgzgF hCgEhCAFBCAFgHgqALBBgLQEgfgvz5AwAEVnAaAeAXAUgWgaCqCdGRgGPGhbAEgcgGAUUO1w PGggANAdAagIAGAoAGSHXFAGAwAGABgQXHXIA7NPAGAeJ7B/0GgU0OgngMAvgMA3puAXgMV0 OPg/APgIRJV5gDgYAeDhABAeV7A4AWhAAWyMAa1pAYJ0gjL0ACAFgXBgAWgAgWgwCrAZgGgG AGAaAaVXB/h+VcgIADAqgZiqAzmJid3CANAHUUgSgPgShAAShIASgCAgASh4GqXxCqzHXp1T qnAhqkgKvUDlgKiFAz1xgNgXgcgYgDrpgcj/AoADhAU3AID1B4D1YBAAgDghgfAhg3TPK9t4 zTgmh2h6B2q6B+1+zTL/YNLB4PtstmMCAfh6B+hyAusAA419A5Q5z0FNN4lVgXhYgDOREyhZ ABs0MKAsh22CWCX+AYAhg8ggAjgagdgOARgCgJgbgcAbAcM2LtkHM2SWgQFxgDAa0OspgIgO gJiagJAJgHtFgOAAgRAR01gciagcAEU6AAxdgFgJAOAIYxAHTI4xAdADAeCalV4PqWMBq6Ae FVAVZAhA5BxUMLAAFtzTMKE3p8yEzzTykPTgFjBaAY3/1kENhZAIAc5LBwBbXugbgQXugQT/ gGYASvjOUOgMAQUOgL5VYz1XgNUOgFXAgcgb5Z5ZAFZaAUZcZZW/Za2/UVGtUXgsgSgDNEUc gTRdxZRYxdsVRWALkRZjxdgbUi0f0fwPsO0gUjRYgKgDZjgTgI5itNRW5sgBAjhGgSAbAegv g9gPAUhlh2ArgpgfgSgTABAXgTASgXhYBPg9AnYjAJAFALwSgGAKgeA4AzAYgdAAhLgWAngi ArAcAmBCA2gIgMhBA1AhgYgiA8UsBEgzF+AWAdAXAZAaAWgrBIAUgPmwBCh/BkhBgdgKADgG geAcBLAiBJzygeAMgWAwAcgkOKkaB/h9h/hyABsqhHLSL7hpVKHTgPACkNB6IyVdAqgCgKGR gMAFTMAMXBhzBaVa1uENXozMXB3oy06wVeO4zH3lgMALkVLr0MudsOQo1VAKAKgAANgSgEgF oAySLAV8182IYeAJT9WGFVWIBgAIBjWAWKAYAN4Z4ao7ATa2Kj6366gAa+QO68gF6nAC58Jt 1U3qAMUJ33atkNB8BaM+XqXBh3BbzHbVAGZ8WCWGWIAVhgbZBm6/V9Afhuhmus4fu2A8gIAT AAhSADBbADBagDh1APgCbOghgGgugbPOg6gBg7ACBDABhDgCBTABhVgEADgjj1AdEMATgGrd APAKAia2GRgCQNEXLHbMa8a9APCMAChIACsagChAAChXqFgCh1gGALEPgMASXlgIAGgoAGg4 AGhIM8BAcGAGoMqkO4gGgQAGgYcIgGhgAGhoAG6ZPDhbgeAagG3jhhAl4Ih6YNtuzSK8Nsw5 g5B27ch2g5AfgIutB6sHMILD4gsuAMrJgFgDgTLJgPAQAAgNAFAMCagMgMAFgGAOAEciCTgC AQ8igMgFvBAAAOgDANspqU4/Y+lVZB5D5HzyA5E+AA5pgZALRW5jARATZvgaMU0cgDgTsNSr sPUixdc485s2gdhChNBGhpBRBFhVgoBSgrAHgQckgVCfgJgWgZg2gcgthOhOgyAagagUABB7 Bch4hoh6BKhAAdAdABhahOAkQ7gRg4B+gUR7gZAZhkBfhYBegNgKEWgjaiABglVGrHB6hZEJ AA6mVLABANM9aps9azM9TMADALASgHgEgDgwAQg4AQgBPJBa6vgQgO1w6vQdAq9tB/hlBbVY 9vAYqkV8WI1+gfhiRI7Chmu1bGhYgJDK3CA5gVW7CYbn7ogLgGgr78AOAJgqACApgCgpgDAq ADgsANgsEBAzgCg7b9AABAAQhaANhigQBoAQBwAAByrtAbiCCwAMAqgOAvgRrVgwAOA7AMA5 WNAJBHAJhIAIhIAMBTbiABBXgRhZyCAAhjgDhjgMh0gEByAOB1AQB6V1YaAlAJArgJBFgPhF gQBAARh4ARgDysAAheENrNesgP5L8sgAXeggStLHdo+JEYAQgIcqAQu79o9phIAQhQAQhYAQ hgAQhoAQhwAQh4AQgGgQgzAOhvrmgHhj9mdn9v0N0TfDAgAcMEskgB69hmAPs0AngGBH3GAG NsAAAYAAAgAAAwAAA4AABIEcgALO+NAE/NfOEYBVA5gNBBgNABAoANNJfZANCFVrAJB4M2qo 3pgQADAYNeqygDAhgRAhlnBItjB6A5A44Kzfg4h+sLhyTTcY19FVV9B2g44JTTByAJbH1Kji gpgOgxgOg5gOgBhJgOiStlAs4fgcf2gAgcRS8ygATTps5JEXUFgNzKhbAJgcgCzHCADkArh/ sBZBAciCCMBYwgACuICsAisslkAnEAgYDCMRAIajQADMZBYKhSNiITiYTSmOAcDSULSIbjYb gMlCVsINOOgAgFaIdXDEWDsPBEFiMRj4yD0oqFEmInDcaAEuLVhxlvtgAg5Hk0TC8TBU7B8P EoxKFSPshi48gABAAmP9yAMpgNYAAKAAOgM+rEBAIhlQsEAUAgLBQKgAGA8IAIqgAHYvGlXI g0G44HBUYEAAAEQAAYW4AAAIaKFrQJhTHACFkAI6/VgAFhsShEDgADhADgID6fGY7ewVa6ng ASCNbUaoq8Z/spbhIJY4CDEFgsAD92xBiRAu9gJDkX9wul12gHwituitgC9msAYjANrEDYDB EAOhVAABQAC7gPPtCzgBtG0q3tk2jbAQ4JgCAEgIAgAwqt0EADlgA8BAOMADkAA5QAOAgDkk AhRAIWQCAG6bqgOwwKIIeggBMy0IAoCiyMSBkYsexYHwgyEdQgBwLRwBwHLICLvvO9L1SM8A VmaaBmuudoumI8YVhk7zwPGLpmveDYgAyCQvgwLoMjAAAwAoawBgKDIQA4HILzcHILCBN4Pt aBQhiUGgEA+IYGi6G07oKWYUBQGlBwWKYVBcGgNgMDIEiwCYvAsL4Li0DAtg0A4AgGBIDAOB IEAYAoKiSAxEgERgDEOBhFAgQoOlGARVgw4ZqAEbIHm0CB6AEeYBgmCUMjABA4Q0A5EgSYID mQB54RUAgAgOBpCAFT5dH+cAAANbYgCUGwEiMAQjgSJ4PioAQqASMQBDkAREgmRIMkyCZSAS UgFFwBBagSWAFGOARzgEcAGHoBQKAQaFOtxhgBDjhrcgPCZIQ5CiXAOPoCLyGCSNbYYczCCo /gqT4Km+CoCAqCoNmnabmGgWQKBy5h0FkCeaoIbAgCQ78UAWLgNgDA4DgOZjDBQDYcgeCwAj eCw/gsR4LAGCx6RmQAEACGAEEgBABa6R4EG+BABggBAgARYw4AQWAEHABADAQVTMgIABEtMA YWCACQYAcIAHCgB0BAcCAHBBwh4AcrbWgTPQaAcIYPCGJYMBWJ1fBWOI5DkJp+jiHgIH6Lo4 9L0UpDiFYIHbKI5OwiI5AjLIhiwWQ3gqAIuiyFYeH70R6PHzgcvf3QABwHAAdMAPaloAzOr+ OIs84iPqgAOQhi4LBctwgogKOHIGCAFocgb8YcgQhZZBQHMFfWHIDfVpf3aX9KCll+f1AV9H 9fb9QCX+PeAdAACoEAMg5Ta7MBoIHZkPIkCuBz1YJEUIqBMAwFyYgyJoBcjRHCPA0AkSIkgJ QQkrJURwAw2gAhkDIIcLQhQWgfAqMoTApR1jxFsJoYw/RDgBFQAWAwYwbBTEGAIHYzA6B0DG HgCgiRwk9GyOtagyxVA6CwCQHAQBAmdAAE80YAw9AFEYQ8AQCC/H0MGCUFoQEHGOjWA8B8bg gGWMcBsiThwDABAQA4FMeo6BVACBIBxBB1N9OgZgCUfzIxwMwAYXQAxxAAATJAIACgEAkBKB 4C5owHgpAeLhogsgJNzAAC87AwAIDAB+M0drrDynnPUemVAxAIDGlrLUYh7yInxPmYF7YAAH yhlGaxoh9gUgGBJJoAACI+o3AahAjMcJoACQdNCQTO3vpCANNIyhBBtC3mqZQBwLQWJLlgMB JJ6pSyrGadg7CXQgA+EWCATIFRMgmAGESfIDAkAZEKAMQqpRNLTBeC0P4IRIAGYsJ8BAnwEi eAgJ4CIsAWgJQeboAQXwVBfBWAIDkexaAeAQJIERPgPG9AG2kD4IwPCfA8L8DwAiiyYAuRMK AEAAgQBgCoFIEgItzAOAoCDQwNygCkLMR4LQAgtFwAIewsgAgqBXKACEcwUR9AkA8CIEBJRw ACCSQahAwBgciQsWYOgdVlUID8H9ahgCzBIDGtwQALAcBCDQSDjDIOHC+A4OADhgAOGgA4Aw DgMgskeAYAZt3LuZeCHKCQTR2vAdFZUHg9HRDmC6OQOR1weA/B5aEfocrPj9dmF0857whh5b 6CUE4FALAmBKBW2QFgUAcABa8EgHCJkTIgIEQIAQ5Omeu6YioAQIgUgwDMGYFQQg1JEDYGwN QIgjugR+6RIoMElJOSolgIiNMsuaAEUwHASg+CmP0boKQUBCAyLIWQWBahxDSFitMmgZhKA+ B8EwLk6jsAGEwfophAAiBYCQEgKAiLuC0EgHgiRfB1CIC0HAHgaghDaBMCYMQzjWCEEiL4AA ej+CMAMbYAxXgAB2AAJIAAsgDEuEAQQEgLBQEuCYTINkBAtAgFsAQdgVB2CmW8FQBgXAGClP MAgPwbhPC2G8G4dQTBwC2I8AgjwCiDAuIQDAjwaiKB8IMIojwliGCeJUC4lQMCZCeLgAguQC i0AuLQDAyQaDJCWMALY0AtjgC2PALYGwNAgAqDMCANQKKCC2AUU4CFwg/A2ABqoNgQhK0iBk IdPgIAPAcA0BgCwFAJAThoCioxAAlkCCUgg3haASOVqpQgFAGA/1ggsBYEgFg/E+CUV4JRfg lAHqoAInhahYBWIAEIAQQ6rjnq4xwEhPghFeCEX4IQB7L1jrPbFb9cA/2XsMIAGBIBKACEoI Gsgf7m26EoFkhwqhKCgBQAKLI9BAAmG9rYf2ttpuSY4BANQDCZCG8wXAAwYhAAYBkJQCgXgZ ACFADIgAMgCAyL0AQ0luySAGE0AAPODSVVCBkKIAQogsBYA8JovgBmhNCB7lYAAcgACbysIA H6dNPBgI8GAnwYcrAwb8KoMAGThBgDUHILgBiACoAEKmqxaANjiFXppzRaAQOV1PVk4epjwk r1BCAVASgfBQAEFBrQLAXA0DQR/YwngoDgCgYAKBoAoAIChwyDwq9lH+PQWkjO8kEHc32Nve Q6ggC2DALYQAtigz3osLZrQOALAYDQLZXBLBGACEZB3eAjAxBA05pocALDPaqBYgg8jXeDAs Aw2AVfVzh9MAIXu9hMg/ACD894AwoADAF7sAIAGz+8AHWYDIHQafDUJ5L46LTUATMd8gegt+ gADDSFoLYugAh4ABskBQsREuXBWPZ6rpQ5DtDkP0iLpTshyHIBBzf4juOq/K9UOIEByD0O5+ V1jrHXA/H6HMdYdKB+dYDkc0PG/M/cO4OyBWC6eaGeBCG+BCAEd2BWDkHoSkIjAcBKG+BLAm CzAKsqSMAuBySXBIO+uQO+ZEByeIBgtWCAD0CWCuB0CKBIBqA4A6AuAwACAKtkBkBiBmrkBi AGAMCCBMCev6BKBUBMCsBKCot4A4KItwCWBqCaM+CE9uM+B6AKB+twCgBaCatwCkBWCoBAAC CIAwCMt4CqBOCut4CsCuA6B0A3CeA2xWCYBiCVDKCWCUBqBsCAMAM+9+B8AIB4t4CcBeCitw CmBSCiM+CKAuCGtwgidWB5EoAhErEvEvEogegmgkqkuBFAuCDkC6eUC6IueueyMGAUBcAg26 BrFa6OIIHgFiO+giIsJUuwu0hEu2AoJcI2BGJIJMI4BOvCtggxGOAtGCJdGGBMI+JnGfFwBo BsACvAJKuWg0I+JSIyJeuUgyumBoJTG0BqCoC0GaFAEGDAGEBWcIAMAKAGAeBWDuBwGIFKCI COBYA+BCBgA4DgGcB6C6DeDUE4H2GCEKCWAWAiBqAOC+BoBWIEAqCUDICIBoCgCYDECKBmH8 HwBeBgB0DIF6FoFWBmBoE0ieCcBSEmCyEQGICAAKAMAS7QAVJcCQDgEAFsAoBMByAoAiQmRM AKASAaDgCkDiDGEkCug0AwAwBKCEASDGA+BipWC8AEEODsD0E8CuCEDkD0E+C0CEH4ECBmCw BKBgBIB8D+CQBpGSAIeeLeB4NGN4AKEcNkAAI6CSjOl8e4BIe8A6j+kSAQj+AaBCAw8HME78 BCAmAwU+8A+aMcASIIHA6eMuCrMcH+OQ79MoGcFs8HKAAw+Yw0MdM6H+HFMjNBMe766jNCGs Fq8GAwIUkoAuCeBCDeBCoO2uBEDei4DAjyAMCA78fiIKFvM+CqAMvAAmnWGsO4GaC6AgG6PI PMeqGalgSaAgGIGMIg/clyBgIml4jQjmBAAknCBDPA7xN+GAFoCWCWQhPKFoCCCDPUNaAyBu BuQgCAjyW6FAPnN0IyNGBABCBEAOAnMUH+HsTqnC1EBIBGMunCMum408RwAbNCHg6q7xNCHt NOQhQiFuRxKTQQnMIiGaIjQ8SglMG6nbOUeoIgeKIgS8AyEgBIACDABIDgBJRcFABIHgBIAK BABICgBIAEQZR6AEBIrMBkBkBpSGUIBwrTSQreBaBhSOrMBGBLSge8BcAy7SAwBSA8AmCUBE AbS0AkCUBGBCBOAyCCBAA8BCCI4SAYAmoSIy5jLoAZQAAkAUEgASACgA+QIMCGBrT3N6B/T8 DWAYRuAyAaBIAwCBIdNCQWA0BsrSEhB0ChB0DAAwDg3EAwFAAwHgAwAKAwFkBGFkFGcuAgHs /IIgsnEy/wBW/Ms8tAOwdkO+AgHqHaH4ACHrRTO0gkd0eWDkuOJGu4I5GbGkAmuTGSuaueg0 umAjHAhPP+BO1QBSBUB2B2BUBUB4B2D8AyBiCCH8CGLWA2ASAOA8A0A47s3nLjWrWuB5WsB2 H8BCH6BACsByA4wQA0B4kADCEqBYBAAyAfRki4AiNGAM56xSCuAGGnLuPqAuCykMMdYaj+Au AjL/MkAiCqCYBg+Y79YyH+HVQmMdY4RcAfOEBgBXYoMcBWBiBuCNY06jZZY7Y+CrZeRdMO+d ZkCCCOCDZOCqCCAI79PdUIMcCCCYAo3cCZZaMdaPQHNJYukJZjaUH0S/aDYuAVOECYBXZ86i BWANamBWBvFke+78BuAgj/a+H+Goe+8GBuA43dbMkKA/amBuAFbKAFOEBuAjayMcp/anJ4II HRbC6iBABgj+IUH+GFbSMmBABU3dcKG0e/amBBbnMlcKH4e/OE8+AyBeBkCKCQ4KHECABACO CoCq4QAYMcBekACeCqDeCqD+CqAGCqCsAMCOBjKUBYAWAOB4BYAKNuncHaBfeAB/OaC7OmH6 GBePePOegnRABXOlQ+IhecSaIiloO3OuloBXeqdWltewl0BXO4l8CAB4BLdvd0ALdxd5dGCs AOAwBiCOAimo7xJ4AInCBBa2m4o6nDa9Pcm4CDfgQhaHcKHVQ0meCqBABACxbMHxQmQhgTQu CrbMHlgHgYBuCxaUHdgdaVQknDaUHxglYuCYCyCxQ8IgdmlhhKdXeYAhhTeklLeDRKrY/2Ha eKFgAaCWMEF+AACMH+HQAACLh2lLh+Bhh2FqA0AwAzKSAweRiUeQCyS8A4BoAOGgCyHeaqEA IsAiCyDAUABsBWAaACEgIsBAAQBBS1M6AEH4FoBEBvS0BiqbcqAWBECZS0CPS6AjS0Au4KAc FoBGBXS1YyAGAbj2CDS1ZZkAniBHDWCaCCCoA8CqCImYBuCaCAByvYAQNwBKCPDfdzd3fGAY AVdwAMAJd4CO86BgAwAuAUCyAu7QAgAiBJH1DKDgBAFhciIUACBrN7jWBcBWiwBgBuACDgBu Fhbla/luroCaCuCCBICYCYA+CaCgCaAEEACaEhmi5kAhmiCaIXJuAsBoCaDACwCyqaC0FmBC FMD/M6hWEKIgCc/w/IB4CadGeAc4d8/aHpnod+CcCKDKCIHMs8tCtCtAs+tCskdYtBBEIESW ABVpVtVwgktUtYAoBEBIMWAaBKBGBNooBCt4AcAeBEAcBKt4jvEqt/FEABeIIud2IsJouyJG Avpa7OJIuSgwJiucugBlGfWXWahQaNYkthprWTpYupp3P+VDWNqABrWVqGJSBMJbWgBm4eDI AkBaDQBmCsD4AqDOEcCWCSDiBCSCAUBsxGB4AmB2BDlQAIA2BOCsBqDWCYL+AqB0CMH8BiCY ByAWAKBCBYCeumCmBbW2CWH8B2B+BkA1XFXIA4BOmCAoo6HYDIAeBMBUDIC+DxPQCqB0D4H8 DsCs8+A+wQAuAgBGAiCgACEUDgv8BqCQAWBWH8CWC8Bds8wQBIAiCltKDg4OA6BYBuH8AqC0 BsA2wRDqkAC8EuBYBDX9YA9+AYi+HuxQJCAFYSL/fAAvlw3c6E8GBi6GMmAcAQaaBGkICBFY MmBGA6BIBSARZ2ARbyCqblamMMBI3cAsA0j+9XOE9M73NOMdvu6yMnvu8CBNamAsL1vWA7Z2 A7a5dMCqA6BSAw3cBSAdOEBTMW8HwkH/Qk79wrQsj/wraiAVamBSAAA5SFj/c+AS4OosMcBi BkAa5UkiAgkhLpxg2BxKBJX+BkAOA0BYN4SiB/eAlcHYHZOZVZBLeUeqnSPXeWIjOpOodXep e7e8PlO6C8BeAs6Ju0QgBjyq7xxDxHxVxxx0APX+VIRwbAnCbkm4MNckQgAtf89du6R29cAs I+L0mcQhwKm4A7zbwXFlMiQhwrg07xwrgim4BSBSI/hGPQIiGB0ReYgheCHbeEGbBLRVRWCA B1lwBUBq3/i0UC6KCgBqDABqDgBqEgBqAKBaWmCB1B1EBqEB1IBqFg4B1iGgBqAF1jRh1aBq GBT9wKAtS0k/HeNcBF0KA8BJS6mYA8AdTFwWA9u+AGcABcBGBiBOBUCCBgA8BiCItwBGBkBn y+N5QQBGjgAcAUgwBIAOa+ACbeACAeWOoaAQGfvUfS9kCAA2BSBnvKBUA+BSCgBSDABSDgBS AIEABSEgBSFgBSQEBSAgBSAFwqQWAStgBp38BpnPVI/Fned+dH4zLctBEys/0gB4dmBzoZVu erogb7iNCGAIBKAyAGAut5JdU7XKt7E0BWuBV5V5pOuEIguOBtF3plG7qQuiJnqHqbP/pnWP psuj6N6OAPqeACCWFCEkCWDY8+AcAWBiCFsEAmCABmAUAICCCaDuDsAWAcBjsCB2Ao86AeA/ XLsU3mo6HaGECWCsB5syDyCuA+AzXqBIJSAeCeACDuD6DiEEH8A6C6AsA7uABICODI6YFKCQ A1X+DgNFh8LmFzucAeL0AEAZYUMGA41kAM8HUI79UIj+6GOqMcAYA0OY748H9c3t9UOWR0Ok AuBKAQAWAgBKNxx4lfQ/OkS4PhyjfAot94AP9v9yA0Rb3qRx9a1kRw1k03zg6GRwAYOY64AW RwAIAIA9UISKSPhPATRBhUghd8ngCKAkEAdyFOAsFsAsGKACGSASGIA6GyVAAkHOAUACCQAS CKIAFiuFUKAUYCUSD2yGwOHyAMhqBA+QwaXRsnw+AWMFWSGgEQIySQQEBKAAOFxKCAWEgIuH +wCAKwkCx+TwIASBN2hN5yUAIYAIcAIkAIsAIBgI7AYQJmPyADE+DAEDCGHiGSwwKycEHoch WTXaXS6ca8S1gKCnZigUS0sQYHiSsQ+BCSUi0WF6AAZLwABL4H5eOMEWSGWF4AA0AxlfQAFM U6Qg6Q3h8TiwJjcU7Qg7SyAB+7c+MRgQzyQBsAQ6EhKDhMAhKHBMChKBhMEQeFBAAA6AQ0IA CFgTuAAGAPvQCEwaEN8GwHygCFQWF9yGQL0gAK+wKwD2e52UCATkAbJ2DiAS6AcKQAidQEdQ MegUegcegkeAsdQwdQ4CC6WS6AAuiGLgsCABIOAgCIcg3BAcgqlx4FiBYcuu7AswsAIZAuCw KgoAwDBGEQThMGoaBsGwLhFD0OAkGYZBtEkRAEABoD8NY7GeP5nj0M4+mYKYajWIRPkEMI/D SI4BleTxDlePZ+EAUpFlaPx8juIIfk8PhkH8bxQGGehGDAAAAACAAGzGARbySAAUACWpYgEA QhipAgUBUIAJgmAQqgMD4LgiE4CAeB89hODCMgiBAGgbPYI0FQgqgiAwGKlSIPpcehaUHPdL n+exaUXTiXHc9QIAhTgKAkCVOAdPNRH+fggAXTYqoyCABgwCwMl2AZxOGAATV6IAHCeE43hO P4TgGE4UAODAGAGA7PGaF4fm6LrNH6YAIgkHIcgCF7uhWbrsmACBiGMFdz3O0QVg2WIDTlOg gBGANbgwE1mAON4Ej+BIBATaFnT6AIIgZRYDUiAlTYSCNOn1UAG4TTp1U0B+JpcdRb4ZWoPh UFNuBzcLsXIFdzGIAFqmaZou2sZuQhy0QNiAN4QAEEAHhkAQZAeICPgeQQCAOIAVACL+ig+F IPAwE4RAjpQLkMEYThOEAghMDwTiIAAFAWFQItwCAAgIDBAASAIEhyCAGACBgsgGAaTAwC4F C+AycbuAwXY8AIVAACISA/wTfEAEBIZsAAQOUWAQGAEBoBAAoQDAFJTDcrKtnosY5B4JoIH6 HgIDkciyM8Hgf9Cdo5LCCIL2/mAAAgep2n4AJ6uw0TwDjAELgqG0Ww3DsQBNEADgMA+wQ0Cw ZgqEIahkG4beiGoIhoE3iBEA4ThKAImDmPIbiQGgSBGgYJAqFoYOQIQfH8FYjBEDIFAKBoRg 0D4TgU58kmcZwhgsBODYIoFAUheH8EkJgJwNgkgYBYCAIwIhQACGMUAPQOAPBIHBMaZQKD/H iAIHgBBggAA2AEfqcF5IEBKB0piegqwsVMnsBYDAMKqT2AwCoEwAgFAnDVVYVQJqthcBMlw+ GLJ7iIP9TKoYgIPKfDGIACwEAsAeBYChLQAgbFkmQAy0x+jQWoO0Yi4DujdXMMZcIzV2ruXh CkIAGQLgMY4BaOQEGEgVjqwmOjHANkuHQLRjgGo/SAjsFUDMfggAUY4HABYAVZwlAqGkCgAQ kyTiuLiLIQAOABANFMB4C4SgFAExwAoCFBsJAKwdiQVYeKjkIwmJI8GLSwJcPoW7CIgATA6B xkLI1xnZjAZ40EXyxLmGaucLruTuoUA2LlMw/x0BACCAwHIX2jJxB+B0TIERMgZF+BUX4Fhc AZHQBkA4nzdiJA0AEJ4DAngNC+AwL4DR6gYAKAYDAFWmAYAGhsDAGTEgBn+YkCgGxQABAGBU GEWGZybAGDBOMnAGA1k8AsCwzwKjfAqO8CtCQy0FGYAABcmB2BABYCBtgDAXAvA6LADoAgOp kbGAQAoJAKBQh0ICHQAAJgQAmLACYwAJjQAmOACYBgJhgA4KsRJWQID2c2Dx0AEHQuhC65oz RmnNA8M8P0cjqDNmbqmORgrrm/uuW6aIAAcTzlkP+V5C4EXmQQAo8tFwNwZoeeGiMCIIwaom eiDcAIShrDWBmCgEIPlAAjEAEQFwWAVCRBuHMFoFwUwiH8NMIw/RXBZB8CkFAYgxgzC+GMAQ aAQgWDSEgEwZYNgAAEP8cgAx+gDEoAAEoAgYQoTmgQCwJymQ/AQAFRSjAqyOBACiGwVQQEuV irNSAIAPRMubbJPEUAQAauKnsDQEgOXLAlEWI4Vbwj/YhEy8o9BaxQAkCQXSvQAAXWEA4DBs wFggvoAYDoLAHALAOAglwwBagJVOFUBACmUrkGaZ8H63Qcg/M2OyMh2Rmgrl8yZcgxF2rvXj b0IAV2hgIDAAgOACAB4HvuAsDADgSAlAvfWfF+r+ALkaSOQoAQFSnuPKphIAbsqPYSBphchQ NAKlxd0BACATAglMxe5gBpcAgBACa8o8pX3kJcp/HV5R7S3lWqpEUvTsoJZHmQCGFTsZnXLM IH+EJjsvwctYLsagYMzBqAEE4YCKg2BBnkE4cATiwUCDQBYNwPg6BAEgD4SHI3aAmE9pYJwR gh0gCXSQCATgBCCAcDwCAiAgAXCvAAAQip4wQCUEoGQMgYxkA4BzXWugLBDc0AIZ1hgAFgAE AIDwAhwACJ8AIz2xgBFwAIXoQASgSoACRVVOBIJ6p1s+oDcaegTBBT+oNQ6j1JBMMIP7mCuV Rc9VMfpY6pA8qq6YzdYKqmbZg7N2rtwVmiNIEACAG4LgRguBoDjsQIoLl2ddewPAViBECgA8 wK6411rsDcC4Ba/V6BE9d6j1gTAHBqCFsFdnpPVXyDUAYYwH2pfwA4fw7gWh2D4EUJocQWAc fDpoLIPwVhtCWDkLVth+jVE+EeXgIw4jCEAEILIjBAABEyEEGUJQSj9E2IAKANgmACAOE4G5 rkyTPHIAUWltgAAsAGM23idBbAmBCB4CIDgBAsFxfMAACQTAYAQAQFAJQPgGYuACLubQfgvB e65z40PBDQGAuBmUbbezOBNNAIARJcAYA5LgBHkZVgYVNIXG3mF8AJMvYjtHag8gsACCwAAd XuAlAWHVNoKAF937yAYFgLAWghBCC4FsvcyGe74y0LoEFr+D8Itx10azsrvAkC7AMmgfg1t+ 4oEAEdLAgBcF8FwaQEhwBcOkEo6QUD4BKPgFFKsAiyAmDX5BLwgDIA2B8GntQXApDIDYDuqg PgbBGBAFwBAFAmA6CYFgEwHIEwKoC4U8AgDAU4EwlQEoG4EgG4E4J4AAJgAIJoA4kQI4EgIw E4JoFAJoFIRAA4QACAQACIRoEoRAFARAFIQAFwTQCASkAwU4EoXYCAXIEoXIFAX4FwZAEoZA FAbIEobIFAaBvYAAApoQAwCoAgC4BIEp7QBIFAAwFIGoC4IYCAIaCIAoKQA4KwDAKQFIRIBY R4CARADARIDIRIEYREEwE0FYC4Q4BIQ0NxYIBoBILIAIO4CAO5RwBIBLJRfLVB/QA4AQDxex P4Dw5TSYDw3IFIFgDwAAB4BQBwDwB4D4DIDwDxToQwWYBAFBqolwPoIAIC+oEjJi/4BIA4Ei 0CAi0BfIEzSwGABA4LJIBKfKf4CoEg2QCgBQ2QEaBgGCf4CgDCf4FJ4jVZukPoA7BCxAXYAI dhxIAEQgdgWYjIB4CMZkZwCAAAB0ZoIDHIB5UxwY3IAUa7rL0UaRMqfEZgNS3AAC4YUwIAB4 FAIB7YEqBj1gEAfgB4Mp/STAWIWgYAAAMoFIEaTABAIACoIADYF4KADIAIUEhoXoDIZ4DIb4 DIAYDISQEgF4DCTADYW5nB7gkgAIErAIWaGYGkGRexYAAACrWop8boF4L4EwnENg1oEykgWg BIPoE4F4BAXSLMdqTIBQ3JNoQAFAeAFAAQFDAIWsk4FAUAA6TDWwDYKAFIAIQEqwAAFICAFI EAFIIAFIWAFIYAFIaAFIA4FIMAFqpipyqAsgdoegFYsagAdqrwegsIOIDAegDQdoDIrkuQOI DUuxzYDAckvgrkw8u7dSqoDSsI0AHirKqkyTdsyJ1LdwCR1wQ4AoFwFYBwPpc4Q4BwFwrIBE z4YkzU0YFc0s0E0U0k0w7ADB2Idpe0gAzc2k2U282wCE2s2c3c3E3YA4CABAHk4Z3IsQ8o/4 84rw7DhJAQLAWoEwCACgBgH4EhB4Wc6YH6JIcAWQDoHIC4l07k708Af87gCk75B4WR10kgf4 eAWQCs9E9oWM+A7ZcThRCwCYEICpFQCgC5PJEVADjM/Z4xDk/wCZF56wE9AR44AIEYAdBoAJ 64E4Bsq7jICIYgYoGhpgCwHgAIWgJADwCgBAaAYICgE5b4EIK4FIfwZwFIcofweoEofwbQDo HAHi2wEoAgDwDgD4FgfoeIAIVoQ4HgC4BwAbVAAYC6B4CgCofoeQAIfbPgCYDw1wEoBoNIfg dYAQJIfpNVLYGZM7rIBgfwIwAYejrxnQETsZAgCkPgFYFRuIPDTIE41IA0YKKACjtocQWwCL yzAoCNPQWwAVPxPYAVQIGVQgKoGVPQWLvSYQFYdoFYdlSQFbvplkzBb4F7w7DpeYDwBIFY3Q CgCIAQPQGRDAAACSLpD4PVOYDo24CgGZMYGgGb3BkQzxa4YjNr3wLrwRbbBw0QWACAJZOgvI DYf4fAAADM9oxE+QBQCAwQwZmYVbAgpoBwFYSoFIAQCYGgFwCz+IQYAoQpeMPgAoCQBADIBA DVT4CgDQEwBLZgEldoFYHAAIGwCQGoDYI4CQNABINABQNIDIMwDQMYDYNAFgPABAPIBQPIDI O4DQOgDYPAFgRIBUMwTAAATABIS4DQSwFYXZGYGgcpD8PgBA7AFgFQFR/QBEQY44DICgDwCb r4GURwCQBQCIDwCUBIECgADQGFlICllABQFg7AEkPtNtN8PtN9dT/SKdpR+UPoBAEYCZVTXT vQE75IBwpsngEYHNVwGgC4C4DSQ64khIR5/Qb4BQeABQAQMABQOABQd4BQAYBQPoH4BIJ4BI L4BIAcnTUYBwIADoFYawB431wgT5mwEAR4L70QF4FgH4FjtYDIGYGgVIEIUzb47AJxzQOQJo cgsYcgfpzRzQsYfoJwIoMoIgcwzwJqr1SrdoHlTBgtTAQ4BEzkz01k1M012QHM2M3U3k3M3t 384E4U4gHk4w8VUA88+8/ICpEEJE/pPNBBER4lBZ49BjiREZEpFpDRFp6SwUVtABtgVZ9D2Y b5l6/4EQ7QFQEoFADABIDIfwRYGwV4KIHYJgG4GAEIHIFABQD0C4IIfwW7kcvwC4GdHFOgE4 Iof1UwfS0ACQBIBYBrVBsgEIBwH4fgNwQoRAIlk4GYCwB4HwLIT4AUaYFwEaOQBhMYAAHeFe FuFmF+F2GOGGGeGWGIVoAGG4VteuHY0+HuHmH+H2HtUmIYPWImI2IuJGI4AYS+JeJuJmJ+J2 KOKGKeKWJYAoSgAwWwA4cuLYBIao6IBoMeMIBwX2MmMwXyvoCQa4CgBuNmNgCoEuOACwKAC4 UWOoDIaePADbpePmPeP2PuQGP+QWQOQmQeQ2QuRGQ+RWRORmReR2RuSGR+SWSOSmSeS2SuTG S+TWTOTmTeT2TuUGT+UWUOUmUeU2UuVGU+VWVOVmVeV2VuWGV+WWWOWmWeW2WuXGW+XWXOXm XeX2XuYGX+YWYOYmYeY2YuZGY+ZWZOZmZeZ2ZuaGZ+aWaOamaea2aubGa+bWbObmbeb2bucG b+cWcOcmcec2cudGc+dWdOdmded2dueGd+eWeOemeee2eufGe+fWfOfmfef2fugGf+gWgOgm geg2guhGg+hWhOhmheh2huiGh+iWiOimiei2iujGi+jWRmFRNDrOjoCgABuOFQ3iDaLpMc/o GIJDnIIgJQKIK4uoKoKALgEgLAJgIwIujunWnenmnun2n+oGoOoWoeomouo2o+pGpOpWoAy4 JGFQy4y5MoAAeCDof5MYeAAIf+qy14y+lC+IAAGIAGpwLWkQABrYJQAAKIAAK4AAJIAAKQAA KoAAKAAALgAAEgAALECIAAIwAGnOjpMoCS2GwZMaLoB5MYKgNINoMoOYEAJwMoO4EAKQN4No MIN2wCDYSEIsdupeowBGoYeGqereoGqWjoAxb4Dm04AO1O1BGWj21+wm2O122WFW2e222u3G 2G2+2GroeG3u35MYEGru4W4O4e424u5BxO4+5W5O4hxIAoY52O6G6W6ICG6e626u6+7W7O7m 6m727G6gf4c26G8W8m8YY+8u9G8+9O9m9e9282+G9W+O9u+e9wAYRutoy5WG++vm/lMu/DqY VQAAmxMYHuroHoARCYHnBIAHBfBXBgHm05v+roBmroIvC3CwAXARRnDfBiK5NGroAW6YBvEf Cmsuzunm0oAoGYGYWIWAV4XQL4B4Hgetc+z+joUQcYDoYWjoZ4OoMIG4fYOgfoRkbIBAB2FQ BOj+jogICmVuZHN0cmVhbQplbmRvYmoKMTAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRv ci9Gb250TmFtZS9RUEhZREIrQXJpYWwvRm9udEJCb3hbMCAtMjEwIDkzMiA3ODFdL0ZsYWdz IDQKL0FzY2VudCA3ODEKL0NhcEhlaWdodCA3MTUKL0Rlc2NlbnQgLTIxMAovSXRhbGljQW5n bGUgMAovU3RlbVYgMTM5Ci9NaXNzaW5nV2lkdGggNzUwCi9YSGVpZ2h0IDUzMAovRm9udEZp bGUyIDEzIDAgUj4+CmVuZG9iagoxMyAwIG9iago8PC9GaWx0ZXIvTFpXRGVjb2RlCi9MZW5n dGgxIDI2OTIwL0xlbmd0aCAxNzg0Mz4+c3RyZWFtCoAAACAIIDQAgAAAwAUCeUxeMoJEQAZV JESsYzaYThEoIZAhBACejGdjoIFCHGu64i3IIBioZjgZzazDyWU1BAOMJabjObDyZo4AAzFQ AL1oaDKYTI5B0BXjBDQ8IiNjRSDCEhmFhFBVBERIaDadDxQTK/IIAmkbDeYzDQSSWIIGlxGT wcAktgK34KxIiIDcYTaZbIjIiFzgbzmdKCaGhfTgcjKcBK1iav4K5IIC18BV1Qs4AA0BVPQg IJgAGII/3PqXRqXO/jS/3RnwzsNkAnVEVxuo4qAArQCad+AMswgDUtQrwAuQAtAAyAAFwARA AnAAfAAlAAhwABgAWueAESACl5AABen2QCGX/zheAFDCfgAGb0QAVwAfgBnQsAQwf50gAP4A EKAZpu3AgAIMrYgoWAA3gARoAiYf46gALgAG+AhBgAG4ACYAA3AAOAAkAf4sH+Rx/kkf6KlK 5YBmQf5+gABbQAAMccPof53AKbB/pYFsLgASoAEzDIAkkBJagAID7oPGBOgAOQAE0AYugIAJ /jOf59PkEIADu+gAAIAAmvoAJgAEFcPomABzv8AI+AGIcfH+UZ/lgf6+IUDgAC6AA0Sq/YAh qAIjgEEICi4f4mn++oLABISxoRI5ZAAW1MAA3ZegAbQAgYAp4Raf6pAyAAWAAJMBOaABnTSA Z/H6QJ/B+iL0NQFIABzVUHgAXwAGOABoACEYAmCAQ3gLUIZAKIACj0f5qAACgABiAAqye0bn HMAJ7gEP1wAEP4BmMAgjH+IQAAdBJIuIABhAAYoAHCAINACF4AieAIrAEFNkgETwByoBFUWt g4yAA4TxkxYIAG8AIVgCWwBAYARngGUYCFWAh9gMDp/HAf92O80xNgBKRggCBs4hAAI5gCQQ AmsAJxgEIYBC+ARNgEcQBkoAhUgIaQDrbPwvAANsIgAVYAHuAIJACHAAiiAItgCNE5ACQ4Ak iAJMgCZoA2IdABCCAQqAENYBHeAY0AGOIBl6AghboAgpgIOcNgKQwCkWAx0H8LB/GIfxon8e 5/hkf5DAAKLrgAQIAXdIpPVa5hngAbPNQyABxACAoAgWAIHdIAOXBCAIqgCPfWACPwAwkUQA lQAJUgCWmx91z50gCeQAnqAJ9gEAHiAEAwBA3RIBBF5gBBGAQ5AEO4BEoAROYv7JoAEdgBHy AYLgGEQBhWAYagGHgBiyAY37gAZDgGSH4gGWoBnCAgNAIZ4CH+AtmrNEsAUT4BRUAFFWAUYS ogDAMAOIJgoCBmD8FGP0FQ/RvD+AAP4RA/hLD+FkP4Wg/xwgAAqUJG6fgPgAB444ABbS2hqA AWMSwAEXnKGmqBOK9wVABB8hNqgAQvgBDUAEOIAQ8MxACIQAImgAildo7YAIrgAi8bCAEa4A R3vGAaAIDjy3mguAEDUAQQgBBPjKAILwAgygCDiAISAAhJACFoAIawAh9ADAOAMBYAwHgDAq AMFQAwjpXAGGUAYdABh5AGJYAYsABjMAGN0AbPh7ADH5JYAY/wCAKAIB8AgIjSgEBWAQI4BA vgEDqAQTwBBzysUWAUZYBRygGAUAYNoBhDAGFwAYeIBwbAHB8AcKABwogHC6AcR4BxbAHGoA gMCmhhgASYLcoJQQAjgAGIEAYRX6AAEcAIGYBAMgCGdORSQAAvgADIAMJoAlbPFdqIgAQfXc ACBIAUPABgdgCB2AEJwAB4GleqAIYwAhPgCHtPydgAQlgBCmAANQAlrkcAMBQAgqiIg8AJNE doBBeRqnJN2fIDHXtsgWAAWRAwBK8IEMUAYMJRADGWp4AY3wAgHAIfEbcmwAgXACO0AQpwBh QdEAFuYPgClwBCAM6wrm4ABD7NIAQRSCAKH2AgRjEZ/ABowdwKgAQZABHxJkhIAp/nOBuAMc YAEONrGwAAdqYQACIAAJcAIZACBnm8AAGack3gAFMwEAYKQChuAMCoAwFQAjJAEGkAgigBAT dw8VoJZwcgBBIAEAYBVqxKC6AMTQBosubQs/sBTDwBiso89mpwTQCDwAKFJrDSQAVRcaHEf7 kg81JaGAGvQA1+AABKAQcB2TrgDBkARMB2kBpUQwe9TJqDOm7CDOxKZpwAQpCZEJ1SRlBk3Y apdMpYzhLVPwiIZxzSXACN2GcArpTBGrTIMsfx5QtD/FMkZLaIUVqSWkdsf52Ddm+HKAAR4A HaiFH8HtEYAAPOcYgEwAoRmL4TH+C0AVkBsgCCmAKGc1JqzWBKf4ABuTciuIjUgXYABFAEGu ACh4Px/iMH+NWEgAAUAAK2kcMQAAlAAMw0odwAMChIAGMCvg/gnACFiP8IwAyN27L0FEf4px /gfADacNA/w2AACeAAXkNADnoDCAdNlHRYABGkprBkawpD/kQGU2FxsDoYSc41Cx4xEhACGF UKgQQgA/B8D0HgOwdA5BwDcGoNAZgyBiDAF4LgWgsBWCoFIKATgmBKCQEYIgQggA+B4DoHAN gaAyBgC4FgKgUAmBICIEAHgOAaAwBYCgEgIAOAYAoBABgCIGCwIoIwjBgBALAEwYBYGlBGEg JGk9ghGBGGHYoJgw7JBNsvZuwNhbIBBtIWGw9rbY2dsLaIsAQbE2NtXbu4dmbj3AEDbwZtkb K3btraG1Qgbo2oLDeG7NsgBAgCCFYPNJgg2DsUZoRARggFwAELQUQscLFgI3hQWdijt4hxIJ vFdiiQ4zsUBvFQQgh4LwYDAaAibFADsQIu3w7BoEUEUMARNJgBFjrUIYIwhhlAVpMAAsQFAL 5yEMBfPhYAXBGHAWNPYe9H6SLEAQFwig66gAABADdnCwA0CMInLQM9c4Ly0AYJQilKFgFDiA RQiAb5GFnSeaQhhjBGGIWAAARhCFgA8FfYe6hD5nzUWABghiwAPzvnoLAQBp35tUAAiwQCxB YMARQjBcEfDEGAFYDAyAjDIGELgWJHBh7dsAWAEQV9OCJ0cPQ5AMdZ9N6jt4EghhYEPy31/S PUgX9WBsAfMQMBp2L7gRQihD7FFBxD0vp/ceqHJ2z5gWQs+tBZ28AQJdhiKCN4sRm2QlhTBB 58WAAhChZ9AAH8fBZHdkFh1/rvWuuBFDKCMIuxexhgDVsUBPdwR8wDUGDbwDQRTuoKQPIEIW QDQDQIAXIf64oDT+YRQKjiIEIWAH4DYEYLIMIIgDgWJaoRUAYWYDIIAEADMB0CAEcCUCkC0D DSYWICACLobooFgWIBwB8F8FYBgBsGsGMG7oYMsGEGUGjnUHsFcFsHkGAJYKQLDtTtgEL0Z0 79IEYJLfjbgMbYo8jiL8IEoHAEcLAMoHDFgMYHEJbkcJgALSYJYWAMjtLxQBLvwRQCAHUMUJ oWAAoEoCDhYRQeoADNIMAEYdodjwEOkOwEEPEPQAIMMPsP4FgALwMOsPMPz9DlbgDgSFUSAM MSTgbt4Fb04FQFTozwrwLojSYHwWETjSYGrSYOwXB57pLgMVT+UKoKD8r0QHQF76TkbzTzgR YXBJwMTScCQQDiEXAMkXQEAAAMQDZS4IAF4FYLL8IMEXwWAYEYLzcYYXACoKsY5S4QEZcZoA UZ4FkYUXUXkPjkgFg5wgYggCoWABAE0dcdsdkdwB4CACwCYIoNAHTNICzScc4iMdUeEf8d4E 0eUekewMsfAAMfQFj7oEYJYKILQLDgwRTmcJb0YJcCEiMibtsMwKchkhwLEMMjUhUCEkEJjt 4Cb2YAZ5T0YWEk4LB5J9UMwKgWD2QLkh8kklcmgLABjZIEsniBcagpQXAA4BD5AAknsox077 ICAMAJAEEpUpgLIBTkcij2IIbz8nco0n0YUoMocoso7EcpwXBUspksMsYJEqMqckMhchsh4W AHQFcqkhUjktj0AHcuEtUuch0mcq0m0uIBgRQAcizawAUiwLT4YBUvcmsj8uMI70ErMo0KMx 4EoJLbwAECDT7wZbD0Dsb9MsQYAHEzwHALIDbfki8zMCELE0M0YEE08zcnrsc0M0M0k2Af8z 76D6EMccraD677DhYI0iQRQMMsQQAMThcOwRQXIAQYU5QRQODmUWEWUsQXQRc0gIwRkZspZr IHUFZ4gIQWJYwRAKIWIIAAIRAKch4XIj4AAEARECAWTXxm4MAIQLIWKzM8ILAXMYpJs9oLE9 4AU+M70+09wAQEFAAAChsxs94BFAE0YXJJwg8/k94AlBlBwggQAMbhqudAdBbv0+dCogdDB4 lCIAQCFChJx4lDBMtEYIFBk28lZm8CEtcj0m8MUkoiMdCYDJQAAIYj4fQV4fQPU9UdDEIjkf hBQLYAAeSFRlAAAA54oAAj494KwggAgVgf4f4854o5gKgAYFAWYEwDAD4aAXiwYACbBXQASw YWQFYDoD4XIAYE4AYDoWQHYD4IAXAAYEYWYCQCoGQB4IIFoAcYogYF9QQgU9dQx9sYoV9QwX 9QxMoL4AbB4gYCFSRAVSwQFS1RjB9RzB4aFSw7whLB9SrB4EFSx9rB4T9SybDB4A1OQAYDgW TUACAINOJU5chU54iPo6Rto6Qf58A+QD9YFQo6QJ9YFSI6QR9YFVQ6Q71XadFYB9o6Rcg6VR w6QeFYA7wIB8AWQSQGdO9bgRdb9PAC4WYNQNgGVcAC4WQMNcZ8AWYLgLtdNcgWYK4LNedd4J oKNfFcoIgJNfgWQHVd1coGIGlfgWYFwIVg4E4Flg4CQEoGQQFegBQBoGQYAIICwAZSNT5SJ4 gOFjQgQAQvgB4AIgaFIUCP0PVlNNNZ1kq7JJoAYCQWYEgEwGQT9RxMqzVNIgZhID82q4AWQB oCIGQIIBQAQf5tgAACS7IAQdwASuNns2tp4WYB1oYT4IIJRnoAAV9rQX9rTXocRnoAQcNsZA QAS4tSls4AAH9tSg64try4oZ9tSLK4p5AcFs4AQb9vIAQb1vgAAB4AQbootwNtdwhnVwSg9w Vr1wSLNwQA9wNwlEolkdAAVydKFytwolk/4blzFEobdkIbYAVz9wAbVkIbQAQbVqQaYWQG4H IGUBRNV1YFYh92AAV1YD9iF2t1YC4Dd191QWQCQCwGUVQaQWQfIFNNwAYE1WFOlOwXZ8QAAH yvh8QWQEoGID9PADAWQHgNN7AAQcYWYEAFYD4UAIIGAARab8JaZ4h4padEpadApaYKF9AAAM F+gOF+g71+waxEaOgg9/yN9/gUF/z8N/lUN/1Et/lAoZU9YAQZmBt/l89/lFl/l+d/lBYaFW V8cVQZ4WQEwIQD9jCcgARYQ6QD4AQZoAQ6GE2Bygg+2E4ZYAReeFixhebB+E4ZSggWQDyFII IBeFx4pYVEoY1y5YQF+GQ84AQYNmYCVnwIICIAQy1k2KNwYy1tgyyMwyxnQywR+Kh5FrwEQW QMgD4CWHwATFYZRgtphS4dONWE6/IURgoIANVOwEwIdf8EOO9dIEwHQHtdIEGPtmwEAT4EwA QIAEwSwTOP+ROPYRwSWP+R2PYQgRmP+SePYPQQOP+TGPYNgO2P+TuPYMgNWP+UWPYLQL+P+U +PYJ4KmP+Vl4ZgIW4EgE4D4G4J4NZ04INwBMV85MVFhMV+ZMVCZ6mYgAAfJMtpgTYWUTl7wT QIAFYFIFQD4QAXREqKgQC2QQB2YQAMpEp2AQAQJEoHhEoLxEpiQQADhEoDxEs8gQAXZqVQ4Q AAIIB3IQGdud8LwgeeQHIIADBEoZREo4AQBmAQAExErEYQCzIQBlwG9O5RIWQJNceh4IuiQE IWYINhWh2iwHoH1P2XRRNwpMAP+kAhVrxMFuRMFpBMAhVFmiwEAEVeZRMD4D2mIEQWYFQH+m OiwFwHQGQN4IIJAASaOkaaOLqaNvSaJMuI6aN+yaNuSaIhVwCaNtiaJnSaJNSaKLKaNpCaI7 1vQrYgeLusFv55lwYrdtgrZnQrekYraLIrY72kwACLJMB4gN+kGkZMFrmldwZMFthMCM2leo WwR5p5oEJRIIADoCADgCAFYCDIwR+dIB+dYJ4Dwf4DwARDwCxSIgjVwBACLhoBoWwe4BofG0 YAABIIIBIASb7A4DtpiN+1tpgR941NrhoTGDwXeEKxQS7BxLK7IAJXmgwEu38LxvVkxQoAAD gBG44Gm5IARprLAGQWQDgK17AAIB+DwFgD+apdgDxLIWwD4fIDgcgD4dIDkVRiYD4dADm3Ia 7hhLIWQD4au8+5+8AagDgRID4ZIF4XG5e+IXgEzhoAO+IXThjX28AXIDgHAD4VoZQXG+AD4Q PAKJe+IP3CYTW8APoDgI4D4Ne8/CAMvC++ILwOfB+eYB4D4KQEwLQD4JG/AD8DIMVO3Eu5e8 AH4DgLwD4HnEQD4GvD+9IGG9gD4FfH+8AFW6gD4FO89ku+IEYD3E2+IKoG7hoNAIAFgA4SwA 4LAA4J6XwA4GQA/K4EIA4D4A4DoA4DYA4CgBACQBACABABwBABgBABQBHOwAwBAAlBaB4Cks QcGZ4kBagA1IQ7uZAgYAnQlEvQN9lQ54oANBbH0PQCcwMwgKYIShkaJHIJYMTYoe0jjhoBUv QAru8RYCQJdA4KjvAHAFYJcoQf4KQWAG/VjwgKALYLDpYAIR0ZvVb8IRFDMCDhof/XARwQs0 j2U/AgQAICIQoRoDY5lkoFHZj6A04CwOwH4DAH4CQHwCIHIIwInbfbvb/bnb3cHcncbmfcrm cTXdfdkTQDHdveHd4DoWASz7r0AVQDsZoGXexPXfMM4Sb7zz4XJ3w47tXgYePgoIj8lN6Hoe QIsJHgYeQAYH3hQLPVpfngPZBlwePgwAGg3jnhU/ABFUvh/jXkfivi4TXjI5jEfhwIg5izPl 3hYBIBK4XkvlnmnlHE3jIWIOYEjtU+vn/kIXIC8YoOfm4AAOfovnRLPngZTsgIgWIEvqHhYC whAZXpAZXq3lAWAH3ngDgDnoAD3sPoZe25PpGdIDXrgK3r/sgWIF/snhYAI8fsPiG5PufnS4 HtvoHsDtXhYBq4vuvZADnwHiveHw/xHxPxQFYMoIUTQAIWYHYLIMYLj+D+UPj+HzDZARbl4D AWE4gEDx4MYLPyz+aRzY4MQMYND+jagMoWALIEYMr1LuTlIWIHfyr+P015QMH1P1f04MP1wL n2L1IHbrgWJC4IsCAWILgIH2VOgIAHbYMDALIWYI4KAGgG/0vzAMvzQWARPzvz/Tjx4GgKH0 v1n3n1X1n4Ds/4YWAGjrjx4I/7P3P8/3v9X1wG/9oI/4xDv5PW4gA3IBlIiyI5AI5FEZhIhZ ABLKZCAJLKBYWIIABCLJDLkWjEaWYCBYKCRDLBgDYhLJCCwQOA+WElLC5HYhDB+Da6AgAAKo AALFZZWAMEZCWANosxky5FpBps5nc7n9BWAOpIPpMyXM3ms5ntSoFCCFJCNFAArOh1OZ1AAY IppIlvuNwOd1Odpu51Fd7tF6vgru2BwWDwl8IqwIEMu4Ah6wFRTJawH5RLUWA4Hw5AMENxo6 yGSykWBYLIq4f7AzcOyIuz460KxAYDzOpxusyI814JBOl0+pv+/4F8v2/jkzACAAS7WYBIAe AJ0ABzLIDWAeJZUAUx65apRcyq6ACfAQinnRh1oOYBFYBOfBwF239n+NyOf0+lp+1wuX3/d0 372rO9q0vc4C8vbA0Br2Oi9sYAABADBoCgBCQAAGAADsYEIIw0EsNBDCCdn4EABmAfggQkfY ABAAhgMZCwkn+FoCAmAwggAFQABiAAcACaggBKPjnAIGAWBsGwXiMEIqhCKAXi6Gw1AGMYXj 0AY7hCOYXj2GxDhCQAXkcGwIBi0xvFuBYcg8EAQBIGgWNMcAgBYEARhoNQEBwFQLAYG4QAsF QYBCBYAArPgY0DQgbhCGAYGVPgKAZPgYAYEIbgIC4ZAMXABFIWwoAKAICnaAIOF1TgAA2ARW lmC4PmmFZcACGogAUCgKgsQALguCkJBVWIblkAIFBlWIaloFJpgCBtSgCHFUAETBZBqOYTNM YFaAkHIYBMIATEAEwB2qAQpCAB89V0D4PzWHAcBkGQUhTXwAkmIALUICgKL2GIYtGBQFBgAA gOOABoAAndNgYIAEgKFw5jeCA/ggAQIF0AJHAAA1m3KH4CieAo/gKR4CgIAoMhyY5FgwFYnA geguiadp6DiduWi6HgIZvnOcZ2fudZ9neb5cFeYnaAAfnpnuWh4H+g5ufpyAhp+oi6cgIgkC 4ckOBwXBXrQ+mIB+wgfQ4MCGPIgCVSoGAmEgShGEoRBKAYDAkEwHAeBoHgEA1FBqJ4AhmFG/ ACFgJhcJ4AUnw4ABsEocb+EIQBuHAaBOGXEBmGQWgiFe/hYFYJgoF+x8QGAYgZQegBX1WcdX nL1r+FQVhUQJAvUFazi6AIugKGoXAEE4bgsC/hgiEwThMEwahoG4bBuGoZ1v4gLgP5ITgj4Y PAECoKAMA4K7mA3ueGCcjeX44An8Q5Uj2BRagqGomDUN46CsLpEC2WY1E6Lg7AwLoCAZQsCI BYFQNQOR3C9DUGkPIZw9wLESGESI0xaARCuMIRgIhIhEDAAsAQPQKhBBgKoNgwA7hQAkFYKw DwmhiFWBwNQcQJD9HyCICYJQ1CSCqLsfQCRbAGBQBARAXQuB8BKP0CwDROBzDEHcF5jEIB8H 8FEAQYACjTAABAAAPVaAnAehACAEgDgIAgBBWIMxZnhAcAiM4QAIgHE+A4LyFQIADRGbEVgE ROiMZUBAewXR+j2ZpIJozSweKHd2AEEwAgIvMecDN70kQKgQACAEb4lRnBNC0LwQIeQTg9BG 7CKYvAAj4ACA4dw2h+j7GgFkRQlhdi9H8B8fwIDyxSipFaLEWgyhAAYCgAUQQBAJAVJQAAEg ExnFmAoT4AwAxnFoeEAYXgHGmHgLSMoAgqzVH+PgWjYZtTcHILQBoDZwmmHYuVf02gHgOA+A 4AQDhWASj3H2P5f5AyDaK0xpkiAugTBGACRryKCAzeGBaSYAh+u2L2CIHoJw9CBF4FoJoz4p gBHAAEcIvBciWEUFoaQ+x+jaHcP4eQ/iMIQFUP4bwARBgAGaAABQAAnC1AUhYA4q1NABCgt0 AIAweACQeAoAIPKZACmdUBjAOADg6cQF8AAbwAB/AAKBCdVQFihExH1lw9GoDtZy0asDO2aD 9VG1YHKhwZvQe494E6Rgbi2GaFAK4Mgcg2AGM0ZocRFgmCaBkMIWzyhBmeAINQAg2oVAACwI AGQ4ACDgAMAQTQAhNqEAGgIAgNAFDgeUDIBA4CNZUywcgXQIDmAAC9mChwABxd2BMGoIYQgC BTM8WotTGACAAFUf45wCARAKi2LQHQAhVFjUIIYVAsK0A0B5kgFAPTlAvMkf46Jvt6CrdQdF jZyzaASBEAADJwBVAAnsBk2rw3dvIC8vgzb2ArpiD8dt8lDgbFiAYAVyblgKubc+6IDbpmmH pdcA12TTDmnIA3At1B3WNNHgu8AEJy4FiypHCgEMH3rvbe++FYr6AwA2LQAwIAMgQA5NYWQA gQALF8P8cF5cXTHxiA/FwQAxAEAMIcAQiAFiIAeMkBwBQEgHAWBgAQRQJhMAqEoDIQwNhUAm FwCoXAMhSA2GsA4awFhjAmGwCoawMkoDyAIO4Bg7ALD0A8Q4BhMAHEsBAZIGBtACGsAYawCx tgPA1f0At0LpBzASEAEKdQYAJQgAkCACZhiQA+BEOYAFrBAAdoMGktmBW6EgB5lE9gutDj8F 0OLQ8PDtn8HEAAXUdrsXYs1dgWQsgTjCDZzIFgLASoSAYEYInkawAs5kGwEQIAm1yAfAoaxp igDsLIOgQg1DTFCNQPIkRcipD4HwVIqQ/B8CUF0ASyQCABB6KwL4sx/D/G0P7dAwxWiYFuAE To/hLjvHgAENAAQ1DuDSIaKAABv25H3cGmQABXhARGEABsjQ1gED+AIR4AhMgIAIKzb4CWMA FqQwsAN5wAjKpnpEBWlGAABlshBOE2GJXkNMOqN14wAAcUjegB16tID/HhY1sOF8LXkwlgq8 gGgGAF4MA8GgBdI6T0IqAEHQOLMlAWxUHgARCltZWBC0uoXVj2ODqAFYPAms9aMD9rAAQI1p Bg7vU4K9BgRAM94GtcAZgCH2LQII0wqCXHEC8OgBA9g+D4B8VwRxlVQPLby3wIQCimAAc4K1 x783KFyTw0/Br1KkAcAoDwFQKgcAkpsXYQAFgPAIAQDwHAGgOQgAcDHKbrza9SP8dWCfWXvv de7Ua2QXj9GIBAYgK76hABSBIBmEwqgP+DzwJYGg8gdEUB0SwExTgTGGAwawDBtgbAQAkCYG AHAqA0AMBIMACgw6bjEAeNQIATAUBUCQEwJjKbuBQBzoW7gNU2KQIAE/K+X0kKCeADm7ggAK gAvMPNPOBbvQAAhpmBOSAAgMOCPRPSAIgvgIGHmIhHgIACAIBAADg5wGuQAMEIAMAIMjPWh6 BbvhAMBIAQAJJSAagAIvhKgAAGlmhZAHBagAmKlnAAPIgFtKNLEHAANGFYhJBYmUurtOmiB6 JBgVutGYmbKxB+mqL5PbAuuxknAIGaByBDgEGuACg+vdKBFspENVEeA4tOiggJnhNegZAbHz tcq3AJrZAQgBtZAZF7tiNcgTAqhegKhMg2BBBaBWhGArhGAUBUhHABBsh+hbgnhCBIhgAAgE A6BGh6BkB+gAhAAIBFBFhiBRBNBZAngfgLABB4hWB/A7AuB/B7BohjhIhZMXjygwjGACALAC hTwYgAA4NJBiQZACReABOIAEgBgGtIDkggAYEHgCAEvgg5jYgBNBE6gngBAvgBA3qkLNAHgE NAB1gAG/gvgAxpgBgfxvgAg3gAg/gAtvgMpqgAwhwimWGXA4uuQkmWB7NQuuQruvgeGegcux uxQwuywyrYLZADEKnvARgbAJAJAbgwgBhahGB/B2glgbAHhcgBhBB5hEgCB9RAhKh/AJB/B9 hcBthWgAh1AAhjhOLcrdregCAMuAAPEbgAhXL7vGgsEzgPwPgAASgIvWh7MCAqwSMEsCvWua gUOcgMAIvisCtgOcyeAInPgFgUAPJ2p3gngHABv/AKAAAoJKpnvIgGgIO1Aqx0PRgGgRAPFe NRvdgugZQph2gZR/Acgcr3sOAIBmhqBmgIBuhir6vGL9SbycydvWvXrxzBggAVL1SkFIrzgq ynSoSpSqAHSrSsAHStSuJKwHyzS0EJL5L5BiS2S3S4K0S5gVr3y7S8S9S+MQAgAaAdANAmAL AgARgtgLArgRgzABg2ALA2gNAzgRg9ANA+gPBGANBFgPBNALBUgNBeANB1ALBzAQB7AQAJge gLBPALBWgLABgdAUgyL8AThdMYgRsagMHIsRypSrAvv+gHAOSzleQEAoDylNg0BaTMgPmKgc ifmNSeRngaAYScwQwRhIAWJnlmpohagSg5gIuiwegIo3JGBIAVtNwjGhwktPtQh2p9h2woBy QpS5gutSOywxtTrXAutXQ0NaHMgfABHlgTu1tc0WAaAANZgJNgG9w8AAgaNhARHxAKQ1AbA4 Tsg+Awgpg+goAbAAgbBdg2hbB+AAgDhjBHh2g9g9B4hRBWM5hlhSg6A8BZNqA+hQgAgpgIA9 A3AmA/hsA4AGAMArA1xIBsBvgAgIBNB/BxqTB/Bzh/BZhXBfgBgaBNhbBiBOBGBXhXt9yUkJ gPgCjwNDA+hYgJAFuPAJgKgaAEAMAGRRAqgBjTLtgQ1MJtAEKkI7IxgKDL1QgDjYvrgCKhMh uII7O1uiB/h2PVgq1Yh5PPL1ACvgTGVYh7ggANMMgCgusVuRAFgoAFoOg4AFhAAFgCgFvrgQ OSSv1JtKjygQJsuUB/yfOWDTSfOZDTB9PPOXryACMMuZh7haOcuZh8FaPhNTgFAdgsp7Osut mktQB6C/mnKjJ+AeFsgcuxS5BDgCGuBDmvyaL9PHvyhwBbgGJGgEAQWG0ZC9gslDi9j1Diha AEAgAjAc1NjThbWOWNK7WPBgBbK7ADgRGTABEyhbGTWUK7WVh/hvWTAc2UARgc2YhvPPWbgD zK2av42cMBBbAJ2fgO2gh/h6BbWjWegK2jh8BY2mjgnbi/j5WJgZgIgZuxWrgRuxBOBjrJBd Bjh+B/VFh9hAuFB9AjACBAB9hAN9gMjGADg7VFi2gAhtlugUgAATAIvfgTAMT8tfgcgJAbAM AkgAAjgIgkgJAjgMAsAAArgIgsAJArwQhMAEBMG9WDrlAgAZpKANAMgV1KACgaAGAiACgiAG AlgKgqACgqAGAtgKgyACgyAGA1gKg6ACg6AGA9gKgHgClCkLAAgJCMAEG9VQgArdAf3lXlGr GsHdTRgNjmgBmSOLHvAEAEACgFAFlIgEvSmwgGAKAJyEnpAMAMAKjTAeBZkJAMAQX0BZgGUa 32h/geAgAtAK1oEJqhVogAAKJKi2gC3rvLgMFbAKgMPgDdPLgJYCUarxAH1rgIgKIymrRlVL AKgCgHymEHXfufgBwQmwjdXrrLgBYDUarwAEANFdANAIAgtDAokVLwgA4XQA4XGBFQAohbE1 yugMgMlYhFhYhULRma3PuugNAMB+h+3Ph+gMAnAiiCLUGmGgYoGf1+uw1/TR4r2Agm2CGvhD gXGVWChiYu4v4uYvGumvi+GtPdYwgHGcY141Y0hiY3Y444BiCJhYAHjPgIjQhZAJAFSetW47 ASjPgVDQvHwdBgAcDVBYAFjPgHDQ33kTggNW2KOyg5AukPgZgJnhnnHAXxALnnAJ2s2uHjnv JKhPB/A9hjhvgSANAcKiALh1BpAngRgOAWhzBhh/A3Bdh/BlgTgDldh/Bk1Fh+AfhLhKh1gS ABhvYkB/B2B5hFhaABhXW0gCAuhGAQAygjh9hRwfglLqgCAOACAfAAAUAAAbgBAWk5XugEgV AMgGgNAVAUgGgVAVAcgGgbAKgbgNgdAVAkgVAugGgugVA1AGg0gVAwAYBFAGhDAUzkBNgNBU gGgKgUVOBaMMgT1OMHAFsChTAMhVAUWWhdgUBiAMhngUBpAKhugUAEAiALAAgPMBI3OcyEuc gCzFsCgak4AgAqucgPlWmVAWAVAaAcgCAcgWAkgCAkAWArAEAsgVgzAEA0gVg7AGBDgGBkgG B8gGh8gVgIgbgaPTQMAXk2lMAQgKAMAvgUg3gUraAOAXgHAfgHBHgHI4h/sgo4hXgHB3yrgH YGpzvXOTa/h6QAIysC6+vhAHADObptz2ABgLlNhVBbAMBKgKAOAOEMaYufAGMKAigTlhgOAB gFgUgwgIRYgDOZEOgSJ0bAgq7VVZVcJzbWgCVx7XJxjRptbXMBsM7XBuPPbC7W7FAHsC7XB+ V07N7WlNgttJATmBATNggQATFthXgTACgclrBaP/JtFqh/hrBbbsgqgTAY7rSvgPNCAchgWc BQV/gc7H2kAgAg7fgLgSgMARaxhfgDBnr8APgDAfr8ADG7rsADPiptADVLzGcBbbgq8EaN8F OYueADAIOcgDAYgcI/OsmZwknVutOsQlmYj3R9AVhyhysPByAVr5Gnq0MOC9tQB2g4q0TRx/ GsLWQzWLQykGA4gS0XgRHlAaK4Hncf0W0dq3UVtZqDvMUfALgRlwHvJ4HxtfHmgaqgAyBcg1 BXheAjg5gkAag1htAznAAihEA/vkhYAMA3BoBEhEBVAoNEgLgRBeAOALgxBiA3guAZA2g0g0 BRATAOhBgqgjBVhCgnBAgnP4Z3m2gFA3AWgegsg4gMK+AljEglAXA8B4B9hCgekeaVAOAIAU AmgXgkAwAtgngeg7jygoLqgBh25xAAANAAgtS/XN6wA/ovgHgFjmStxcLFACAJAOAFvUZw9b AHAKox7vgD8Bgq9jVxgDsMIPdkcVS7hjNRvdS2dpgZPegjxlAAgPgOAhgJghgLgpgJgpgLgw AJgwALhNgBBNgBhNAGhSAIBSOfAEAGgMgFLDg0gBg1ACg6gGA4AGhAAGhTAGBaofH3FIk9hD AGBxqkAHARAvgHg3gH9ZgBov7IAgA8mAGBT4gwdchIKqgAMXh4AAOKGwlBmDdedfAMdgAOda ASI17EARANjygSCgAP3/SuvPcGDmbfgAgkOcgAgNPhAAgkgOAKgSBngD9tADgfgDgBWesMgD pigIMCgD1d+qAYgNgaBiV58VmZ8LC+Aug5CIARgl5CvIZEAsh2g5V8e1Pay5wqgIGqe4hycZ 0Sg4gsgAgL8dKBAaXBtZnqHkw3cnQ1qgBYgOh3hXNzh7g5B0hEhWhuAPhXgMg/gtc0hSBCA1 BHOoALhbhngAriAFBWXkBAhXhQsrg2BhhphrBhBBSVAjdUBv26LwLiAqggBSAFABRegSgGga AGgiAGnegKAagOArgBAqAFApAKApgOAzgBXZAygEgxgKAwAOBgAPhqAChqgJhugMhygJhygK B3gLh1/ugOhwAPh/gPgLF0gVgNAeALAeANPjg4APtGADnfgSAGgXALAdUWAGiAEsBEUGkYKE kOFcFFYGmcGuUDOcLPoAvQHBAAhUBg4FhAHgANhwFgcIgAFBUOAMFhgZgEACUIg8ShAINAIg EIBEgBEwBFABECB8gAsFgIq0IGg2jBEJTSlrh/vSdg8H0sDA4HUsMUmnv95UOiAYqhGLhCxB GoO5aAwGWeoPggEKk2c6BISL8Ds8Dt8Dv8D0EDj8Dk8DgMDh6iUYDhi2YoPVwqgcGWHIgy55 ENWyxAcMh4aFAMCsnBB6CvTacunEmu1+6fXag4jwIO0IP0eOQAD92j8ebreBEc0wcjEYAAug E4l0AHEQjUDCMRCYTDUaBIbDMZBYLhEZzcKBbsDbqCboAYBjgysQ/tU6mpqIMwJYXrN+iBWH U7KVUHs8KFDE8Rh9lGT4AgGRQoiCAQHH0IwBAkZhlGCYxtGYYgAAAAQACWf50AIDwCB8AAKg ADoAimIALg+AAOAqowBi6AougSKoFjKAY1gKN4EjKBYEAqqByFoy60H+cggCky4Og4y4Tgkb ICn0Ch7A0AgYgkHQMhiDgggkJoNCCDgogkLgMikDgwgkNoNDCDg8AMPAKnsAR7AwCAAAsAIH gaC4LigCwwAsOALAGCwOAeSAIFACABJoAiQgUA4AF0ARVAAAJ/mAWinCqAKoGAICaLMKqMAC AJKgmDgCAWC4gAaqBuSEpQq1cf61MvWh1LWttZ08IAEhOFQaFgBoAgaDQP08WYShMGlkUwIA gg8EYaBgD4Ag+8AIBIA4gBJYIPsCwbCgOEDEsixgGMVJdZAOjgFs2DjNMiCzLs4zwbtC0bSt eLoViafpyNGOLTHtgbTtW3LWX6FZyN0CQcheLoeH62IAuEHOHuIALlYWFbkDkAILgM54RAAC M7OxkwKAOEILPAGQbACEITBO8gRPMLxdBYdxcnSfx3gCChuGqAIHACfh0AUWRCjGRh+m0AQo gYHArESPhUgCKwLlGWlrwKAIGACFB/G8fx8ggEBXl0NFTEMIY0FNDAACEfwogGdUQAADwABU AI3iAMCiAKCgWAWEoKCYBYigoAwEg6DIO8KE3CBGHIFhsCglAWgwrAOLAFjQBZ9AUeoKgcFw RhYE4fBGHwTiYE5IBYUAWAOGwQhsFIfhYI3NhCIoUioEIqBSNIDjGEIxhSMAWEAFhtBOdAQn cEZ3hOCILgsA0fgEWJaBQDgJgPTtKVAEAAOKMAADgABAAAYAAGgAFIlwAQ+iAGQCg5QwFCKE S8QFAWAqDMEoMwFAlAwBgaAFycKsAuGAC4gALgEBYUNdIVYKmQAuU1RYVQLlQKkTEqsHirlZ g8vRWUHx/jqLAu+D0HCxQqLUvKFQ/AgBKMuBcOgDwAglAACID5dwHjPAeN8B4/wHlBAeD8B4 TwHgDAeuUooVQHmZguA8ERkAHkihcA8ywDSxRVXkA8DIKwWB0BCZ80Jol9muNSasehtDWmvj cbE2o5B7A8YSw1hUfGGg8Y0ak4wcU+HaZeDYG4NgTskAEdQ6x2ALg1O64xkgJgJnfPCeM8oZ hXgLBkEMOgfREAYaMHYWA2x4BuGiI0XgehTBlG2KAXw6hMimD6HwVArQ9B4FQFgDQUQSgyDI FoG4sBFgBB4N0TCpRGCYEAPwNQ+Bnh4FWAMFQ0RgC/GYMMYww0LkuEOhcAY6ACi6AABQAIYR cp3UwLMCoFwaADKgOAIADjLglAIDUAYRQBi6AaASeQ/56A6AuBkGgFwEARAYBECgAwCkui2A UA4FAFgKAYCUBIQAZg2BoP8BIARgUfAsWAo1I1NgJBRScChWCjAJKgOwnZkAEgEMaFUBIGlz UuH+PaFpYgEgUJpT4t5QzLgJAUVSoVOxbLyASE4CyvZ4UcFgBYeAFgBKCFABaqY/wLAEqsBQ EpLlegQo2DQeClkLvnfkOAAABAAFQH0pqDtbx/j6RRSwKtbaagAAQuatplK6V2AtUivIAl5I YMuAAJwFQjmgBWBAe0dDTGpBWxM2VlI22SsmwMdpuTem7OAcAALGQYBDDzPUq4BwSgOAMAwD axQEAPteABjxphA20X6AEFZ3TunXOzAICIIwIg0ZsyMCoERDi0D8MAOwrgli0DqGsKAjQeTl H6PISQXRSCcH6F8AQoRDh7CmI4Po/RdtyERN+6s5gBvzAAM0IAXgEg2XME8BIkAEigASLABN IRvgJHgAlSICQPgJDgAkQACRP37v6Am/44AE0eAVgUlwAS/gCAGAk8wfiXAGAKAYAgCgDWqA LW0T4BBQAEFgAQYABBwAEANi0eABEMgEBAAQaGLgCY7LfXIowBK4V3hNjumuIVzAEopC7IEK 65FiyWP5WOTioQ2osrsAgTgEWNNDZCzRqQ5WWNybw3TFmHnBzLIEOTAwJySI0dwCIiBaZxAI OsZ4zx9gVAICYfY2pvgAvSAAAY+JygAKKGEIAG7Wr1AMFYAwWgExQAaPMAo9jzAJAYpsA0IF dFGAVpqmtOh6abCrQEdCoDL6jDuApBwBgQATjSAgqA8BZgSBODSnQ8Baa0OqAXWOs4063CAI TXWIACAFxgDcBIR9iglAMC0BQWAFB3AGHUBQ2gBjjxGKYAwAQRgGBNaoBAOQDA4ASD8BoTwG hZAIFkAwWADhZASH0AgeQCiZASMYAw0gCDWAMOQAw6QDj3AMPlHwEgFAKAKAMAeNGRgHASAk BHBwC8QAQCUA4BmV8X4WAQEoBQFAUALx4BWGuFgIADjXD4BwEV9AWSbICeVfbGXkAUEWsOYA hBAuEAQBwILyAOBoSCxAGuGQxWEAIkFLA/AAE9uRUB/BABjXgAAEDIdTr2AqvwErAASsOAix IGTLDhBCEcM0awnWZNgDwJpszZsCsiF2OAK7Om8AgbI3vd3sA5EOAUFwKwCB9AgMTvYLjQgO 8AMTngCAeeKAGBDxXihYgGAEEMKgWFWhLo/gUQgAwBAJK3cO3AcQssaCGFzy3IwWAdBzxADo HQeaZH+N4WXqvYDUFkCDcRUBqCxBCDk14WTlHJORbQFfpQsTrAMpgWXvaAjAFkBYHNAfZAQ9 z7EWX1PpCyAZ9EqA3hYgL997+3RpvjBAAkN0AgAQEHf9X+sCgPOIAU/f7AewsgMfVHYLEDf4 TTsbCyOMNeY2YGt4JuJa24wszea6FUZ8DUACF+bKFCD+nKH4F4ACFgH8DsH6DIAEA+D0H8C2 z6EGm+Bu0GvaHGFsAKvoim14naBuBwBpBYGAFmBoOpBiFmBgBjBgWSBEBLB0WeBKneBoAeAK A+AKE+AKG+2MCfCQAKHg4TCKDgAKEAAKH+2MJcJMwwrCrpBlBcBpC2CAgGOoE+UsfgrOQyAA rUAArYrcx6U2sCCAA66kpoguJMr8ySLEr4qCry6cyjD2H+H+V1DwymCAyrDwCcAIy0sesiy6 DiDkNMzAB+B+kDEajpAIEGFonKQYz6nCAA28byBGACGOnWAaKjD61hFKqKKgGwCACaAWAaBo nwHIAIHIASHCAuHKBAAKGq0mBAAEoQBABG88A2BA0eAGBGA8A4e2i4xGACOeA0AyAgAUGgrC EgBKFABKAEBKT4A0AcBKEgJuKAU2AiAwKoK6pgAWrwoYpqSI1KAuXMAiAEMooVD0AiAMsISI riXkSIHxD6LQY2CAAYAxG8teA3HIhGA2peKGrwA2AoprIQVqJ2XMA2VUhcA2AVD1Ie6fFcjA CqA2AYsJIeH5EDI6FxH+AsQwBmBGrCfk6OAAFAQwRU6U6Yva6dDg6k6oVk6tDoMmimTusAym ybD8KkAosIJMsOntI4AAAyBIBLJKDwFm7GscjYs0BWy87UYANJKoC6Ha7QX4H6CcCKDKCIHN Eas8B4N6N47WNoHa7yzIYwOGtKtOAcAYAoAmcmoWteAkAaAqtmtqBWECY3AANMt4AqBst8O1 MOuOuEuIuLMUuGuKe2uQFCBkFMDUDsEuA+D8GUE8FUFmBGC4B8DgEoFoCwDICYECB0zyEqCc C+DECwF0FeFsH6BOAEE6DYC+B0EqFIH6EuAEFkDwDwCgE0EiH6GzE2nEHMbyTwfuAm4SAMAm AEFQAgFwAgHGAGHOAmHgAGHsAmxA1iCAB5FcBoDyIwEwJqAwHAAwH+Awxs/WAcO+AkA4olGa XoAUAbLmAcBIAwVAg7P2XMAWpSg6AWpWhMAXISAiMgAXDmKMAWBFP+hAp6RoqAVFQMH+HyqJ I4oqsJQqp464V2AWo0o4H+AWUvRIAWCcAwV6A0BoqkAwHgAwquAwFAAwFgAwGBPYAw84BmAq AtC0KgHsFoAjHhD8rjDcyCAvDk6ur9IpEErqKmAfDwsMV2rasSV6AkrKrPCvDTDWsUAusgsp KossHosuYGHtTBKoNMHa7ss9EjLYBytHLgtMCAe0AiqM4iAOAUAGAMAgBNHqActeAeAUAlL6 /GBVMAkFKqDjMJMOkNMdMYPKuOEOFEDqG6DAFCChGiFoBUDWCQDmFOzyEuFeCKDgCaBkvKDm AEEMDcDaCCEkGYH6F4QuQyCIQ4AIBObyAbKUACDWFsAqK3I4AmKgHRD6AfWECADmMuAzV+LE AlTw7ACOAMCQAQ0YCyAQDOAMDS5WBoAgB0SuAsBqAwCKAgCWAkCWAsCKAwC4AKC4ASCkAgC6 AkC6AsCkAwDaAKDaASDIAgDaTSAsDIAwDuIyw0AKAaC2AGCoAKCoAUC2AYDYAGDKAKDKAUDY AYAUAuVSJIi4AoBIA2VaVlY6XMAOKghYhEMVV+MUAhZC1iFoMpZEH+1wXrZWsJZc1w58V6An KYWofGfmAgXIXGBiG/IIV6CSWkWpIJPyAAAYAchGABL1JyLZDoi4KMAAXdDxKRDw0uVETusO W7B7JibkBjRWXxEUY6joNoYGC7TNbLbMYSN0Y0OSOW/KASCmAKCmASDEAKDEpm/8+INMAmAg kSZSAqkoOgAAkukOk0ZuCIFIESGKG2ACAsD2HWEWG+H8HaFyFkEOEMFkFmEKEOFkAEAmACBO EcDsH8HCH6GaHWEEACA8WKGYGWGYGiGKGWGUbkEOH8DSAIBCbyAkb0ACDECAEc0uBaAgB7XG AgAIB+BAFhF6A+BABSAYBGA6BkAqBkA6CEA6DgBAEgBAAQoIB0A2CUAuCUA3WrYYC4AuC4A2 DUAQDWAYDTX2AuDWA2GABAGmAoG6AwG6A0GmA8HIAoHIA8HABAH+BAAsBGAIseBWAqBqAIB0 AgCMAICUAgC0AgHKAWHWA6H9ZSLIUIf3GYAMUKI5apKWGgAUJwAVEIDAAUEAAUxspICqBBY8 04KgHMKHHKCqAVZPh0rg1E06VrZYhdiA1CsJiA1KBGXkAUDoACAmBmAEBmAkh8feVKEgACFB AsACHgACKCACB+ACCea/EHDihMJwMgJwpqJwXMbAMoU6p3KDjchssHSgU5agLEtGMuACAyA+ COXwt0X1K1Ea7UNqHoHINrEY7mN8N0OAtIONAEDkOWAmO5MLUZcGAEkqeuAGkwZhcSAMEOFI B0EkDQEQGgDUDqG+D2C0EeBcAiFMDsmoFODoDmFjdyAKF6QOCiEYH+EwFGH8H2EWCYB0H6H2 AGFIGaGIGWGrdqGuz6ELVkGMbyJKGSCAB2BfdFeS24AIBoAICGAICmAIDMAIDoxgASAiAQ4g ASAbklnS0A5MAXGSfGAMJMpQEg5MAQBE1biaAEBEAjR8WerIo5SyrSfjDUrarpH5SMH+LgLI hMr1DoAMr9KBD0roKljnDwtbSm69KSCcAkCOGIy3EWjosoYnkMC6HoDkNxEjkWByODpZLcBy 6mGSEO8MGIOIOMZAC7UWt8AuAOuK4uuOEKFEB8DSB+C2C8B8CECEB2C8AoQ+BMFCDiCQB0FO BOCOB+DADkH6Goz6BIK8AEBU3qAAAuAAGwnWAUnaBGWYp0U+CDrSBoEAAywqMthQvaAsAgAS BXUDhEJSAWAeAgZKBEWLikbCL8AQCKASCKDAAODgAOEAAOEgL+fm5yFAAOFgAOGAAOGg4vZc LUU3ZdiKhHZcHkForxZdH4MhtM1FZdSKVFZphxjo4vZsQ5D6AOUmDUAAAwACBsFi7LEVkDkK NmssAgHJTHbastkYOCBmBmAgGSkCNNG0kqOmuCkkAiBvkmuEO+ZeUYA0CYB4DEDYBYEIEIFm FqFqAmBWBQA8FCE+AgB8DKFEAEaawsDYH8EaacEmCaBYA1BCQ4AGxeBNtxjAnWA0WeATCCAE 1aAtCFO/iiAoBoBXdEBIAQAmAsbDwoXeJMAjr4AABnR6AwVYrKA1P4KMAvQDxIAkrwhVHOg1 QWg9QgKIhcAvQmhiqHI2hjI/johUp4AaXkH+gYGAgYAuCcA0V6ArRYWEA0HgA0quA0FAA0Fh wISoMyowrHSwo+AAATGIGgASwgAIp1oQg7y+J2rwpm0+6whcp0p5osptSkp8AEqKCcAzESy5 pEs5XfTLTOs1pJbaN5pcOEOJTkSoAgnsT1ku5UAMAQAKART1eStcAAAaoSA2QutqBVUNkcNO ObuiZqBqzcAoeykOPEzcAGB+D4GqC8FGCfZTZYAiDcCiCiEcB2FoE4FoCQDaCeBrVQEkH6Fm EaBiCOCiCmEeEQAEByz2rQBCbqAGHczyAAA0ACHuFiAE8m8rDg4+ieAWAGA4AyAeAlohOe/M ijRAAYBAAfIMKMjIBeBWA1f4AwGbGeAh3YGazCYcAvLgA2Fmi2Ty+6CADaA4ByBQAoCsAeFf TyVaCAKqiiBQBhW2BB4UBoMkASAkXoAw1oAWBOAYBOAaBsAYBsAaBqAcEyAjQAAkBQAmCQAs CyAkCyAmCyAqDSAkDSAmDSAqDyAMDsAaDyAiD0AoD0AqEKAaEUAiEYAkEYAmESAoEwAUFQAW F4AgF2AiF0AoHUAUHOAoHqAaH6AgHyAoH+A4A8Ak8j2m8sAsAnnfImAeCIAeEIiejJ2x2125 293nLYYeOOYvY6BuKo0uKY4M0AAzLqAmBK4MAoAk4Mi8AeoUBKoqySAUAn8ILYXf2z22RWAg A4AEBeA4F/8qA4fqB+FqAeAm/MCAAofqCoKGB+Ak/MAEC+AkF+AkQdJKCEFsh4ZKCLIt9J3A XKCACABAAYBgAYCeAYAGCgAYH+XSAZ9gFmBeh5WKAEB+FpGGD5t73eYoHoNSA0AwHb3eHaTr kLGgHINT+yTqHb+8kEAwN87s7q8GBWAQ8O8G8K8OZMYfpm7q8WGICWFgAcCn/uAwCiC0CwIA uwADH+6AAC4KARwOCyWRiMACQy4WFyAAo/28thuOQUIo2DlxBVqFRyERFJBXKRWWS6cZSADi XRWAS6WQmJwsMxkNhvPJ4ARmEwsF54ExmAQMBwMBhGIj+FB2LB4SAuERMBQW/jawm6KxEHxW 41o/jYQRIMD4Vho/jOqQgKBIGzWDw6BBQ/UydUCfDsAjW+2QryEWSmAAAAgAUwG8wEWgK04O AAuAGwQC4nwyrwyAneB3eEwE3wO39AzwOz9AvwOv9ArwOr9AnwOn9AjwOj9AfgOftA+wQ+wo AjYCDZwS0CC1wQYCAZwQoEwQBwuDAeCwAAwe+QcA3yAgcDQEAQYPAaAPIAVwASgQBeEzeBz/ twOAwOAQmOAoPO/4weDwcIALg0GgHDqAIDhwBAePC8wBgGR7wgEDIMDiU4MBWJwIHoLoeCaC B+h5DxyAgewVxBD8QgAH8Nw+doIRbEEQRadoAgiCSSxsAAIGTHSHgAOQ4yAAMgSHIaaACCoR hqGiehuC6lgOEMkSVJknKSAIKGCEAVC2FgbhoAYAkpLMty7L4CGIaJSkMHgoBSIwLi2K80zX Ns3ziw4ACOAZ0gEJwCmSyLJm2IAnMwzQBHgBB4OCAIESuARwAOcDQGgA5oNAYADmA0BYAOWD QFEA5RNASQDkk0BBAOQTQDgA44NAMoEDK4IpgQKbnOg6QHgYBYBosVYJvS9YGAa7IHAc8YG0 aVYD2EICIO4ATEB4AIAgcB4eAY+4KBOBoLh8BliQBAQGjraQBh4AEDgQE4ABBaoAjVCcKhXE cNnpEUTxJEERXxD10h+dsYw8duA4GfsZxrG4cxzHZkofIUiYlHw4poCYahmCoKKUA4ThsngZ 4xjWOY8ngrmCsEuBsGoBmxlAV5VlgCHxOYdiiFIjgsL4p5rm+c52wzDAqAGh6LomjgqAIsaV pmlkwAJ16hqABBOAQlatqwBhQAZLa5rxLAIOewgIZOyAKcez7TtG17Vtu2bft23AMXG57rum 77tuYDmvve+75v+/b8BIgcGBQNAUegFmnxQGGWBpOgcC/IgeMYHnCCB8gibgJF6CbaE+CgRd CChaAqQfTdQQYLFf1fW9Z1/Xdj2HZ9l2vadv23c9x3fdd73nf994PgdmC4iAubXj+T5Hl+V5 vmef53o+h6fper6nr+t7Pse37Xu+57/vfD8Hx/F8vyfP830/R9f1fb9n3/d+P4fn+X6/p+/7 fz/H9/1/v+P/f9AGAEA4BQFgJAeA0CYEQLgVA2BkD4HQRghBOCUFYKQXgtBmDEG4NQdg5B+D 0IYQQjhFCWEkJ4TQphRCuFULYWQvhdDGGEM4ZQ1hpDeG0OYcQ7h1D2HkP4fRBiBEOIURYiRH iNEmJES4lRNiZE+J0UYoRTilFWKkV4rRZixFuLUXYuRfi9GGMEY4xReaCYgALQTDAUOvGoAI GjDFIaCDoIgTwnBXCWFUKQWAlADAWBwBgMQkBMFmFAKIXBaAPAOBgCYEAjhGVvHCNUk5KSVk tJeTEmZNSbk5J2T0n5QShlFKEAgAAwNBlLKWNIAB4AgH+P8ww8AAyvaDGmUphgdAACIAAJ4A AnAACuAAJYAAqgACkAALAAAlRtOsBwgYAAYgACQAAJgABZgACgAAKIAAuAAFoAAB66gAAYAA BNHKeQABGMSRYAEkpagAAkngxBhgDAAAKYYIIcg0hhDZHGOIkJ7AAARKOUFA5NjwlZLCTUq4 1T1jTQ4AFEABMMMPRSiZhqLgAbCAAJNG6Ohzo5R4AQqgAB8pHSWk9JqSUmYYKqk4QaX0vo2F WjY36a03pBTakFNKd0bDDT6mdQae1DmJUKotRKeVHqVUmplRqm1IqcAUY4ABOVSqpVaqtU6s 1Xq1Vir1WgDiNAABmsNY6y1krFWis1aaz1trZWmjYSq4y3ChRsI1Gwl14o2EKjYhwA1TERX8 AAiJb2BqmIMA1JBD19o2ESxlIBD0nELZKi4JKNiDsvZmkFmDDAhlvZ6ztn7RWhtIAC0FprR2 otLae1lqbW2rtdbG2Fs7VW1tfba2VuLaW3t5bm3tu7fXBuBcO3Vxbf3GuFci4lvKTmFCO0FX 1BJLUMAKDMGYsRYCvF0F9bA9QEAboM0EUQ4wTgqjUM8OoYQRj6FeP0M4EKBAMaCAkAFDGgkB CmVuZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQg OC42MykKL0NyZWF0aW9uRGF0ZShEOjIwMTYxMDE4MTE0MDIzKzEzJzAwJykKL01vZERhdGUo RDoyMDE2MTAxODExNDAyMysxMycwMCcpCi9UaXRsZShNaWNyb3NvZnQgUG93ZXJQb2ludCAt IElFVEY5Mi1hbmltYS1HRE5QLnBwdCkKL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24g NS4yLjIpCi9BdXRob3IoYnJpYW4pPj5lbmRvYmoKeHJlZgowIDE2CjAwMDAwMDAwMDAgNjU1 MzUgZiAKMDAwMDAwMTI5OCAwMDAwMCBuIAowMDAwMDQxNjUyIDAwMDAwIG4gCjAwMDAwMDEy MjkgMDAwMDAgbiAKMDAwMDAwMTA4NiAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAw MDAwMDEwNjcgMDAwMDAgbiAKMDAwMDAwMTM4NSAwMDAwMCBuIAowMDAwMDAyMjMyIDAwMDAw IG4gCjAwMDAwMDE3NDQgMDAwMDAgbiAKMDAwMDAyMzUxNCAwMDAwMCBuIAowMDAwMDAxMzQ2 IDAwMDAwIG4gCjAwMDAwMDI0NTMgMDAwMDAgbiAKMDAwMDAyMzcyNiAwMDAwMCBuIAowMDAw MDAxNjE0IDAwMDAwIG4gCjAwMDAwMDIwMTQgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAx NiAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzw2MEM2QjU0MUI2REZCRTg3NTFGODgz MTk5NzgwOUY2Mz48NjBDNkI1NDFCNkRGQkU4NzUxRjg4MzE5OTc4MDlGNjM+XQo+PgpzdGFy dHhyZWYKNDE4ODAKJSVFT0YK --------------0A7BFA24797DE84CB4696CC1-- From nobody Tue Oct 18 08:14:42 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72083129696 for ; Tue, 18 Oct 2016 08:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34DSeR9ChmH2 for ; Tue, 18 Oct 2016 08:14:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A136C12967C for ; Tue, 18 Oct 2016 08:14:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 33FD1203B1 for ; Tue, 18 Oct 2016 11:29:14 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B6A1A63AFE for ; Tue, 18 Oct 2016 11:14:38 -0400 (EDT) From: Michael Richardson To: anima X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] comments on GRASP-07 draft (fwd) Michael Richardson: comments on GRASP-07 draft X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:14:41 -0000 --===-=-= Content-Type: multipart/mixed; boundary="==-=-=" --==-=-= Content-Type: text/plain I was supposed to repost this to the main list, but didn't get to it. I realize that WGLC is over, but I wanted to make sure it was in the record. --==-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=2845 Content-Description: forwarded message From: Michael Richardson To: anima-signaling Subject: comments on GRASP-07 draft X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m --=-=-= Content-Type: text/plain I read draft-ietf-anima-grasp-07 from beginning to end. This is probably my first read through in many months. I will be happy to turn these into issues in the tracker if told to do so. I am overall pleased with the document, it read well. I did feel like there was a section missing between 2 and 3, that gives a detailed architecture use of GRASP, without resorting to bits on the wire. I think that section 3.3 is trying to do this, but it failing because it gets into security before it has explained anything about how things work. Maybe if 3.3.1/3.3.2 were moved to a new section 3.3b entitles "Protocol Security" or some such. I had to go learn about CDDL from draft-greevenbosch-appsawg-cbor-cddl-08 (now -09), and then how it maps to bytes on the wire. Can we please have some worked through examples with bytes on the wire? I will attempt to contribute some. Some specific text that I didn't like: 3.3.4, Discovery Procedures section says: An exponential backoff SHOULD be used for subsequent repetitions, in order to mitigate possible denial of service attacks. I agree that an exponential backoff SHOULD be used by senders in order to deal with overloads due to unintentional in corrolations of senders. But, telling well-behaved senders what to do does nothing to mitigate denial of service attacks. The point is that the malicious attackers are not well-behaved. If the point is to tell responders that they should backoff in their replies, or rate limit their replies, then that would make sense, but since the reply will be by TCP (as I understand it), then the opportunity to do forged source address attacks is rather low. Later in that section, it says: A GRASP device with multiple link-layer interfaces (typically a router) MUST support discovery on all interfaces. If it receives a Discovery message on a given interface for a specific objective that it does not support and for which it has not previously cached a Discovery Responder, it MUST relay the query by re-issuing a Discovery message as a link-local multicast on its other interfaces. The relayed discovery message MUST have the same Session ID as the incoming discovery message and MUST be tagged with the IP address of its original initiator. Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds. Could we rewrite this into positive language, and also split it up, and maybe even number some of these things. I suggest: 3.3.4.1 GRASP discovery relaying by routers A GRASP device with multiple link-layer interfaces (typically a router) MUST support discovery on all interfaces. Different interfaces may be at different security levels: each group of interfaces with the same security level SHOULD be serviced by the same GRASP process, except for Limited Security Instances which are always single-interface instances. When a router receives a Discovery message on any interface, for an objective that it supports, then acting like any other GRASP device, it replies to it. When a router receives a Discovery message for an objective that it does not support, but which for which it has previously cached a response, then it replies to that request with the cached information. When a router receives a Discovery message for an objective that it does not support, and for which it has no cached response, then it MUST relay the query by re-issuing a Discovery message as a link-local multicast on ALL of its other interfaces which are at the same security level as the incoming interface. The relayed discovery message formed MUST have the same Session ID as the incoming discovery message and MUST be tagged (XXX HOW?) with the IP address of its original initiator. Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds. section 3.7.3 says: The discovery initiator sends the Discovery messages via UDP to port GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBOR multicast address. It then listens for unicast TCP responses on the same port, and stores the discovery results (including responding discovery objectives and corresponding unicast locators). I have a problem with the mixing of UDP and TCP port numbers in this way. First of all, this is text is ambiguous because the binding of "same" is unclear to me. Let me number things so that the ambiguity is clear: sender: UDP from: X -> to: GRASP_LISTEN_PORT responder: TCP from: Z -> to: Y "then listens for unicast TCP responses on the same port" could mean that Y = GRASP_LISTEN_PORT, or it could mean that Y = X Could we just *say* in the UDP which port the initiator is going to listen on? Assuming Y=GRASP_LISTEN_PORT, may I suggest that if we say port '0' that it means grasp_listen_port, which is often GRASP_LISTEN_PORT, except if one might be debugging,etc. when one might set it to another port. That is, we normally say, "0" to mean GRASP_LISTEN_PORT whatever it might be at that moment. When we to reach at a port!="0", then we mean that port. Y=X can be made to work if one picks X well, but may be unworkable on some platforms. (I'm saying this mostly from experience with IKE, which originally said to ignore the source port of the UDP, and always use 500, which was a problem when it came to NAT traversal, but more to the point, it made it sometimes painful to test in-vitro). I'm understanding that ONLY Discovery requests go out via UDP, but that all Discovery responses occur via TCP. I'm a bit concerned about this process during bootstrap. The Discovery initiator will have to be prepared for many TCP connections... I guess we had assumed that the reply would be UDP as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV+6dw4CLcPvd0N1lAQK61wgAo+YeCD+nsCHepfhV13yv6c++RJ2CWJh2 I2MSxeayL5OFmvJiwtS7FMhS9xj0go+IxkaQJNSiBmY7eZ6tSN5cGJ99meXD2elO XIuaEYm0xOHDqlZthoKvHmxuTGSpi9SUjEdFZods/Hh8PFqweDibf39Tw6c2PwKZ lzgV1V8d4Z24TUUpSe2hDxsm1J1U6K0TdieZClIBHs7pmJbT+sg425Usy+LjYTm1 yipop9d0NklIRMwSNFIXgLoGqxDxWt8MJu9y48IfPAress6ejK4yV1DXU8EKwNWd KV0so1F6BuqUCYuOhM+eMXQZnp/hF/YKpCC0wsNUz/Ila0oVEEhOOQ== =7U6o -----END PGP SIGNATURE----- --=-=-=-- --==-=-= Content-Type: text/plain -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --==-=-=-- --===-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAY8W4CLcPvd0N1lAQJvjgf/bkR47mF8TaWtBZuUt+4rO3fvYm6Vs2th rONW0zyZ0CQPAaP6g0qWG9y/f3d0pQYUfHbPAEdfrO5zI015zC5txlq1xLDrG1nO b39AOQN8PS+VkNTKprdiLnQV3h7CT1i+ghFEujY2fqP87kBQHKXespR1PrRptTdv f8mE7qffrsY5AQ3OQdZha2SJUyY2DHUeR+hCdHCvTjGVP1WLdk7vNeNkDna09GTZ H50bys8asHIEPjRd2dJwwbp4z7zi9u65PNKfha8uVRcTYubau5VqYAy8MiRGFQRt FFjWuE6Cwe3/NwdHHCFjCDfxUk79L95V+jPhHq+HARRAYY2uJh0m4Q== =gVRZ -----END PGP SIGNATURE----- --===-=-=-- From nobody Tue Oct 18 12:50:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F811296DD for ; Tue, 18 Oct 2016 12:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKrrq58Cir0u for ; Tue, 18 Oct 2016 12:50:33 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07C6129490 for ; Tue, 18 Oct 2016 12:50:33 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id 128so1861103pfz.0 for ; Tue, 18 Oct 2016 12:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=DFkKrVq218YyQd7NcI3oX7BAhXGB0HOZJaSfk52s25Y=; b=JQyFfx+VvhOVFspxT7gajK+uyp8qVZV/N4IfaBN/ZhhSffwW7tyX4pHxlf9LIJ+c28 YszTKj8TFcyC62JKNoYgxf3mb4SCN2fumQPgeUUTEr/a807Zlz21YEG98iP5J8s8VTCj 46BRJ5h/AvWnMhWY321cuHbUFqb1Q8qS6fhBXQzfI3fTeSTs53fz82P2LzBHcGnuwHZT /LrAnQsq3rsxDjY9hnl7WXFEZHl+Uq9NR28kwEWVJWZHSVhZ5wQ7gHzz9oqfCaMo3uZG 9Na53QtSQDR9ojV8ATPTLhpuXV3dJzNQazrm9vCszxjULSXxur7++sKTF8rgRnj//KKW nqPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DFkKrVq218YyQd7NcI3oX7BAhXGB0HOZJaSfk52s25Y=; b=h82qy00y156XwNrkC/tHIIJ4Wg2Z6j3lfLoaM/2MqT7rWNr8oD/Zgr58tLkUFtSGtE Qws2vfUzB6wFjKA9J+nU4PojXF2vM+l3JLlLyPkJjnskDxBa/isAsmbGIhizJNms8KR4 lPGGThaCfbbvKlmBqbrArvj3w3QrSUmRBUBtgm9UlfFS0t4L5ugV5YfF3MGLyG/jFV+1 5oNmq9okxcOoVSJMKzcbtXjezG3aT0tBtC8b0voA8Rc8Rj27NFO31bIYtE4JmnLw7vkP Vo+Zb71pd6vLc7PbATTEVJFyr71Sy92I+6HJRLNahLSyb8rX9UDF0R3UC5hN09P+7F6S MYmg== X-Gm-Message-State: AA6/9RmG4FhkLRgiY+AsK7goXmGbgYjKqrxQeYstDukMtoj8/vvXcCPqD4pWDl7WHj3Fjw== X-Received: by 10.98.102.221 with SMTP id s90mr3646411pfj.146.1476820233298; Tue, 18 Oct 2016 12:50:33 -0700 (PDT) Received: from [192.168.178.23] ([118.148.117.247]) by smtp.gmail.com with ESMTPSA id l187sm57891676pfc.0.2016.10.18.12.50.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 12:50:32 -0700 (PDT) To: Michael Richardson , anima References: <31218.1476803678@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3c64e43f-f751-d543-f671-dc358c834578@gmail.com> Date: Wed, 19 Oct 2016 08:50:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <31218.1476803678@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] comments on GRASP-07 draft (fwd) Michael Richardson: comments on GRASP-07 draft X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 19:50:35 -0000 I'm not going to echo all the follow-ups here, it would get boring, but they are on the design team list at http://www.ietf.org/mail-archive/web/anima-signaling/ or https://mailarchive.ietf.org/arch/browse/anima-signaling/ according to which archive format you prefer. The editorial comments will get taken care of in the next version. Some technical issues will follow this message. Regards Brian On 19/10/2016 04:14, Michael Richardson wrote: > > I was supposed to repost this to the main list, but didn't get to it. > I realize that WGLC is over, but I wanted to make sure it was in the record. > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Oct 18 13:02:51 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82812947E for ; Tue, 18 Oct 2016 13:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XgP3lc_l4fH for ; Tue, 18 Oct 2016 13:02:48 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C476129412 for ; Tue, 18 Oct 2016 13:02:48 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 128so1992726pfz.0 for ; Tue, 18 Oct 2016 13:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=wpMeBLVRe0Uyxw/jPVXa6dKqlVS7ugW/vwCpivLWHNU=; b=rvojqr+zKpt4rS5aOcy7r4b8lbOB4hsMEGI7/2oZ7nWcwO8YySFxA4LpxBWqYRDsZN /duMXeysqpPp3W1a9STgoYGKPSw0OzKpqf+8rya8ELzfMsIC+lE5WfrQaekXHxSafggF 4It/+7If6RhSkmvD5vGuoTh90j4xqy2zyO/3C+95Oz7OL9HC5yiabeyN0H203KZVk539 Lq5EcmwrM+HdOV8/0bEgnjZfrQYcN1AtROPqIRsCpHvglQlQIEVEj2x2+ryEqZs4VXt1 giL8z8KVgpRtiuEp9Pegub3C1f1gSPJCd0dHo09lBmYXmaHt7Mb1dL2vr4/4RFPRhbwE d8dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=wpMeBLVRe0Uyxw/jPVXa6dKqlVS7ugW/vwCpivLWHNU=; b=U0ZM8EGemxmTbZ9I/g+zKjEVUyemECZ1LvgDPluXFrvPuv3rXIoTnXuhx8y7dUxrYL 9doa5mDdCo8HlQmZ80vGQ6VqMG2K61qI1DkLdBtW/H1xq/yhk/qfxmQ5kagbJvvDt8cq rKgWto3pRiWGVob7hLWwA5OBXiKAqQLazx5psSnTW359HsvbEIb3GZpCjc/cZDC0iM1u fq71XTa5PmotmuoBv8VD9/MMzrEkwYtylQf3/SDZLUqFFsh5tSVzLULVwvobk070huqI AWWSn/NSC2HCNTuFV9z3YwCHb9IHb/CQwTTuFiNNCMlV7EAU8yjDJVOqf5Cnlaz5n85x 03Kg== X-Gm-Message-State: AA6/9Rm/ASmrbicncQCrnBWaWt7Zi8Y6wLhohjBFNX7P/f1YLUfFIdRBtCnuh3fkJv8aOg== X-Received: by 10.98.153.204 with SMTP id t73mr3735370pfk.144.1476820967850; Tue, 18 Oct 2016 13:02:47 -0700 (PDT) Received: from [192.168.178.23] ([118.148.117.247]) by smtp.gmail.com with ESMTPSA id b88sm57899950pfe.72.2016.10.18.13.02.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 13:02:47 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> Date: Wed, 19 Oct 2016 09:02:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:02:49 -0000 55: Could discovery be performed over TCP? Michael is concerned by the use of insecure link-local multicast. MR: I wonder if we shouldn't just send discovery messages on always-up TCP connections from GRASP_LISTEN_PORT<->GRASP_LISTEN_PORT. BC: Yes, if the ACP could give me an API call for that. But at the moment all we can rely on is standard sockets, and in the 'no ACP mode' that's what we have anyway. I believe GRASP has to assume standard socket calls by design; if we want to fix this it's a problem for the ACP. Regards Brian From nobody Tue Oct 18 13:04:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FD81296EE for ; Tue, 18 Oct 2016 13:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y94YbBv0h8es for ; Tue, 18 Oct 2016 13:04:02 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0EC129534 for ; Tue, 18 Oct 2016 13:04:02 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id e6so1946879pfk.3 for ; Tue, 18 Oct 2016 13:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=1unSJH/MwhLsHuKNK6cJ6H4rLpRr+D5OT9kd+YyXNSU=; b=YNgiiWUZmau/aMmID8hmletAg5ipp/YvvCVVloEXW3ur4rkIvZxZkWESsX6XMdr0mS oyjAMdWfC/SNit02PdZD5odXb4nTUWJyJuvb/udp+IPVPGr4At712wtDxkosLiMsfHWp 1hvOWCU+UXfyFfTAwWxoDFs+pN/+zeE4pC8I9rInrkI8g2tGqCmpn/3R3cKT6PNMCCtf yiScbzNBImn7jQsLscKi0fJFkb4XiBpaSP0lEOVqTnkTLYs9zs4f4ZxrhHa1Ii8Slnp+ hozafsXe0jkdHnh44GB5Ya389KFUcQcOmDGaGf8nLk1JXSmp8klHYFZ9c/v3qbVh7BWJ rQmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=1unSJH/MwhLsHuKNK6cJ6H4rLpRr+D5OT9kd+YyXNSU=; b=avT8B19a2TX9ytGJbGAAUpgdwUl/4ba8CWFLckzAQQw9dZjJYABjozIuVAoY3MO50/ FHVGJgtjcOJioM0+UtXr7CXyWHx+WMZSCpLgxmVmHcxQ9tzPPLhPVDApGUmqHwM1FDP2 zQv8o3Mw2MpzIFe9vtznRyO3wXReaofSwccDpvUEqzp0YMa5tbn4I8gdrmhUO/Pn2Nfb xOIJAnLmfr9d00LdVNVQ0Jk7bMxsSkZIyoE+ES0+Al2nBqTUVhOxiTI541CGIPY2344n M9X7tTMv6Tq5KnTYdiNlilkBr6VjhpyBL7YMG3wugjWCDsKJl78KEP32RE6Yx8T3sErW RBSQ== X-Gm-Message-State: AA6/9RmkljmCh30n7tEfPOOyyvb9auZWWubi4SpBZHWyZkG5zqq0ZNBHbV/eu12vLRmMxw== X-Received: by 10.98.75.152 with SMTP id d24mr3670708pfj.97.1476821041830; Tue, 18 Oct 2016 13:04:01 -0700 (PDT) Received: from [192.168.178.23] ([118.148.117.247]) by smtp.gmail.com with ESMTPSA id q7sm57864135pfq.80.2016.10.18.13.04.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 13:04:01 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> Date: Wed, 19 Oct 2016 09:04:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:04:03 -0000 56: Change Session-ID to 32 bits? MR: Given that CBOR has only 1,2, and 4 byte uintegers, why do we have a 24-bit session-id? BC: Well, it's a hangover from the pre-CBOR TLV format. But I think it's true that we'd increase the average message size by making it 32 bits, since there are a lot more random numbers between 2^24 and 2^32 than between 1 and 2^24. MR: okay, hangover that you'd like to save a byte. But CBOR doesn't let you save that byte, so just make it uint32? BC: CBOR sends 1, 2 or 4 bytes according to need, as I understand it. Regards Brian From nobody Tue Oct 18 13:04:57 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690F2129857 for ; Tue, 18 Oct 2016 13:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ob4vIu0gC85 for ; Tue, 18 Oct 2016 13:04:46 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA5B129534 for ; Tue, 18 Oct 2016 13:04:45 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id s8so1974956pfj.2 for ; Tue, 18 Oct 2016 13:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=ieYSEZnEJMOX9gcqCwoMSBRblcUalGjZ/JI6QS5e8LE=; b=giOFGhz2wGZuTPguXtA0L7QPfRcWlRa4Mm/7tNUReTt/Esa04buKxjc5+nqn2Yoie3 B7yzj2Coqbtl7RstTo/58nbZjU/U5VRusitsNVVnZ2pQ8sOiJYQ5F2LB7I5o0Bq9ssir Zd0WudFU5B8SfbIaOFCxn4YBnQfUwbjju8qJ3rQPPuQiLMkwOCtVFEe0efXFaLVtUUHW 7vUF9FvtREX7OzKEPKA+8kKy5vhgKvF4T3POf1WOwI0talWQV839t9H7bPjjCypxC44S FheYqzaPG5ksaUAfcndtct7eZSho/m+rVezGJG11Yg0o+aUZZXhgraL1zTa0jWM2SDTN tmBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=ieYSEZnEJMOX9gcqCwoMSBRblcUalGjZ/JI6QS5e8LE=; b=OAl9+Z+NRwgJcADe7PzxfZcgiSQSB28oaBtXpsjDw71QGsvzB1k43pViCoXZVSt36m e2bcZ09ol7w7FkzZH40kBuZAjYj8kDSuMkMZ27Bb8vKtVA9CBiAB9zizRb+hyqQNC8g2 +tTMBv7OkgkrEGOuiVFTz10R8WbEl2Ci4A7eRby2Yiy8/1WaAQJ0ZHjYrQ/NGqfINMMX fOryval/dgA62fg28pDMlYKx4GhfbA6+m27bOWP/9qhLHWFiPUa/ARUXqhf9xorsERKH W5ibm2CkrXVHe05h8nD6gi3b44TmTlubV2c+y6YKg/8FHs3qpDz1OPYZLzFsjHOHgre4 liyg== X-Gm-Message-State: AA6/9RlvVRyFQob941CnA+SU4m9KGg8kJ6yAA+ck7/qduSMmfYE5GHbS/oPHmRLKR01JIw== X-Received: by 10.98.61.85 with SMTP id k82mr3744227pfa.7.1476821085282; Tue, 18 Oct 2016 13:04:45 -0700 (PDT) Received: from [192.168.178.23] ([118.148.117.247]) by smtp.gmail.com with ESMTPSA id 128sm57962182pfy.4.2016.10.18.13.04.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 13:04:44 -0700 (PDT) From: Brian E Carpenter To: Anima WG Organization: University of Auckland Message-ID: Date: Wed, 19 Oct 2016 09:04:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP issue 57: Add M_INVALID message? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:04:48 -0000 57: Add M_INVALID message? MR: What does one do with an invalid msgtype? Options are: 1) ignore (drop msg) 2) die: drop TCP connection 3) reply with ???-M_INVALID or something. BC: I'm inclined to add M_INVALID as a MAY, or possibly a SHOULD, but with a rule that you MUST NOT reply to M_INVALID with M_INVALID. And the reason is indeed that we could use this to discover that a peer doesn't understand a new (or obsolete) message or option. Regards Brian From nobody Tue Oct 18 13:05:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC45F129443 for ; Tue, 18 Oct 2016 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRpe3BAqkaoV for ; Tue, 18 Oct 2016 13:05:41 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B2A1294DA for ; Tue, 18 Oct 2016 13:05:40 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 128so2024162pfz.0 for ; Tue, 18 Oct 2016 13:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=8jocztPlvNwsppQcN5KoTZU/HEznfu4CoWj5gDCNx/A=; b=AYJGu4a3V8fTELBYiobZhLgwqfAW92vuBgd8P6SC0RjGadx+iIDxzBlGted7eE7DCY et1Kjyn08pTSZ5XXKCUxQhrfUzkltZWE/r+v/SRKP18xXVNLoKtmvpOMvyqaoTkgxzb3 SQBtrDP6Zo/3uJjFDaAgE2jrOdkD/qZXAklO2c1W56jkOAmp/oSKUo2Y/cZ7tXsrHQeC sh9EPVJ/doSdG3bU1f5Kg0gnaEgysvmGRcXNEpiqP1xnZgKJq8k/E1tbV9val5D6WIsA Ea3QqYC8JBk8I3gdoNA7hh0CaETQmWqpO7jyKL6yuEzGAWOHr04sKfbGg0URHpl3tnTB hl/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=8jocztPlvNwsppQcN5KoTZU/HEznfu4CoWj5gDCNx/A=; b=VPiGtryMEZ+fKNvmBy/YIWfu6ad8op8IlMTETXU+GzSMXoy6DcTw6BmuT5L+sAf0yI dz9rvp3cxqS1X3LLHQIpnVofdh4C5VEQskAOqyB8RRXO4dp4Duuc1M+TGElAcNY9RJdO 2zQo20W+wZb8H8B9BGwpedvGbJgCNXq3bDZRjKLlbHemM++x54n1B0iKelNpmqCvE5kF ftqvhgUh+zATUnxn9Ytoh06nTydH04lJ0nVpR1OMA5U11REmjun13eEBDf+XqNxPrxAw wEqP/5aLKLA1eCC/zbzfYSbTOBx1UmczML3NVvwZc790CkcsaKprY7TagACtF38nbbPN g1HA== X-Gm-Message-State: AA6/9RknWb5SIomJKPz0hqHyRe0lX+8Lj6WkSqdrfSwYRBSdB4Q1EFEZrUrx+PcUM6a/3g== X-Received: by 10.99.42.131 with SMTP id q125mr2994575pgq.3.1476821139275; Tue, 18 Oct 2016 13:05:39 -0700 (PDT) Received: from [192.168.178.23] ([118.148.117.247]) by smtp.gmail.com with ESMTPSA id y2sm57928722pfk.54.2016.10.18.13.05.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 13:05:38 -0700 (PDT) From: Brian E Carpenter To: Anima WG Organization: University of Auckland Message-ID: <0f3ecf86-ead6-486b-c5a6-403bbf1e4689@gmail.com> Date: Wed, 19 Oct 2016 09:05:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP issue 58: Maximum message size? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:05:42 -0000 58: Maximum message size? MR: I'm also a bit concerned that we have no statement about maximum message size. BC: Me too. I coded my prototype with recvfrom limited to 2048 bytes, but we probably need to specify something. On the other hand, Michael B wants to send infinitely long Intents, I think. Regards Brian From nobody Wed Oct 19 01:41:44 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B57129568 for ; Wed, 19 Oct 2016 01:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.953 X-Spam-Level: X-Spam-Status: No, score=-14.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxNG2eO2jmCw for ; Wed, 19 Oct 2016 01:41:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631D112956F for ; Wed, 19 Oct 2016 01:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1174; q=dns/txt; s=iport; t=1476866501; x=1478076101; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Uqj/zA2VEqjEwe+cb9J6oAcMqXwMuRZrXmelSs1liKM=; b=VtO8Yu3HHzT42pGJcYB9LcOM3EowTMMQib1FaT34Q1iufKuGR4w1QToQ gzyh1+loSexa1IEYkBKX4qABYAo7BVXu9f5DGcQxBmWwcl4bk1wIXgyGA lgdgRYnWRF6zjP1eTrIPf9CKJmeSDAucP9vFyO6MU+iX61grbY/hk1FXp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQByMQdY/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR1XfAeNLZcFlDmCCBwLhXoCgg04FAECAQEBAQEBAWI?= =?us-ascii?q?nhGEBAQEDAQEBATc0EAcEAgEIEQQBAR8JBycLFAkIAgQBEgiIQggOw0UBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYY9hFWEI4YDBZoJAY9/j36MfYN/AR42VYMCH4F?= =?us-ascii?q?TcoVqgS+BAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,513,1473120000"; d="scan'208";a="165007456" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2016 08:41:39 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u9J8fdrk004379 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Oct 2016 08:41:39 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Oct 2016 03:41:38 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Wed, 19 Oct 2016 03:41:38 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] GRASP issue 58: Maximum message size? Thread-Index: AQHSKXsHqPGJcBrCP06mOJp74G+yUqCvdURw Date: Wed, 19 Oct 2016 08:41:38 +0000 Message-ID: <9e81a607a34c4ad58d6957ab2a0a3a0c@XCH-RCD-006.cisco.com> References: <0f3ecf86-ead6-486b-c5a6-403bbf1e4689@gmail.com> In-Reply-To: <0f3ecf86-ead6-486b-c5a6-403bbf1e4689@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] GRASP issue 58: Maximum message size? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 08:41:43 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 18 October 2016 22:06 > To: Anima WG > Subject: [Anima] GRASP issue 58: Maximum message size? >=20 > 58: Maximum message size? >=20 > MR: I'm also a bit concerned that we have no statement about maximum > message size. >=20 > BC: Me too. I coded my prototype with recvfrom limited to 2048 bytes, but > we probably need to specify something. On the other hand, Michael B wants > to send infinitely long Intents, I think. :-)=20 My view:=20 - We use GRASP to signal which Intent version we have, and where the latest= version can be fetched from, and with which method / protocol.=20 - We use that protocol to actually get the Intent file.=20 This is the most flexible and extensible model, IMHO. So, from my point, no problem with a maximum message size of 2048 bytes, as= long as we send the Intent file separately :-) Michael =20 > Regards > Brian >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Oct 19 01:48:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059CA129568 for ; Wed, 19 Oct 2016 01:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj4-FbMBfq0i for ; Wed, 19 Oct 2016 01:47:57 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF41129564 for ; Wed, 19 Oct 2016 01:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=884; q=dns/txt; s=iport; t=1476866877; x=1478076477; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9DUwc9gumS/3UuXJV+e0C/WmkOZEL8e7PL+JIDqC6qc=; b=OL4OrXHBaFmeZ83wkpN7f6ArTvluZhtvGpDuPgTVUyjGQrEniXzjJX37 m8gcF3pQ3Le4amAHbTn1cNACg8VKS7t/gMNiZdGwyQgZzWQbhOEbnEmnu I6YbNlm5x+W4wOMp/1vEz5phzD5wgOhZSoCvwqoCh3NGMGLxGdiaTbIQL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQCiMgdY/5BdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzwBAQEBAR2BUweNLZcFkiqCD4IIhiECgg04FAECAQEBAQEBAWInhGE?= =?us-ascii?q?BAQEEOksEAgEIEQQBAR8JBzIUCQgCBAESCIhKw1YBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEdhj2EVYomBZoJAY9/j35JjDSDfwEeNlWEdHKHGYEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,513,1473120000"; d="scan'208";a="335680702" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2016 08:47:56 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u9J8luxu010918 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Oct 2016 08:47:56 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Oct 2016 03:47:56 -0500 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1210.000; Wed, 19 Oct 2016 03:47:56 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] GRASP issue 57: Add M_INVALID message? Thread-Index: AQHSKXrqhVEWdqyedkSPCddqF7tUl6Cvd8cQ Date: Wed, 19 Oct 2016 08:47:55 +0000 Message-ID: <618610f7ccaf4dea93bb9bea65908f13@XCH-RCD-006.cisco.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] GRASP issue 57: Add M_INVALID message? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 08:48:01 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 18 October 2016 22:05 > To: Anima WG > Subject: [Anima] GRASP issue 57: Add M_INVALID message? >=20 > 57: Add M_INVALID message? >=20 > MR: What does one do with an invalid msgtype? Options are: > 1) ignore (drop msg) > 2) die: drop TCP connection > 3) reply with ???-M_INVALID or something. >=20 > BC: I'm inclined to add M_INVALID as a MAY, or possibly a SHOULD, but wit= h > a rule that you MUST NOT reply to M_INVALID with M_INVALID. > And the reason is indeed that we could use this to discover that a peer > doesn't understand a new (or obsolete) message or option. Agree.=20 I think the handling of an invalid message is up to the ASA, so what it act= ually does depends on the use case.=20 Michael From nobody Wed Oct 19 05:37:55 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A291294F7 for ; Wed, 19 Oct 2016 05:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3bL4Zo23lSZ for ; Wed, 19 Oct 2016 05:37:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95734129456 for ; Wed, 19 Oct 2016 05:37:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D56612009E for ; Wed, 19 Oct 2016 08:52:28 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5EA0163AFE for ; Wed, 19 Oct 2016 08:37:50 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] text for grasp-07 (-08) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 12:37:54 -0000 --=-=-= Content-Type: text/plain Brian, I began reading draft-carpenter-anima-asa-guidelines-00 and also draft-liu-anima-grasp-api-01. (Chairs, I think they should become WG items) I think though, that section 3.3 of asa-guidelines ought to be worked into the GRASP protocol document's introduction. (But should remain in asa-guidelines as is, except for "kernel") This would be some of the text that I suggested was missing that explains how to use the different mechanisms. I haven't read -08 yet, mind you, so many you got this already. Let me tweak the text slightly below. I suggest that the world "kernel" may be confusing to some developers: it may make them think that GRASP requires access to toggle hardware bits... 3.3. Mechanisms offered by GRASP GRASP is expected to run as an operating system core module, providing an API (such as [I-D.liu-anima-grasp-api]) to interface to less privileged ASAs. Thus ASAs may operate without special privilege, unless they need it for other reasons (such as configuring IP addresses or manipulating routing tables). The GRASP mechanisms used by the ASA are built around GRASP objectives defined as data structures containing administrative information such as the objective's unique name, and its current value. The format and size of the value is not restricted by the protocol, except that it must be possible to serialise it for transmission in CBOR [RFC7049], which is no restriction at all in practice. The GRASP provides the following mechanisms: o A discovery mechanism (M_DISCOVERY, M_RESPONSE), by which an ASA can discover other ASAs supporting a given objective. o A negotiation request mechanism (M_REQ_NEG), by which an ASA can start negotiation of an objective with a counterpart ASA. With this, there is a corresponding negotiation response mechanism (M_NEGOTIATE) mechanism for an ASA that wishes to respond to negotiation requests, and a set of functions to support negotiating steps (M_END). o A synchronization mechanism (M_REQ_SYN), by which an ASA can request the current value of an objective from a counterpart ASA. With this, there is a corresponding listening function for an ASA that wishes to respond to synchronization requests. o A flood mechanism (M_FLOOD), by which an ASA can cause the current value of an objective to be flooded throughout the AN so that any ASA can receive it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAdpG4CLcPvd0N1lAQK1lwgAkz1D3193dYSOmMsfrMYeFAD0TAsVp+/m eijtJmDLmnnuCa46LQfuP8/PDRgdf3l1UHOaIpCtqHgZfkkMiSoV49fJQZZ6MozU X+YtFsNiKkm+732SKyZmuQvxgXLUNBA7erhTw4/SmnbMcDYCle+C8B+2xSlqaI68 T/16vRocw3h+1uoJCcRcJBvsMfbaB2cPQwwGVt0PIVqq8aFECs6J0Mr5ZAQOCt4y wkOlPaEwVdSr27B38sOjUlQkh8JevAbrhXj1rLdfs/XAixSzNW3+Y30sFpg1jhRr bwRQKEHKQwhgQeFwuLjTgcpTTUPYqz1WctMdST4+HHBRBQl1zKEkXA== =CLph -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 19 08:59:22 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C0D129687 for ; Wed, 19 Oct 2016 08:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEe6KZOz4LFT for ; Wed, 19 Oct 2016 08:59:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA98129413 for ; Wed, 19 Oct 2016 08:59:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F15AF2009E for ; Wed, 19 Oct 2016 12:13:57 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0AAAA63AFE for ; Wed, 19 Oct 2016 11:59:19 -0400 (EDT) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] concerns about selection of session-id in GRASP messages X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 15:59:22 -0000 --=-=-= Content-Type: text/plain As I understand it, once an ASA has discovered a counterpart ASA in another node, they will open a TCP connection. Some questions occured to me this morning while cycling home from a working breakfast. Some clarification questions are in order first, as it may be that my concern is moot. while "3.3.6.1. Flooding" talks about preventing loops by caching session-id+originator, I think that the problem extends to all parts of GRASP. 1) do DISCOVERY messages have to be multicast? My understanding is that they do not have to be. I think that they could be sent over TCP on links where multicast means nothing (PPP, GRE), or where multicast is not known to be available (MESH networks). Given an ACP made up of a bunch of point to point GRE tunnels, is there any reason there is no discovery really to do, is there any reason why the two GRASP daemons don't just establish a TCP connection between them, and leave it up? They could use this connection for flooding messages and the like. The responding GRASP daemon could realize that the link can be used in both directions if the originating port is also the GRASP_LISTEN_PORT. 2) the response from a multicast DISCOVERY is a unicast TCP connection. (We've discussed this before, and I'm okay with it, but I still wonder if it will be well received.) Is there any reason why the TCP connection for the reply has to be from the GRASP "kernel"/"core" daemon? Could the GRASP daemon pass the enquiry to the ASA itself, and the ASA could connect to the thing that is asking, and reply with the M_RESPONSE itself? 3) part two of above, if the M_RESPONSE indicates a locator (address and port) which is identical to that connection on which the M_RESPONSE is. Or maybe we need a locator which just says, "HERE". Is this acceptable? If the answer to (1) and (3) is yes, and the TCP connection can support bi-directional flows of GRASP messages, then I think that we have a problem if the session-id happens to be poorly chosen, and both sides initiate a query that involved multiple M_NEGOTIATE cycles. The two ends may get confused. (Again, I haven't caught up with the emails about -08 yet) If we are expanding the session-id from 24 to 32-bits, then may I suggest simply that we actually stop at 31 bits, and make the top bit to essentially follow the ACK bit on the TCP. I.e. the side that responded to the TCP connection always sets bit-31 on it's session-id. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAeYVICLcPvd0N1lAQI6lwgAjOFopYU3OG1z48j5orQVDhtrtYgaC8a+ nP+Tq0y27JwqMkwZK9PksheQNIfy2nUzMOHGP01hKtvHKRk/SdZON9mI+D9OoeAJ G7NUYVOTkMS+cmuGIu+Rl0TgCfdnDlcrUHZiMsUNkwFKLNzcJr8yX5QTmVaCUabx SxOZwfAO7dK3TA2VbQ2TvWNxsepts6XfS4i09TQQrOE7Sd5z93u1xcprpibAWzWu /ew8gfwC5Fh8zIYgf4Li/ouaUWSz2KDDRy+zlsryUIGdeMWFzp0TdKHiMtBxFN2H ixgO/WJXvTfJz7rWyQ6gsXfRbmDYLFiqG+2nQnRdmlFdBnAsNCEmQg== =hoVe -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 19 12:59:40 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD65129715 for ; Wed, 19 Oct 2016 12:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGayPzai308S for ; Wed, 19 Oct 2016 12:59:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA02129704 for ; Wed, 19 Oct 2016 12:59:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BEF832009E; Wed, 19 Oct 2016 16:14:14 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3E95063AFE; Wed, 19 Oct 2016 15:59:35 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 19:59:39 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Michael is concerned by the use of insecure link-local multicast. No. That's not my concern, actually. My original concern was that, when doing discovery outside of the ACP, the client doing the discovery has to open a TCP port that anyone who can see multicast (i.e. everyone on the link) can beat on. If for some reason, the client already knows a GRASP speaker, it could initiate a TCP connection to GRASP_LISTEN_PORT, and receive the answer there. > MR: I wonder if we shouldn't just send discovery messages on always-up > TCP connections from GRASP_LISTEN_PORT<->GRASP_LISTEN_PORT. > BC: Yes, if the ACP could give me an API call for that. But at the > moment all we can rely on is standard sockets, and in the 'no ACP mode' > that's what we have anyway. I believe GRASP has to assume standard > socket calls by design; if we want to fix this it's a problem for the > ACP. I don't understand the problem here. The ACP essentially a VPN. The ability to bind a socket such that it hears only traffic from within the ACP, while not IETF/POSIX standard, is commonly available. (We tried in the IPSP WG to make it standard. We really tried hard) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAfQpICLcPvd0N1lAQKIoQgAkc0LnEL5JRmJS0CqBksDlCZQOfgdRVL9 ieuyy8ARyg3ovy4gA2mnblqYKi9LdA7eOY2NQMZ0al4bZ/W7lsKxYq2AMR1/atqX NxVSL7CLoDeZpYekPFviLxVsG6kdGstHstAE0nhEkPe/rRVNBsrIlwsSl4z/MERX VChHWj68swCu+xf6GUAFiGLhlNpo/5AE2Kz3u+7wS8YDkuQMGYd6dXZD3gBQqOrP F+489Jch2FkuRQozeRvTUIrCRxb+BX946knPeab2Y6+gQ9qjjWSvaL6HiZhlXFhL sn6LfsKfaE7iVDHguktnVGyq6s2N4YJY4AU5FCi568GrzazTgI8A9g== =NMdW -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 19 13:03:58 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AD71296F9 for ; Wed, 19 Oct 2016 13:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47O7DJ91V18Q for ; Wed, 19 Oct 2016 13:03:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D410129579 for ; Wed, 19 Oct 2016 13:03:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4F0412009E; Wed, 19 Oct 2016 16:18:34 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B109563AFE; Wed, 19 Oct 2016 16:03:54 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 20:03:56 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > MR: Given that CBOR has only 1,2, and 4 byte uintegers, why do we have > a 24-bit session-id? > BC: Well, it's a hangover from the pre-CBOR TLV format. But I think > it's true that we'd increase the average message size by making it 32 > bits, since there are a lot more random numbers between 2^24 and 2^32 > than between 1 and 2^24. > MR: okay, hangover that you'd like to save a byte. But CBOR doesn't > let you save that byte, so just make it uint32? > BC: CBOR sends 1, 2 or 4 bytes according to need, as I understand it. If my session-id is 0x010000, then CBOR will send 4 bytes. In the unlikely (1/2^27 + 1/2^24 + 1/ 2^16 chance, less than 0.001%) that a randomly generated session-id has two or three leading zeros, or is less than 24, CBOR will send fewer bytes. (I think, sending more bytes is still permissible). In most cases, it will send 4 bytes, so might as well use them. See my email today about perhaps using bit 31 to partition the session-id space between TCP sender and receiver. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAfRp4CLcPvd0N1lAQKYsQf/dHgddgQ5Ty3CU3CDwQSbxSESlB1AxYZx jBnn6EPy5Yhw9oIuNNsyArgQ71pA3oCx6eslc1Z4yCVwR1OC40fMuFVaKEALevfm Z2b9EW8periSRoEsSd/nixQ9eEtFg0sERiD8NjLHeEcDsTpEGx/9tsFwu/g6H3Q6 Gg00Urv1cZEWY5IptsFafNxa/oXqzKHmtvI2e9wzQBbFfD2RAcnenNaYOGhCMs3d M+6JlnsxfhYQv+7WKTuOKo4P/MxnBEbf1XqadInuQtbow03Hvm/l3ySRQH9UQmpX M8DJiDuCs6xRQIoVceeJMbS+L18sBxyENWjjKUnKGx3LFwe3rkOMKw== =HxNf -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 19 13:13:50 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B17129652 for ; Wed, 19 Oct 2016 13:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC58J3Rym1oU for ; Wed, 19 Oct 2016 13:13:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881D712955F for ; Wed, 19 Oct 2016 13:13:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 662DF2009E; Wed, 19 Oct 2016 16:28:26 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D36ED63AFE; Wed, 19 Oct 2016 16:13:46 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <0f3ecf86-ead6-486b-c5a6-403bbf1e4689@gmail.com> References: <0f3ecf86-ead6-486b-c5a6-403bbf1e4689@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 58: Maximum message size? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 20:13:49 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > BC: Me too. I coded my prototype with recvfrom limited to 2048 bytes, > but we probably need to specify something. On the other hand, Michael B > wants to send infinitely long Intents, I think. libcbor nicely responds to an incomplete message with CBOR_ERR_NOTENOUGHDATA. This lets you grow the data structure for the situation where Intents are large. https://libcbor.readthedocs.io/en/latest/api/decoding.html#associated-data-structures It would be better if the initial parts of the structure could be examined even in the error case, and if it was the case that one didn't want to deal with the rest, one could be told how much more to discard. Or, in some cases, one wouldn't know (streaming arrays, etc), and perhaps the answer is drop the TCP connection. I think that this could be added to libraries. What I guess I'm concerned about is a CBOR definite array structure that says that there are 10 Billion items to be expected, the library goes and allocates that much ram (10G), and the system fails or goes into swap hell. No need to actually transmit the 10G of data. libcbor can be configured to use a custom allocator rather than malloc(3), and this is likely the correct answer: to provide some reasonable limit on amount of memory for decoding... which comes back to how big will the Intents be. kilobytes? probably. megabytes? maybe one or two Mbytes. gigabytes? most certainly not. *could* we make the maximum objective (assuming intents are directly in an objective) size itself be a synchronizable parameter? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAfT+ICLcPvd0N1lAQKyNgf+PuStDUYLaSaUcZhRaByxeVUoBjU4WAN1 oYLNyYVIGfNcTcxs2DQQsC4mnCvLaPwKyxmtXTyeMirM1nCtdkRqSx/G1TB4vtm7 ZZUANwI9fLfgdMPLo2KSmvERC87rVXu8rHzEYQLkykIDLX6MGHMMCESleOdxLlHq xsba22ykLynTAsCZK67iODbce4k+kVRn2dYXsOsbyvcxnZJuRuqE8n3NDuNW46Kz uPL+YWyxQe75sQfyz40zILIvzw9RaLROrljIBtABvJ+I1Jqvz4VKfEVAoyZsouUS xM+sZnAzd9OJfAXx/X/PkWXsFWWTdc20eRb52XOcXzef1wqP4Ckc6w== =KuJS -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 19 13:16:25 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F98D1294DA for ; Wed, 19 Oct 2016 13:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcDVwN8tMZHW for ; Wed, 19 Oct 2016 13:16:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEACA1294C4 for ; Wed, 19 Oct 2016 13:16:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9EB4E2009E; Wed, 19 Oct 2016 16:31:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 15B5B63AFE; Wed, 19 Oct 2016 16:16:21 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: <9e81a607a34c4ad58d6957ab2a0a3a0c@XCH-RCD-006.cisco.com> References: <0f3ecf86-ead6-486b-c5a6-403bbf1e4689@gmail.com> <9e81a607a34c4ad58d6957ab2a0a3a0c@XCH-RCD-006.cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 58: Maximum message size? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 20:16:23 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > My view: - We use GRASP to signal which Intent version we have, and > where the latest version can be fetched from, and with which method / > protocol. - We use that protocol to actually get the Intent file. I agree that this is a better way to do things. I think that an Intent to get the ACP working ought be less than a few KB. > This is the most flexible and extensible model, IMHO. > So, from my point, no problem with a maximum message size of 2048 > bytes, as long as we send the Intent file separately :-) RFC6920 defines ni:, which might prove useful. Naming Things with Hashes Abstract This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAfUkoCLcPvd0N1lAQK8hwf/RJdlEyTPXR5o7wMBnAfTdQKTy/8jtJdc SnjeZqMY3O/RCvFDRhAv+6V5igcNs8HKpxRYvbRjdixEwvYrU5LfBADoMtV6Pw/6 tcCU4CsN0PgRdlDAb+8xvbe3UWqDIz55XqG61JQxd5XBfNKALaJoLwBZtlaPDzQM YeOUaJwuyZh8nJMj9LeYLR9G9nLkKBLKL/m52Lriz06swntWpARVzFvLb9MAltRF v9ceWb0JbCOswtx7s8/iUOjxeMUEt6dV5qkUioDjSjZ3edWwETZPQpHW3rikcPDI 7LQlWdYY82UemBT05CPeeqcYCd8FXYZ11TimVRcVLmWjV1Lh12OEnA== =zTRW -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 19 15:06:13 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAE0129462 for ; Wed, 19 Oct 2016 15:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6denYM4OqrNj for ; Wed, 19 Oct 2016 15:06:10 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC4F129469 for ; Wed, 19 Oct 2016 15:06:09 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id s8so22821925pfj.2 for ; Wed, 19 Oct 2016 15:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=inqHf4TLrBRBYvyj9qOkYqZhufCRlIuB1GSIuqTwm4Y=; b=xyFsVtLelWo7lEQDVk4ksrAyozCJeq20Ke/bQx3OqGhQQaQl7wV6Z7A30zfh/ivmDg m0o7vrtB6VyEME0mybCMpy4DGhy5t5dpyFrKNncNAM0zowisNSGY9xszy065xMvwg5Kc 3uT73PzOV5ylylNfQeIALrGSxRA6Q2d6VxZnNsEWxePkZLTzUAgasxPlH8ZMQJHGlAXO glZ02zToGiFzNEE1g1BhZS/CYEGwv1HC8heppZsaMIA3HFK6uoKzVtxo6F1qs3q0smGM 43guwYpngtEf2+fqyIgpsWbWJ8BQm22g8f71bFfBupk5g7RT4qcvxMHxJJhTj4p4nFe8 0gCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=inqHf4TLrBRBYvyj9qOkYqZhufCRlIuB1GSIuqTwm4Y=; b=L+EyvMkA3Hx7dSGC0u0DH2/PdX+VFaSTWsrr/qp98eyFyJ5c8Ki7abDZe4IvLJkFBL xWxDnATJ1Eas4+2hZjrpHin3WvhQk1pkSkJUOg4j9q/2B5AGifdab7jpBOZEdP3RIYLm xnGH/i20ibxoMLcxPUstcVoKu5NxFjrbiUwGZ6eOaWLO73JWXM15upgeS6WcSgjGuaz/ RkzdvrrFRiAk9GzI53Fbgsatmjj2L0GMJHeEb0XSTaOzmxbTObqVhYLChtkZsVV2iIZs gMshuhSNHzYtYHvrrpOTtRzpRF3gb+L1esNM9PT5sYeh/KEImlkI0QOVnNaOHonkoV3U TDoQ== X-Gm-Message-State: AA6/9Rm8+Uu4LmZ9CUDv8aN4TUTgzmcJLt4otRnmlEnI58CB65PJLoieRhwBj2LekdmWXg== X-Received: by 10.98.77.1 with SMTP id a1mr15356932pfb.160.1476914768579; Wed, 19 Oct 2016 15:06:08 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id 136sm66109110pfu.87.2016.10.19.15.06.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 15:06:07 -0700 (PDT) To: Michael Richardson , anima References: <7655.1476892759@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <58c9a8e6-bd24-7568-82d3-5fbf2d7eaacd@gmail.com> Date: Thu, 20 Oct 2016 11:06:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7655.1476892759@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] concerns about selection of session-id in GRASP messages X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 22:06:12 -0000 Hi Michaeil, On 20/10/2016 04:59, Michael Richardson wrote: > > As I understand it, once an ASA has discovered a counterpart ASA in another > node, they will open a TCP connection. Some questions occured to me this > morning while cycling home from a working breakfast. Some clarification > questions are in order first, as it may be that my concern is moot. > > while "3.3.6.1. Flooding" talks about preventing loops by caching > session-id+originator, I think that the problem extends to all parts of > GRASP. > > > 1) do DISCOVERY messages have to be multicast? My understanding is that they > do not have to be. I think that they could be sent over TCP on links > where multicast means nothing (PPP, GRE), or where multicast is not known > to be available (MESH networks). > > Given an ACP made up of a bunch of point to point GRE tunnels, is there > any reason there is no discovery really to do, is there any reason why the > two GRASP daemons don't just establish a TCP connection between them, and > leave it up? They could use this connection for flooding messages and the > like. > > The responding GRASP daemon could realize that the link can be used in > both directions if the originating port is also the GRASP_LISTEN_PORT. In a context where there is an ACP, yes, but where there is no ACP, it has to be LL multicast. Logically, it's always multicast. What I want is for the ACP to do that for me. So either the ACP actually emulates a multicast socket or it gives me a specific API that does the same thing as multicast sendto() and recvfrom(). I don't think it's GRASP's job to do this. > > 2) the response from a multicast DISCOVERY is a unicast TCP connection. > (We've discussed this before, and I'm okay with it, but I still wonder if > it will be well received.) > > Is there any reason why the TCP connection for the reply has to be from > the GRASP "kernel"/"core" daemon? Could the GRASP daemon pass the enquiry > to the ASA itself, and the ASA could connect to the thing that is asking, > and reply with the M_RESPONSE itself? In my opinion, no. ASAs are the apps of an autonomic network and won't be written by protocol geeks. The actual ASA should simply register itself with GRASP and indicate that it's available for discovery; it will be some daemon inside GRASP that handles discovery. I think any other implementation model is unreasonable: we're hoping there will be 100s or 1000s of ASAs. (However, some of GRASP will be a user space library, as Toerless pointed out ages ago and as the API draft indicates.) > > 3) part two of above, if the M_RESPONSE indicates a locator (address and port) > which is identical to that connection on which the M_RESPONSE is. Or > maybe we need a locator which just says, "HERE". > Is this acceptable? It would be a protocol change, since there's no way to signal that at the moment. Is it really useful? (It would probably be a new locator option, like locator-option /= [O_SAME_LOCATOR]). But it would only work in compressed implementation where the ASA and GRASP are tightly integrated. > > > If the answer to (1) and (3) is yes, and the TCP connection can support > bi-directional flows of GRASP messages, then I think that we have a problem > if the session-id happens to be poorly chosen, and both sides initiate a > query that involved multiple M_NEGOTIATE cycles. The two ends may get > confused. Why? The M_REQ_NEG would use a new session_id. And session_ids are uniquised by also matching the source address when relevant. I don't understand the problem. > > (Again, I haven't caught up with the emails about -08 yet) And neither has the WG since it's only a candidate draft so far... (No secrets of course, it's at https://github.com/becarpenter/animaproto) Brian > If we are expanding the session-id from 24 to 32-bits, then may I suggest > simply that we actually stop at 31 bits, and make the top bit to essentially > follow the ACK bit on the TCP. I.e. the side that responded to the TCP > connection always sets bit-31 on it's session-id. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Oct 19 16:27:45 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7191297F7 for ; Wed, 19 Oct 2016 16:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjy6dtMt4pAR for ; Wed, 19 Oct 2016 16:27:41 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3981295A5 for ; Wed, 19 Oct 2016 16:27:41 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id r16so23884296pfg.1 for ; Wed, 19 Oct 2016 16:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ZAUoFSU4nGzQxE3A4KK+HFb+sAFMriUUD/eLuG4pb80=; b=Kw4avWqXxag7rx9bwXDL2xR+qc80Z3oYSS2GQpaSMqIFfRbiaKAOJktrCY/V9v8y7Q CTKVCtI0FYV7tr9R1BRdvxz5vRrN7TnEALzltPcLlAnijuJ3MceKdP54Ey8Luy4CFIre cyVeMl0ykZ1D3yusGOKwHLMyi0tngtzY6NvlxXjZTFeSmPkJ9zkKYEyfpf8IT14EX589 fdEqMVLN/A3vO1WddyBOtYmn4suCq2556nWvtWkpokAlu0b1MWKdqbzr8aMxkRHwwcEP ZACj3dOGAP1TsaXMIX4ZI9sOoIY/HNPIgqLf3cYP8Dwym3lpmTaJ5pJcjO5jTBMACsqG oVng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ZAUoFSU4nGzQxE3A4KK+HFb+sAFMriUUD/eLuG4pb80=; b=TNZor9Uwy91BzBocA3Zl+oTRkL23HBF/Iai2TokrdwXMr/C44fnG5cZnzAJYZ00KtO 2YWIFbpJXBDEtxiZV9c1xIBZfHd5/+vv/+Edn7lny7owEH6zGB2cPhZ9No4ZEIZdlU1R RQylZO59u1GqdOJ6UoNi/3+tSvJM7VFH8f00OKdIRkKV1DA3WjnERBXeRAFDjwRzql2F ZDf3N2L+OUYAk4aHSZhRY7hEftkzhR9JHaoh8TgW+XcqNlP2zbf7KZvpIEzYKG0oEfEG DKduLHWs6WyCpAJ0krmOK/sc/A1SsJ7kKucCBC4xvxvIhrR6i0yNYwv1BHi1+78Y+ZY5 KXpQ== X-Gm-Message-State: AA6/9RlRyrQ2JuOwYgVdaLqOOqTgEX2SfTLRjH21f6LCo1qGAgBGfTbJavUS8+x8B3IySw== X-Received: by 10.99.229.17 with SMTP id r17mr12743220pgh.97.1476919660824; Wed, 19 Oct 2016 16:27:40 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id q12sm44004164pfd.7.2016.10.19.16.27.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 16:27:39 -0700 (PDT) To: "Michael Behringer (mbehring)" , Anima WG References: <0f3ecf86-ead6-486b-c5a6-403bbf1e4689@gmail.com> <9e81a607a34c4ad58d6957ab2a0a3a0c@XCH-RCD-006.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <134bc8ab-ec17-0305-2360-32ceba1d6534@gmail.com> Date: Thu, 20 Oct 2016 12:27:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9e81a607a34c4ad58d6957ab2a0a3a0c@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP issue 58: Maximum message size? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 23:27:43 -0000 On 19/10/2016 21:41, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 18 October 2016 22:06 >> To: Anima WG >> Subject: [Anima] GRASP issue 58: Maximum message size? >> >> 58: Maximum message size? >> >> MR: I'm also a bit concerned that we have no statement about maximum >> message size. >> >> BC: Me too. I coded my prototype with recvfrom limited to 2048 bytes, but >> we probably need to specify something. On the other hand, Michael B wants >> to send infinitely long Intents, I think. > > :-) > > My view: > - We use GRASP to signal which Intent version we have, and where the latest version can be fetched from, and with which method / protocol. > - We use that protocol to actually get the Intent file. > > This is the most flexible and extensible model, IMHO. One possible tweak: if Intent is in fact short enough to fit in one message, we send it via GRASP. If not, we send the file coordinates. Just needs a little syntactic sugar in the Intent objective. > > So, from my point, no problem with a maximum message size of 2048 bytes, as long as we send the Intent file separately :-) Yes. I would tend to do it by defining a new constant GRASP_MSG_LIMIT so that the value (2048 or whatever) is only specified in one place, along with the other protocol constants. Any other opinions? Brian > > Michael > >> Regards >> Brian >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Oct 19 16:42:46 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177FD12950F for ; Wed, 19 Oct 2016 16:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAKpG-7UgzJA for ; Wed, 19 Oct 2016 16:42:43 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84244129418 for ; Wed, 19 Oct 2016 16:42:43 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id s8so24036509pfj.2 for ; Wed, 19 Oct 2016 16:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bMmcVahNbQdvsGsHk09UxqhUrL6xum/l+4egSovwe0k=; b=iCP8euft0b90J8jAv59GDw645BVLQXzQbfWaSVVea5cqBACGYbzODk0u4s6+M6zknS awkxmoHJQtltnPS8UUKLmerHWl0WlBJvwGKX25gQn6VJGmXuwgJa46Ny8shceRLTITCW 1MCBETMn1MMwgMUegrgbVq8JNuhXO39EIwFNDpiF20GriRLG1Cw8x/RQW8+CcqFv5BpK yjGiaHTgQubjodSKSYNFycWjl2955cl7NB1A0qbweOfbj0wode/od31Pwc0cBgQvJKdL f972Aojt39KcXa/Hlgo688C+DOPvBlBqA0LQGYSm082V4ap1glrKhqR23ysCyHr7ARkG 2GRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=bMmcVahNbQdvsGsHk09UxqhUrL6xum/l+4egSovwe0k=; b=j3f3h7LzLH4ZtuNU6TQfskpM2Ena8bu11/e5YG/aJZDMan2qrpp1MuEds5G6R0643Q MYnmKFQqKxRVhh2eEPDZZfS7q9G20hvBOzWOxp+8sgcvUQlbJBicTAW6kYBMsCRONnhN FpmYzrj3F6p28Zu4yevOWe7WcOZg771MgVG5PJfkr5ZDjO0/A6GhK4bTswxgQqTksO2Z J7ByL7Fk49bnYWB0MrDQm34YmkOVxxW++jF+vQNG34ENUo0rYrJjqELqplkZC3sDw/sP ZErfSBgVUwaA1IlWUOT62bnPMQZCiA0Ln7yXrx/+4tPHN8fUjr2Bn7aKRZfJX8ONBIgS Q8hw== X-Gm-Message-State: AA6/9RkkYce64E6yVwYIpfxa2t4BKnq9O0OvIbXx/onKup7D2W8Hl7VBck2lS4rVimb7gw== X-Received: by 10.98.201.28 with SMTP id k28mr15906163pfg.25.1476920563074; Wed, 19 Oct 2016 16:42:43 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id l85sm66288425pfk.55.2016.10.19.16.42.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 16:42:42 -0700 (PDT) To: Michael Richardson References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 20 Oct 2016 12:42:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <648.1476907175@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 23:42:45 -0000 On 20/10/2016 08:59, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Michael is concerned by the use of insecure link-local multicast. > > No. That's not my concern, actually. > > My original concern was that, when doing discovery outside of the ACP, > the client doing the discovery has to open a TCP port that anyone who can see > multicast (i.e. everyone on the link) can beat on. It's true. Malicious on-link neighbors can DoS you anyway, though. I'm not convinced there's a new risk here. > > If for some reason, the client already knows a GRASP speaker, The only way it could find the *first* one is by multicast, though. Can't avoid that. > it could > initiate a TCP connection to GRASP_LISTEN_PORT, and receive the answer there. That relies on the peer already knowing the answer (in its own discovery cache) or relaying the discovery message and replying later. At the moment, nothing tells the recipient of a Discovery message to relay it to on-link neighbors. Are you saying the if I receive a unicast Discover message, I MUST relay it unicast to all on-link neighbors? Otherwise I don't see how this would work at all. > > MR: I wonder if we shouldn't just send discovery messages on always-up > > TCP connections from GRASP_LISTEN_PORT<->GRASP_LISTEN_PORT. > > > BC: Yes, if the ACP could give me an API call for that. But at the > > moment all we can rely on is standard sockets, and in the 'no ACP mode' > > that's what we have anyway. I believe GRASP has to assume standard > > socket calls by design; if we want to fix this it's a problem for the > > ACP. > > I don't understand the problem here. > > The ACP essentially a VPN. The ability to bind a socket such that it hears > only traffic from within the ACP, while not IETF/POSIX standard, is commonly > available. (We tried in the IPSP WG to make it standard. We really tried hard) Yes, *iff* the ACP VPN is implemented to look like an interface that supports LL multicast. That's all I'm asking for - if that was stated in the ACP spec I'd be quite happy. Brian From nobody Wed Oct 19 17:08:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30A3129454 for ; Wed, 19 Oct 2016 17:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0prXaJawkPP for ; Wed, 19 Oct 2016 17:08:31 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DDD129439 for ; Wed, 19 Oct 2016 17:08:30 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 128so24450733pfz.0 for ; Wed, 19 Oct 2016 17:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=rjThNqUvWl2T7uX05h/ABoulSsbg61WiTjK0yBovPG4=; b=rpAxhz/Dto1ur5cIosAD3LZpIdVkyGS0uZJK6oL5+h0PDcp5dj03b389IsMQv+BFOM qZZLH71yZpUFy68ASqQKxiwzwTQB/A5JIhJTkfJ1YV5BZ8q9e6CLt44bBRXCFbDVdVvB o76PpEqKXw1nioseCHjX6OQzGOJE8xhdvmNTpk0aHqRG3Eqh0jt9KHAUFv3zHyUVMbMW nW7gGGKAefENz7yyXTtHEsqAIBJe9jaeqV/I+17mu7uUqRaubno0ASdp98bZFzF/Dmeb OvmJyG6c4WGkS3bNvyYO21ZeF9bSVODZpEzmY5dvrTPG4XRB9YhkLC1tHzop7p/2kQgu LJSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=rjThNqUvWl2T7uX05h/ABoulSsbg61WiTjK0yBovPG4=; b=UxiKN53psZ4lLDsgaT8Bj3oJOdRr29xl+1SPVL7xbGRSApzspBXdTdtrxPloFTaKWb zlEo/f4Nl68KgVsJPeiv3Kx4Z+b7yBLUcNCVmkHZf1NGgbYG2z9Hibb4qXcoUHYOcbDL Nd1ibqLdaaJWNPx35qZw/leEf/gfVxo+mXbL8e/RuiRKE6m3CsWQI23HzCSaz3SleKk6 qXKUSRy6nYHzUxnystTWZQD1POj/g3hhPk1fUL5M/8ivwE07Cqc9biuRoT514+tMW7z/ Mhzfr7FXUL3vLrr7SEnCIE1qDOYCtCrt653PLs1SG8ZEZD2gNvhms7CwF/dfvaO7zpOY flxg== X-Gm-Message-State: AA6/9RlOsKgG98rMd6aWhDQSIXDJoinIkq+37kxYgKdx1o0BeG+WB4T9WvXghEWkEIBVuQ== X-Received: by 10.98.16.203 with SMTP id 72mr16019572pfq.57.1476922110276; Wed, 19 Oct 2016 17:08:30 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id s64sm66377170pfk.81.2016.10.19.17.08.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 17:08:29 -0700 (PDT) To: Michael Richardson , anima@ietf.org References: <26928.1476880670@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <938f84c8-3213-d282-20ac-b0894f645808@gmail.com> Date: Thu, 20 Oct 2016 13:08:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <26928.1476880670@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] text for grasp-07 (-08) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 00:08:32 -0000 Hi Michael, That seems like a good idea. I think there might be an element of redundancy but maybe that is not such a bad thing. Regards Brian On 20/10/2016 01:37, Michael Richardson wrote: > > Brian, I began reading draft-carpenter-anima-asa-guidelines-00 and also > draft-liu-anima-grasp-api-01. (Chairs, I think they should become > WG items) > > I think though, that section 3.3 of asa-guidelines ought to be worked into > the GRASP protocol document's introduction. (But should remain in > asa-guidelines as is, except for "kernel") > > This would be some of the text that I suggested was missing that explains how > to use the different mechanisms. I haven't read -08 yet, mind you, so many > you got this already. > > Let me tweak the text slightly below. I suggest > that the world "kernel" may be confusing to some developers: it may make them > think that GRASP requires access to toggle hardware bits... > > 3.3. Mechanisms offered by GRASP > > GRASP is expected to run as an operating system core module, > providing an API (such as [I-D.liu-anima-grasp-api]) to interface to > less privileged ASAs. > Thus ASAs may operate without special privilege, unless they need it for > other reasons (such as configuring IP addresses or manipulating routing > tables). > > The GRASP mechanisms used by the ASA are built around GRASP objectives > defined as data structures > containing administrative information such as the objective's unique > name, and its current value. The format and size of the value is > not restricted by the protocol, except that it must be possible to > serialise it for transmission in CBOR [RFC7049], which is no > restriction at all in practice. > > The GRASP provides the following mechanisms: > > o A discovery mechanism (M_DISCOVERY, M_RESPONSE), by which an ASA can > discover other ASAs > supporting a given objective. > > o A negotiation request mechanism (M_REQ_NEG), by which an ASA can start > negotiation of an objective with a counterpart ASA. With this, > there is a corresponding negotiation response mechanism > (M_NEGOTIATE) mechanism for an ASA that > wishes to respond to negotiation requests, and a set of functions to > support negotiating steps (M_END). > > o A synchronization mechanism (M_REQ_SYN), by which an ASA can request the > current value of an objective from a counterpart ASA. With this, > there is a corresponding listening function for an ASA that > wishes > to respond to synchronization requests. > > o A flood mechanism (M_FLOOD), by which an ASA can cause the current value of > an objective to be flooded throughout the AN so that any ASA can > receive it. > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Oct 19 17:36:42 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21181294C1 for ; Wed, 19 Oct 2016 17:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UQWwkmfGcWz for ; Wed, 19 Oct 2016 17:36:40 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3AF212940E for ; Wed, 19 Oct 2016 17:36:39 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 128so24823749pfz.0 for ; Wed, 19 Oct 2016 17:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=emsNTTDb/WP5j7DD4rVKRtdHa0Bgj73zrh+Gd8S5b+w=; b=fufh9ecKgxronQap7YQkrYTunDCTXR2gFXcW221a2M4n3pCfJScSwZBdDT1q+qGipz V09al1LDokpRez8uSL8ljokG95TZu30HcBIElRmNLQ3BNzCbs5CMb4Do1ld3KPPkqDSd xR+zMZO4i3sv2UkgFK20EDaG9V5bC4p+6UUKiTbUnmsbUCyzi3S8IFEcE4DUQHv8aDrP S8P+J7r2/SeeuCxmy99JnqouL8NCFPBx/O8GiD1KE71oU0ya5h1u/ihlSMVMnt/I3AT3 3LItAg8sGAh1x5HPwIvZIykrBifXPn+ZrrZlSFSmLpkeWgRVwAcXdCJB+xtLozaH4MaJ YNzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=emsNTTDb/WP5j7DD4rVKRtdHa0Bgj73zrh+Gd8S5b+w=; b=SWXueBU/HpyQDWBuSlBsxC7pZoFj1lO5a3pEzyR9zS3cFRja2fFVYDgFD0GihTrvHl cryl1nQf8znESJXWe1Ks3vFHgW9DeUkefsLBBAeA7huGttNuDQpLjK8KyGjQxApGuLMR 8vNzkYa+LsU3DWSndgr+rHTvUkGBvAIsMW7CJwtRDlc5313dp++yl6L4uPuJnndA3kvH vBiMbn2qnhs0/dhKJVZ6z+F4oDF2Vi0ERVoeeeioMCzXBaWmt7SDsi3y6bl+s5yivOei 74Ur7JyyiQ/aG9BL64AxQCKOIIHLsLrbrv5ej/+G3t3uhHXJggTz8Bo/N6IPH1g3UD7M OClQ== X-Gm-Message-State: AA6/9RlZQN/+OnSNRSG5SCiUMpqkFbfeL1Ejnr61bVd3OzsuUcsnKwSB5vd16yPM8b9mxw== X-Received: by 10.98.130.11 with SMTP id w11mr16439347pfd.101.1476923799319; Wed, 19 Oct 2016 17:36:39 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id r77sm8090565pfb.2.2016.10.19.17.36.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 17:36:38 -0700 (PDT) To: Michael Richardson References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> <1693.1476907434@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> Date: Thu, 20 Oct 2016 13:36:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1693.1476907434@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 00:36:42 -0000 On 20/10/2016 09:03, Michael Richardson wrote: > > Brian E Carpenter wrote: > > MR: Given that CBOR has only 1,2, and 4 byte uintegers, why do we have > > a 24-bit session-id? > > > BC: Well, it's a hangover from the pre-CBOR TLV format. But I think > > it's true that we'd increase the average message size by making it 32 > > bits, since there are a lot more random numbers between 2^24 and 2^32 > > than between 1 and 2^24. > > > MR: okay, hangover that you'd like to save a byte. But CBOR doesn't > > let you save that byte, so just make it uint32? > > > BC: CBOR sends 1, 2 or 4 bytes according to need, as I understand it. > > If my session-id is 0x010000, then CBOR will send 4 bytes. > In the unlikely (1/2^27 + 1/2^24 + 1/ 2^16 chance, less than 0.001%) that a randomly generated > session-id has two or three leading zeros, or is less than 24, CBOR will send > fewer bytes. (I think, sending more bytes is still permissible). > > In most cases, it will send 4 bytes, so might as well use them. Yes, I think you are correct. An easy change if people agree. > See my email today about perhaps using bit 31 to partition the session-id > space between TCP sender and receiver. As I said, I don't really see the issue there. According to https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.6 the negotiation (or synchronization) session has its own session-id, distinct from the one used for discovery, even if they did re-use the same TCP session. Messages for the two transactions (discovery and negotiation) could be demultiplexed using the session-id, even if they overlapped in time for some reason. The ids will never clash, because the same party initiates discovery and negotiation. Brian From nobody Wed Oct 19 18:59:00 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C25129473 for ; Wed, 19 Oct 2016 18:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpPNIpi66F0V for ; Wed, 19 Oct 2016 18:58:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55EC129864 for ; Wed, 19 Oct 2016 18:58:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E836200A5; Wed, 19 Oct 2016 22:13:35 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C8E5F63AFE; Wed, 19 Oct 2016 21:58:54 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 01:58:58 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Brian E Carpenter wrote: > Michael is >> concerned by the use of insecure link-local multicast. >> >> No. That's not my concern, actually. >> >> My original concern was that, when doing discovery outside of the ACP, >> the client doing the discovery has to open a TCP port that anyone who >> can see multicast (i.e. everyone on the link) can beat on. > It's true. Malicious on-link neighbors can DoS you anyway, though. I'm > not convinced there's a new risk here. A direct TCP connection from client to server would require that the attacker race (or actively MITM) the process. With the multicast followed by TCP to client, the attacker doesn't have to be an active attacker: they just have to see the multicast and then send traffic. >> it could initiate a TCP connection to GRASP_LISTEN_PORT, and receive >> the answer there. > That relies on the peer already knowing the answer (in its own > discovery cache) or relaying the discovery message and replying > later. At the moment, nothing tells the recipient of a Discovery > message to relay it to on-link neighbors. Are you saying the if I > receive a unicast Discover message, I MUST relay it unicast to all > on-link neighbors? Otherwise I don't see how this would work at all. I think I've lost too much context to answer properly to your conjecture. What I was saying was, *IF* I know how to find a machine with an open GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that I should receive my answer on that connection. In the 6tisch case doing multicast is either expensive or unsupported. On the other hand, we can quite easily declare that the 6LBR / DODAG-root (the router at the top of the tree) will have GRASP_LISTEN_PORT open. >> I don't understand the problem here. >> >> The ACP essentially a VPN. The ability to bind a socket such that it >> hears only traffic from within the ACP, while not IETF/POSIX standard, >> is commonly available. (We tried in the IPSP WG to make it >> standard. We really tried hard) > Yes, *iff* the ACP VPN is implemented to look like an interface that > supports LL multicast. That's all I'm asking for - if that was stated > in the ACP spec I'd be quite happy. I don't think we have a choice. It has to look like that. If the ACP spec doesn't say this, then it's because it's too obvious to state, which naturally means it really really needs to be stated. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAgk3ICLcPvd0N1lAQK3kAgAkyQfydqQAbb1RATho50xbm+R9UM9lASg rNp6lhmBp3oMDstiiZf6fIxN7PkICtx0V8BADKgiigaYsjESoNlefwUg+Ilgto5M EyI7398yLXmRbvOZoMPKYAu7NuUlkdKgraW9kXNeBGRPmmVL3iRJf8KaOKGb5g9i fV0YaiuNJ9xG/4htpgFWp8CK/o+AQEo4Y3KRBG5VvDqpX/DqHJDt+jheE6y9lTA3 bKKcNuoLkZwJhmNV5Ck+9/NbcScLckWxPR/U1WErmMZZJmIOmFFaSuD8WwGm4vhT AnIJQ2Rg4xqdz56Bgyez9TO5ZGyCwjA5dW9YzWH7qXr8SW4V4jkAng== =CaJn -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 19 19:01:46 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCEC1294DC for ; Wed, 19 Oct 2016 19:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEUYS_Hdsawz for ; Wed, 19 Oct 2016 19:01:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0974D1288B8 for ; Wed, 19 Oct 2016 19:01:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7DF16200A5; Wed, 19 Oct 2016 22:16:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1E3E963AFE; Wed, 19 Oct 2016 22:01:42 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> <1693.1476907434@obiwan.sandelman.ca> <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 02:01:45 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > As I said, I don't really see the issue there. According to > https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.6 the > negotiation (or synchronization) session has its own session-id, > distinct from the one used for discovery, even if they did re-use the > same TCP session. Messages for the two transactions (discovery and > negotiation) could be demultiplexed using the session-id, even if they > overlapped in time for some reason. The ids will never clash, because > the same party initiates discovery and negotiation. But, can't there be multiple back and forths of M_NEGOTIATE? As such the same session-id would be sent in an M_NEGOTIATE in both directions. If not, then I don't understand negotiation at all. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAglg4CLcPvd0N1lAQKlhgf/QoKtszKSMXq01wpldxHqpxXGyfr8Fm8m VwC9WPuh6kdNG6dfSxXzWBkadJAYlS4uFklvhPFDwcvswFO/xciElqdJOIRn0ttE 9IhkbD/XhNX1eehYD1Mb+9Rrs5vwcSrmwkDYlChjsATEW04Ds/pRVztjT6iktT/j bDJCqGuSB5ADMEQe0SWq3vd9YQq7eIF/gi6Xs2oF8o7MbWOwk1FLNnlj9OtwAOmA /kAHEmnb37dqaqv0kTDBJmDl+cwEbBykqPquTfDvTNprYNO29Q5eP5H8LspHGGiE BoYs8Bzh19fOgz9QhwXfzmhRR291VIeUtYpxUjC9K3iOVHeLS8q5mA== =j/Qo -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 19 19:12:46 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AFE129857 for ; Wed, 19 Oct 2016 19:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQI0EeaLwDgV for ; Wed, 19 Oct 2016 19:12:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B339D129650 for ; Wed, 19 Oct 2016 19:12:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 26277200A5 for ; Wed, 19 Oct 2016 22:27:23 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B8EAC63AFE for ; Wed, 19 Oct 2016 22:12:42 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] M_END, O_ACCEPT X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 02:12:44 -0000 --=-=-= Content-Type: text/plain Brian, is there some reason why the M_END could not be: accept-option = [O_ACCEPT, ?stuff] or is it your intention that if the one end has additional information to add (such as port number where the requested service has been started), then it should use an M_NEGOTIATE and extend the objective to include the additional information, and then perhaps the M_END would occur from the initiator accepting the result? If so, I'd very much like an example of that in the document, as this wasn't clear to me until just now. (If in fact, I even got that) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAgoGICLcPvd0N1lAQI9gwf+IAjamEX+NI/vRFn3eU6JLVGGFXXncKP3 D/DHNHW+NNTMS7PlX4YEdqMcdOtGYYiJPDq3WYhvxzhyQj/Z7s/qIMitvlAblX6U ma4eMCzm5dLbaxwF9wOcwU7Rk71it0YMX4IXRXTOXrOLKBRku760Tq+oySLDrEuv +TuGHELQZ9JMzyrkfe4TlLbUCfQ7zkhTnopKqtBqjbS4hhzrdspAUqwznxnGo2kc dPEp5Wx3l++bwsHFQ5bCKypZ1Xvboq822o/tAlzJm6+IVRx6BxXjCnumIHYus3Yz fO0GUz+rJs+fQRL06yUygE6oDVNKAPeZbJP5OlkkmihLel8DBt4iNg== =IemV -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 19 19:34:22 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23744129415 for ; Wed, 19 Oct 2016 19:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp5VtfOHSFXV for ; Wed, 19 Oct 2016 19:34:19 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C7C1200DF for ; Wed, 19 Oct 2016 19:34:19 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id r16so26470134pfg.1 for ; Wed, 19 Oct 2016 19:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=btT6TFL0HnqyL9f22MsxsZVtSybldY1DU92+u//qle0=; b=mF3Xuu98jt/6D5J7TbUqegkdoI2cxGNn6NIREfCCrz3ik/FAg+RWzO0ii61dblIlKN K+CWbGmzoLLiSCBpEqIlODrnRSxRyxscPeqBJ+LeMIpg0nqleaAOSkT/Xcw42wYA0/Xi 1WgBfVMU3CXw+Fz5KKSuqdDBqXOqqAIFVk0INdQdhSoHodPBsy9BwJ/gl1MJD7WJxv3w z8mzB4YjbOJdoNMV4qiZB5wV4j1Ci4m4UvNdgbax8LI468OU1zEEwBoQCo0PqNV0lSZS p6gMLft5FHEYcapVg6RLSTMrbymJn1Jo66zTwhBTkRCLK/a3h2s7qUyUwIyGyPhUYqAg DCEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=btT6TFL0HnqyL9f22MsxsZVtSybldY1DU92+u//qle0=; b=VqPGWtXmDbfb7/hX5lvjU5e3v/SgZ9aN3jj5KFcPjz8m6ZCjUYJ3wNulzpiWWXkJjY XmJLhaXI4Q7z0MtzxWzwmXF0BPCEair0uBwnpXpLNe7cT1hG1+0gHQbRpnacSCuUq34j J/0sU6ubKNu8rVeE7lBxRF1KFlPFtL7IJwU657OIS9AylYUoMefqUceDJNhLMYzePE3A bxrOCx76cppuMJWS6yYlgpZX5ibX4+nnULcod7SWQxUCpnGoK5nnOZjpq5qOPKcwfV8Y GrhhJn1s9hrgwa+nU0w0oNcp7OCgmLVabABhNhEP4VIvMZexy3zqPJrV+vsjjTFin7FJ FBew== X-Gm-Message-State: AA6/9Rl2FN4/w2IdI4tMRwA6cFhATS2tQJw3dgWWTe4bvysyzmze30SQm1cf2/iJOJn65w== X-Received: by 10.98.93.83 with SMTP id r80mr9678249pfb.17.1476930858438; Wed, 19 Oct 2016 19:34:18 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id t29sm44625444pfk.26.2016.10.19.19.34.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 19:34:17 -0700 (PDT) To: Michael Richardson References: <0f3ecf86-ead6-486b-c5a6-403bbf1e4689@gmail.com> <4112.1476908026@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3b8a49d2-cfc5-199b-2650-e35abfffbd54@gmail.com> Date: Thu, 20 Oct 2016 15:34:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4112.1476908026@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 58: Maximum message size? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 02:34:21 -0000 On one point: > *could* we make the maximum objective (assuming intents are directly in an > objective) size itself be a synchronizable parameter? We could even make it negotiable, since GRASP supports negotiation :-). But I think we'd better start off with a hard limit so that we don't encounter 10GB requirements during initialization. I could imagine adding a max_size parameter to the API, too, so that a given ASA could accept larger messages for a given objective. So maybe the best thing for now is to define a *default* maximum size in the spec. Regards Brian On 20/10/2016 09:13, Michael Richardson wrote: > Brian E Carpenter wrote: > > BC: Me too. I coded my prototype with recvfrom limited to 2048 bytes, > > but we probably need to specify something. On the other hand, Michael B > > wants to send infinitely long Intents, I think. > > libcbor nicely responds to an incomplete message with CBOR_ERR_NOTENOUGHDATA. > This lets you grow the data structure for the situation where Intents are > large. > https://libcbor.readthedocs.io/en/latest/api/decoding.html#associated-data-structures > > It would be better if the initial parts of the structure could be examined > even in the error case, and if it was the case that one didn't want to deal > with the rest, one could be told how much more to discard. Or, in some > cases, one wouldn't know (streaming arrays, etc), and perhaps the answer is > drop the TCP connection. > I think that this could be added to libraries. > > What I guess I'm concerned about is a CBOR definite array structure that says > that there are 10 Billion items to be expected, the library goes and > allocates that much ram (10G), and the system fails or goes into swap hell. > No need to actually transmit the 10G of data. > > libcbor can be configured to use a custom allocator rather than malloc(3), > and this is likely the correct answer: to provide some reasonable limit on > amount of memory for decoding... which comes back to how big will the Intents > be. > kilobytes? probably. > megabytes? maybe one or two Mbytes. > gigabytes? most certainly not. > > *could* we make the maximum objective (assuming intents are directly in an > objective) size itself be a synchronizable parameter? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Oct 19 19:39:57 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ABD129412 for ; Wed, 19 Oct 2016 19:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ndotqT3NszJ for ; Wed, 19 Oct 2016 19:39:54 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824C012947F for ; Wed, 19 Oct 2016 19:39:53 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id s8so26515742pfj.2 for ; Wed, 19 Oct 2016 19:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0kHVSCzxlqNNI/Hlt+eQzUVuM96v5/QqAQETmP+biaw=; b=Md8ldSanj0ECQAlnsthr5ILdoz8XqzTHmsg9OtknaqEqC0poZZxs4oortDmXus9IOn HAbBf5J88XGXtn2nVH/eYQtw5RqfJjJV4rSIrHCZgrKvv4eIg+jQedWnB8UfY99u/G0u U7ac7wbsgRSh2iszF4nuI8e3mfEk207b8JrqNtpb0VWRlOpCjzU98R3wGBjZKTtZjghB 1VS5xcjoPmc283WSxv11BD56hHvLiA4H3fuKV07pw2vUdlGtjL7ghSUHgfRCax93V/eN WVl/BjDfoZGEtUPiThNJesAF4WzqD3H9aPq9pUbjvC5V4c7XzcNVQ/wW9GGO+nfVM+fc cuww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=0kHVSCzxlqNNI/Hlt+eQzUVuM96v5/QqAQETmP+biaw=; b=d/7nQ03V6umXo1wI7FVIkGKeYkX2oNOrUKWh2iomqTrgtg0vlYNkF6i9Im7blOBRcu xz8cgEeMxScvRrkfKftd5mf7R/V/GGcuehzDa3DKm5RD1HZsBdQF9QyDDAZvuF0q8DBq jeO/YuUZ/niJpeFAfcpsWgqOPQbA5GIpxgsXnxGzdQWnnRNMF2oyI5BkZe0pHuke3kCe 2S4VUfmqkhR7fnXHDntTYUckMSXsCmEk4d1vBHhGzCGEz6EaqA+lmGFd5jv7DSzSGLB7 Qj3xCqaOj8x+K1SUJY0DvrVmpUG7K9fsseWrHFntYWwvMva6d5fSmigDQTbo4lS1urzv aRMA== X-Gm-Message-State: AA6/9RncN+g/9iBBYzP+mxa+SXFaDzI4/HI3jPMicWk2sJ0+F0pTRewdwMlVBogTBFKT0w== X-Received: by 10.98.12.208 with SMTP id 77mr16915646pfm.14.1476931192708; Wed, 19 Oct 2016 19:39:52 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id bx5sm66954899pad.6.2016.10.19.19.39.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 19:39:52 -0700 (PDT) To: Michael Richardson References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> Date: Thu, 20 Oct 2016 15:39:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <19006.1476928734@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 02:39:55 -0000 On 20/10/2016 14:58, Michael Richardson wrote: > > Brian E Carpenter wrote: > > >> Brian E Carpenter wrote: > Michael is > >> concerned by the use of insecure link-local multicast. > >> > >> No. That's not my concern, actually. > >> > >> My original concern was that, when doing discovery outside of the ACP, > >> the client doing the discovery has to open a TCP port that anyone who > >> can see multicast (i.e. everyone on the link) can beat on. > > > It's true. Malicious on-link neighbors can DoS you anyway, though. I'm > > not convinced there's a new risk here. > > A direct TCP connection from client to server would require that the attacker > race (or actively MITM) the process. With the multicast followed by TCP to > client, the attacker doesn't have to be an active attacker: they just have to > see the multicast and then send traffic. > > >> it could initiate a TCP connection to GRASP_LISTEN_PORT, and receive > >> the answer there. > > > That relies on the peer already knowing the answer (in its own > > discovery cache) or relaying the discovery message and replying > > later. At the moment, nothing tells the recipient of a Discovery > > message to relay it to on-link neighbors. Are you saying the if I > > receive a unicast Discover message, I MUST relay it unicast to all > > on-link neighbors? Otherwise I don't see how this would work at all. > > I think I've lost too much context to answer properly to your conjecture. > > What I was saying was, *IF* I know how to find a machine with an open > GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that I > should receive my answer on that connection. A says discover("B") to C, but C doesn't know where B is. So there will be no answer, unless C does extra stuff. > In the 6tisch case doing multicast is either expensive or unsupported. > On the other hand, we can quite easily declare that the 6LBR / DODAG-root > (the router at the top of the tree) will have GRASP_LISTEN_PORT open. Yes, you have topology knowledge in that case. Brian > > >> I don't understand the problem here. > >> > >> The ACP essentially a VPN. The ability to bind a socket such that it > >> hears only traffic from within the ACP, while not IETF/POSIX standard, > >> is commonly available. (We tried in the IPSP WG to make it > >> standard. We really tried hard) > > > Yes, *iff* the ACP VPN is implemented to look like an interface that > > supports LL multicast. That's all I'm asking for - if that was stated > > in the ACP spec I'd be quite happy. > > I don't think we have a choice. It has to look like that. > If the ACP spec doesn't say this, then it's because it's too obvious to > state, which naturally means it really really needs to be stated. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Oct 19 20:05:31 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E73129473 for ; Wed, 19 Oct 2016 20:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw38bLjKx7lV for ; Wed, 19 Oct 2016 20:05:28 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782D2129415 for ; Wed, 19 Oct 2016 20:05:27 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 128so26974843pfz.0 for ; Wed, 19 Oct 2016 20:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SkR7RTLqMwrpmXU6oBCBJvZOJaNorfEB1iciaAC+wLc=; b=PCJBD3rI1cjBHRyPIr93FAf2iANiL82tdm3BO6tR1xUxpzp4WJhL5SRcA/zcbHTlly O1APKOtOWQzUlGJ9dNFtqVC2xwm6SuT05KShMWUKbpDcVu5MIXAXPBHCdPlDlAh11m/d pNQ5wdWJFK47UKJf/hW/uzSx7YYkIMe/29eD6ArNjc/KVKJmKLNX5XgFKtt1bsTb9Q3N 9J1d48yU084vfsENu8RO220m7O20tiHpMLawvyoTYopnViplsli4I4jkz4go3vDK8qKl 14ub3X0VMFLmjUhFejsyJdZZuA8s/bWoCWsufdEbx5XrnbUV1NqK6P6mrnkfIMJ02vUQ D6/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=SkR7RTLqMwrpmXU6oBCBJvZOJaNorfEB1iciaAC+wLc=; b=VSY6cSjkOAaxPdx0ip/hudRPF9gB266EJKJRqWTgtrsRUHpOGyhmA/h9SXIXMLrJTX Iu6DHXsMzxj2a6disyBg24YbmT+wTg2O9ZO7wAj1XsCrOPzh9VgdPlqnjHWZxlT8P6/S Ehsqlk+PRWfGzzHZxgmu2KodXu8J5xz5UJ4cC8wN9bMlWSp+wJ8wuWr/vsYqdqUh0eVT CWdzbtslXoAvbFcWA00yXey+FZlsWPJxwoFiBh6BmUckWYZDRXw9B3r73cGYG8ChvEiv BRv7u9qo19RuXgAK9aYd6Paaa9HtvPLfD5A+ePkpwTrq/FRSQ5oV0Wp+VN2lF4IlMNmU gqEA== X-Gm-Message-State: AA6/9Rl4jb/zF4Vc6nwxs1fJFXpH3pZRlS+z/Uk6/Pg/BH/yAaP6pudYcXLkBzH5PN0s9A== X-Received: by 10.98.205.207 with SMTP id o198mr16967458pfg.114.1476932727080; Wed, 19 Oct 2016 20:05:27 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id o75sm66879352pfi.25.2016.10.19.20.05.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 20:05:26 -0700 (PDT) To: Michael Richardson References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> <1693.1476907434@obiwan.sandelman.ca> <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> <19660.1476928902@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 20 Oct 2016 16:05:30 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <19660.1476928902@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 03:05:29 -0000 On 20/10/2016 15:01, Michael Richardson wrote: > > Brian E Carpenter wrote: > > As I said, I don't really see the issue there. According to > > https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.6 the > > negotiation (or synchronization) session has its own session-id, > > distinct from the one used for discovery, even if they did re-use the > > same TCP session. Messages for the two transactions (discovery and > > negotiation) could be demultiplexed using the session-id, even if they > > overlapped in time for some reason. The ids will never clash, because > > the same party initiates discovery and negotiation. > > But, can't there be multiple back and forths of M_NEGOTIATE? > As such the same session-id would be sent in an M_NEGOTIATE in both > directions. Exactly. Like my example that I sent. Manually prettified, it reads: A to B: [M_REQ_NEG, 8280376, ['EX3', 1, 6, ['NZD', 156]]] B to A: [M_NEGOTIATE, 8280376, ['EX3', 1, 6, ['NZD', 155.5]]] A to B: [M_END, 8280376, [O_ACCEPT]] What's the problem? 8280376 is unique in A, and {8280376, A's address} is unique in B. They can't get confused, even if there are numerous negotiation steps. OK, so now I'll make one with multiple steps [pause while I run my example generator and prettify the results] A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, 294.75]] B to A: [M_WAIT, 11146801, 20899] B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 84.0]]] A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, 235.8]] B to A: [M_END, 11146801, [O_DECLINE, 'Insufficient funds']] I use random numbers to generate the test cases. That was a nice one, it shows B telling A to wait and it shows a failed negotiation. But since A and B both know who they are, the fact that the session-id is identical isn't a problem. Brian > If not, then I don't understand negotiation at all. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Oct 19 20:14:46 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3748A1295F3 for ; Wed, 19 Oct 2016 20:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP9e0Pvo5_Fi for ; Wed, 19 Oct 2016 20:14:44 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A151295B8 for ; Wed, 19 Oct 2016 20:14:43 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id e6so27056088pfk.3 for ; Wed, 19 Oct 2016 20:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=SDrfceZ1p7nK6QBYMQbiq3mAoXbXFLZOssy6fcz6W3A=; b=zFWjd73Tg8cDrhNv/VzkLDCM/UBmAAMojx+hrRfdA4O1uBVpqNmg0sEaHVE/B6E+np mgrj49V+1XixG2VJv5lEoWXGp2wQPk3PQjTdGPlO7lF8DQub1mwNgz+UIEor+DUk7PNY 14RCTzo9xAZ5AbYYbGNkuqoBjYBjD7BE8ydKNxNb/+GsDoSCEnFskoOSM4zpBIRmP0vS mNFPyuN69vt2I+/BOFWZ+fuaK/hrLPxlvD43mR6TccD0CMXfPY8/GK+Nz5JOGQ/UiS6b ooO5ErNLMZTgGnEphkAsua56+pnZMYygxQRHqXsL8GL9dF1xWa58JPLhPx5LuzoXHuGL wExA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=SDrfceZ1p7nK6QBYMQbiq3mAoXbXFLZOssy6fcz6W3A=; b=j2x6DOZ+7UQP7kEiQm3GQQDIk7u/ViwCpXnHvOhjBHlxvufD3uI1pWUUirlS79RAPY p8FMxQ4iVpfyLweOUbqBaTipsaUVDc3LbG9vcJm7sva8zx4xKDwD4kw/hKn6t9RoUJK7 4onnYD0tOS6oEJcvBLI4pVzBxlOQXuee/wBWX08IpB4kdG7/k+YdGs4otAkSGd2H8+TN BGwL8DD/vWWpe9845JoyVFVX+X6feSU1WXYiPVF84TV28o23/8Kzrou7C19QKNu4FU7i HjuJxaK4RGikj/o0NaGdM6RgDsAJ+NeJ3KpB5OEsdzfoFdyFE1yMBKip9Gyn6Xbyx5vH Z4Ww== X-Gm-Message-State: AA6/9RnlCJvNLTSqpZD2ERhHB+mJqHATehwzf3PgYsBVxaRZTmeKVqp20GXxUspQZ+Xx9w== X-Received: by 10.98.198.132 with SMTP id x4mr17251921pfk.23.1476933283394; Wed, 19 Oct 2016 20:14:43 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id zh13sm67125666pab.4.2016.10.19.20.14.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 20:14:42 -0700 (PDT) To: anima@ietf.org References: <22445.1476929562@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 20 Oct 2016 16:14:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <22445.1476929562@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] M_END, O_ACCEPT X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 03:14:45 -0000 On 20/10/2016 15:12, Michael Richardson wrote: > > Brian, is there some reason why the M_END could not be: > > accept-option = [O_ACCEPT, ?stuff] > > or is it your intention that if the one end has additional information to add > (such as port number where the requested service has been started), then it > should use an M_NEGOTIATE and extend the objective to include the additional > information, and then perhaps the M_END would occur from the initiator > accepting the result? Yes, my mental model is that you would negotiate until everything was settled, so there would be nothing left to say in ?stuff. Because there are no constraints on the format of the value of an objective (except that it can be CBORized), I don't see why this would be restrictive - negotiation allows values to be passed in both directions anyway. Really [M_END, session-id, [O_ACCEPT]] is just the final handshake. > If so, I'd very much like an example of that in the document, as this wasn't > clear to me until just now. (If in fact, I even got that) Ack. Brian From nobody Wed Oct 19 20:19:26 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B8129415 for ; Wed, 19 Oct 2016 20:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbseegsPMAkS for ; Wed, 19 Oct 2016 20:19:23 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740AA129465 for ; Wed, 19 Oct 2016 20:19:23 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id s8so27126437pfj.2 for ; Wed, 19 Oct 2016 20:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QS1ZTG0sBDniwT8lk9ZME2ygfEOMK2kVuvUUbPJiVAE=; b=B7d98sl7JO5LQ0jr38Hu5G6IHPmeLi6ceyo77sEcQVQrcgjfGZZZ2bvy5lh7cXAEjy 5R1G9mrr4IJuSm4Y+tXEWoA3KE+DvmrmOzDZ6o/VWiBRYg6m/99EtEUNQAY29H4uUAPw FzcVzMzNriu5mzY8IkKt4H6oUr/6ngqvqlxxJHh6tkbpcZiXx4oAPCefoAqfeNGqhRbf LnOViX0HNcs///+hSTffhdDc8LRG+M2TzKIAjsarIpzsXD0gFB/cV30yqp11siVpYBj6 vgebjnIwz/CSkZfbRCYAHL2xSaH5fJ3/4BV2cGvcsXlGp2PYfzK8v1TO+OpLe3Ayw0Ri 0DFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=QS1ZTG0sBDniwT8lk9ZME2ygfEOMK2kVuvUUbPJiVAE=; b=k+Piv0dWBdKe7qMR7vo+iFidgL/ZfrnDrVHXtI+f1mY4W5Y4S2VuzDteBe/Cq29NcN BBoMsVKFzLxUgL1aI91FuA2/YUavTzSvmNNe3kasnzLl6Jbi/+TJTkFFE7plaB/We/ly dU94LLTox1bww4pthq5ztzuGJcw65hoLO4gQBLMXeUtPip0rQHpaqCoDSRPoP9sa62ZA M4JpoiX8hglKTy1qBrcq1X8/X5BiZap7Goev3iI+kdObeKJnxpMvQ1cUs9jdovrcTAvJ 9u8evUQeKRfAPNdi53Fz9uPtd6b7H/4tlfyz+/GnqpIbGn/RD1kg43CUOCRnxYnoPMJG yT2Q== X-Gm-Message-State: AA6/9Rnb2WmzDbtHqHwqmdy1ZZywfZ0jCowaRQt6ao18vgt2/CWnodOW1Z67ywhTOrhkmw== X-Received: by 10.98.63.78 with SMTP id m75mr17320090pfa.19.1476933562761; Wed, 19 Oct 2016 20:19:22 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.82]) by smtp.gmail.com with ESMTPSA id oo10sm63736016pac.12.2016.10.19.20.19.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 20:19:22 -0700 (PDT) To: Michael Richardson References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> <1693.1476907434@obiwan.sandelman.ca> <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> <19660.1476928902@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 20 Oct 2016 16:19:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 03:19:25 -0000 Oops, there was a prettifying bug in the previous version... On 20/10/2016 15:01, Michael Richardson wrote: > > Brian E Carpenter wrote: > > As I said, I don't really see the issue there. According to > > https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.6 the > > negotiation (or synchronization) session has its own session-id, > > distinct from the one used for discovery, even if they did re-use the > > same TCP session. Messages for the two transactions (discovery and > > negotiation) could be demultiplexed using the session-id, even if they > > overlapped in time for some reason. The ids will never clash, because > > the same party initiates discovery and negotiation. > > But, can't there be multiple back and forths of M_NEGOTIATE? > As such the same session-id would be sent in an M_NEGOTIATE in both > directions. Exactly. Like my example that I sent. Manually prettified, it reads: A to B: [M_REQ_NEG, 8280376, ['EX3', 1, 6, ['NZD', 156]]] B to A: [M_NEGOTIATE, 8280376, ['EX3', 1, 6, ['NZD', 155.5]]] A to B: [M_END, 8280376, [O_ACCEPT]] What's the problem? 8280376 is unique in A, and {8280376, A's address} is unique in B. They can't get confused, even if there are numerous negotiation steps. OK, so now I'll make one with multiple steps [pause while I run my example generator and prettify the results] A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 294.75]]] B to A: [M_WAIT, 11146801, 20899] B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 84.0]]] A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 235.8]]] B to A: [M_END, 11146801, [O_DECLINE, 'Insufficient funds']] I use random numbers to generate the test cases. That was a nice one, it shows B telling A to wait and it shows a failed negotiation. But since A and B both know who they are, the fact that the session-id is identical isn't a problem. Brian > If not, then I don't understand negotiation at all. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Thu Oct 20 05:57:01 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E2812940B for ; Thu, 20 Oct 2016 05:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLwMiIN034ZG for ; Thu, 20 Oct 2016 05:56:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479F21294EE for ; Thu, 20 Oct 2016 05:56:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CB6FC20553; Thu, 20 Oct 2016 09:11:39 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DB4A7639BA; Thu, 20 Oct 2016 08:56:57 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 12:57:00 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> What I was saying was, *IF* I know how to find a machine with an open >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that >> I should receive my answer on that connection. > A says discover("B") to C, but C doesn't know where B is. So there will > be no answer, unless C does extra stuff. So, C would forward the discover("B"), and then when it gets to B, it would connect directly to A, and introduce itself? This is obvious now that you give this example, but not from the document. I might also think that B would connect to C, and then C would tell A. This clearly fails if A has a LL address only. >> In the 6tisch case doing multicast is either expensive or unsupported. >> On the other hand, we can quite easily declare that the 6LBR / >> DODAG-root (the router at the top of the tree) will have >> GRASP_LISTEN_PORT open. > Yes, you have topology knowledge in that case. Do you agree that a discovery("C") sent to C over TCP should be answered over that TCP connection? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAi/F4CLcPvd0N1lAQI5sQf/ebloNTyPPvnpqyrZGYQoFypBsWjzQdp7 vfuoQbhcCedOnpnuDiSl3tCChupcy2WuHGunCE+3+agJKFaSeWwX+o+3cP4KCWEc /tSLPcC960o/P38KACo5KuBdDeC6yoKPltu+rtk/7T6t8XTtRaTC2lkoITsgWqOk FORv+uauRF5wx1HRZ6dYNz/LpRLXFi6o1H4FAj/BqnZPbp+YbVjc5AEMX0sTHBDl 2zHAOvPg/xa3Zqcw2IIvA86dsTv4GOMeiys+C+Gw3UG0zD0n4DKqZjngPESi0+iI mH3ao5Gzjb8qPH4dYjBn2rgwWpvZCTB+bT+9WqeLVt/pKIQOjBcbNQ== =aksU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 20 06:02:14 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E12112954F for ; Thu, 20 Oct 2016 06:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqOWcqh4GCh1 for ; Thu, 20 Oct 2016 06:02:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C5E1295CB for ; Thu, 20 Oct 2016 06:02:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 29C7420553; Thu, 20 Oct 2016 09:16:45 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2FA4B639BA; Thu, 20 Oct 2016 09:02:03 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> <1693.1476907434@obiwan.sandelman.ca> <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> <19660.1476928902@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 13:02:13 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Oops, there was a prettifying bug in the previous version... ... > OK, so now I'll make one with multiple steps [pause while I run my > example generator and prettify the results] 1> A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] 2> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] 3> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 294.75]]] 4> B to A: [M_WAIT, 11146801, 20899] 5> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 84.0]]] 6> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 235.8]]] 7> B to A: [M_END, 11146801, [O_DECLINE, 'Insufficient funds']] Lines 2 and 5 look identical to me. As do lines 3 and 6. > I use random numbers to generate the test cases. That was a nice one, it > shows B telling A to wait and it shows a failed negotiation. But since > A and B both know who they are, the fact that the session-id is identical > isn't a problem. Does it work only because line 4 precedes line 5? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAjASICLcPvd0N1lAQITYQgAgA5fqhtSxQKUguvGkpjuqrV3k135CiuP NehCI9V12kYGXYrz0/w43LGrrKyeRA8ymkU0gEnsyeAUpU0zAQGgNvCv7jMGkXJB fEAp7lzG7h8NXh10S8Rnka4GNeWnhoIeH41++vHMs2axxuRg1/bMVx+ZZT4LPbfV 2F9ZVssCPZfnuphRZMYcly5NuEPGp7AXfIM4f6g8JWL/YHgYtKBOPt9fNLloRjG2 BQ1fKhu/PW962Ztl+q2igJMdonOr4zwd2O7G80r+xrZEc+o/Aq4QQgqxKP/VkNoD ffzWwj+vpeW/2OtO9/DORvNdyS5Q47U9NAlai/dF5m1wrS/ySjLYMA== =kTSh -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 20 11:33:55 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703741295E7; Thu, 20 Oct 2016 11:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC03YK0h3djr; Thu, 20 Oct 2016 11:33:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2759F1294D4; Thu, 20 Oct 2016 11:33:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D3A05203AD; Thu, 20 Oct 2016 14:48:32 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 16073639BA; Thu, 20 Oct 2016 14:33:50 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, netconf@ietf.org In-Reply-To: <83877198-8FCF-4AFA-9B75-3200683ADE0B@juniper.net> References: <83877198-8FCF-4AFA-9B75-3200683ADE0B@juniper.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Kent Watsen Subject: Re: [Anima] Regarding MCR's email from 2014 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 18:33:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I include Kent's email at the bottom, in complete form, but I'll reply inli= ne to a copy up here. This is fundamentally about the format and requirements for the ownership voucher. > This is the ownership-voucher idea, but with the following distinctio= ns: > 1) uses X.509 certs > - this is compelling, as using an existing standard with lots of > available tooling sounds like a win. Yes, when I thought hard about the problem, I realized that while they were not attestations as to identity (which a certificate usually is), that they were attestations as to ownership, and then I realized that it was identical to the SIDR work that binds ISPs to BGP4-ASN and IP address range= s. So, in: https://datatracker.ietf.org/doc/draft-richardson-anima-idevid-cert/ I blantantly stole from RFC3779, even forgetting to delete some of the terminology.. > 2) uses a delegation model > - that is, each owner generates a sub-cert when selling some of their > stock. This I have mixed feelings about. On one hand it seems > natural/intuitive, and yet it does also mean that the > delegates have to 1) setup PKI and 2) be trustworthy. I agree that it's a serious challenge to get things setup! 1) My comments are that we can skip many layers in the hierarchy depending = upon the value and cluefulness of the layers. A MASA, provided by the end-customer with a PSK from a QR code, can retrieve the end-certificate from the vendor directly. It's basically a form of PSK authenticated ES= T. 2) For higher value items (like routers from big manufacturers), I suspect that this system would actually be simpler than the nonsense I have gone through trying to obtain firmware... At the least, it would filter out clueless intermediaries that simply cost everyone time and money. > 3) this solution seems geared for consumer-oriented gear, stuff one > might get a Best Buy. Well, is this because my example involved Road Runners and Coyotes, and Cadabra was the original name for Amazon, I learnt from Wikipedia. I don't think that it's a failure of such a system if it can be made to work at the scale of retail. I'd say it's a major feature. The retail scale is both massive (Best Buy moves a lot of devices), and miniscule (people on= ly buy one or two devices/year at present). At the personal level, the question becomes: is there actually *any* infrastructure we can depend upon? At the retail level, the question is the opposite: if there are any human interactions required, it's a fail. > 1) only the manufacturer can sign the vouchers > - no one else needs to setup signing infrastructure > - manufacturer can ensure a voucher is only created once per device > - manufacturer MAY be able to reassigned a voucher, but this might > entail needing to maintain something like a voucher-revocation-list > (VRL?), which would create further dependencies on clocks (ugh!) One model, where you stop here: is a bearer token. I think that this model is entirely doable, and makes sense for devices of a certain price/point. But, it might be that this has significant externalities which society would not want, such as DDoS if the devices can be trojaned and then new vouchers affixed. > 2) at some point, the device is sold to an entity that wants to take > ownership > of the device. > - this entity MUST have (within my soln.) previously obtained an owner > certificate from the manufacturer. > - this entity submits a "voucher signing request" (VSR?), signed by i= ts > private > key, to the manufacturer, along with its previously-signed owner > certificate, So, this is my model with a QR code. > - Instead of submitting its owner certificate, the entity might inste= ad > log into > the interface, from which the manufacturer could lookup the same info= as > in the owner certificate... Kent Watsen wrote: > Here=E2=80=99s the URL to the MCR=E2=80=99s email: > https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU= 9s5yqfRm0n00 > This is the ownership-voucher idea, but with the following distinctio= ns: > 1) uses X.509 certs > - this is compelling, as using an existing standard with lots of > available tooling sounds like a win. > 2) uses a delegation model > - that is, each owner generates a sub-cert when selling some of their= stock. > This I have mixed > feelings about. On one hand it seems natural/intuitive, and yet it do= es also > mean that the > delegates have to 1) setup PKI and 2) be trustworthy. > 3) this solution seems geared for consumer-oriented gear, stuff one m= ight get > a Best Buy. > I haven=E2=80=99t put much thought to a consumer-oriented solution, b= ut maybe > something like this would work: > 1) only the manufacturer can sign the vouchers > - no one else needs to setup signing infrastructure > - manufacturer can ensure a voucher is only created once per device > - manufacturer MAY be able to reassigned a voucher, but this might > entail needing to maintain something like a voucher-revocation-list > (VRL?), which would create further dependencies on clocks (ugh!) > 2) at some point, the device is sold to an entity that wants to take > ownership > of the device. > - this entity MUST have (within my soln.) previously obtained an owner > certificate from the manufacturer. > - this entity submits a =E2=80=9Cvoucher signing request=E2=80=9D (VS= R?), signed by its > private > key, to the manufacturer, along with its previously-signed owner cert= ificate, > - Instead of submitting its owner certificate, the entity might inste= ad log > into > the interface, from which the manufacturer could lookup the same info= as > in the owner certificate... > - The VSR is essentially just a list of device unique-ids and, for ea= ch, some > =E2=80=9Cproof of ownership=E2=80=9D. > - Proof of ownership could take on different flavors, but when owners= hip > can only be taken once, a simple code inside the packaging might suff= ice. > 3) the above assumes physical possession of the device at the time th= e VSR is > submitted, but that is not always desirable. For instance, the owner = may > have instead placed an order for devices to be dropped-shipped to some > specific locations. > - In this case, the owner would like to get the vouchers as soon as t= he > devices > are shipped, and before the boxes are opened, so that they can stage = the > network in preparation for the devices being powered on. > - In my view, this gets into a high-touch scenario where it is approp= riate > for > the manufacturer to proactively issue the vouchers. That is, instead = of > receiving a VSR, the manufacturer receives an *order*, which it can a= gain > correlate to the appropriate owner certificate. > - this is in essence what is documented in the current zerotouch draf= t. > What do you think? - especially regarding (2) above, as that is the n= ew > part... > Kent =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAkOC4CLcPvd0N1lAQLWcQf/ZIzTbsxRBkv4BPSBPe6U8QDy1m0o1LK6 1vESBjpkXM3KKNuNTBZT4xr0AvVFTlAmzKe+nlql/KoMLbL+43Ds3WoHZSD/2rNU +tiNMjwSwzpNcxWSYZhuhGkTy/dEMOHr08fVp9VJQ3DuVHFgl9B2ZnkGw5Qc9NbE xJhA4fbNRZxh2W2Lcj1y9yiNqwo1RtY6VkTxm6avhah0Jf3/IT2DcQO5p2v5qyPu 2gI1UDnUHkc9bCrnwNcGDi7bYB9nQv3kVKQaEr6161pAxRNe0kbAkQ1IA/FWHqhb CMUoRr9TsAKdKMM5vyFjPgq/wugEMRvoZmCXg8MIftVrSPPNKLNcxw== =yZlj -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 20 12:10:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC0C1294FE for ; Thu, 20 Oct 2016 12:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhmPrEAV8i8P for ; Thu, 20 Oct 2016 12:10:31 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0047B129550 for ; Thu, 20 Oct 2016 12:10:29 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id 128so42173745pfz.0 for ; Thu, 20 Oct 2016 12:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZFBsnn84NCIitJ+t94/KMtpiIXpvb/tv9ZDEHT/Bdew=; b=uTnSjTYqGWPISfjrFd3NURuAgt6+3auhJysWUSTXzXUV921QDejTYAM34oabQqcTBD +R1UOPf8hO5P2+yG2pXmoC56tljMxeif0VcVKwRiQ8xYZnUhUrrwitZkwYw5SdoTyLLL 0u2xaxhMpmwYuF/B10PMx8fn1jPmI6P5i0wpmIzyw1ypmLCkCB9q1Qd7ModGKZWyi2yD AuqZOiAZ/8sTSX6iWyJtzG0KwqGkEf70r8gsUJe0482eAWBejpu9K/8wj0wQYZiWpobp yn79pCL4JJgR4sAUq9Zmymvs/xVmoawFqmedNfxjhPlNsdexGUX72SOuhoBvrZNyIt0R Z0XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ZFBsnn84NCIitJ+t94/KMtpiIXpvb/tv9ZDEHT/Bdew=; b=frm3lk0k4wI2DwtqgdnfDTE1EGtRMp78FJaz4shaTJ1fXqG4BNya+t0ALrfsVMFEZ8 iFilE2tPk51WJRag5U3Wm4Q91HH9gWEWTgQ4VQIShTZMA+jHnOJWLuYpdsVpm9DitO3n VhCzXuHCNCHaqq+wogEE2swBo/rF41H8CLGwx3QqU2tusWOyIduv6a3KC5LQoCNejU8/ BSEqL/fzZuCoeciGGqurc+Uq/6tOECSIS+8MNjVShaSesCLGJw424oWiQT2UTKSUMHrN kPu/nPXmFVD975zIN0kIk+CWYNhptanVdPwr42VFwWVNvp11zzvIlK9CoYIDj6gXI0Lz ASoQ== X-Gm-Message-State: AA6/9Rn/bcO8LRttVVGb8zGkfmOty3/WeRlnlbHqkUduZ9KpVAg2dOglaicr5rwwKC/4bw== X-Received: by 10.98.214.89 with SMTP id r86mr3926300pfg.54.1476990629381; Thu, 20 Oct 2016 12:10:29 -0700 (PDT) Received: from [192.168.178.23] (214.218.69.111.dynamic.snap.net.nz. [111.69.218.214]) by smtp.gmail.com with ESMTPSA id y125sm73515420pfg.61.2016.10.20.12.10.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Oct 2016 12:10:28 -0700 (PDT) To: Michael Richardson References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> <7995.1476968217@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <84cc21bc-8a5b-651d-a24c-1b50221229ef@gmail.com> Date: Fri, 21 Oct 2016 08:10:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7995.1476968217@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 19:10:32 -0000 On 21/10/2016 01:56, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> What I was saying was, *IF* I know how to find a machine with an open > >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that > >> I should receive my answer on that connection. > > > A says discover("B") to C, but C doesn't know where B is. So there will > > be no answer, unless C does extra stuff. > > So, C would forward the discover("B"), and then when it gets to B, > it would connect directly to A, and introduce itself? This is obvious now > that you give this example, but not from the document. I might also think > that B would connect to C, and then C would tell A. But it couldn't do that unless it had already discovered C previously, in which case it could simply reply to A with its cached locator for C. > > This clearly fails if A has a LL address only. Yes, but that's why we have discovery relaying. > > >> In the 6tisch case doing multicast is either expensive or unsupported. > >> On the other hand, we can quite easily declare that the 6LBR / > >> DODAG-root (the router at the top of the tree) will have > >> GRASP_LISTEN_PORT open. > > > Yes, you have topology knowledge in that case. > > Do you agree that a discovery("C") sent to C over TCP should be answered > over that TCP connection? Oh yes, and that is what should happen under the covers in any case, if discovery is running over the ACP. However, I'm not convinced that we should document this (unicast discovery). At least not yet. Brian From nobody Thu Oct 20 12:19:23 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AA31296B6 for ; Thu, 20 Oct 2016 12:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwTOteKKIH94 for ; Thu, 20 Oct 2016 12:19:20 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730421296B3 for ; Thu, 20 Oct 2016 12:19:20 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id s8so42046771pfj.2 for ; Thu, 20 Oct 2016 12:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=We7RyCLoTIFCxFzRQgDCp2AENad/EYapkLMhTC5Hwgk=; b=A8MUIR1i1HhFQk7EB/Lo0yb3ZH2gtApArAth7vl4jm8BBzoQBidr7Zdexisuo8KFJv pAk5Stc7AGqXffMYS2myPvEF6j3CUbRsu7po2rZFiVc5ydqRDc7SaunjH1CZdf4GIsis XMP9Fr3/BLgbJKBWol8Z/b4ryApK45ur4TS/FHO4WQg+Om4Xfjl4xdWEAnthPE8d3o8D In+ZpBjk4dufWkzqRp42L7OW5dFV06je33p8dG8MgIccxE5k87UAnZEnfe0fQD8plZwu eyI/AuiUAeC7rQtSX97zxbTjy/WRKndNnzBqh0JutdtbX3YP7PZl3lf3T7OVwu87KGV6 TMWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=We7RyCLoTIFCxFzRQgDCp2AENad/EYapkLMhTC5Hwgk=; b=mXJWi9RZziXF63T1dycDGA4lY8IvGzQhIzbSp1bmhAhpYmOjYpIXAbjA4IbOcfp4ad jvpBYDbHSlWSeUGGEZGeGD3CLhCy9Fmilr6l5+9e4zMMoDk07pqDhauq5SY4uyJlLeo9 M5dTsDobanHRr4EMzR0tmpmjKHqiTy06upvpvcCpjLt3VSYZHScE9nseUtswyo7Ng+lW IVTW/ZBD70lnzWx+6aEu7Y+g2jsV9UULFvMVIbgvAm45gkwbvbdaEpy+sMk7kPcj8MOi 0XrVwUP/lbAB7ac6loGVSu2K3zC4R1dMcjCDDvxMuWhNM9PNs+FYvHVAS62QY+uHcW4H cz1g== X-Gm-Message-State: AA6/9RnpoMDYnGHEIcTn8GCyXuVOWNeml8sv2AzWNXwJY51YvNwKxn1eB1Cz/S8gX2VwCA== X-Received: by 10.98.64.140 with SMTP id f12mr3976963pfd.45.1476991160072; Thu, 20 Oct 2016 12:19:20 -0700 (PDT) Received: from [192.168.178.23] (214.218.69.111.dynamic.snap.net.nz. [111.69.218.214]) by smtp.gmail.com with ESMTPSA id b83sm73555786pfl.41.2016.10.20.12.19.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Oct 2016 12:19:19 -0700 (PDT) To: Michael Richardson References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> <1693.1476907434@obiwan.sandelman.ca> <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> <19660.1476928902@obiwan.sandelman.ca> <9115.1476968523@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6c282690-b8cc-0876-71da-85aeb2f49d6d@gmail.com> Date: Fri, 21 Oct 2016 08:19:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9115.1476968523@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 19:19:22 -0000 On 21/10/2016 02:02, Michael Richardson wrote: > > > Brian E Carpenter wrote: > > Oops, there was a prettifying bug in the previous version... > > ... > > > OK, so now I'll make one with multiple steps [pause while I run my > > example generator and prettify the results] > > 1> A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] > 2> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] > 3> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 294.75]]] > 4> B to A: [M_WAIT, 11146801, 20899] > 5> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 84.0]]] > 6> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 235.8]]] > 7> B to A: [M_END, 11146801, [O_DECLINE, 'Insufficient funds']] > > Lines 2 and 5 look identical to me. Yes, except that B increased its offer from $56 to $84. > As do lines 3 and 6. Yes, except that A reduced its request from $294 to $235 > > > I use random numbers to generate the test cases. That was a nice one, it > > shows B telling A to wait and it shows a failed negotiation. But since > > A and B both know who they are, the fact that the session-id is identical > > isn't a problem. > > Does it work only because line 4 precedes line 5? Well, that is B telling A "hang on for 20.9 seconds", so A will extend its timeout on the current negotiation step. It's an optional message. My test rig decides at random when to insert it. There's a state machine at each end which is specific for this particular objective. I'm a little confused about what's confusing you. (Maybe the Appendix of examples needs explanatory text?) Brian From nobody Fri Oct 21 16:28:32 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FE6129992; Fri, 21 Oct 2016 16:21:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208258.28214.15457104560051755913.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:22 -0700 Archived-At: Cc: anima@ietf.org, terry.manderson@icann.org Subject: [Anima] anima - Requested sessions have been scheduled for IETF 97 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:26 -0000 Dear Sheng Jiang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. anima Session 1 (2:00:00) Friday, Morning Session I 0930-1130 Room Name: Park Ballroom 2 size: 125 --------------------------------------------- anima Session 2 (1:30:00) Wednesday, Morning Session I 0930-1100 Room Name: Grand Ballroom 3 size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: homenet netconf dhc 6tisch nmlrg nmrg Second Priority: 6man softwire roll 6lo supa v6ops Third Priority: cfrg saag intarea opsarea Special Requests: Please arrange the first session on Monday/Tuesday and the second session on Thursday. So the WG participatants could work and make progress between the two sessions. --------------------------------------------------------- From nobody Sat Oct 22 12:38:00 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1B3129682 for ; Sat, 22 Oct 2016 12:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N76Jx3pBFSGq for ; Sat, 22 Oct 2016 12:37:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCDC12967C for ; Sat, 22 Oct 2016 12:37:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0A56C203B9; Sat, 22 Oct 2016 15:52:46 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 522F0639BA; Sat, 22 Oct 2016 15:37:56 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <84cc21bc-8a5b-651d-a24c-1b50221229ef@gmail.com> References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> <7995.1476968217@obiwan.sandelman.ca> <84cc21bc-8a5b-651d-a24c-1b50221229ef@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 19:37:59 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > On 21/10/2016 01:56, Michael Richardson wrote: >> >> Brian E Carpenter wrote: >> >> What I was saying was, *IF* I know how to find a machine with an open >> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that >> >> I should receive my answer on that connection. >> >> > A says discover("B") to C, but C doesn't know where B is. So there will >> > be no answer, unless C does extra stuff. >> >> So, C would forward the discover("B"), and then when it gets to B, >> it would connect directly to A, and introduce itself? This is obvious now >> that you give this example, but not from the document. I might also think >> that B would connect to C, and then C would tell A. > But it couldn't do that unless it had already discovered C previously, in which > case it could simply reply to A with its cached locator for C. >> This clearly fails if A has a LL address only. > Yes, but that's why we have discovery relaying. Still, I'm more confused now. When A has a LL only, we would have to have, not only discovery relaying, but also response forwarding. So does B reply to C (to be relayed to A), or is it a fail as B tries to connect to A's LL address, and does not connect? >> >> In the 6tisch case doing multicast is either expensive or unsupported. >> >> On the other hand, we can quite easily declare that the 6LBR / >> >> DODAG-root (the router at the top of the tree) will have >> >> GRASP_LISTEN_PORT open. >> >> > Yes, you have topology knowledge in that case. >> >> Do you agree that a discovery("C") sent to C over TCP should be answered >> over that TCP connection? > Oh yes, and that is what should happen under the covers in any case, if discovery > is running over the ACP. > However, I'm not convinced that we should document this (unicast discovery). > At least not yet. When? I feel that this is important behaviour that needs to be defined for the GRASP core system. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWAvAEYCLcPvd0N1lAQIxhQgAtf36tmFwSI5b6LEPNegji9eIwGZNrmVE Op6mFxmRyfSAlVg3HYK4UcZK8fCabgxSi3xOUuaD3GbStE2oGSVTIPh6+OhHqOQd KbNVPhyUf44wJQMU/Fbe1Lqs51fvnRXbOgc3e79GV8T6G4hhpRpEBcd2EeUN4UnU wFGHhu3hH/gbL9dP9xHM3C4e8yKPbLntce/Xlu8X3gR4/V8aTMgT60Y5/A9rY8bt N/q+gcchgaRq7bickJkeGEJbLJqvT5XJ9DpF69ujPI4QCrzkw0z8eDhgnRWxbpbt K07JhcioJgQBVKNG+C7qNqWxc0JY38oacXl44wPc9EBhg8qNvMcl8A== =ttuK -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 22 14:05:33 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700D61293EE for ; Sat, 22 Oct 2016 14:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERYFl367n9vj for ; Sat, 22 Oct 2016 14:05:31 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEBEA12950F for ; Sat, 22 Oct 2016 14:05:30 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id r16so75852324pfg.1 for ; Sat, 22 Oct 2016 14:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lopIOeFNT/02aPU/vqw+LfI2KlrDXo9E5Ats/8xLtK4=; b=ZlyQns6qdcpZDa+ZtoEkh8yqteKSXrfz6RvN4ShYnnur8rZgkjP1/LhuFgt71ggEFq 6OfXJv5Yp8Wl5BygK77bhj3CnUyO06qr6NhDwMz9vMIjcVf6EnRcMkXHlJcBbCJvgm9P ipvYVIKGF7Um0qJh9Aj77ECrKphCSn+4L7LN6jM44daf8nzP/n0g5pmljEwMYfEldqyF if7QaSA9ZJpMh46sYl/8Y7rdSWdvJC7ODtOXMeTOG4L7gt1mP5BevrCUvT0Rn2HC8Q8S Xp64CfGDVKtouXngCkt6zGgMYUXGKery+aPqXkdJvB//HJZ2ynUjZnTQwidjmpsbxM+H p3xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=lopIOeFNT/02aPU/vqw+LfI2KlrDXo9E5Ats/8xLtK4=; b=FCTUqgZssUBgXyaiJTLs56HLRKhTeCqadwqaAK9CLI6a4SbvtESiHCXRbIIrWcrRZl nhXUbNCjNGGj6L12wwFolUKJkLcrzkPX4b9q8Wd1rtYBfq3B/XIC5U1drijStVjNlcWK LEIiR7kagC12mB3lt8+8f+0ryOiPyjLlEUlM933tGrkPD34v8mg/oqpulVsHpXPI9uxj 5MDA0maI/AEl46q/UNUnxbNdSXoEy82SYe8+GtC0MmNXoUI8zxSDImGHeje9HYC31d04 Ds4WXTJcqQUgbo4pPS60AvtNK25JImcvz5GKxRJrCci0n2Q3pDeDGNnc831HQxNBV2I9 4dLQ== X-Gm-Message-State: ABUngvfbymrafMVBRq45EFwLGTMBn3azbYqGuBRUCNquDX24GOQnMgSJ+Fhbg9wpoNNqzA== X-Received: by 10.99.94.196 with SMTP id s187mr11749054pgb.107.1477170330390; Sat, 22 Oct 2016 14:05:30 -0700 (PDT) Received: from [192.168.178.23] ([118.148.125.128]) by smtp.gmail.com with ESMTPSA id y2sm14276537pfk.54.2016.10.22.14.05.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Oct 2016 14:05:29 -0700 (PDT) To: Michael Richardson References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> <7995.1476968217@obiwan.sandelman.ca> <84cc21bc-8a5b-651d-a24c-1b50221229ef@gmail.com> <8498.1477165076@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1ca5cbca-e932-4c95-1a78-936a5eb95d7a@gmail.com> Date: Sun, 23 Oct 2016 10:05:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8498.1477165076@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 21:05:32 -0000 On 23/10/2016 08:37, Michael Richardson wrote: > > Brian E Carpenter wrote: > > On 21/10/2016 01:56, Michael Richardson wrote: > >> > >> Brian E Carpenter wrote: > >> >> What I was saying was, *IF* I know how to find a machine with an open > >> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that > >> >> I should receive my answer on that connection. > >> > >> > A says discover("B") to C, but C doesn't know where B is. So there will > >> > be no answer, unless C does extra stuff. > >> > >> So, C would forward the discover("B"), and then when it gets to B, > >> it would connect directly to A, and introduce itself? This is obvious now > >> that you give this example, but not from the document. I might also think > >> that B would connect to C, and then C would tell A. > > > But it couldn't do that unless it had already discovered C previously, in which > > case it could simply reply to A with its cached locator for C. > > >> This clearly fails if A has a LL address only. > > > Yes, but that's why we have discovery relaying. > > Still, I'm more confused now. > > When A has a LL only, we would have to have, not only discovery relaying, but > also response forwarding. Yes. And if that isn't clear from the text, we (authors) have blown it. Let me look... ... https://tools.ietf.org/html/draft-ietf-anima-grasp-07#page-20 "The discovery results received by the relaying device MUST in turn be sent as a Discovery Response message to the Discovery message that caused the relay action." (which is intentionally recursive, but safe because of the loop suppression rules.) > So does B reply to C (to be relayed to A), or is > it a fail as B tries to connect to A's LL address, and does not connect? > > > >> >> In the 6tisch case doing multicast is either expensive or unsupported. > >> >> On the other hand, we can quite easily declare that the 6LBR / > >> >> DODAG-root (the router at the top of the tree) will have > >> >> GRASP_LISTEN_PORT open. > >> > >> > Yes, you have topology knowledge in that case. > >> > >> Do you agree that a discovery("C") sent to C over TCP should be answered > >> over that TCP connection? > > > Oh yes, and that is what should happen under the covers in any case, if discovery > > is running over the ACP. > > > However, I'm not convinced that we should document this (unicast discovery). > > At least not yet. > > When? I feel that this is important behaviour that needs to be defined for > the GRASP core system. Well, I don't really know when I would use it, but I have no problem with adding that an initiator MAY send unicast discovery and the recipient will respond accordingly (i.e. treat it just the same as a multicast discovery). Brian From nobody Sun Oct 23 13:17:14 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2110D129479 for ; Sun, 23 Oct 2016 13:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4NBhNsf2Af7 for ; Sun, 23 Oct 2016 13:17:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7201E1293FD for ; Sun, 23 Oct 2016 13:17:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CAEC4203AF; Sun, 23 Oct 2016 16:32:02 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 91A82639BA; Sun, 23 Oct 2016 16:17:09 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <6c282690-b8cc-0876-71da-85aeb2f49d6d@gmail.com> References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> <1693.1476907434@obiwan.sandelman.ca> <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> <19660.1476928902@obiwan.sandelman.ca> <9115.1476968523@obiwan.sandelman.ca> <6c282690-b8cc-0876-71da-85aeb2f49d6d@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 20:17:13 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > On 21/10/2016 02:02, Michael Richardson wrote: >> >> >> Brian E Carpenter wrote: >> > Oops, there was a prettifying bug in the previous version... >> >> ... >> >> > OK, so now I'll make one with multiple steps [pause while I run my >> > example generator and prettify the results] 1> A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] 2> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] 3> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 294.75]]] 4> B to A: [M_WAIT, 11146801, 20899] 5> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 84.0]]] 6> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 235.8]]] 7> B to A: [M_END, 11146801, [O_DECLINE, 'Insufficient funds']] >> Lines 2 and 5 look identical to me. > Yes, except that B increased its offer from $56 to $84. >> As do lines 3 and 6. > Yes, except that A reduced its request from $294 to $235 Ah, so this is one negotiation then? I thought the M_WAIT was the end of a negotiation and 5> was a second thing, but of course, that makes no sense, it would start with M_REQ_NEG. > There's a state machine at each end which is specific for this particular > objective. I'm a little confused about what's confusing you. (Maybe the > Appendix of examples needs explanatory text?) Let me add some messages and interleave a second negotiation n2: n1 1> A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] n2 11> B to A: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 392]]] Yup, both ends picked the same session-id because cosmic ray hit, and started negotiation. n1 2> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] n2 21> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 55.0]]] n1 3> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 294.75]]] n1 4> B to A: [M_WAIT, 11146801, 20899] n2 31> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 292]]] .. So, is message 31 (which looks the same as (5) above part of n1 or n2? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWA0aw4CLcPvd0N1lAQLHbAf/eBM+Fu/y9/0/o//pYn1bY09msgQMGW6R 1043IUHWTzQzpBUsT5zUh/Fme4/YgKwVnB2lBRZh2BiNRAaS+A7UfVNhSgQVgEcX BHBVPlR9arEar7vXLq4LYZN1A+Y31baO+Y2jw6/dp54MWftW0lsV+xT3yq7gyWOH nMcEP0/o3Y/6i3HT0Le1Lo6h6uyh0HCJ7ThfwrhgnzNOJuvlrcx1lKRtVpnkJops gxaSTmK3Mn5E+d9nfIM5lW4+bE6u2EYVAJThfVg6zPpWsLZ/YSwiaPRw6xeyiXk1 RkFQw3/Ysfz+QT2r1vY3PIGxLZxaUr+BDR3zaO3AX5gJN4JlP/2QvA== =oNat -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 23 20:28:12 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E64A1294C3 for ; Sun, 23 Oct 2016 20:28:11 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdP5Qy9JBTsq for ; Sun, 23 Oct 2016 20:28:09 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF43612940D for ; Sun, 23 Oct 2016 20:28:09 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id e6so89771110pfk.3 for ; Sun, 23 Oct 2016 20:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rdxPx72uuVM7mD+M7FWrOPR6paPfyEkurk1QwjuYtqo=; b=YJzQJW0c0tYdTKHCw6dMSQ6oIUvAiadNyDAUuxNFRvH9EYRRCt4jPKs1g2sm1Qr2lQ Cottnc2EH5WnOK3PonVfqZoIeIlSJg3O/7U8yLBzfjvZioR0fWLUnofLqLebLAK6eYL/ IC/eyArqYL74AILQTqGz5DULKCJBhOKm2d5RdEPFO+0pUfa+pJqbQTiT9TQyFwveXQc5 RONiqLvK/Qn/ee5D7Yrh+HYHJ+1Kk+oTLc8OuOuI6EJkJJkqm9YnvY1SDxOjE5E6YrTi 6USnyfrqbg0I1gTvtVgdyM6VqAWrONx842hY7+BqkHiEu0ecjT0M5JGWVwtwMvnv6Ezb /gGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=rdxPx72uuVM7mD+M7FWrOPR6paPfyEkurk1QwjuYtqo=; b=NgYqA3AgOl7/VBbZ+QwkYg9cLW/AV/HTxyOUZSAXJbwF8QMxjpayrsz48h9z8S+Qlb tZI5FdaOb5BVsyLpc+2bieifn7nhNvYRjpZ5CsnyGRm5HVq8E13AjpGXKOOo4d7Drv43 BnkrfgYKzPgSwsktBS35KTtDmPLot3frIY75S4KflZTX2purWNoV47mtO9uW1dIzN/uX xAG7fe2/1bdclslY74LPc1TICdu72zANN2DwhQi5VC/w0NieGtZYfrngej+n4Sx2bLZV 7z1sdjlSQ+sUmF+w11ng22vqLcJfSN/bDM9mjzrH1scZtl6Hd1csvxWNKPOZKEu6JzyF jXrA== X-Gm-Message-State: ABUngvePuat014q7tbd0zZKOmp/ZZbRTOHrs5Ac21RWrqtQE5tUaaeHXVoiG9V6I9+y2tQ== X-Received: by 10.99.97.15 with SMTP id v15mr20503063pgb.10.1477279688696; Sun, 23 Oct 2016 20:28:08 -0700 (PDT) Received: from ?IPv6:2406:e007:652c:1:28cc:dc4c:9703:6781? ([2406:e007:652c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u1sm10196381pfb.96.2016.10.23.20.28.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Oct 2016 20:28:08 -0700 (PDT) To: Michael Richardson References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> <1693.1476907434@obiwan.sandelman.ca> <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> <19660.1476928902@obiwan.sandelman.ca> <9115.1476968523@obiwan.sandelman.ca> <6c282690-b8cc-0876-71da-85aeb2f49d6d@gmail.com> <20000.1477253829@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <668e819c-5f72-156a-6f4d-0fcdc0134a4e@gmail.com> Date: Mon, 24 Oct 2016 16:28:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20000.1477253829@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 03:28:11 -0000 On 24/10/2016 09:17, Michael Richardson wrote: > > Brian E Carpenter wrote: > > On 21/10/2016 02:02, Michael Richardson wrote: > >> > >> > >> Brian E Carpenter wrote: > >> > Oops, there was a prettifying bug in the previous version... > >> > >> ... > >> > >> > OK, so now I'll make one with multiple steps [pause while I run my > >> > example generator and prettify the results] > > 1> A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] > 2> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] > 3> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 294.75]]] > 4> B to A: [M_WAIT, 11146801, 20899] > 5> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 84.0]]] > 6> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 235.8]]] > 7> B to A: [M_END, 11146801, [O_DECLINE, 'Insufficient funds']] > > >> Lines 2 and 5 look identical to me. > > > Yes, except that B increased its offer from $56 to $84. > > >> As do lines 3 and 6. > > > Yes, except that A reduced its request from $294 to $235 > > Ah, so this is one negotiation then? > I thought the M_WAIT was the end of a negotiation and 5> was a second thing, > but of course, that makes no sense, it would start with M_REQ_NEG. > > > There's a state machine at each end which is specific for this particular > > objective. I'm a little confused about what's confusing you. (Maybe the > > Appendix of examples needs explanatory text?) > > Let me add some messages and interleave a second negotiation n2: > > n1 1> A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] > n2 11> B to A: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 392]]] > > Yup, both ends picked the same session-id because cosmic ray hit, and started > negotiation. > > n1 2> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] > n2 21> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 55.0]]] > > n1 3> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 294.75]]] > n1 4> B to A: [M_WAIT, 11146801, 20899] > n2 31> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 292]]] > > .. > > So, is message 31 (which looks the same as (5) above part of n1 or n2? Two answers: 1. n1 and n2 would be two different TCP sessions, and two different threads at each end. 2. In any case, the session_ID cache (of all currently valid IDs, should be implemented with 2-tuples* like {ID, initiator}.) I coded it with 0 meaning "me", so {11146801,0} would be a session that I initiated, and {11146801,2406:e007:652c:1:660a:5169:6c66:4669} would be one that the other guy initiated. So if you did build a single-threaded implementation, that would be enough to demultiplex the sessions. Brian *in practice I have more in the session cache. Gory details: class _session_instance: """Internal use only""" def __init__(self, id_value, id_active, id_source): self.id_value = id_value #Integer self.id_active = id_active #True if active self.id_source = id_source #Source locator of ID if needed self.id_dq = None #Queue if discovering self.id_sock = None #Socket if negotiating self.id_relayed = False #True if has been relayed # Session_ID cache contains # - all currently active Session_IDs # - foreign source address if any # - status for each one (in use or inactive) # - as memory permits, all previously seen Session_IDs (status inactive) to avoid reuse From nobody Mon Oct 24 16:34:47 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A951294E3 for ; Mon, 24 Oct 2016 16:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bISKt8E5j5zV for ; Mon, 24 Oct 2016 16:34:45 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318DC1294A4 for ; Mon, 24 Oct 2016 16:34:45 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id r16so106886525pfg.1 for ; Mon, 24 Oct 2016 16:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hkgaZ898l66ZFdTucpplpxZBd1h6Mqc3cThiY9bBtJc=; b=txfiaNXMEGZbQsTUDmD094MnPm0hEXxzQTR4nKljdgsONgUDNer4MWdTG2xfb9uzzP EdpwAMsqLmXu7anFYQcf/fc9b2H4obNmkfWT73a0OkmbfaP//IW+ZOe9x6y+9GMgKiIs o8lMnthANHFWa726SyePgO73zgUlYVsRHhQrip22SJalVx0DnwKwARdTjKcPX2P7G7Dz F8ZOEKkSg8BjeX+XPWDlWYZLKrAV840TChdxjFsAF2zDr7vZfoRma+iSa5t0dVZ2X9Tm VOLT4RS5bdkuXYi75iGh3ftqA2L3SfGnelQuoogHywjB5mFbpZqt8Bv3LHLClGsXCtZu 6RqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hkgaZ898l66ZFdTucpplpxZBd1h6Mqc3cThiY9bBtJc=; b=SDMiktbfIyduMM1JPpR2zLjZgqv2cCsYv0Vcs0pVLBQADAVHJyDix+e3ZkjDRCRLO8 Mr49RP/vWIvZBMrnzfWRrpdlte19/3Azm39fuDHwM5Wq2A72MKZEwSm6ozcFXs791som V3D8/WxIsRxHs8G1vIgYscTo8C24Zybs1+AdBkS9FMqWz1UjBSrae664wF7L4DwF1s27 Brx8MhUqv8KknABoTm1k46ZiY0Y0N31JVQvm3Y7zBHLgHxEbVry3DH4Zaqk/ocJqkSf8 VjIEQq3/tMQqyV4i0rRz57Z6deE+6CC1gtyFkWkbvNZde3b57aRXQNMCaGNjMyuChcyZ qphg== X-Gm-Message-State: ABUngvcg5KdEdhaYR3KkzFFbXgKv03QDl8X1gL6SUalnCQQbCnBWjQC9Didl/JnWmzv1Lw== X-Received: by 10.98.142.26 with SMTP id k26mr33437896pfe.26.1477352084636; Mon, 24 Oct 2016 16:34:44 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id bu8sm3884374pab.46.2016.10.24.16.34.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 16:34:44 -0700 (PDT) To: Anima WG References: <0f3ecf86-ead6-486b-c5a6-403bbf1e4689@gmail.com> <4112.1476908026@obiwan.sandelman.ca> <3b8a49d2-cfc5-199b-2650-e35abfffbd54@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 25 Oct 2016 12:34:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3b8a49d2-cfc5-199b-2650-e35abfffbd54@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson Subject: Re: [Anima] GRASP issue 58: Maximum message size? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 23:34:47 -0000 I'm going to take silence as assent: i.e. we will specify a default maximum message size of 2048, and leave the question of how it can be exceeded to be a negotiable property of individual objectives. Regards Brian On 20/10/2016 15:34, Brian E Carpenter wrote: > On one point: > >> *could* we make the maximum objective (assuming intents are directly in an >> objective) size itself be a synchronizable parameter? > > We could even make it negotiable, since GRASP supports negotiation :-). > But I think we'd better start off with a hard limit so that we don't > encounter 10GB requirements during initialization. > > I could imagine adding a max_size parameter to the API, too, so that > a given ASA could accept larger messages for a given objective. So maybe > the best thing for now is to define a *default* maximum size in the spec. > > Regards > Brian > > On 20/10/2016 09:13, Michael Richardson wrote: >> Brian E Carpenter wrote: >> > BC: Me too. I coded my prototype with recvfrom limited to 2048 bytes, >> > but we probably need to specify something. On the other hand, Michael B >> > wants to send infinitely long Intents, I think. >> >> libcbor nicely responds to an incomplete message with CBOR_ERR_NOTENOUGHDATA. >> This lets you grow the data structure for the situation where Intents are >> large. >> https://libcbor.readthedocs.io/en/latest/api/decoding.html#associated-data-structures >> >> It would be better if the initial parts of the structure could be examined >> even in the error case, and if it was the case that one didn't want to deal >> with the rest, one could be told how much more to discard. Or, in some >> cases, one wouldn't know (streaming arrays, etc), and perhaps the answer is >> drop the TCP connection. >> I think that this could be added to libraries. >> >> What I guess I'm concerned about is a CBOR definite array structure that says >> that there are 10 Billion items to be expected, the library goes and >> allocates that much ram (10G), and the system fails or goes into swap hell. >> No need to actually transmit the 10G of data. >> >> libcbor can be configured to use a custom allocator rather than malloc(3), >> and this is likely the correct answer: to provide some reasonable limit on >> amount of memory for decoding... which comes back to how big will the Intents >> be. >> kilobytes? probably. >> megabytes? maybe one or two Mbytes. >> gigabytes? most certainly not. >> >> *could* we make the maximum objective (assuming intents are directly in an >> objective) size itself be a synchronizable parameter? >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> From nobody Mon Oct 24 16:37:05 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF07129A14 for ; Mon, 24 Oct 2016 16:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMCeSQLdWFEJ for ; Mon, 24 Oct 2016 16:37:03 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846EB1294E8 for ; Mon, 24 Oct 2016 16:37:03 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id r16so106916738pfg.1 for ; Mon, 24 Oct 2016 16:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=/tNNUplyMzfhELppTMUzCxV7L5hQ16zudrWlLs8/BAM=; b=yrb23B/YBm+4JaBDq+h4Ru26gPWriQurnCJS3/Nx0dThUAzZvIZrAXeRLJJVenuXP8 Ns+1bTMzcO6NznYegxwtWszhzO75vEXAyGze0gVGfu6ylghH7hzt9Hkm3XH6L2JiFkkc wdVZAwLiVze5xdL331No7sksxLqNYd9khJk4rFOzcMrUr5LGDWGNjnto+e/78Eem7TIt aYe0HiGe/5sw0YhWQgR49sONKy6Ftaaj5dV1x8z6yiPv6n0U6TlcM+ApawoLh7c2y/uf 9o7dBGk6RAY+u9QaAY/HrzUF65EfUwL3mFYX9CJldvxjXyZy5tQDf3rW5/iwhokxH1f1 6gKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=/tNNUplyMzfhELppTMUzCxV7L5hQ16zudrWlLs8/BAM=; b=iBpJLDfjZwwR/1T/B3UxwCm1iYNb6MNazQ+q6jccxkLzsteHEMmNTWGxiYVTjsRjbY IOd4YcDscgh4xypKgUGyymGHPu59vMp6fgrdbSrCuDDhPA5lSGn16aYUfhcotJsHy+sA GWGHn78FL0N2vF8i6cM0aoeInzg70WPvsMT4VUCqEDMlZ+o21jt8vWrcU1xpEQ5dMSwc +fg8xtw87oqM5Iff697bZpT+KklNqNhpO+VzIa6z+tR8rtVebKLNeRxqAMfqfJ7Vz+2J FI6YLa0aD/kSAEH5SCWf7iUQzZPwDZFKbB8IMOrN8dLtlnYeXpWjWl7Y1umDj0VxPy3d Oetg== X-Gm-Message-State: ABUngveTysa4+K34Q031cCvI94U3I8u4/ba7CuWuhyTJmmSIbOO5Oc7PEtauVVcIXeji4A== X-Received: by 10.99.184.25 with SMTP id p25mr27798725pge.120.1477352222925; Mon, 24 Oct 2016 16:37:02 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id ak3sm27910553pad.19.2016.10.24.16.37.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 16:37:02 -0700 (PDT) To: "Michael Behringer (mbehring)" , Anima WG References: <618610f7ccaf4dea93bb9bea65908f13@XCH-RCD-006.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2934ca3a-f5c5-6173-1415-4489cc0551d1@gmail.com> Date: Tue, 25 Oct 2016 12:37:00 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <618610f7ccaf4dea93bb9bea65908f13@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP issue 57: Add M_INVALID message? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 23:37:05 -0000 And I'm going to take silence on this one as assent, and add the message to the spec (and test it in the prototype). Regards Brian On 19/10/2016 21:47, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 18 October 2016 22:05 >> To: Anima WG >> Subject: [Anima] GRASP issue 57: Add M_INVALID message? >> >> 57: Add M_INVALID message? >> >> MR: What does one do with an invalid msgtype? Options are: >> 1) ignore (drop msg) >> 2) die: drop TCP connection >> 3) reply with ???-M_INVALID or something. >> >> BC: I'm inclined to add M_INVALID as a MAY, or possibly a SHOULD, but with >> a rule that you MUST NOT reply to M_INVALID with M_INVALID. >> And the reason is indeed that we could use this to discover that a peer >> doesn't understand a new (or obsolete) message or option. > > Agree. > > I think the handling of an invalid message is up to the ASA, so what it actually does depends on the use case. > > Michael > From nobody Mon Oct 24 19:53:43 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D71294DB for ; Mon, 24 Oct 2016 19:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zs8R-xSzNYg for ; Mon, 24 Oct 2016 19:53:40 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F09129400 for ; Mon, 24 Oct 2016 19:53:40 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id r16so109774056pfg.1 for ; Mon, 24 Oct 2016 19:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DJ1qu5ZB7/rtjJtOgDnPHeglDd7lUru9d2gzeLWcDgM=; b=eHksBg2bo++31brNOabyGi6UysghQJprlufKvD4lqT5ZXJtySIDr7wlJ52P1Qrf5bk rB6FoDT+/E+cR33zEGqZliQYVi6LXVZtzhTmkTg25PrkpzuZF1mXJd90NQ8zKtHYu4cc 3lgfBso7jOlOZMZjbynbE7aQj/DDJ0YXsqfZCAKh/zyDFLq4f2dFW2pmeTKvAV0UUhWG DSE+oV3PPloKALanMXJpn4OdocQveziW5fIpnAITRnuKxbjHxzu7rDIk6ryIJIxy5lFQ CgT0g/hO34CTliUW4AWsBHGbwh+0XOWUvyWWtZPQV1ykiVIxZhu0Fo4ERp2Ud4YeU/P9 LNZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DJ1qu5ZB7/rtjJtOgDnPHeglDd7lUru9d2gzeLWcDgM=; b=QeidGlCmjvXXNU3WkRO/cvluV8Jm48nxOCNUwjUsKRnvINF1aI0/IFCasDocR7yfRL gzbRNpXMWqi/ZptQYKmsBC7KAb4PwbnrzXBHXuXhvVxXyH0wSb+qNfZcjRGBVlqNotB1 LbaizZcdQaokm45L7MDifXFhVEE+GBxEG8BdhVaxRO/VnEbsoXg5cvUxETLCEf51vQaI fwJetHfu0ngYCwgwDRXGVoMqdHGhq5y71l7gVB3KzQ+GKmRnd2lbeXIkft2/xXD4mTGe hXoWWGWHYEGjQmymyT/z5o8KPtnN6e2LC7Qrihx3WWPUX1y9MRWAXcA63A1uT4KQSXM7 BwzA== X-Gm-Message-State: ABUngvf3+7Ya5+Q8DMl8GzOqvMlB5JdCyfpn5gQ8nEazOmzmaGbG2LIPaSiDbEoQEM12Hg== X-Received: by 10.99.168.10 with SMTP id o10mr29189854pgf.152.1477364019393; Mon, 24 Oct 2016 19:53:39 -0700 (PDT) Received: from ?IPv6:2406:e007:6593:1:28cc:dc4c:9703:6781? ([2406:e007:6593:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b83sm28357404pfl.41.2016.10.24.19.53.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 19:53:38 -0700 (PDT) To: Michael Richardson References: <3db8ce44-fbfb-37d3-9ffd-8de2c41cb5c2@gmail.com> <1693.1476907434@obiwan.sandelman.ca> <87199ed6-1c66-3dc5-b106-380cbfa89c9f@gmail.com> <19660.1476928902@obiwan.sandelman.ca> <9115.1476968523@obiwan.sandelman.ca> <6c282690-b8cc-0876-71da-85aeb2f49d6d@gmail.com> <20000.1477253829@obiwan.sandelman.ca> <668e819c-5f72-156a-6f4d-0fcdc0134a4e@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8a34ebf3-9efc-6fe7-8739-31bfd15997eb@gmail.com> Date: Tue, 25 Oct 2016 15:53:38 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <668e819c-5f72-156a-6f4d-0fcdc0134a4e@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 56: Change Session-ID to 32 bits? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 02:53:42 -0000 Hi, Walking to the bus stop just now, I think I finally understood Michael's concern. 1. We assume the extremely unlikely case that two GRASP peers A and B choose the same session ID -- let's call it C for 'clash'. This would need to be at about the same time, too, for the ambiguity to matter. 2. We assume that A sends req_negotiate(C,...) to B, and B sends req_negotiate(C,...) to A, at about the same time. Now we have to consider the possible race condition. - If A's req_negotiate reaches B before B has committed to using the ID value C for its own req_negotiate, we are OK: B will find that C is already in use (in its local session cache) and will generate a new value C'. No race condition, no problem. - Similarly in the other direction. - If A's req_negotiate reaches B after B has committed to using the ID value C, B can detect this, because C is already in its local session cache, tagged as locally originated. So it can simply drop the req_negotiate (or send back an M_END[O_DECLINE]). - Similarly in the other direction. In fact, if the race condition arises in one direction, it will automatically arise in the opposite direction too. So both attempted negotiations will fail. That's fine; ASAs need to retry after failure in any case. In any case it's highly unlikely, unless somebody uses a really bad PRNG. Is that correct? If so, it needs to be explained better in the spec. That said, I think it's quite logical to increase the space to 32 bits, since as Michael observed it will be stored as a uint32 anyway, in practice, and the impact on CBOR size is minor. Regards Brian On 24/10/2016 16:28, Brian E Carpenter wrote: > On 24/10/2016 09:17, Michael Richardson wrote: >> >> Brian E Carpenter wrote: >> > On 21/10/2016 02:02, Michael Richardson wrote: >> >> >> >> >> >> Brian E Carpenter wrote: >> >> > Oops, there was a prettifying bug in the previous version... >> >> >> >> ... >> >> >> >> > OK, so now I'll make one with multiple steps [pause while I run my >> >> > example generator and prettify the results] >> >> 1> A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] >> 2> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] >> 3> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 294.75]]] >> 4> B to A: [M_WAIT, 11146801, 20899] >> 5> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 84.0]]] >> 6> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 235.8]]] >> 7> B to A: [M_END, 11146801, [O_DECLINE, 'Insufficient funds']] >> >> >> Lines 2 and 5 look identical to me. >> >> > Yes, except that B increased its offer from $56 to $84. >> >> >> As do lines 3 and 6. >> >> > Yes, except that A reduced its request from $294 to $235 >> >> Ah, so this is one negotiation then? >> I thought the M_WAIT was the end of a negotiation and 5> was a second thing, >> but of course, that makes no sense, it would start with M_REQ_NEG. >> >> > There's a state machine at each end which is specific for this particular >> > objective. I'm a little confused about what's confusing you. (Maybe the >> > Appendix of examples needs explanatory text?) >> >> Let me add some messages and interleave a second negotiation n2: >> >> n1 1> A to B: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 393]]] >> n2 11> B to A: [M_REQ_NEG, 11146801, ['EX2', 1, 6, ['NZD', 392]]] >> >> Yup, both ends picked the same session-id because cosmic ray hit, and started >> negotiation. >> >> n1 2> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 56.0]]] >> n2 21> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 55.0]]] >> >> n1 3> A to B: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 294.75]]] >> n1 4> B to A: [M_WAIT, 11146801, 20899] >> n2 31> B to A: [M_NEGOTIATE, 11146801, ['EX2', 1, 6, ['NZD', 292]]] >> >> .. >> >> So, is message 31 (which looks the same as (5) above part of n1 or n2? > > Two answers: > > 1. n1 and n2 would be two different TCP sessions, and two different threads > at each end. > > 2. In any case, the session_ID cache (of all currently valid IDs, > should be implemented with 2-tuples* like {ID, initiator}.) > I coded it with 0 meaning "me", so {11146801,0} would be a session > that I initiated, and {11146801,2406:e007:652c:1:660a:5169:6c66:4669} > would be one that the other guy initiated. > So if you did build a single-threaded implementation, that would be > enough to demultiplex the sessions. > > Brian > > *in practice I have more in the session cache. Gory details: > > class _session_instance: > """Internal use only""" > def __init__(self, id_value, id_active, id_source): > self.id_value = id_value #Integer > self.id_active = id_active #True if active > self.id_source = id_source #Source locator of ID if needed > self.id_dq = None #Queue if discovering > self.id_sock = None #Socket if negotiating > self.id_relayed = False #True if has been relayed > > # Session_ID cache contains > # - all currently active Session_IDs > # - foreign source address if any > # - status for each one (in use or inactive) > # - as memory permits, all previously seen Session_IDs (status inactive) to avoid reuse > From nobody Tue Oct 25 04:40:17 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4592712940B; Tue, 25 Oct 2016 04:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHDiOFRlnklU; Tue, 25 Oct 2016 04:40:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170E1126B6D; Tue, 25 Oct 2016 04:40:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYZ32269; Tue, 25 Oct 2016 11:40:07 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 25 Oct 2016 12:40:05 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 25 Oct 2016 19:39:52 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 97, Seoul, Korea Thread-Index: AdIutH58Odwhi0GhRUu6/2nVO6atAw== Date: Tue, 25 Oct 2016 11:39:52 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CC293B7@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CC293B7NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.580F4499.003D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f3659480e019492cde7029658ff32827 Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: [Anima] Call for agenda ANIMA @ IETF 97, Seoul, Korea X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 11:40:15 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CC293B7NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all anima, We have requested two sessions of 2 hour + 2 hour for the ANIMA WG meeting = for IETF-97 (Seoul, Korea) and are starting to collect agenda items for the= se sessions. Same with previous IETF meetings, we do not reserve the second= session for non-charter work items. It says the charter work item would ha= ve priority. We will only discuss non-charter work items till we finish cha= rter work items. However, since we are approaching our milestones, some of = our chartered work item may be mature and request less discussion time. So,= hopefully, we could have more time for discussion of non-charter work item= s. As normal, the priority among these non-charter work items would be: the= se that have active discussion in mail list, then these have submitted draf= ts, and topics without drafts. Please send us (anima-chairs at ietf.org) requests for time slot by Novembe= r 3rd, Thursday and include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): Brief description of what issues need discussing and what you hope to accomplish by presenting (please focus on open issues, rather than a status update): More details about the IETF 97, Seoul, Korea can be found at: http://www.ietf.org/meeting/97/index.html Again, presenters and draft authors please invoke active discussions in the= ANIMA list. We have very limited time for each topic in the face-to-face m= eeting. Mail list is a very good place to discuss and reach consensus on te= chnical issues. Best regards, Toerless & Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CC293B7NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all anima,

 

We have requested two sessions of 2 hour + 2 hour for the ANIMA= WG meeting for IETF-97 (Seoul, Korea) and are starting to collect agenda i= tems for these sessions. Same with previous IETF meetings, we do not reserve the second session for non-charter work i= tems. It says the charter work item would have priority. We will only discu= ss non-charter work items till we finish charter work items. However, since= we are approaching our milestones, some of our chartered work item may be mature and request less discussion = time. So, hopefully, we could have more time for discussion of non-charter = work items. As normal, the priority among these non-charter work items woul= d be: these that have active discussion in mail list, then these have submitted drafts, and topics without drafts.=

 

Please send us (anima-chairs at ietf.org) requests for time slot by= November 3rd, Thursday and include:

Name of time slot:

Name of draft(s):

Time requested:

Presenter name(s):

Brief description of what issues need discussing and what you hope = to

accomplish by presenting (please focus on open issues, rather than = a

status update):

 

More details about the IETF 97, Seoul, Korea can be found at:<= /o:p>

http://www.ietf.org/meeting/97/index.html

 

Again, presenters and draft authors please invoke active discussion= s in the ANIMA list. We have very limited time for each topic in the face-t= o-face meeting. Mail list is a very good place to discuss and reach consensus on technical issues.<= /span>

 

Best regards,

 

Toerless & Sheng

 

--_000_5D36713D8A4E7348A7E10DF7437A4B927CC293B7NKGEML515MBXchi_-- From nobody Wed Oct 26 19:14:54 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC63F1296BF for ; Wed, 26 Oct 2016 19:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgPH7i442HeU for ; Wed, 26 Oct 2016 19:14:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA1612995E for ; Wed, 26 Oct 2016 19:14:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTY89715; Thu, 27 Oct 2016 02:14:44 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 27 Oct 2016 03:14:43 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 27 Oct 2016 10:14:37 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Result of WGLC on draft-ietf-anima-grasp-07 - Respond by Oct. 14, 2016 Thread-Index: AdIa3lKtZwMFGGBxRGe3GtIfD074fwVGDJrw Date: Thu, 27 Oct 2016 02:14:36 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CC29FDF@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CC1FE61@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CC1FE61@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CC29FDFNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.58116315.0051, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8771515d14d225d8c2a3e3a1fd4c7895 Archived-At: Cc: Toerless Eckert , "anima-chairs@tools.ietf.org" Subject: [Anima] Result of WGLC on draft-ietf-anima-grasp-07 - Respond by Oct. 14, 2016 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 02:14:53 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CC29FDFNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all Given there is no negative response to the WGLC and we did receive good rev= iews through ANIMA-signaling mail list and considering the past history of = this work, the ANIMA chairs feel it is has passed the WGLC and should advan= ce. However, this conclusion is made with the condition that the authors wo= uld solve the comments received during the WGLC and these modifications wer= e not substantial changes from 07 version. If there are big changes, a shor= ter second WGLC may be needed. Once the update is published and it meets the above condition, for which th= e second WGLC is not needed, as shepherd, Sheng Jiang will finalize the she= pherd document and send the document on. Best regards, Toerless & Sheng From: Sheng Jiang [mailto:jiangsheng@huawei.com] Sent: Friday, September 30, 2016 1:49 PM To: anima@ietf.org Cc: anima-chairs@tools.ietf.org; Toerless Eckert Subject: WGLC on draft-ietf-anima-grasp-07 - Respond by Oct. 14, 2016 Hi all, This message starts the ANIMA Working Group Last Call to advance draft-ietf= -anima-grasp-07, A Generic Autonomic Signaling Protocol (GRASP). This docum= ent's intended status is Proposed Standard. At present, there is no IPR fil= e against this document. Please send your comments by October 14, 2016. If you do not feel this doc= ument should advance, please state your reasons why. Sheng Jiang is the assigned shepherd. Regards, Sheng & Toerless --_000_5D36713D8A4E7348A7E10DF7437A4B927CC29FDFNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all=

&n= bsp;

Given t= here is no negative response to the WGLC and we did receive good reviews th= rough ANIMA-signaling mail list and considering the past history of this wo= rk, the ANIMA chairs feel it is has passed the WGLC and should advance. However, this conclusion is made with the con= dition that the authors would solve the comments received during the WGLC a= nd these modifications were not substantial changes from 07 version. If the= re are big changes, a shorter second WGLC may be needed.

&n= bsp;

Once th= e update is published and it meets the above condition, for which the secon= d WGLC is not needed, as shepherd, Sheng Jiang will finalize the shepherd d= ocument and send the document on.

&n= bsp;

Best re= gards,

&n= bsp;

Toerles= s & Sheng

&n= bsp;

From: Sheng Jiang = [mailto:jiangsheng@huawei.com]
Sent: Friday, September 30, 2016 1:49 PM
To: anima@ietf.org
Cc: anima-chairs@tools.ietf.org; Toerless Eckert
Subject: WGLC on draft-ietf-anima-grasp-07 - Respond by Oct. 14, 201= 6

 

Hi all,

 

This message starts the ANIMA W= orking Group Last Call to advance draft-ietf-anima-grasp-07, A Generic Auto= nomic Signaling Protocol (GRASP). This document’s intended status is = Proposed Standard. At present, there is no IPR file against this document.

 

Please send your comments by Oc= tober 14, 2016. If you do not feel this  document should advance, plea= se state your reasons why.

 

Sheng Jiang is the assigned she= pherd.

 

Regards,

 

Sheng & Toerless=

--_000_5D36713D8A4E7348A7E10DF7437A4B927CC29FDFNKGEML515MBXchi_-- From nobody Sat Oct 29 12:11:49 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C363129588; Sat, 29 Oct 2016 12:11:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147776830637.30723.15038178138979622245.idtracker@ietfa.amsl.com> Date: Sat, 29 Oct 2016 12:11:46 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-grasp-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 19:11:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : A Generic Autonomic Signaling Protocol (GRASP) Authors : Carsten Bormann Brian Carpenter Bing Liu Filename : draft-ietf-anima-grasp-08.txt Pages : 73 Date : 2016-10-29 Abstract: This document establishes requirements for a signaling protocol that enables autonomic devices and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings mutually with them. The document then defines a general protocol for discovery, synchronization and negotiation, while the technical objectives for specific scenarios are to be described in separate documents. An Appendix briefly discusses existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 29 12:29:17 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0884A1295E0 for ; Sat, 29 Oct 2016 12:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1auj3yY9hUSn for ; Sat, 29 Oct 2016 12:29:14 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B00F129593 for ; Sat, 29 Oct 2016 12:29:14 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id s8so54722028pfj.2 for ; Sat, 29 Oct 2016 12:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hOwvuvnC5uW2T82FN0kbXeAfFeKVArIBwEkxp+sd/Lk=; b=v9BtKF+bQmyGBF0hPrwXnn3U7GbDO51gYyxMp8Sj4g9OS6vTyF9bTzj0eujdn2Xfbo 3Zo3/i1GbsP3I0Dzl28AD/8hFr2n9KM3eqKIr3Q2E4nEb25bHdp6VbVqE52DhQdB6/uo MxGd6aUDuAloUQ60DiHvS8mGrqOW0li+/co07IMKoQxOAsDnL22YY4ynM/TwM/ZJR+eP 3po+kVNjIZQTHGiYCgyKJc6JZERihNHo865iMFOltmQlcnKQqhJPmE/TU599J7rsDGAq BeqGigjiGQdOSq2RPS1x/oVgcbn6aZYw4hizhGCvsuBYf6oDHpM2cJPN7GPrkyrkElJa qAjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hOwvuvnC5uW2T82FN0kbXeAfFeKVArIBwEkxp+sd/Lk=; b=KXAaj/gN3W2kTkYTRRupEQw7Fm54/nXlgU8KjmY7kVWpk3+VWeEsA8SryFZmHX5fKS nvwSYorFwd8RfFVxOJP4ROojWmxRlG93SaQZZfqU/uokUkesdsfZzp0tXKilJjQsTCI9 +JxRr0V8Doe8Xsp5/dgLwmJRaVCjY7N8wodcQa/GWP33fcVpyZpMe2oGC+NV/fpTSmdA Fc3r/3j3z0LkrfxxlFRsbcbMGIF3zdeXtlsQ/UOL3JJHEqnWaWyA9hiWY+ljVWMN4ALS yRS7fMYWrCY9cDNdg/s6Jh35svghaoBl5mskx2osVvs1y3ELr8rPcJvu0COxDj7gOSgS sE7A== X-Gm-Message-State: ABUngvdUVN3WCWcU9MJveBLk3e4ldj4lSOA1AtXlcHcUp151bDs+16qpfVYC+oTWp91trQ== X-Received: by 10.99.106.6 with SMTP id f6mr30072089pgc.27.1477769353778; Sat, 29 Oct 2016 12:29:13 -0700 (PDT) Received: from [192.168.178.23] (113.217.69.111.dynamic.snap.net.nz. [111.69.217.113]) by smtp.gmail.com with ESMTPSA id f62sm16797184pfg.18.2016.10.29.12.29.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2016 12:29:13 -0700 (PDT) References: <147776830637.30723.15038178138979622245.idtracker@ietfa.amsl.com> To: anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <3be8e1da-df03-f7c1-c2d0-6168d3676c72@gmail.com> Date: Sun, 30 Oct 2016 08:29:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147776830637.30723.15038178138979622245.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 19:29:16 -0000 Hi, This version is intended to respond to all the comments we received so far, including those discussed on the design team list. Special thanks to Michael Richardson for his thorough analysis. There are a couple of protocol changes: 1. Added an M_INVALID message, so that a node can tell its peer that it did not understand a message. This is mainly intended so that future extensions (new message types and option types) can be added without disruption. 2. Increased the Session ID space from 24 to 32 bits. This has very minor impact on the CBOR encoding, but significantly reduces the chance of a Session ID collision. There is one idnits warning: draft-greevenbosch-appsawg-cbor-cddl is a normative reference to an informative draft. If CDDL is not on the standards track soon, we will have to deal with this reference in a different way. The full change log: Protocol change: Added M_INVALID message. Protocol change: Increased Session ID space to 32 bits. Enhanced rules to avoid Session ID clashes. Corrected and completed description of timeouts for Request messages. Improved wording about exponential backoff and DoS. Clarified that discovery relaying is not done by limited security instances. Corrected and expanded explanation of port used for Discovery Response. Noted that Discovery message could be sent unicast in special cases. Added paragraph on extensibility. Specified default maximum message size. Added Appendix for sample messages. Added short protocol overview. Editorial fixes, including minor re-ordering for readability. Regards Brian + Bing + Carsten P.S. My Python prototype is up to date for these changes. On 30/10/2016 08:11, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : A Generic Autonomic Signaling Protocol (GRASP) > Authors : Carsten Bormann > Brian Carpenter > Bing Liu > Filename : draft-ietf-anima-grasp-08.txt > Pages : 73 > Date : 2016-10-29 > > Abstract: > This document establishes requirements for a signaling protocol that > enables autonomic devices and autonomic service agents to dynamically > discover peers, to synchronize state with them, and to negotiate > parameter settings mutually with them. The document then defines a > general protocol for discovery, synchronization and negotiation, > while the technical objectives for specific scenarios are to be > described in separate documents. An Appendix briefly discusses > existing protocols with comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Oct 30 17:03:56 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381521293F4 for ; Sun, 30 Oct 2016 17:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTtYISDi5uNo for ; Sun, 30 Oct 2016 17:03:54 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A3E120726 for ; Sun, 30 Oct 2016 17:03:53 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 475D458C4AE; Mon, 31 Oct 2016 01:03:52 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2A27FB0ACBB; Mon, 31 Oct 2016 01:03:52 +0100 (CET) Date: Mon, 31 Oct 2016 01:03:52 +0100 From: Toerless Eckert To: Michael Richardson Message-ID: <20161031000352.GA967@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 00:03:55 -0000 MichaelR: I am confused about the reason for this discussion. It seems you are trying to figure out how to minimize the impact of the insecure multicast piece of GRASP, but in the context of ANIMA this question would be irrelevant, because we are not doing any insecure GRASP in BRSKY or ACP with current draft - the use of insecure GRASP was removed in those drafts before Berlin because of the majority of the bootstrap teams choice for DNS-SD/mDNS. When GRASP is run securely in its two forms for the ACP, it is always protected/ encrypted by the ACP, so i think your security concern would then not be valid. Do you see some IoT context where you would use insecure GRASP instead of DNS-SD/mDNS, eg: in some IoT context ? Cheers Toerless On Sat, Oct 22, 2016 at 03:37:56PM -0400, Michael Richardson wrote: > > Brian E Carpenter wrote: > > On 21/10/2016 01:56, Michael Richardson wrote: > >> > >> Brian E Carpenter wrote: > >> >> What I was saying was, *IF* I know how to find a machine with an open > >> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that > >> >> I should receive my answer on that connection. > >> > >> > A says discover("B") to C, but C doesn't know where B is. So there will > >> > be no answer, unless C does extra stuff. > >> > >> So, C would forward the discover("B"), and then when it gets to B, > >> it would connect directly to A, and introduce itself? This is obvious now > >> that you give this example, but not from the document. I might also think > >> that B would connect to C, and then C would tell A. > > > But it couldn't do that unless it had already discovered C previously, in which > > case it could simply reply to A with its cached locator for C. > > >> This clearly fails if A has a LL address only. > > > Yes, but that's why we have discovery relaying. > > Still, I'm more confused now. > > When A has a LL only, we would have to have, not only discovery relaying, but > also response forwarding. So does B reply to C (to be relayed to A), or is > it a fail as B tries to connect to A's LL address, and does not connect? > > > >> >> In the 6tisch case doing multicast is either expensive or unsupported. > >> >> On the other hand, we can quite easily declare that the 6LBR / > >> >> DODAG-root (the router at the top of the tree) will have > >> >> GRASP_LISTEN_PORT open. > >> > >> > Yes, you have topology knowledge in that case. > >> > >> Do you agree that a discovery("C") sent to C over TCP should be answered > >> over that TCP connection? > > > Oh yes, and that is what should happen under the covers in any case, if discovery > > is running over the ACP. > > > However, I'm not convinced that we should document this (unicast discovery). > > At least not yet. > > When? I feel that this is important behaviour that needs to be defined for > the GRASP core system. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Sun Oct 30 17:23:43 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1515B129454 for ; Sun, 30 Oct 2016 17:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5g26Byqm9t3 for ; Sun, 30 Oct 2016 17:23:40 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BC0120726 for ; Sun, 30 Oct 2016 17:23:40 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id 197so67337661pfu.0 for ; Sun, 30 Oct 2016 17:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=b/NFvjNNZf+iLOWmx4B1+C2d3M7HUHl3K0527jtoWuw=; b=HCuFDpPYoK3VObs7ORj67EQYmfi6mHe7fBZVF/LfYLdv+5axMMBuoszqEVOv0LpiG6 HP69N++OxC1O1lRxgshEmhvy9jHrD8T9RVLA8ELZMDPkoL4tT9GyM5GR2igebJbaJUAO ckx1WsZa2Lb3JscHxK0GD8GQc/49VCpf5pajbIZoSji7qXO0/7Y/lehgI8xBgzvCA8f9 KsBdow3azGoLjDVX6HKHs/2F8LeHlx54gcvfdjaaIugT8V+3hbAxMsPgZqbbNNKG6D9L dv+n5Fqfl/47h5lVNiOdyQxgl/OpRcVCNdZ8ErllX9PzoZa0gfAYZ8qiGXtds02XzDQh MUFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=b/NFvjNNZf+iLOWmx4B1+C2d3M7HUHl3K0527jtoWuw=; b=jRmUqbl1GbG8TPPn4zW3op7/BSLJHBV8/K7IoccgL+wox5t7JfwqloYOSqqckaOUyP h45OEdX3RxjNjblhtHIYZ2SOOkMEc5SQvhvXSLAkqpTS7sNBQVanUjwC7pW1GXEXDrVA X4HdnxbgpYmJeEWB4L/3MKE6Fca9B5QC67TZ4A8TpOwEznVRXv4Vw90WqnUvyp9Yn4Ii DuXLBvZCasIPsj9LU5VzzLxicRKwHLNraitJlPxCS3GN4NErLqKCh5NFGEtrC1LIz4mV huy/3Uq58T9StTJbO81WHGq8dQxDDZN6EbnvGiCGm0HhZ833Y2nApOghuL1rCg6v8Lls A8Lw== X-Gm-Message-State: ABUngvcdr8OYZNRUoyw8WKNPWU/24eqxnnB+DoI6UlwLYRA0zqAsw9XS0O3ColAPn3Kjpg== X-Received: by 10.98.211.147 with SMTP id z19mr44467532pfk.149.1477873419456; Sun, 30 Oct 2016 17:23:39 -0700 (PDT) Received: from ?IPv6:2406:e007:7cc3:1:28cc:dc4c:9703:6781? ([2406:e007:7cc3:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c75sm32046635pfb.23.2016.10.30.17.23.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Oct 2016 17:23:38 -0700 (PDT) To: Toerless Eckert , Michael Richardson References: <20161031000352.GA967@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <519c36bf-843a-d215-95d3-1efa829b7f60@gmail.com> Date: Mon, 31 Oct 2016 13:23:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161031000352.GA967@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 00:23:42 -0000 On 31/10/2016 13:03, Toerless Eckert wrote: > MichaelR: > > I am confused about the reason for this discussion. It seems you are trying > to figure out how to minimize the impact of the insecure multicast piece of GRASP, > but in the context of ANIMA this question would be irrelevant, because we are > not doing any insecure GRASP in BRSKY or ACP with current draft - the use of > insecure GRASP was removed in those drafts before Berlin because of the majority > of the bootstrap teams choice for DNS-SD/mDNS. Which, I have to point out, is not a consensus position; design teams propose, they don't decide. I'm waiting to see the next draft before I raise this issue on the WG list. > When GRASP is run securely in its two forms for the ACP, it is always protected/ > encrypted by the ACP, so i think your security concern would then not be valid. I'm still waiting to see a clear explanation of how the ACP will secure LL multicast, however. > Do you see some IoT context where you would use insecure GRASP instead of DNS-SD/mDNS, > eg: in some IoT context ? Michael can answer that for himself, but the reason we noted the *possibility* of doing this in grasp-08 is because it seems clearly harmless. So from the GRASP spec point of view, I consider the issue closed. Regards, Brian > Cheers > Toerless > > On Sat, Oct 22, 2016 at 03:37:56PM -0400, Michael Richardson wrote: >> >> Brian E Carpenter wrote: >> > On 21/10/2016 01:56, Michael Richardson wrote: >> >> >> >> Brian E Carpenter wrote: >> >> >> What I was saying was, *IF* I know how to find a machine with an open >> >> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that >> >> >> I should receive my answer on that connection. >> >> >> >> > A says discover("B") to C, but C doesn't know where B is. So there will >> >> > be no answer, unless C does extra stuff. >> >> >> >> So, C would forward the discover("B"), and then when it gets to B, >> >> it would connect directly to A, and introduce itself? This is obvious now >> >> that you give this example, but not from the document. I might also think >> >> that B would connect to C, and then C would tell A. >> >> > But it couldn't do that unless it had already discovered C previously, in which >> > case it could simply reply to A with its cached locator for C. >> >> >> This clearly fails if A has a LL address only. >> >> > Yes, but that's why we have discovery relaying. >> >> Still, I'm more confused now. >> >> When A has a LL only, we would have to have, not only discovery relaying, but >> also response forwarding. So does B reply to C (to be relayed to A), or is >> it a fail as B tries to connect to A's LL address, and does not connect? >> >> >> >> >> In the 6tisch case doing multicast is either expensive or unsupported. >> >> >> On the other hand, we can quite easily declare that the 6LBR / >> >> >> DODAG-root (the router at the top of the tree) will have >> >> >> GRASP_LISTEN_PORT open. >> >> >> >> > Yes, you have topology knowledge in that case. >> >> >> >> Do you agree that a discovery("C") sent to C over TCP should be answered >> >> over that TCP connection? >> >> > Oh yes, and that is what should happen under the covers in any case, if discovery >> > is running over the ACP. >> >> > However, I'm not convinced that we should document this (unicast discovery). >> > At least not yet. >> >> When? I feel that this is important behaviour that needs to be defined for >> the GRASP core system. >> >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > From nobody Sun Oct 30 18:19:25 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311BA12940A for ; Sun, 30 Oct 2016 16:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDLBWXaN3Dj2 for ; Sun, 30 Oct 2016 16:54:26 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7A7129409 for ; Sun, 30 Oct 2016 16:54:26 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 72B9C58C4AE; Mon, 31 Oct 2016 00:54:24 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5C0E8B0ACC1; Mon, 31 Oct 2016 00:54:24 +0100 (CET) Date: Mon, 31 Oct 2016 00:54:24 +0100 From: Toerless Eckert To: Michael Richardson Message-ID: <20161030235424.GA30878@faui40p.informatik.uni-erlangen.de> References: <475a43c1-1522-1e38-5c66-00199bb7f455@gmail.com> <648.1476907175@obiwan.sandelman.ca> <19006.1476928734@obiwan.sandelman.ca> <050276dd-f406-8aa7-7c62-accc3da6c7f1@gmail.com> <7995.1476968217@obiwan.sandelman.ca> <84cc21bc-8a5b-651d-a24c-1b50221229ef@gmail.com> <8498.1477165076@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8498.1477165076@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Sun, 30 Oct 2016 18:19:24 -0700 Cc: Anima WG Subject: Re: [Anima] GRASP issue 55: Could discovery be performed over TCP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 23:54:29 -0000 MichaelR: I am confused about the reason for this discussion. It seems you are trying to figure out how to minimize the impact of the insecure multicast piece of GRASP, but in the context of ANIMA this question would be irrelevant, because we are not doing any insecure GRASP in BRSKY or ACP with current draft - the use of insecure GRASP was removed in those drafts before Berlin because of the majority of the bootstrap teams choice for DNS-SD/mDNS. When GRASP is run securely in its two forms for the ACP, it is always protected/ encrypted by the ACP, so i think your security concern would then not be valid. Do you see some IoT context where you would use insecure GRASP instead of DNS-SD/mDNS, eg: in some IoT context ? Cheers Toerless On Sat, Oct 22, 2016 at 03:37:56PM -0400, Michael Richardson wrote: > > Brian E Carpenter wrote: > > On 21/10/2016 01:56, Michael Richardson wrote: > >> > >> Brian E Carpenter wrote: > >> >> What I was saying was, *IF* I know how to find a machine with an open > >> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that > >> >> I should receive my answer on that connection. > >> > >> > A says discover("B") to C, but C doesn't know where B is. So there will > >> > be no answer, unless C does extra stuff. > >> > >> So, C would forward the discover("B"), and then when it gets to B, > >> it would connect directly to A, and introduce itself? This is obvious now > >> that you give this example, but not from the document. I might also think > >> that B would connect to C, and then C would tell A. > > > But it couldn't do that unless it had already discovered C previously, in which > > case it could simply reply to A with its cached locator for C. > > >> This clearly fails if A has a LL address only. > > > Yes, but that's why we have discovery relaying. > > Still, I'm more confused now. > > When A has a LL only, we would have to have, not only discovery relaying, but > also response forwarding. So does B reply to C (to be relayed to A), or is > it a fail as B tries to connect to A's LL address, and does not connect? > > > >> >> In the 6tisch case doing multicast is either expensive or unsupported. > >> >> On the other hand, we can quite easily declare that the 6LBR / > >> >> DODAG-root (the router at the top of the tree) will have > >> >> GRASP_LISTEN_PORT open. > >> > >> > Yes, you have topology knowledge in that case. > >> > >> Do you agree that a discovery("C") sent to C over TCP should be answered > >> over that TCP connection? > > > Oh yes, and that is what should happen under the covers in any case, if discovery > > is running over the ACP. > > > However, I'm not convinced that we should document this (unicast discovery). > > At least not yet. > > When? I feel that this is important behaviour that needs to be defined for > the GRASP core system. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Oct 31 11:18:38 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BC912999F; Mon, 31 Oct 2016 11:18:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147793791802.23181.7413424443005063098.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 11:18:38 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:18:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-04.txt Pages : 47 Date : 2016-10-31 Abstract: This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed X.509 certificate, in combination with a vendor authorized service on the Internet. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 14:44:00 2016 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 444A5129AA4; Mon, 31 Oct 2016 14:43:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795023527.23245.9243965489950062206.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 14:43:55 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 21:43:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : An Autonomic Control Plane Authors : Michael H. Behringer Toerless Eckert Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-04.txt Pages : 33 Date : 2016-10-31 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM communications over a network that is not configured, or mis-configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 15:19:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26448129B74 for ; Mon, 31 Oct 2016 15:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OYiHlQjhUox for ; Mon, 31 Oct 2016 15:19:00 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B3E129B4D for ; Mon, 31 Oct 2016 15:18:57 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C518458C4AE; Mon, 31 Oct 2016 23:18:55 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id AF006B0ACD8; Mon, 31 Oct 2016 23:18:55 +0100 (CET) Date: Mon, 31 Oct 2016 23:18:55 +0100 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Toerless Eckert , Michael Richardson , Anima WG Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:19:03 -0000 On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote: > > I am confused about the reason for this discussion. It seems you are trying > > to figure out how to minimize the impact of the insecure multicast piece of GRASP, > > but in the context of ANIMA this question would be irrelevant, because we are > > not doing any insecure GRASP in BRSKY or ACP with current draft - the use of > > insecure GRASP was removed in those drafts before Berlin because of the majority > > of the bootstrap teams choice for DNS-SD/mDNS. > > Which, I have to point out, is not a consensus position; design teams propose, > they don't decide. I'm waiting to see the next draft before I raise this issue on > the WG list. Right. I guess we've now posted all drafts we can before the deadline, so let me change this mail threads subject to get the discussion started. Current state: a) The bootstrap design team mayority did conclude that mDNS is the best option for discovery of bootstrap proxy by the pledge (link-local). I'll still have to read in more detail through the document to see how well the text discusses all the reasons why. b) I have just posted ACP draft -04 in which i have reversed the choice of mDNS for ACP discovery by neighbors from the -03 text which had mDNS. So -04 defines to use (DULL) GRASP for ACP discovery with more details. I had put mDNS into -03 because of my thinking that all the reasons that that bootstrap had for mDNS would a) also apply to ACP discovery, and that b) it would make life easier to have fewer discovery protocols. a) was not well thought through on my side. Pls check out the text on discover in -04, i hope it justifies use of GRASP for neighbor discovery. > > When GRASP is run securely in its two forms for the ACP, it is always protected/ > > encrypted by the ACP, so i think your security concern would then not be valid. > > I'm still waiting to see a clear explanation of how the ACP will secure > LL multicast, however. I am not sure i understand the documentation ask. The ACP has a bunch of (virtual) interfaces. In the most simple implementation option, each ACP channel to an ACP neighbor is its own (p2p) L3 interface in the ACP. And thats all the interfaces the ACP has. All packets, unicast or multicast that are sent into or received from those interfaces are protected/encrypted by the fact that they are transmitted encrypted by the seleted ACP channel encryption protocol. > > Do you see some IoT context where you would use insecure GRASP instead of DNS-SD/mDNS, > > eg: in some IoT context ? > > Michael can answer that for himself, but the reason we noted the *possibility* > of doing this in grasp-08 is because it seems clearly harmless. So from the > GRASP spec point of view, I consider the issue closed. Ues, i am mostly interested in use-case explanations Michael has in mind. The other piece was that Michael was trying to figure out how to avoid using LL multicast and instead use unicast: -> Within the ACP this question is somewhat irrelevant because its secured. -> Given how ACP interfaces are p2p secured interfaces to neigbhors, you could know upfront the LL IPv6 address of the neighbor on the interface, but there is really no framework in IETF protocols that leverages this optimization for p2p links, so i don't think we should bother doing it. Its work without RoI. -> Outside the ACP i am not sure about the use-case. To be options proof: GRASP should permit sending and receiving of LL UNICAST instead of LL multicast for those messages where GRASP specifies LL multicast, so that if some deployment figures out that there is some optimization possible with the use of LL unicast, then it can simply do that instead of asking for a GRASP spec modification. The big security risk though is GLOBAL UNICAST MUST NOT BE PERMITTED as a replacement for LL multicast. Thats an attack vector. And typical socket software code is usually victim to that. Aka: you open a socket, you bind it to a link-local multicast group and you go away. Alas: this socket will receive not only link-local multicast, but also LL unicast (good) and global unicast (bad). So the application code usually would need to check the destination address the packet was sent to and drop those packets sent to the global unicast address - if the protocol was really only designed for LL multicast - and therefore assuming security properties of LL multicast (logical vicinity of sender). A good exampe for replacing multicast with unicast is WiFI where luckily hosts do accept multicast packets as L2 unicast instead of L2 multicast. And thats done to get the benefit of L2 retransmissions, that do not exist for L2 multicast. Cheers Toerless > > Regards, > Brian > > > Cheers > > Toerless > > > > On Sat, Oct 22, 2016 at 03:37:56PM -0400, Michael Richardson wrote: > >> > >> Brian E Carpenter wrote: > >> > On 21/10/2016 01:56, Michael Richardson wrote: > >> >> > >> >> Brian E Carpenter wrote: > >> >> >> What I was saying was, *IF* I know how to find a machine with an open > >> >> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that > >> >> >> I should receive my answer on that connection. > >> >> > >> >> > A says discover("B") to C, but C doesn't know where B is. So there will > >> >> > be no answer, unless C does extra stuff. > >> >> > >> >> So, C would forward the discover("B"), and then when it gets to B, > >> >> it would connect directly to A, and introduce itself? This is obvious now > >> >> that you give this example, but not from the document. I might also think > >> >> that B would connect to C, and then C would tell A. > >> > >> > But it couldn't do that unless it had already discovered C previously, in which > >> > case it could simply reply to A with its cached locator for C. > >> > >> >> This clearly fails if A has a LL address only. > >> > >> > Yes, but that's why we have discovery relaying. > >> > >> Still, I'm more confused now. > >> > >> When A has a LL only, we would have to have, not only discovery relaying, but > >> also response forwarding. So does B reply to C (to be relayed to A), or is > >> it a fail as B tries to connect to A's LL address, and does not connect? > >> > >> > >> >> >> In the 6tisch case doing multicast is either expensive or unsupported. > >> >> >> On the other hand, we can quite easily declare that the 6LBR / > >> >> >> DODAG-root (the router at the top of the tree) will have > >> >> >> GRASP_LISTEN_PORT open. > >> >> > >> >> > Yes, you have topology knowledge in that case. > >> >> > >> >> Do you agree that a discovery("C") sent to C over TCP should be answered > >> >> over that TCP connection? > >> > >> > Oh yes, and that is what should happen under the covers in any case, if discovery > >> > is running over the ACP. > >> > >> > However, I'm not convinced that we should document this (unicast discovery). > >> > At least not yet. > >> > >> When? I feel that this is important behaviour that needs to be defined for > >> the GRASP core system. > >> > >> > >> -- > >> Michael Richardson , Sandelman Software Works > >> -= IPv6 IoT consulting =- From nobody Mon Oct 31 16:40:40 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EEF1294A8 for ; Mon, 31 Oct 2016 16:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUBOuWoHmsk1 for ; Mon, 31 Oct 2016 16:40:38 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35371127077 for ; Mon, 31 Oct 2016 16:40:38 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 189so30864600pfz.3 for ; Mon, 31 Oct 2016 16:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=JId0onr5R1u13Dmn5wDbMq3LwfU/6/YPcTvKgA7WiU0=; b=SPIeW/IJ9o/sHcPN/JMpH9BdbtQXEwewy3FG46jMGjZ91j6iRgoRbKPP+Yce80s/rG k/XnOcTOvLi4KFSu++UhfUVP7RG2oy+D+MKytRc1isBv2VP5VCtLzSgQ32QT2HoQnmvi AjgD9pXGsrflosIiicnusJNEt58hWcnaAsOAYxQLDhTJtMALlttN+CpR1+jEc2dWpH9f vsP7odZSSBGe9bcKnXNDkpd1LE1U1Um2PKjyqL9IiiYADacQRwnCZI3aAxwkBWLuflS7 qYHeiE5nFfGAcdtGaFmeEeTBlrYs4P9HbifHCoWgIUMqmCCWqqq97M1J+27vdC5xe2bh VZxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=JId0onr5R1u13Dmn5wDbMq3LwfU/6/YPcTvKgA7WiU0=; b=mwvau02ObBWIBZy2xLWWNsR1pExD9XicZJ+7DVbFY4/2A7bo5YUwFdSmAWQXTfNXwa dXlfRP8RIcQ19bD3EIXWq4pW0LSkjsEhsv+z+MNPCSltzjWzlTIhQd+bU7FwyByCOhrN gQMNXwxw+vU+yrF/V6l+keTtEGtJYcqXQR8v9QOn10DfUOCelpXwHqjOyY1oX19x9wn5 z1jcF83EhwVUwL03eBdZSmmVzaOvKbCRJr3Re0vLFPpBJstd6vAAfVhaXroSCxvvPkU7 SRJDvg8jpxGD9oam7o/BHokpbyoMKJ03sFSkcZluPU3IyM+v8kqrouSvJfKZj6oQmrwF qJxA== X-Gm-Message-State: ABUngvfJWhVBA+Y+rT1AOOJBqNRJhdV8zUT7x8RyZ94Qh3vMtAjk6lAPwKZIFlU9GaL0og== X-Received: by 10.99.174.5 with SMTP id q5mr44902369pgf.128.1477957237569; Mon, 31 Oct 2016 16:40:37 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id e7sm37849114pfa.65.2016.10.31.16.40.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 16:40:37 -0700 (PDT) To: Anima WG References: <147793791802.23181.7413424443005063098.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 1 Nov 2016 12:40:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147793791802.23181.7413424443005063098.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 23:40:40 -0000 Hi, This is about the bootstrapping draft, but I will start by quoting Toerless from another thread: On 01/11/2016 11:18, Toerless Eckert wrote: > On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote: >>> I am confused about the reason for this discussion. It seems you are trying >>> to figure out how to minimize the impact of the insecure multicast piece of GRASP, >>> but in the context of ANIMA this question would be irrelevant, because we are >>> not doing any insecure GRASP in BRSKY or ACP with current draft - the use of >>> insecure GRASP was removed in those drafts before Berlin because of the majority >>> of the bootstrap teams choice for DNS-SD/mDNS. >> >> Which, I have to point out, is not a consensus position; design teams propose, >> they don't decide. I'm waiting to see the next draft before I raise this issue on >> the WG list. > > Right. I guess we've now posted all drafts we can before the deadline, so > let me change this mail threads subject to get the discussion started. > > Current state: > > a) The bootstrap design team mayority did conclude that mDNS is the best option > for discovery of bootstrap proxy by the pledge (link-local). I'll still have > to read in more detail through the document to see how well the text discusses > all the reasons why. To be clear, I have no objection to mDNS being mandatory to implement for BRSKI proxies and/or registrars. This will allow the BRSKI mechanism to be used in a wider context than just an Anima-conformant autonomous network (AN), because any joining node (pledge) can then discover a registrar or proxy via mDNS. However, I belive that the Anima solution will be incoherent unles GRASP mechanisms are *also* mandatory for BRSKI proxies and/or registrars. In this case it will be possible for autonomic nodes that wish to join the AN to use GRASP with no need for mDNS. If we don't do this, the Anima solution will not be complete in itself. Especially during the early formation of an AN after a cold start, this is a problem. So specifically I want bootstrapping-keyinfra to specify that - registrars and proxies MUST be disoverable by both mDNS/DNS-SD and GRASP. - pledges MUST use one of these two mechanisms There are some details to be worked out, because there are several ways to use GRASP for this purpose, but we need to get the question settled as a matter of principle first. I do believe that the security issues are very similar. Both mDNS and GRASP involve link-local multicast and its intrinsic security and privacy issues. The information that would communicated by multicast would be pretty much the same in both cases. Unfortunately I will not be in Seoul to argue this point, so it would be nice to settle it by email. Regards Brian From nobody Mon Oct 31 17:59:24 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F064612947A for ; Mon, 31 Oct 2016 17:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGnsSxEyxh1j for ; Mon, 31 Oct 2016 17:59:21 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0969A1293F4 for ; Mon, 31 Oct 2016 17:59:21 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id s8so85032116pfj.2 for ; Mon, 31 Oct 2016 17:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lZz3W0RpGbc6hOjA6S3mz3R3lvh3dldgxCePNOYgzBg=; b=b9I1gOwbOYI6HaVaNI44xBb9vgBQrR6EIWX+DAqmSlRXzZlWEUGy9KVjI0r9j3WkBM TuZxg51Kh3MNumhJioJtwhDoFmE895Yia/2D60IspvCmaIuXx2wshxGzxtQI1MlZ6Fjg D847MVDv0CtWoP4lE8XgRYK07NYdMn0u+timAu4TXKsjff8waJIXwhzUZvzpTMB4+3gn dWM7hIkvJ9GcSUHYNthI/d7aj7pGx/0XrDBfSjjyWh9e5KouwUw0wIdaVeZO/aOflH+c lv8tyXuninSfBS0IBlNG6cVb8YztmRqibz9zcPrt1ej3CaILZ9rqtAlroHKA9u/GRRYc aaow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=lZz3W0RpGbc6hOjA6S3mz3R3lvh3dldgxCePNOYgzBg=; b=aCQGiGS7Gi9jspS2OV8Y8b0eO2c4PGt8sIWcVmH6NTMU7n/W1uCUq6m4EloWyYog5F M6UxSazCdcMx6O04Mn8cg4A7EkGZ98wQau1qDJWfp++QAvfNq1lOIvkpSUOGbdIuX7/Z fd7RILuoKY79fk7PjRIwF966VrTsm4XVrPTGJC9JbkAX6l490PSnF/liUUDrjaTD3EkZ H523A+GFRs1KDcHK986MNvsY1NtpLpzYf1MlO6FrhzWitx2jAmfk4GgLedSjht6b4xnU AOUBtTefrCwHkAfjIfRU0Gd9e98jC0byRob1b/h4+LVwPxnJ6nV91+aw259xV8o7+XRT tpww== X-Gm-Message-State: ABUngvetTU/Oiv7ikjdVoF/Y9xHvv1l3aueY8+b+cer8JggkM+R9U03opTIib/iA9qFXeA== X-Received: by 10.99.0.194 with SMTP id 185mr11669438pga.111.1477961960211; Mon, 31 Oct 2016 17:59:20 -0700 (PDT) Received: from [172.24.60.35] ([202.36.244.191]) by smtp.gmail.com with ESMTPSA id bu8sm38105307pab.46.2016.10.31.17.59.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 17:59:19 -0700 (PDT) To: Toerless Eckert References: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 1 Nov 2016 13:59:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161031221855.GA1970@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , Anima WG Subject: Re: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 00:59:23 -0000 Hi Toerless, On 01/11/2016 11:18, Toerless Eckert wrote: > On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote: >>> I am confused about the reason for this discussion. It seems you are trying >>> to figure out how to minimize the impact of the insecure multicast piece of GRASP, >>> but in the context of ANIMA this question would be irrelevant, because we are >>> not doing any insecure GRASP in BRSKY or ACP with current draft - the use of >>> insecure GRASP was removed in those drafts before Berlin because of the majority >>> of the bootstrap teams choice for DNS-SD/mDNS. >> >> Which, I have to point out, is not a consensus position; design teams propose, >> they don't decide. I'm waiting to see the next draft before I raise this issue on >> the WG list. > > Right. I guess we've now posted all drafts we can before the deadline, so > let me change this mail threads subject to get the discussion started. > > Current state: > > a) The bootstrap design team mayority did conclude that mDNS is the best option > for discovery of bootstrap proxy by the pledge (link-local). I'll still have > to read in more detail through the document to see how well the text discusses > all the reasons why. I responded to that under a different subject header. > > b) I have just posted ACP draft -04 in which i have reversed the choice of mDNS for > ACP discovery by neighbors from the -03 text which had mDNS. So -04 defines to > use (DULL) GRASP for ACP discovery with more details. > > I had put mDNS into -03 because of my thinking that all the reasons that that bootstrap > had for mDNS would a) also apply to ACP discovery, and that b) it would make life easier > to have fewer discovery protocols. a) was not well thought through on my side. > > Pls check out the text on discover in -04, i hope it justifies use of GRASP > for neighbor discovery. I will read that carefully, but for me that doesn't need justification, because we need the ANI to be self-contained, so depending on mDNS seems wrong. (In fact, why wouldn't configuring mDNS/DNS-SD/DNS be an autonomic function itself?) > >>> When GRASP is run securely in its two forms for the ACP, it is always protected/ >>> encrypted by the ACP, so i think your security concern would then not be valid. >> >> I'm still waiting to see a clear explanation of how the ACP will secure >> LL multicast, however. > > I am not sure i understand the documentation ask. The ACP has a bunch of (virtual) interfaces. In > the most simple implementation option, each ACP channel to an ACP neighbor is its own > (p2p) L3 interface in the ACP. And thats all the interfaces the ACP has. And that's the problem. GRASP discovery and flooding need sockets that supports link-local multicast sending and receiving for each physical interface. Currently the GRASP code finds out how many physical interfaces it has and for each one creates a multicast sending socket. It also has a socket that listens for incoming link-local multicasts on all physical interfaces. I don't see how to do that using the ACP interfaces that you describe. > All packets, unicast or multicast that are sent into or > received from those interfaces are protected/encrypted by the fact that they are transmitted > encrypted by the seleted ACP channel encryption protocol. Yes, and I'd like the LL multicast traffic to be protected too. But as far as I can see that needs explicit support in the ACP to emulate LL multicast sockets. The ideal would be that the ACP simply emulates LL interfaces, so that GRASP could treat them exactly like physical interfaces. If you want, I can point you the exact Python code that handles this in the prototype. > >>> Do you see some IoT context where you would use insecure GRASP instead of DNS-SD/mDNS, >>> eg: in some IoT context ? >> >> Michael can answer that for himself, but the reason we noted the *possibility* >> of doing this in grasp-08 is because it seems clearly harmless. So from the >> GRASP spec point of view, I consider the issue closed. > > Ues, i am mostly interested in use-case explanations Michael has in mind. > > The other piece was that Michael was trying to figure out how to avoid using LL multicast > and instead use unicast: > > -> Within the ACP this question is somewhat irrelevant because its secured. > > -> Given how ACP interfaces are p2p secured interfaces to neigbhors, you > could know upfront the LL IPv6 address of the neighbor on the interface, > but there is really no framework in IETF protocols that leverages this > optimization for p2p links, so i don't think we should bother doing it. > Its work without RoI. > > -> Outside the ACP i am not sure about the use-case. To be options proof: GRASP > should permit sending and receiving of LL UNICAST instead of LL multicast for > those messages where GRASP specifies LL multicast, so that if some deployment > figures out that there is some optimization possible with the use of LL unicast, > then it can simply do that instead of asking for a GRASP spec modification. Sure. That was my conclusion (for discovery; it makes no sense for flooding). > The big security risk though is GLOBAL UNICAST MUST NOT BE PERMITTED > as a replacement for LL multicast. Thats an attack vector. And typical > socket software code is usually victim to that. Aka: you open a socket, > you bind it to a link-local multicast group and you go away. Alas: this > socket will receive not only link-local multicast, but also LL unicast (good) > and global unicast (bad). So the application code usually would need to check > the destination address the packet was sent to and drop those packets > sent to the global unicast address - if the protocol was really only > designed for LL multicast - and therefore assuming security properties > of LL multicast (logical vicinity of sender). GRASP discovery and flood are specified as link-local, so yes, that check is needed. > A good exampe for replacing multicast with unicast is WiFI where luckily > hosts do accept multicast packets as L2 unicast instead of L2 multicast. > And thats done to get the benefit of L2 retransmissions, that do not exist > for L2 multicast. Ack. Brian From nobody Mon Oct 31 18:04:01 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08562129B74 for ; Mon, 31 Oct 2016 15:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W17px3lCk3rb for ; Mon, 31 Oct 2016 15:18:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C42F12946D for ; Mon, 31 Oct 2016 15:18:33 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C0A5C58C4AE; Mon, 31 Oct 2016 23:18:31 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9ABE3B0ACD8; Mon, 31 Oct 2016 23:18:31 +0100 (CET) Date: Mon, 31 Oct 2016 23:18:31 +0100 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20161031221831.GA941@faui40p.informatik.uni-erlangen.de> References: <20161031000352.GA967@faui40p.informatik.uni-erlangen.de> <519c36bf-843a-d215-95d3-1efa829b7f60@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519c36bf-843a-d215-95d3-1efa829b7f60@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Mon, 31 Oct 2016 18:04:01 -0700 Cc: Toerless Eckert , Michael Richardson , Anima WG Subject: [Anima] Use of GRSP in discovery (was: Re: GRASP issue 55: Could discovery be performed over TCP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:18:39 -0000 On Mon, Oct 31, 2016 at 01:23:36PM +1300, Brian E Carpenter wrote: > > I am confused about the reason for this discussion. It seems you are trying > > to figure out how to minimize the impact of the insecure multicast piece of GRASP, > > but in the context of ANIMA this question would be irrelevant, because we are > > not doing any insecure GRASP in BRSKY or ACP with current draft - the use of > > insecure GRASP was removed in those drafts before Berlin because of the majority > > of the bootstrap teams choice for DNS-SD/mDNS. > > Which, I have to point out, is not a consensus position; design teams propose, > they don't decide. I'm waiting to see the next draft before I raise this issue on > the WG list. Right. I guess we've now posted all drafts we can before the deadline, so let me change this mail threads subject to get the discussion started. Current state: a) The bootstrap design team mayority did conclude that mDNS is the best option for discovery of bootstrap proxy by the pledge (link-local). I'll still have to read in more detail through the document to see how well the text discusses all the reasons why. b) I have just posted ACP draft -04 in which i have reversed the choice of mDNS for ACP discovery by neighbors from the -03 text which had mDNS. So -04 defines to use (DULL) GRASP for ACP discovery with more details. I had put mDNS into -03 because of my thinking that all the reasons that that bootstrap had for mDNS would a) also apply to ACP discovery, and that b) it would make life easier to have fewer discovery protocols. a) was not well thought through on my side. Pls check out the text on discover in -04, i hope it justifies use of GRASP for neighbor discovery. > > When GRASP is run securely in its two forms for the ACP, it is always protected/ > > encrypted by the ACP, so i think your security concern would then not be valid. > > I'm still waiting to see a clear explanation of how the ACP will secure > LL multicast, however. I am not sure i understand the documentation ask. The ACP has a bunch of (virtual) interfaces. In the most simple implementation option, each ACP channel to an ACP neighbor is its own (p2p) L3 interface in the ACP. And thats all the interfaces the ACP has. All packets, unicast or multicast that are sent into or received from those interfaces are protected/encrypted by the fact that they are transmitted encrypted by the seleted ACP channel encryption protocol. > > Do you see some IoT context where you would use insecure GRASP instead of DNS-SD/mDNS, > > eg: in some IoT context ? > > Michael can answer that for himself, but the reason we noted the *possibility* > of doing this in grasp-08 is because it seems clearly harmless. So from the > GRASP spec point of view, I consider the issue closed. Ues, i am mostly interested in use-case explanations Michael has in mind. The other piece was that Michael was trying to figure out how to avoid using LL multicast and instead use unicast: -> Within the ACP this question is somewhat irrelevant because its secured. -> Given how ACP interfaces are p2p secured interfaces to neigbhors, you could know upfront the LL IPv6 address of the neighbor on the interface, but there is really no framework in IETF protocols that leverages this optimization for p2p links, so i don't think we should bother doing it. Its work without RoI. -> Outside the ACP i am not sure about the use-case. To be options proof: GRASP should permit sending and receiving of LL UNICAST instead of LL multicast for those messages where GRASP specifies LL multicast, so that if some deployment figures out that there is some optimization possible with the use of LL unicast, then it can simply do that instead of asking for a GRASP spec modification. The big security risk though is GLOBAL UNICAST MUST NOT BE PERMITTED as a replacement for LL multicast. Thats an attack vector. And typical socket software code is usually victim to that. Aka: you open a socket, you bind it to a link-local multicast group and you go away. Alas: this socket will receive not only link-local multicast, but also LL unicast (good) and global unicast (bad). So the application code usually would need to check the destination address the packet was sent to and drop those packets sent to the global unicast address - if the protocol was really only designed for LL multicast - and therefore assuming security properties of LL multicast (logical vicinity of sender). A good exampe for replacing multicast with unicast is WiFI where luckily hosts do accept multicast packets as L2 unicast instead of L2 multicast. And thats done to get the benefit of L2 retransmissions, that do not exist for L2 multicast. Cheers Toerless > > Regards, > Brian > > > Cheers > > Toerless > > > > On Sat, Oct 22, 2016 at 03:37:56PM -0400, Michael Richardson wrote: > >> > >> Brian E Carpenter wrote: > >> > On 21/10/2016 01:56, Michael Richardson wrote: > >> >> > >> >> Brian E Carpenter wrote: > >> >> >> What I was saying was, *IF* I know how to find a machine with an open > >> >> >> GRASP_LISTEN_PORT, and I connect to it, and unicast a DISCOVERY, that > >> >> >> I should receive my answer on that connection. > >> >> > >> >> > A says discover("B") to C, but C doesn't know where B is. So there will > >> >> > be no answer, unless C does extra stuff. > >> >> > >> >> So, C would forward the discover("B"), and then when it gets to B, > >> >> it would connect directly to A, and introduce itself? This is obvious now > >> >> that you give this example, but not from the document. I might also think > >> >> that B would connect to C, and then C would tell A. > >> > >> > But it couldn't do that unless it had already discovered C previously, in which > >> > case it could simply reply to A with its cached locator for C. > >> > >> >> This clearly fails if A has a LL address only. > >> > >> > Yes, but that's why we have discovery relaying. > >> > >> Still, I'm more confused now. > >> > >> When A has a LL only, we would have to have, not only discovery relaying, but > >> also response forwarding. So does B reply to C (to be relayed to A), or is > >> it a fail as B tries to connect to A's LL address, and does not connect? > >> > >> > >> >> >> In the 6tisch case doing multicast is either expensive or unsupported. > >> >> >> On the other hand, we can quite easily declare that the 6LBR / > >> >> >> DODAG-root (the router at the top of the tree) will have > >> >> >> GRASP_LISTEN_PORT open. > >> >> > >> >> > Yes, you have topology knowledge in that case. > >> >> > >> >> Do you agree that a discovery("C") sent to C over TCP should be answered > >> >> over that TCP connection? > >> > >> > Oh yes, and that is what should happen under the covers in any case, if discovery > >> > is running over the ACP. > >> > >> > However, I'm not convinced that we should document this (unicast discovery). > >> > At least not yet. > >> > >> When? I feel that this is important behaviour that needs to be defined for > >> the GRASP core system. > >> > >> > >> -- > >> Michael Richardson , Sandelman Software Works > >> -= IPv6 IoT consulting =- > >> From nobody Mon Oct 31 18:22:19 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7258129AF3 for ; Mon, 31 Oct 2016 18:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuDIaCALpCeh for ; Mon, 31 Oct 2016 18:22:17 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BED129477 for ; Mon, 31 Oct 2016 18:22:16 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id s8so85357687pfj.2 for ; Mon, 31 Oct 2016 18:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=h0aNuhUYkRqK016+PdjBXQF6wGyA/ZVhrWRlCWuGOog=; b=NmOoJjJlpv2x2r1vmuNeFwEaMZo1BP4EpkHyXSWj3SN6Oe12dyXo6xTeqhI4aldKyv jP2M4hSFweyyCyTNPz6Dqt9IwJrDXo/gbcI9XzuHnJGsJ4HP4d1HeV9nZ+FlfPNjloEk 7FLf2BqlGO/OAcqJimkYLupA4KIVBbyLeQA9EwJdEQUjj3Kkaw78m9WRGQKFeq+7kNtx RgfaDU7+WXttcJFGI9LyHfh6UWqfWy+dbMptwhMJfCf8bARJbGc11kr6cjZ4FyChvSz0 5i89MpC3K96m7D5iZ79br08FS/mNGtuOc98XOrjqqiOAjgVh+2XZqxR9xBd0739AD6Lk zpdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=h0aNuhUYkRqK016+PdjBXQF6wGyA/ZVhrWRlCWuGOog=; b=IlRR0wbCUGuXW8PhjjAwdRwHrCnBxV/IzXPyLZ10uZNXdR+om/7froHAdXhhkO3aGJ gWCpNQ6oEbtl23u49V9wpiWH0WcmjpJl2D1doTDuI/FcDagWkMiewiE7pUIZGzcSHB2a zXCswWcIHJDntwJjAkW6EHnUOwrWJNjNwTLIUhLAyG1z0narhEmtjw53bYzAAU6dvOXV IWSbMeY4Bg4J3LzcIovHBXQRzikPjqRVRUvCYEsUqhtXu9N3COfwn5TnNSS/ovYyPYh6 L3x5abEg/gjeuaJtDHqfslDuyfD1DDb8hH3CrRbr+o/i+br5EjSUxL7c4ntt+cL6gK2a lASA== X-Gm-Message-State: ABUngvdY9H1G+kwFkAh0brLtkUnFgeHrY3nmhFgqXDSPXkWJhO4SlMa3LvgoIIDEf11eAQ== X-Received: by 10.99.61.10 with SMTP id k10mr45827694pga.142.1477963336395; Mon, 31 Oct 2016 18:22:16 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id 73sm38092235pfn.45.2016.10.31.18.22.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 18:22:15 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 1 Nov 2016 14:22:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP API status X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 01:22:19 -0000 Hi, We haven't updated draft-liu-anima-grasp-api for this meeting, or requested an agenda slot for it. It didn't need any significant changes for the -08 version of GRASP. However, we (the authors) believe that this is essential work and we definitely intend to improve the document and request its adoption when the WG charter permits. Regards Brian From nobody Mon Oct 31 18:33:14 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53691129477 for ; Mon, 31 Oct 2016 18:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWPMB4Si59WH for ; Mon, 31 Oct 2016 18:33:10 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623FA1293DA for ; Mon, 31 Oct 2016 18:33:10 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id s8so85517890pfj.2 for ; Mon, 31 Oct 2016 18:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:organization:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=pujuYfx2ede0w5EmbGaA5bAkvWiTA639XUHP2UTg8kc=; b=qjvctupSXac5AG1kjqXtixXNflh0Nk8WTUGTJqgdTaC2785J2M31AbBEmNO82P4VXI 84PRGufKoBZFmTK4ltwBcZR0CycwJTdY4tkFtVCQ3Dzegdd1iXdbLCALdB9Kqwfd6HIE O6TQ+cBDBlxJAMaO3sBy74/dnscpwH/29rWjXwM/8c9UnH5CxN7cg+mMFmBQmvT4AORD A8V/EgsqXlJ294Rng2PFuYsYRhN85rrcwvRpYRtBOTFOch7q2DmPkn+Fx9QJjqErqYOK 6MA/l4ylHi+5gEde+6BEqQphUeIPar/b1xm0DifU3GrNuAYhoHOBeYr9++UlvKMnpWId NL4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:organization:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=pujuYfx2ede0w5EmbGaA5bAkvWiTA639XUHP2UTg8kc=; b=lHp83AFn/t9lJPuc40u1M/I1Ms+yWZnd3U99p7E3fW1FPbKd0AWxG5cwF3QtfaPvSJ 9cElvuNVj+Q1BEuC1A8W+NprNgog0VIvwGUZM4qgczK2b5yQ/ekntWVO0xG+ZLbpgf7t jR+XTy/jV3nFU/vNdhgRYlpaPlqxdfT60vg3XWSGXXu+j8e17yLoBC7rdp6a4WvsGFMN q8SiJAPEsfW9Xcz5+POttH6hbgZqWqvvrjFgDdZoLQjdizUusl2ZdoEMTbvLyLWUdnq0 NIBNFNdnLUVrstIgbpj3LD08abvGOIe+jA9ao2ahBj94RvRA9AkHXUL6LOD9cBSXFEb1 wlHA== X-Gm-Message-State: ABUngvep7x0dJ5Eox2e9W7kkWoY58hb/+A+bAqlzftd7Y217dASPs6b2BQOTXfcwX5EBBw== X-Received: by 10.98.78.68 with SMTP id c65mr55289133pfb.43.1477963989390; Mon, 31 Oct 2016 18:33:09 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id s85sm38172358pfi.17.2016.10.31.18.33.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 18:33:08 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 1 Nov 2016 14:33:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Autonomic prefix management X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 01:33:12 -0000 Hi, We haven't updated draft-ietf-anima-prefix-management for this meeting and haven't requested a slot for it. However, it's important work that needs to be finished. At the moment, the main issue is that the section on Intent needs to be improved. 1) It uses some made-up notation for Intent. The WG probably needs to make a decision about how to write down Intent. Personally I think the arguments for using YANG are very strong, but of course that needs a discussion. 2) It makes an assumption that the relevant Intent is distributed as a dedicated GRASP objective called "Intent.PrefixManager". We don't actually have agreement on that approach to distributing Intent. 3) It assumes a certain specific level of detail for Intent, down to statements like {"prefix_length": "34"}. I have no idea if there is consensus that this is the right level of detail. (However, if not, the question is open how the prefix manager would decide what length of prefix to assign.) I think the authors need feedback before can continue work on this. Regards Brian