From nobody Mon Nov 3 02:11:34 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E5F1A0055 for ; Mon, 3 Nov 2014 02:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQrxN9cT1ZWU for ; Mon, 3 Nov 2014 02:11:28 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0FF1A0053 for ; Mon, 3 Nov 2014 02:11:28 -0800 (PST) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 1A8B440BFF for ; Mon, 3 Nov 2014 11:11:27 +0100 (CET) Message-ID: <545754CE.2050508@restena.lu> Date: Mon, 03 Nov 2014 11:11:26 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: opsawg@ietf.org References: In-Reply-To: OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lwdqmBak0XcM7w87DbAfWJjCSm4KO8Ifc" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/W9QZQdCg3t4jAmJMCNT_t2m_OWQ Subject: Re: [OPSAWG] Agenda time in Hawaii... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 10:11:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lwdqmBak0XcM7w87DbAfWJjCSm4KO8Ifc Content-Type: multipart/mixed; boundary="------------010502080109040601080203" This is a multi-part message in MIME format. --------------010502080109040601080203 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > A reminder to please send us your requests for agenda time for the > upcoming meeting. >=20 > We give priority to documents that have outstanding issues, then those > that have gotten a lot of discussion. Just before the cutoff, I submitted an updated draft on the eap-metadata sepcification (see below). As discussed in the IETF89 opsawg meeting, and announced on my IETF90 slides (thanks for flashing the slides, and sorry I couldn't be there), we have changed course from an XML-based specification towards a YANG module to express properties of the EAP protocol for any particular deployment of EAP. I would like to present the -01 draft at IETF91 if there's still some time on the agenda for it. Greetings, Stefan Winter A new version of I-D, draft-winter-opsawg-eap-metadata-01.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Name: draft-winter-opsawg-eap-metadata Revision: 01 Title: A Configuration File Format for Extensible Authentication Protocol (EAP) Deployments Document date: 2014-10-27 Group: Individual Submission Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-winter-opsawg-eap-metadata-01.t= xt Status: https://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ Htmlized: http://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-winter-opsawg-eap-metadata-01 Abstract: This document specifies a YANG module and derived XML and JSON file formats for transfering configuration information of deployments of the Extensible Authentication Protocol (EAP). Such configuration files are meant to be discovered, consumed and used by EAP supplicant software to achieve secure and automatic EAP configuration on the consuming device. --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------010502080109040601080203 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------010502080109040601080203-- --lwdqmBak0XcM7w87DbAfWJjCSm4KO8Ifc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJUV1TPAAoJEMDeajWKOdxm2a8P/0Ob+98+V84BkiXPnNJI9dOH dcAht22DgjmZvvq1sKEsnUQf2NXAAnK64sbh4hYEwqG7z3wOPv/sTw3S5bymFXEV e2p9JxapEXxRWzZ+YfpoYLEvE3IZDhZVIvb+PKi7JqbEK4VX9bToU1cirQory3lw F0HPFzLme4zoXqos68MnXS/t/trvUTWrEjRgJ8SBR5Q4w4COr21uf3OxvtZySEmm AF6acNTFeMhzQ48F+SVqDYxngfwsR2bg0g0/QDXhUtrX69nHqwZR35fzaxtDzkaP E4LMhb3gsg5agA69GrIOMKnllgKw8QAHoDtnilKHvS0vttMTK5L6TWdMD2oezmBv EhEvyW1DGdrZ5jsuoQKdj6AbWsBOFTI285tJUoxHZk0y9l1XB7T/wHoKDeBjpqGU vA/hTRhJ/Vp6JSEoVJv7GeQXgyNfjO/F1ME5ikS4Jj2xQnL9bV+KZ7xqoYEib4Ra SeWE8JHkHCpZMcXmc8n0Jldj+J3khGqitr/MOWEdQW2R2VgtFtgdNlYr5dC1+zML TVpk9p/eVzVjxwwlv3E69gsOXAci8ngyQDM0L+TkvD/dur07l1B2rSYJuGjKd12O JplDD+uBdcOGYCWxei1qCtdPw/Rz/ZIUQlPZnmDuVIgD5chHHqVr+r0oI0HGV/a5 5++MVT9O3y1kSjno/u8u =oSNE -----END PGP SIGNATURE----- --lwdqmBak0XcM7w87DbAfWJjCSm4KO8Ifc-- From nobody Mon Nov 3 03:02:46 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FAF1A007F for ; Mon, 3 Nov 2014 03:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE0ENKCObc21 for ; Mon, 3 Nov 2014 03:02:42 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0C01A007C for ; Mon, 3 Nov 2014 03:02:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 14E15953599; Mon, 3 Nov 2014 06:03:04 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3epGDjZ-NsDq; Mon, 3 Nov 2014 06:03:03 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 09192953583; Mon, 3 Nov 2014 06:03:03 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Scott O. Bradner" In-Reply-To: <545754CE.2050508@restena.lu> Date: Mon, 3 Nov 2014 06:02:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <06A6F660-6918-4870-9887-5955B811B65F@sobco.com> References: <545754CE.2050508@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/tlpa5mraqcW5v21T7ZjjeaXNSPo Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Agenda time in Hawaii... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 11:02:44 -0000 we do not provide agenda time for people to =93present drafts=94 if you want to talk about what the changes are between this version and = the previous version and what remaining issues/questions there might be then there is time Scott > On Nov 3, 2014, at 5:11 AM, Stefan Winter = wrote: >=20 > Hello, >=20 >> A reminder to please send us your requests for agenda time for the >> upcoming meeting. >>=20 >> We give priority to documents that have outstanding issues, then = those >> that have gotten a lot of discussion. >=20 > Just before the cutoff, I submitted an updated draft on the = eap-metadata > sepcification (see below). >=20 > As discussed in the IETF89 opsawg meeting, and announced on my IETF90 > slides (thanks for flashing the slides, and sorry I couldn't be = there), > we have changed course from an XML-based specification towards a YANG > module to express properties of the EAP protocol for any particular > deployment of EAP. >=20 > I would like to present the -01 draft at IETF91 if there's still some > time on the agenda for it. >=20 > Greetings, >=20 > Stefan Winter >=20 > A new version of I-D, draft-winter-opsawg-eap-metadata-01.txt > has been successfully submitted by Stefan Winter and posted to the > IETF repository. >=20 > Name: draft-winter-opsawg-eap-metadata > Revision: 01 > Title: A Configuration File Format for Extensible = Authentication > Protocol (EAP) Deployments > Document date: 2014-10-27 > Group: Individual Submission > Pages: 19 > URL: > = http://www.ietf.org/internet-drafts/draft-winter-opsawg-eap-metadata-01.tx= t > Status: > https://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ > Htmlized: > http://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-winter-opsawg-eap-metadata-01 >=20 > Abstract: > This document specifies a YANG module and derived XML and JSON file > formats for transfering configuration information of deployments of > the Extensible Authentication Protocol (EAP). Such configuration > files are meant to be discovered, consumed and used by EAP = supplicant > software to achieve secure and automatic EAP configuration on the > consuming device. >=20 >=20 >=20 >=20 > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me >=20 > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66= > <0x8A39DC66.asc>_______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Nov 5 23:27:19 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988D51A0178 for ; Wed, 5 Nov 2014 23:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKUjQp5ziQ7z for ; Wed, 5 Nov 2014 23:27:11 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC621A1A99 for ; Wed, 5 Nov 2014 23:08:48 -0800 (PST) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9EDCF40CA5; Thu, 6 Nov 2014 08:08:25 +0100 (CET) Message-ID: <545B1E69.4020402@restena.lu> Date: Thu, 06 Nov 2014 08:08:25 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Scott O. Bradner" References: <545754CE.2050508@restena.lu> <06A6F660-6918-4870-9887-5955B811B65F@sobco.com> In-Reply-To: <06A6F660-6918-4870-9887-5955B811B65F@sobco.com> OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n1VhjpghujHpGpKVaN9B1DauekI6aVAnT" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Ap1RIoW-GYuSkN8qs_jocZJUiGY Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Agenda time in Hawaii... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 07:27:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n1VhjpghujHpGpKVaN9B1DauekI6aVAnT Content-Type: multipart/mixed; boundary="------------050106070802060208090202" This is a multi-part message in MIME format. --------------050106070802060208090202 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > we do not provide agenda time for people to =93present drafts=94 >=20 > if you want to talk about what the changes are between this version and= the previous version and > what remaining issues/questions there might be then there is time That's what I meant... update folks on the changes between -00 and -01; and ask about a possible future for the draft (=3Dadoption?) Greetings, Stefan Winter >=20 > Scott >=20 >> On Nov 3, 2014, at 5:11 AM, Stefan Winter w= rote: >> >> Hello, >> >>> A reminder to please send us your requests for agenda time for the >>> upcoming meeting. >>> >>> We give priority to documents that have outstanding issues, then thos= e >>> that have gotten a lot of discussion. >> >> Just before the cutoff, I submitted an updated draft on the eap-metada= ta >> sepcification (see below). >> >> As discussed in the IETF89 opsawg meeting, and announced on my IETF90 >> slides (thanks for flashing the slides, and sorry I couldn't be there)= , >> we have changed course from an XML-based specification towards a YANG >> module to express properties of the EAP protocol for any particular >> deployment of EAP. >> >> I would like to present the -01 draft at IETF91 if there's still some >> time on the agenda for it. >> >> Greetings, >> >> Stefan Winter >> >> A new version of I-D, draft-winter-opsawg-eap-metadata-01.txt >> has been successfully submitted by Stefan Winter and posted to the >> IETF repository. >> >> Name: draft-winter-opsawg-eap-metadata >> Revision: 01 >> Title: A Configuration File Format for Extensible Authentication >> Protocol (EAP) Deployments >> Document date: 2014-10-27 >> Group: Individual Submission >> Pages: 19 >> URL: >> http://www.ietf.org/internet-drafts/draft-winter-opsawg-eap-metadata-0= 1.txt >> Status: >> https://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ >> Htmlized: >> http://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-winter-opsawg-eap-metadata-01= >> >> Abstract: >> This document specifies a YANG module and derived XML and JSON file >> formats for transfering configuration information of deployments of >> the Extensible Authentication Protocol (EAP). Such configuration >> files are meant to be discovered, consumed and used by EAP supplican= t >> software to achieve secure and automatic EAP configuration on the >> consuming device. >> >> >> >> >> --=20 >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et >> de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> >> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the >> recipient's key is known to me >> >> http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC= 66 >> <0x8A39DC66.asc>_______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------050106070802060208090202 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------050106070802060208090202-- --n1VhjpghujHpGpKVaN9B1DauekI6aVAnT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUWx5pAAoJEMDeajWKOdxmoBsP/0AGKTLc/3GM/LazOSr6g06+ wdKN5R69bdz/rdWnwhO/fYQFxw4YMBtvbb/EJzHJ8l0Yaj+AYSoCV5F1YJz1zfvn QG3cwNZwrtMADjs80Ivf+vw6MHI7eNRifJeLnTUd4WKlcPdX8na3dT6/mzzR4Uzq 7pjZSyr0PPFEgAwXemUvm/IlV/jVGDMTyllBs7CSUGOFiPD/nJPB9//keXsAgJKx eosTIOVwe3SuR/qp808n4sx8YQ1cSFXNSaNwk/bzchDB2xx+RADZHJuiMlOrbiI3 i3ypC7kQzz/2Bg1FoE32VP8p1oWi0Az6LILWFrZhsT6mOHvarczPazPYKUR6AEdp ET0z+Iina33vTadoGtR4Wfs8I92QpoeCFnHOQRqWxzIw5xFE37hLIb2pB2bFkSnZ UPG6Y+FbfsZh+mel8TNh1AXWOHnCFbgMq5mz5j//XYT5dX1s6eHXgpgVSMkce8bj vf+YDDtzhWeMHVGv7ZlTG6uTKgXqwNz8yWK5VCcBLYp7Qn4W5W/J599eWCZR4pHs 2VAQu/Q1C4Ri26KXm6en9zX7+XFaYZ/Yq0oH/VRzuhhaNabD32ew499TQECuyxtV +0mUUp1aDYtpw3ZWhF7YqVnE0rU6jb9EZJUK5fpDvoVwyH3X90y0ek1DTRg2nbFR NssZTPoKZWssMMNp6M90 =XOwV -----END PGP SIGNATURE----- --n1VhjpghujHpGpKVaN9B1DauekI6aVAnT-- From nobody Thu Nov 6 00:18:21 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7AE1A1A12; Thu, 6 Nov 2014 00:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgKfGuDrwb3Y; Thu, 6 Nov 2014 00:18:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C02E1A1A67; Thu, 6 Nov 2014 00:18:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, warren@kumari.net, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141106081819.5257.17549.idtracker@ietfa.amsl.com> Date: Thu, 06 Nov 2014 00:18:19 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/2m6DMBxz8nFUqte7uL0j50WAwQo Cc: iesg-secretary@ietf.org Subject: [OPSAWG] Last Call Expired: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 08:18:20 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Thu Nov 6 01:55:05 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60221A1AB4; Thu, 6 Nov 2014 01:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG_ry0T1YT-Z; Thu, 6 Nov 2014 01:55:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BAF1A1A1C; Thu, 6 Nov 2014 01:55:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: iesg-secretary@ietf.org, iesg@ietf.org, draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, warren@kumari.net, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141106095500.14995.96958.idtracker@ietfa.amsl.com> Date: Thu, 06 Nov 2014 01:55:00 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/PgkX0kOglLt1rnMYvAttboyomHw Subject: [OPSAWG] Telechat update notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:55:02 -0000 Placed on agenda for telechat - 2014-11-25 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ From nobody Thu Nov 6 01:55:32 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7341A1A1C for ; Thu, 6 Nov 2014 01:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLJluaQoP8BF; Thu, 6 Nov 2014 01:55:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D4B1A1ABB; Thu, 6 Nov 2014 01:55:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, warren@kumari.net, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141106095526.15789.37269.idtracker@ietfa.amsl.com> Date: Thu, 06 Nov 2014 01:55:26 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/kAjXIJtilri32OL2yExM1cPI6Jo Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:55:28 -0000 IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ From nobody Thu Nov 6 01:55:50 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23D21A1AB5 for ; Thu, 6 Nov 2014 01:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNFyfMSxbD64; Thu, 6 Nov 2014 01:55:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6D41A1A1C; Thu, 6 Nov 2014 01:55:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, warren@kumari.net, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141106095546.12031.67153.idtracker@ietfa.amsl.com> Date: Thu, 06 Nov 2014 01:55:46 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/5edXr2jqR40CEedCWtRAJGTVFqg Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 09:55:48 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ From nobody Thu Nov 6 16:06:08 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E831ACDA5; Thu, 6 Nov 2014 16:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 256Ruwu-glH0; Thu, 6 Nov 2014 16:06:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8909B1ACDA7; Thu, 6 Nov 2014 16:06:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141107000603.32045.5122.idtracker@ietfa.amsl.com> Date: Thu, 06 Nov 2014 16:06:03 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/3y6Q_tBL1l5EP0JhskbrittAVA4 Cc: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, opsawg-chairs@tools.ietf.org Subject: [OPSAWG] Barry Leiba's No Objection on draft-ietf-opsawg-mibs-to-ieee80231-01: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 00:06:05 -0000 Barry Leiba has entered the following ballot position for draft-ietf-opsawg-mibs-to-ieee80231-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As I can't find anything to complain about in this most straightforward of documents, I'll have to whine about stuff in the shepherd writeup. The feedback received was integrated and the feedbacker (sic) states he is happy with the changes. That should be "feederbackerer". And who you calling sic? Nope. No one cared What does Scott Bradner have to do with this? It's also in my favorite font... Wingdings? From nobody Mon Nov 10 02:16:56 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5D21A89B3; Mon, 10 Nov 2014 02:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPCIXE0Iu6lx; Mon, 10 Nov 2014 02:16:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DC21A8969; Mon, 10 Nov 2014 02:16:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141110101652.14810.79440.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 02:16:52 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/vOo8vhbmAPIpNB6qx5DXDtQdoyI Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-vmm-mib-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 10:16:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Management Information Base for Virtual Machines Controlled by a Hypervisor Authors : Hirochika Asai Michael MacFaden Juergen Schoenwaelder Keiichi Shima Tina Tsou Filename : draft-ietf-opsawg-vmm-mib-02.txt Pages : 57 Date : 2014-11-10 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-vmm-mib-02 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 Nov 10 11:49:54 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4991A1ACD04; Mon, 10 Nov 2014 11:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nH3ulOOlyyFy; Mon, 10 Nov 2014 11:49:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F5D1AC442; Mon, 10 Nov 2014 11:49:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141110194947.20568.26735.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 11:49:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/f0Ceb8C7fqhZx-dwva9PAxAY53E Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:49:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Alternate Tunnel Encapsulation for Data Frames in CAPWAP Authors : Rong Zhang Zhen Cao Hui Deng Rajesh S. Pazhyannur Sri Gundavelli Li Xue Filename : draft-ietf-opsawg-capwap-alt-tunnel-04.txt Pages : 13 Date : 2014-11-10 Abstract: Control And Provisioning of Wireless Access Points (CAPWAP) defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments encapsulating data frames to an entity other than the AC (for example to an Access Router (AR)) is desirable. Further, it may also be desirable to use different tunnel encapsulations to carry the stations' data frames. This document provides a specification for this and refers to it as Alternate tunnel encapsulation. The Alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for Alternate tunnel encapsulation during the discovery or join process and AC may select one of the supported Alternate Tunnel encapsulation types while configuring the WTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-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 Tue Nov 11 23:36:53 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFB51A6FAC for ; Tue, 11 Nov 2014 23:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdNhOz4aDfcV for ; Tue, 11 Nov 2014 23:36:45 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFF01A6F0D for ; Tue, 11 Nov 2014 23:36:45 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so13362899wgg.9 for ; Tue, 11 Nov 2014 23:36:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=tWPFKYrzU/RYMQxmkP04njL1UpDHLu9knF6t+jXvvXk=; b=YwpHnEoC/fQFHrrzityzHICiXh1Ny/DpqDNXyFFfxIJyqNmW81lEOhkqvAyIV4UjPn zV+AmWhV00pdS52TtYVuXJPKdAC491MZAV0OmAQiFGB9j2kEvr8C/lj9aOzsqzcHrrxD tAOnpKWensrm9snHrM3cfa/jW/wtW9PmJt1PWOZQYmINncnvzKDH9P6xmTbu9DGqs1CN 0RChI/iLVRoRUgNsa0OvH08jyVkZAKAedfg7GBovHcJjMGIQTVCop3SahmHeyHgSwKYa P1TyIv+ahpxMLeQfez4iEfUHm9BCF01smhxVwqZ+QycNhNe/e1JZvpIlEtB6RhnCtOPi 2hMw== X-Gm-Message-State: ALoCoQn4VW1U6DEb9tzPaOOi5+xh5YWL3SyFa+BHUbUGS4MQ0ax1GfMLYN6YKxgP22ndA/kTbk54 MIME-Version: 1.0 X-Received: by 10.194.93.168 with SMTP id cv8mr37369516wjb.114.1415777803926; Tue, 11 Nov 2014 23:36:43 -0800 (PST) Received: by 10.194.64.37 with HTTP; Tue, 11 Nov 2014 23:36:43 -0800 (PST) Date: Tue, 11 Nov 2014 21:36:43 -1000 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/SHiyiA7KSFDj0iFGYlRJLU9YyLg Subject: [OPSAWG] Scribe and notes takes. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 07:36:48 -0000 Hi there, Would anyone be willing to: A: scribe and B: Jabber? The agenda is fairly light, so you you can get easy brownie points :-) W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Nov 12 11:07:24 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F501A1AA7 for ; Wed, 12 Nov 2014 11:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6FGRscQSuPe for ; Wed, 12 Nov 2014 11:06:57 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0080.outbound.protection.outlook.com [207.46.100.80]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5A01ACEEA for ; Wed, 12 Nov 2014 11:05:49 -0800 (PST) Received: from SN2PR0601MB719.namprd06.prod.outlook.com (25.160.14.152) by BY2PR06MB598.namprd06.prod.outlook.com (10.141.222.17) with Microsoft SMTP Server (TLS) id 15.1.16.15; Wed, 12 Nov 2014 19:05:48 +0000 Received: from SN2PR0601MB719.namprd06.prod.outlook.com ([25.160.14.152]) by SN2PR0601MB719.namprd06.prod.outlook.com ([25.160.14.152]) with mapi id 15.01.0006.000; Wed, 12 Nov 2014 19:05:47 +0000 From: Chris Grundemann To: "OPSAWG@ietf.org" Thread-Topic: New Version Notification for draft-opsawg-operators-ietf-00.txt Thread-Index: AQHP8kBNF+/bGivo3EGOHGZ1UCgRiJxcyyyA Date: Wed, 12 Nov 2014 19:05:47 +0000 Message-ID: References: <20141027234652.7224.2180.idtracker@ietfa.amsl.com> In-Reply-To: <20141027234652.7224.2180.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [31.133.179.245] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR06MB598; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BY2PR06MB598; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(24454002)(377454003)(377424004)(51704005)(479174003)(99396003)(230783001)(110136001)(87936001)(19580395003)(86362001)(31966008)(2501002)(19580405001)(92726001)(2656002)(120916001)(15202345003)(92566001)(101416001)(15975445006)(4396001)(77156002)(64706001)(20776003)(66066001)(99286002)(95666004)(2351001)(107046002)(76176999)(106116001)(54356999)(21056001)(105586002)(46102003)(50986999)(62966003)(106356001)(77096003)(40100003)(36756003)(97736003)(122556002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB598; H:SN2PR0601MB719.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <880168016468ED42BA870F0C23466A7C@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/sWFylCSTfptv7gsDU0DVsTnWtIE Cc: Jan Zorz Subject: [OPSAWG] FW: New Version Notification for draft-opsawg-operators-ietf-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:07:07 -0000 Hail OpsAWG! My apologies for forwarding this so late. I do intend to ask the working group to adopt this as a WG item for continued discussion and documentation of the conclusions of that discussion. See you in the meeting this morning! Cheers, ~Chris On 10/27/14, 8:46 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-opsawg-operators-ietf-00.txt >has been successfully submitted by Chris Grundemann and posted to the >IETF repository. > >Name: draft-opsawg-operators-ietf >Revision: 00 >Title: Operators and the IETF >Document date: 2014-10-28 >Group: Individual Submission >Pages: 23 >URL: =20 >http://www.ietf.org/internet-drafts/draft-opsawg-operators-ietf-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ >Htmlized: http://tools.ietf.org/html/draft-opsawg-operators-ietf-00 > > >Abstract: > Internet Society has launched a new project to address the perceived > gap between Operators and the IETF. The objective of this project is > ultimately to facilitate communications between the operator > community and the IETF to help ensure that operational realities > inform the development of key standards. The first phase of this > project was a survey of the operator community that was conducted > over the first half of 2014. This I-D aims to synthesize the initial > survey results, along with information we collected directly from > operators during the survey window. The primary purpose of doing > this is to start a conversation which we hope will lead to increases > in the level of operational input and feedback to the IETF standards > making process. > > > =20 > =20 > > >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. > >The IETF Secretariat > From nobody Wed Nov 12 11:16:41 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9671A0369 for ; Wed, 12 Nov 2014 11:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiyCZCm9AG0G for ; Wed, 12 Nov 2014 11:16:34 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258811A0049 for ; Wed, 12 Nov 2014 11:16:31 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id r20so5973648wiv.10 for ; Wed, 12 Nov 2014 11:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sl9cdhkRVv0feZ05TJVMPNEnw4nEkoIq7SQxKwyLnLc=; b=IHlD4VxZicW/leuro/JqvRBz0zH0YLWdYLTedYfukLj+cFNVi8pf2aJYOdzfzBl2/Y W2+5JSKxLF38fybEkCrvmFNQ4YR1LYw9CMZ9SE9B0CTpcSCRm4Px9s5jSlTayiW7PC2b hSQu0tpmSo/4tHBXk3oiZFHk3UNAt4XQy7Bd4D5yM8veeeb1CsZno0yDNwSu2FSRJVHD JmUIJk8CrgDOAckH+2/ne5pRlfUMrr/945ypsHVCuvtGNfyY6pCrE8/xBXG5ePWosEoW 8dcBB8jrapf5smCJkAQ7T421estWzwngG6i+E8P8hISAKIl/qjI6/dr8MJ9PHjnVV/MD V4Mg== X-Received: by 10.180.106.103 with SMTP id gt7mr8530753wib.0.1415819789926; Wed, 12 Nov 2014 11:16:29 -0800 (PST) Received: from [31.133.163.84] (dhcp-a354.meeting.ietf.org. [31.133.163.84]) by mx.google.com with ESMTPSA id fa16sm22758402wid.5.2014.11.12.11.16.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 11:16:29 -0800 (PST) Message-ID: <5463B211.6060706@gmail.com> Date: Thu, 13 Nov 2014 08:16:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Chris Grundemann References: <20141027234652.7224.2180.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/xazzuggWxJLtKMiABhG3vkj7vpU Cc: "OPSAWG@ietf.org" , Jan Zorz Subject: Re: [OPSAWG] FW: New Version Notification for draft-opsawg-operators-ietf-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:16:36 -0000 Unfortunately I can't be in OPSAWG this morning, but I do think this draft is important and worrying (and should be discussed in plenary, because the entire IETF needs to worry about it). I'm all for adoption if that means quick publication and a follow-up action plan. Brian On 13/11/2014 08:05, Chris Grundemann wrote: > Hail OpsAWG! > > My apologies for forwarding this so late. I do intend to ask the working > group to adopt this as a WG item for continued discussion and > documentation of the conclusions of that discussion. See you in the > meeting this morning! > > Cheers, > ~Chris > > > On 10/27/14, 8:46 PM, "internet-drafts@ietf.org" > wrote: > >> A new version of I-D, draft-opsawg-operators-ietf-00.txt >> has been successfully submitted by Chris Grundemann and posted to the >> IETF repository. >> >> Name: draft-opsawg-operators-ietf >> Revision: 00 >> Title: Operators and the IETF >> Document date: 2014-10-28 >> Group: Individual Submission >> Pages: 23 >> URL: >> http://www.ietf.org/internet-drafts/draft-opsawg-operators-ietf-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ >> Htmlized: http://tools.ietf.org/html/draft-opsawg-operators-ietf-00 >> >> >> Abstract: >> Internet Society has launched a new project to address the perceived >> gap between Operators and the IETF. The objective of this project is >> ultimately to facilitate communications between the operator >> community and the IETF to help ensure that operational realities >> inform the development of key standards. The first phase of this >> project was a survey of the operator community that was conducted >> over the first half of 2014. This I-D aims to synthesize the initial >> survey results, along with information we collected directly from >> operators during the survey window. The primary purpose of doing >> this is to start a conversation which we hope will lead to increases >> in the level of operational input and feedback to the IETF standards >> making process. >> >> >> >> >> >> >> 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. >> >> The IETF Secretariat >> > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Fri Nov 14 20:16:58 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7FA1A0AC8 for ; Fri, 14 Nov 2014 20:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKeqA-rzZ1fq for ; Fri, 14 Nov 2014 20:16:55 -0800 (PST) Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6D58D1A00E2 for ; Fri, 14 Nov 2014 20:16:55 -0800 (PST) X-AuditID: 44571fa7-f79716d000006a1f-f2-5466d3b609d7 Received: from pacdcexhub05.cable.comcast.com (pacdcexhub05.cable.comcast.com [24.40.56.122]) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 98.32.27167.6B3D6645; Fri, 14 Nov 2014 23:16:54 -0500 (EST) Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.113]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.03.0181.006; Fri, 14 Nov 2014 23:16:54 -0500 From: "Brzozowski, John" To: "draft-opsawg-operators-ietf@tools.ietf.org" Thread-Topic: draft-opsawg-operators-ietf-00 Thread-Index: AQHQAIr9jGOdCycB8EyMC7Ea/u5gLw== Date: Sat, 15 Nov 2014 04:16:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUioWFRpbvtclqIwYmLNhZH5qdZrDi5mcmB yWPJkp9MHl8uf2YLYIritklKLCkLzkzP07dL4M74c4294ApXxfYPs5gaGDdwdTFyckgImEhs 6uxnhrDFJC7cW8/WxcjFISRwk1Fi+vTNzBDOIUaJ/Y0HWEGq2ARsJF5/+MkIYosIxEv0/m8B 6uDgYBZQl1jw0xckLAxkXv3RwAZRoiPRdmg/M4StJ3Gx4wGYzSKgKvF//g6wkbwC9hIPP99l B7EZgY74fmoNE4jNLCAucevJfCaI4wQkluw5D3WoqMTLx//AekWBZs57+IoNIq4g8etkAwvE OZoS63fpQ4xxkJjfcJMdwlaUmNL9kB1iraDEyZlPWCYwis1Csm0WQvcsJN2zkHTPQtK9gJF1 FaNcQWJySnJuRn5piYGhXnJiUk6qXnJ+bnJicQmI3sQIjDGXcPnlOxjvvXA6xCjAwajEw3th UlqIEGtiWXFlLjB8OZiVRHiFLgGFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8yov8AoREkhPLEnN Tk0tSC2CyTJxcIJ0c0mJFKfmpaQWJZaWZMSDoj2+GBjvUg2Mi5h77y85JXS2J7rIZuKr1Xft nH9O913pv+/Mx0OmNiVra7ay/Xz4Y6GtSECgafLezyumTnn7WmXBj1flOzLthWesKGHJcBCe L3txgivPTQuztQ+aTxp52vHy1PeE2VonL8m9UXn3yRvj3u6iS51GW/7aB1mef/kwr8d2seIV Hu/FS41rnxpEKbEUZyQaajEXFScCACUbxIPIAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/FJ5_I1LIozJVFAprzRNY8XGGUkg Cc: "opsawg@ietf.org" Subject: [OPSAWG] draft-opsawg-operators-ietf-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 04:16:56 -0000 Rmlyc3QsIHRoYW5rIHlvdS4gIFRoaXMgaXMgYSBuaWNlbHkgd3JpdHRlbiBkb2N1bWVudC4gIFRo ZSBwb3NzaWJsZQ0Kc29sdXRpb25zIHNlY3Rpb25zIGluY2x1ZGVzIHNldmVyYWwgaXRlbXMgdGhh dCBkaWQgbm90IGV2ZW4gY3Jvc3MgbXkgbWluZC4NCiBXaGlsZSB0aGUgcG9zc2libGUgc29sdXRp b25zIGFyZSBhIGdyZWF0IHN0YXJ0IEkgdGhpbmsgdGhlcmUgaXMgYSBsb3QNCm1vcmUgdG8gZG8g aW4gdGhlIHNvbHV0aW9uIHNwYWNlLiAgSSByZWNhbGwgZm91ciB5ZWFycyBhZ28gd2hpbGUgd2Ug d2VyZQ0KaW4gQmVpamluZyB3ZSBoYWQgYSB2ZXJ5IHNpbWlsYXIgZGlzY3Vzc2lvbiwgbm90IHN1 cmUgd2hlcmUgaXQgd2VudCBvciB3aHkNCndlIGRpZCBub3QgY29udGludWUgc29tZSBvZiB0aGUg d29yayB0byBpbnRlZ3JhdGUgb3BlcmF0b3IgZmVlZGJhY2sNCmJldHRlci4gIEl0IHNlZW1zIHRv IG1lIHdlIHZlcnkgd2VsbCBtYXkgbmVlZCB0byByZXZpc2l0IGFuZCByZXN0cnVjdHVyZQ0Kb3Vy IHByb2Nlc3NlcyBhbmQgaG93IHRoZSBJRVRGIG9wZXJhdGVzLiAgSSBmb3IgbG9vayBvbmUgd2ls bCBrZWVwIHRhYnMgb24NCnRoaXMgZHJhZnQgYWxvbmcgd2l0aCB3aGF0IHdlIGRvIG5leHQuICBU aGVyZSBpcyBhIGxvdCBvZiBtZWFuaW5nZnVsDQpmZWVkYmFjayBoZXJlIGZyb20gYSBmYWlybHkg bGFyZ2UgcG9wdWxhdGlvbiBvZiBvcGVyYXRvcnMsIHdlIHNob3VsZCBkbw0Kc29tZXRoaW5nIHdp dGggdGhpcyBpbmZvcm1hdGlvbi4NCg0KSm9obg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCkpvaG4gSmFzb24gQnJ6b3pvd3NraQ0KQ29tY2FzdCBDYWJsZQ0KbSkg NjA5LTM3Ny02NTk0DQpvKSA0ODQtOTYyLTAwNjANCncpIHd3dy5jb21jYXN0Ni5uZXQNCmUpIGpv aG5fYnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbQ0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg0KDQoNCg0K From nobody Mon Nov 17 07:24:34 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505131A6F6E; Mon, 17 Nov 2014 07:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0J3doEnVHzj; Mon, 17 Nov 2014 07:24:27 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5981A6F7F; Mon, 17 Nov 2014 07:24:27 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so2480535ieb.23 for ; Mon, 17 Nov 2014 07:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=R0emaK9uUx7E/ZCfCRWg6sCmqYDkSj8xz3ELtlAbXbM=; b=zwH1w5r7U59dRMofDpC1V8lEBWq7I03+jjmzqPRvdHBpNA/YkhroeUlL5OvN8BgWmj Fe/SGllyfQCxu15k53sK23IdieAztrDHIuqFfsW3m7/+CiBW91NJNNnr5EIuVsnkwv1E 1hyWdvme1CwSVJwDsxGAXeuIur03DQvcJtrlPi9LDUVp8Xb4a0+QDJukkcn5uurX59Ep t0buEPbyouxAFenmQBm2u5uL3bDY7FipVkMMGXkKUK1zblzlXvtgCWAwodhNsrQNvpP2 K5FIvFM2uaxAdnPt+8RNyOwb9TzzQ3s1XzT3QefBd3qpJjgyR5o65V3gzVluuIedK63a 0Dow== X-Received: by 10.42.142.201 with SMTP id t9mr2995030icu.60.1416237866493; Mon, 17 Nov 2014 07:24:26 -0800 (PST) Received: from [192.168.0.102] ([173.206.163.91]) by mx.google.com with ESMTPSA id rp2sm585835igb.0.2014.11.17.07.24.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 07:24:26 -0800 (PST) Message-ID: <546A1327.4090905@gmail.com> Date: Mon, 17 Nov 2014 10:24:23 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/8XGCCT9ZW-ZmnMIEouFN5wFXAMQ Subject: [OPSAWG] NAT MIB: Life cycle of objects and counter persistence X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 15:24:29 -0000 Natv2-MIB has few writable objects, only for control of notifications and setting of quotas. Thus the module assumes that other means are used to provision NAT instances and address pools and configure subscriber data. It seems likely that a mechanism such as the one used to maintain the integrity of references to ifIndex will be needed to protect references to NAT instance index, address pool index, and subscriber index, but that is another topic. The basic question is how persistent the counter values supported by the Natv2-MIB should be. Apparently past practice has been to say: "until the agent restarts", but that isn't really helpful when you are trying to debug a problem. I distinguish between a counter, which is cumulative, and a state object, which gives a snapshot at the moment of reporting. Would implementors support the following general statement? "Ideally, counter values are never reset while the parent object (NAT instance, address pool, subscriber) continues to exist, even across reboots. Individual implementations may not be able to guarantee this level of persistence, and SHOULD document the circumstances under which resets could occur. In any event, all implementations MUST report the time of last reset in the relevant object in the NAT instance, address pool, and subscriber tables." By "reset" I mean setting the counter back to zero. I think that is the proper action, because it makes discontinuities more obvious than resetting to a random value. No comments mean that I will go ahead with this proposal. Tom Taylor BACKGROUND In my present thinking, the conceptual tables in the MIB module come in two groups, device level, and NAT instance level: 1. Device level: indexed by subscriber index, not by instance index (to make it easier to reassign subscribers from one NAT instance on the device to another): natv2SubscriberTable -- contains per-subscriber counters natv2SubscriberIngressInterfaceClassifierTable -- configuration data only 2. Group indexed by NAT instance, meaningful only while the instance exists: natv2InstanceTable -- now incorporates the per-instance counters, thresholds, and limits that were in separate tables before natv2NextProtocolTable -- counters per protocol supported by the NAT instance natv2PoolTable -- counters per address pool natv2PoolRangeTable -- configuration data only natv2AddressMapTable -- state data only natv2PortMapTable -- state data only From nobody Mon Nov 17 08:11:55 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF30F1A6FDE; Mon, 17 Nov 2014 08:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWyTuxluy0lj; Mon, 17 Nov 2014 08:11:42 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233F71A6F9F; Mon, 17 Nov 2014 08:11:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7AA8758; Mon, 17 Nov 2014 17:11:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XTRw3rkS75EZ; Mon, 17 Nov 2014 17:11:31 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 17 Nov 2014 17:11:33 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D4D82002C; Mon, 17 Nov 2014 17:11:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SNi-j8UG97i3; Mon, 17 Nov 2014 17:11:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F28F620013; Mon, 17 Nov 2014 17:11:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ED51A2F885E7; Mon, 17 Nov 2014 17:11:31 +0100 (CET) Date: Mon, 17 Nov 2014 17:11:31 +0100 From: Juergen Schoenwaelder To: Tom Taylor Message-ID: <20141117161131.GA79448@elstar.local> Mail-Followup-To: Tom Taylor , "behave@ietf.org" , "opsawg@ietf.org" References: <546A1327.4090905@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546A1327.4090905@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/CFIIgvXziKnIH_zO-gNR8UeQE_8 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] [BEHAVE] NAT MIB: Life cycle of objects and counter persistence X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 16:11:51 -0000 Tom, please do not talk about a counter 'reset' or resetting a counter to zero. This is not how SNMP counters work. Instead, make it clear for every Counter what the discontinuity indicator is. See Section 7.1.6 of RFC 2578: Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content. Discontinuities in the monotonically increasing value normally occur at re- initialization of the management system, and at other times as specified in the description of an object-type using this ASN.1 type. If such other times can occur, for example, the creation of an object instance at times other than re-initialization, then a corresponding object should be defined, with an appropriate SYNTAX clause, to indicate the last discontinuity. Examples of appropriate SYNTAX clause include: TimeStamp (a textual convention defined in [3]), DateAndTime (another textual convention from [3]) or TimeTicks. The default discontinuity indicator is sysUpTime. If NAT instances can come and go dynamically, you want to specify other discontinuity indicators. /js On Mon, Nov 17, 2014 at 10:24:23AM -0500, Tom Taylor wrote: > Natv2-MIB has few writable objects, only for control of notifications > and setting of quotas. Thus the module assumes that other means are used > to provision NAT instances and address pools and configure subscriber > data. It seems likely that a mechanism such as the one used to maintain > the integrity of references to ifIndex will be needed to protect > references to NAT instance index, address pool index, and subscriber > index, but that is another topic. > > The basic question is how persistent the counter values supported by the > Natv2-MIB should be. Apparently past practice has been to say: "until > the agent restarts", but that isn't really helpful when you are trying > to debug a problem. I distinguish between a counter, which is > cumulative, and a state object, which gives a snapshot at the moment of > reporting. > > Would implementors support the following general statement? > > "Ideally, counter values are never reset while the parent object (NAT > instance, address pool, subscriber) continues to exist, even across > reboots. Individual implementations may not be able to guarantee this > level of persistence, and SHOULD document the circumstances under which > resets could occur. In any event, all implementations MUST report the > time of last reset in the relevant object in the NAT instance, address > pool, and subscriber tables." > > By "reset" I mean setting the counter back to zero. I think that is the > proper action, because it makes discontinuities more obvious than > resetting to a random value. > > No comments mean that I will go ahead with this proposal. > > Tom Taylor > > > > BACKGROUND > > In my present thinking, the conceptual tables in the MIB module come in > two groups, device level, and NAT instance level: > > 1. Device level: indexed by subscriber index, not by instance index (to > make it easier to reassign subscribers from one NAT instance on the > device to another): > > natv2SubscriberTable > -- contains per-subscriber counters > natv2SubscriberIngressInterfaceClassifierTable > -- configuration data only > > 2. Group indexed by NAT instance, meaningful only while the instance exists: > > natv2InstanceTable > -- now incorporates the per-instance counters, thresholds, and > limits that were in separate tables before > natv2NextProtocolTable > -- counters per protocol supported by the NAT instance > natv2PoolTable > -- counters per address pool > natv2PoolRangeTable > -- configuration data only > natv2AddressMapTable > -- state data only > natv2PortMapTable > -- state data only > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Nov 17 08:33:28 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD61A6FFE; Mon, 17 Nov 2014 08:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXIkDYzUbEJI; Mon, 17 Nov 2014 08:33:23 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C23C1A6FE9; Mon, 17 Nov 2014 08:33:23 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so2725854ieb.9 for ; Mon, 17 Nov 2014 08:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YFx1aHec9/XF0VpkdJLVinxtSwGO5u6nrNiRDNjN5O0=; b=QgiH75D8cbX3o9rY+u9Vwo97ySqDdxn8xCMyeKh2KEqjkoptMnMYYB3rsHC/b6twcR OrSt72RPo4oZN7hsAJg/j9Wy9E0TaRn7yvKKrygjakbBAxnSAqtUbJjr41aI7V8mGGiA 1P186ZTun4wnMp2bO+U4Z/uJijB1mUFj+/CwbLXh4wB2gNkgNO86OAZmtywiHBJLS0GF Fevu4py5aZhpeS2lBbr5W5jJqwHBKJ/yCNRpebCkSBekbMyt6rTlox5zUQj8vjcQ6bB6 8Ame/oG3wVTlCP0qbnM9aoHHAnDPWAbJwqXu8qR4GXpCf4Qpc4YXZ4EO22ujxP42Qc20 Ujhw== X-Received: by 10.50.142.33 with SMTP id rt1mr27018772igb.12.1416242002700; Mon, 17 Nov 2014 08:33:22 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-163-91.tor.primus.ca. [173.206.163.91]) by mx.google.com with ESMTPSA id mf8sm6159829igb.22.2014.11.17.08.33.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 08:33:22 -0800 (PST) Message-ID: <546A2353.6000403@gmail.com> Date: Mon, 17 Nov 2014 11:33:23 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" , Juergen Schoenwaelder References: <546A1327.4090905@gmail.com> <20141117161131.GA79448@elstar.local> In-Reply-To: <20141117161131.GA79448@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/kRABRHGTuyH7vpayjtkDsxPYf-I Subject: Re: [OPSAWG] [BEHAVE] NAT MIB: Life cycle of objects and counter persistence X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 16:33:25 -0000 OK On 17/11/2014 11:11 AM, Juergen Schoenwaelder wrote: > Tom, > > please do not talk about a counter 'reset' or resetting a counter to > zero. This is not how SNMP counters work. Instead, make it clear for > every Counter what the discontinuity indicator is. See Section 7.1.6 > of RFC 2578: > > Counters have no defined "initial" value, and thus, a single value of > a Counter has (in general) no information content. Discontinuities > in the monotonically increasing value normally occur at re- > initialization of the management system, and at other times as > specified in the description of an object-type using this ASN.1 type. > If such other times can occur, for example, the creation of an object > instance at times other than re-initialization, then a corresponding > object should be defined, with an appropriate SYNTAX clause, to > indicate the last discontinuity. Examples of appropriate SYNTAX > clause include: TimeStamp (a textual convention defined in [3]), > DateAndTime (another textual convention from [3]) or TimeTicks. > > The default discontinuity indicator is sysUpTime. If NAT instances can > come and go dynamically, you want to specify other discontinuity > indicators. > > /js > ... From nobody Mon Nov 17 10:44:52 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44981A87AE; Mon, 17 Nov 2014 10:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niipYzDpM0PO; Mon, 17 Nov 2014 10:44:47 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28111A88C7; Mon, 17 Nov 2014 10:43:29 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tr6so3489222ieb.36 for ; Mon, 17 Nov 2014 10:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=8VZaIdaBU7WD6WHX8lf9eR+bCv9hWNdIaDodHj6yui4=; b=i9KbBIbfkeYybm+QOwN8zMBg1VBcAtgFtPZi678rDysNYkz2e+l9LZyPu1iLZJrRg6 9nlcnPFNS6JIpuFsf5lJOzrlLOdk9hGCKudHZGV4vjbDHF3Y6064q7jV4Wxa2fAhRGJb JB4HRyPBY/QOfj6TfGfdiYZYwvOHzzW5fozpEI9ZXgtaPpBBZwn6xcnYkjlV9KfMhsO7 jG7PcSFXKrlrLUXqT+9BIaBrcHcGIz3I8/DaFPEgRV9vzvdJO+6c8uavxYlgbU3+paKO Bu/IZ42SddIxzZddUD4x8zd41iiycWro9jVREwgzxg2fPlrR41HDIYxaBxqjlcRAxAU+ PAJg== X-Received: by 10.51.16.37 with SMTP id ft5mr27662333igd.6.1416249809052; Mon, 17 Nov 2014 10:43:29 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-163-91.tor.primus.ca. [173.206.163.91]) by mx.google.com with ESMTPSA id w197sm19256650iod.24.2014.11.17.10.43.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 10:43:28 -0800 (PST) Message-ID: <546A41D2.4040009@gmail.com> Date: Mon, 17 Nov 2014 13:43:30 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/j3X9xNxoKkgEDv_cktfbuyiVvuk Subject: [OPSAWG] NAT MIB: meaning of indexes for NAT instance, address pool, and subscriber X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 18:44:49 -0000 As I understand it, NAT instances, address pools, and subscribers could all be provisioned (and deleted) dynamically. To ensure that a given index value continues to point to information for the same object assuming that object continues to exist, I propose the following rules (adapted from RFC 2863, Interfaces MIB and taking into account the proposal in my previous E-mail): 1. The index value for a given object instance MUST remain constant between events that cause the discontinuity time for that object to be updated. (The interfaces MIB module requires constancy at least between reinitializations of the management system.) 2. After the object instance is dynamically removed, its index value MUST NOT be re-used by a *different* dynamically added object instance until after the following re-initialization of the network management system. (Same constraint as the interfaces MIB module.) DiscontinuityTime objects were part of the previous proposal and will be assumed here, since they are part of the ifIndex solution. Question to operators: should there be objects giving: -- total number of object instances (e.g., subscribers) provisioned -- next available index value -- I expect particularly useful for subscribers Comments? Tom Taylor From nobody Tue Nov 18 07:00:55 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376121A19F3 for ; Tue, 18 Nov 2014 07:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSZ3aB8YnK-T for ; Tue, 18 Nov 2014 07:00:45 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E141A19EB for ; Tue, 18 Nov 2014 07:00:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 286E5F60 for ; Tue, 18 Nov 2014 16:00:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 78S0-uYZ-d9p for ; Tue, 18 Nov 2014 16:00:31 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 18 Nov 2014 16:00:40 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E2C120017 for ; Tue, 18 Nov 2014 16:00:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id liDd6ooH65oa; Tue, 18 Nov 2014 15:58:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4687720013; Tue, 18 Nov 2014 16:00:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 778B72FA3B6D; Tue, 18 Nov 2014 16:00:38 +0100 (CET) Date: Tue, 18 Nov 2014 16:00:37 +0100 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20141118150037.GB88064@elstar.local> Mail-Followup-To: opsawg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/lnW-KbNISYFbf4tOplglF95UO7k Subject: [OPSAWG] document status X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 15:00:49 -0000 Hi, since I could not follow the meeting in Honolulu, can I please get a clarification where we are with these WG documents? - https://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-03 This I-D was apparently sent to the IESG on 2014-10-30. So the token is with Benoit and I understand that Warren is the document shepherd. - https://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-03 This I-D is still a WG document. What are the next steps and who holds the token? Who is going to be the document shepherd? - https://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-02 This I-D is still a WG document. What are the next steps and who holds the token? Who is going to be the document shepherd? I just want to make sure it is clear who has to take the next action so that we can wrap up things in a timely manner. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Nov 19 11:50:29 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2732C1A6F61 for ; Wed, 19 Nov 2014 11:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.349 X-Spam-Level: X-Spam-Status: No, score=-12.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_IMAGE_SPAM_HTML=0.81, DC_IMAGE_SPAM_TEXT=0.242, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Snilxl8lacd for ; Wed, 19 Nov 2014 11:50:19 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7141A6F02 for ; Wed, 19 Nov 2014 11:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29663; q=dns/txt; s=iport; t=1416426619; x=1417636219; h=message-id:date:from:mime-version:to:cc:subject; bh=ZaadmsxszJl/JQzO7+/1lSfMRJqsFgYa5qIY6YxreG0=; b=jgmb2WzaBvQktP6RTUb7vYvA5c1R287M16VLdtMTShF7I+bco/MHF7cA fb7+SNsXQvUMC54q2OgBE5Oyq2/4xIm05DBHC4UoIiBNitKOt3goKftcj hwrcKrCnZnGotvodf/F++TJDBj7zoDL/jAPtqUaDwSF1Jg0ZbV2I+CibP M=; X-Files: bgfaccjg.png : 19447 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoTAC70bFStJV2d/2dsb2JhbABagkoEQFVZhHu2NpByL4EihXaBChYBAQEBAX2EDm0HHAECARgBAQEBGg0NAgYBDjcBDAEEAQIBAQIViCYN1EUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkQiEUgWSAoRIAWqHLIFwhhGFJolUgjaBRjwwAYJKAQEB X-IronPort-AV: E=Sophos;i="5.07,418,1413244800"; d="png'150?scan'150,208,217,150";a="98243768" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 19 Nov 2014 19:50:17 +0000 Received: from [10.21.116.249] (sjc-vpn2-1273.cisco.com [10.21.116.249]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sAJJoD0k028368; Wed, 19 Nov 2014 19:50:15 GMT Message-ID: <546CF473.70201@cisco.com> Date: Wed, 19 Nov 2014 20:50:11 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" Content-Type: multipart/alternative; boundary="------------000109040106050907030608" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/auJFzaiBl6ZJwxsfLcOEBcfMn_k Cc: "opsawg@ietf.org" Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:50:22 -0000 This is a multi-part message in MIME format. --------------000109040106050907030608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear CAPWAP authors, After the draft-xue-opsawg-capwap-alt-tunnel-information presentation at the last IETF meeting, I've been wondering about the relationship between the two drafts: - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types Note:this draft is currently in AD review, so close to be sent to the IESG. - draft-xue-opsawg-capwap-alt-tunnel-information provides the encoding of the tunnel-specific fields. I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel doesn't provide a complete solution without draft-xue-opsawg-capwap-alt-tunnel-information? I'm aware of the changes between version 3 and 4 (attached picture and http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-04.txt) But now I wonder: why do we have two different drafts, as opposed to a single one? Regards, Benoit --------------000109040106050907030608 Content-Type: multipart/related; boundary="------------060805070008030306070203" --------------060805070008030306070203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear CAPWAP authors,

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

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

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

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

Regards, Benoit


--------------060805070008030306070203 Content-Type: image/png; name="bgfaccjg.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bgfaccjg.png" iVBORw0KGgoAAAANSUhEUgAABxoAAACzCAIAAAAxAI48AAAgAElEQVR4nO2dO5LbuPe2uYlJ XOVy0lUKJnbkpCdWQmczqfNx0JkVO/i8AQcdW8l/CxP0Bn7airfQX6AbLucAByQogOrnqbfK ZYkCDy4EgbdBcPgNAAAAAFDCKwAAAADAW2VoPRoHAAAAgJXRegQLAAAAANAM7FQAAAAAKKP1 CBYAAAAAoBnYqQAAAABQRusRLAAAAABAM7BTAQAAAKCM1iNYAAAAAIBmYKcCAAAAQBmtR7AA AAAAAM3ATgUAAACAMlqPYAEAAAAAmoGdCgAAAABltB7BAgAAAAA0AzsVAAAAAMpoPYIFAAAA AGgGdioAAAAAlNF6BAsAAAAA0AzsVAAAAAAoo/UIFgAAAACgGXdop748PQzDMDw8vZT8YPu8 aFBd87y1FNepXC8IJdZhSdryti6et8lauMnJZ5WpmwE5rQ5bEhi4x8utOqstJMMt4M4oHky8 OVqPYNfCYbcZhmHY7A4lPxj3iwbVNfvRVFz70euThF90WJLGvK2KUwvXamFZTq1g1nlX2ZLA wD1ebtVZbeN2O55hWGceyigeTMBNWJmdGs7nNFPm5ekBO9WMZXr/vLU6rrcoyeet9TSrtS4s 2IuhLkWXl/DjfNRv/ppcKXd6udW90FZaSKZbwB0yq7e7e1qPYHsgnM9ppsxht8FONWPxQA67 Tb6MblaS9vq9a3+nqJn3ct6+WhJU5U4vt/1YszGutHHvx3us2jytelnQWZ+dep3ZuHPcYMrD DKgyrYw7hc7CacUa7VQuTVgd9DdvuAzosVK0HsH2gDezcee4wZSHGVBlOivQzsJpxRrtVKoO VkddO3WdvNkyoMfqD+xUsNDZXLqzcFqBnQpwA+hv3nAZ0GOlaD2C7QHs1EZ0VqCdhdMK7FSA G/BmrUSHN1sG9Fj9cS926u/nrWCnOns0SjNB4x6U3g4DD08v0+eV3p6R22c3N86WlOH5MhHp T2D6h/nnC7/XEgm2uVSKy7ybp5ecUJa5XTXV3R7Cs1ryJpWR9N32+XeuKRmpfDalJTpnuX4t fjgh6u2zaDDkm6RSdcGhmZZUUki2qyRxTRaQ3w3WTNhy3Swr5wuyX7WQLgccvwv+qwWtk+sB zBgSSl1uSo8bBG/ubywNIFdIJfWWbADeAcfvgv+WYLsFhAfGGbS1JCupu3J8ySSzn2lJtsHE W6X1CLYHVDv1dT8KdqqzR6M0E3S3cEzNFL2tHsf99OlVIiFnS0pvRwPxTP6eB2ow/mFx4JY9 OJXtFYLDrSXpl8Bmdwjn6NldNYMD1COt+4uGZSR9N+5fc03JSOWzKS3ROcv11+KHE6Ie9/J5 /YoRTlGlJZUUku0qqXNxV9xVMmy5bpblqKOzyZ3JtK7kcsDxu+C/WtA6uR7AjCWh8Bjhu3Qh qbvLKEWeLoOKjTt7uV0OOH4X/LcEpcuNE0qVdt2QXl+ju2Twx9Ug4eS5MvdJ22ACbsnK7FSP xEQ8eoPEy9NDYtqWSOl568+ejpOqCfOpMIJjiKG9+bDd+oeF5xd23hO34os2nxTO5504Pae1 mh6p48TAs36hNgG2VkEib2IZhQc/b4ft1tk1MN2S0oHUPlu63YqGRnHoQRW8PD0MD9vtQ7oF JnaHtMaQzlu2kEwhGa7JaWjttvSHz9theHgICky+tAV/r04hnX/98PTsnEfbATdZvRN6gMkJ mS63c497OU6puGLPN90AUoVkqDdbA7gG7pbW9A1Q02Ug1ojaQCwtKRNL9q4sxCt/ZGpJ9sHE G6P1CLY7EhPx6A0Sh90mMc3PpBTMreS5Yg5DQofdZjOO/mH7MZy9RdsTivsVRvvzpQLPe0hW lylljoiB541sZQJsrYLEoWIZhQfvx2EcnV0D0y0pHUjtsyXyJm50OMUrDKrgsNsMm3EUfPmo sckVW6ElWQrJdJVUu7hDJjeSoLT34zBsNkGB2Ur73JlcPheuJVtXck5tt3fOo+2Am6zeCT3A 9ITEY4JTWQrp9HFZkFrHlU/P0LgLLrf9OIx7tySmb4CaLgNLadcLKUxcakdCvMJHhvtk4WAC bsAd26nxkq3kFNZuS01bT2UISZkVvzw9eIsM5SVkkTGbPyr/xYX5dqr8TTbdiT+7Upppab1s ZGeVT6YXOVuqGIT2NsFK8Rd9y0GWNbY6dmqmkIwhFXYTJUzqJKQfSX6P5YqoVkjnT22+Z6L8 Zl/KBQkZLzehxxUTrxZkMrrz7zL1VlKOz9s6fx9QT5D6TsymuSVlYsnelS12qqkoF+wl7oDW I9juyJigwsxZmwLVS0nHkJAyKz7sNt4iQ3kJWWTM5o/Kf1FwxBG9JOVvsj6FfEANO1X5Qlov G9lZ5fW/yNky3wnuWblvoawyCyx/e9XWsVMzhWRs/9Uu7phJ6WgLLEOfylLaQmcSHFPSSRwt JYOlmHb4aziVtoRs/Ua+kCoHmf8y37hLynE/1vn7gHqC1HdyW6gRktCTRSFY7FTTJbBgLwET uV87VVqINMWWCh92nDGNCp4cjU6ZWPF1/thmUpXO9m5gp059pncxO1XNc5B2fKopc+llzpZt t+HSy8IqMJVdYQFXWp2aLKSCkHLX5FSmtHfRuw6D1hIWjPlqhVTQ5vUDp/YAUxKyXm7CcR3Y qel6szaAbBSFFF2QR6R8Vvx7RfqubLBTbaVTOJh4Y7QewXZH2gQVVqJNsVNfowc+pz/pl0so seLr/LGWC//z0tneDezUqc/0LmanqkkEZ4wDmDKXXuZs6UgCz0FrXROi9j/XqnZe1WUW8CUL qaDOq13c+VNlEb3rMCVraQsB+IcUXRjm7OgHTn6qf0pC2jH5htKBnZpu3EWXW7VCL4z5iNgY KoXkb0Eg27Y5O9XWqgsHE3ADsFMzKUnH1pmhxo8MGgwOdS8/zwoqnUQvb6ea55/+LFmzuCrY qVbjt46duszZMsXgGahTnvK12qmGJplNM2SmnVoSkpfOxL+X2NptEpv/LJzoTGYN45xCmm+n VnOgLAlZL7eKdmpJA5hrp5oagDVwK3pSRXW+jBMp3JXzdqoxFOzUFK1HsN1xKzs1SrrOcp84 IYPBEbg/Ht5OcUUz1uXtVPP8058lB/kqT04/1Gr81rFTlzlbJhLPQJ3ylK/ZTtUoWSIdMNNO NVwlAtMvbuGUpQkpJRO7aabSttip9kKab6dWc6AsCVmjqGin2jqufHoWO9V+ud3ETi2r84oh eYkKa/FzdqotFOzU/sBOzaRU4XAdweCYuDo1mW5pHAI3WZ0qbXbA6tQ57fbioU5Ympo4t2l1 amGaIUusTq0Zn/8TY7tNM2t1apxYzUJidWru7xYlDWCR1anG1CbT2erUbBCsTr0JrUew3dHG Ts0kVUT+qcLz57nVqfMC7GR1qrTZAatTp9upjoc6YWlqIn3b6tSyNEOWWJ1aM74gIGF/y9uu Ts38LP5pUYSsTk2d0t5x5b+cvDq19ESldLY6NRsEq1PvGOzUZEryj6ZZJcJvpPVi4lHOh7Ln kk7YPYHi1y5tp2rfOIsmxSgWs1O1L4ofmp4Vxryz5YvhVONTlqaeziC3/+B1aQWJ38JONYZk uSYNFLTbCQGFhR10BwVpTSsk5bcTDsz3AEYMCRkvtzp2anEDmGWnWhtANopCUknJ383bNkLH dlc22Km2JomdmqL1CLY7bmGnit9UW54oLaoTj/I2BZzupyb82qXtVO0bZ9FkweS7gp2qfZGf lU+aSy9yNlO9DeN+0tLUUzzyY7ThNgJ2g+QWdqrxKql1cUvpTGokUkKRVWssbYNTaCokNbXi A/M9gBFLQrZ+o46dWu4azmrcJZfbbezUol56fki2dA12qu0+iZ3aH9ipyZRehFd9T7OmnuN3 D0fm5svT8T3TmRWr0nYD0WeSCxMG4J14aTtVMIufg/ekhCV7eqxVnqgHht6UvMVlK9RtJTt1 kbNZauV5Ozw8TFmaqgT5vB0ettvImDM0ySO3sVNNIVmuSQv2dlua1MvTw/DwEOZN2pIg+qxW Iam/lUkdmO8BjFgSMl1uVjs109+UNoB5dqqxAei5mUY6qahwp//pLovxrhwv/I/rxNiSsFNV Wo9gu+NGdmr41Oa0hX6WhA6743umMytWhQcb488kF0Z9/vQWdqpgFu+Dl5KExsrpsVbFOoke XC5+yDguW8HaqWSnLnI2SyT7cdhsprRYJcj9OGzGMTiv9JC88uD8bexU01VS6+IOf3QIXwVu Zx/vd7vZhHkzlbbJKTR1JUpqMpnmmukBjJgSiq4uoW6tdmpYuvtxCDZXsXZciZNoX8VB2i+3 G9mpttKuFdLx+srUtrTwX6gTw30SO7U/1minxpv+SXNZd0IrfJTYOtCZXR2nTc/ebnVTl/kN 2+fgnOFs8zxJ886nPUWZKAGpJOJDnrU9+CLfIH2IrSTFQzPfPzy9nAMQjYKZeRMCih2B4Bup JdmpcbaC0nZ+MMtTiYr6HEPw3HSyqLW4k2kkc5+tklxIlmvSRkG7zRJe/epaPLUcaxaSciVF RqWMuDhxfnEbE0pebkKRCOWm5FF6hD34OmoA+UIqqrdUA1CvpCn3LsstQDpQsukFJrQA8105 rDP5oky1JONg4g3TegTbDYdo0z9pLjsMw2VWJHwkpBIecfrluA8OnTQZtCR0nqR5u+NpT1Em SkAqifiQvbYHX7RgNlNGtpKUDs18v9kdzlHG+fMPFWyibN6EgGJHIPhGakl2qpzNnDc33VkG hnfGze5wCTV2tFyihWBi1GUtqahKcldJtYs7zPy4l4uoPKljSsoKYbUc4yIRyu1EppCU1hb9 XUAmd9nOaJeWhIK49KBzhRSmFX1r6LgqN+705aacbKLDb0sqWdo1QzpeEem7WxzR9SfpO+GU wQTcmDXaqXcLa16gPpMf9IcuoFcAgE5pPYKFpWHNC9Rn8oP+0AX0CgAADtipHYFxArWZ9PQ6 dAS9AgB0SusRLCwNxgnUZtrWFNAP9AoAAA7YqR2BcQKVYWnqylF2oAUAaE/rESwsDcYJVIal qStH3MkUAODtgp3aCZmN5wDsxNsU4qmuhmq7iwIALEvrESwsSWbjOQA78XaHeKqrodruogAA 9wh2KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ2KkAAAAAUEbrESwAAAAAQDOw UwEAAACgjNYjWAAAAACAZmCnAgAAAEAZrUewAAAAAADNwE4FAAAAgDJaj2ABAAAAAJqBnQoA AAAAZbQewQIAAAAANAM79Q3z8vQwnHl4emkdDqye522llvTy9DAM2+f5Ca2I0+W4titxpWFD VbiXTOF5myqs5+3g0mexth7Bwr1x2G0ubX6zO7QOB1bPYbcZhnHfUUIr4nQ5ru1KXGnYUBXu JVPYj6nC2o/esJRivYKdCr9/vzw99DlX03jerslr86bFp4J27YfejUN781ifnXrbpp89W9Vw ql0ltw0b1szqmkK7e8nL04N+6uSXHdF6BAt3y2G3WddcbV0Be9PiU9yu/dC7cWgv7fXZqbdt SdmzVQ2nWmK3DRvWzOqaQruAD7uN3sclv3zzYKcCU+DFUefGq5g0r655FICdagA7Faysrik0 u5c8bxN/MVpNMbYewcLdwhR4YdS58SomzWsr7RKwU2skdM8tBIpYXVNoFvB+TPzFaHXFeFuw U2FFc7cza7NT1ac6sVMbg51qADsVrKyuKTS6l7w8PaQW8q+mGFuPYOFuWd3cbXUBa091Yqc2 Bju1RkL33EKgiNU1hUYBH3ab1OP7qyvG27ImO/X0zPTD09P2+tz05aHpcErkP02tTU2857C3 z+Ikxkvp4eklnn/551LXnLgn2z47GXrRkpozo/J3XkvOGNNzt0RCNavEKQ3nwOCosKRT+cvX 2+1w7FTvOfbYZq3VADIb751P47RDoRiDRLKp5UMONz4IKyW8RsRfB21EPGf2mrTmrU6VGM92 uhL1GpESiyIquUpuGHbFTnlulXAvKYJ7Se17ieqmKlHleiW1rzx/Ffy3Gq1HsM05PTO92e1O D09vdofrQ9OhKeU/Ta1NTbznsMe9PInJHuSfS11z4qYz7p0MHbSk5syo/J3Xkp5deu6WCKlm lTil4RyoHBUhxO+dbrM77Md2zqVjp3rPscc2a60GkNl473wapx0KVWYu7bBp28ISKiWdkNxG 8rUvJWZvSTWqxHi205Wo14iUWBxRwVVyw7Ardspzq4R7SRHcS2rfS1Q3Nax/NabcdjGX3B2/ Cv67ctZkp/7+fZ5DuBOE4zwjWOUX7eEobeoYzmiOaQdHhU/kHU+anpJIU6Xgs5enh+HhIVyZ aArbQrT1ZHovSn0KbEiocpU8bLfO75QHIvOz2Sn1tiDXwjjNgq//CaOs0gAixIJ83g7brWPo KnP8gpVSyUPF3GmVolbxuY24KSWfmz3/SizIbN6qVollmefgdUKZRWyXiBTX9XarU/NhV+uU K1UJ9xIT3EuWuJfkeqz0JScWpXj883bYPrvFk377VTmtR7BdcJxDuBOE4zwjWOW3H4W5muQo uZ8d0xZmt9mDhCAzJzvsNsNmE65MNIVtIdp6Mr0XZWIKnA+pcpVsxtH5nfJAZH7tTvjDY2TN ppLXwjjNgq//CaOs0gAixILcj8M4OoauMscvWSmV8hnE3GmVoiZ0biNuSsnnZs+/Egsym7eq VWJZ5umbJ5lFbJeIpNzfdHVqPuxqnXKlKuFeYoJ7yRL3klyPZXClwzoRj9+Pw7h3iyf99qu1 sEI79ToZcCdC7hfyVCT6VHjQOv6lMPswuBRhOuoCq2BKNM/LykSox62ew5JQ7SqJbQFx5U1+ Cjyh3pbjfPKXpwfHwvQLoF4DSEXgfzREFSCug6pgpxY2ypSdKjkRL08PWWOqvHQrV4nJl8z2 STGlF3whNcKu1ilXqxLuJRa4lyxxL8n+lSRVVcp3Wu4q/UFOofUItgu8WYbruLhfyFOR6FPh QWt5sVD2oHSYyk+kKdFML+uMbEXpTpd6DktItasktgXiqE1TYMHOabcy53zyw27jWJiJknxN fzo9Av+jIaoAcR1UBTu1sFGm7FTJiTjsNllDtbx0K1eJyZcs726UwrqtnZoJu1qnXK1KuJdY 4F6yxL0k+1eSVFTKd2JM+zHr2K+Re7RTtZmI8HnwZJ1q7DiYpiaxA5BfPVYQdgZtrpdc8Kcu bcklVLNKhOMmToF/T6q35ThPyY//+v87HVKvAWgRCHaqxburYqeWGhBJO1X6JuenTnGYaleJ xZeUVtmtwE7NhF2tU65XJdxLDHAvOR9U9V6SXU6fqKkiw3rxvyG2HsF2gWW+pc1EhM8P/pN1 lidUTdOo2AFQntl1Pi4IO4M210su+Cs5tfd5zSoRjps4BX4Nn+VsPKU8T8mP//r/Ox1SrwFo EQh2qsXeqWKnlhoQSTtVWYs54Snk7CqwqlVi8SWlVXYrsFMzYVfrlOtVCfcSA9xLzr+sei/J LqdPRKV+JWWv6d8Ql+NO7dRBIzeFyc+UxImQcEo3IWVOE02Bp4UthqggZy8xBc4nVLNKqk6B 47y0W5x6NgFP/unpf74zWK8B/P79W6y8hnZqsZFT7NcIdoqh9Wft1JpVUs1ONdTt7+7s1Gkl GXbK9aqEe4kB7iVKoSz7rH/qkita0I+deguM8y213eamMPmZkniQcEr3GGVOE02Bp4UtpatR snDIGFLNKqk6BY4LpeHE8mQCnvzT0/98Z7BeA3h9fRVbQUM7tbjGZvs1mWvSFFflKqlmpxrq 1nK2G4ZdrVOuVyXcSwxwL1EKZdln/VNRFf3FCju1C+YsXylOXyOYoggbt9VcUVRO8RSqdEWR /uOZVbLgFHjyr+pwdE4v+Qv+ez6k1hJa4UHXt7U6NX9NZgPOf1tODTvVWLfqpxNYcHVq8enr VQn3EgPcS2RmXltCPfuwOnVNzFm+Upy+8SBh47aaK4rKKZ5CzVrMVLNKFpwCa0ndiKNzeok7 +O/5kFpLaA/CA/FvanVq/ppMfmr7tpwadqqxbi1ns7Lg6tTi09erEu4lBriXyMy8l2Q3smV1 apJ7tFN//37eGiZc4kTDZAL4v5TSMTx4KNgiprAtKFPu1PHqUqNsQhWrpNoU2FJv7sfDsPhu AM/bwX0zyvN28F8DdfywThBi9hvbqYnSL7NfJDvxd+ymZq/JbMCnlGq2i6V8yf7t1Iqd8iJX CfcSBe4lJfcSM7nlqalLTvmuollcQOsRbBdY5luvr/vRMEEyza0MB0mHGB48FGwRU9gWlCl3 6njlzIaQKlZJtSmw/L2+sEtfbFWN/Ti4b0bZj4P/GqjjhwvaX43t1ETpi4nP2jvVck2mPnXD qNkulvIl+7dTK3bKi1wl3EsUuJeU3EvM5JanpqJSvtP2TsVObY9tviXPVoLPnuP380YL317k 90pHq8WChwwFdy486nkrvI3ZErYN6VlT/fnT9FKYTEIVq8Q8BQ6jet76VWmpN++3y/upp9Nc ggz/f/20QgMI8yqfzGqnhhG8PD2UPup7+Vng+ejFnnzYf7uNnwAPr8H8NWnLW7Vr0nI2gy9p rNvf+avkpmHHqUifWTrlWlXCvcQG9xLzvcSOXoCX79Or5oOcFP9VqhatR7BdYJtvybOV4LN9 /H7eeOGb4SDp/7E7Fx61H4W3MVvCtiE9Rqo/f5qau2VDqlgl5ilw+MPDbuOV+EF+H7jm26Ue Xq3F6TSXoMP/Xz+t0ADCvMons9qpudJOJ+n/LPB89GJPPuw/jvET4OXXpC1v1a5Jy9kMvqSx bi1nu2XYcSrSZ6ZOuVKVcC+xwb3EfC+xoxfg5fv0qvm4cZX9VWrdrMlOdXdf2z5fP3h4erlM PJ25w/mTC8F043l7fNzaPSSceRwnNf62b4rd5CUSRxMG9PD0os/uUmFPKy8hd9HX6gn1hGpW SZSWd3g6KNnLydabl9LCq1OjWbnmJdZpAH4qp9bmpCaUbVwBWnKCcSMiLnQd9ISirEsHno0G 76zisiz/e/GazOZNjmtGW9HPJpS/XCW5utVKYU4LrxB2nEwck6VTNiWUgXtJGdxLar/XUPFT tS4w02uJNrWlPmbTegTbHHcbt3F//WCzO1wmns7c4fzJhWC6sR+Pj1u7h8jPyuUO8iIbhnEv RBMGtNkd1MUyybCnlZcQuLornrz2STyiZpVEaXmHZ4ISXUE/h8lJ/pxythHNyjUvsU4D8FM5 tTYnNaFs4wrQkotLe5CRltolvjcldDYavNqdek1m8ybHNaOt6GcTyl+uklzdFuXtdmHHycQh 2/pbQ0IZuJeUwb2k9nsNFT9V6wJzPankd1vqY6WsyU69OxZfOQJwdxRsPQDwRuBesjomL3Hv itYjWKjNna4cAViQao+wA9wN3EtWx+Ql7oCd2hKmwAClYKcChHAvWR/CNhbro/UIFmrDFBig FOxUgBDuJetD2MYCbGCntiK3eRoACGCnAnhwL1kp8/dgbU7rESxUJbd5GgAIYKcCeHAvWSnz 92B9o2Cn3pDq+68BvCmCnRdXv7QLYBrcS6ALWo9gYS7V918DeFMEezSytAveKNxL4A2DnQoA AAAAZbQewQIAAAAANAM7FQAAAADKaD2CBQAAAABoBnYqAAAAAJTRegQLAAAAANAM7FQAAAAA KKP1CBYAAAAAoBnYqQAAAABQRusRLAAAAABAM7BTAQAAAKCM1iNYAAAAAIBmYKcCAAAAQBmt R7AAAAAAAM24Qzv15elhGIbh4emlcQTD9ln7UvzG43k7uMi5MR0E94Zb7fmWlEnp9o3meZto qpa8na+vGW0+eYneiFNW51SAWxJKdpKlvRTzi9fYTUKf9HB9wS1oPYJdC4fdZhiGYbM7NI5g GPfal+I3HvvRu9/IuTEdBPfGuX3Nr/P92KDR7MdE2G6T1q6SCvlPXqI34pTVORXgloSSHWN/ U5f5xdskbKhFD9cX3C/rtFNfnh7SDkH2gOV53k63U1+eHvITUdNBfaGVSed0G/b8wF6eHm5u ttkMPkveZl7mHdTrrByYzPAmdur5zNipTWncwDu4vm5JB4OOBrQewXbEYbdJmxDZA5ZnP063 Uw+7TX4iajqoL7Qy6Zxuw57fzA+7zc0N1aSd6h5luQTmBN9Bvc7KgckMb+dLzipe7NQKNG7g HVxft6SDQcebATt1KWbMJU3Rd5DFYlY6v+427BqBNVmgagA7NUcH4SfpPb77Bzv1lqzxjjyf 1iPYjliznWrAFH0HWSxmpfPrbsOu0QaaLFA1gJ2ao4Pwk/Qe3/2DnXpL1nhHXivYqUuBnRqz 0vl1t2FXCex52+UyQOzUHB2En6T3+O4f7NRbssY78nxaj2A7Aju1iywWs9L5dbdhV2kD+7HL ZYDYqTk6CD9J7/HdP9ipt2SNd+S1sjY7NdgtVNtC8TSzcY6W53V+cnPmfm5KD08vwlzSsCtk uBWimDnTQZa8XQ44fhf815qQswOkE1lcH3K9lRW5fC7pYWZr3oLIgq+LwvaKSZtXh6eTpuCm hM5HpgrQS0g+1/mwGc6/GKn0edmWpze0U3NXpl9p1fY63T6LOcifTekE/dBzpe3ubpnrJ03d ZL4HNJGpjJKwy0+oXCWpKlECkkIy7HRr7Lhym2YXdFz1GrepAST7W/Uop1KiHYcvx0ZHPG2v X1yOCk+Zzr+tuRlHJdHpHp5eVm85tx7BdkGwW+iFYB5zmtk4R8vzOj+5OXM/N6XN7iDMJQ27 QoZbIYqZMx1kydvlgON3wX+1E4bncXaAdA6M60Out7Iid3fk87IXJWPNWxBZ8HVR2F5A2rw6 PJ00BTcldE4t9X1QRNrRs/xU7RITPi/b8vSGdmruykxfACV4KY17MQf5symdYBB6JlfKtSSW uambzPeAJiqGXX5C5SpJVYm9TzLtdW3ruHIJFXRc9Rq3rQHM7SajHYcvx0ZH7MbrF5ej9FuF 9LWtuRlHJVHONrvDG7Oca7E2O/WIZXXqMHd8a3YAACAASURBVIRzLsnic6cyk7frCxN/3g7D dqvOk7IzqPmrUwvy9rwdts/uBove09+2hF6eHh62W2crV8WhqzF3PJ8rKnDZm0jkTc6cUKj5 sKMNKqWI5LKMf5dNyBJYmBXhXLZz5FGj0PYRMLXvG9mpW7/A451GxRqZdNagmF+eHoaH7fYh X//K2YxXU6qQTiXgOd5TusnCHtBEInuGsG1YrhJLlZxbUli92ZtUqmr1jks4XO//EhHUa9ym BmDrbw3dpPxHiLgiXUv6+G2w4bgt/8bmlu+Nwno6RoadeidYVqfGcy7J4nOnMpO36wsT34/D MI7qPCk7g5q/OrUgb/txGPfudpb+09/RRpfSzpeH3WYzjs5WropDV2XuuB+HcfTT13YAzeRN LCUhnXzYYimJtnRUKZnSTXqdiTYQZkU4l+0cedQotN19Te37Rnbq6Bd43LpNF4D1dFGjHcdN vv6Vs1mvpsRxpxK4nGBqN1nYA5qYF7YNy1ViqZKCPilIWf0zX6rjsiaUbSHVGretAdTqJuU/ QsQV6VrSx2+DLsl2nzQ2t3xvFGb3GBl2ajl3bKfGM/5w4lTH8Ht5elDW/DSzU0vy9rxVbTZz QkJuxV9WslOVRVbi+ZILRZWlf8IC3GTY8vfxBD87BTclZAvMcAW4ycxZlqalq74rrSM7VV6v 7P05YZJxIp1MNuoDf7/gbHXs1HixZXE3WdwDmkjbqZmwjeSvEluVKFeQWOeWqJMdl8Sku1m1 xm1qALb+1hSTyU69/tc9hfuFNf/G5mayU8MjWJ16P5js1HjGH87k6hh+h91GWfPTzE4tydt+ TK8SsswbhdxqK5Oq2Kmy5xl/OCFvUoy5sOXv4wl+tihNCZm+sVwBbvxzl6VpTr2YbEd2qrxe 2fszzCTjRDqZbNQH/n7B2erYqfFiy+JusrgHNDErbCP5q8RWJQV9UnBAYjlwSYYm3c2qNW5b A6jWTdrs1Ot/3ROrXyTiNDY3k50aHsHq1Encr52amW9p05ji6U15QovbqUUhpaKxJiTEsqid qjyRHX2cOl/Kyoif5cw8U593DS11akrIHljwxK9+5OTFfVEYroWiuqk92anSz51UE05x2YlN CRWerdLq1KSbaOkBqnWl5p9nwy4gfZUYq0RbPJrxUyde2OYfZPuHOo3b1ABsebWdu46das6/ sblZuzWHOb1XJ7QewXaExU7NzLcSE9my6U15QovbqUUhpaLRzhF+Lhy3qJ2quEvRx1PyJvwo E7b2tcGXm5CQ6Yvzt4nHWIMD59iSwaO42RV1Hdmp0s+dVK0XQBZTQoVnq7Q6NekmWrqSal2p +efZsAtIXyXGKinok4LvF70LpZOp1rhtuajWTVazU62lb2xu1m4tvRsAWHjLdqrGAnNJ4zd6 9EUHFeUtY6eaErqxnWo2AaZYxcV2qloR6pR+VkL2wKJEtJY91069GKcna+ryjK1+vl7s1Myl G3htHkUt2WqnlpztRnZqtgdYt53qE14KxioxFoGQ2sQLW6iXKXZqncZtyr2tv7W1mWp2qi3/ Ne1UH22XhhXRegTbEXXsVI0l5pK2b/Toiw4qylvGclRTCh6RvKmdai3w1PnU70rtVJvZach6 uWtaYnwkPNO5durVTUo8V+ufrxc7NdOSrBdAFqudWnK2G9mp2a5k3Xaqj/z0f7ZKCow5UzMy PaU/t4VUa9ym3FfrJuW0Jtqp2cYtBzXdTvWRNjsAA2/ZTq0zj+nTTrXnbZLlmI+F1anNV6ea 05n5sP8l4aOBerJR9cWpPdmpE1enFjNrdapCy9WpljjWaKeGSRnTtaxOFa6yaRd2+BS9/oOJ fwcq5c5Wp6Yj1H86rTzX/rR/6xFsRyy4OrWYPu1Ue94mreDMH8fq1OarU82Hz33Y/xz50UA9 26jq4tSe7NSJq1OLmbU6VaHl6lRL+mu0U8OkjOla+iRp94NJRWdPaOLfgUq5t9Wp6XyoYU4r T572n8KbtVNF+21qMPmN41wWt1OL8pabuU90bBa1U4VUxEhzeTM+Qp0LW/4+NcH3jso9Nq3X dKFln7JT59XL83bYPp89peft8PD0rLupPdmpub1Tc49rl5xMSCi02IrOdgs71dQDFPeAJm5g p1quElOVKH+QCNzUTFPLBZb60RQ7tV7jNjUAW39r6SYr2anm/FeyU+Xv1T5/GIY17AbQegTb ERXsVHm/t4nBGDaOc1jcTi3KWzqa7O5/WiyL2qkFe6cmXQnjI9S5sOXvUxN876jcY9N6Tevf iCml7NR59XLYbTa7/SkrxyzpbmpPdmpu71TjBWA6mdho/bZcdLZb2KmmrqS4BzRxAzvVcpWY qsTQJ4kRTrFTCxLKd1zV/lhgaADVusladqr1PlnJTpW/V0slXiULF9Zpp4YG0MvTQ+mrf3/L zzhPeu45XIj38vSQeq/18nZqSd4y0ZgSstqp4Q9lPyvNy9PDw3YbP5IrJWPIm/+9vMosH3b0 OymiyHN5cV4/XZKQe7TexsKk1ZQqPHH68vTw8HAppOft4PxPProTO9XwPnapeCYVWVi3z9vh YbuN92m0nu0mdqqtByjsAU3cxk41XCWGKhFaUljdUhGpflmyaoV2FGXjeo5sx1WlcZsagK2/ tXSTsXk6JAYAqp1qzL+1uWVGJXGUqQXy6zBTsVNdAgPosNuUvvr3VX7GedJzz+FjzYfdJvVe 6+Xt1JK8GbxCyV+c9LB/GIHsZ2XYj9FbtLXVYZm8xY+jy+nkw45+Jz3pHnkuB+f10yUJuV/q dmqYtJpSjSdO9+Ow2ZzTP+w2zv9KwvZTvMXD/vn3sVsuAOvpwmeIN+MY5KDgbDexU21dSWEP aOI2dqrhKjFUiaVPEv4/7WF/e0KmjqtK47Y1gGrdZGyeDokBgGqnGu+T1uaWGZXEUaYWyGOm plipnXpdvjFEU0l3W7nT58JHwsHapHRaOKeUTzMi/3vlhNpB0Zw0e5Ahb0o6ygIiPaG4bN2U xcly8mSGkj6vgVQzb89bcGTKd8ocFRRS0uack5CpJR0dgODQREiV1wwLNlXciIRCMOXNkpAt 3lO63lnFkojimupzRM3IjcN6NqUAJIstcZRwlc7qJnM9oIl8AygKO4f5KjFUSdSSxL9c+SeK at/YcfmHPTy96GWd77hqNW5TAzD2t/luMjybU5RRe3DjiC+4ZP4Lm5s+Kvl9vnMZ7gByB9op rUewfXFevnEkmMaGnwsfCQcLX88I55TyaUbkf6+cUDsomu9nDzLkTUknMbmTD4rL1j1cev4+ fbIsp8mtF5TgANnyFhypBpQPOyht3Uqfm1BUrUqtHB+7t4VUec2wYhxkwzZdJab85zifKWpJ 2vPI00/lEjUjNw7r2ZQCECyoVEkKV+msbjLXA5qoHHYO81ViqJJcnxSlstkdoiIydlz5hNzI UiEZ8mbF1gBqdZPh2ZwLKWoPbhzCBZdq3IXNTR+VvJ49WMMdQPT5wWW1diq8UWauSIQAbdtH ADCy9g0woSuet8M6lqb+xk4FeH1ls7nKJB7KBwAL9ElQkf043dV+G2CnwrrATq3JpM0tAMAF OxXqMWUPnGa0HsEC9ADWRUUmbW4BAC70SVCPSXvgvC2wU2FdYKdWhKWpAPPBToVqrOtPXK1H sAA9gHVRD5amAsyHPgmqwZ+48mCnwnqw7U8KAHAbrLsvA9wjrUewAI2x7nQKAHAL6JMAbg12 KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ2KkAAAAAUEbrESwAAAAAQDOG/17/ QwghhNAS+r//vd5SzfOL3o7MQ83/hxBCCCGE0FR1CnYqQgghtJSwU9G9yjzUbD4ERwghhBBC 61WnYKcihBBCSwk7Fd2rzEPN5kNwhBBCCCG0XnUKdipCCCG0lLBT0b3KPNRsPgRHCCGEEELr Vadgp3ap/adheP/PYWYKZ8Zv8jGHf95fjtn887N5rtvp5+5aEqkSux/9/GczDMPwfvezdSQt 9W281vmnffrgb5/efHH1orV1XNip6F5lHmo2H4KjudqPw7D56zAzhcsgay8fc9j9ce3dd/82 z3U7/bvb+MNSpcTuR4e/NsMwDH/sDq0jaam/navkz3364P2fb764ehEdF0I3Uae8cTv15z+b ea5lkQ7/vDdO/ufbqW5SWXPQHthdav9pFaZMdf3cva/nD377NHz61jpHk/VtxE7V1W3/0G1g vhyvc//RmR6/+7L//GHz+Rd2KlqrzEPN5kPw9ejw12aea1mkw+4P4+R/vp3qJpU1B+2B3aX2 49s0Zf7dber5g7e9lGrr7xE7VVe3/UO3gSF0F+oU7NQu7dSKwk7NyWCl3aewUy96s23ApG77 h24D83UyOn/t3g2eefr1cRgG7FS0YpmHms2H4OtRr3ZqRWGn5mSw0u5T2KkXvdk2YFK3/UO3 gSF0F+oU7FTs1NW4EgvpzVpp2KkXvdk2YFK3/UO3gfk6upw/vmzefTn41ueB1alo1TIPNZsP wdcj7NR2gXWjN2ulYade9GbbgEnd9g/dBobQXahTVmWnnrfM+7T39wZVfBx3Y8Toae5v7u8d Ynf1tMukks752/Gbl2bgYO6Vs2mpyZGcVLbR5ww71TnRtYTFD63yyiHI4Kn03u9+unsjin6f XwKTDXGlDcTFlQrba2lHSy7477RGnsi+17BTT6D7TXf8Fvinp/86uZsfsIPTPE6nuBbdpQad eCwNwHa5mUvSLVIt725jkxIpaLfRjsbOb02lrWRfqLjLt8daCP6rXgVhJNaOK2qWqssZnk4o eb/iUm0yY6cGRXTbP5450u1USb9275ywlZ94mwYMj3vsVNRE5qFm8yH4Ujpvmffn3t8bdBj/ lo7/2+smg1n3/k+lv40tIS+d8FynPSiHce+lGTiYe38goUZ1Tk2J5KiyjT7n2KnXsJ1gxA+N 8soh+Pmp9P7YHdy9EWW/zy/PqUaY0gbi4kqF7bWQYyTBf6c18kT2zQ3AbU7DMO4D//T0Xyd3 k0rScCmdTnH95JIFJx5LA7BdbuaSdGtQy7tb2lIiJSGFOxo7WTYVtXIuoeIuVX8s8+C/avWF kVg7Lq/ZaweIpxNK3q+4VJvM2Kle+5fPhRDS1SmrslNf//vvaHyMnzxf4PDPe8mb86yB/SfJ SshOsMV0op/sPw3jp0/Xz3/+s5EskoK1VAUz/5+796mtP2euThX3FZ20KOzbGJgs3z5FXsnP 3fv346f315oSjhHTmbPKMr0y0RK2k44bzLdPpVZv1LqisysRxlV8+Oe9H+fRFgzs1GFw01fa rUnZ1alCk46Xx1oagOlyKyxJy+rUxGJeS9jBdfpz937YvH8/7W8S4yc/fa3ivn0aPn1ziyK4 nMVSEttSphHa+lvxdEIrdX+YbJOJwMKbwtGJbmmnHn3SjKP6fRziDQE+7H5EfuvH79dPfnzZ DMP4FTsV3VzmoWbzIfii+nsc/hxHz9Y87P6QvDnPGtiPkuuaXVJ3+GvjOyOH3R/xDH8/DuP4 5zWGw18bySIpWEtVsNbv390mtfXnzNWph90fQrnt/1Qs7HTF+XHu/4xK8t/d5o9xdM4oH+NX ZVRH5YElTBZL2E46bsPb/1nqOEd75kZnNzeAqKEebcHATvWdL6XdmmS5lMID4uWxlgZgutwK S9JitKUW8xpCCqrp391m2Gyki8vQSMbRLxat4g5/bTZ/7Z2WEFzOYinFl1K+47L1t+LphFYa Xt1qsacCC1tOfC6EUFqdsko7VbJFvn1yPpTNEWHunXEtZQMlTif2WMV5/jJ2aubguQ/7//xn IxiaxaabHEYYeWSmRD+UQ5217ixlpdnCvqQzz6+RkzU8kh9bmaakfu7eh7mb/vR0NTs10wBe LZdbcUnOt1MntFvhVxYp76n7NsYffvs0pBeKCmcXsplrFbb+Vj6d91vlRGrtZOxU00VxA7mG 6dfH68oE47P/wbLWr4+el3r1Yc9rVG+fQfRmZR5qNh+CLyrFFtn/6XwomyPC3DvnAcleZGQm xm+OEuf5y9ipmYNnP+z/9ygZQ6X2pRxGGHlkpsQ/lJ3cOevOUr+1hX1JZ94LxORkDY/kxz80 JSXU4/Snp6vZqbkGYLncikuygp2aDkkqWCGzFinvqft7jD88Ls/UTiFfSkI2c63C1t8arlzl RGrtZOzUsEBYnYpQkTpllXaq8gT0ZaqsOTvxdDo9wda+jT6PHZ/7sVOjFW2CT2GqNdEQkR8/ 1+PXLK0524AmrDRj2Nl0TNJqwbQ20K8RW0ubYJwVxBDKvDo12QDkT4Kwy0uywurUXLuV0p+0 4ay4YPz1v//2n6LwkulrPUNcSvln6g39raEjUkvYHmrwrfskWLYbXEzaWtSvj4O7qvT/fu3e BQtRhc/3H92feI//nz5vlU30BmUeajYfgi+q2N07f36ZPGtrJ62uk3sufR2i80ns+NyRnRot UC1fdKmXpPz4eSJ+LTuWbBbGZg87m45JWi3km03UAGwtbYJxVhCD4QB5dWq6AYifGLzLdO5q rE5NhfTvbiOlP2WV9//bj/Iy2/0YhTepZ4hLKdMqbP2t4QpVS9geahiYZf8BhJCsTlmlnao/ av3ff6+JOfYEO1XeoiV4QPXWdqqwW+WSdqq/QHXK0lQ9OxPsVLVKptolupVmDTuXjk3qJqSD sPIxe4ChNO7ZTjWWZEndzbFTlfSn2qli5Qqfp9JXs1Nqp9r6W8sfPNRamGanRvnN7puxkBJP 9399dNao+rumBr3b16ttqnFa2Xr7DKI3K/NQs/kQfFHlLU51jj3FTtUIn2y9pZ3q7y147JAW tFN9C3vK0lQ9O1PsVLVTnmiX6FaaNexcOjYJ1Xq9Kf2dOdKP02Yu37OdaizJkrqbY6cq6U+1 U61/UUhVipqdUjvV1t9a3num1sJEOzVKZEJpI/SG1SmrtFNbr06NdEs7VXjUd+HVqa/OgrhJ S1P/W3516hz1vjo1OnXkCbI61bY6dVIbSFe6MWxWpzZYnVpSg4sqYad6D/Jrq1OVVaiabp9B 9GZlHmo2H4Ivqh5Wp4a6pZ0qPOq78OrUV3eB6pSlqYmSrLY6dYZ6X50aV2i2AbA6tTAXrE5N tYG1rk41p4MQktQpq7RTb7Z3quRQyIfdzE6Vsra8nXpeoDppaWoiDGHv1Jyb5lV0FVXcO3WW nSpvf2k5tXXv1MANv1s71VSSxXU3x05tt3dqIv0u9k713OF6e6eKP9Fq8NvpDb9LrV1N2KDB RqhfH4W9U2MHVtg7FTsVtZB5qNl8CL6obrp36mH3h2X6fUM7Vcra8nbq2cWetDQ1EYawd2rO TTv8tam8xKzi3qkzd2aUtr+0nMX8dwJ/34a7tVNtJVlad3Ps1HZ7pybKoYu9Uz13uN7eqXJl KZ3h6SkEdgNAyFenrNJO/TQGr42OX6EefaIsqwzeZP1z997wquvotd1GOzX84c9/NtocPvWY eWjTDMPCD/uf05n2InKnJH0vQ3jJldVNi8KQ30huDixhpVnCtqRjk/Iieye/YTynB//zb1E/ 7pMQvEW9np0avoH92xhGJbwIawjd+Vp2qqUkS+tulp0aX7mTL6j9p2H8FORO+TtHzuOOFroK bycTCjPuuEz9bWwfx29viwNI/QknaacGrV1fWf/tvHfGUi+qch7S9x3V7+MQLkfdfxyiN019 H/0fHj5/iF5j9Wv3jof90c1lHmo2H4Ivqr/H4c8xeGwzXjIZfSK/oT58k/W/u01gVUivTY9e Nm20U8OXTR/+2mhz+NRj5t65Ts81L26n/r/D7o9h80fBjq5CUfsGx+GvTeiSmNy0w+6PKL/y 2+3tLUq30ixhW9KxSXmRve+BmhpAZLr9u9sM0VvU69mppkspfBHWILzlrIqdainJ0rqbZafG Fbcfh81G7JQy2o/DOMavrZdiM7xqLx2kXJhxx2Xqb2P7OH57WxyA9jiCUu+J1qWtrL9ssTrn PXII3aE6ZZ126j7YHlGcBn/zN5jUbAV/g1TJkov263RP5/789Pk3Zx+l0KPxd3UMvv2mbcAU rrwL8nWO4RK8vnekc8Zv8Qacp2zI5sXPfzZzX+cSZNDPvhvPsbKEstUyOGXNrLADqZxUMmy1 tKc+Vhzt2CssqQ6+PRWd9Ky3lk5c2sl2a5J3Oin74bV2vrKOAVgaQNHllilJfR9ep69QGonT IAvarXfGU8VN3jvVy13sSidj1q8C7QJPdlxCY9PyZXg9VBB8plUrR34bh0/7oAGoRX271anB 7qjyo/2Hzx/8jEmHfX0Mcn/1W5fIAkKizEPN5kPwRXUyPrztEdOT5NNVq9gWx5dfX45SNiX0 CZ0FPwx3x9XQo/F3dQy+VbdqDVfeBfk6x3AJXt870jljUD5XEm8/n7mAK8ign303nmNlCWWr Bj9hzayyDav4FL8etlra2Z0iFfkNchDKPN8AxFIK/a+gtJPtdkLk8qpe74Cj5zVc95EIQoob QNHllinJ89ljnL5C3av30iALQvLOuNn9O2vvVC93ggctIVRrcKR2HSU7LumSVPIVXCzS6YJ6 ia4jU8d19L79K0V1S1mdipCoTlmtndo6jLeneAkwQmiOqr6KCvWq9MP71dU8v+jtyDzUbD4E X1Q11gCiCVJXZSKEJqnqq6gQQqiqOgU7FZmkPAWMEJos7NQ3IexUdK8yDzWbD8EXFXZqG2kv wEEITRR2KkKoX3UKdiqyiKWpCNVVuNusVdipaxN2KrpXmYeazYfgiwo7tYVYmopQXUVbMBuF nYoQuok6ZVV2arDv3mJb3aGT4o0jKXOEJsu/oMq91GAzUP7CsQ5hp6J7lXmo2XwIvpSCffdY LHnjAk9siYgQysrfqLTcSw12g+XVSQihBdUpq7JTEUIIoVUJOxXdq8xDzeZDcIQQQgghtF51 CnYqQgghtJSwU9G9yjzUbD4ERwghhBBC61WnYKcihBBCSwk7Fd2rzEPN5kNwhBBCCCG0XnXK cOOZHkIIIYQQ6lnYqQghhBBCqA91CnYqQgghhBC6CjsVIYQQQgj1oU7BTkUIIYQQQldhpyKE EEIIoT7UKdipCCGEEELoKuxUhBBCCCHUhzpl1Xbq/uNw4t2XQ+tgELpLXa+yYRi/to+nS30f r4X0uK+U4Obzr9qxDcPwYfejeXFV0tfHm2Tn1+5d5RuNe00N1Sr67cipke7asxtb133mqRF+ /K4eg52KEEIIIYT6UKes3U5V5iqBgzBxMnz4/EFIJDH9QOh+pV9u+W8L9OPLZsV/Hfk+9mWn /tq969fQkWVvADeyU8sDS+rw+QM3kUr6tXvXl526/7gqc/zrI3YqQgghhBDqX51yp3bqVYfP H+ZNb0J/5PD5Q6UFaAitSdipBtWyUytpjYXZbcx1AuvOAVyzeivMzi7/rLBTEUIIIYTQGtQp 2Kk5SROk9CQEoXsUdqpBnfkpayzMbmPGTu1OvRVmZ5d/VtipCCGEEEJoDeoU7NScxAlS6SzO 2U/tOHv58WUT7K329THYCe6y1UAcv78Lwaz5pLeLn2cWnGP++D3YPEEu81P8Rx73sfXgZPl0 jPJzL33xczepd18OXqilJeBvdffxe9hg0mGfS2bz+Zd/pFspTul5EQqfh/tL+Dk6f/u4Dypu orlfts2fcrmFiRhTyzUhB6chnXJ9/eRydqfAzxUxftXblVJxYl9RcrnN9VPcc0nBWMOWNyqR gtd7AL/9H79S/jt+Pn/udhdFPYCtAURNLlUdfiGYrtzUzWKmnRpmXz+jVw5xBoM2L10CU6OK gjHcucT2JnV0m89fnIZxSflcL8plm3wWJH0j9vf8mfUXUC+pXJVdmfYXJq8w3305uKanW0rB qaUMhld34J8e/6u1f+xUhBBCCCHUhzoFOzUn2R+ZsBYv2lXt+xhOgIXJYRz//mPgL0zeZjH6 4ddHweX8+Dh608Jfu3fh6Q6fP3ghHadnaevhx5dNkH3VrfD3fwyC/Po4DB8209Yo/fiykUyB jKUS2RaHzx82Hx83kYXqF5ocYXojxbBgTyk/jh+9ybN02AQJNeuql9WpwgFC8e4/DuPHx2ux pCru0pyCWjulU3K5VVuelui4LGHbCtPQAzjp7J19Ttx2u/84BNbeMZjMPpJSjZgaQLLena98 g2lqA5gU2LSYz4UZtTflzxgfdl+dHuzHl01p24s2n43OLtZjfOcKFfdIx6710jAu3WzQAZ4u WzcjWjtJF6bct0+6NsVSkjvtCpd/mPjRLfVPJ3S2wjpT8eqWEndi9s6OnYoQQgghhPpQp2Cn 5iRPkKYl68xLxRmpwU6Vp/RTnnmUSy9IX3nZy/6j96HgCRqsh6gMtbmoW1bK3gtTVmbJhZat 2fgAZaL+a/fOm6aKbTX36pI4SMXO+/pY4RUoyVpbnZ0aGzr5igtcieLL7UZ2aibsORUq/uT4 BxLF93fT8cLObYoi57GGnaqUnmEj7ETMN7BT5bOLPzk613MaW0EHmLtz5RNXG4ZfqqKf+/p/ 30f1L21yMHLbnrJLT9EAoI6dGqYchW2xU00l8PVR/HPdKQvYqQghhBBCqA91ytu1U7UHS4WH gqvZqa+nydIXZUaat1O18/qf+w85ulynUtrEz49BmG6dPpecqbKHHKO8OKd2HVI3Btk0FKbu Sv79R8InmSOyKyfN0g+fP0g2k+uHZr0J0U4Vf+I6DpYGIGk5O1V50nmIreGKq1P9eMSKSzsX tsstqB3ZT/GeuvWQj8+sTs0ZLobCtPUAhQ2jDzvV6rIVlGRZYBNiFsJLFtTsbUO17CifJ+9c +Wza7VSx2Qd/wMsVQuIvc+ULeAuurDp/TfH7CnmDjpydaotEXtOKnYoQQgghhPpSp7xdO9Wq ag/7OwlqCxJNdqrmypStu0k9We/bqWKyGaNEfGxc2GQz3sfg+In2NKhSm5OcBetKpXzYJtPt Ygofffzr1pN+6xJsx9hOreQUiM3pwkCrPAAAC6ZJREFUjlanVrFTCy+3Wz3sP99ONfYAhkox 26n5S8nUANKhJmuhbzu1aLFtDTtVbdxaD6Mvpc91XHY7VVvFr+54IDcAjbJCUy/DJe3UOC/x DiQZO9XYVrFTEUIIIYTQGtQp2KmGycz8V1G5qX3Y/dDW4ExfnVopX1EM5tWpubwIU3HVyzia jGer0Ssr2+pUk0wTTlPYltWp5wI/7gN73g02KF5h14Jpq1NNEp6rva+H/ZdbnZpsMCuxU2+9 OtXWA1gaQDrU1Oed26l9rE6VlbxzGTquPlanlqvF6tRsdlidihBCCCGE3pQ6BTu1dCbz+n// e/3xZSPvcJdYtva/wAiT5o2WV1EVu2ZlpTdl71SD4yxNSoWqubzx5uP38xuoAvdw8b1TvRWj trAte6c6r4553J8d2KANSDWy3N6pSsPGTg1cibLLbUV2auHeqTPtVGMPYGkAyXpPlp6wd2pX dmrh3qnz7FTVo4yVuXNZOq4b753q/ylrjm67d6rNpZ2+d2rw1zjsVIQQQgghtAZ1CnZqTtEE SXuB8vVpR+1b6W05/mRGfLRfmPBHp9DfNZzOmh9SnLWvj8PHx+BhQ+lFz2GuwwWbYcon6zmq mu/j8GHz7nS6w+cPw7sPQkjuhPPHl83wYTPNWYh8WPf10/awz+8Hd5M6rz/162jz7lwsp7Cj d0+HhRY/nfp9HB7H+O3PxUZPGOHpwfapdmr4Lu+vj4NtC12pWbo//LV7F0QVeCjHSlnITi29 3NZkp5p6AEM6JjvV2gNYGoDWEoKv4l2ws3+sam2nCr2r0JNY0rFJeJA8bPCGO5el4yp42P9j cMUlNpjONADhz3UT/vAW9a7a4wh17NSoE86/nOq4gUz8Nsigcr8+hlccdipCCCGEEFqDOuVO 7VRl67TCybCyc6I2X9JXp7qvvbq6aWJU/vaCH7+fY8jssDnVMg4KSlr4eV4oqp/r+3h6Nt+L PFUIwzB+/Z+YNW91kjS3jJI6PkE/2VnwSyBzLjnss1PgJSW/Vfk6mVdNwChrQXmeprte45zo 8vh5P22z4AWvbx4qbyg8OyShecsrKL0D/FISLi43p8fI40/cRh6bjB6x4SVT+hcO9f14l3iM YWshxbWW6QGUN2idD4uK2rs6Ttlx3y93ResBsg1AfamXsGbZ/VpY5e1nR28Al6hmtGrtUoqb d5BBye40pWNT1FSiP4qcSN65kh1XVNRuw/D7nNM93WsA6U5SiVw+cqrXGZR5dF0rIU3dgsY/ nbL7gZ/x4FqTK1f4e4b7K7eJbj7/wk5FCCGEEEKdqFPu1E5FlWR9X1NbVVmoNV31NrS1aKHt +RBCSdVZnYpS4p7ekbBTEUIIIYRQH+oU7FSUEnaqQdipCN2/sFOXF/f0joSdihBCCCGE+lCn rN1O1Z7yQ3W0Bjt10r6xNYWditD9ynksmhvNwsJO7UjYqQghhBBCqA91yqrtVLSk0jsPNlV2 n9bbKbf5bFUF2y/e0MNFCKElFfTqONfNhZ2KEEIIIYT6UKdgpyKEEEIIoauwUxFCCCGEUB/q FOxUhBBCCCF0FXYqQgghhBDqQ52CnYoQQgghhK7CTkUIIYQQQn2oU7BT0VuUZaKIEEIIIU3m oWbzIThCCCGEEFqvOgU7Fb1FNZ+FIoQQQquWeajZfAiOEEIIIYTWq07BTkVvUc1noQghhNCq ZR5qNh+CI4QQQgih9apTsFPRW1TzWShCCCG0apmHms2H4AghhBBCaL3qFOzULvV9HIbN51+W wxw+7H6Exxw+fxiGx337HF21/zgM774c2obRfBaKEEIIrVrmoWbzIThCCCGEEFqvOgU7tUtZ 7NRfu3fD+DWT1M3s1MPnDwb/93+v2KkIIYTQHcg81Gw+BEcIIYQQQutVp2CnrlU/vmyam5KO 7HZqF2o+C0UIIYRWLfNQs/kQHCGEEEIIrVedgp26VmGnzlHzWShCCCG0apmHms2H4AghhBBC aL3qlDXaqfuP3o6hs1y8r49OSo9716M8ffVh9+P4yPwZ0cT88WVjCck/bPz6a/fO2/DUPZGW iBeMunGqu61q8mF/rwQ+7H58H/3js6UdHKAe6eY9ZQT/2r1zUvn4Xcr74947b/luBs1noQgh hNCqZR5qNh+CI4QQQgih9apT1minCnaeb7oZdfj8wfP1jn6f5/T92r37MH70D/v6GPp3Xx8D N1PcHjTaxvToGwrvj3q1LPa0rk4N7dGw6LxEjiZsyp3USrtgdWoi8h9fNoO3IWxYR+ccjR+v dq10TE7NZ6EIIYTQqmUeajYfgiOEEEIIofWqU+7ATk07hgkdPn8IncHQ6fu1eye5hz++bK4f hitML4l79qLsIcq/FX4ea76d+vVRMkazhSkfUMNOVUojjDN+T5dajKqaz0IRQgihVcs81Gw+ BEcIIYQQQutVp7xlO/U1enDeXRd59uniD4+fn8+omYP+56Vbi97ATt1/FLM2McEKdqqao+CM cQDYqQghhNBtZR5qNh+CI4QQQgih9apTVmmnett9Tt09U9Cv3Tvjskfnc387VC2qUu9yeTvV bEHaSruCnSqvlo2zgJ2KEEIItZZ5qNl8CI4QQgghhNarTlmdnRrtQJpwDCcoMOZmrE6Nwl7j 6lR7abM6FSGEEHpDMg81mw/BEUIIIYTQetUpa7NTReNsmp0q/kqwU3N7p/5v/9Hg5SleobB/ 6/nzRnun/m9/fctTQWnfdu9Uq5163swhCrj5LBQhhBBatcxDzeZDcIQQQgghtF51ytrsVNfs O3ttEx/2F95iH5mbv3bvPowf/RfH//iyERZsRis9vz4Gie8/DkP8nisl8lvYqYJZ/H0cvCAL SjvI748vm/CFUYbI47L9+jiEB9vt1GMJS7viNp+FIoQQQquWeajZfAiOEEIIIYTWq05ZnZ3q emTDyfs7GqOKeafq+zg87oOdT8PVmmefzts/VNuK1N9fVNse1CEMWNil9Ei0YFbAjUo7Rlhp a3kZl7G0/aQEx1kkTCeoEb8Y3VOcfugWmpo7VqcihBBCVWUeajYfgiOEEEIIofWqU1Zop95S 5ZtyolWo+SwUIYQQWrXMQ83mQ3CEEEIIIbRedQp2alLYqXeq5rNQhBBCaNUyDzWbD8ERQggh hNB61SnYqUlhp96pms9CEUIIoVXLPNRsPgRHCCGEEELrVadgp6oKdjKN9uVEK1bzWShCCCG0 apmHms2H4AghhBBCaL3qFOxU9BbVfBaKEEIIrVrmoWbzIThCCCGEEFqvOgU7Fb1FNZ+FIoQQ QquWeajZfAiOEEIIIYTWq07BTkVvUc1noQghhNCqZR5qNh+CI4QQQgih9apTht8AAAAAACW0 HsECAAAAADQDOxUAAAAAymg9ggUAAAAAaAZ2KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgW AAAAAKAZ2KkAAAAAUEbrESwAAAAAQDOwUwEAAACgjNYjWAAAAACAZmCnAgAAAEAZrUewAAAA AADNwE4FAAAAgDJaj2ABAAAAAJqBnQoAAAAAZbQewQIAAAAANAM7FQAAAADKaD2CBQAAAABo BnYqAAAAAJTRegQLAAAAANAM7FQAAAAAKKP1CBYAAAAAoBnYqQAAAABQRusRLAAAAABAM7BT AQAAAKCM1iNYAAAAAIBmYKcCAAAAQBmtR7AAAAAAAM3ATgUAAACAMlqPYAEAAAAAmoGdCgAA AABltB7BAgAAAAA0AzsVAAAAAMpoPYIFAAAAAGgGdioAAAAAlNF6BAsAAAAA0AzsVAAAAAAo o/UIFgAAAACgGdipAAAAAFBG6xEsAAAAAEAzsFMBAAAAoIzWI1gAAAAAgGZgpwIAAABAGa1H sAAAAAAAzcBOBQAAAIAyWo9gAQAAAACagZ0KAAAAAGW0HsECAAAAADQDOxUAAAAAymg9ggUA AAAAaAZ2KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ/x8E6waq+6ElzwAAAABJ RU5ErkJggg== --------------060805070008030306070203-- --------------000109040106050907030608-- From nobody Thu Nov 20 00:30:41 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39F81A00F6 for ; Thu, 20 Nov 2014 00:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.493 X-Spam-Level: X-Spam-Status: No, score=-14.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEQ8CWgj01yC for ; Thu, 20 Nov 2014 00:30:36 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40B71A00F2 for ; Thu, 20 Nov 2014 00:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37147; q=dns/txt; s=iport; t=1416472232; x=1417681832; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J6nfrkrTeM8PiUqQYzYnkzq/SqfEnHyTImmUaE7UZNw=; b=IqsI9621aPm5hEAqJ4YakcgRtqc+Tq0oPtM93pt0Prjtzl+0h7eaMD0M AY/kUvHWz8iNzzeclUAOhaB9PYI0da74tOcCNcm3sYjsHVH1eaTIN2skW 5JPxkHktCGt3bejDuhzS5ZeaF2j6ih8KEXi3kOvNb8uhu9SQbUxHeUZkY w=; X-Files: bgfaccjg.png : 19447 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwGAKmlbVStJA2K/2dsb2JhbABagkhGVVkEhHe1V5Byh0cCgQkWAQEBAQF9hAIBAQEEBWYHBxACAQgRAwECBgEBARsEBwIVAQ4MFAkIAgQBDQQBBggNiCYN1AoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkG0KDAUHBoRFAQSQLYFVVYIhgVIBaocsgXCLN4lUgjaBRW0BgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="png'150?scan'150,208,217,150";a="98436424" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP; 20 Nov 2014 08:30:31 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sAK8UVTX002882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Nov 2014 08:30:31 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.134]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 02:30:31 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: "Benoit Claise (bclaise)" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" Thread-Topic: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship Thread-Index: AQHQBDIW9jh9SimcRUm69VAcj2zNTZxpDpEA Date: Thu, 20 Nov 2014 08:30:31 +0000 Message-ID: References: <546CF473.70201@cisco.com> In-Reply-To: <546CF473.70201@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.85.101] Content-Type: multipart/mixed; boundary="_004_D092E3B616C87rpazhyanciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/gdNRY6uUG3afA0K3MUKFycNod_Q Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 08:30:39 -0000 --_004_D092E3B616C87rpazhyanciscocom_ Content-Type: multipart/alternative; boundary="_000_D092E3B616C87rpazhyanciscocom_" --_000_D092E3B616C87rpazhyanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit But now I wonder: why do we have two different drafts, as opposed to a sing= le one? This is a good question. Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel does not prov= ide a complete solution and needs something like draft-ietf-opsawg-capwap-= alt-tunnel to complete the solution. The best answer I have is that we wan= ted the keep the following two areas separate (and in different drafts) 1. Discover and negotiation of alternate tunneling capability. These are= independent of specific alternate tunnel method 2. Definition of tunnel specific message elements. While draft-ietf-opsa= wg-capwap-alt-tunnel contains message elements for most of the tunneling me= thods defined in draft-ietf-opsawg-capwap-alt-tunnel, I had anticipated se= parate drafts for each tunneling protocol. Finishing 1. would allow 2. to be completed separately and independently in= potentially different drafts (and potentially different groups with releva= nt expertise). It is somewhat akin (though not identical) to separation bet= ween RFC 5415 and RFC 5416 where RFC 5415 is wireless technology independen= t and RFC 5416 is 802.11 specific. Hope the above makes sense. Regards Rajesh From: "Benoit Claise (bclaise)" > Date: Wednesday, November 19, 2014 at 11:50 AM To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >, "draft-ietf-opsawg-capwap-a= lt-tunnel@tools.ietf.org" > Cc: "opsawg@ietf.org" > Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-= capwap-alt-tunnel-information relationship Dear CAPWAP authors, After the draft-xue-opsawg-capwap-alt-tunnel-information presentation at th= e last IETF meeting, I've been wondering about the relationship between the= two drafts: - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types Note:this draft is currently in AD review, so close to be sent to the IES= G. - draft-xue-opsawg-capwap-alt-tunnel-information provides the encoding of t= he tunnel-specific fields. I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel doesn't = provide a complete solution without draft-xue-opsawg-capwap-alt-tunnel-info= rmation? I'm aware of the changes between version 3 and 4 (attached picture and http= ://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-capwap-alt-tunnel-04.txt= ) [cid:part1.06060400.02040901@cisco.com] But now I wonder: why do we have two different drafts, as opposed to a sing= le one? Regards, Benoit --_000_D092E3B616C87rpazhyanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Benoit

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

This is a good question.  
Yes, you are correct that draft-ietf-= opsawg-capwap-alt-tunnel does not provide a complete solution and needs som= ething like  draft-ietf-o= psawg-capwap-alt-tunnel to complete the solution. The best answer I have is  that we wanted the keep the following two area= s separate (and in different drafts) 
  1. Discover and negotiation of alternate tunneling capability. These are  = ;independent of specific alternate tunnel method 
  2. Definition of tunnel specific message elements. Whi= le draft-ietf-opsawg-capwap-al= t-tunnel contains message elements for most of the tunneling= methods defined in  draft-ietf-opsawg-capwap-alt-tunnel, I had anticipated separate drafts for each tunneling protocol.
    3. =
Finishing 1. would allow 2. to be com= pleted separately and independently in potentially different drafts (a= nd potentially different groups with relevant expertise). It is somewhat akin (though not identical) to separation between RFC 5415 and RFC 5416 where R= FC 5415 is wireless technology independent and RFC 5416 is 802.11 specific.=  

Hope = the above  makes sense. 

Regards

Rajes= h
From: "Benoit Claise (bclaise)= " <bclaise@cisco.com> Date: Wednesday, November 19, 2014 = at 11:50 AM
To: "draft-xue-opsawg-ca= pwap-alt-tunnel-information@tools.ietf.org" <draft-xue-op= sawg-capwap-alt-tunnel-information@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" <draft-ietf-o= psawg-capwap-alt-tunnel@tools.ietf.org>
Cc: "opsawg@ietf.org" <= opsawg@ietf.org>
Subject: [OPSAWG] draft-ietf-opsawg= -capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relat= ionship

Dear CAPWAP authors,

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

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

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

Regards, Benoit


 --_000_D092E3B616C87rpazhyanciscocom_-- --_004_D092E3B616C87rpazhyanciscocom_ Content-Type: image/png; name="bgfaccjg.png" Content-Description: bgfaccjg.png Content-Disposition: attachment; filename="bgfaccjg.png"; size=19447; creation-date="Thu, 20 Nov 2014 08:30:31 GMT"; modification-date="Thu, 20 Nov 2014 08:30:31 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABxoAAACzCAIAAAAxAI48AAAgAElEQVR4nO2dO5LbuPe2uYlJXOVy 0lUKJnbkpCdWQmczqfNx0JkVO/i8AQcdW8l/CxP0Bn7airfQX6AbLucAByQogOrnqbfKZYkCDy4E gbdBcPgNAAAAAFDCKwAAAADAW2VoPRoHAAAAgJXRegQLAAAAANAM7FQAAAAAKKP1CBYAAAAAoBnY qQAAAABQRusRLAAAAABAM7BTAQAAAKCM1iNYAAAAAIBmYKcCAAAAQBmtR7AAAAAAAM3ATgUAAACA MlqPYAEAAAAAmoGdCgAAAABltB7BAgAAAAA0AzsVAAAAAMpoPYIFAAAAAGgGdioAAAAAlNF6BAsA AAAA0AzsVAAAAAAoo/UIFgAAAACgGXdop748PQzDMDw8vZT8YPu8aFBd87y1FNepXC8IJdZhSdry ti6et8lauMnJZ5WpmwE5rQ5bEhi4x8utOqstJMMt4M4oHky8OVqPYNfCYbcZhmHY7A4lPxj3iwbV NfvRVFz70euThF90WJLGvK2KUwvXamFZTq1g1nlX2ZLAwD1ebtVZbeN2O55hWGceyigeTMBNWJmd Gs7nNFPm5ekBO9WMZXr/vLU6rrcoyeet9TSrtS4s2IuhLkWXl/DjfNRv/ppcKXd6udW90FZaSKZb wB0yq7e7e1qPYHsgnM9ppsxht8FONWPxQA67Tb6MblaS9vq9a3+nqJn3ct6+WhJU5U4vt/1YszGu tHHvx3us2jytelnQWZ+dep3ZuHPcYMrDDKgyrYw7hc7CacUa7VQuTVgd9DdvuAzosVK0HsH2gDez cee4wZSHGVBlOivQzsJpxRrtVKoOVkddO3WdvNkyoMfqD+xUsNDZXLqzcFqBnQpwA+hv3nAZ0GOl aD2C7QHs1EZ0VqCdhdMK7FSAG/BmrUSHN1sG9Fj9cS926u/nrWCnOns0SjNB4x6U3g4DD08v0+eV 3p6R22c3N86WlOH5MhHpT2D6h/nnC7/XEgm2uVSKy7ybp5ecUJa5XTXV3R7Cs1ryJpWR9N32+Xeu KRmpfDalJTpnuX4tfjgh6u2zaDDkm6RSdcGhmZZUUki2qyRxTRaQ3w3WTNhy3Swr5wuyX7WQLgcc vwv+qwWtk+sBzBgSSl1uSo8bBG/ubywNIFdIJfWWbADeAcfvgv+WYLsFhAfGGbS1JCupu3J8ySSz n2lJtsHEW6X1CLYHVDv1dT8KdqqzR6M0E3S3cEzNFL2tHsf99OlVIiFnS0pvRwPxTP6eB2ow/mFx 4JY9OJXtFYLDrSXpl8Bmdwjn6NldNYMD1COt+4uGZSR9N+5fc03JSOWzKS3ROcv11+KHE6Ie9/J5 /YoRTlGlJZUUku0qqXNxV9xVMmy5bpblqKOzyZ3JtK7kcsDxu+C/WtA6uR7AjCWh8Bjhu3QhqbvL KEWeLoOKjTt7uV0OOH4X/LcEpcuNE0qVdt2QXl+ju2Twx9Ug4eS5MvdJ22ACbsnK7FSPxEQ8eoPE y9NDYtqWSOl568+ejpOqCfOpMIJjiKG9+bDd+oeF5xd23hO34os2nxTO5504Pae1mh6p48TAs36h NgG2VkEib2IZhQc/b4ft1tk1MN2S0oHUPlu63YqGRnHoQRW8PD0MD9vtQ7oFJnaHtMaQzlu2kEwh Ga7JaWjttvSHz9theHgICky+tAV/r04hnX/98PTsnEfbATdZvRN6gMkJmS63c497OU6puGLPN90A UoVkqDdbA7gG7pbW9A1Q02Ug1ojaQCwtKRNL9q4sxCt/ZGpJ9sHEG6P1CLY7EhPx6A0Sh90mMc3P pBTMreS5Yg5DQofdZjOO/mH7MZy9RdsTivsVRvvzpQLPe0hWlylljoiB541sZQJsrYLEoWIZhQfv x2EcnV0D0y0pHUjtsyXyJm50OMUrDKrgsNsMm3EUfPmosckVW6ElWQrJdJVUu7hDJjeSoLT34zBs NkGB2Ur73JlcPheuJVtXck5tt3fOo+2Am6zeCT3A9ITEY4JTWQrp9HFZkFrHlU/P0LgLLrf9OIx7 tySmb4CaLgNLadcLKUxcakdCvMJHhvtk4WACbsAd26nxkq3kFNZuS01bT2UISZkVvzw9eIsM5SVk kTGbPyr/xYX5dqr8TTbdiT+7Upppab1sZGeVT6YXOVuqGIT2NsFK8Rd9y0GWNbY6dmqmkIwhFXYT JUzqJKQfSX6P5YqoVkjnT22+Z6L8Zl/KBQkZLzehxxUTrxZkMrrz7zL1VlKOz9s6fx9QT5D6Tsym uSVlYsnelS12qqkoF+wl7oDWI9juyJigwsxZmwLVS0nHkJAyKz7sNt4iQ3kJWWTM5o/Kf1FwxBG9 JOVvsj6FfEANO1X5QlovG9lZ5fW/yNky3wnuWblvoawyCyx/e9XWsVMzhWRs/9Uu7phJ6WgLLEOf ylLaQmcSHFPSSRwtJYOlmHb4aziVtoRs/Ua+kCoHmf8y37hLynE/1vn7gHqC1HdyW6gRktCTRSFY 7FTTJbBgLwETuV87VVqINMWWCh92nDGNCp4cjU6ZWPF1/thmUpXO9m5gp059pncxO1XNc5B2fKop c+llzpZtt+HSy8IqMJVdYQFXWp2aLKSCkHLX5FSmtHfRuw6D1hIWjPlqhVTQ5vUDp/YAUxKyXm7C cR3Yqel6szaAbBSFFF2QR6R8Vvx7RfqubLBTbaVTOJh4Y7QewXZH2gQVVqJNsVNfowc+pz/pl0so seLr/LGWC//z0tneDezUqc/0LmanqkkEZ4wDmDKXXuZs6UgCz0FrXROi9j/XqnZe1WUW8CULqaDO q13c+VNlEb3rMCVraQsB+IcUXRjm7OgHTn6qf0pC2jH5htKBnZpu3EWXW7VCL4z5iNgYKoXkb0Eg 27Y5O9XWqgsHE3ADsFMzKUnH1pmhxo8MGgwOdS8/zwoqnUQvb6ea55/+LFmzuCrYqVbjt46duszZ MsXgGahTnvK12qmGJplNM2SmnVoSkpfOxL+X2NptEpv/LJzoTGYN45xCmm+nVnOgLAlZL7eKdmpJ A5hrp5oagDVwK3pSRXW+jBMp3JXzdqoxFOzUFK1HsN1xKzs1SrrOcp84IYPBEbg/Ht5OcUUz1uXt VPP8058lB/kqT04/1Gr81rFTlzlbJhLPQJ3ylK/ZTtUoWSIdMNNONVwlAtMvbuGUpQkpJRO7aabS ttip9kKab6dWc6AsCVmjqGin2jqufHoWO9V+ud3ETi2r84oheYkKa/FzdqotFOzU/sBOzaRU4XAd weCYuDo1mW5pHAI3WZ0qbXbA6tQ57fbioU5Ympo4t2l1amGaIUusTq0Zn/8TY7tNM2t1apxYzUJi dWru7xYlDWCR1anG1CbT2erUbBCsTr0JrUew3dHGTs0kVUT+qcLz57nVqfMC7GR1qrTZAatTp9up joc6YWlqIn3b6tSyNEOWWJ1aM74gIGF/y9uuTs38LP5pUYSsTk2d0t5x5b+cvDq19ESldLY6NRsE q1PvGOzUZEryj6ZZJcJvpPVi4lHOh7Lnkk7YPYHi1y5tp2rfOIsmxSgWs1O1L4ofmp4Vxryz5Yvh VONTlqaeziC3/+B1aQWJ38JONYZkuSYNFLTbCQGFhR10BwVpTSsk5bcTDsz3AEYMCRkvtzp2anED mGWnWhtANopCUknJ383bNkLHdlc22Km2JomdmqL1CLY7bmGnit9UW54oLaoTj/I2BZzupyb82qXt VO0bZ9FkweS7gp2qfZGflU+aSy9yNlO9DeN+0tLUUzzyY7ThNgJ2g+QWdqrxKql1cUvpTGokUkKR VWssbYNTaCokNbXiA/M9gBFLQrZ+o46dWu4azmrcJZfbbezUol56fki2dA12qu0+iZ3aH9ipyZRe hFd9T7OmnuN3D0fm5svT8T3TmRWr0nYD0WeSCxMG4J14aTtVMIufg/ekhCV7eqxVnqgHht6UvMVl K9RtJTt1kbNZauV5Ozw8TFmaqgT5vB0ettvImDM0ySO3sVNNIVmuSQv2dlua1MvTw/DwEOZN2pIg +qxWIam/lUkdmO8BjFgSMl1uVjs109+UNoB5dqqxAei5mUY6qahwp//pLovxrhwv/I/rxNiSsFNV Wo9gu+NGdmr41Oa0hX6WhA6743umMytWhQcb488kF0Z9/vQWdqpgFu+Dl5KExsrpsVbFOokeXC5+ yDguW8HaqWSnLnI2SyT7cdhsprRYJcj9OGzGMTiv9JC88uD8bexU01VS6+IOf3QIXwVuZx/vd7vZ hHkzlbbJKTR1JUpqMpnmmukBjJgSiq4uoW6tdmpYuvtxCDZXsXZciZNoX8VB2i+3G9mpttKuFdLx +srUtrTwX6gTw30SO7U/1minxpv+SXNZd0IrfJTYOtCZXR2nTc/ebnVTl/kN2+fgnOFs8zxJ886n PUWZKAGpJOJDnrU9+CLfIH2IrSTFQzPfPzy9nAMQjYKZeRMCih2B4BupJdmpcbaC0nZ+MMtTiYr6 HEPw3HSyqLW4k2kkc5+tklxIlmvSRkG7zRJe/epaPLUcaxaSciVFRqWMuDhxfnEbE0pebkKRCOWm 5FF6hD34OmoA+UIqqrdUA1CvpCn3LsstQDpQsukFJrQA8105rDP5oky1JONg4g3TegTbDYdo0z9p LjsMw2VWJHwkpBIecfrluA8OnTQZtCR0nqR5u+NpT1EmSkAqifiQvbYHX7RgNlNGtpKUDs18v9kd zlHG+fMPFWyibN6EgGJHIPhGakl2qpzNnDc33VkGhnfGze5wCTV2tFyihWBi1GUtqahKcldJtYs7 zPy4l4uoPKljSsoKYbUc4yIRyu1EppCU1hb9XUAmd9nOaJeWhIK49KBzhRSmFX1r6LgqN+705aac bKLDb0sqWdo1QzpeEem7WxzR9SfpO+GUwQTcmDXaqXcLa16gPpMf9IcuoFcAgE5pPYKFpWHNC9Rn 8oP+0AX0CgAADtipHYFxArWZ9PQ6dAS9AgB0SusRLCwNxgnUZtrWFNAP9AoAAA7YqR2BcQKVYWnq ylF2oAUAaE/rESwsDcYJVIalqStH3MkUAODtgp3aCZmN5wDsxNsU4qmuhmq7iwIALEvrESwsSWbj OQA78XaHeKqrodruogAA9wh2KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ2KkAAAAA UEbrESwAAAAAQDOwUwEAAACgjNYjWAAAAACAZmCnAgAAAEAZrUewAAAAAADNwE4FAAAAgDJaj2AB AAAAAJqBnQoAAAAAZbQewQIAAAAANAM79Q3z8vQwnHl4emkdDqye522llvTy9DAM2+f5Ca2I0+W4 titxpWFDVbiXTOF5myqs5+3g0mexth7Bwr1x2G0ubX6zO7QOB1bPYbcZhnHfUUIr4nQ5ru1KXGnY UBXuJVPYj6nC2o/esJRivYKdCr9/vzw99DlX03jerslr86bFp4J27YfejUN781ifnXrbpp89W9Vw ql0ltw0b1szqmkK7e8nL04N+6uSXHdF6BAt3y2G3WddcbV0Be9PiU9yu/dC7cWgv7fXZqbdtSdmz VQ2nWmK3DRvWzOqaQruAD7uN3sclv3zzYKcCU+DFUefGq5g0r655FICdagA7Faysrik0u5c8bxN/ MVpNMbYewcLdwhR4YdS58SomzWsr7RKwU2skdM8tBIpYXVNoFvB+TPzFaHXFeFuwU2FFc7cza7NT 1ac6sVMbg51qADsVrKyuKTS6l7w8PaQW8q+mGFuPYOFuWd3cbXUBa091Yqc2Bju1RkL33EKgiNU1 hUYBH3ab1OP7qyvG27ImO/X0zPTD09P2+tz05aHpcErkP02tTU2857C3z+Ikxkvp4eklnn/551LX nLgn2z47GXrRkpozo/J3XkvOGNNzt0RCNavEKQ3nwOCosKRT+cvX2+1w7FTvOfbYZq3VADIb751P 47RDoRiDRLKp5UMONz4IKyW8RsRfB21EPGf2mrTmrU6VGM92uhL1GpESiyIquUpuGHbFTnlulXAv KYJ7Se17ieqmKlHleiW1rzx/Ffy3Gq1HsM05PTO92e1OD09vdofrQ9OhKeU/Ta1NTbznsMe9PInJ HuSfS11z4qYz7p0MHbSk5syo/J3Xkp5deu6WCKlmlTil4RyoHBUhxO+dbrM77Md2zqVjp3rPscc2 a60GkNl473wapx0KVWYu7bBp28ISKiWdkNxG8rUvJWZvSTWqxHi205Wo14iUWBxRwVVyw7Ardspz q4R7SRHcS2rfS1Q3Nax/NabcdjGX3B2/Cv67ctZkp/7+fZ5DuBOE4zwjWOUX7eEobeoYzmiOaQdH hU/kHU+anpJIU6Xgs5enh+HhIVyZaArbQrT1ZHovSn0KbEiocpU8bLfO75QHIvOz2Sn1tiDXwjjN gq//CaOs0gAixIJ83g7brWPoKnP8gpVSyUPF3GmVolbxuY24KSWfmz3/SizIbN6qVollmefgdUKZ RWyXiBTX9XarU/NhV+uUK1UJ9xIT3EuWuJfkeqz0JScWpXj883bYPrvFk377VTmtR7BdcJxDuBOE 4zwjWOW3H4W5muQouZ8d0xZmt9mDhCAzJzvsNsNmE65MNIVtIdp6Mr0XZWIKnA+pcpVsxtH5nfJA ZH7tTvjDY2TNppLXwjjNgq//CaOs0gAixILcj8M4OoauMscvWSmV8hnE3GmVoiZ0biNuSsnnZs+/ Egsym7eqVWJZ5umbJ5lFbJeIpNzfdHVqPuxqnXKlKuFeYoJ7yRL3klyPZXClwzoRj9+Pw7h3iyf9 9qu1sEI79ToZcCdC7hfyVCT6VHjQOv6lMPswuBRhOuoCq2BKNM/LykSox62ew5JQ7SqJbQFx5U1+ Cjyh3pbjfPKXpwfHwvQLoF4DSEXgfzREFSCug6pgpxY2ypSdKjkRL08PWWOqvHQrV4nJl8z2STGl F3whNcKu1ilXqxLuJRa4lyxxL8n+lSRVVcp3Wu4q/UFOofUItgu8WYbruLhfyFOR6FPhQWt5sVD2 oHSYyk+kKdFML+uMbEXpTpd6DktItasktgXiqE1TYMHOabcy53zyw27jWJiJknxNfzo9Av+jIaoA cR1UBTu1sFGm7FTJiTjsNllDtbx0K1eJyZcs726UwrqtnZoJu1qnXK1KuJdY4F6yxL0k+1eSVFTK d2JM+zHr2K+Re7RTtZmI8HnwZJ1q7DiYpiaxA5BfPVYQdgZtrpdc8KcubcklVLNKhOMmToF/T6q3 5ThPyY//+v87HVKvAWgRCHaqxburYqeWGhBJO1X6JuenTnGYaleJxZeUVtmtwE7NhF2tU65XJdxL DHAvOR9U9V6SXU6fqKkiw3rxvyG2HsF2gWW+pc1EhM8P/pN1lidUTdOo2AFQntl1Pi4IO4M210su +Cs5tfd5zSoRjps4BX4Nn+VsPKU8T8mP//r/Ox1SrwFoEQh2qsXeqWKnlhoQSTtVWYs54Snk7Cqw qlVi8SWlVXYrsFMzYVfrlOtVCfcSA9xLzr+sei/JLqdPRKV+JWWv6d8Ql+NO7dRBIzeFyc+UxImQ cEo3IWVOE02Bp4UthqggZy8xBc4nVLNKqk6B47y0W5x6NgFP/unpf74zWK8B/P79W6y8hnZqsZFT 7NcIdoqh9Wft1JpVUs1ONdTt7+7s1GklGXbK9aqEe4kB7iVKoSz7rH/qkita0I+deguM8y213eam MPmZkniQcEr3GGVOE02Bp4UtpatRsnDIGFLNKqk6BY4LpeHE8mQCnvzT0/98Z7BeA3h9fRVbQUM7 tbjGZvs1mWvSFFflKqlmpxrq1nK2G4ZdrVOuVyXcSwxwL1EKZdln/VNRFf3FCju1C+YsXylOXyOY oggbt9VcUVRO8RSqdEWR/uOZVbLgFHjyr+pwdE4v+Qv+ez6k1hJa4UHXt7U6NX9NZgPOf1tODTvV WLfqpxNYcHVq8enrVQn3EgPcS2RmXltCPfuwOnVNzFm+Upy+8SBh47aaK4rKKZ5CzVrMVLNKFpwC a0ndiKNzeok7+O/5kFpLaA/CA/FvanVq/ppMfmr7tpwadqqxbi1ns7Lg6tTi09erEu4lBriXyMy8 l2Q3smV1apJ7tFN//37eGiZc4kTDZAL4v5TSMTx4KNgiprAtKFPu1PHqUqNsQhWrpNoU2FJv7sfD sPhuAM/bwX0zyvN28F8DdfywThBi9hvbqYnSL7NfJDvxd+ymZq/JbMCnlGq2i6V8yf7t1Iqd8iJX CfcSBe4lJfcSM7nlqalLTvmuollcQOsRbBdY5luvr/vRMEEyza0MB0mHGB48FGwRU9gWlCl36njl zIaQKlZJtSmw/L2+sEtfbFWN/Ti4b0bZj4P/GqjjhwvaX43t1ETpi4nP2jvVck2mPnXDqNkulvIl +7dTK3bKi1wl3EsUuJeU3EvM5JanpqJSvtP2TsVObY9tviXPVoLPnuP380YL317k90pHq8WChwwF dy486nkrvI3ZErYN6VlT/fnT9FKYTEIVq8Q8BQ6jet76VWmpN++3y/upp9Ncggz/f/20QgMI8yqf zGqnhhG8PD2UPup7+Vng+ejFnnzYf7uNnwAPr8H8NWnLW7Vr0nI2gy9prNvf+avkpmHHqUifWTrl WlXCvcQG9xLzvcSOXoCX79Or5oOcFP9VqhatR7BdYJtvybOV4LN9/H7eeOGb4SDp/7E7Fx61H4W3 MVvCtiE9Rqo/f5qau2VDqlgl5ilw+MPDbuOV+EF+H7jm26UeXq3F6TSXoMP/Xz+t0ADCvMons9qp udJOJ+n/LPB89GJPPuw/jvET4OXXpC1v1a5Jy9kMvqSxbi1nu2XYcSrSZ6ZOuVKVcC+xwb3EfC+x oxfg5fv0qvm4cZX9VWrdrMlOdXdf2z5fP3h4erlMPJ25w/mTC8F043l7fNzaPSSceRwnNf62b4rd 5CUSRxMG9PD0os/uUmFPKy8hd9HX6gn1hGpWSZSWd3g6KNnLydabl9LCq1OjWbnmJdZpAH4qp9bm pCaUbVwBWnKCcSMiLnQd9ISirEsHno0G76zisiz/e/GazOZNjmtGW9HPJpS/XCW5utVKYU4LrxB2 nEwck6VTNiWUgXtJGdxLar/XUPFTtS4w02uJNrWlPmbTegTbHHcbt3F//WCzO1wmns7c4fzJhWC6 sR+Pj1u7h8jPyuUO8iIbhnEvRBMGtNkd1MUyybCnlZcQuLornrz2STyiZpVEaXmHZ4ISXUE/h8lJ /pxythHNyjUvsU4D8FM5tTYnNaFs4wrQkotLe5CRltolvjcldDYavNqdek1m8ybHNaOt6GcTyl+u klzdFuXtdmHHycQh2/pbQ0IZuJeUwb2k9nsNFT9V6wJzPankd1vqY6WsyU69OxZfOQJwdxRsPQDw RuBesjomL3HvitYjWKjNna4cAViQao+wA9wN3EtWx+Ql7oCd2hKmwAClYKcChHAvWR/CNhbro/UI FmrDFBigFOxUgBDuJetD2MYCbGCntiK3eRoACGCnAnhwL1kp8/dgbU7rESxUJbd5GgAIYKcCeHAv WSnz92B9o2Cn3pDq+68BvCmCnRdXv7QLYBrcS6ALWo9gYS7V918DeFMEezSytAveKNxL4A2DnQoA AAAAZbQewQIAAAAANAM7FQAAAADKaD2CBQAAAABoBnYqAAAAAJTRegQLAAAAANAM7FQAAAAAKKP1 CBYAAAAAoBnYqQAAAABQRusRLAAAAABAM7BTAQAAAKCM1iNYAAAAAIBmYKcCAAAAQBmtR7AAAAAA AM24Qzv15elhGIbh4emlcQTD9ln7UvzG43k7uMi5MR0E94Zb7fmWlEnp9o3meZtoqpa8na+vGW0+ eYneiFNW51SAWxJKdpKlvRTzi9fYTUKf9HB9wS1oPYJdC4fdZhiGYbM7NI5gGPfal+I3HvvRu9/I uTEdBPfGuX3Nr/P92KDR7MdE2G6T1q6SCvlPXqI34pTVORXgloSSHWN/U5f5xdskbKhFD9cX3C/r tFNfnh7SDkH2gOV53k63U1+eHvITUdNBfaGVSed0G/b8wF6eHm5uttkMPkveZl7mHdTrrByYzPAm dur5zNipTWncwDu4vm5JB4OOBrQewXbEYbdJmxDZA5ZnP063Uw+7TX4iajqoL7Qy6Zxuw57fzA+7 zc0N1aSd6h5luQTmBN9Bvc7KgckMb+dLzipe7NQKNG7gHVxft6SDQcebATt1KWbMJU3Rd5DFYlY6 v+427BqBNVmgagA7NUcH4SfpPb77Bzv1lqzxjjyf1iPYjliznWrAFH0HWSxmpfPrbsOu0QaaLFA1 gJ2ao4Pwk/Qe3/2DnXpL1nhHXivYqUuBnRqz0vl1t2FXCex52+UyQOzUHB2En6T3+O4f7NRbssY7 8nxaj2A7Aju1iywWs9L5dbdhV2kD+7HLZYDYqTk6CD9J7/HdP9ipt2SNd+S1sjY7NdgtVNtC8TSz cY6W53V+cnPmfm5KD08vwlzSsCtkuBWimDnTQZa8XQ44fhf815qQswOkE1lcH3K9lRW5fC7pYWZr 3oLIgq+LwvaKSZtXh6eTpuCmhM5HpgrQS0g+1/mwGc6/GKn0edmWpze0U3NXpl9p1fY63T6LOcif TekE/dBzpe3ubpnrJ03dZL4HNJGpjJKwy0+oXCWpKlECkkIy7HRr7Lhym2YXdFz1GrepAST7W/Uo p1KiHYcvx0ZHPG2vX1yOCk+Zzr+tuRlHJdHpHp5eVm85tx7BdkGwW+iFYB5zmtk4R8vzOj+5OXM/ N6XN7iDMJQ27QoZbIYqZMx1kydvlgON3wX+1E4bncXaAdA6M60Out7Iid3fk87IXJWPNWxBZ8HVR 2F5A2rw6PJ00BTcldE4t9X1QRNrRs/xU7RITPi/b8vSGdmruykxfACV4KY17MQf5symdYBB6JlfK tSSWuambzPeAJiqGXX5C5SpJVYm9TzLtdW3ruHIJFXRc9Rq3rQHM7SajHYcvx0ZH7MbrF5ej9FuF 9LWtuRlHJVHONrvDG7Oca7E2O/WIZXXqMHd8a3YAACAASURBVIRzLsnic6cyk7frCxN/3g7DdqvO k7IzqPmrUwvy9rwdts/uBove09+2hF6eHh62W2crV8WhqzF3PJ8rKnDZm0jkTc6cUKj5sKMNKqWI 5LKMf5dNyBJYmBXhXLZz5FGj0PYRMLXvG9mpW7/A451GxRqZdNagmF+eHoaH7fYhX//K2YxXU6qQ TiXgOd5TusnCHtBEInuGsG1YrhJLlZxbUli92ZtUqmr1jks4XO//EhHUa9ymBmDrbw3dpPxHiLgi XUv6+G2w4bgt/8bmlu+Nwno6RoadeidYVqfGcy7J4nOnMpO36wsT34/DMI7qPCk7g5q/OrUgb/tx GPfudpb+09/RRpfSzpeH3WYzjs5WropDV2XuuB+HcfTT13YAzeRNLCUhnXzYYimJtnRUKZnSTXqd iTYQZkU4l+0cedQotN19Te37Rnbq6Bd43LpNF4D1dFGjHcdNvv6Vs1mvpsRxpxK4nGBqN1nYA5qY F7YNy1ViqZKCPilIWf0zX6rjsiaUbSHVGretAdTqJuU/QsQV6VrSx2+DLsl2nzQ2t3xvFGb3GBl2 ajl3bKfGM/5w4lTH8Ht5elDW/DSzU0vy9rxVbTZzQkJuxV9WslOVRVbi+ZILRZWlf8IC3GTY8vfx BD87BTclZAvMcAW4ycxZlqalq74rrSM7VV6v7P05YZJxIp1MNuoDf7/gbHXs1HixZXE3WdwDmkjb qZmwjeSvEluVKFeQWOeWqJMdl8Sku1m1xm1qALb+1hSTyU69/tc9hfuFNf/G5mayU8MjWJ16P5js 1HjGH87k6hh+h91GWfPTzE4tydt+TK8SsswbhdxqK5Oq2Kmy5xl/OCFvUoy5sOXv4wl+tihNCZm+ sVwBbvxzl6VpTr2YbEd2qrxe2fszzCTjRDqZbNQH/n7B2erYqfFiy+JusrgHNDErbCP5q8RWJQV9 UnBAYjlwSYYm3c2qNW5bA6jWTdrs1Ot/3ROrXyTiNDY3k50aHsHq1Encr52amW9p05ji6U15Qovb qUUhpaKxJiTEsqidqjyRHX2cOl/Kyoif5cw8U593DS11akrIHljwxK9+5OTFfVEYroWiuqk92anS z51UE05x2YlNCRWerdLq1KSbaOkBqnWl5p9nwy4gfZUYq0RbPJrxUyde2OYfZPuHOo3b1ABsebWd u46das6/sblZuzWHOb1XJ7QewXaExU7NzLcSE9my6U15QovbqUUhpaLRzhF+Lhy3qJ2quEvRx1Py JvwoE7b2tcGXm5CQ6Yvzt4nHWIMD59iSwaO42RV1Hdmp0s+dVK0XQBZTQoVnq7Q6NekmWrqSal2p +efZsAtIXyXGKinok4LvF70LpZOp1rhtuajWTVazU62lb2xu1m4tvRsAWHjLdqrGAnNJ4zd69EUH FeUtY6eaErqxnWo2AaZYxcV2qloR6pR+VkL2wKJEtJY91069GKcna+ryjK1+vl7s1MylG3htHkUt 2WqnlpztRnZqtgdYt53qE14KxioxFoGQ2sQLW6iXKXZqncZtyr2tv7W1mWp2qi3/Ne1UH22XhhXR egTbEXXsVI0l5pK2b/Toiw4qylvGclRTCh6RvKmdai3w1PnU70rtVJvZach6uWtaYnwkPNO5durV TUo8V+ufrxc7NdOSrBdAFqudWnK2G9mp2a5k3Xaqj/z0f7ZKCow5UzMyPaU/t4VUa9ym3FfrJuW0 Jtqp2cYtBzXdTvWRNjsAA2/ZTq0zj+nTTrXnbZLlmI+F1anNV6ea05n5sP8l4aOBerJR9cWpPdmp E1enFjNrdapCy9WpljjWaKeGSRnTtaxOFa6yaRd2+BS9/oOJfwcq5c5Wp6Yj1H86rTzX/rR/6xFs Ryy4OrWYPu1Ue94mreDMH8fq1OarU82Hz33Y/xz50UA926jq4tSe7NSJq1OLmbU6VaHl6lRL+mu0 U8OkjOla+iRp94NJRWdPaOLfgUq5t9Wp6XyoYU4rT572n8KbtVNF+21qMPmN41wWt1OL8pabuU90 bBa1U4VUxEhzeTM+Qp0LW/4+NcH3jso9Nq3XdKFln7JT59XL83bYPp89peft8PD0rLupPdmpub1T c49rl5xMSCi02IrOdgs71dQDFPeAJm5gp1quElOVKH+QCNzUTFPLBZb60RQ7tV7jNjUAW39r6SYr 2anm/FeyU+Xv1T5/GIY17AbQegTbERXsVHm/t4nBGDaOc1jcTi3KWzqa7O5/WiyL2qkFe6cmXQnj I9S5sOXvUxN876jcY9N6TevfiCml7NR59XLYbTa7/SkrxyzpbmpPdmpu71TjBWA6mdho/bZcdLZb 2KmmrqS4BzRxAzvVcpWYqsTQJ4kRTrFTCxLKd1zV/lhgaADVusladqr1PlnJTpW/V0slXiULF9Zp p4YG0MvTQ+mrf3/LzzhPeu45XIj38vSQeq/18nZqSd4y0ZgSstqp4Q9lPyvNy9PDw3YbP5IrJWPI m/+9vMosH3b0OymiyHN5cV4/XZKQe7TexsKk1ZQqPHH68vTw8HAppOft4PxPProTO9XwPnapeCYV WVi3z9vhYbuN92m0nu0mdqqtByjsAU3cxk41XCWGKhFaUljdUhGpflmyaoV2FGXjeo5sx1WlcZsa gK2/tXSTsXk6JAYAqp1qzL+1uWVGJXGUqQXy6zBTsVNdAgPosNuUvvr3VX7GedJzz+FjzYfdJvVe 6+Xt1JK8GbxCyV+c9LB/GIHsZ2XYj9FbtLXVYZm8xY+jy+nkw45+Jz3pHnkuB+f10yUJuV/qdmqY tJpSjSdO9+Ow2ZzTP+w2zv9KwvZTvMXD/vn3sVsuAOvpwmeIN+MY5KDgbDexU21dSWEPaOI2dqrh KjFUiaVPEv4/7WF/e0KmjqtK47Y1gGrdZGyeDokBgGqnGu+T1uaWGZXEUaYWyGOmplipnXpdvjFE U0l3W7nT58JHwsHapHRaOKeUTzMi/3vlhNpB0Zw0e5Ahb0o6ygIiPaG4bN2Uxcly8mSGkj6vgVQz b89bcGTKd8ocFRRS0uack5CpJR0dgODQREiV1wwLNlXciIRCMOXNkpAt3lO63lnFkojimupzRM3I jcN6NqUAJIstcZRwlc7qJnM9oIl8AygKO4f5KjFUSdSSxL9c+SeKat/YcfmHPTy96GWd77hqNW5T AzD2t/luMjybU5RRe3DjiC+4ZP4Lm5s+Kvl9vnMZ7gByB9oprUewfXFevnEkmMaGnwsfCQcLX88I 55TyaUbkf6+cUDsomu9nDzLkTUknMbmTD4rL1j1cev4+fbIsp8mtF5TgANnyFhypBpQPOyht3Uqf m1BUrUqtHB+7t4VUec2wYhxkwzZdJab85zifKWpJ2vPI00/lEjUjNw7r2ZQCECyoVEkKV+msbjLX A5qoHHYO81ViqJJcnxSlstkdoiIydlz5hNzIUiEZ8mbF1gBqdZPh2ZwLKWoPbhzCBZdq3IXNTR+V vJ49WMMdQPT5wWW1diq8UWauSIQAbdtHADCy9g0woSuet8M6lqb+xk4FeH1ls7nKJB7KBwAL9ElQ kf043dV+G2CnwrrATq3JpM0tAMAFOxXqMWUPnGa0HsEC9ADWRUUmbW4BAC70SVCPSXvgvC2wU2Fd YKdWhKWpAPPBToVqrOtPXK1HsAA9gHVRD5amAsyHPgmqwZ+48mCnwnqw7U8KAHAbrLsvA9wjrUew AI2x7nQKAHAL6JMAbg12KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ2KkAAAAAUEbr ESwAAAAAQDOG/17/QwghhNAS+r//vd5SzfOL3o7MQ83/hxBCCCGE0FR1CnYqQgghtJSwU9G9yjzU bD4ERwghhBBC61WnYKcihBBCSwk7Fd2rzEPN5kNwhBBCCCG0XnUKdipCCCG0lLBT0b3KPNRsPgRH CCGEEELrVadgp3ap/adheP/PYWYKZ8Zv8jGHf95fjtn887N5rtvp5+5aEqkSux/9/GczDMPwfvez dSQt9W281vmnffrgb5/efHH1orV1XNip6F5lHmo2H4KjudqPw7D56zAzhcsgay8fc9j9ce3dd/82 z3U7/bvb+MNSpcTuR4e/NsMwDH/sDq0jaam/navkz3364P2fb764ehEdF0I3Uae8cTv15z+bea5l kQ7/vDdO/ufbqW5SWXPQHthdav9pFaZMdf3cva/nD377NHz61jpHk/VtxE7V1W3/0G1gvhyvc//R mR6/+7L//GHz+Rd2KlqrzEPN5kPw9ejw12aea1mkw+4P4+R/vp3qJpU1B+2B3aX249s0Zf7dber5 g7e9lGrr7xE7VVe3/UO3gSF0F+oU7NQu7dSKwk7NyWCl3aewUy96s23ApG77h24D83UyOn/t3g2e efr1cRgG7FS0YpmHms2H4OtRr3ZqRWGn5mSw0u5T2KkXvdk2YFK3/UO3gSF0F+oU7FTs1NW4Egvp zVpp2KkXvdk2YFK3/UO3gfk6upw/vmzefTn41ueB1alo1TIPNZsPwdcj7NR2gXWjN2ulYade9Gbb gEnd9g/dBobQXahTVmWnnrfM+7T39wZVfBx3Y8Toae5v7u8dYnf1tMukks752/Gbl2bgYO6Vs2mp yZGcVLbR5ww71TnRtYTFD63yyiHI4Kn03u9+unsjin6fXwKTDXGlDcTFlQrba2lHSy7477RGnsi+ 17BTT6D7TXf8Fvinp/86uZsfsIPTPE6nuBbdpQadeCwNwHa5mUvSLVIt725jkxIpaLfRjsbOb02l rWRfqLjLt8daCP6rXgVhJNaOK2qWqssZnk4oeb/iUm0yY6cGRXTbP5450u1USb9275ywlZ94mwYM j3vsVNRE5qFm8yH4Ujpvmffn3t8bdBj/lo7/2+smg1n3/k+lv40tIS+d8FynPSiHce+lGTiYe38g oUZ1Tk2J5KiyjT7n2KnXsJ1gxA+N8soh+Pmp9P7YHdy9EWW/zy/PqUaY0gbi4kqF7bWQYyTBf6c1 8kT2zQ3AbU7DMO4D//T0Xyd3k0rScCmdTnH95JIFJx5LA7BdbuaSdGtQy7tb2lIiJSGFOxo7WTYV tXIuoeIuVX8s8+C/avWFkVg7Lq/ZaweIpxNK3q+4VJvM2Kle+5fPhRDS1SmrslNf//vvaHyMnzxf 4PDPe8mb86yB/SfJSshOsMV0op/sPw3jp0/Xz3/+s5EskoK1VAUz/5+796mtP2euThX3FZ20KOzb GJgs3z5FXsnP3fv346f315oSjhHTmbPKMr0y0RK2k44bzLdPpVZv1LqisysRxlV8+Oe9H+fRFgzs 1GFw01farUnZ1alCk46Xx1oagOlyKyxJy+rUxGJeS9jBdfpz937YvH8/7W8S4yc/fa3ivn0aPn1z iyK4nMVSEttSphHa+lvxdEIrdX+YbJOJwMKbwtGJbmmnHn3SjKP6fRziDQE+7H5EfuvH79dPfnzZ DMP4FTsV3VzmoWbzIfii+nsc/hxHz9Y87P6QvDnPGtiPkuuaXVJ3+GvjOyOH3R/xDH8/DuP45zWG w18bySIpWEtVsNbv390mtfXnzNWph90fQrnt/1Qs7HTF+XHu/4xK8t/d5o9xdM4oH+NXZVRH5YEl TBZL2E46bsPb/1nqOEd75kZnNzeAqKEebcHATvWdL6XdmmS5lMID4uWxlgZgutwKS9JitKUW8xpC Cqrp391m2Gyki8vQSMbRLxat4g5/bTZ/7Z2WEFzOYinFl1K+47L1t+LphFYaXt1qsacCC1tOfC6E UFqdsko7VbJFvn1yPpTNEWHunXEtZQMlTif2WMV5/jJ2aubguQ/7//xnIxiaxaabHEYYeWSmRD+U Q5217ixlpdnCvqQzz6+RkzU8kh9bmaakfu7eh7mb/vR0NTs10wBeLZdbcUnOt1MntFvhVxYp76n7 NsYffvs0pBeKCmcXsplrFbb+Vj6d91vlRGrtZOxU00VxA7mG6dfH68oE47P/wbLWr4+el3r1Yc9r VG+fQfRmZR5qNh+CLyrFFtn/6XwomyPC3DvnAcleZGQmxm+OEuf5y9ipmYNnP+z/9ygZQ6X2pRxG GHlkpsQ/lJ3cOevOUr+1hX1JZ94LxORkDY/kxz80JSXU4/Snp6vZqbkGYLncikuygp2aDkkqWCGz Finvqft7jD88Ls/UTiFfSkI2c63C1t8arlzlRGrtZOzUsEBYnYpQkTpllXaq8gT0ZaqsOTvxdDo9 wda+jT6PHZ/7sVOjFW2CT2GqNdEQkR8/1+PXLK0524AmrDRj2Nl0TNJqwbQ20K8RW0ubYJwVxBDK vDo12QDkT4Kwy0uywurUXLuV0p+04ay4YPz1v//2n6LwkulrPUNcSvln6g39raEjUkvYHmrwrfsk WLYbXEzaWtSvj4O7qvT/fu3eBQtRhc/3H92feI//nz5vlU30BmUeajYfgi+q2N07f36ZPGtrJ62u k3sufR2i80ns+NyRnRotUC1fdKmXpPz4eSJ+LTuWbBbGZg87m45JWi3km03UAGwtbYJxVhCD4QB5 dWq6AYifGLzLdO5qrE5NhfTvbiOlP2WV9//bj/Iy2/0YhTepZ4hLKdMqbP2t4QpVS9geahiYZf8B hJCsTlmlnao/av3ff6+JOfYEO1XeoiV4QPXWdqqwW+WSdqq/QHXK0lQ9OxPsVLVKptolupVmDTuX jk3qJqSDsPIxe4ChNO7ZTjWWZEndzbFTlfSn2qli5Qqfp9JXs1Nqp9r6W8sfPNRamGanRvnN7pux kBJP9399dNao+rumBr3b16ttqnFa2Xr7DKI3K/NQs/kQfFHlLU51jj3FTtUIn2y9pZ3q7y147JAW tFN9C3vK0lQ9O1PsVLVTnmiX6FaaNexcOjYJ1Xq9Kf2dOdKP02Yu37OdaizJkrqbY6cq6U+1U61/ UUhVipqdUjvV1t9a3num1sJEOzVKZEJpI/SG1SmrtFNbr06NdEs7VXjUd+HVqa/OgrhJS1P/W351 6hz1vjo1OnXkCbI61bY6dVIbSFe6MWxWpzZYnVpSg4sqYad6D/Jrq1OVVaiabp9B9GZlHmo2H4Iv qh5Wp4a6pZ0qPOq78OrUV3eB6pSlqYmSrLY6dYZ6X50aV2i2AbA6tTAXrE5NtYG1rk41p4MQktQp q7RTb7Z3quRQyIfdzE6Vsra8nXpeoDppaWoiDGHv1Jyb5lV0FVXcO3WWnSpvf2k5tXXv1MANv1s7 1VSSxXU3x05tt3dqIv0u9k713OF6e6eKP9Fq8NvpDb9LrV1N2KDBRqhfH4W9U2MHVtg7FTsVtZB5 qNl8CL6obrp36mH3h2X6fUM7Vcra8nbq2cWetDQ1EYawd2rOTTv8tam8xKzi3qkzd2aUtr+0nMX8 dwJ/34a7tVNtJVlad3Ps1HZ7pybKoYu9Uz13uN7eqXJlKZ3h6SkEdgNAyFenrNJO/TQGr42OX6Ee faIsqwzeZP1z997wquvotd1GOzX84c9/NtocPvWYeWjTDMPCD/uf05n2InKnJH0vQ3jJldVNi8KQ 30huDixhpVnCtqRjk/Iieye/YTynB//zb1E/7pMQvEW9np0avoH92xhGJbwIawjd+Vp2qqUkS+tu lp0aX7mTL6j9p2H8FORO+TtHzuOOFroKbycTCjPuuEz9bWwfx29viwNI/QknaacGrV1fWf/tvHfG Ui+qch7S9x3V7+MQLkfdfxyiN019H/0fHj5/iF5j9Wv3jof90c1lHmo2H4Ivqr/H4c8xeGwzXjIZ fSK/oT58k/W/u01gVUivTY9eNm20U8OXTR/+2mhz+NRj5t65Ts81L26n/r/D7o9h80fBjq5CUfsG x+GvTeiSmNy0w+6PKL/y2+3tLUq30ixhW9KxSXmRve+BmhpAZLr9u9sM0VvU69mppkspfBHWILzl rIqdainJ0rqbZafGFbcfh81G7JQy2o/DOMavrZdiM7xqLx2kXJhxx2Xqb2P7OH57WxyA9jiCUu+J 1qWtrL9ssTrnPXII3aE6ZZ126j7YHlGcBn/zN5jUbAV/g1TJkov263RP5/789Pk3Zx+l0KPxd3UM vv2mbcAUrrwL8nWO4RK8vnekc8Zv8Qacp2zI5sXPfzZzX+cSZNDPvhvPsbKEstUyOGXNrLADqZxU Mmy1tKc+Vhzt2CssqQ6+PRWd9Ky3lk5c2sl2a5J3Oin74bV2vrKOAVgaQNHllilJfR9ep69QGonT IAvarXfGU8VN3jvVy13sSidj1q8C7QJPdlxCY9PyZXg9VBB8plUrR34bh0/7oAGoRX271anB7qjy o/2Hzx/8jEmHfX0Mcn/1W5fIAkKizEPN5kPwRXUyPrztEdOT5NNVq9gWx5dfX45SNiX0CZ0FPwx3 x9XQo/F3dQy+VbdqDVfeBfk6x3AJXt870jljUD5XEm8/n7mAK8ign303nmNlCWWrBj9hzayyDav4 FL8etlra2Z0iFfkNchDKPN8AxFIK/a+gtJPtdkLk8qpe74Cj5zVc95EIQoobQNHllinJ89ljnL5C 3av30iALQvLOuNn9O2vvVC93ggctIVRrcKR2HSU7LumSVPIVXCzS6YJ6ia4jU8d19L79K0V1S1md ipCoTlmtndo6jLeneAkwQmiOqr6KCvWq9MP71dU8v+jtyDzUbD4EX1Q11gCiCVJXZSKEJqnqq6gQ QqiqOgU7FZmkPAWMEJos7NQ3IexUdK8yDzWbD8EXFXZqG2kvwEEITRR2KkKoX3UKdiqyiKWpCNVV uNusVdipaxN2KrpXmYeazYfgiwo7tYVYmopQXUVbMBuFnYoQuok6ZVV2arDv3mJb3aGT4o0jKXOE Jsu/oMq91GAzUP7CsQ5hp6J7lXmo2XwIvpSCffdYLHnjAk9siYgQysrfqLTcSw12g+XVSQihBdUp q7JTEUIIoVUJOxXdq8xDzeZDcIQQQgghtF51CnYqQgghtJSwU9G9yjzUbD4ERwghhBBC61WnYKci hBBCSwk7Fd2rzEPN5kNwhBBCCCG0XnXKcOOZHkIIIYQQ6lnYqQghhBBCqA91CnYqQgghhBC6CjsV IYQQQgj1oU7BTkUIIYQQQldhpyKEEEIIoT7UKdipCCGEEELoKuxUhBBCCCHUhzpl1Xbq/uNw4t2X Q+tgELpLXa+yYRi/to+nS30fr4X0uK+U4Obzr9qxDcPwYfejeXFV0tfHm2Tn1+5d5RuNe00N1Sr6 7cipke7asxtb133mqRF+/K4eg52KEEIIIYT6UKes3U5V5iqBgzBxMnz4/EFIJDH9QOh+pV9u+W8L 9OPLZsV/Hfk+9mWn/tq969fQkWVvADeyU8sDS+rw+QM3kUr6tXvXl526/7gqc/zrI3YqQgghhBDq X51yp3bqVYfPH+ZNb0J/5PD5Q6UFaAitSdipBtWyUytpjYXZbcx1AuvOAVyzeivMzi7/rLBTEUII IYTQGtQp2Kk5SROk9CQEoXsUdqpBnfkpayzMbmPGTu1OvRVmZ5d/VtipCCGEEEJoDeoU7NScxAlS 6SzO2U/tOHv58WUT7K329THYCe6y1UAcv78Lwaz5pLeLn2cWnGP++D3YPEEu81P8Rx73sfXgZPl0 jPJzL33xczepd18OXqilJeBvdffxe9hg0mGfS2bz+Zd/pFspTul5EQqfh/tL+Dk6f/u4Dypuorlf ts2fcrmFiRhTyzUhB6chnXJ9/eRydqfAzxUxftXblVJxYl9RcrnN9VPcc0nBWMOWNyqRgtd7AL/9 H79S/jt+Pn/udhdFPYCtAURNLlUdfiGYrtzUzWKmnRpmXz+jVw5xBoM2L10CU6OKgjHcucT2JnV0 m89fnIZxSflcL8plm3wWJH0j9vf8mfUXUC+pXJVdmfYXJq8w3305uKanW0rBqaUMhld34J8e/6u1 f+xUhBBCCCHUhzoFOzUn2R+ZsBYv2lXt+xhOgIXJYRz//mPgL0zeZjH64ddHweX8+Dh608Jfu3fh 6Q6fP3ghHadnaevhx5dNkH3VrfD3fwyC/Po4DB8209Yo/fiykUyBjKUS2RaHzx82Hx83kYXqF5oc YXojxbBgTyk/jh+9ybN02AQJNeuql9WpwgFC8e4/DuPHx2uxpCru0pyCWjulU3K5VVuelui4LGHb CtPQAzjp7J19Ttx2u/84BNbeMZjMPpJSjZgaQLLena98g2lqA5gU2LSYz4UZtTflzxgfdl+dHuzH l01p24s2n43OLtZjfOcKFfdIx6710jAu3WzQAZ4uWzcjWjtJF6bct0+6NsVSkjvtCpd/mPjRLfVP J3S2wjpT8eqWEndi9s6OnYoQQgghhPpQp2Cn5iRPkKYl68xLxRmpwU6Vp/RTnnmUSy9IX3nZy/6j 96HgCRqsh6gMtbmoW1bK3gtTVmbJhZat2fgAZaL+a/fOm6aKbTX36pI4SMXO+/pY4RUoyVpbnZ0a Gzr5igtcieLL7UZ2aibsORUq/uT4BxLF93fT8cLObYoi57GGnaqUnmEj7ETMN7BT5bOLPzk613Ma W0EHmLtz5RNXG4ZfqqKf+/p/30f1L21yMHLbnrJLT9EAoI6dGqYchW2xU00l8PVR/HPdKQvYqQgh hBBCqA91ytu1U7UHS4WHgqvZqa+nydIXZUaat1O18/qf+w85ulynUtrEz49BmG6dPpecqbKHHKO8 OKd2HVI3Btk0FKbuSv79R8InmSOyKyfN0g+fP0g2k+uHZr0J0U4Vf+I6DpYGIGk5O1V50nmIreGK q1P9eMSKSzsXtsstqB3ZT/GeuvWQj8+sTs0ZLobCtPUAhQ2jDzvV6rIVlGRZYBNiFsJLFtTsbUO1 7CifJ+9c+Wza7VSx2Qd/wMsVQuIvc+ULeAuurDp/TfH7CnmDjpydaotEXtOKnYoQQgghhPpSp7xd O9Wqag/7OwlqCxJNdqrmypStu0k9We/bqWKyGaNEfGxc2GQz3sfg+In2NKhSm5OcBetKpXzYJtPt Ygofffzr1pN+6xJsx9hOreQUiM3pwkCrPAAAC6ZJREFUjlanVrFTCy+3Wz3sP99ONfYAhkox26n5 S8nUANKhJmuhbzu1aLFtDTtVbdxaD6Mvpc91XHY7VVvFr+54IDcAjbJCUy/DJe3UOC/xDiQZO9XY VrFTEUIIIYTQGtQp2KmGycz8V1G5qX3Y/dDW4ExfnVopX1EM5tWpubwIU3HVyziajGer0Ssr2+pU k0wTTlPYltWp5wI/7gN73g02KF5h14Jpq1NNEp6rva+H/ZdbnZpsMCuxU2+9OtXWA1gaQDrU1Oed 26l9rE6VlbxzGTquPlanlqvF6tRsdlidihBCCCGE3pQ6BTu1dCbz+n//e/3xZSPvcJdYtva/wAiT 5o2WV1EVu2ZlpTdl71SD4yxNSoWqubzx5uP38xuoAvdw8b1TvRWjtrAte6c6r4553J8d2KANSDWy 3N6pSsPGTg1cibLLbUV2auHeqTPtVGMPYGkAyXpPlp6wd2pXdmrh3qnz7FTVo4yVuXNZOq4b753q /ylrjm67d6rNpZ2+d2rw1zjsVIQQQgghtAZ1CnZqTtEESXuB8vVpR+1b6W05/mRGfLRfmPBHp9Df NZzOmh9SnLWvj8PHx+BhQ+lFz2GuwwWbYcon6zmqmu/j8GHz7nS6w+cPw7sPQkjuhPPHl83wYTPN WYh8WPf10/awz+8Hd5M6rz/162jz7lwsp7Cjd0+HhRY/nfp9HB7H+O3PxUZPGOHpwfapdmr4Lu+v j4NtC12pWbo//LV7F0QVeCjHSlnITi293NZkp5p6AEM6JjvV2gNYGoDWEoKv4l2ws3+sam2nCr2r 0JNY0rFJeJA8bPCGO5el4yp42P9jcMUlNpjONADhz3UT/vAW9a7a4wh17NSoE86/nOq4gUz8Nsig cr8+hlccdipCCCGEEFqDOuVO7VRl67TCybCyc6I2X9JXp7qvvbq6aWJU/vaCH7+fY8jssDnVMg4K Slr4eV4oqp/r+3h6Nt+LPFUIwzB+/Z+YNW91kjS3jJI6PkE/2VnwSyBzLjnss1PgJSW/Vfk6mVdN wChrQXmeprte45zo8vh5P22z4AWvbx4qbyg8OyShecsrKL0D/FISLi43p8fI40/cRh6bjB6x4SVT +hcO9f14l3iMYWshxbWW6QGUN2idD4uK2rs6Ttlx3y93ResBsg1AfamXsGbZ/VpY5e1nR28Al6hm tGrtUoqbd5BBye40pWNT1FSiP4qcSN65kh1XVNRuw/D7nNM93WsA6U5SiVw+cqrXGZR5dF0rIU3d gsY/nbL7gZ/x4FqTK1f4e4b7K7eJbj7/wk5FCCGEEEKdqFPu1E5FlWR9X1NbVVmoNV31NrS1aKHt +RBCSdVZnYpS4p7ekbBTEUIIIYRQH+oU7FSUEnaqQdipCN2/sFOXF/f0joSdihBCCCGE+lCnrN1O 1Z7yQ3W0Bjt10r6xNYWditD9ynksmhvNwsJO7UjYqQghhBBCqA91yqrtVLSk0jsPNlV2n9bbKbf5 bFUF2y/e0MNFCKElFfTqONfNhZ2KEEIIIYT6UKdgpyKEEEIIoauwUxFCCCGEUB/qFOxUhBBCCCF0 FXYqQgghhBDqQ52CnYoQQgghhK7CTkUIIYQQQn2oU7BT0VuUZaKIEEIIIU3moWbzIThCCCGEEFqv OgU7Fb1FNZ+FIoQQQquWeajZfAiOEEIIIYTWq07BTkVvUc1noQghhNCqZR5qNh+CI4QQQgih9apT sFPRW1TzWShCCCG0apmHms2H4AghhBBCaL3qFOzULvV9HIbN51+Wwxw+7H6Exxw+fxiGx337HF21 /zgM774c2obRfBaKEEIIrVrmoWbzIThCCCGEEFqvOgU7tUtZ7NRfu3fD+DWT1M3s1MPnDwb/93+v 2KkIIYTQHcg81Gw+BEcIIYQQQutVp2CnrlU/vmyam5KO7HZqF2o+C0UIIYRWLfNQs/kQHCGEEEII rVedgp26VmGnzlHzWShCCCG0apmHms2H4AghhBBCaL3qlDXaqfuP3o6hs1y8r49OSo9716M8ffVh 9+P4yPwZ0cT88WVjCck/bPz6a/fO2/DUPZGWiBeMunGqu61q8mF/rwQ+7H58H/3js6UdHKAe6eY9 ZQT/2r1zUvn4Xcr74947b/luBs1noQghhNCqZR5qNh+CI4QQQgih9apT1minCnaeb7oZdfj8wfP1 jn6f5/T92r37MH70D/v6GPp3Xx8DN1PcHjTaxvToGwrvj3q1LPa0rk4N7dGw6LxEjiZsyp3USrtg dWoi8h9fNoO3IWxYR+ccjR+vdq10TE7NZ6EIIYTQqmUeajYfgiOEEEIIofWqU+7ATk07hgkdPn8I ncHQ6fu1eye5hz++bK4fhitML4l79qLsIcq/FX4ea76d+vVRMkazhSkfUMNOVUojjDN+T5dajKqa z0IRQgihVcs81Gw+BEcIIYQQQutVp7xlO/U1enDeXRd59uniD4+fn8+omYP+56Vbi97ATt1/FLM2 McEKdqqao+CMcQDYqQghhNBtZR5qNh+CI4QQQgih9apTVmmnett9Tt09U9Cv3Tvjskfnc387VC2q Uu9yeTvVbEHaSruCnSqvlo2zgJ2KEEIItZZ5qNl8CI4QQgghhNarTlmdnRrtQJpwDCcoMOZmrE6N wl7j6lR7abM6FSGEEHpDMg81mw/BEUIIIYTQetUpa7NTReNsmp0q/kqwU3N7p/5v/9Hg5SleobB/ 6/nzRnun/m9/fctTQWnfdu9Uq5163swhCrj5LBQhhBBatcxDzeZDcIQQQgghtF51ytrsVNfsO3tt Ex/2F95iH5mbv3bvPowf/RfH//iyERZsRis9vz4Gie8/DkP8nisl8lvYqYJZ/H0cvCALSjvI748v m/CFUYbI47L9+jiEB9vt1GMJS7viNp+FIoQQQquWeajZfAiOEEIIIYTWq05ZnZ3qemTDyfs7GqOK eafq+zg87oOdT8PVmmefzts/VNuK1N9fVNse1CEMWNil9Ei0YFbAjUo7Rlhpa3kZl7G0/aQEx1kk TCeoEb8Y3VOcfugWmpo7VqcihBBCVWUeajYfgiOEEEIIofWqU1Zop95S5ZtyolWo+SwUIYQQWrXM Q83mQ3CEEEIIIbRedQp2alLYqXeq5rNQhBBCaNUyDzWbD8ERQgghhNB61SnYqUlhp96pms9CEUII oVXLPNRsPgRHCCGEEELrVadgp6oKdjKN9uVEK1bzWShCCCG0apmHms2H4AghhBBCaL3qFOxU9BbV fBaKEEIIrVrmoWbzIThCCCGEEFqvOgU7Fb1FNZ+FIoQQQquWeajZfAiOEEIIIYTWq07BTkVvUc1n oQghhNCqZR5qNh+CI4QQQgih9apTht8AAAAAACW0HsECAAAAADQDOxUAAAAAymg9ggUAAAAAaAZ2 KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ2KkAAAAAUEbrESwAAAAAQDOwUwEAAACg jNYjWAAAAACAZmCnAgAAAEAZrUewAAAAAADNwE4FAAAAgDJaj2ABAAAAAJqBnQoAAAAAZbQewQIA AAAANAM7FQAAAADKaD2CBQAAAABoBnYqAAAAAJTRegQLAAAAANAM7FQAAAAAKKP1CBYAAAAAoBnY qQAAAABQRusRLAAAAABAM7BTAQAAAKCM1iNYAAAAAIBmYKcCAAAAQBmtR7AAAAAAAM3ATgUAAACA MlqPYAEAAAAAmoGdCgAAAABltB7BAgAAAAA0AzsVAAAAAMpoPYIFAAAAAGgGdioAAAAAlNF6BAsA AAAA0AzsVAAAAAAoo/UIFgAAAACgGdipAAAAAFBG6xEsAAAAAEAzsFMBAAAAoIzWI1gAAAAAgGZg pwIAAABAGa1HsAAAAAAAzcBOBQAAAIAyWo9gAQAAAACagZ0KAAAAAGW0HsECAAAAADQDOxUAAAAA ymg9ggUAAAAAaAZ2KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ/x8E6waq+6ElzwAA AABJRU5ErkJggg== --_004_D092E3B616C87rpazhyanciscocom_-- From nobody Thu Nov 20 04:46:24 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FE01A040B for ; Thu, 20 Nov 2014 04:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUTl2T9peFXC for ; Thu, 20 Nov 2014 04:46:19 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEE11A0451 for ; Thu, 20 Nov 2014 04:46:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmELAODhbVTGmAcV/2dsb2JhbABXA4JrI1VZBLczAQEBAQIGk2kiCoZ0VQKBCRYBAQEBAQF8hAIBAQEBAwEBAQ8oNBcCAgIBCA0BAgEEAQELFAkHGwwLFAkIAgQBEggaiB8BDLJmoUsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIY1ih4hFwYLgxyBHgWSV4ReiF+DVYMijlGDe22BSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,423,1413259200"; d="scan'208";a="81397395" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Nov 2014 07:46:15 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 20 Nov 2014 07:46:15 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 20 Nov 2014 07:46:13 -0500 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "opsawg@ietf.org" Thread-Topic: [OPSAWG] document status Thread-Index: AQHQA0B10A1cVz795US+VcK3vvdSsJxpeOkg Date: Thu, 20 Nov 2014 12:46:12 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C90B442@AZ-FFEXMB04.global.avaya.com> References: <20141118150037.GB88064@elstar.local> In-Reply-To: <20141118150037.GB88064@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/3On8rC9jJI54ZdrBNxbli7kM_UE Subject: Re: [OPSAWG] document status X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 12:46:21 -0000 Hi Juergen, The coman documents were not on the agenda of the OPSAWG meeting in Honolul= u. My understanding is that the first one is on Benoit's table for review, = soon to be followed by the second one (pending Warren's shepherd write-up a= nd submission).=20 Regards, Dan > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, November 18, 2014 5:01 PM > To: opsawg@ietf.org > Subject: [OPSAWG] document status >=20 > Hi, >=20 > since I could not follow the meeting in Honolulu, can I please get a > clarification where we are with these WG documents? >=20 > - https://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-03 >=20 > This I-D was apparently sent to the IESG on 2014-10-30. So the token > is with Benoit and I understand that Warren is the document shepherd. >=20 > - https://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-03 >=20 > This I-D is still a WG document. What are the next steps and who > holds the token? Who is going to be the document shepherd? >=20 > - https://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-02 >=20 > This I-D is still a WG document. What are the next steps and who > holds the token? Who is going to be the document shepherd? >=20 > I just want to make sure it is clear who has to take the next action so t= hat we > can wrap up things in a timely manner. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Nov 21 08:05:41 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED47E1AD53C; Fri, 21 Nov 2014 08:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuz5D-FPTIEo; Fri, 21 Nov 2014 08:05:26 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607EF1AD567; Fri, 21 Nov 2014 08:04:46 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so4905255igi.6 for ; Fri, 21 Nov 2014 08:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=sGJQiuQJF4aU10/fMrMVeL0SLouxZhQoZB2WJqnsap4=; b=TEmHjz1Vde9tFeWS4/hKU7uzOemwb8GvymTbTxw4OJlG2edDzcK18LliB+tvaac5bY 7BN1isllTQ7dun8nc6gHvBCS4/DBZGxL7hwYM0VtpI2r9YNVeKEWvq7Q21DZTG23jUme kHMWFC16RJ4PdUreMkgpeNzP+T/zH0W2IDen3XT79yaFG7yyegTJRRpLzKycsyL4JxLr bN3kUS3QTY0xBB9PzSrIPGq+Tz+IJ3fYnQtK/04aDFlCQUZZti0yzp4O4bk51ILMWpKv ErqDDAu3BXBmJIIthOmjOM6tAW/dMsaPmNgO6hXSG8BEhbbfogSrf5m03QyCkcc/gnCO u76Q== X-Received: by 10.50.3.106 with SMTP id b10mr16130822igb.41.1416585885484; Fri, 21 Nov 2014 08:04:45 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id rp2sm4418257igb.0.2014.11.21.08.04.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 08:04:45 -0800 (PST) Message-ID: <546F629F.2000801@gmail.com> Date: Fri, 21 Nov 2014 11:04:47 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/i_UdBck8yWck581jnUoup0R00S0 Subject: [OPSAWG] NAT MIB: compliance levels X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:05:32 -0000 One of the issues David Harrington raised regarding the NAT MIB -11 version was what he thought might be an excessive number of compliance levels. (Issue 36, http://trac.tools.ietf.org/wg/behave/trac/wiki/MibIss036) These are the ones currently defined: (1) Basic NAT, all mappings are administered. (2) Dynamic port mappings are supported (3) Address maps and address pooling are supported (4) "Receive fragments out of order" is supported (5) Subscribers are supported I think we can combine the first with the second one. We can get rid of the fragment-related one by redefining the dropped fragment counter to count all dropped fragments and providing an object to indicate the fragmentation behaviour to help interpret the counter. This gives us three application scenarios: -- basic NAT: support of port mappings only. Objects in the natv2InstanceTable, natv2NextProtocolTable, and natv2PortMapTable are relevant. -- large-scale NAT: additional support of address pools and address maps, hence natv2PoolTable, natv2PoolRangeTable, and natv2AddressMapTable come into the picture. -- subscriber-aware NAT: additional support of subscribers, hence natv2Subscribers and natv2SubscriberIngressInterfaceIdentifierTable are added. Comments? Tom Taylor From nobody Fri Nov 21 14:59:29 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038E41A8F3C for ; Fri, 21 Nov 2014 14:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b52ajI3ii_FU for ; Fri, 21 Nov 2014 14:59:26 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3316C1A8F3A for ; Fri, 21 Nov 2014 14:59:26 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id b6so4955416lbj.16 for ; Fri, 21 Nov 2014 14:59:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YYIdnuPQu4MLYLpF9ItSf9l0qAq4u7mXCFemXRwhsQc=; b=c28ey631DoGBW5pecQ0l1/a7D3PzG1PmHFxP5rZbgc9Z6k76b+eSiHAfBfKxlSTqAg sCVgQrBEzCZtK62AG+xIGz/PbD/h8QfVcMSHUb9sx3GfPoqttx0p3LHgHnjygjgPzhoB YkKAs0BcJtcinjMjoqesSHRRpXZncYQJwqXByPZQD18TPMW/yhEr08z5p8nBHMotmeBk 7Hip52k6QUx7OqZnG6ZP5TmZiZzwHG34t6wby2EYi14baHsB4B+1SP9eWLFQud5eiqTM BF8/uJU2aOLqpLOHXu14yxWRegxufO4hM1//nwIlA3od3tYLlCfKziMeKJFuNaZVb3/G NQvw== X-Gm-Message-State: ALoCoQl1oxtWgMIUVZ7LImn+n3Daq6lNZ5S/vNjlAbFkwAIsK4eX/B3WNavOx9X4ekTZt4GDIkii MIME-Version: 1.0 X-Received: by 10.152.10.67 with SMTP id g3mr8088226lab.59.1416610764497; Fri, 21 Nov 2014 14:59:24 -0800 (PST) Received: by 10.25.84.145 with HTTP; Fri, 21 Nov 2014 14:59:24 -0800 (PST) In-Reply-To: <546A41D2.4040009@gmail.com> References: <546A41D2.4040009@gmail.com> Date: Fri, 21 Nov 2014 12:59:24 -1000 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a1132f4a0673e7c0508666515 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/hWLr9b6HxaGaP7kHjqCjTZtwXwM Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: meaning of indexes for NAT instance, address pool, and subscriber X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 22:59:28 -0000 --001a1132f4a0673e7c0508666515 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 17, 2014 at 8:43 AM, Tom Taylor wrote: > As I understand it, NAT instances, address pools, and subscribers could > all be provisioned (and deleted) dynamically. To ensure that a given index > value continues to point to information for the same object assuming that > object continues to exist, I propose the following rules (adapted from RFC > 2863, Interfaces MIB and taking into account the proposal in my previous > E-mail): > > 1. The index value for a given object instance MUST remain constant > between events that cause the discontinuity time for that object to be > updated. (The interfaces MIB module requires constancy at least between > reinitializations of the management system.) > > 2. After the object instance is dynamically removed, its index value MUST > NOT be re-used by a *different* dynamically added object instance until > after the following re-initialization of the network management system. > (Same constraint as the interfaces MIB module.) > > DiscontinuityTime objects were part of the previous proposal and will be > assumed here, since they are part of the ifIndex solution. > LGTM! Simon --001a1132f4a0673e7c0508666515 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 17, 2014 at 8:43 AM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
As I understand it, NAT instan= ces, address pools, and subscribers=C2=A0 could all be provisioned (and del= eted) dynamically. To ensure that a given index value continues to point to= information for the same object assuming that object continues to exist, I= propose the following rules (adapted from RFC 2863, Interfaces MIB and tak= ing into account the proposal in my previous E-mail):

1. The index value for a given object instance MUST remain constant between= events that cause the discontinuity time for that object to be updated. (T= he interfaces MIB module requires constancy at least between reinitializati= ons of the management system.)

2. After the object instance is dynamically removed, its index value MUST N= OT be re-used by a *different* dynamically added object instance until afte= r the following re-initialization of the network management system. (Same c= onstraint as the interfaces MIB module.)

DiscontinuityTime objects were part of the previous proposal and will be as= sumed here, since they are part of the ifIndex solution.
=

LGTM!

Simon
--001a1132f4a0673e7c0508666515-- From nobody Fri Nov 21 16:05:37 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACA21A90F2 for ; Fri, 21 Nov 2014 16:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-kJbvI4ilKP for ; Fri, 21 Nov 2014 16:05:32 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE761A90F3 for ; Fri, 21 Nov 2014 16:05:31 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so5449252lbj.13 for ; Fri, 21 Nov 2014 16:05:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Syg5AnQ1Ck58EVZauieIERYt2Tc6bFomViwox2TBHUs=; b=PNmMnfhzpngy9v78gsiB2dpliHlSSBwDl9sJTZ6Gq9pWL9uo/VPtuH1oyaZ0MLgp/X 8i2b2JUtytvQgf3SQFWOVEvNavAGF7Bjd/DCWgQDnqv8iWCuRkrePvutyh69+nsV28hp jr+FxzPCK0A0dpv5phauGT15iqBtLQeJiTvbw0Wm1CPGKeUP4I7PakG7HWCQXSiZFxex bKs9/krQbthh7adHOV+7U9yqVeZjx2bkjDFh6SADbcdD2M7PZ3L22rWbCAop+8zY6iTR 5M0mymAifM5NqoinBEi8+ncKjmLd5XvJfT6gi1AhAxa9S+/XsGMShnn/GRq6gTiwpJf0 PTJA== X-Gm-Message-State: ALoCoQnP9xe1tI5SZMefEfKrMbihheoUmvnqV9fffuOixCtP9nrZ7Ixfq+7odBdaWbgWg/LRtBzo MIME-Version: 1.0 X-Received: by 10.112.225.225 with SMTP id rn1mr7059208lbc.98.1416614729412; Fri, 21 Nov 2014 16:05:29 -0800 (PST) Received: by 10.25.84.145 with HTTP; Fri, 21 Nov 2014 16:05:29 -0800 (PST) In-Reply-To: <546F629F.2000801@gmail.com> References: <546F629F.2000801@gmail.com> Date: Fri, 21 Nov 2014 14:05:29 -1000 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a1134dc20bb059805086751ff Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/yDOCRPTURizR1G41yLkqP63ZXhw Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: compliance levels X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 00:05:35 -0000 --001a1134dc20bb059805086751ff Content-Type: text/plain; charset=UTF-8 On Fri, Nov 21, 2014 at 6:04 AM, Tom Taylor wrote: > -- basic NAT: support of port mappings only. Objects in the > natv2InstanceTable, natv2NextProtocolTable, and natv2PortMapTable > are relevant. > > -- large-scale NAT: additional support of address pools and address maps, > hence natv2PoolTable, natv2PoolRangeTable, and natv2AddressMapTable come > into the picture. > > -- subscriber-aware NAT: additional support of subscribers, hence > natv2Subscribers and natv2SubscriberIngressInterfaceIdentifierTable > are added. > Makes sense. FYI, the IETF term for "subscriber-aware NAT" is, perhaps surprisingly, "carrier-grade NAT" [RFC6888]. Simon --001a1134dc20bb059805086751ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 21, 2014 at 6:04 AM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
-- basic NAT: support of port = mappings only. Objects in the natv2InstanceTable, natv2NextProtocolTable, a= nd natv2PortMapTable
are relevant.

-- large-scale NAT: additional support of address pools and address maps, h= ence natv2PoolTable, natv2PoolRangeTable, and natv2AddressMapTable come int= o the picture.

-- subscriber-aware NAT: additional support of subscribers, hence natv2Subs= cribers and natv2SubscriberIngressInterfaceIdentifierTable
are added.

Makes sense.

FYI, the IETF term for "= subscriber-aware NAT" is, perhaps surprisingly, "carrier-grade NA= T" [RFC6888].

Simon
--001a1134dc20bb059805086751ff-- From nobody Mon Nov 24 06:04:48 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA851A02BE; Mon, 24 Nov 2014 06:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLzgKM0Rzq-o; Mon, 24 Nov 2014 06:04:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E31EE1A6F6F; Mon, 24 Nov 2014 06:04:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124140438.2657.40156.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 06:04:38 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/jDLyd978YMXrywIMH4X_f5kheEA Cc: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, opsawg-chairs@tools.ietf.org Subject: [OPSAWG] Brian Haberman's Discuss on draft-ietf-opsawg-mibs-to-ieee80231-01: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 14:04:45 -0000 Brian Haberman has entered the following ballot position for draft-ietf-opsawg-mibs-to-ieee80231-01: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This strictly a DISCUSS to make sure I understand the process going forward. Will any of the RFCs listed in section 2 need to have their status changed to Historic? Can we mark an RFC as being obsoleted by an IEEE spec? From nobody Mon Nov 24 06:30:56 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54F11A6F81; Mon, 24 Nov 2014 06:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyqGz8AkEUMA; Mon, 24 Nov 2014 06:30:52 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24161A6F61; Mon, 24 Nov 2014 06:30:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisGAMY/c1SHCzIm/2dsb2JhbABbgmsjVVkEtk0EBpQ/hmoCgR0WAQEBAQEBfIQCAQEBAQMSKDQLDAQCAQgNBAQBAQsUCQcyFAkIAgQBDQUIGogfAQyue6BCAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGOolvEQEfMQcGgymBHwWGTowahGWIaINZgyaOZ4I4gUV4AYEOOYEDAQEB X-IronPort-AV: E=Sophos;i="5.07,449,1413259200"; d="scan'208";a="93484932" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Nov 2014 09:30:50 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 24 Nov 2014 09:30:49 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 24 Nov 2014 15:30:48 +0100 From: "Romascanu, Dan (Dan)" To: Brian Haberman , The IESG Thread-Topic: [OPSAWG] Brian Haberman's Discuss on draft-ietf-opsawg-mibs-to-ieee80231-01: (with DISCUSS) Thread-Index: AQHQB++dB2gd504GXk6fpoCRygSiKpxv1k/g Date: Mon, 24 Nov 2014 14:30:47 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C91003B@AZ-FFEXMB04.global.avaya.com> References: <20141124140438.2657.40156.idtracker@ietfa.amsl.com> In-Reply-To: <20141124140438.2657.40156.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/KTmGii6yIm4OuGqwmfbsD0nBAmo Cc: "draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org" , "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Brian Haberman's Discuss on draft-ietf-opsawg-mibs-to-ieee80231-01: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 14:30:53 -0000 No, I do not think that this is needed. We did not do this for the Bridge M= IB RFCs, no reason to do it here. The rationale is that the MIB modules may= continue to be widely used and deployed for a while.=20 Regards, Dan > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Brian > Haberman > Sent: Monday, November 24, 2014 4:05 PM > To: The IESG > Cc: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org; > opsawg@ietf.org; opsawg-chairs@tools.ietf.org > Subject: [OPSAWG] Brian Haberman's Discuss on draft-ietf-opsawg-mibs-to- > ieee80231-01: (with DISCUSS) >=20 > Brian Haberman has entered the following ballot position for > draft-ietf-opsawg-mibs-to-ieee80231-01: Discuss >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.ietf.org_iesg_statement_discuss- > 2Dcriteria.html&d=3DAAICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcN > XCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DnliNRC0Y- > s4fTxoES6A9TSP2fMZZ2Gp6v83Q44Pm2Vc&s=3Dl2IWNPty546y14Wx6QX6H50Fa > LuGkOrf_3aMzDEnw-Q&e=3D > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dopsawg-2Dmibs-2Dto- > 2Dieee80231_&d=3DAAICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcN > XCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DnliNRC0Y- > s4fTxoES6A9TSP2fMZZ2Gp6v83Q44Pm2Vc&s=3D4m4W05-_3wyJk- > UAsdfvWhBajCWVsJ_DNL9f0hmGo4A&e=3D >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This strictly a DISCUSS to make sure I understand the process going > forward. Will any of the RFCs listed in section 2 need to have their > status changed to Historic? Can we mark an RFC as being obsoleted by an > IEEE spec? >=20 >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_opsawg&d=3DAAICAg&c=3DBFpWQw8bsuK > pl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DnliNR > C0Y- > s4fTxoES6A9TSP2fMZZ2Gp6v83Q44Pm2Vc&s=3DSIklSSGbD8cD_9OsYgOnwMOn > sx8tfCUFDiRk1_Gpxyw&e=3D From nobody Mon Nov 24 08:30:40 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A731A86F6; Mon, 24 Nov 2014 08:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ9SS6Pr0G1s; Mon, 24 Nov 2014 08:30:35 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D2B1A711A; Mon, 24 Nov 2014 08:30:34 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so9209999ieb.9 for ; Mon, 24 Nov 2014 08:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=8s2pcBqONUrOswd+9RduYR86056WJT1AwfoLNRDMDVE=; b=HMyB5FnqUUC+pWxPZEebJ+W+sJUGIt1u8OUptc/V6mA94dbb/cDj6ls4D8vpQtlpFw Wmk/0Avj1tqNREfs4L5Zx4BgBjMJKy5mnqTigoWIwGISu/ENrLDfTpH6/0pid0kMhpiA RB2UYShYg8pef5M0Di6rJmA05DoMkfKK8rKV/3UBJWqIj7trCNU/RpFtgBOccaVjcd3w +rHGi+ezpmW1Jc+T8H1PJgGycmV6/YFFe94qp5t0v0/64ie1zPV7eg+S4zS4VHZ/+S3D kxG5qB8WuGcx5OU3+k8d2yJqDxdBg3Zbhxv/yVkKVIARqWjHCrN7C+/e0XBImfVFsIlK bZFQ== X-Received: by 10.50.8.71 with SMTP id p7mr12513903iga.9.1416846633775; Mon, 24 Nov 2014 08:30:33 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id ro6sm4721864igb.3.2014.11.24.08.30.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 08:30:33 -0800 (PST) Message-ID: <54735D29.7050308@gmail.com> Date: Mon, 24 Nov 2014 11:30:33 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/aVD4ghtIxcZwFsE_qy-c3a4h1Ns Subject: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:30:36 -0000 The published version -11 of the NAT MIB module indexes address maps by NAT instance, internal realm, and internal address. This works fine, I think, except in the CGN case where packets originated by the subscriber come in by way of tunnels. Take DS-Lite as an example. In the case of DS-Lite, the realm actually defines an IPv6 numbering space -- the reserved IPv4 address 192.0.0.2 appearing as the source of packets originated by the subscriber certainly won't be unique over the realm, making nonsense of the definition of realm as defining a numbering space. I see two possible ways to present the address map in the MIB module. One is to keep things as they are, but add a note that the operator may want to filter on subscriber index (which is part of the mapping information) to select the information they really want. If they are starting with the IPv6 tunnel source address, they have to go to the subscriber table to get the corresponding subscriber index, then use that to filter the map data. The other possible solution is to index the map data by the "internal realm address" (which would be the IPv6 tunnel source address) and present the internal packet source address (which would be the reserved 192.0.0.2) separately in the mapping table. Except in the case of tunneling, the two addresses will be the same, so there is redundancy in most cases. However, the workflow for tracing back from a tunnel source address would be simplified. Comments? Preferences? Tom Taylor From nobody Mon Nov 24 10:13:34 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A841A87B1 for ; Mon, 24 Nov 2014 10:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgWol1fMIP79 for ; Mon, 24 Nov 2014 10:13:27 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223091A0673 for ; Mon, 24 Nov 2014 10:13:27 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gf13so8185528lab.13 for ; Mon, 24 Nov 2014 10:13:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oQnZ0JFYDjLj7sqZh0Y0WwScoDYmMqsFjOCOoXFcyCA=; b=AmCgF1VZ3wRGPY36V7uVhDLcnaJVVTgFWKK21nuTqEyjhwpWQRW2S2oqwDvh8IAtRH loSJyfhB3ncU2GtQufFvdFi/R7IIMeF/f2NhWcSb+VZ86jf5tf3RVFPRwx2oylNVxxg/ uNOnjl8cM+/cVtDV1JSAyiHubSf/WR8faEBXjnm9kdtQFT7J0XiWwIooHkeaPIdY4rjD e9kj1zpTAP9/fFuzhFEWoTK5PeWMSFejY7a8uit8R06bebb6TIED6qQvn3cv/o4pXw9D zqTnoGqAHqSlCZInehgIsv9Hw42PU32WEEvLCdPK0MQuhCTxdQVIePNM6omZJ73juWW1 fg7A== X-Gm-Message-State: ALoCoQksMLL8t3dY/CwNyys75rsmhcpQgvlbcORzRF7FGq2L8Yn9bvaDK/OLoD8mLt5PsAPBhYSv MIME-Version: 1.0 X-Received: by 10.152.243.37 with SMTP id wv5mr22332076lac.10.1416852805475; Mon, 24 Nov 2014 10:13:25 -0800 (PST) Received: by 10.25.84.145 with HTTP; Mon, 24 Nov 2014 10:13:25 -0800 (PST) In-Reply-To: <54735D29.7050308@gmail.com> References: <54735D29.7050308@gmail.com> Date: Mon, 24 Nov 2014 13:13:25 -0500 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a1133f0242c32a405089ec0ad Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/get9nFgTB22cbz9-MJkxJCP2YCg Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 18:13:29 -0000 --001a1133f0242c32a405089ec0ad Content-Type: text/plain; charset=UTF-8 On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor wrote: > The published version -11 of the NAT MIB module indexes address maps by > NAT instance, internal realm, and internal address. This works fine, I > think, except in the CGN case where packets originated by the subscriber > come in by way of tunnels. Take DS-Lite as an example. > > In the case of DS-Lite, the realm actually defines an IPv6 numbering space > -- the reserved IPv4 address 192.0.0.2 appearing as the source of packets > originated by the subscriber certainly won't be unique over the realm, > making nonsense of the definition of realm as defining a numbering space. > The definition of realm should be changed so that the tuple (internal address, subscriber index) is unique. Actually I argued in the beginning that each DS-Lite subscriber should have its own realm. That would make for a simpler model, but it turns out that that maps poorly to current implementations. That's why we have subscriber indexes now. I see two possible ways to present the address map in the MIB module. One > is to keep things as they are, but add a note that the operator may want to > filter on subscriber index (which is part of the mapping information) to > select the information they really want. If they are starting with the IPv6 > tunnel source address, they have to go to the subscriber table to get the > corresponding subscriber index, then use that to filter the map data. > Not sure what you mean. Are you suggesting a different *usage*, or actual changes to the MIB? > The other possible solution is to index the map data by the "internal > realm address" (which would be the IPv6 tunnel source address) and present > the internal packet source address (which would be the reserved 192.0.0.2) > separately in the mapping table. Except in the case of tunneling, the two > addresses will be the same, so there is redundancy in most cases. However, > the workflow for tracing back from a tunnel source address would be > simplified. > Why not just add the subscriber index to the index? Simon --001a1133f0242c32a405089ec0ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
The published version -11 of t= he NAT MIB module indexes address maps by NAT instance, internal realm, and= internal address. This works fine, I think, except in the CGN case where p= ackets originated by the subscriber come in by way of tunnels. Take DS-Lite= as an example.

In the case of DS-Lite, the realm actually defines an IPv6 numbering space = -- the reserved IPv4 address 192.0.0.2 appearing as the source of packets o= riginated by the subscriber certainly won't be unique over the realm, m= aking nonsense of the definition of realm as defining a numbering space.

The definition of realm should be c= hanged so that the tuple (internal address, subscriber index) is unique.

Actually I argued in the beginning that each DS-Lite= subscriber should have its own realm. That would make for a simpler model,= but it turns out that that maps poorly to current implementations. That= 9;s why we have subscriber indexes now.

I see two possible ways to present the address map in the MIB module. One i= s to keep things as they are, but add a note that the operator may want to = filter on subscriber index (which is part of the mapping information) to se= lect the information they really want. If they are starting with the IPv6 t= unnel source address, they have to go to the subscriber table to get the co= rresponding subscriber index, then use that to filter the map data.

Not sure what you mean. Are you suggesti= ng a different *usage*, or actual changes to the MIB?
=C2=A0
The other possible solution is to index the map data by the "internal = realm address" (which would be the IPv6 tunnel source address) and pre= sent the internal packet source address (which would be the reserved 192.0.= 0.2) separately in the mapping table. Except in the case of tunneling, the = two addresses will be the same, so there is redundancy in most cases. Howev= er, the workflow for tracing back from a tunnel source address would be sim= plified.

Why not just add the subscri= ber index to the index?

Simon
--001a1133f0242c32a405089ec0ad-- From nobody Mon Nov 24 10:51:22 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D501A049A for ; Mon, 24 Nov 2014 10:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_LWU0Zpwh4J for ; Mon, 24 Nov 2014 10:50:37 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 01C861A8794 for ; Mon, 24 Nov 2014 10:50:36 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA23993; Mon, 24 Nov 2014 13:50:31 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id sAOIoVFg004859; Mon, 24 Nov 2014 13:50:32 -0500 (EST) (envelope-from reid@snmp.com) Message-Id: <201411241850.sAOIoVFg004859@mainfs.snmp.com> To: Johannes Merkle From: David Reid In-reply-to: Your message of Fri, 24 Oct 2014 13:19:23 +0200. <544A35BB.2070503@secunet.com> Date: Mon, 24 Nov 2014 13:50:31 -0500 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/rf_9UBPTX4g9ab78qdYbvSiQB2M Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 18:50:43 -0000 X-List-Received-Date: Mon, 24 Nov 2014 18:50:43 -0000 Is there any progress on this? I like the proposal from Johannes to continue with draft-hmac-sha-2-usm-snmp and to shorten the list of protocols. -David Reid > > A month on, what is the WG chairs take on this? > > Good question. Even more time has passed by now. > > Maybe it helps, if I summarize the results of my poll. Hereby, I assume that the authors of the two drafts prefer their > respective approach (a presumption, I can confirm for draft-hmac-sha-2-usm-snmp). > > Question 1: Should the protocols be described > a) as "diff" to the previous protocols like done in draft-hmac-sha-2-usm-snmp, or > b) completely and based on a description of a generic hmac-based authentication protocol, as done in draft-hartman? > > Result: > a) is preferred by the authors of draft-hmac-sha-2-usm-snmp, and by David Reid, Tom Petch, Uri Blumenthal > b) is preferred by the authors of draft-hartman-snmp-sha2. > > Question 2: Should the protocols be based on complete or truncated HMACs? > - complete is preferred by the authors of draft-hartman-snmp-sha2. > - truncated is preferred by the authors of draft-hmac-sha-2-usm-snmp, and by David Reid, Tom Petch, Uri Blumenthal > > Question 3: Which (sub)set of protocols (hash function, MAC length) should be selected? > - Johannes: SHA-256-192 as MUST, SHA-512-256 as SHOULD, all other can be MAY or omitted. > - Uri: SHA-256-192 and SHA-384-320 as MUST, SHA-512-256 as SHOULD, and SHA-224-??? as MAY > - Tom: AFAIU, he agrees with the preferences expressed by David, Johannes and Uri. > - David: SHA-256-192 and SHA-512-384. > (In all the above cases, the preferences were not that strong, there was mainly the wish to reduce the number of > protocols in the current draft.) > - Again, I assume, that the authors of draft-hartman-snmp-sha2 prefer their proposals. > > The preferences are clearly split between two groups, the authors of draft-hartman-snmp-sha2 on one side, the authors of > draft-hmac-sha-2-usm-snmp, David Reid, Tom Petch, and Uri Blumenthal on the other. I don't see any potential compromise > here. > > My proposal, which is clearly biased due to my role as author, is to continue with draft-hmac-sha-2-usm-snmp and to > shorten the list of protocols, e.g. to > usmHMAC192SHA256AuthProtocol as MUST > usmHMAC384SHA512AuthProtocol as SHOULD > usmHMAC256SHA384AuthProtocol and usmHMAC128SHA224AuthProtocol as MAY > > In these proposals the truncation is reduced to 25% which is in line with the preferences expressed by Uri and David, > and may even reduce the concerns of the authors of draft-hartman-snmp-sha2 about truncation. > > > So, chairs, what is your decision? > > Johannes > From nobody Mon Nov 24 15:39:06 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18E91A871E; Mon, 24 Nov 2014 15:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgtX_5Q7aY_R; Mon, 24 Nov 2014 15:39:01 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6FB1A802E; Mon, 24 Nov 2014 15:39:01 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id r2so4093661igi.0 for ; Mon, 24 Nov 2014 15:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ND1Fk9UuvhHn2Mr4PZT0/9qnwXzHRtzRxer0v9mXMHE=; b=JdQ7nifIGv11CERWffix85AhXsVLVCqae3fb/QxX4M9myb3IWQ8DzudqKKo9YzhvKz H8UdAiFU4GsNNo5BA2MaWGXli4TQplzsPlLUCG05mGlBwmVDPUqnc9YW+QPJeMXnPmOB i+YGer6afb5sogEMQikG+qu+K+ToyjFVfXemVoc8KG/mD9RPzJeTPBAaXDGYr5gKZ963 nCdtLy1xdxQzqgnyUlnxfKc57Wc9IpOUM6vYzdOqoJ9cf8qcH7lfXAK/flrYw+0eA423 OcDf6VuLWQyYaGnEu+KFf5dKCL0Kg9m3rFMmXx/Qk1fFe0RqiwgVIjnvXZck45Z3EmiU BTLg== X-Received: by 10.50.138.76 with SMTP id qo12mr14739679igb.43.1416872340540; Mon, 24 Nov 2014 15:39:00 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id fy5sm5225203igd.3.2014.11.24.15.38.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 15:39:00 -0800 (PST) Message-ID: <5473C191.2020101@gmail.com> Date: Mon, 24 Nov 2014 18:38:57 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ZijVeH4e_4yjuqViyZCunjD7LWY Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 23:39:05 -0000 Below, with [PTT]. On 24/11/2014 1:13 PM, Simon Perreault wrote: > On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor > wrote: > >> The published version -11 of the NAT MIB module indexes address maps by >> NAT instance, internal realm, and internal address. This works fine, I >> think, except in the CGN case where packets originated by the subscriber >> come in by way of tunnels. Take DS-Lite as an example. >> >> In the case of DS-Lite, the realm actually defines an IPv6 numbering space >> -- the reserved IPv4 address 192.0.0.2 appearing as the source of packets >> originated by the subscriber certainly won't be unique over the realm, >> making nonsense of the definition of realm as defining a numbering space. >> > > The definition of realm should be changed so that the tuple (internal > address, subscriber index) is unique. > > Actually I argued in the beginning that each DS-Lite subscriber should have > its own realm. That would make for a simpler model, but it turns out that > that maps poorly to current implementations. That's why we have subscriber > indexes now. > > I see two possible ways to present the address map in the MIB module. One >> is to keep things as they are, but add a note that the operator may want to >> filter on subscriber index (which is part of the mapping information) to >> select the information they really want. If they are starting with the IPv6 >> tunnel source address, they have to go to the subscriber table to get the >> corresponding subscriber index, then use that to filter the map data. >> > > Not sure what you mean. Are you suggesting a different *usage*, or actual > changes to the MIB? > [PTT] Different usage, just the necessary information in the description clause. Anyway, I prefer the suggestion at the end. > >> The other possible solution is to index the map data by the "internal >> realm address" (which would be the IPv6 tunnel source address) and present >> the internal packet source address (which would be the reserved 192.0.0.2) >> separately in the mapping table. Except in the case of tunneling, the two >> addresses will be the same, so there is redundancy in most cases. However, >> the workflow for tracing back from a tunnel source address would be >> simplified. >> > > Why not just add the subscriber index to the index? [PTT] Bearing in mind the application scenarios we listed the other day, I figured subscriber wouldn't always be supported. However, I've already defined a Natv2SubscriberIndexOrZero for the map, so it won't do any harm to add it to the map index. > > Simon > From nobody Mon Nov 24 15:39:14 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF5C1A879F; Mon, 24 Nov 2014 15:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHYC0ZGJJRdJ; Mon, 24 Nov 2014 15:39:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 712821A8770; Mon, 24 Nov 2014 15:39:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141124233907.21407.7374.idtracker@ietfa.amsl.com> Date: Mon, 24 Nov 2014 15:39:07 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/vWbTH66F5eq1QfRJoQzcIMMfp5g Cc: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, opsawg-chairs@tools.ietf.org Subject: [OPSAWG] Spencer Dawkins' No Objection on draft-ietf-opsawg-mibs-to-ieee80231-01: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 23:39:09 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-opsawg-mibs-to-ieee80231-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have the same questions that Brian put in his Discuss, but if you answer his questions, I'll believe you ... From nobody Tue Nov 25 11:16:40 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DD11ACEFC for ; Tue, 25 Nov 2014 11:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVye7otdiGIv; Tue, 25 Nov 2014 11:15:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B6B1A87DB; Tue, 25 Nov 2014 11:15:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-opsawg-mibs-to-ieee80231.all@tools.ietf.org, opsawg@ietf.org, warren@kumari.net, opsawg-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125191529.18572.75919.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 11:15:29 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/r9W9cg1wHYVsRUTav2HGkQP-mTE Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 19:15:30 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ From nobody Wed Nov 26 09:55:01 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550F11A1A55 for ; Wed, 26 Nov 2014 09:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f51CAmecIYEl for ; Wed, 26 Nov 2014 09:54:57 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2391A1A52 for ; Wed, 26 Nov 2014 09:54:57 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x12so4413995wgg.19 for ; Wed, 26 Nov 2014 09:54:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QXqHuCoBH/T3xhAsLgOjtLVqD7WG6Qi5JO7ezuniSXA=; b=d1hQ43U5zdYBuL5l98fRZuRUYsRvFCWGzlaFCOSkbODmsZSwYA8JXtq2THxC5MSw4/ HVHUphqQUL8x1xQWEstOoOx0zVWBya6HN837fGWB8Mz2cEJdAvXYKA0bTEwgvJnChcy+ DhvguPOhw7cHw6Go2cR6McPFuVq1wnDVhlBdRq/BxKirdWcGKXcBnLq2W/rg0PNtoVMx 6A/cAujWOKwiBFPiRV6PGcVNmwj1Q09CvKy/Jr15BPuTKsy35MVT+3xyY4cBPhr3ZAqb acQS6jD53M3X9fkaunEjQ+HvazG/5DgmZYkWm4f6Qvi7YALENcjjsGQV45SRekLTtCRd kkrQ== X-Gm-Message-State: ALoCoQkw50sQ6q92y9wOny7AbsYNwDHyC8+8m63TA/ZD5mThQfWUqL7pQA2aoQEg0Ebdgypo91Vw MIME-Version: 1.0 X-Received: by 10.180.210.226 with SMTP id mx2mr43147124wic.42.1417024496163; Wed, 26 Nov 2014 09:54:56 -0800 (PST) Received: by 10.194.64.37 with HTTP; Wed, 26 Nov 2014 09:54:56 -0800 (PST) In-Reply-To: <201411241850.sAOIoVFg004859@mainfs.snmp.com> References: <544A35BB.2070503@secunet.com> <201411241850.sAOIoVFg004859@mainfs.snmp.com> Date: Wed, 26 Nov 2014 12:54:56 -0500 Message-ID: From: Warren Kumari To: David Reid Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/f5etyrNVlalwsdEU8OWIsgGD0dE Cc: "opsawg@ietf.org" , draft-hmac-sha-2-usm-snmp@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-hmac-sha-2-usm-snmp X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 17:54:59 -0000 On Mon, Nov 24, 2014 at 1:50 PM, David Reid wrote: > Is there any progress on this? > Wow. Yes, sorry, there is... We mentioned in the face to face meeting at IETF91 that we would be adopting draft-hmac-sha-2-usm-snmp (and thanking Sam et al. for supporting this decision) - however, we never actually sent the "Dear authors, please resubmit draft-hmac-sha-2-usm-snmp as draft-ietf-opsawg-hmac-sha-2-usm-snmp"[0]. So, dear authors, please resubmit as.. etc. Also, thanks to the authors of draft-hartman-snmp-sha2 and draft-hmac-sha-2-usm-snmp, and the WG participants for all of their work and input on this. W [0]: I took the week after IETF off as vacation, then looked at the unread email and have been hiding under the covers ever since, hoping it might all just disappear... > I like the proposal from Johannes to continue with draft-hmac-sha-2-usm-snmp > and to shorten the list of protocols. > > -David Reid > >> > A month on, what is the WG chairs take on this? >> >> Good question. Even more time has passed by now. >> >> Maybe it helps, if I summarize the results of my poll. Hereby, I assume that the authors of the two drafts prefer their >> respective approach (a presumption, I can confirm for draft-hmac-sha-2-usm-snmp). >> >> Question 1: Should the protocols be described >> a) as "diff" to the previous protocols like done in draft-hmac-sha-2-usm-snmp, or >> b) completely and based on a description of a generic hmac-based authentication protocol, as done in draft-hartman? >> >> Result: >> a) is preferred by the authors of draft-hmac-sha-2-usm-snmp, and by David Reid, Tom Petch, Uri Blumenthal >> b) is preferred by the authors of draft-hartman-snmp-sha2. >> >> Question 2: Should the protocols be based on complete or truncated HMACs? >> - complete is preferred by the authors of draft-hartman-snmp-sha2. >> - truncated is preferred by the authors of draft-hmac-sha-2-usm-snmp, and by David Reid, Tom Petch, Uri Blumenthal >> >> Question 3: Which (sub)set of protocols (hash function, MAC length) should be selected? >> - Johannes: SHA-256-192 as MUST, SHA-512-256 as SHOULD, all other can be MAY or omitted. >> - Uri: SHA-256-192 and SHA-384-320 as MUST, SHA-512-256 as SHOULD, and SHA-224-??? as MAY >> - Tom: AFAIU, he agrees with the preferences expressed by David, Johannes and Uri. >> - David: SHA-256-192 and SHA-512-384. >> (In all the above cases, the preferences were not that strong, there was mainly the wish to reduce the number of >> protocols in the current draft.) >> - Again, I assume, that the authors of draft-hartman-snmp-sha2 prefer their proposals. >> >> The preferences are clearly split between two groups, the authors of draft-hartman-snmp-sha2 on one side, the authors of >> draft-hmac-sha-2-usm-snmp, David Reid, Tom Petch, and Uri Blumenthal on the other. I don't see any potential compromise >> here. >> >> My proposal, which is clearly biased due to my role as author, is to continue with draft-hmac-sha-2-usm-snmp and to >> shorten the list of protocols, e.g. to >> usmHMAC192SHA256AuthProtocol as MUST >> usmHMAC384SHA512AuthProtocol as SHOULD >> usmHMAC256SHA384AuthProtocol and usmHMAC128SHA224AuthProtocol as MAY >> >> In these proposals the truncation is reduced to 25% which is in line with the preferences expressed by Uri and David, >> and may even reduce the concerns of the authors of draft-hartman-snmp-sha2 about truncation. >> >> >> So, chairs, what is your decision? >> >> Johannes >> -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Nov 27 10:50:07 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BFD1A0123; Thu, 27 Nov 2014 10:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qChKX1BZyBQv; Thu, 27 Nov 2014 10:50:03 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14A71A010D; Thu, 27 Nov 2014 10:50:02 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so4664098igb.17 for ; Thu, 27 Nov 2014 10:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NhyxkYtMqOHykUtZRh193o0NPHOtOPQfPylQ+vQMbfQ=; b=asz152P0yujHMTIHDQQ4Pd2PREKa6wXCimS0IYURHE0rnmvAIiLYxMg7iBHQwOz5Pn dJQHbdD5yJf+OSJ5wil4csKm6Qfuw84PgZNxITYbdsA1T6PgF+y0c74BpafI30/5qkNL 95e+WWcvqVdoJ/Ha7Dkip8LwnQw6N+AF6KvCTL140ndGOMa+Lqt2VkGHRfY3HmbZzKVG rB++wIwdgCmwGxSTAOKFEvc26ne9RdAi1S3lIPRN4AD2HWlWqh/CukbdgoHBOmLtQe2J aaETU0xIXuRBY1iGkq6i9hlDRm5AleKhV0xBGYxHAli4D9zwhrlG1gKIpe+GvdJJhkY5 DDEw== X-Received: by 10.107.162.134 with SMTP id l128mr23445828ioe.65.1417114201696; Thu, 27 Nov 2014 10:50:01 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id i184sm3878196ioi.33.2014.11.27.10.50.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 10:50:01 -0800 (PST) Message-ID: <54777259.5060202@gmail.com> Date: Thu, 27 Nov 2014 13:50:01 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/nShpHhkNYu3BYSwW2deoPWmRpA4 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 18:50:05 -0000 I have thought this through a bit more. One of the results is a resolution between the need to define an IPv6 realm covering some group of DS-Lite-served subscribers and your intuition that there should be a realm per subscriber. In fact, both are true simultaneously, but the scope of the IPv4 realm is limited to the tunnel in which it operates, so it isn't very interesting. What I propose at this point is as follows: natv2AddressMapInternalRealm OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Realm to which the internal address belongs. In most cases this is the realm defining the address space of the packet being translated. However, in the case of DS-Lite [RFC 6333], this realm defines the IPv6 outer header address space, while it is the inner IPv4 packet header that is remapped to the external address and realm. The corresponding IPv4 realm is restricted in scope to the tunnel, so there is no point in identifying it. Similarly, the mapped IPv4 address will normally be the well-known value 192.0.0.2, or at least lie in the reserved 192.0.0.0/29 range, and hence is not particularly interesting. If natv2AddressMapSubscriberIndex in this table is a valid subscriber index (i.e., greater than zero), then the value of natv2AddressMapInternalRealm MUST be identical to the value of natv2SubscriberRealm associated with that index." REFERENCE "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and Section 6.6 on the need to have the IPv6 tunnel address in the NAT mapping tables." ::= { natv2AddressMapEntry 2 } natv2AddressMapInternalAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Address type in the header of packets on the interior side of this mapping. Any value other than ipv4(1) or ipv6(2) would be unexpected. In the DS-Lite case, the address type is ipv6(2). The mapping in that case is considered to be from the combination of the IPv6 tunnel source address and the well-known IPv4 inner source address (which is not presented in this table) to the external address." REFERENCE "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and Section 6.6 on the need to have the IPv6 tunnel address in the NAT mapping tables." ::= { natv2AddressMapEntry 3 } natv2AddressMapInternalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Source address of packets originating from the interior of the association provided by this mapping. In the case of DS-Lite [RFC 6333], this is the IPv6 tunnel source address. In this case, the mapping is considered to be from the combination of the tunnel source address and the well-known IPv4 inner source address (which is not presented in this table) to the external address." REFERENCE "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and Section 6.6 on the need to have the IPv6 tunnel address in the NAT mapping tables." ::= { natv2AddressMapEntry 4 } Tom Taylor On 24/11/2014 1:13 PM, Simon Perreault wrote: > > On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor > wrote: > > The published version -11 of the NAT MIB module indexes address maps > by NAT instance, internal realm, and internal address. This works > fine, I think, except in the CGN case where packets originated by > the subscriber come in by way of tunnels. Take DS-Lite as an example. > > In the case of DS-Lite, the realm actually defines an IPv6 numbering > space -- the reserved IPv4 address 192.0.0.2 appearing as the source > of packets originated by the subscriber certainly won't be unique > over the realm, making nonsense of the definition of realm as > defining a numbering space. > > > The definition of realm should be changed so that the tuple (internal > address, subscriber index) is unique. > > Actually I argued in the beginning that each DS-Lite subscriber should > have its own realm. That would make for a simpler model, but it turns > out that that maps poorly to current implementations. That's why we have > subscriber indexes now. > > I see two possible ways to present the address map in the MIB > module. One is to keep things as they are, but add a note that the > operator may want to filter on subscriber index (which is part of > the mapping information) to select the information they really want. > If they are starting with the IPv6 tunnel source address, they have > to go to the subscriber table to get the corresponding subscriber > index, then use that to filter the map data. > > > Not sure what you mean. Are you suggesting a different *usage*, or > actual changes to the MIB? > > The other possible solution is to index the map data by the > "internal realm address" (which would be the IPv6 tunnel source > address) and present the internal packet source address (which would > be the reserved 192.0.0.2) separately in the mapping table. Except > in the case of tunneling, the two addresses will be the same, so > there is redundancy in most cases. However, the workflow for tracing > back from a tunnel source address would be simplified. > > > Why not just add the subscriber index to the index? > > Simon From nobody Thu Nov 27 10:56:27 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97B91A0145 for ; Thu, 27 Nov 2014 10:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.331 X-Spam-Level: * X-Spam-Status: No, score=1.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAgmQxMeeRxl for ; Thu, 27 Nov 2014 10:56:23 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFCE1A013B for ; Thu, 27 Nov 2014 10:56:22 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so4497370lab.40 for ; Thu, 27 Nov 2014 10:56:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9T2zqYvBkgsbvZSUJEMztSduDJsu2tbi+PhG8ymSJ/A=; b=CyS/4S5ZGWZrNjbBRp/oQFxg/4BG+mLA8qtU4jFC+Imsc3gM8Vnc07NUJnlDatElJM ZdEOT1xG4LPC2w3MWDCW1kA1cuZ28JP54XyTWmdL4twTJl+JT6m9GhUunRl69TrCQUrM t3D95XOcdhxyOSdgeuFi00Aco+SWe3LvBL224eTayjZzId4gtUvel3vG+AYsdwOX/41G 25gZ0LPYSqK9Mx8FPIDXCjyw2tK0VJLmk7A0xBwj3saog84u8FCWU5ypvfS2ST9nxMJv teFdr+G/dz09NPIfgHveK9Fyt4bAKEXmHp/ErMcR+/KIRLsYEMI3o+nUQ03KPVlWzGyz qfnQ== X-Gm-Message-State: ALoCoQnoT3tj3dUuUm65heZGQ2eu+HY65fJxoAn8YriqCX8IVijb3isecg5VYvSeSjmnBOy7B9IC MIME-Version: 1.0 X-Received: by 10.112.219.227 with SMTP id pr3mr36895956lbc.63.1417114581283; Thu, 27 Nov 2014 10:56:21 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 27 Nov 2014 10:56:21 -0800 (PST) In-Reply-To: <54777259.5060202@gmail.com> References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> Date: Thu, 27 Nov 2014 13:56:21 -0500 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a11c334123957060508dbb331 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/-6cqPh6hMAD7GZMjNnM86Bp6yLw Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 18:56:26 -0000 --001a11c334123957060508dbb331 Content-Type: text/plain; charset=UTF-8 Ok so if I understand correctly, you replace the IPv4 --> IPv4 address mapping with the IPv6 --> IPv4 address mapping in the case of DS-Lite. If that's right, then I don't see how it could work. There is not necessarily such an IPv6 --> IPv4 address mapping. The internal 192.0.0.0/29 addresses could be mapped to different external IPv4 addresses. Or maybe I misunderstood your proposal... Simon On Thu, Nov 27, 2014 at 1:50 PM, Tom Taylor wrote: > I have thought this through a bit more. One of the results is a resolution > between the need to define an IPv6 realm covering some group of > DS-Lite-served subscribers and your intuition that there should be a realm > per subscriber. In fact, both are true simultaneously, but the scope of the > IPv4 realm is limited to the tunnel in which it operates, so it isn't very > interesting. > > What I propose at this point is as follows: > > natv2AddressMapInternalRealm OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(0..32)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Realm to which the internal address belongs. In most cases > this is the realm defining the address space of the packet > being translated. However, in the case of DS-Lite [RFC > 6333], this realm defines the IPv6 outer header address > space, while it is the inner IPv4 packet header that is > remapped to the external address and realm. The > corresponding IPv4 realm is restricted in scope to the > tunnel, so there is no point in identifying it. Similarly, > the mapped IPv4 address will normally be the well-known > value 192.0.0.2, or at least lie in the reserved > 192.0.0.0/29 range, and hence is not particularly > interesting. > > If natv2AddressMapSubscriberIndex in this table is a valid > subscriber index (i.e., greater than zero), then the value > of natv2AddressMapInternalRealm MUST be identical to the > value of natv2SubscriberRealm associated with that index." > REFERENCE > "DS-Lite: RFC 6333, Section 5.7 for well-known addresses > and Section 6.6 on the need to have the IPv6 tunnel address > in the NAT mapping tables." > ::= { natv2AddressMapEntry 2 } > > natv2AddressMapInternalAddressType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Address type in the header of packets on the > interior side of this mapping. Any value other than ipv4(1) > or ipv6(2) would be unexpected. > > In the DS-Lite case, the address type is ipv6(2). The > mapping in that case is considered to be from the > combination of the IPv6 tunnel source address and the > well-known IPv4 inner source address (which is not presented > in this table) to the external address." > REFERENCE > "DS-Lite: RFC 6333, Section 5.7 for well-known addresses > and Section 6.6 on the need to have the IPv6 tunnel address > in the NAT mapping tables." > ::= { natv2AddressMapEntry 3 } > > natv2AddressMapInternalAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Source address of packets originating from the interior > of the association provided by this mapping. > > In the case of DS-Lite [RFC 6333], this is the IPv6 tunnel > source address. In this case, the mapping is considered to > be from the combination of the tunnel source address and the > well-known IPv4 inner source address (which is not presented > in this table) to the external address." > REFERENCE > "DS-Lite: RFC 6333, Section 5.7 for well-known addresses > and Section 6.6 on the need to have the IPv6 tunnel address > in the NAT mapping tables." > ::= { natv2AddressMapEntry 4 } > > Tom Taylor > > On 24/11/2014 1:13 PM, Simon Perreault wrote: > >> >> On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor > > wrote: >> >> The published version -11 of the NAT MIB module indexes address maps >> by NAT instance, internal realm, and internal address. This works >> fine, I think, except in the CGN case where packets originated by >> the subscriber come in by way of tunnels. Take DS-Lite as an example. >> >> In the case of DS-Lite, the realm actually defines an IPv6 numbering >> space -- the reserved IPv4 address 192.0.0.2 appearing as the source >> of packets originated by the subscriber certainly won't be unique >> over the realm, making nonsense of the definition of realm as >> defining a numbering space. >> >> >> The definition of realm should be changed so that the tuple (internal >> address, subscriber index) is unique. >> >> Actually I argued in the beginning that each DS-Lite subscriber should >> have its own realm. That would make for a simpler model, but it turns >> out that that maps poorly to current implementations. That's why we have >> subscriber indexes now. >> >> I see two possible ways to present the address map in the MIB >> module. One is to keep things as they are, but add a note that the >> operator may want to filter on subscriber index (which is part of >> the mapping information) to select the information they really want. >> If they are starting with the IPv6 tunnel source address, they have >> to go to the subscriber table to get the corresponding subscriber >> index, then use that to filter the map data. >> >> >> Not sure what you mean. Are you suggesting a different *usage*, or >> actual changes to the MIB? >> >> The other possible solution is to index the map data by the >> "internal realm address" (which would be the IPv6 tunnel source >> address) and present the internal packet source address (which would >> be the reserved 192.0.0.2) separately in the mapping table. Except >> in the case of tunneling, the two addresses will be the same, so >> there is redundancy in most cases. However, the workflow for tracing >> back from a tunnel source address would be simplified. >> >> >> Why not just add the subscriber index to the index? >> >> Simon >> > --001a11c334123957060508dbb331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok so if I understand correctly, you replace the IPv4 --&g= t; IPv4 address mapping with the IPv6 --> IPv4 address mapping in the ca= se of DS-Lite.

If that's right, then I don't see= how it could work. There is not necessarily such an IPv6 --> IPv4 addre= ss mapping. The internal 192.0.0.0/29 a= ddresses could be mapped to different external IPv4 addresses. Or maybe I m= isunderstood your proposal...

Simon

On Thu, Nov 27, 2014= at 1:50 PM, Tom Taylor <tom.taylor.stds@gmail.com> = wrote:
I have thought this through a bit = more. One of the results is a resolution between the need to define an IPv6= realm covering some group of DS-Lite-served subscribers and your intuition= that there should be a realm per subscriber. In fact, both are true simult= aneously, but the scope of the IPv4 realm is limited to the tunnel in which= it operates, so it isn't very interesting.

What I propose at this point is as follows:

natv2AddressMapInternalRealm OBJECT-TYPE
=C2=A0 =C2=A0 SYNTAX SnmpAdminString (SIZE(0..32))
=C2=A0 =C2=A0 MAX-ACCESS not-accessible
=C2=A0 =C2=A0 STATUS current
=C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Realm to which the internal address belon= gs. In most cases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this is the realm defining the address sp= ace of the packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0being translated. However, in the case of= DS-Lite [RFC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06333], this realm defines the IPv6 outer = header address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0space, while it is the inner IPv4 packet = header that is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0remapped to the external address and real= m. The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0corresponding IPv4 realm is restricted in= scope to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tunnel, so there is no point in identifyi= ng it. Similarly,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the mapped IPv4 address will normally be = the well-known
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value 192.0.0.2, or at least lie in the r= eserved
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0192.0.0.0/29 range, and hence is not particularly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interesting.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If natv2AddressMapSubscriberIndex in this= table is a valid
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subscriber index (i.e., greater than zero= ), then the value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of natv2AddressMapInternalRealm MUST be i= dentical to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value of natv2SubscriberRealm associated = with that index."
=C2=A0 =C2=A0 REFERENCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "DS-Lite: RFC 6333, Section 5.7 for well-k= nown addresses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Section 6.6 on the need to have the I= Pv6 tunnel address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the NAT mapping tables."
=C2=A0 =C2=A0 ::=3D { natv2AddressMapEntry 2 }

natv2AddressMapInternalAddressType OBJECT-TYPE
=C2=A0 =C2=A0 SYNTAX InetAddressType
=C2=A0 =C2=A0 MAX-ACCESS read-only
=C2=A0 =C2=A0 STATUS current
=C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Address type in the header of packets on = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interior side of this mapping. Any value = other than ipv4(1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or ipv6(2) would be unexpected.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the DS-Lite case, the address type is = ipv6(2). The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mapping in that case is considered to be = from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0combination of the IPv6 tunnel source add= ress and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0well-known IPv4 inner source address (whi= ch is not presented
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in this table) to the external address.&q= uot;
=C2=A0 =C2=A0 REFERENCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "DS-Lite: RFC 6333, Section 5.7 for well-k= nown addresses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Section 6.6 on the need to have the I= Pv6 tunnel address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the NAT mapping tables."
=C2=A0 =C2=A0 ::=3D { natv2AddressMapEntry 3 }

natv2AddressMapInternalAddress OBJECT-TYPE
=C2=A0 =C2=A0 SYNTAX InetAddress
=C2=A0 =C2=A0 MAX-ACCESS read-only
=C2=A0 =C2=A0 STATUS current
=C2=A0 =C2=A0 DESCRIPTION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Source address of packets originating fro= m the interior
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the association provided by this mappi= ng.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the case of DS-Lite [RFC 6333], this i= s the IPv6 tunnel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source address. In this case, the mapping= is considered to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be from the combination of the tunnel sou= rce address and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0well-known IPv4 inner source address (whi= ch is not presented
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in this table) to the external address.&q= uot;
=C2=A0 =C2=A0 REFERENCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "DS-Lite: RFC 6333, Section 5.7 for well-k= nown addresses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Section 6.6 on the need to have the I= Pv6 tunnel address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the NAT mapping tables."
=C2=A0 =C2=A0 ::=3D { natv2AddressMapEntry 4 }

Tom Taylor

On 24/11/2014 1:13 PM, Simon Perreault wrote:

On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor <tom.taylor.stds@gmail.com
<mailto:t= om.taylor.stds@gmail.com>> wrote:

=C2=A0 =C2=A0 The published version -11 of the NAT MIB module indexes addre= ss maps
=C2=A0 =C2=A0 by NAT instance, internal realm, and internal address. This w= orks
=C2=A0 =C2=A0 fine, I think, except in the CGN case where packets originate= d by
=C2=A0 =C2=A0 the subscriber come in by way of tunnels. Take DS-Lite as an = example.

=C2=A0 =C2=A0 In the case of DS-Lite, the realm actually defines an IPv6 nu= mbering
=C2=A0 =C2=A0 space -- the reserved IPv4 address 192.0.0.2 appearing as the= source
=C2=A0 =C2=A0 of packets originated by the subscriber certainly won't b= e unique
=C2=A0 =C2=A0 over the realm, making nonsense of the definition of realm as=
=C2=A0 =C2=A0 defining a numbering space.


The definition of realm should be changed so that the tuple (internal
address, subscriber index) is unique.

Actually I argued in the beginning that each DS-Lite subscriber should
have its own realm. That would make for a simpler model, but it turns
out that that maps poorly to current implementations. That's why we hav= e
subscriber indexes now.

=C2=A0 =C2=A0 I see two possible ways to present the address map in the MIB=
=C2=A0 =C2=A0 module. One is to keep things as they are, but add a note tha= t the
=C2=A0 =C2=A0 operator may want to filter on subscriber index (which is par= t of
=C2=A0 =C2=A0 the mapping information) to select the information they reall= y want.
=C2=A0 =C2=A0 If they are starting with the IPv6 tunnel source address, the= y have
=C2=A0 =C2=A0 to go to the subscriber table to get the corresponding subscr= iber
=C2=A0 =C2=A0 index, then use that to filter the map data.


Not sure what you mean. Are you suggesting a different *usage*, or
actual changes to the MIB?

=C2=A0 =C2=A0 The other possible solution is to index the map data by the =C2=A0 =C2=A0 "internal realm address" (which would be the IPv6 t= unnel source
=C2=A0 =C2=A0 address) and present the internal packet source address (whic= h would
=C2=A0 =C2=A0 be the reserved 192.0.0.2) separately in the mapping table. E= xcept
=C2=A0 =C2=A0 in the case of tunneling, the two addresses will be the same,= so
=C2=A0 =C2=A0 there is redundancy in most cases. However, the workflow for = tracing
=C2=A0 =C2=A0 back from a tunnel source address would be simplified.


Why not just add the subscriber index to the index?

Simon

--001a11c334123957060508dbb331-- From nobody Thu Nov 27 11:06:47 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE99D1A00E9; Thu, 27 Nov 2014 11:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.309 X-Spam-Level: * X-Spam-Status: No, score=1.309 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, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSao8AyZgpEc; Thu, 27 Nov 2014 11:06:41 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651171A0146; Thu, 27 Nov 2014 11:06:41 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id rl12so4968893iec.30 for ; Thu, 27 Nov 2014 11:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qaq1aVGHAg7ljaDccMZdA4MsapU7hWduY6Sjr0j2KGs=; b=hq+1o5CDv2EZETA457tEKn9fhMzoxfbccGo+YjLokgy9OtzaKp60xiAvF85+uUj/ge Hrfo0syTfrtS8pnj3M/pRCPmrroMsys3iaYg44uGV4dSFj1F5tBXrYDDR6BZiSBLGQJ4 7rZj7WO4AQEpJGCeQiNyEKDE2EnJ0bRapUJLnP3DQBrif5nXyjl8i89Eo0/8WK9Cj5RS tSrkgKd0V415kQ2Mu4yJz1aNEx/LKNyjGc+iVfPKryxNfRE9gy/51gk7/oqNG2AEfNdU 7rGEJZVlwR0leO9SiHi6sOieiHr1Uk3ENCLbu+ov+Xtr393/9VLwvz6LoTm3SrIIL7vb FtgA== X-Received: by 10.50.66.179 with SMTP id g19mr29830239igt.40.1417115200515; Thu, 27 Nov 2014 11:06:40 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id 69sm1810474ioo.28.2014.11.27.11.06.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 11:06:40 -0800 (PST) Message-ID: <5477763A.4070305@gmail.com> Date: Thu, 27 Nov 2014 14:06:34 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/YXKHNNPPTcnpkdqFxLZjA-GkVtA Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:06:43 -0000 In the first place, you replace the IPv4 --> IPv4 mapping with {IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333. Beyond that, the text I gave refers to a single mapping in the address map table. For different external IPv4 external addresses, you would be looking at different mapping instances. Tom On 27/11/2014 1:56 PM, Simon Perreault wrote: > Ok so if I understand correctly, you replace the IPv4 --> IPv4 address > mapping with the IPv6 --> IPv4 address mapping in the case of DS-Lite. > > If that's right, then I don't see how it could work. There is not > necessarily such an IPv6 --> IPv4 address mapping. The internal > 192.0.0.0/29 addresses could be mapped to > different external IPv4 addresses. Or maybe I misunderstood your proposal... > > Simon > ... From nobody Thu Nov 27 11:11:45 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DD31A0146 for ; Thu, 27 Nov 2014 11:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pqopelf6Rc98 for ; Thu, 27 Nov 2014 11:11:40 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6451A013B for ; Thu, 27 Nov 2014 11:11:39 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so4587391lab.4 for ; Thu, 27 Nov 2014 11:11:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QbE/DofKLiZEXTNe71E7+TU2K8IsI+w27cLLhMkvgxY=; b=J5WD9QstlZQ9dLT2cO0FekAu2DQX5+BCaJIeI1FHjrf6rt1H5xbEFG08tBz/B2ibkP 6EK/43Jwa5uQC9SrbZ0/vmPwOQ1TUGbuyaXOc74jxbO38wlTr3eN6bBGP4jUVgXEv2Tq roFGEfQ+elXvcGH7Xm2te0fBgQFQ4ihYy7ZQuIdBcjYTU5bs5ql5Vb0RQg3fSMo0saPH 2iURCn0Ilea94i64rgzp3YARMjXQBM/cVh1k17LyNtqXPHlqLNjHVnDFbMvvZ6uVvxit 1Y7wCj8LV3Gysgdk/CMZYf9fhXM0WuIMxXUHstDGrsbrVV9ZP8x02Rbez0IsQHtGF9WY tN5A== X-Gm-Message-State: ALoCoQm1uaYrOR5G07It0WSaQMJrCAOimzDbvMs4HxbJh8JWpMXyCKPynqKCehi5wHdFas4bw5XI MIME-Version: 1.0 X-Received: by 10.112.168.97 with SMTP id zv1mr40898278lbb.6.1417115498099; Thu, 27 Nov 2014 11:11:38 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 27 Nov 2014 11:11:38 -0800 (PST) In-Reply-To: <5477763A.4070305@gmail.com> References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> <5477763A.4070305@gmail.com> Date: Thu, 27 Nov 2014 14:11:38 -0500 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a11c341c8decbc10508dbe94b Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/UBazpupemNxd37oAhSmEJ8ec41U Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:11:42 -0000 --001a11c341c8decbc10508dbe94b Content-Type: text/plain; charset=UTF-8 On Thu, Nov 27, 2014 at 2:06 PM, Tom Taylor wrote: > In the first place, you replace the IPv4 --> IPv4 mapping with > {IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333. > I understand that, but I don't see how the proposed MIB text does that. Beyond that, the text I gave refers to a single mapping in the address map > table. For different external IPv4 external addresses, you would be looking > at different mapping instances. > Can you please give an example with numbers showing how a DS-Lite address mapping would be represented in the MIB? Thanks, Simon --001a11c341c8decbc10508dbe94b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Nov 27, 2014 at 2:06 PM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
In the first place, you replac= e the IPv4 --> IPv4 mapping with
{IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333.

I understand that, but I don't see how th= e proposed MIB text does that.

Beyond that, the text I gave refers to a single mapping in the address map = table. For different external IPv4 external addresses, you would be looking= at different mapping instances.

Can you please= give an example with numbers showing how a DS-Lite address mapping would b= e represented in the MIB?

Thanks,
Simon
--001a11c341c8decbc10508dbe94b-- From nobody Thu Nov 27 11:23:37 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BDD1A015F; Thu, 27 Nov 2014 11:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLZ5RE8GHySR; Thu, 27 Nov 2014 11:23:12 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4521C1A0173; Thu, 27 Nov 2014 11:23:12 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so4707303igd.13 for ; Thu, 27 Nov 2014 11:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=L5ecvSXZoG3MUXlcz/+k0oHOY1MTv3jyLcSWcDoS++o=; b=zCGnGnQt+sl9UhkZu1mBRzvE3HyjiwMGVNG6pkXE0RfOHY/JV3gk3nn38TKu0TyZdq kXjr2vdL9dJsZM/YzbQ+HL0U5km5+fBfY/D1igy+IZsek0fkmYOHADjDHhr48XKhb8yD kdbey4nbpOEZP71NlWrXWhZwIZmTjj2fIUPY9OQaIkcb9q8V8Poh9059tTltVHbM0muk JxCGgnRCroh6XkOQmK/JvCW4wq0bXH4CgZCzmS/zuJvoTd5pprkEoMgiuxxvQB4NKBEG 9dhOcDVvHLNcOjeUhndsG9hgPrDfdu6Lt91C5HexPtzdOulPUsGwGVeX22teDxcRgL53 tsHQ== X-Received: by 10.50.78.164 with SMTP id c4mr14916529igx.1.1417116191251; Thu, 27 Nov 2014 11:23:11 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id jg3sm968251igb.12.2014.11.27.11.23.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 11:23:10 -0800 (PST) Message-ID: <54777A19.4010409@gmail.com> Date: Thu, 27 Nov 2014 14:23:05 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> <5477763A.4070305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/QOY0EepcAXYUgbI0BZobBztCtIQ Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:23:22 -0000 Just to set the agenda: the definition of the address mapping table entry: natv2AddressMapEntry OBJECT-TYPE SYNTAX Natv2AddressMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Mapping from internal to external address." INDEX { natv2AddressMapInstanceIndex, natv2AddressMapInternalRealm, natv2AddressMapInternalAddressType, natv2AddressMapInternalAddress } ::= { natv2AddressMapTable 1 } Natv2AddressMapEntry ::= SEQUENCE { natv2AddressMapInstanceIndex Natv2InstanceIndex, natv2AddressMapInternalRealm SnmpAdminString, natv2AddressMapInternalAddressType InetAddressType, natv2AddressMapInternalAddress InetAddress, natv2AddressMapExternalRealm SnmpAdminString, natv2AddressMapExternalAddressType InetAddressType, natv2AddressMapExternalAddress InetAddress, natv2AddressMapSubscriberIndex Natv2SubscriberIndexOrZero } Now some example numbers: natv2AddressMapInstanceIndex = 1 natv2AddressMapInternalRealm = "DS-Lite Group 5" natv2AddressMapInternalAddressType = ipv6(2) natv2AddressMapInternalAddress = 2001:db8:0:1::1 natv2AddressMapExternalRealm = "global4" natv2AddressMapExternalAddressType = ipv4(1) natv2AddressMapExternalAddress = 192.0.2.1 natv2AddressMapSubscriberIndex = 487231 This entry would be indexed by the combination of { 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 } Tom On 27/11/2014 2:11 PM, Simon Perreault wrote: > On Thu, Nov 27, 2014 at 2:06 PM, Tom Taylor > wrote: > >> In the first place, you replace the IPv4 --> IPv4 mapping with >> {IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333. >> > > I understand that, but I don't see how the proposed MIB text does that. > > Beyond that, the text I gave refers to a single mapping in the address map >> table. For different external IPv4 external addresses, you would be looking >> at different mapping instances. >> > > Can you please give an example with numbers showing how a DS-Lite address > mapping would be represented in the MIB? > > Thanks, > Simon > From nobody Thu Nov 27 11:38:57 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833FC1A0162 for ; Thu, 27 Nov 2014 11:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Upjp0I8HpizW for ; Thu, 27 Nov 2014 11:38:53 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE1F1A00A9 for ; Thu, 27 Nov 2014 11:38:53 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id q1so4730851lam.16 for ; Thu, 27 Nov 2014 11:38:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WHcvq4yCzASGioiCQSHYcBk2dCs+uh2qeBv0AWXhyhU=; b=T5h3f+/injrn4iSTenKZDBaUwXAtFE5yu2ClUNC4Y2Zd+vzwYXl22+JIaCmitHwtfu 6u19MQSUjsshBfXVqZxwmlyiSw5iKYiQtmEZ3UkJ7GiiD10i3JTJ2y0aPetddmuGozzm fqkgJF+cZiSh3YZzWDHEGb4hn0IBau9feiTf1bF0Ljpk16/aFeVxr8C+FxUPHqSazGMA GY9wsxI8p8LEB8wVVG9FfEnbfMuYT+4AfeIflEjOHvSy0XLHB40FEQ2+gkt8PG8toAOk uh4yYsA8nRr/CTBSUbq+EMhCpCS4N5kkVOutQ0/pvMDO8E2eFvmsCvPEesgQcN7Xvxbj VvUg== X-Gm-Message-State: ALoCoQm7hrY16EARIfeX7qy629upHX2FTJUIPDvd3Z0eNlFREaBnjAzSQ7L1U9LwyqKg2h5dsCv6 MIME-Version: 1.0 X-Received: by 10.112.168.97 with SMTP id zv1mr40979973lbb.6.1417117131994; Thu, 27 Nov 2014 11:38:51 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 27 Nov 2014 11:38:51 -0800 (PST) In-Reply-To: <54777A19.4010409@gmail.com> References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> <5477763A.4070305@gmail.com> <54777A19.4010409@gmail.com> Date: Thu, 27 Nov 2014 14:38:51 -0500 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=001a11c341c84207180508dc4b93 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/4Jk8V9BpqxKn9uS0dudJQ3lrJoA Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:38:55 -0000 --001a11c341c84207180508dc4b93 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 27, 2014 at 2:23 PM, Tom Taylor wrote: > Just to set the agenda: the definition of the address mapping table entry: > > natv2AddressMapEntry OBJECT-TYPE > SYNTAX Natv2AddressMapEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Mapping from internal to external address." > INDEX { natv2AddressMapInstanceIndex, > natv2AddressMapInternalRealm, > natv2AddressMapInternalAddressType, > natv2AddressMapInternalAddress } > ::= { natv2AddressMapTable 1 } > > Natv2AddressMapEntry ::= > SEQUENCE { > natv2AddressMapInstanceIndex Natv2InstanceIndex, > natv2AddressMapInternalRealm SnmpAdminString, > natv2AddressMapInternalAddressType InetAddressType, > natv2AddressMapInternalAddress InetAddress, > natv2AddressMapExternalRealm SnmpAdminString, > natv2AddressMapExternalAddressType InetAddressType, > natv2AddressMapExternalAddress InetAddress, > natv2AddressMapSubscriberIndex Natv2SubscriberIndexOrZero > } > > Now some example numbers: > > natv2AddressMapInstanceIndex = 1 > natv2AddressMapInternalRealm = "DS-Lite Group 5" > natv2AddressMapInternalAddressType = ipv6(2) > natv2AddressMapInternalAddress = 2001:db8:0:1::1 > natv2AddressMapExternalRealm = "global4" > natv2AddressMapExternalAddressType = ipv4(1) > natv2AddressMapExternalAddress = 192.0.2.1 > natv2AddressMapSubscriberIndex = 487231 > > This entry would be indexed by the combination of > > { 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 } > Ok, so far this is what I expected. I see a mapping from 2001:db8:0:1::1 to 192.0.2.1. However, in DS-Lite that mapping does not necessarily exist. For example, you could have these two mappings to different external addresses simultaneously: { 2001:db8:0:1::1, 192.0.0.1 } --> 192.0.2.1 { 2001:db8:0:1::1, 192.0.0.2 } --> 192.0.2.2 Note that this is the same subscriber, same IPv6 address, but different internal IPv4 addresses mapped to different external IPv4 addresses. As you can see there is no unique mapping IPv6 --> IPv4. Simon --001a11c341c84207180508dc4b93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Nov 27, 2014 at 2:23 PM, Tom Taylor <tom.taylor.stds@gma= il.com> wrote:
Just to set the agenda: the de= finition of the address mapping table entry:

natv2AddressMapEntry OBJECT-TYPE
=C2=A0 =C2=A0 SYNTAX Natv2AddressMapEntry
=C2=A0 =C2=A0 MAX-ACCESS not-accessible
=C2=A0 =C2=A0 STATUS current
=C2=A0 =C2=A0 DESCRIPTION
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Mapping from internal to external address= ."
=C2=A0 =C2=A0 INDEX { natv2AddressMapInstanceIndex,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalRealm,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalAddress= Type,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalAddress }<= br> =C2=A0 =C2=A0 ::=3D { natv2AddressMapTable 1 }

Natv2AddressMapEntry ::=3D
=C2=A0 =C2=A0 SEQUENCE {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInstanceIndex=C2=A0 =C2=A0 =C2= =A0 =C2=A0Natv2InstanceIndex,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalRealm=C2=A0 =C2=A0 =C2= =A0 =C2=A0SnmpAdminString,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalAddressType InetA= ddressType,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapInternalAddress=C2=A0 =C2=A0 =C2= =A0InetAddress,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapExternalRealm=C2=A0 =C2=A0 =C2= =A0 =C2=A0SnmpAdminString,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapExternalAddressType InetA= ddressType,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapExternalAddress=C2=A0 =C2=A0 =C2= =A0InetAddress,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 natv2AddressMapSubscriberIndex=C2=A0 =C2=A0 =C2= =A0Natv2SubscriberIndexOrZero
=C2=A0 =C2=A0 }

Now some example numbers:

natv2AddressMapInstanceIndex=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 1
natv2AddressMapInternalRealm=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D "DS-Lite Gr= oup 5"
natv2AddressMapInternalAddressType =3D ipv6(2)
natv2AddressMapInternalAddress=C2=A0 =C2=A0 =C2=A0=3D 2001:db8:0:1::1
natv2AddressMapExternalRealm=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D "global4&qu= ot;
natv2AddressMapExternalAddressType =3D ipv4(1)
natv2AddressMapExternalAddress=C2=A0 =C2=A0 =C2=A0=3D 192.0.2.1
natv2AddressMapSubscriberIndex=C2=A0 =C2=A0 =C2=A0=3D 487231

This entry would be indexed by the combination of

{ 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 }

Ok, so far this is what I expected. I see a mapping from 2001= :db8:0:1::1 to 192.0.2.1. However, in DS-Lite that mapping does not necessa= rily exist. For example, you could have these two mappings to different ext= ernal addresses simultaneously:

<= div class=3D"gmail_extra">{ 2001:db8:0:1::1, 192.0.0.1 } --> 192.0.2.1
{ 2001:db8:0:1::1, 192.0.0.2 } --> 192.0.= 2.2

No= te that this is the same subscriber, same IPv6 address, but different inter= nal IPv4 addresses mapped to different external IPv4 addresses. As you can = see there is no unique mapping IPv6 --> IPv4.

Simon
--001a11c341c84207180508dc4b93-- From nobody Thu Nov 27 11:45:18 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BEF1A017E; Thu, 27 Nov 2014 11:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC14IkSVIwYA; Thu, 27 Nov 2014 11:45:06 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E051A0181; Thu, 27 Nov 2014 11:45:04 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so5003366ieb.37 for ; Thu, 27 Nov 2014 11:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=faUedEa63CTzG6+pwhJ0V3DMbjfp4dbxxltw0aV5waw=; b=MuTkuWQV5Ci6cSgIGDFCe2uQw6ieTrgp4PqZ8xpHl6IgeMS6f0QpOlATC9ywfGcYdY CCw8xHsNqJ3ket087To2gtB64FzOlIFo8NzRc5DAOFyJNjuqpfuZPh1N6N3y/tAyShgx d/gNE+L1VZ9LUCoqWUuxZmMHathly9OFfcW3BzzpBHw6j6RQMLv5wDnBhGi8AJi+rKov VppAub3Aq/i8PqRFAkI6tMQDlT2/XOMXU0SC22w3hlH2gewlXeFY97Z9fp7x+BCFqMZH wxSvhVhgYNHTKRb7ObKjJFRIf8uB99sQzh/XWHM+eJxjTQGbLveOe9ABmK7i/mmuIheW wugg== X-Received: by 10.107.135.211 with SMTP id r80mr35257790ioi.67.1417117503650; Thu, 27 Nov 2014 11:45:03 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-26-221.tor.primus.ca. [173.206.26.221]) by mx.google.com with ESMTPSA id g139sm3940223iog.41.2014.11.27.11.45.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 11:45:03 -0800 (PST) Message-ID: <54777F39.1010901@gmail.com> Date: Thu, 27 Nov 2014 14:44:57 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Perreault References: <54735D29.7050308@gmail.com> <54777259.5060202@gmail.com> <5477763A.4070305@gmail.com> <54777A19.4010409@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/RG6IRaKkpK_dOIf_J6rjhi334Fw Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] NAT MIB: index for retrieval of address maps X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:45:12 -0000 Below. On 27/11/2014 2:38 PM, Simon Perreault wrote: > On Thu, Nov 27, 2014 at 2:23 PM, Tom Taylor > wrote: > >> Just to set the agenda: the definition of the address mapping table entry: >> >> natv2AddressMapEntry OBJECT-TYPE >> SYNTAX Natv2AddressMapEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "Mapping from internal to external address." >> INDEX { natv2AddressMapInstanceIndex, >> natv2AddressMapInternalRealm, >> natv2AddressMapInternalAddressType, >> natv2AddressMapInternalAddress } >> ::= { natv2AddressMapTable 1 } >> >> Natv2AddressMapEntry ::= >> SEQUENCE { >> natv2AddressMapInstanceIndex Natv2InstanceIndex, >> natv2AddressMapInternalRealm SnmpAdminString, >> natv2AddressMapInternalAddressType InetAddressType, >> natv2AddressMapInternalAddress InetAddress, >> natv2AddressMapExternalRealm SnmpAdminString, >> natv2AddressMapExternalAddressType InetAddressType, >> natv2AddressMapExternalAddress InetAddress, >> natv2AddressMapSubscriberIndex Natv2SubscriberIndexOrZero >> } >> >> Now some example numbers: >> >> natv2AddressMapInstanceIndex = 1 >> natv2AddressMapInternalRealm = "DS-Lite Group 5" >> natv2AddressMapInternalAddressType = ipv6(2) >> natv2AddressMapInternalAddress = 2001:db8:0:1::1 >> natv2AddressMapExternalRealm = "global4" >> natv2AddressMapExternalAddressType = ipv4(1) >> natv2AddressMapExternalAddress = 192.0.2.1 >> natv2AddressMapSubscriberIndex = 487231 >> >> This entry would be indexed by the combination of >> >> { 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 } >> > > Ok, so far this is what I expected. I see a mapping from 2001:db8:0:1::1 to > 192.0.2.1. However, in DS-Lite that mapping does not necessarily exist. For > example, you could have these two mappings to different external addresses > simultaneously: > > { 2001:db8:0:1::1, 192.0.0.1 } --> 192.0.2.1 > { 2001:db8:0:1::1, 192.0.0.2 } --> 192.0.2.2 > > Note that this is the same subscriber, same IPv6 address, but different > internal IPv4 addresses mapped to different external IPv4 addresses. As you > can see there is no unique mapping IPv6 --> IPv4. > > Simon > [PTT] If this is true for a single NAT instance, then I have to add the mapped address to the table. I see Section 5.7 is open on the subject, so I'll do so. Thanks, Tom From nobody Thu Nov 27 13:24:50 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8428E1A01F2 for ; Thu, 27 Nov 2014 13:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owtw1GkSvdaX for ; Thu, 27 Nov 2014 13:24:46 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C6E1A0137 for ; Thu, 27 Nov 2014 13:24:45 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hi2so9465637wib.11 for ; Thu, 27 Nov 2014 13:24:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uidmLbhWwng5NMoFcJDNmqvP9NU7GXFkK/iePlBeTBc=; b=KeAhvdEItKwJ1d8r4rZYG0fDoYmxyR2stjrD8dSrgZE/v7wwOPYGPEma5jD79vTT1k YMvRPsp3hq4PtCZ4/xrbyPpPgpNh2AB6THfAWxiCpMQQURN2E71VoDBmmIDGn+DxdApL 9R5QPOPUlhaiX1l/lzu11MKWBwX6+PIdQXoCbrDUg1aYQip3BSHWg2VzOQr+np4w0zD5 fBIAfsyDbuLorehh5fO8MMVWpgEaT7iukOAjlo2EQmYducRJUecGRYk5Z/dKLFyZq/e2 Z1wcK1HfqotH8HGMKJm7G7LP8OvweZMmnuFmFq72UcrVdVFg1DEJ0wy4dZnJhYgRCODp qC1g== X-Gm-Message-State: ALoCoQmOo5+THdaheuKK2xvqI3Gye7URqPirgLnhx6OxbBSY/HVW7jpuD8/poe3GYugAFAMVyfdU MIME-Version: 1.0 X-Received: by 10.180.210.226 with SMTP id mx2mr53802364wic.42.1417123484429; Thu, 27 Nov 2014 13:24:44 -0800 (PST) Received: by 10.194.64.37 with HTTP; Thu, 27 Nov 2014 13:24:44 -0800 (PST) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C90B442@AZ-FFEXMB04.global.avaya.com> References: <20141118150037.GB88064@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C90B442@AZ-FFEXMB04.global.avaya.com> Date: Thu, 27 Nov 2014 16:24:44 -0500 Message-ID: From: Warren Kumari To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=001a11c38980e487320508ddc574 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/CI3lgdnW34mOXEJ81Q4llZXFIFg Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] document status X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 21:24:48 -0000 --001a11c38980e487320508ddc574 Content-Type: text/plain; charset=UTF-8 Updating old thread... I finished the Shepherd write up and requested publication a few days ago. Sorry for the delay. W On Thursday, November 20, 2014, Romascanu, Dan (Dan) wrote: > Hi Juergen, > > The coman documents were not on the agenda of the OPSAWG meeting in > Honolulu. My understanding is that the first one is on Benoit's table for > review, soon to be followed by the second one (pending Warren's shepherd > write-up and submission). > > Regards, > > Dan > > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org ] On Behalf > Of Juergen > > Schoenwaelder > > Sent: Tuesday, November 18, 2014 5:01 PM > > To: opsawg@ietf.org > > Subject: [OPSAWG] document status > > > > Hi, > > > > since I could not follow the meeting in Honolulu, can I please get a > > clarification where we are with these WG documents? > > > > - https://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-03 > > > > This I-D was apparently sent to the IESG on 2014-10-30. So the token > > is with Benoit and I understand that Warren is the document shepherd. > > > > - https://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-03 > > > > This I-D is still a WG document. What are the next steps and who > > holds the token? Who is going to be the document shepherd? > > > > - https://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-02 > > > > This I-D is still a WG document. What are the next steps and who > > holds the token? Who is going to be the document shepherd? > > > > I just want to make sure it is clear who has to take the next action so > that we > > can wrap up things in a timely manner. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --001a11c38980e487320508ddc574 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Updating old thread...

I finished the Shepherd write up = and requested publication a few days ago.

Sorry fo= r the delay.

W

On Thursday, No= vember 20, 2014, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:
Hi= Juergen,

The coman documents were not on the agenda of the OPSAWG meeting in Honolul= u. My understanding is that the first one is on Benoit's table for revi= ew, soon to be followed by the second one (pending Warren's shepherd wr= ite-up and submission).

Regards,

Dan


> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, November 18, 2014 5:01 PM
> To: opsawg@ietf.org
> Subject: [OPSAWG] document status
>
> Hi,
>
> since I could not follow the meeting in Honolulu, can I please get a > clarification where we are with these WG documents?
>
> - https://tools.ietf.org/html/draft-ietf-opsa= wg-coman-probstate-reqs-03
>
>=C2=A0 =C2=A0This I-D was apparently sent to the IESG on 2014-10-30. So= the token
>=C2=A0 =C2=A0is with Benoit and I understand that Warren is the documen= t shepherd.
>
> - https://tools.ietf.org/html/draft-ietf-opsawg-co= man-use-cases-03
>
>=C2=A0 =C2=A0This I-D is still a WG document. What are the next steps a= nd who
>=C2=A0 =C2=A0holds the token? Who is going to be the document shepherd?=
>
> - https://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-02=
>
>=C2=A0 =C2=A0This I-D is still a WG document. What are the next steps a= nd who
>=C2=A0 =C2=A0holds the token? Who is going to be the document shepherd?=
>
> I just want to make sure it is clear who has to take the next action s= o that we
> can wrap up things in a timely manner.
>
> /js
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= , 28759 Bremen, Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.= jacobs-university.de/>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

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


--
I don't think the execution is releva= nt when it was obviously a bad idea in the first place.
This is like put= ting rabid weasels in your pants, and later expressing regret at having cho= sen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0= ---maf
--001a11c38980e487320508ddc574-- From nobody Fri Nov 28 18:51:49 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5071A03A9 for ; Fri, 28 Nov 2014 18:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZFXNANf6S5K for ; Fri, 28 Nov 2014 18:51:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4600D1A038A for ; Fri, 28 Nov 2014 18:51:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPI99566; Sat, 29 Nov 2014 02:51:44 +0000 (GMT) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 29 Nov 2014 02:51:43 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.67]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.03.0158.001; Sat, 29 Nov 2014 10:51:37 +0800 From: "Hedanping (Ana)" To: "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt Thread-Index: AQHQC32W7oq+6LVoDE6S5Cxlxqg8yZx25Uig Date: Sat, 29 Nov 2014 02:51:37 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/kGYWBO2VoXtyivzLywaSTuJDTN8 Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: [OPSAWG] FW: New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 02:51:48 -0000 RGVhciBhbGwsDQpXZSBmaW5kIGEgc2VjdXJpdHkgcHJvYmxlbSBpbiB0aGUgY3VycmVudCBTTk1Q IGtleSBsb2NhbGl6YXRpb24gYWxnb3JpdGhtLCBidXQgd2UgYXJlIG5vdCBzdXJlIHdoZXRoZXIg SUVURiBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gaW1wcm92ZSBpdC4gVGhlIGRyYWZ0IGlzIHN1Ym1p dHRlZCBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtZHUtb3BzYXdnLXNubXAta2V5LWxvY2FsaXphdGlvbi0wMC50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGFucGluZyBIZSBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1kdS1vcHNhd2ctc25tcC1rZXktbG9jYWxp emF0aW9uDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJQSBOZXcgQWxnb3JpdGhtIGZvciBTTk1QIEtl eSBMb2NhbGl6YXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTQtMTEtMjgNCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTQNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kdS1vcHNhd2ctc25tcC1rZXktbG9jYWxpemF0 aW9uLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWR1LW9wc2F3Zy1zbm1wLWtleS1sb2NhbGl6YXRpb24vDQpIdG1saXplZDogICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHUtb3BzYXdnLXNubXAta2V5LWxv Y2FsaXphdGlvbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBkaXNjdXNzZXMgYSBz ZWN1cml0eSBpc3N1ZSB3aXRoIHRoZSBhbGdvcml0aG0gZm9yDQogICBnZW5lcmF0aW5nIFNOTVAg bG9jYWxpemVkIGtleXMgYW5kIGludHJvZHVjZSBhIG5ldyBhbGdvcml0aG0gdG8NCiAgIGFkZHJl c3MgdGhpcyBwcm9ibGVtLg0KDQoNClJlZ2FyZHMsDQpBbmEgKERhbnBpbmcpDQo= From nobody Fri Nov 28 19:59:46 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51281A07BE for ; Fri, 28 Nov 2014 19:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx20IX9Lrk_T for ; Fri, 28 Nov 2014 19:59:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6138A1A07BC for ; Fri, 28 Nov 2014 19:59:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPJ03289; Sat, 29 Nov 2014 03:59:39 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 29 Nov 2014 03:59:39 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.22]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Sat, 29 Nov 2014 11:59:30 +0800 From: "Zhangdacheng (Dacheng)" To: "Hedanping (Ana)" , "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt Thread-Index: AQHQC32WC7Sbfn/ed0aGRZg6AZ5soJx25UiggAATbtA= Date: Sat, 29 Nov 2014 03:59:30 +0000 Message-ID: References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/3rVZrRe_aEOMxaXW4QQ1m6nep2k Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 03:59:44 -0000 Let me help clarify Danping's point.=20 We found there was a problem in the localization algorithm, but we are not = sure whether this issue is worthwhile for us to address, or the effort of a= ddressing this issue is out of scope of the SNMP specification. So, we rais= e this question here, and hope to get comments or suggestions. Cheers Dacheng > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Hedanping > (Ana) > Sent: Saturday, November 29, 2014 10:52 AM > To: opsawg@ietf.org > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > Subject: [OPSAWG] FW: New Version Notification for > draft-du-opsawg-snmp-key-localization-00.txt >=20 > Dear all, > We find a security problem in the current SNMP key localization algorithm= , but > we are not sure whether IETF is the right place to improve it. The draft = is > submitted and comments are appreciated. >=20 > A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt > has been successfully submitted by Danping He and posted to the IETF > repository. >=20 > Name: draft-du-opsawg-snmp-key-localization > Revision: 00 > Title: A New Algorithm for SNMP Key Localization > Document date: 2014-11-28 > Group: Individual Submission > Pages: 4 > URL: > http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localization= -00. > txt > Status: > https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localization/ > Htmlized: > http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 >=20 >=20 > Abstract: > This draft discusses a security issue with the algorithm for > generating SNMP localized keys and introduce a new algorithm to > address this problem. >=20 >=20 > Regards, > Ana (Danping) > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Sat Nov 29 05:25:27 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA5F1A1A13 for ; Sat, 29 Nov 2014 05:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm9XnP2dXNpA for ; Sat, 29 Nov 2014 05:25:22 -0800 (PST) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0911A1A0F for ; Sat, 29 Nov 2014 05:25:22 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1Xui1P-0007ki-Nr; Sat, 29 Nov 2014 14:25:13 +0100 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh-6.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Xui1P-0007yj-Iz; Sat, 29 Nov 2014 14:25:11 +0100 Message-ID: <5479C937.7070808@bwijnen.net> Date: Sat, 29 Nov 2014 14:25:11 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Zhangdacheng (Dacheng)" , "Hedanping (Ana)" , "opsawg@ietf.org" References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd453214e5ac84d50ebf250b169cdf92407 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/yVbQpLc6JeNrRf4ZxnoyKR_bnQI Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 13:25:25 -0000 From a quick check, it seems that your solution would solve the problem that we describe in RFC3414. However, RFC3414 also discusses the issue (page 73) in the Security considerations, so users of the spec should/could be well aware of the issue and easily avoid the problem. It should also be clear to anyone that a password of "bertbert" or any "abcdabcd" repeated sequence is a very weak password. The RFC3414 spec (i.e. its final Internet Standard version) is from 2002. I don;t think it is wise to change the algorithms at this point, specifically since we have documented how to avoid the issue. If we (IETF) were to change the algorith, I think we would also have to indicate how implementations of the old and new algorithms can coexist. We cannot expect all current deployments to migrate to a new version on some D-day. Full disclosure: as co-author of the RFC3414 I am probably biased. Bert On 29/11/14 04:59, Zhangdacheng (Dacheng) wrote: > Let me help clarify Danping's point. > > We found there was a problem in the localization algorithm, but we are not sure whether this issue is worthwhile for us to address, or the effort of addressing this issue is out of scope of the SNMP specification. So, we raise this question here, and hope to get comments or suggestions. > > Cheers > > Dacheng > >> -----Original Message----- >> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Hedanping >> (Ana) >> Sent: Saturday, November 29, 2014 10:52 AM >> To: opsawg@ietf.org >> Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org >> Subject: [OPSAWG] FW: New Version Notification for >> draft-du-opsawg-snmp-key-localization-00.txt >> >> Dear all, >> We find a security problem in the current SNMP key localization algorithm, but >> we are not sure whether IETF is the right place to improve it. The draft is >> submitted and comments are appreciated. >> >> A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt >> has been successfully submitted by Danping He and posted to the IETF >> repository. >> >> Name: draft-du-opsawg-snmp-key-localization >> Revision: 00 >> Title: A New Algorithm for SNMP Key Localization >> Document date: 2014-11-28 >> Group: Individual Submission >> Pages: 4 >> URL: >> http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localization-00. >> txt >> Status: >> https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localization/ >> Htmlized: >> http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 >> >> >> Abstract: >> This draft discusses a security issue with the algorithm for >> generating SNMP localized keys and introduce a new algorithm to >> address this problem. >> >> >> Regards, >> Ana (Danping) >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Sun Nov 30 16:08:41 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB8B1A1AD3 for ; Sun, 30 Nov 2014 16:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.909 X-Spam-Level: X-Spam-Status: No, score=-13.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMGYVjA2czR6 for ; Sun, 30 Nov 2014 16:08:35 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3141A1ACC for ; Sun, 30 Nov 2014 16:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43125; q=dns/txt; s=iport; t=1417392515; x=1418602115; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ctLt4Z52i0qcEUs8CFeaSbxltkrbO23i281uhGAh4pI=; b=S6qn73yenq0Owvy2Kesx5d0nigATpPWDclGTXQboyuFRaz1V4J8cWnlG +oMJMezeoHnb0knTQq4IT3YSithgkdmY/txzLYX4uukogPrS9UO9iivQk 4bF3V6lWayU7k30jXAHUVSeNjL3YD+Xx81s68u4yO+dDnHD2JIGs9nmk6 g=; X-Files: bgfaccjg.png : 19447 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFALewe1StJA2E/2dsb2JhbABbgkJEUU4KBIRhsguNaYIqhkwCgQsWAQEBAQF9hAIBAQEEBWYHBxACAQgRAwECBgEBARsEBwIVAQ4MFAkIAgQBDQQBBggNiCUN0VYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkGAKDAUGAQaEQgEEjn2BNVOCGIFOAWaGdYEuPIJ/kFqCN4FEbwGBRYEBAQEB X-IronPort-AV: E=Sophos;i="5.07,489,1413244800"; d="png'150?scan'150,208,217,150";a="101349085" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 01 Dec 2014 00:08:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB108XUp026750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 00:08:33 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.134]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 18:08:33 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: "Rajesh Pazhyannur (rpazhyan)" , "Benoit Claise (bclaise)" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" Thread-Topic: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship Thread-Index: AQHQBDIW9jh9SimcRUm69VAcj2zNTZxpDpEAgBCknoA= Date: Mon, 1 Dec 2014 00:08:33 +0000 Message-ID: References: <546CF473.70201@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.24.7.8] Content-Type: multipart/mixed; boundary="_004_D0A0DA92173EFrpazhyanciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ROEcvNUreLdWV2l50JLcV27mqB0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 00:08:38 -0000 --_004_D0A0DA92173EFrpazhyanciscocom_ Content-Type: multipart/alternative; boundary="_000_D0A0DA92173EFrpazhyanciscocom_" --_000_D0A0DA92173EFrpazhyanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I realized there was a typographical error in my response below. Please see corrections. Regards Rajesh From: Rajesh Pazhyannur > Date: Thursday, November 20, 2014 at 12:30 AM To: "Benoit Claise (bclaise)" >= , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >, "draft-ietf-opsawg-capwap-alt= -tunnel@tools.ietf.org" > Cc: "opsawg@ietf.org" > Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-ops= awg-capwap-alt-tunnel-information relationship Hi Benoit But now I wonder: why do we have two different drafts, as opposed to a sing= le one? This is a good question. [original] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel do= es not provide a complete solution and needs something like draft-ietf-ops= awg-capwap-alt-tunnel to complete the solution. [corrected statement] Yes, you are correct that draft-ietf-opsawg-capwap-al= t-tunnel does not provide a complete solution and needs something like dra= ft-xue-opsawg-capwap-alt-tunnel-information to complete the solution. The best answer I have is that we wanted the keep the following two areas = separate (and in different drafts) 1. Discover and negotiation of alternate tunneling capability. These are= independent of specific alternate tunnel method 2. [original] Definition of tunnel specific message elements. While draf= t-ietf-opsawg-capwap-alt-tunnel contains message elements for most of the t= unneling methods defined in draft-ietf-opsawg-capwap-alt-tunnel, I had ant= icipated separate drafts for each tunneling protocol. [corrected] 2 Definition of tunnel specific message elements. While draft-i= etf-opsawg-capwap-alt-tunnel contains message elements for most of the tunn= eling methods defined in draft-xue-opsawg-capwap-alt-tunnel-information I = had anticipated separate drafts for each tunneling protocol. Finishing 1. would allow 2. to be completed separately and independently in= potentially different drafts (and potentially different groups with releva= nt expertise). It is somewhat akin (though not identical) to separation bet= ween RFC 5415 and RFC 5416 where RFC 5415 is wireless technology independen= t and RFC 5416 is 802.11 specific. Hope the above makes sense. Regards Rajesh From: "Benoit Claise (bclaise)" > Date: Wednesday, November 19, 2014 at 11:50 AM To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >, "draft-ietf-opsawg-capwap-a= lt-tunnel@tools.ietf.org" > Cc: "opsawg@ietf.org" > Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-= capwap-alt-tunnel-information relationship Dear CAPWAP authors, After the draft-xue-opsawg-capwap-alt-tunnel-information presentation at th= e last IETF meeting, I've been wondering about the relationship between the= two drafts: - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types Note:this draft is currently in AD review, so close to be sent to the IES= G. - draft-xue-opsawg-capwap-alt-tunnel-information provides the encoding of t= he tunnel-specific fields. I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel doesn't = provide a complete solution without draft-xue-opsawg-capwap-alt-tunnel-info= rmation? I'm aware of the changes between version 3 and 4 (attached picture and http= ://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-capwap-alt-tunnel-04.txt= ) [cid:part1.06060400.02040901@cisco.com] But now I wonder: why do we have two different drafts, as opposed to a sing= le one? Regards, Benoit --_000_D0A0DA92173EFrpazhyanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello

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

Regards

Rajesh
From: Rajesh Pazhyannur <rpazhyan@cisco.com>
Date: Thursday, November 20, 2014 a= t 12:30 AM
To: "Benoit Claise (bclaise)&q= uot; <bclaise@cisco.com>, &q= uot;draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org= " <draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" <= draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org>
Cc: "opsawg@ietf.org" <= opsawg@ietf.org>
Subject: Re: [OPSAWG] draft-ietf-op= sawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information r= elationship

Hi Benoit

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

This is a good question.  

[origi= nal] Yes, you are correct that draft-ietf-opsawg-capwap-alt-tunnel does not provide a c= omplete solution and needs something like  draft-ietf-opsawg-capwap-alt-t= unnel to complete the solution. 
= [corrected statement] Yes, you a= re correct that draft-ietf-opsawg-cap= wap-alt-tunnel does not provide a complete solution and needs something like  
The best answer I have is  that we wanted the keep the following two a= reas separate (and in different drafts) 
  1. Discover and negotiation of alternate tunneling capability. These are  = ;independent of specific alternate tunnel method 
  2. [original] De= finition of tunnel specific message elements. While draft-ietf-opsawg-capwap-alt-tunnel contains&nbs= p;message elements for most of the tunneling methods defined in  draft-ietf-opsawg= -capwap-alt-tunnel, I had anticipated separate drafts for each t= unneling protocol.
[correcte= d] 2 Definition of tunnel specific message elements. While draft-ietf-opsawg-capwap-alt-tunnel conta= ins message elements for most of the tunneling methods defined in  draft-xue-opsawg-capwap-alt-tunnel-information I had anticipated separate drafts for each tunneling protocol.=

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

Hope = the above  makes sense. 

Regards

Rajes= h
From: "Benoit Claise (bclaise)= " <bclaise@cisco.com> Date: Wednesday, November 19, 2014 = at 11:50 AM
To: "draft-xue-opsawg-ca= pwap-alt-tunnel-information@tools.ietf.org" <draft-xue-op= sawg-capwap-alt-tunnel-information@tools.ietf.org>, "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" <draft-ietf-o= psawg-capwap-alt-tunnel@tools.ietf.org>
Cc: "opsawg@ietf.org" <= opsawg@ietf.org>
Subject: [OPSAWG] draft-ietf-opsawg= -capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relat= ionship

Dear CAPWAP authors,

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

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

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

Regards, Benoit


 --_000_D0A0DA92173EFrpazhyanciscocom_-- --_004_D0A0DA92173EFrpazhyanciscocom_ Content-Type: image/png; name="bgfaccjg.png" Content-Description: bgfaccjg.png Content-Disposition: attachment; filename="bgfaccjg.png"; size=19447; creation-date="Mon, 01 Dec 2014 00:08:33 GMT"; modification-date="Mon, 01 Dec 2014 00:08:33 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABxoAAACzCAIAAAAxAI48AAAgAElEQVR4nO2dO5LbuPe2uYlJXOVy 0lUKJnbkpCdWQmczqfNx0JkVO/i8AQcdW8l/CxP0Bn7airfQX6AbLucAByQogOrnqbfKZYkCDy4E gbdBcPgNAAAAAFDCKwAAAADAW2VoPRoHAAAAgJXRegQLAAAAANAM7FQAAAAAKKP1CBYAAAAAoBnY qQAAAABQRusRLAAAAABAM7BTAQAAAKCM1iNYAAAAAIBmYKcCAAAAQBmtR7AAAAAAAM3ATgUAAACA MlqPYAEAAAAAmoGdCgAAAABltB7BAgAAAAA0AzsVAAAAAMpoPYIFAAAAAGgGdioAAAAAlNF6BAsA AAAA0AzsVAAAAAAoo/UIFgAAAACgGXdop748PQzDMDw8vZT8YPu8aFBd87y1FNepXC8IJdZhSdry ti6et8lauMnJZ5WpmwE5rQ5bEhi4x8utOqstJMMt4M4oHky8OVqPYNfCYbcZhmHY7A4lPxj3iwbV NfvRVFz70euThF90WJLGvK2KUwvXamFZTq1g1nlX2ZLAwD1ebtVZbeN2O55hWGceyigeTMBNWJmd Gs7nNFPm5ekBO9WMZXr/vLU6rrcoyeet9TSrtS4s2IuhLkWXl/DjfNRv/ppcKXd6udW90FZaSKZb wB0yq7e7e1qPYHsgnM9ppsxht8FONWPxQA67Tb6MblaS9vq9a3+nqJn3ct6+WhJU5U4vt/1YszGu tHHvx3us2jytelnQWZ+dep3ZuHPcYMrDDKgyrYw7hc7CacUa7VQuTVgd9DdvuAzosVK0HsH2gDez cee4wZSHGVBlOivQzsJpxRrtVKoOVkddO3WdvNkyoMfqD+xUsNDZXLqzcFqBnQpwA+hv3nAZ0GOl aD2C7QHs1EZ0VqCdhdMK7FSAG/BmrUSHN1sG9Fj9cS926u/nrWCnOns0SjNB4x6U3g4DD08v0+eV 3p6R22c3N86WlOH5MhHpT2D6h/nnC7/XEgm2uVSKy7ybp5ecUJa5XTXV3R7Cs1ryJpWR9N32+Xeu KRmpfDalJTpnuX4tfjgh6u2zaDDkm6RSdcGhmZZUUki2qyRxTRaQ3w3WTNhy3Swr5wuyX7WQLgcc vwv+qwWtk+sBzBgSSl1uSo8bBG/ubywNIFdIJfWWbADeAcfvgv+WYLsFhAfGGbS1JCupu3J8ySSz n2lJtsHEW6X1CLYHVDv1dT8KdqqzR6M0E3S3cEzNFL2tHsf99OlVIiFnS0pvRwPxTP6eB2ow/mFx 4JY9OJXtFYLDrSXpl8Bmdwjn6NldNYMD1COt+4uGZSR9N+5fc03JSOWzKS3ROcv11+KHE6Ie9/J5 /YoRTlGlJZUUku0qqXNxV9xVMmy5bpblqKOzyZ3JtK7kcsDxu+C/WtA6uR7AjCWh8Bjhu3QhqbvL KEWeLoOKjTt7uV0OOH4X/LcEpcuNE0qVdt2QXl+ju2Twx9Ug4eS5MvdJ22ACbsnK7FSPxEQ8eoPE y9NDYtqWSOl568+ejpOqCfOpMIJjiKG9+bDd+oeF5xd23hO34os2nxTO5504Pae1mh6p48TAs36h NgG2VkEib2IZhQc/b4ft1tk1MN2S0oHUPlu63YqGRnHoQRW8PD0MD9vtQ7oFJnaHtMaQzlu2kEwh Ga7JaWjttvSHz9theHgICky+tAV/r04hnX/98PTsnEfbATdZvRN6gMkJmS63c497OU6puGLPN90A UoVkqDdbA7gG7pbW9A1Q02Ug1ojaQCwtKRNL9q4sxCt/ZGpJ9sHEG6P1CLY7EhPx6A0Sh90mMc3P pBTMreS5Yg5DQofdZjOO/mH7MZy9RdsTivsVRvvzpQLPe0hWlylljoiB541sZQJsrYLEoWIZhQfv x2EcnV0D0y0pHUjtsyXyJm50OMUrDKrgsNsMm3EUfPmosckVW6ElWQrJdJVUu7hDJjeSoLT34zBs NkGB2Ur73JlcPheuJVtXck5tt3fOo+2Am6zeCT3A9ITEY4JTWQrp9HFZkFrHlU/P0LgLLrf9OIx7 tySmb4CaLgNLadcLKUxcakdCvMJHhvtk4WACbsAd26nxkq3kFNZuS01bT2UISZkVvzw9eIsM5SVk kTGbPyr/xYX5dqr8TTbdiT+7Upppab1sZGeVT6YXOVuqGIT2NsFK8Rd9y0GWNbY6dmqmkIwhFXYT JUzqJKQfSX6P5YqoVkjnT22+Z6L8Zl/KBQkZLzehxxUTrxZkMrrz7zL1VlKOz9s6fx9QT5D6Tsym uSVlYsnelS12qqkoF+wl7oDWI9juyJigwsxZmwLVS0nHkJAyKz7sNt4iQ3kJWWTM5o/Kf1FwxBG9 JOVvsj6FfEANO1X5QlovG9lZ5fW/yNky3wnuWblvoawyCyx/e9XWsVMzhWRs/9Uu7phJ6WgLLEOf ylLaQmcSHFPSSRwtJYOlmHb4aziVtoRs/Ua+kCoHmf8y37hLynE/1vn7gHqC1HdyW6gRktCTRSFY 7FTTJbBgLwETuV87VVqINMWWCh92nDGNCp4cjU6ZWPF1/thmUpXO9m5gp059pncxO1XNc5B2fKop c+llzpZtt+HSy8IqMJVdYQFXWp2aLKSCkHLX5FSmtHfRuw6D1hIWjPlqhVTQ5vUDp/YAUxKyXm7C cR3Yqel6szaAbBSFFF2QR6R8Vvx7RfqubLBTbaVTOJh4Y7QewXZH2gQVVqJNsVNfowc+pz/pl0so seLr/LGWC//z0tneDezUqc/0LmanqkkEZ4wDmDKXXuZs6UgCz0FrXROi9j/XqnZe1WUW8CULqaDO q13c+VNlEb3rMCVraQsB+IcUXRjm7OgHTn6qf0pC2jH5htKBnZpu3EWXW7VCL4z5iNgYKoXkb0Eg 27Y5O9XWqgsHE3ADsFMzKUnH1pmhxo8MGgwOdS8/zwoqnUQvb6ea55/+LFmzuCrYqVbjt46duszZ MsXgGahTnvK12qmGJplNM2SmnVoSkpfOxL+X2NptEpv/LJzoTGYN45xCmm+nVnOgLAlZL7eKdmpJ A5hrp5oagDVwK3pSRXW+jBMp3JXzdqoxFOzUFK1HsN1xKzs1SrrOcp84IYPBEbg/Ht5OcUUz1uXt VPP8058lB/kqT04/1Gr81rFTlzlbJhLPQJ3ylK/ZTtUoWSIdMNNONVwlAtMvbuGUpQkpJRO7aabS ttip9kKab6dWc6AsCVmjqGin2jqufHoWO9V+ud3ETi2r84oheYkKa/FzdqotFOzU/sBOzaRU4XAd weCYuDo1mW5pHAI3WZ0qbXbA6tQ57fbioU5Ympo4t2l1amGaIUusTq0Zn/8TY7tNM2t1apxYzUJi dWru7xYlDWCR1anG1CbT2erUbBCsTr0JrUew3dHGTs0kVUT+qcLz57nVqfMC7GR1qrTZAatTp9up joc6YWlqIn3b6tSyNEOWWJ1aM74gIGF/y9uuTs38LP5pUYSsTk2d0t5x5b+cvDq19ESldLY6NRsE q1PvGOzUZEryj6ZZJcJvpPVi4lHOh7Lnkk7YPYHi1y5tp2rfOIsmxSgWs1O1L4ofmp4Vxryz5Yvh VONTlqaeziC3/+B1aQWJ38JONYZkuSYNFLTbCQGFhR10BwVpTSsk5bcTDsz3AEYMCRkvtzp2anED mGWnWhtANopCUknJ383bNkLHdlc22Km2JomdmqL1CLY7bmGnit9UW54oLaoTj/I2BZzupyb82qXt VO0bZ9FkweS7gp2qfZGflU+aSy9yNlO9DeN+0tLUUzzyY7ThNgJ2g+QWdqrxKql1cUvpTGokUkKR VWssbYNTaCokNbXiA/M9gBFLQrZ+o46dWu4azmrcJZfbbezUol56fki2dA12qu0+iZ3aH9ipyZRe hFd9T7OmnuN3D0fm5svT8T3TmRWr0nYD0WeSCxMG4J14aTtVMIufg/ekhCV7eqxVnqgHht6UvMVl K9RtJTt1kbNZauV5Ozw8TFmaqgT5vB0ettvImDM0ySO3sVNNIVmuSQv2dlua1MvTw/DwEOZN2pIg +qxWIam/lUkdmO8BjFgSMl1uVjs109+UNoB5dqqxAei5mUY6qahwp//pLovxrhwv/I/rxNiSsFNV Wo9gu+NGdmr41Oa0hX6WhA6743umMytWhQcb488kF0Z9/vQWdqpgFu+Dl5KExsrpsVbFOokeXC5+ yDguW8HaqWSnLnI2SyT7cdhsprRYJcj9OGzGMTiv9JC88uD8bexU01VS6+IOf3QIXwVuZx/vd7vZ hHkzlbbJKTR1JUpqMpnmmukBjJgSiq4uoW6tdmpYuvtxCDZXsXZciZNoX8VB2i+3G9mpttKuFdLx +srUtrTwX6gTw30SO7U/1minxpv+SXNZd0IrfJTYOtCZXR2nTc/ebnVTl/kN2+fgnOFs8zxJ886n PUWZKAGpJOJDnrU9+CLfIH2IrSTFQzPfPzy9nAMQjYKZeRMCih2B4BupJdmpcbaC0nZ+MMtTiYr6 HEPw3HSyqLW4k2kkc5+tklxIlmvSRkG7zRJe/epaPLUcaxaSciVFRqWMuDhxfnEbE0pebkKRCOWm 5FF6hD34OmoA+UIqqrdUA1CvpCn3LsstQDpQsukFJrQA8105rDP5oky1JONg4g3TegTbDYdo0z9p LjsMw2VWJHwkpBIecfrluA8OnTQZtCR0nqR5u+NpT1EmSkAqifiQvbYHX7RgNlNGtpKUDs18v9kd zlHG+fMPFWyibN6EgGJHIPhGakl2qpzNnDc33VkGhnfGze5wCTV2tFyihWBi1GUtqahKcldJtYs7 zPy4l4uoPKljSsoKYbUc4yIRyu1EppCU1hb9XUAmd9nOaJeWhIK49KBzhRSmFX1r6LgqN+705aac bKLDb0sqWdo1QzpeEem7WxzR9SfpO+GUwQTcmDXaqXcLa16gPpMf9IcuoFcAgE5pPYKFpWHNC9Rn 8oP+0AX0CgAADtipHYFxArWZ9PQ6dAS9AgB0SusRLCwNxgnUZtrWFNAP9AoAAA7YqR2BcQKVYWnq ylF2oAUAaE/rESwsDcYJVIalqStH3MkUAODtgp3aCZmN5wDsxNsU4qmuhmq7iwIALEvrESwsSWbj OQA78XaHeKqrodruogAA9wh2KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ2KkAAAAA UEbrESwAAAAAQDOwUwEAAACgjNYjWAAAAACAZmCnAgAAAEAZrUewAAAAAADNwE4FAAAAgDJaj2AB AAAAAJqBnQoAAAAAZbQewQIAAAAANAM79Q3z8vQwnHl4emkdDqye522llvTy9DAM2+f5Ca2I0+W4 titxpWFDVbiXTOF5myqs5+3g0mexth7Bwr1x2G0ubX6zO7QOB1bPYbcZhnHfUUIr4nQ5ru1KXGnY UBXuJVPYj6nC2o/esJRivYKdCr9/vzw99DlX03jerslr86bFp4J27YfejUN781ifnXrbpp89W9Vw ql0ltw0b1szqmkK7e8nL04N+6uSXHdF6BAt3y2G3WddcbV0Be9PiU9yu/dC7cWgv7fXZqbdtSdmz VQ2nWmK3DRvWzOqaQruAD7uN3sclv3zzYKcCU+DFUefGq5g0r655FICdagA7Faysrik0u5c8bxN/ MVpNMbYewcLdwhR4YdS58SomzWsr7RKwU2skdM8tBIpYXVNoFvB+TPzFaHXFeFuwU2FFc7cza7NT 1ac6sVMbg51qADsVrKyuKTS6l7w8PaQW8q+mGFuPYOFuWd3cbXUBa091Yqc2Bju1RkL33EKgiNU1 hUYBH3ab1OP7qyvG27ImO/X0zPTD09P2+tz05aHpcErkP02tTU2857C3z+Ikxkvp4eklnn/551LX nLgn2z47GXrRkpozo/J3XkvOGNNzt0RCNavEKQ3nwOCosKRT+cvX2+1w7FTvOfbYZq3VADIb751P 47RDoRiDRLKp5UMONz4IKyW8RsRfB21EPGf2mrTmrU6VGM92uhL1GpESiyIquUpuGHbFTnlulXAv KYJ7Se17ieqmKlHleiW1rzx/Ffy3Gq1HsM05PTO92e1OD09vdofrQ9OhKeU/Ta1NTbznsMe9PInJ HuSfS11z4qYz7p0MHbSk5syo/J3Xkp5deu6WCKlmlTil4RyoHBUhxO+dbrM77Md2zqVjp3rPscc2 a60GkNl473wapx0KVWYu7bBp28ISKiWdkNxG8rUvJWZvSTWqxHi205Wo14iUWBxRwVVyw7Ardspz q4R7SRHcS2rfS1Q3Nax/NabcdjGX3B2/Cv67ctZkp/7+fZ5DuBOE4zwjWOUX7eEobeoYzmiOaQdH hU/kHU+anpJIU6Xgs5enh+HhIVyZaArbQrT1ZHovSn0KbEiocpU8bLfO75QHIvOz2Sn1tiDXwjjN gq//CaOs0gAixIJ83g7brWPoKnP8gpVSyUPF3GmVolbxuY24KSWfmz3/SizIbN6qVollmefgdUKZ RWyXiBTX9XarU/NhV+uUK1UJ9xIT3EuWuJfkeqz0JScWpXj883bYPrvFk377VTmtR7BdcJxDuBOE 4zwjWOW3H4W5muQouZ8d0xZmt9mDhCAzJzvsNsNmE65MNIVtIdp6Mr0XZWIKnA+pcpVsxtH5nfJA ZH7tTvjDY2TNppLXwjjNgq//CaOs0gAixILcj8M4OoauMscvWSmV8hnE3GmVoiZ0biNuSsnnZs+/ Egsym7eqVWJZ5umbJ5lFbJeIpNzfdHVqPuxqnXKlKuFeYoJ7yRL3klyPZXClwzoRj9+Pw7h3iyf9 9qu1sEI79ToZcCdC7hfyVCT6VHjQOv6lMPswuBRhOuoCq2BKNM/LykSox62ew5JQ7SqJbQFx5U1+ Cjyh3pbjfPKXpwfHwvQLoF4DSEXgfzREFSCug6pgpxY2ypSdKjkRL08PWWOqvHQrV4nJl8z2STGl F3whNcKu1ilXqxLuJRa4lyxxL8n+lSRVVcp3Wu4q/UFOofUItgu8WYbruLhfyFOR6FPhQWt5sVD2 oHSYyk+kKdFML+uMbEXpTpd6DktItasktgXiqE1TYMHOabcy53zyw27jWJiJknxNfzo9Av+jIaoA cR1UBTu1sFGm7FTJiTjsNllDtbx0K1eJyZcs726UwrqtnZoJu1qnXK1KuJdY4F6yxL0k+1eSVFTK d2JM+zHr2K+Re7RTtZmI8HnwZJ1q7DiYpiaxA5BfPVYQdgZtrpdc8KcubcklVLNKhOMmToF/T6q3 5ThPyY//+v87HVKvAWgRCHaqxburYqeWGhBJO1X6JuenTnGYaleJxZeUVtmtwE7NhF2tU65XJdxL DHAvOR9U9V6SXU6fqKkiw3rxvyG2HsF2gWW+pc1EhM8P/pN1lidUTdOo2AFQntl1Pi4IO4M210su +Cs5tfd5zSoRjps4BX4Nn+VsPKU8T8mP//r/Ox1SrwFoEQh2qsXeqWKnlhoQSTtVWYs54Snk7Cqw qlVi8SWlVXYrsFMzYVfrlOtVCfcSA9xLzr+sei/JLqdPRKV+JWWv6d8Ql+NO7dRBIzeFyc+UxImQ cEo3IWVOE02Bp4UthqggZy8xBc4nVLNKqk6B47y0W5x6NgFP/unpf74zWK8B/P79W6y8hnZqsZFT 7NcIdoqh9Wft1JpVUs1ONdTt7+7s1GklGXbK9aqEe4kB7iVKoSz7rH/qkita0I+deguM8y213eam MPmZkniQcEr3GGVOE02Bp4UtpatRsnDIGFLNKqk6BY4LpeHE8mQCnvzT0/98Z7BeA3h9fRVbQUM7 tbjGZvs1mWvSFFflKqlmpxrq1nK2G4ZdrVOuVyXcSwxwL1EKZdln/VNRFf3FCju1C+YsXylOXyOY oggbt9VcUVRO8RSqdEWR/uOZVbLgFHjyr+pwdE4v+Qv+ez6k1hJa4UHXt7U6NX9NZgPOf1tODTvV WLfqpxNYcHVq8enrVQn3EgPcS2RmXltCPfuwOnVNzFm+Upy+8SBh47aaK4rKKZ5CzVrMVLNKFpwC a0ndiKNzeok7+O/5kFpLaA/CA/FvanVq/ppMfmr7tpwadqqxbi1ns7Lg6tTi09erEu4lBriXyMy8 l2Q3smV1apJ7tFN//37eGiZc4kTDZAL4v5TSMTx4KNgiprAtKFPu1PHqUqNsQhWrpNoU2FJv7sfD sPhuAM/bwX0zyvN28F8DdfywThBi9hvbqYnSL7NfJDvxd+ymZq/JbMCnlGq2i6V8yf7t1Iqd8iJX CfcSBe4lJfcSM7nlqalLTvmuollcQOsRbBdY5luvr/vRMEEyza0MB0mHGB48FGwRU9gWlCl36njl zIaQKlZJtSmw/L2+sEtfbFWN/Ti4b0bZj4P/GqjjhwvaX43t1ETpi4nP2jvVck2mPnXDqNkulvIl +7dTK3bKi1wl3EsUuJeU3EvM5JanpqJSvtP2TsVObY9tviXPVoLPnuP380YL317k90pHq8WChwwF dy486nkrvI3ZErYN6VlT/fnT9FKYTEIVq8Q8BQ6jet76VWmpN++3y/upp9Ncggz/f/20QgMI8yqf zGqnhhG8PD2UPup7+Vng+ejFnnzYf7uNnwAPr8H8NWnLW7Vr0nI2gy9prNvf+avkpmHHqUifWTrl WlXCvcQG9xLzvcSOXoCX79Or5oOcFP9VqhatR7BdYJtvybOV4LN9/H7eeOGb4SDp/7E7Fx61H4W3 MVvCtiE9Rqo/f5qau2VDqlgl5ilw+MPDbuOV+EF+H7jm26UeXq3F6TSXoMP/Xz+t0ADCvMons9qp udJOJ+n/LPB89GJPPuw/jvET4OXXpC1v1a5Jy9kMvqSxbi1nu2XYcSrSZ6ZOuVKVcC+xwb3EfC+x oxfg5fv0qvm4cZX9VWrdrMlOdXdf2z5fP3h4erlMPJ25w/mTC8F043l7fNzaPSSceRwnNf62b4rd 5CUSRxMG9PD0os/uUmFPKy8hd9HX6gn1hGpWSZSWd3g6KNnLydabl9LCq1OjWbnmJdZpAH4qp9bm pCaUbVwBWnKCcSMiLnQd9ISirEsHno0G76zisiz/e/GazOZNjmtGW9HPJpS/XCW5utVKYU4LrxB2 nEwck6VTNiWUgXtJGdxLar/XUPFTtS4w02uJNrWlPmbTegTbHHcbt3F//WCzO1wmns7c4fzJhWC6 sR+Pj1u7h8jPyuUO8iIbhnEvRBMGtNkd1MUyybCnlZcQuLornrz2STyiZpVEaXmHZ4ISXUE/h8lJ /pxythHNyjUvsU4D8FM5tTYnNaFs4wrQkotLe5CRltolvjcldDYavNqdek1m8ybHNaOt6GcTyl+u klzdFuXtdmHHycQh2/pbQ0IZuJeUwb2k9nsNFT9V6wJzPankd1vqY6WsyU69OxZfOQJwdxRsPQDw RuBesjomL3HvitYjWKjNna4cAViQao+wA9wN3EtWx+Ql7oCd2hKmwAClYKcChHAvWR/CNhbro/UI FmrDFBigFOxUgBDuJetD2MYCbGCntiK3eRoACGCnAnhwL1kp8/dgbU7rESxUJbd5GgAIYKcCeHAv WSnz92B9o2Cn3pDq+68BvCmCnRdXv7QLYBrcS6ALWo9gYS7V918DeFMEezSytAveKNxL4A2DnQoA AAAAZbQewQIAAAAANAM7FQAAAADKaD2CBQAAAABoBnYqAAAAAJTRegQLAAAAANAM7FQAAAAAKKP1 CBYAAAAAoBnYqQAAAABQRusRLAAAAABAM7BTAQAAAKCM1iNYAAAAAIBmYKcCAAAAQBmtR7AAAAAA AM24Qzv15elhGIbh4emlcQTD9ln7UvzG43k7uMi5MR0E94Zb7fmWlEnp9o3meZtoqpa8na+vGW0+ eYneiFNW51SAWxJKdpKlvRTzi9fYTUKf9HB9wS1oPYJdC4fdZhiGYbM7NI5gGPfal+I3HvvRu9/I uTEdBPfGuX3Nr/P92KDR7MdE2G6T1q6SCvlPXqI34pTVORXgloSSHWN/U5f5xdskbKhFD9cX3C/r tFNfnh7SDkH2gOV53k63U1+eHvITUdNBfaGVSed0G/b8wF6eHm5uttkMPkveZl7mHdTrrByYzPAm dur5zNipTWncwDu4vm5JB4OOBrQewXbEYbdJmxDZA5ZnP063Uw+7TX4iajqoL7Qy6Zxuw57fzA+7 zc0N1aSd6h5luQTmBN9Bvc7KgckMb+dLzipe7NQKNG7gHVxft6SDQcebATt1KWbMJU3Rd5DFYlY6 v+427BqBNVmgagA7NUcH4SfpPb77Bzv1lqzxjjyf1iPYjliznWrAFH0HWSxmpfPrbsOu0QaaLFA1 gJ2ao4Pwk/Qe3/2DnXpL1nhHXivYqUuBnRqz0vl1t2FXCex52+UyQOzUHB2En6T3+O4f7NRbssY7 8nxaj2A7Aju1iywWs9L5dbdhV2kD+7HLZYDYqTk6CD9J7/HdP9ipt2SNd+S1sjY7NdgtVNtC8TSz cY6W53V+cnPmfm5KD08vwlzSsCtkuBWimDnTQZa8XQ44fhf815qQswOkE1lcH3K9lRW5fC7pYWZr 3oLIgq+LwvaKSZtXh6eTpuCmhM5HpgrQS0g+1/mwGc6/GKn0edmWpze0U3NXpl9p1fY63T6LOcif TekE/dBzpe3ubpnrJ03dZL4HNJGpjJKwy0+oXCWpKlECkkIy7HRr7Lhym2YXdFz1GrepAST7W/Uo p1KiHYcvx0ZHPG2vX1yOCk+Zzr+tuRlHJdHpHp5eVm85tx7BdkGwW+iFYB5zmtk4R8vzOj+5OXM/ N6XN7iDMJQ27QoZbIYqZMx1kydvlgON3wX+1E4bncXaAdA6M60Out7Iid3fk87IXJWPNWxBZ8HVR 2F5A2rw6PJ00BTcldE4t9X1QRNrRs/xU7RITPi/b8vSGdmruykxfACV4KY17MQf5symdYBB6JlfK tSSWuambzPeAJiqGXX5C5SpJVYm9TzLtdW3ruHIJFXRc9Rq3rQHM7SajHYcvx0ZH7MbrF5ej9FuF 9LWtuRlHJVHONrvDG7Oca7E2O/WIZXXqMHd8a3YAACAASURBVIRzLsnic6cyk7frCxN/3g7DdqvO k7IzqPmrUwvy9rwdts/uBove09+2hF6eHh62W2crV8WhqzF3PJ8rKnDZm0jkTc6cUKj5sKMNKqWI 5LKMf5dNyBJYmBXhXLZz5FGj0PYRMLXvG9mpW7/A451GxRqZdNagmF+eHoaH7fYhX//K2YxXU6qQ TiXgOd5TusnCHtBEInuGsG1YrhJLlZxbUli92ZtUqmr1jks4XO//EhHUa9ymBmDrbw3dpPxHiLgi XUv6+G2w4bgt/8bmlu+Nwno6RoadeidYVqfGcy7J4nOnMpO36wsT34/DMI7qPCk7g5q/OrUgb/tx GPfudpb+09/RRpfSzpeH3WYzjs5WropDV2XuuB+HcfTT13YAzeRNLCUhnXzYYimJtnRUKZnSTXqd iTYQZkU4l+0cedQotN19Te37Rnbq6Bd43LpNF4D1dFGjHcdNvv6Vs1mvpsRxpxK4nGBqN1nYA5qY F7YNy1ViqZKCPilIWf0zX6rjsiaUbSHVGretAdTqJuU/QsQV6VrSx2+DLsl2nzQ2t3xvFGb3GBl2 ajl3bKfGM/5w4lTH8Ht5elDW/DSzU0vy9rxVbTZzQkJuxV9WslOVRVbi+ZILRZWlf8IC3GTY8vfx BD87BTclZAvMcAW4ycxZlqalq74rrSM7VV6v7P05YZJxIp1MNuoDf7/gbHXs1HixZXE3WdwDmkjb qZmwjeSvEluVKFeQWOeWqJMdl8Sku1m1xm1qALb+1hSTyU69/tc9hfuFNf/G5mayU8MjWJ16P5js 1HjGH87k6hh+h91GWfPTzE4tydt+TK8SsswbhdxqK5Oq2Kmy5xl/OCFvUoy5sOXv4wl+tihNCZm+ sVwBbvxzl6VpTr2YbEd2qrxe2fszzCTjRDqZbNQH/n7B2erYqfFiy+JusrgHNDErbCP5q8RWJQV9 UnBAYjlwSYYm3c2qNW5bA6jWTdrs1Ot/3ROrXyTiNDY3k50aHsHq1Encr52amW9p05ji6U15Qovb qUUhpaKxJiTEsqidqjyRHX2cOl/Kyoif5cw8U593DS11akrIHljwxK9+5OTFfVEYroWiuqk92anS z51UE05x2YlNCRWerdLq1KSbaOkBqnWl5p9nwy4gfZUYq0RbPJrxUyde2OYfZPuHOo3b1ABsebWd u46das6/sblZuzWHOb1XJ7QewXaExU7NzLcSE9my6U15QovbqUUhpaLRzhF+Lhy3qJ2quEvRx1Py JvwoE7b2tcGXm5CQ6Yvzt4nHWIMD59iSwaO42RV1Hdmp0s+dVK0XQBZTQoVnq7Q6NekmWrqSal2p +efZsAtIXyXGKinok4LvF70LpZOp1rhtuajWTVazU62lb2xu1m4tvRsAWHjLdqrGAnNJ4zd69EUH FeUtY6eaErqxnWo2AaZYxcV2qloR6pR+VkL2wKJEtJY91069GKcna+ryjK1+vl7s1MylG3htHkUt 2WqnlpztRnZqtgdYt53qE14KxioxFoGQ2sQLW6iXKXZqncZtyr2tv7W1mWp2qi3/Ne1UH22XhhXR egTbEXXsVI0l5pK2b/Toiw4qylvGclRTCh6RvKmdai3w1PnU70rtVJvZach6uWtaYnwkPNO5durV TUo8V+ufrxc7NdOSrBdAFqudWnK2G9mp2a5k3Xaqj/z0f7ZKCow5UzMyPaU/t4VUa9ym3FfrJuW0 Jtqp2cYtBzXdTvWRNjsAA2/ZTq0zj+nTTrXnbZLlmI+F1anNV6ea05n5sP8l4aOBerJR9cWpPdmp E1enFjNrdapCy9WpljjWaKeGSRnTtaxOFa6yaRd2+BS9/oOJfwcq5c5Wp6Yj1H86rTzX/rR/6xFs Ryy4OrWYPu1Ue94mreDMH8fq1OarU82Hz33Y/xz50UA926jq4tSe7NSJq1OLmbU6VaHl6lRL+mu0 U8OkjOla+iRp94NJRWdPaOLfgUq5t9Wp6XyoYU4rT572n8KbtVNF+21qMPmN41wWt1OL8pabuU90 bBa1U4VUxEhzeTM+Qp0LW/4+NcH3jso9Nq3XdKFln7JT59XL83bYPp89peft8PD0rLupPdmpub1T c49rl5xMSCi02IrOdgs71dQDFPeAJm5gp1quElOVKH+QCNzUTFPLBZb60RQ7tV7jNjUAW39r6SYr 2anm/FeyU+Xv1T5/GIY17AbQegTbERXsVHm/t4nBGDaOc1jcTi3KWzqa7O5/WiyL2qkFe6cmXQnj I9S5sOXvUxN876jcY9N6TevfiCml7NR59XLYbTa7/SkrxyzpbmpPdmpu71TjBWA6mdho/bZcdLZb 2KmmrqS4BzRxAzvVcpWYqsTQJ4kRTrFTCxLKd1zV/lhgaADVusladqr1PlnJTpW/V0slXiULF9Zp p4YG0MvTQ+mrf3/LzzhPeu45XIj38vSQeq/18nZqSd4y0ZgSstqp4Q9lPyvNy9PDw3YbP5IrJWPI m/+9vMosH3b0OymiyHN5cV4/XZKQe7TexsKk1ZQqPHH68vTw8HAppOft4PxPProTO9XwPnapeCYV WVi3z9vhYbuN92m0nu0mdqqtByjsAU3cxk41XCWGKhFaUljdUhGpflmyaoV2FGXjeo5sx1WlcZsa gK2/tXSTsXk6JAYAqp1qzL+1uWVGJXGUqQXy6zBTsVNdAgPosNuUvvr3VX7GedJzz+FjzYfdJvVe 6+Xt1JK8GbxCyV+c9LB/GIHsZ2XYj9FbtLXVYZm8xY+jy+nkw45+Jz3pHnkuB+f10yUJuV/qdmqY tJpSjSdO9+Ow2ZzTP+w2zv9KwvZTvMXD/vn3sVsuAOvpwmeIN+MY5KDgbDexU21dSWEPaOI2dqrh KjFUiaVPEv4/7WF/e0KmjqtK47Y1gGrdZGyeDokBgGqnGu+T1uaWGZXEUaYWyGOmplipnXpdvjFE U0l3W7nT58JHwsHapHRaOKeUTzMi/3vlhNpB0Zw0e5Ahb0o6ygIiPaG4bN2Uxcly8mSGkj6vgVQz b89bcGTKd8ocFRRS0uack5CpJR0dgODQREiV1wwLNlXciIRCMOXNkpAt3lO63lnFkojimupzRM3I jcN6NqUAJIstcZRwlc7qJnM9oIl8AygKO4f5KjFUSdSSxL9c+SeKat/YcfmHPTy96GWd77hqNW5T AzD2t/luMjybU5RRe3DjiC+4ZP4Lm5s+Kvl9vnMZ7gByB9oprUewfXFevnEkmMaGnwsfCQcLX88I 55TyaUbkf6+cUDsomu9nDzLkTUknMbmTD4rL1j1cev4+fbIsp8mtF5TgANnyFhypBpQPOyht3Uqf m1BUrUqtHB+7t4VUec2wYhxkwzZdJab85zifKWpJ2vPI00/lEjUjNw7r2ZQCECyoVEkKV+msbjLX A5qoHHYO81ViqJJcnxSlstkdoiIydlz5hNzIUiEZ8mbF1gBqdZPh2ZwLKWoPbhzCBZdq3IXNTR+V vJ49WMMdQPT5wWW1diq8UWauSIQAbdtHADCy9g0woSuet8M6lqb+xk4FeH1ls7nKJB7KBwAL9ElQ kf043dV+G2CnwrrATq3JpM0tAMAFOxXqMWUPnGa0HsEC9ADWRUUmbW4BAC70SVCPSXvgvC2wU2Fd YKdWhKWpAPPBToVqrOtPXK1HsAA9gHVRD5amAsyHPgmqwZ+48mCnwnqw7U8KAHAbrLsvA9wjrUew AI2x7nQKAHAL6JMAbg12KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ2KkAAAAAUEbr ESwAAAAAQDOG/17/QwghhNAS+r//vd5SzfOL3o7MQ83/hxBCCCGE0FR1CnYqQgghtJSwU9G9yjzU bD4ERwghhBBC61WnYKcihBBCSwk7Fd2rzEPN5kNwhBBCCCG0XnUKdipCCCG0lLBT0b3KPNRsPgRH CCGEEELrVadgp3ap/adheP/PYWYKZ8Zv8jGHf95fjtn887N5rtvp5+5aEqkSux/9/GczDMPwfvez dSQt9W281vmnffrgb5/efHH1orV1XNip6F5lHmo2H4KjudqPw7D56zAzhcsgay8fc9j9ce3dd/82 z3U7/bvb+MNSpcTuR4e/NsMwDH/sDq0jaam/navkz3364P2fb764ehEdF0I3Uae8cTv15z+bea5l kQ7/vDdO/ufbqW5SWXPQHthdav9pFaZMdf3cva/nD377NHz61jpHk/VtxE7V1W3/0G1gvhyvc//R mR6/+7L//GHz+Rd2KlqrzEPN5kPw9ejw12aea1mkw+4P4+R/vp3qJpU1B+2B3aX249s0Zf7dber5 g7e9lGrr7xE7VVe3/UO3gSF0F+oU7NQu7dSKwk7NyWCl3aewUy96s23ApG77h24D83UyOn/t3g2e efr1cRgG7FS0YpmHms2H4OtRr3ZqRWGn5mSw0u5T2KkXvdk2YFK3/UO3gSF0F+oU7FTs1NW4Egvp zVpp2KkXvdk2YFK3/UO3gfk6upw/vmzefTn41ueB1alo1TIPNZsPwdcj7NR2gXWjN2ulYade9Gbb gEnd9g/dBobQXahTVmWnnrfM+7T39wZVfBx3Y8Toae5v7u8dYnf1tMukks752/Gbl2bgYO6Vs2mp yZGcVLbR5ww71TnRtYTFD63yyiHI4Kn03u9+unsjin6fXwKTDXGlDcTFlQrba2lHSy7477RGnsi+ 17BTT6D7TXf8Fvinp/86uZsfsIPTPE6nuBbdpQadeCwNwHa5mUvSLVIt725jkxIpaLfRjsbOb02l rWRfqLjLt8daCP6rXgVhJNaOK2qWqssZnk4oeb/iUm0yY6cGRXTbP5450u1USb9275ywlZ94mwYM j3vsVNRE5qFm8yH4Ujpvmffn3t8bdBj/lo7/2+smg1n3/k+lv40tIS+d8FynPSiHce+lGTiYe38g oUZ1Tk2J5KiyjT7n2KnXsJ1gxA+N8soh+Pmp9P7YHdy9EWW/zy/PqUaY0gbi4kqF7bWQYyTBf6c1 8kT2zQ3AbU7DMO4D//T0Xyd3k0rScCmdTnH95JIFJx5LA7BdbuaSdGtQy7tb2lIiJSGFOxo7WTYV tXIuoeIuVX8s8+C/avWFkVg7Lq/ZaweIpxNK3q+4VJvM2Kle+5fPhRDS1SmrslNf//vvaHyMnzxf 4PDPe8mb86yB/SfJSshOsMV0op/sPw3jp0/Xz3/+s5EskoK1VAUz/5+796mtP2euThX3FZ20KOzb GJgs3z5FXsnP3fv346f315oSjhHTmbPKMr0y0RK2k44bzLdPpVZv1LqisysRxlV8+Oe9H+fRFgzs 1GFw01farUnZ1alCk46Xx1oagOlyKyxJy+rUxGJeS9jBdfpz937YvH8/7W8S4yc/fa3ivn0aPn1z iyK4nMVSEttSphHa+lvxdEIrdX+YbJOJwMKbwtGJbmmnHn3SjKP6fRziDQE+7H5EfuvH79dPfnzZ DMP4FTsV3VzmoWbzIfii+nsc/hxHz9Y87P6QvDnPGtiPkuuaXVJ3+GvjOyOH3R/xDH8/DuP45zWG w18bySIpWEtVsNbv390mtfXnzNWph90fQrnt/1Qs7HTF+XHu/4xK8t/d5o9xdM4oH+NXZVRH5YEl TBZL2E46bsPb/1nqOEd75kZnNzeAqKEebcHATvWdL6XdmmS5lMID4uWxlgZgutwKS9JitKUW8xpC Cqrp391m2Gyki8vQSMbRLxat4g5/bTZ/7Z2WEFzOYinFl1K+47L1t+LphFYaXt1qsacCC1tOfC6E UFqdsko7VbJFvn1yPpTNEWHunXEtZQMlTif2WMV5/jJ2aubguQ/7//xnIxiaxaabHEYYeWSmRD+U Q5217ixlpdnCvqQzz6+RkzU8kh9bmaakfu7eh7mb/vR0NTs10wBeLZdbcUnOt1MntFvhVxYp76n7 NsYffvs0pBeKCmcXsplrFbb+Vj6d91vlRGrtZOxU00VxA7mG6dfH68oE47P/wbLWr4+el3r1Yc9r VG+fQfRmZR5qNh+CLyrFFtn/6XwomyPC3DvnAcleZGQmxm+OEuf5y9ipmYNnP+z/9ygZQ6X2pRxG GHlkpsQ/lJ3cOevOUr+1hX1JZ94LxORkDY/kxz80JSXU4/Snp6vZqbkGYLncikuygp2aDkkqWCGz Finvqft7jD88Ls/UTiFfSkI2c63C1t8arlzlRGrtZOzUsEBYnYpQkTpllXaq8gT0ZaqsOTvxdDo9 wda+jT6PHZ/7sVOjFW2CT2GqNdEQkR8/1+PXLK0524AmrDRj2Nl0TNJqwbQ20K8RW0ubYJwVxBDK vDo12QDkT4Kwy0uywurUXLuV0p+04ay4YPz1v//2n6LwkulrPUNcSvln6g39raEjUkvYHmrwrfsk WLYbXEzaWtSvj4O7qvT/fu3eBQtRhc/3H92feI//nz5vlU30BmUeajYfgi+q2N07f36ZPGtrJ62u k3sufR2i80ns+NyRnRotUC1fdKmXpPz4eSJ+LTuWbBbGZg87m45JWi3km03UAGwtbYJxVhCD4QB5 dWq6AYifGLzLdO5qrE5NhfTvbiOlP2WV9//bj/Iy2/0YhTepZ4hLKdMqbP2t4QpVS9geahiYZf8B hJCsTlmlnao/av3ff6+JOfYEO1XeoiV4QPXWdqqwW+WSdqq/QHXK0lQ9OxPsVLVKptolupVmDTuX jk3qJqSDsPIxe4ChNO7ZTjWWZEndzbFTlfSn2qli5Qqfp9JXs1Nqp9r6W8sfPNRamGanRvnN7pux kBJP9399dNao+rumBr3b16ttqnFa2Xr7DKI3K/NQs/kQfFHlLU51jj3FTtUIn2y9pZ3q7y147JAW tFN9C3vK0lQ9O1PsVLVTnmiX6FaaNexcOjYJ1Xq9Kf2dOdKP02Yu37OdaizJkrqbY6cq6U+1U61/ UUhVipqdUjvV1t9a3num1sJEOzVKZEJpI/SG1SmrtFNbr06NdEs7VXjUd+HVqa/OgrhJS1P/W351 6hz1vjo1OnXkCbI61bY6dVIbSFe6MWxWpzZYnVpSg4sqYad6D/Jrq1OVVaiabp9B9GZlHmo2H4Iv qh5Wp4a6pZ0qPOq78OrUV3eB6pSlqYmSrLY6dYZ6X50aV2i2AbA6tTAXrE5NtYG1rk41p4MQktQp q7RTb7Z3quRQyIfdzE6Vsra8nXpeoDppaWoiDGHv1Jyb5lV0FVXcO3WWnSpvf2k5tXXv1MANv1s7 1VSSxXU3x05tt3dqIv0u9k713OF6e6eKP9Fq8NvpDb9LrV1N2KDBRqhfH4W9U2MHVtg7FTsVtZB5 qNl8CL6obrp36mH3h2X6fUM7Vcra8nbq2cWetDQ1EYawd2rOTTv8tam8xKzi3qkzd2aUtr+0nMX8 dwJ/34a7tVNtJVlad3Ps1HZ7pybKoYu9Uz13uN7eqXJlKZ3h6SkEdgNAyFenrNJO/TQGr42OX6Ee faIsqwzeZP1z997wquvotd1GOzX84c9/NtocPvWYeWjTDMPCD/uf05n2InKnJH0vQ3jJldVNi8KQ 30huDixhpVnCtqRjk/Iieye/YTynB//zb1E/7pMQvEW9np0avoH92xhGJbwIawjd+Vp2qqUkS+tu lp0aX7mTL6j9p2H8FORO+TtHzuOOFroKbycTCjPuuEz9bWwfx29viwNI/QknaacGrV1fWf/tvHfG Ui+qch7S9x3V7+MQLkfdfxyiN019H/0fHj5/iF5j9Wv3jof90c1lHmo2H4Ivqr/H4c8xeGwzXjIZ fSK/oT58k/W/u01gVUivTY9eNm20U8OXTR/+2mhz+NRj5t65Ts81L26n/r/D7o9h80fBjq5CUfsG x+GvTeiSmNy0w+6PKL/y2+3tLUq30ixhW9KxSXmRve+BmhpAZLr9u9sM0VvU69mppkspfBHWILzl rIqdainJ0rqbZafGFbcfh81G7JQy2o/DOMavrZdiM7xqLx2kXJhxx2Xqb2P7OH57WxyA9jiCUu+J 1qWtrL9ssTrnPXII3aE6ZZ126j7YHlGcBn/zN5jUbAV/g1TJkov263RP5/789Pk3Zx+l0KPxd3UM vv2mbcAUrrwL8nWO4RK8vnekc8Zv8Qacp2zI5sXPfzZzX+cSZNDPvhvPsbKEstUyOGXNrLADqZxU Mmy1tKc+Vhzt2CssqQ6+PRWd9Ky3lk5c2sl2a5J3Oin74bV2vrKOAVgaQNHllilJfR9ep69QGonT IAvarXfGU8VN3jvVy13sSidj1q8C7QJPdlxCY9PyZXg9VBB8plUrR34bh0/7oAGoRX271anB7qjy o/2Hzx/8jEmHfX0Mcn/1W5fIAkKizEPN5kPwRXUyPrztEdOT5NNVq9gWx5dfX45SNiX0CZ0FPwx3 x9XQo/F3dQy+VbdqDVfeBfk6x3AJXt870jljUD5XEm8/n7mAK8ign303nmNlCWWrBj9hzayyDav4 FL8etlra2Z0iFfkNchDKPN8AxFIK/a+gtJPtdkLk8qpe74Cj5zVc95EIQoobQNHllinJ89ljnL5C 3av30iALQvLOuNn9O2vvVC93ggctIVRrcKR2HSU7LumSVPIVXCzS6YJ6ia4jU8d19L79K0V1S1md ipCoTlmtndo6jLeneAkwQmiOqr6KCvWq9MP71dU8v+jtyDzUbD4EX1Q11gCiCVJXZSKEJqnqq6gQ QqiqOgU7FZmkPAWMEJos7NQ3IexUdK8yDzWbD8EXFXZqG2kvwEEITRR2KkKoX3UKdiqyiKWpCNVV uNusVdipaxN2KrpXmYeazYfgiwo7tYVYmopQXUVbMBuFnYoQuok6ZVV2arDv3mJb3aGT4o0jKXOE Jsu/oMq91GAzUP7CsQ5hp6J7lXmo2XwIvpSCffdYLHnjAk9siYgQysrfqLTcSw12g+XVSQihBdUp q7JTEUIIoVUJOxXdq8xDzeZDcIQQQgghtF51CnYqQgghtJSwU9G9yjzUbD4ERwghhBBC61WnYKci hBBCSwk7Fd2rzEPN5kNwhBBCCCG0XnXKcOOZHkIIIYQQ6lnYqQghhBBCqA91CnYqQgghhBC6CjsV IYQQQgj1oU7BTkUIIYQQQldhpyKEEEIIoT7UKdipCCGEEELoKuxUhBBCCCHUhzpl1Xbq/uNw4t2X Q+tgELpLXa+yYRi/to+nS30fr4X0uK+U4Obzr9qxDcPwYfejeXFV0tfHm2Tn1+5d5RuNe00N1Sr6 7cipke7asxtb133mqRF+/K4eg52KEEIIIYT6UKes3U5V5iqBgzBxMnz4/EFIJDH9QOh+pV9u+W8L 9OPLZsV/Hfk+9mWn/tq969fQkWVvADeyU8sDS+rw+QM3kUr6tXvXl526/7gqc/zrI3YqQgghhBDq X51yp3bqVYfPH+ZNb0J/5PD5Q6UFaAitSdipBtWyUytpjYXZbcx1AuvOAVyzeivMzi7/rLBTEUII IYTQGtQp2Kk5SROk9CQEoXsUdqpBnfkpayzMbmPGTu1OvRVmZ5d/VtipCCGEEEJoDeoU7NScxAlS 6SzO2U/tOHv58WUT7K329THYCe6y1UAcv78Lwaz5pLeLn2cWnGP++D3YPEEu81P8Rx73sfXgZPl0 jPJzL33xczepd18OXqilJeBvdffxe9hg0mGfS2bz+Zd/pFspTul5EQqfh/tL+Dk6f/u4Dypuorlf ts2fcrmFiRhTyzUhB6chnXJ9/eRydqfAzxUxftXblVJxYl9RcrnN9VPcc0nBWMOWNyqRgtd7AL/9 H79S/jt+Pn/udhdFPYCtAURNLlUdfiGYrtzUzWKmnRpmXz+jVw5xBoM2L10CU6OKgjHcucT2JnV0 m89fnIZxSflcL8plm3wWJH0j9vf8mfUXUC+pXJVdmfYXJq8w3305uKanW0rBqaUMhld34J8e/6u1 f+xUhBBCCCHUhzoFOzUn2R+ZsBYv2lXt+xhOgIXJYRz//mPgL0zeZjH64ddHweX8+Dh608Jfu3fh 6Q6fP3ghHadnaevhx5dNkH3VrfD3fwyC/Po4DB8209Yo/fiykUyBjKUS2RaHzx82Hx83kYXqF5oc YXojxbBgTyk/jh+9ybN02AQJNeuql9WpwgFC8e4/DuPHx2uxpCru0pyCWjulU3K5VVuelui4LGHb CtPQAzjp7J19Ttx2u/84BNbeMZjMPpJSjZgaQLLena98g2lqA5gU2LSYz4UZtTflzxgfdl+dHuzH l01p24s2n43OLtZjfOcKFfdIx6710jAu3WzQAZ4uWzcjWjtJF6bct0+6NsVSkjvtCpd/mPjRLfVP J3S2wjpT8eqWEndi9s6OnYoQQgghhPpQp2Cn5iRPkKYl68xLxRmpwU6Vp/RTnnmUSy9IX3nZy/6j 96HgCRqsh6gMtbmoW1bK3gtTVmbJhZat2fgAZaL+a/fOm6aKbTX36pI4SMXO+/pY4RUoyVpbnZ0a Gzr5igtcieLL7UZ2aibsORUq/uT4BxLF93fT8cLObYoi57GGnaqUnmEj7ETMN7BT5bOLPzk613Ma W0EHmLtz5RNXG4ZfqqKf+/p/30f1L21yMHLbnrJLT9EAoI6dGqYchW2xU00l8PVR/HPdKQvYqQgh hBBCqA91ytu1U7UHS4WHgqvZqa+nydIXZUaat1O18/qf+w85ulynUtrEz49BmG6dPpecqbKHHKO8 OKd2HVI3Btk0FKbuSv79R8InmSOyKyfN0g+fP0g2k+uHZr0J0U4Vf+I6DpYGIGk5O1V50nmIreGK q1P9eMSKSzsXtsstqB3ZT/GeuvWQj8+sTs0ZLobCtPUAhQ2jDzvV6rIVlGRZYBNiFsJLFtTsbUO1 7CifJ+9c+Wza7VSx2Qd/wMsVQuIvc+ULeAuurDp/TfH7CnmDjpydaotEXtOKnYoQQgghhPpSp7xd O9Wqag/7OwlqCxJNdqrmypStu0k9We/bqWKyGaNEfGxc2GQz3sfg+In2NKhSm5OcBetKpXzYJtPt Ygofffzr1pN+6xJsx9hOreQUiM3pwkCrPAAAC6ZJREFUjlanVrFTCy+3Wz3sP99ONfYAhkox26n5 S8nUANKhJmuhbzu1aLFtDTtVbdxaD6Mvpc91XHY7VVvFr+54IDcAjbJCUy/DJe3UOC/xDiQZO9XY VrFTEUIIIYTQGtQp2KmGycz8V1G5qX3Y/dDW4ExfnVopX1EM5tWpubwIU3HVyziajGer0Ssr2+pU k0wTTlPYltWp5wI/7gN73g02KF5h14Jpq1NNEp6rva+H/ZdbnZpsMCuxU2+9OtXWA1gaQDrU1Oed 26l9rE6VlbxzGTquPlanlqvF6tRsdlidihBCCCGE3pQ6BTu1dCbz+n//e/3xZSPvcJdYtva/wAiT 5o2WV1EVu2ZlpTdl71SD4yxNSoWqubzx5uP38xuoAvdw8b1TvRWjtrAte6c6r4553J8d2KANSDWy 3N6pSsPGTg1cibLLbUV2auHeqTPtVGMPYGkAyXpPlp6wd2pXdmrh3qnz7FTVo4yVuXNZOq4b753q /ylrjm67d6rNpZ2+d2rw1zjsVIQQQgghtAZ1CnZqTtEESXuB8vVpR+1b6W05/mRGfLRfmPBHp9Df NZzOmh9SnLWvj8PHx+BhQ+lFz2GuwwWbYcon6zmqmu/j8GHz7nS6w+cPw7sPQkjuhPPHl83wYTPN WYh8WPf10/awz+8Hd5M6rz/162jz7lwsp7Cjd0+HhRY/nfp9HB7H+O3PxUZPGOHpwfapdmr4Lu+v j4NtC12pWbo//LV7F0QVeCjHSlnITi293NZkp5p6AEM6JjvV2gNYGoDWEoKv4l2ws3+sam2nCr2r 0JNY0rFJeJA8bPCGO5el4yp42P9jcMUlNpjONADhz3UT/vAW9a7a4wh17NSoE86/nOq4gUz8Nsig cr8+hlccdipCCCGEEFqDOuVO7VRl67TCybCyc6I2X9JXp7qvvbq6aWJU/vaCH7+fY8jssDnVMg4K Slr4eV4oqp/r+3h6Nt+LPFUIwzB+/Z+YNW91kjS3jJI6PkE/2VnwSyBzLjnss1PgJSW/Vfk6mVdN wChrQXmeprte45zo8vh5P22z4AWvbx4qbyg8OyShecsrKL0D/FISLi43p8fI40/cRh6bjB6x4SVT +hcO9f14l3iMYWshxbWW6QGUN2idD4uK2rs6Ttlx3y93ResBsg1AfamXsGbZ/VpY5e1nR28Al6hm tGrtUoqbd5BBye40pWNT1FSiP4qcSN65kh1XVNRuw/D7nNM93WsA6U5SiVw+cqrXGZR5dF0rIU3d gsY/nbL7gZ/x4FqTK1f4e4b7K7eJbj7/wk5FCCGEEEKdqFPu1E5FlWR9X1NbVVmoNV31NrS1aKHt +RBCSdVZnYpS4p7ekbBTEUIIIYRQH+oU7FSUEnaqQdipCN2/sFOXF/f0joSdihBCCCGE+lCnrN1O 1Z7yQ3W0Bjt10r6xNYWditD9ynksmhvNwsJO7UjYqQghhBBCqA91yqrtVLSk0jsPNlV2n9bbKbf5 bFUF2y/e0MNFCKElFfTqONfNhZ2KEEIIIYT6UKdgpyKEEEIIoauwUxFCCCGEUB/qFOxUhBBCCCF0 FXYqQgghhBDqQ52CnYoQQgghhK7CTkUIIYQQQn2oU7BT0VuUZaKIEEIIIU3moWbzIThCCCGEEFqv OgU7Fb1FNZ+FIoQQQquWeajZfAiOEEIIIYTWq07BTkVvUc1noQghhNCqZR5qNh+CI4QQQgih9apT sFPRW1TzWShCCCG0apmHms2H4AghhBBCaL3qFOzULvV9HIbN51+Wwxw+7H6Exxw+fxiGx337HF21 /zgM774c2obRfBaKEEIIrVrmoWbzIThCCCGEEFqvOgU7tUtZ7NRfu3fD+DWT1M3s1MPnDwb/93+v 2KkIIYTQHcg81Gw+BEcIIYQQQutVp2CnrlU/vmyam5KO7HZqF2o+C0UIIYRWLfNQs/kQHCGEEEII rVedgp26VmGnzlHzWShCCCG0apmHms2H4AghhBBCaL3qlDXaqfuP3o6hs1y8r49OSo9716M8ffVh 9+P4yPwZ0cT88WVjCck/bPz6a/fO2/DUPZGWiBeMunGqu61q8mF/rwQ+7H58H/3js6UdHKAe6eY9 ZQT/2r1zUvn4Xcr74947b/luBs1noQghhNCqZR5qNh+CI4QQQgih9apT1minCnaeb7oZdfj8wfP1 jn6f5/T92r37MH70D/v6GPp3Xx8DN1PcHjTaxvToGwrvj3q1LPa0rk4N7dGw6LxEjiZsyp3USrtg dWoi8h9fNoO3IWxYR+ccjR+vdq10TE7NZ6EIIYTQqmUeajYfgiOEEEIIofWqU+7ATk07hgkdPn8I ncHQ6fu1eye5hz++bK4fhitML4l79qLsIcq/FX4ea76d+vVRMkazhSkfUMNOVUojjDN+T5dajKqa z0IRQgihVcs81Gw+BEcIIYQQQutVp7xlO/U1enDeXRd59uniD4+fn8+omYP+56Vbi97ATt1/FLM2 McEKdqqao+CMcQDYqQghhNBtZR5qNh+CI4QQQgih9apTVmmnett9Tt09U9Cv3Tvjskfnc387VC2q Uu9yeTvVbEHaSruCnSqvlo2zgJ2KEEIItZZ5qNl8CI4QQgghhNarTlmdnRrtQJpwDCcoMOZmrE6N wl7j6lR7abM6FSGEEHpDMg81mw/BEUIIIYTQetUpa7NTReNsmp0q/kqwU3N7p/5v/9Hg5SleobB/ 6/nzRnun/m9/fctTQWnfdu9Uq5163swhCrj5LBQhhBBatcxDzeZDcIQQQgghtF51ytrsVNfsO3tt Ex/2F95iH5mbv3bvPowf/RfH//iyERZsRis9vz4Gie8/DkP8nisl8lvYqYJZ/H0cvCALSjvI748v m/CFUYbI47L9+jiEB9vt1GMJS7viNp+FIoQQQquWeajZfAiOEEIIIYTWq05ZnZ3qemTDyfs7GqOK eafq+zg87oOdT8PVmmefzts/VNuK1N9fVNse1CEMWNil9Ei0YFbAjUo7Rlhpa3kZl7G0/aQEx1kk TCeoEb8Y3VOcfugWmpo7VqcihBBCVWUeajYfgiOEEEIIofWqU1Zop95S5ZtyolWo+SwUIYQQWrXM Q83mQ3CEEEIIIbRedQp2alLYqXeq5rNQhBBCaNUyDzWbD8ERQgghhNB61SnYqUlhp96pms9CEUII oVXLPNRsPgRHCCGEEELrVadgp6oKdjKN9uVEK1bzWShCCCG0apmHms2H4AghhBBCaL3qFOxU9BbV fBaKEEIIrVrmoWbzIThCCCGEEFqvOgU7Fb1FNZ+FIoQQQquWeajZfAiOEEIIIYTWq07BTkVvUc1n oQghhNCqZR5qNh+CI4QQQgih9apTht8AAAAAACW0HsECAAAAADQDOxUAAAAAymg9ggUAAAAAaAZ2 KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ2KkAAAAAUEbrESwAAAAAQDOwUwEAAACg jNYjWAAAAACAZmCnAgAAAEAZrUewAAAAAADNwE4FAAAAgDJaj2ABAAAAAJqBnQoAAAAAZbQewQIA AAAANAM7FQAAAADKaD2CBQAAAABoBnYqAAAAAJTRegQLAAAAANAM7FQAAAAAKKP1CBYAAAAAoBnY qQAAAABQRusRLAAAAABAM7BTAQAAAKCM1iNYAAAAAIBmYKcCAAAAQBmtR7AAAAAAAM3ATgUAAACA MlqPYAEAAAAAmoGdCgAAAABltB7BAgAAAAA0AzsVAAAAAMpoPYIFAAAAAGgGdioAAAAAlNF6BAsA AAAA0AzsVAAAAAAoo/UIFgAAAACgGdipAAAAAFBG6xEsAAAAAEAzsFMBAAAAoIzWI1gAAAAAgGZg pwIAAABAGa1HsAAAAAAAzcBOBQAAAIAyWo9gAQAAAACagZ0KAAAAAGW0HsECAAAAADQDOxUAAAAA ymg9ggUAAAAAaAZ2KgAAAACU0XoECwAAAADQDOxUAAAAACij9QgWAAAAAKAZ/x8E6waq+6ElzwAA AABJRU5ErkJggg== --_004_D0A0DA92173EFrpazhyanciscocom_-- From nobody Sun Nov 30 18:52:55 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C121A016F for ; Sun, 30 Nov 2014 18:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3DEjsAAXZrK for ; Sun, 30 Nov 2014 18:52:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD481A00D7 for ; Sun, 30 Nov 2014 18:52:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMF31382; Mon, 01 Dec 2014 02:52:49 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Dec 2014 02:52:49 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.22]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 1 Dec 2014 10:52:39 +0800 From: "Zhangdacheng (Dacheng)" To: "Bert Wijnen (IETF)" , "Hedanping (Ana)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt Thread-Index: AQHQC32WC7Sbfn/ed0aGRZg6AZ5soJx25UiggAATbtCAABn/gIAC9ksA Date: Mon, 1 Dec 2014 02:52:38 +0000 Message-ID: References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <5479C937.7070808@bwijnen.net> In-Reply-To: <5479C937.7070808@bwijnen.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Sv2JQ8i_V-dK7xgdqGj4wzAUo9I Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 02:52:54 -0000 Hi, Bert: Thanks a lot for your comments. We fully understand the concerns of potenti= al compatibility issues. That is why we intend to firstly discuss whether t= his work will bring more benefits than negative influences . However, for t= he moment, opsawg is discussing the work of enhancing snmp with sha-2. So, = maybe we can use this chance to address this problem and use the new key lo= calization mechanism for sha-2 only? That is, when md-5 or sha-1 is deploye= d for snmp, we still use the old algorithm. Thoughts? Dacheng > -----Original Message----- > From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: Saturday, November 29, 2014 9:25 PM > To: Zhangdacheng (Dacheng); Hedanping (Ana); opsawg@ietf.org > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > Subject: Re: [OPSAWG] New Version Notification for > draft-du-opsawg-snmp-key-localization-00.txt >=20 > From a quick check, it seems that your solution would solve the problem = that > we describe in RFC3414. However, RFC3414 also discusses the issue (page 7= 3) > in the Security considerations, so users of the spec should/could be well= aware > of the issue and easily avoid the problem. >=20 > It should also be clear to anyone that a password of "bertbert" or any > "abcdabcd" repeated sequence is a very weak password. >=20 > The RFC3414 spec (i.e. its final Internet Standard version) is from 2002. > I don;t think it is wise to change the algorithms at this point, specific= ally since > we have documented how to avoid the issue. >=20 > If we (IETF) were to change the algorith, I think we would also have to i= ndicate > how implementations of the old and new algorithms can coexist. We cannot > expect all current deployments to migrate to a new version on some D-day. >=20 > Full disclosure: > as co-author of the RFC3414 I am probably biased. >=20 > Bert >=20 > On 29/11/14 04:59, Zhangdacheng (Dacheng) wrote: > > Let me help clarify Danping's point. > > > > We found there was a problem in the localization algorithm, but we are = not > sure whether this issue is worthwhile for us to address, or the effort of > addressing this issue is out of scope of the SNMP specification. So, we r= aise this > question here, and hope to get comments or suggestions. > > > > Cheers > > > > Dacheng > > > >> -----Original Message----- > >> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Hedanping > >> (Ana) > >> Sent: Saturday, November 29, 2014 10:52 AM > >> To: opsawg@ietf.org > >> Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > >> Subject: [OPSAWG] FW: New Version Notification for > >> draft-du-opsawg-snmp-key-localization-00.txt > >> > >> Dear all, > >> We find a security problem in the current SNMP key localization > >> algorithm, but we are not sure whether IETF is the right place to > >> improve it. The draft is submitted and comments are appreciated. > >> > >> A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt > >> has been successfully submitted by Danping He and posted to the IETF > >> repository. > >> > >> Name: draft-du-opsawg-snmp-key-localization > >> Revision: 00 > >> Title: A New Algorithm for SNMP Key Localization > >> Document date: 2014-11-28 > >> Group: Individual Submission > >> Pages: 4 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localization= -00. > >> txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localizatio > >> n/ > >> Htmlized: > >> http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 > >> > >> > >> Abstract: > >> This draft discusses a security issue with the algorithm for > >> generating SNMP localized keys and introduce a new algorithm to > >> address this problem. > >> > >> > >> Regards, > >> Ana (Danping) > >> _______________________________________________ > >> OPSAWG mailing list > >> OPSAWG@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > From nobody Sun Nov 30 19:51:24 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068C51A039B for ; Sun, 30 Nov 2014 19:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqgPosrqmwCA for ; Sun, 30 Nov 2014 19:51:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1F11A0119 for ; Sun, 30 Nov 2014 19:51:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPK44956; Mon, 01 Dec 2014 03:51:17 +0000 (GMT) Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Dec 2014 03:51:16 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.67]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.03.0158.001; Mon, 1 Dec 2014 11:51:04 +0800 From: "Hedanping (Ana)" To: "Zhangdacheng (Dacheng)" , "Bert Wijnen (IETF)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt Thread-Index: AQHQC32W7oq+6LVoDE6S5Cxlxqg8yZx25Uig//+PYQCAAJ4MgIACc+8AgACLcYA= Date: Mon, 1 Dec 2014 03:51:04 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8F4FD2@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8F4E6D@szxeml557-mbs.china.huawei.com> <5479C937.7070808@bwijnen.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/0mhlXb6XezpQZ-FgO3IZgBn82gY Cc: "draft-du-opsawg-snmp-key-localization@tools.ietf.org" Subject: Re: [OPSAWG] New Version Notification for draft-du-opsawg-snmp-key-localization-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 03:51:24 -0000 The security of SNMP is emerged to be enhanced . Besides customers won't ch= eck RFC before using SNMP devices, thus they are not aware of this vulnerab= ility. Vendors have to implement extra modules to constrain user behavior, = but not all the vendors do so. The current key localization algorithm is vu= lnerable, and the CVSS is rated as 7.6, AV:N/AC:H/Au:N/C:C/I:C/A:C. The new= key localization mechanism might be bundled with SHA2 as important updates= . Cheers, Ana > -----Original Message----- > From: Zhangdacheng (Dacheng) > Sent: Monday, December 01, 2014 10:53 AM > To: Bert Wijnen (IETF); Hedanping (Ana); opsawg@ietf.org > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > Subject: RE: [OPSAWG] New Version Notification for > draft-du-opsawg-snmp-key-localization-00.txt >=20 > Hi, Bert: >=20 > Thanks a lot for your comments. We fully understand the concerns of poten= tial > compatibility issues. That is why we intend to firstly discuss whether th= is work > will bring more benefits than negative influences . However, for the mome= nt, > opsawg is discussing the work of enhancing snmp with sha-2. So, maybe we = can > use this chance to address this problem and use the new key localization > mechanism for sha-2 only? That is, when md-5 or sha-1 is deployed for snm= p, > we still use the old algorithm. >=20 > Thoughts? >=20 > Dacheng >=20 > > -----Original Message----- > > From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > > Sent: Saturday, November 29, 2014 9:25 PM > > To: Zhangdacheng (Dacheng); Hedanping (Ana); opsawg@ietf.org > > Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > > Subject: Re: [OPSAWG] New Version Notification for > > draft-du-opsawg-snmp-key-localization-00.txt > > > > From a quick check, it seems that your solution would solve the > > problem that we describe in RFC3414. However, RFC3414 also discusses > > the issue (page 73) in the Security considerations, so users of the > > spec should/could be well aware of the issue and easily avoid the probl= em. > > > > It should also be clear to anyone that a password of "bertbert" or any > > "abcdabcd" repeated sequence is a very weak password. > > > > The RFC3414 spec (i.e. its final Internet Standard version) is from 200= 2. > > I don;t think it is wise to change the algorithms at this point, > > specifically since we have documented how to avoid the issue. > > > > If we (IETF) were to change the algorith, I think we would also have > > to indicate how implementations of the old and new algorithms can > > coexist. We cannot expect all current deployments to migrate to a new > version on some D-day. > > > > Full disclosure: > > as co-author of the RFC3414 I am probably biased. > > > > Bert > > > > On 29/11/14 04:59, Zhangdacheng (Dacheng) wrote: > > > Let me help clarify Danping's point. > > > > > > We found there was a problem in the localization algorithm, but we > > > are not > > sure whether this issue is worthwhile for us to address, or the effort > > of addressing this issue is out of scope of the SNMP specification. > > So, we raise this question here, and hope to get comments or suggestion= s. > > > > > > Cheers > > > > > > Dacheng > > > > > >> -----Original Message----- > > >> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of > > >> Hedanping > > >> (Ana) > > >> Sent: Saturday, November 29, 2014 10:52 AM > > >> To: opsawg@ietf.org > > >> Cc: draft-du-opsawg-snmp-key-localization@tools.ietf.org > > >> Subject: [OPSAWG] FW: New Version Notification for > > >> draft-du-opsawg-snmp-key-localization-00.txt > > >> > > >> Dear all, > > >> We find a security problem in the current SNMP key localization > > >> algorithm, but we are not sure whether IETF is the right place to > > >> improve it. The draft is submitted and comments are appreciated. > > >> > > >> A new version of I-D, draft-du-opsawg-snmp-key-localization-00.txt > > >> has been successfully submitted by Danping He and posted to the > > >> IETF repository. > > >> > > >> Name: draft-du-opsawg-snmp-key-localization > > >> Revision: 00 > > >> Title: A New Algorithm for SNMP Key Localization > > >> Document date: 2014-11-28 > > >> Group: Individual Submission > > >> Pages: 4 > > >> URL: > > >> > > > http://www.ietf.org/internet-drafts/draft-du-opsawg-snmp-key-localization= -00. > > >> txt > > >> Status: > > >> https://datatracker.ietf.org/doc/draft-du-opsawg-snmp-key-localizat > > >> io > > >> n/ > > >> Htmlized: > > >> http://tools.ietf.org/html/draft-du-opsawg-snmp-key-localization-00 > > >> > > >> > > >> Abstract: > > >> This draft discusses a security issue with the algorithm for > > >> generating SNMP localized keys and introduce a new algorithm to > > >> address this problem. > > >> > > >> > > >> Regards, > > >> Ana (Danping) > > >> _______________________________________________ > > >> OPSAWG mailing list > > >> OPSAWG@ietf.org > > >> https://www.ietf.org/mailman/listinfo/opsawg > > > > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsawg > > >