From glq@jolyriendeau.com Thu Jun 07 05:25:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEEq-0000Bc-Ph for pana-archive@lists.ietf.org; Thu, 07 Jun 2007 05:25:04 -0400 Received: from ip-62-241-101-27.evc.net ([62.241.101.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwEEq-0007H6-5R for pana-archive@lists.ietf.org; Thu, 07 Jun 2007 05:25:04 -0400 Received: from tkxq ([122.33.140.25]) by ip-62-241-101-27.evc.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jun 2007 11:25:03 +0200 Message-ID: <001101c7a8e5$ba6c37e0$198c217a@tkxq> From: "Holloway Molly" To: Subject: unreasonable Date: Thu, 7 Jun 2007 11:25:03 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C7A8F6.7DEA0B60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 ------=_NextPart_000_000D_01C7A8F6.7DEA0B60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C7A8F6.7DECCA80" ------=_NextPart_001_000E_01C7A8F6.7DECCA80 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable In recognizing this trend, Chuck Solomon, a contractor himself, = established ContractorHired. Again, that contractor will not likely get bonding in the future. Searching the Internet is a convenient and non-threatening way for = homeowners to look for qualified and local home improvement = professionals. Therefore many of you may have heard something like "This = is Brian with The Rice Report. Read more weird news. Tuscan architectural columns are simple and elegant in design and have a = powerful, clean appearance as they give the impression of supporting a = great deal of weight. Building and maintaining a Japanese garden takes commitment and requires = a discipline in maintaining the sculptural shapes of shrubs, trees and = groundcovers. This is critical when several decorative columns are being used and are = also the focal point of the building elevation. They will all be available for adoption after being treated by a = veterinarian, she said. Poorly spaced decorative columns can block = windows and entries or make elevations look unbalanced. And the = experience must be consistent. Expandability If a company outgrows = AvailSuite Personal, moving up to the Standard version requires little = effort. Further, people are seeking a sense of connectedness known as a sense of = place. A dry cascade sits nearby the Paradise Garden. And that's how we find out how people lived. Cracking Interviews . Your = answers should be to the point and precise. Financial, educational and like institutions want their communities to = perceive them as a substantial entity, with strength and a superb = foundation. Further, people are seeking a sense of connectedness known = as a sense of place. The brand delivers on those expectations and = therefore becomes memorable and recognizable. Getting to rock out on a Moog Modular with patch cords flailing = everywhere mad scientist style is a great experience! How is branding a business different from branding a product? ------=_NextPart_001_000E_01C7A8F6.7DECCA80 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D"geometrically"=20
In recognizing this trend, Chuck = Solomon, a=20 contractor himself, established ContractorHired.
Again, that contractor will not likely = get bonding=20 in the future.
Searching the Internet is a convenient = and=20 non-threatening way for homeowners to look for qualified and local home = improvement=20 professionals. Therefore many of you may have heard something like "This = is Brian=20 with The Rice Report. Read more weird news.
Tuscan architectural columns are simple = and elegant=20 in design and have a powerful, clean appearance as they give the = impression of=20 supporting a great deal of weight.
Building and maintaining a Japanese = garden takes=20 commitment and requires a discipline in maintaining the sculptural = shapes of shrubs,=20 trees and groundcovers.
This is critical when several = decorative columns=20 are being used and are also the focal point of the building = elevation.
They will all be available for adoption = after being=20 treated by a veterinarian, she said. Poorly spaced decorative columns = can block=20 windows and entries or make elevations look unbalanced. And the = experience must be=20 consistent. Expandability If a company outgrows AvailSuite Personal, = moving up to=20 the Standard version requires little effort.
Further, people are seeking a sense = of=20 connectedness known as a sense of place.
A dry cascade sits nearby the = Paradise=20 Garden.
And that's how we find out how people = lived.=20 Cracking Interviews . Your answers should be to the point and = precise.
Financial, educational and like = institutions want=20 their communities to perceive them as a substantial entity, with = strength and a=20 superb foundation. Further, people are seeking a sense of connectedness = known as a=20 sense of place. The brand delivers on those expectations and therefore = becomes=20 memorable and recognizable.
Getting to rock out on a Moog Modular = with patch=20 cords flailing everywhere mad scientist style is a great = experience!
How is branding a business different = from branding=20 a product?
------=_NextPart_001_000E_01C7A8F6.7DECCA80-- ------=_NextPart_000_000D_01C7A8F6.7DEA0B60-- From pana-bounces@ietf.org Fri Jun 08 05:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwamH-0007RL-DT; Fri, 08 Jun 2007 05:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwamF-0007R9-Ss for pana@ietf.org; Fri, 08 Jun 2007 05:29:03 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwamF-0005VH-G6 for pana@ietf.org; Fri, 08 Jun 2007 05:29:03 -0400 Received: from [88.233.212.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1HwamC4772-0001YJ; Fri, 08 Jun 2007 05:29:03 -0400 From: "Alper Yegin" To: Date: Fri, 8 Jun 2007 12:28:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceoTW7ozcnfsFvKSXiVjGM7ajZdZAALQ1UAAE0WGLA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-ID: <0MKpCa-1HwamC4772-0001YJ@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19h4LfpKjcwr9bHKcLMdFNgZynFu8eTmQ3Ob0T YSh6pDIR5V3JWU/oVBqp1xk5UDrkfAloBBPLTV2NgmKdCeZXIv tUlLvgos8FQPRpWc5pKWQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [Pana] FW: Gen-ART review of draft-ietf-pana-framework-08.txt X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org My response to David Black's e-mail. -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, June 07, 2007 12:35 AM To: 'Black_David@emc.com' Cc: 'prakash_jayaraman@net.com'; 'Rafa Marin Lopez'; 'Yoshihiro Ohba'; 'Mohan Parthasarathy'; 'gen-art@ietf.org'; 'Mark Townsley'; 'Jari Arkko'; 'Basavaraj Patil' Subject: Gen-ART review of draft-ietf-pana-framework-08.txt David, Thank you again for the review. > Section 3 could use a discussion about the relationship of the > access network to the network that PANA controls access to. > Figure 1 ought to show the latter (accessed) network as connected > to the EP, and a two-cloud ASCII diagram would be very useful. > Among other things, this would make it clear that the access > network is in general a shared access network Application of that concept to Figure 1 is tricky. The reason is, PAA may be on either side of the boundary between the "access network" and "accessed network." The only certain thing is that EP is on the border between the two. Unless anyone has a creative way to capture that in the figure, how about if we make the following change to capture your feedback? Change from: An EP must be located strategically in a local area network to minimize the access of unauthorized clients to the network. It is recommended but not mandated that the EP be on-path between the PaC and the PAA for the aforementioned reason. For example, the EP can be hosted on the switch that is directly connected to the clients in a wired network. That way the EP can drop unauthorized packets before they reach any other client node or beyond the local area network. To: An EP is located between the access network (the topology within reach of any client) and the accessed network (the topology within reach of only authorized clients). It must be located strategically in a local area network to minimize the access of unauthorized clients. It is recommended but not mandated that the EP be on-path between the PaC and the PAA for the aforementioned reason. For example, the EP can be hosted on the switch that is directly connected to the clients in a wired network. That way the EP can drop unauthorized packets before they reach any other client node or beyond the local area network. > Section 4 talks about authentication at two levels - the lower > level (link native or IPsec) and EAP over PANA. It needs to > describe the recommended or required relationships between the > identities used for these authentications. If there is no > relationship, there is a potential vulnerability (particularly > in the IPsec scenario) to a man-in-the-middle attack where the > secure channel ends are not at the PaC and EP. > > The latter concern needs to be noted in the Security Considerations > section, even if it is addressed elsewhere - the solution need > not be in this draft, but the identity correspondence problem > is an aspect of the PANA framework and needs to be noted as a > security consideration. How about if we modify the following paragraph In case cryptographic access control needs to be enabled after the PANA authentication, a secure association protocol runs between the PaC and the EP. The PaC should already have the input parameters to this process as a result of the successful PANA exchange. Similarly, the EP should have obtained them from the PAA during the service provisioning. The secure association protocol exchange produces the required security associations between the PaC and the EP to enable cryptographic data traffic protection. Per-packet cryptographic data traffic protection introduces additional per-packet overhead but the overhead exists only between the PaC and EP and will not affect communications beyond the EP. To: In case cryptographic access control needs to be enabled after the PANA authentication, a secure association protocol runs between the PaC and the EP. Dynamic parameters required for that protocol (e.g., endpoint identity, shared secret) are derived from successful PANA authentication. For example, see [I-D.ietf-pana-ipsec] for how it is done with IKE. The secure association protocol exchange produces the required security associations between the PaC and the EP to enable cryptographic data traffic protection. Per-packet cryptographic data traffic protection introduces additional per-packet overhead but the overhead exists only between the PaC and EP and will not affect communications beyond the EP. Security consideration related text is distributed all across, due to the subject of this document. That's why I prefer to handle this discussion around the relevant text (as in above). Please let us know if these make sense. Regards, Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 08 05:29:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwamM-0007xo-Jk; Fri, 08 Jun 2007 05:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwamL-0007ng-2C for pana@ietf.org; Fri, 08 Jun 2007 05:29:09 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwamJ-0005Ve-Mz for pana@ietf.org; Fri, 08 Jun 2007 05:29:09 -0400 Received: from [88.233.212.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1HwamF1g2G-0001YJ; Fri, 08 Jun 2007 05:29:07 -0400 From: "Alper Yegin" To: Date: Fri, 8 Jun 2007 12:28:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceoTW7ozcnfsFvKSXiVjGM7ajZdZABYT0VQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-ID: <0MKpCa-1HwamF1g2G-0001YJ@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/gz/ZFgZLhwUVHECt7hNDHAq7z4ZcUmEU6Yg4 mamAHSLlXjHZ4Pg+QdRd/xQBqrMv4/bPpWbs58BwKBk3w5IcPS wOgeADoOI7uYP63dz0oZQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [Pana] FW: [Black_David@emc.com: Gen-ART review of draft-ietf-pana-framework-08.txt] X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org David Black's Gen-Art review feedback. ----- Forwarded message from Black_David@emc.com ----- X-VirusChecked: Checked X-Env-Sender: Black_David@emc.com X-Msg-Ref: server-2.tower-55.messagelabs.com!1181017142!23922125!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [128.222.32.20] X-SpamReason: No, hits=0.0 required=7.0 tests= From: Black_David@emc.com Subject: Gen-ART review of draft-ietf-pana-framework-08.txt To: prakash_jayaraman@net.com, rafa@dif.um.es, yohba@tari.toshiba.com, mohanp@sbcglobal.net, alper01.yegin@partner.samsung.com, gen-art@ietf.org Cc: Black_David@emc.com, townsley@cisco.com, basavaraj.patil@nokia.com X-OriginalArrivalTime: 05 Jun 2007 04:18:00.0083 (UTC) FILETIME=[80907630:01C7A728] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.4.205032 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-MIME-Autoconverted: from quoted-printable to 8bit by toshi17.tari.toshiba.com id l554JAxI020531 X-UIDL: ~WL"!CN~!!*:3!!S@L"! I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pana-framework-08.txt Reviewer: David L. Black Review Date: June 4, 2007 IETF LC End Date: June 7, 2007 Summary: This draft is on the right track but has open issues, described in the review. Comments: This draft has changed significantly since it's -06 version that I previously reviewed for Gen-ART. Sections 5-10 of the -06 draft have been removed, resulting in a considerably higher level -08 document that is appropriate to publish as Informational (my previous review of -06 had expressed a concern about whether it should be standards track instead of informational). Much of my previous Gen-ART review concerned portions of the -06 draft that have been removed: http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-pana-framework-06-b lack.txt The following points from that review of -06 has not been addressed: Section 3 could use a discussion about the relationship of the access network to the network that PANA controls access to. Figure 1 ought to show the latter (accessed) network as connected to the EP, and a two-cloud ASCII diagram would be very useful. Among other things, this would make it clear that the access network is in general a shared access network Section 4 talks about authentication at two levels - the lower level (link native or IPsec) and EAP over PANA. It needs to describe the recommended or required relationships between the identities used for these authentications. If there is no relationship, there is a potential vulnerability (particularly in the IPsec scenario) to a man-in-the-middle attack where the secure channel ends are not at the PaC and EP. The latter concern needs to be noted in the Security Considerations section, even if it is addressed elsewhere - the solution need not be in this draft, but the identity correspondence problem is an aspect of the PANA framework and needs to be noted as a security consideration. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ----- End forwarded message ----- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 08 05:29:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwamR-0008Pb-TZ; Fri, 08 Jun 2007 05:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwamQ-0008L8-1m for pana@ietf.org; Fri, 08 Jun 2007 05:29:14 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwamM-0005Vo-Ku for pana@ietf.org; Fri, 08 Jun 2007 05:29:14 -0400 Received: from [88.233.212.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1HwamK1MBE-0001YJ; Fri, 08 Jun 2007 05:29:10 -0400 From: "Alper Yegin" To: Date: Fri, 8 Jun 2007 12:28:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceoTbB4qhFc0pc6S+27e69o0FsOAQBYOb3w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-ID: <0MKpCa-1HwamK1MBE-0001YJ@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18Q73g9t3BhaV6/tf4WZqbtveLITvPcd7BxvLz +0+O+IMAV0lzWK7lYktueWjJEX8vGYCUp6bZA51SPPSz2sSW96 rLFO6H9sarT15DUnUCzSA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Pana] FW: [drafts-lastcall@icann.org: [IANA #82696] RE: Last Call: draft-ietf-pana-framework (Protocol for Carrying Authentication for Network Access (PANA) Framework) to Informational RFC] X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org IANA feedback on PANA framework document. IESG: The IANA has reviewed the following Internet-Draft which is in Last Call: draft-ietf-pana-framework-08.txt, and has the following comments/questions with regards to the publication of this document: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. Thank you. Yoshiko Chong (on behalf of IANA) > ------ Forwarded Message > From: The IESG > Reply-To: > Date: Thu, 24 May 2007 17:15:08 -0400 > To: IETF-Announce > Cc: > Subject: [Iana-rfcs] Last Call: draft-ietf-pana-framework (Protocol for > Carrying Authentication for Network Access (PANA) Framework) to > Informational RFC > > The IESG has received a request from the Protocol for carrying > Authentication for Network Access WG (pana) to consider the following > documents: > > - 'Protocol for Carrying Authentication for Network Access (PANA) ' > as a Proposed Standard > - 'Protocol for Carrying Authentication for Network Access (PANA) > Framework ' > as an Informational RFC > > This is a second IETF Last Call for these documents. During the previous > Last Call, a number of objections were raised on these documents. It > has been exactly one year since these objections were raised, and > the PANA WG has been busy working to address the community's > concerns. The protocol and resulting documentation has been > simplified in the process. A high-level summary of changes may be > found here: > > http://panasec.org/docs/listof-changes.txt > > The IESG plans to make a decision in the next few weeks on these > documents, and solicits final comments on this action. Please send > substantive comments to the ietf@ietf.org mailing lists by 2007-06-07. > Exceptionally, comments may be sent to iesg@ietf.org instead. In either > case, please retain the beginning of the Subject line to allow automated > sorting. > > The files can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-08.txt > http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-15.txt > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1177 > 6&rfc_flag=0 > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > Iana-rfcs mailing list > Iana-rfcs@rs.icann.org > https://rs.icann.org/mailman/listinfo/iana-rfcs > > ------ End of Forwarded Message > > ----- End forwarded message ----- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 08 05:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwamV-0008SP-47; Fri, 08 Jun 2007 05:29:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwamU-0008S8-24 for pana@ietf.org; Fri, 08 Jun 2007 05:29:18 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwamT-0005YV-FB for pana@ietf.org; Fri, 08 Jun 2007 05:29:18 -0400 Received: from [88.233.212.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1HwamO1DOM-0001YJ; Fri, 08 Jun 2007 05:29:17 -0400 From: "Alper Yegin" To: Date: Fri, 8 Jun 2007 12:28:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceoTau0iikRZw42R8+q74GN3I1BBwBYK0fg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-ID: <0MKpCa-1HwamO1DOM-0001YJ@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18PQX++WR30c29wJXAYZolhcrJft9RUulPNzw5 66sWRGIEcv5v/lODvcKvLq2w3HoB8k8m34zfxPtRgxI+7aNCLO 9GVNJmCcVDrHZVK217Kog== X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Subject: [Pana] FW: [drafts-lastcall@icann.org: [IANA #82695] RE: Last Call: draft-ietf-pana-pana-15.txt] X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org IANA feedback on PANA base specification... > IESG: > > The IANA has reviewed the following Internet-Draft > which is in Last Call: draft-ietf-pana-pana-15.txt, > and has the following comments/questions with regards > to the publication of this document: > > IANA HAS QUESTIONS. > > Upon approval of this document, the IANA will take > the following Actions: > > > Action 1 (section 10.1): > > Upon approval of this document, the IANA will make > the following assignments in the "PORT NUMBERS" > registry located at > > http://www.iana.org/assignments/port-numbers > > sub-registry "WELL KNOWN PORT NUMBERS" > > Keyword Decimal Description References > ------- ------- ----------- ---------- > pana [tbd]/udp PANA [RFC-pana-pana-15] > > > Action 2 (General PANA Registry): > > [ NOTE: The document never explicitly requests a > registry be created ] > > Upon approval of this document, the IANA will > create the following registry "PANA Protocol > Numbers" located at > > http://www.iana.org/assignments/TBD > > This registry contains the following sub-registries.. > > > Action 3 (section 10.2.1): > > [ NOTE: section 10.2 is confusing. it says "two > fields" and then lists "the Version, Message Type, > and Flags fields". Unless my math is wrong, that > would be three. ] > > Upon approval of this document, the IANA will > in the following registry "PANA Protocol Numbers" > located at > > http://www.iana.org/assignments/TBD > > create a new sub-registry "Message Types (version 1)" > > Assignment policy: IETF Consensus > > Initial contents of this sub-registry will be: > > Message Number Description Reference > (16-bits) > -------------- ------------- --------- > 1 Client-Initiation [RFC-pana-pana-15] > 2 Auth Request/Answer [RFC-pana-pana-15] > 3 Termination Request/Answer [RFC-pana-pana-15] > 4 Notification Request/Answer [RFC-pana-pana-15] > 5-65519 Reserved to IANA [RFC-pana-pana-15] > 65520-65535 Reserved for Experimental [RFC-pana-pana-15] > Messages [RFC-pana-pana-15] > > [ NOTE: While this section refers back to sections > 7.1-7.7, it's unclear what the actual definition of > this registry should be. This document needs to get > its IANA considerations fixed to be more clear. Perhaps > pointing back to section 7? Also, there are multiple > messages defined for each Message Number code.] > > Action 4 (section 10.2.3): > > Upon approval of this document, the IANA will in > the following registry "PANA Protocol Numbers" > located at > > http://www.iana.org/assignments/TBD > > create a new sub-registry "Message Flags (version 1)" > > Assignment policy: Standards Action > > Initial contents of this sub-registry will be: > > Flag Bit Code Description Reference > -------- ---- --------------------- --------- > 0 R Request [RFC-pana-pana-15] > 1 S Start [RFC-pana-pana-15] > 2 C Complete [RFC-pana-pana-15] > 3 A re-Authentication [RFC-pana-pana-15] > 4 P Ping [RFC-pana-pana-15] > 5-15 Reserved to IANA [RFC-pana-pana-15] > > > [ NOTE: this registry did not point back to a > previous section where these flags are defined. > A back-pointer to section 6.1 should be added ] > > > Action 5 (section 10.3.1): > > Upon approval of this document, the IANA will > in the following registry "PANA Protocol Numbers" > located at > > http://www.iana.org/assignments/TBD > > create a new sub-registry "AVP Codes" > > Assignment policy: Designated Expert with > Specification or Standards Action > > NOTE: IESG must designate an expert. > > Initial contents of this sub-registry will be: > > Code Bit Description Reference > -------- --------------------- --------- > 0 Reserved [RFC-pana-pana-15] > 1 Algorithm [RFC-pana-pana-15] > 2 AUTH [RFC-pana-pana-15] > 3 EAP-Payload [RFC-pana-pana-15] > 4 Key-Id [RFC-pana-pana-15] > 5 Nonce [RFC-pana-pana-15] > 6 Result-Code [RFC-pana-pana-15] > 7 Session-Lifetime [RFC-pana-pana-15] > 8 Termination-Cause [RFC-pana-pana-15] > 9 ??? [RFC-pana-pana-15] > 10 ??? [RFC-pana-pana-15] > 11-15 Reserved to IANA [RFC-pana-pana-15] > > [ NOTE: Section 10.3.1 specifies codes 1-10, > but refers back to sections 8.1-8.8 which only > define codes 1-8 ] > > > Action 6 (section 10.3.2): > > Upon approval of this document, the IANA will > in the following registry "PANA Protocol Numbers" > located at > > http://www.iana.org/assignments/TBD > > create a new sub-registry "AVP Flags" > > Assignment policy: Standards Action > > Initial contents of this sub-registry will be: > > Flag Bit Code Description Reference > -------- ---- --------------------- --------- > 0 V Vendor [RFC-pana-pana-15] > 1 M Mandatory [RFC-pana-pana-15] > 2-15 Reserved to IANA [RFC-pana-pana-15] > > > Action 7 (section 10.4.1): > > Upon approval of this document, the IANA will > in the following registry "PANA Protocol Numbers" > located at > > http://www.iana.org/assignments/TBD > > create a new sub-registry "Result-Code AVP > Values (AVP Code 6)" > > Allocation policy: IETF Consensus > > Initial contents of this sub-registry will be: > > Value Description Reference > 32-bit > ----- ------------------ --------- > 0 PANA_SUCCESS [RFC-pana-pana-15] > 1 PANA_AUTHENTICATION_REJECTED [RFC-pana-pana-15] > 2 PANA_AUTHORIZATION_REJECTED [RFC-pana-pana-15] > 3 to Reserved to IANA [RFC-pana-pana-15] > 2^32 > > > Action 8 (section 10.4.2): > > Upon approval of this document, the IANA will > in the following registry "PANA Protocol Numbers" > located at > > http://www.iana.org/assignments/TBD > > create a new sub-registry "Termination-Cause AVP > Values (AVP Code 8)" > > Allocation policy: IETF Consensus > > Initial contents of this sub-registry will be: > > Value Description Reference > (32-bit) > ----- ------------------ --------- > 1 LOGOUT [RFC-pana-pana-15] > 2-3 Reserved to IANA [RFC-pana-pana-15] > 4 ADMINISTRATIVE [RFC-pana-pana-15] > 5-7 Reserved to IANA [RFC-pana-pana-15] > 8 SESSION_TIMEOUT [RFC-pana-pana-15] > 9 to Reserved to IANA [RFC-pana-pana-15] > 2^32 > > > Action 9 (section 10.4): > > [ Question: The document requests First-come, > First-serve entries into 'registries' for Values > for the other AVP Codes. Should these registries > get created now or on-demand? ] > > > We understand the above to be the only IANA > Actions for this document. > > > Thank you. > > Yoshiko Chong > (on behalf of IANA) > > > > > > ------ Forwarded Message > > From: The IESG > > Reply-To: > > Date: Thu, 24 May 2007 17:15:08 -0400 > > To: IETF-Announce > > Cc: > > Subject: [Iana-rfcs] Last Call: draft-ietf-pana-framework (Protocol > for > > Carrying Authentication for Network Access (PANA) Framework) to > > Informational RFC > > > > The IESG has received a request from the Protocol for carrying > > Authentication for Network Access WG (pana) to consider the > following > > documents: > > > > - 'Protocol for Carrying Authentication for Network Access (PANA) ' > > as a Proposed Standard > > - 'Protocol for Carrying Authentication for Network Access (PANA) > > Framework ' > > as an Informational RFC > > > > This is a second IETF Last Call for these documents. During the > previous > > Last Call, a number of objections were raised on these documents. It > > has been exactly one year since these objections were raised, and > > the PANA WG has been busy working to address the community's > > concerns. The protocol and resulting documentation has been > > simplified in the process. A high-level summary of changes may be > > found here: > > > > http://panasec.org/docs/listof-changes.txt > > > > The IESG plans to make a decision in the next few weeks on these > > documents, and solicits final comments on this action. Please send > > substantive comments to the ietf@ietf.org mailing lists by 2007-06- > 07. > > Exceptionally, comments may be sent to iesg@ietf.org instead. In > either > > case, please retain the beginning of the Subject line to allow > automated > > sorting. > > > > The files can be obtained via > > > > http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-08.txt > > http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-15.txt > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1177 > > 6&rfc_flag=0 > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > > _______________________________________________ > > Iana-rfcs mailing list > > Iana-rfcs@rs.icann.org > > https://rs.icann.org/mailman/listinfo/iana-rfcs > > > > ------ End of Forwarded Message > > > > > > ----- End forwarded message ----- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 08 05:29:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwamm-00005Q-AR; Fri, 08 Jun 2007 05:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwaml-00005L-Ix for pana@ietf.org; Fri, 08 Jun 2007 05:29:35 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwaml-0005k9-8C for pana@ietf.org; Fri, 08 Jun 2007 05:29:35 -0400 Received: from [88.233.212.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1Hwama2OHL-0001YJ; Fri, 08 Jun 2007 05:29:32 -0400 From: "Alper Yegin" To: "'Mark Townsley'" Date: Fri, 8 Jun 2007 12:28:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceePnRR/TcQ3obzRay8cYqSVMWQygLbtmhw In-Reply-To: <4655EF41.4030104@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-ID: <0MKpCa-1Hwama2OHL-0001YJ@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+B2WUJjqnuufqBxss+QiQj22hev5TFgF+P7Zo II0YxrHPHyI3wMTluASybJqjo74GU7E3eVv0PletdNvLUGaVsI 8aScBVM3s5h3VmYUhMotQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 'Jari Arkko' , 'Basavaraj Patil' , pana@ietf.org Subject: [Pana] RE: Ready for IETF LC X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Mark, The last call has completed and we received comments from IANA and David Black (will forward them to the list now.) Unless you/IESG has received any other, that's all we know of. We'll revise the documents and resubmit. Could you please put the documents on the IESG agenda for the next call? Thanks. Alper > -----Original Message----- > From: Mark Townsley [mailto:townsley@cisco.com] > Sent: Thursday, May 24, 2007 11:02 PM > To: Alper Yegin > Cc: 'Basavaraj Patil'; 'Jari Arkko'; pana@ietf.org > Subject: Re: Ready for IETF LC > > Alper Yegin wrote: > > Mark, > > > > Here it is, thanks to Yoshi: > > > > http://panasec.org/docs/listof-changes.txt > > > Thank you Yoshi. > > I have submitted the Last Call request, you should see it on > ietf-announce shortly. It will last two weeks, ending June 7, the date > of the next IESG telechat. If the LC goes well, the PANA documents will > be on the June 7 telechat for evaluation by the IESG. > > Thanks to everyone for all of the hard work and perseverance improving > the PANA protocol and specifications. > > - Mark > > > Alper > > > > > >> -----Original Message----- > >> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >> Sent: Tuesday, May 15, 2007 4:42 PM > >> To: 'Mark Townsley' > >> Cc: 'Basavaraj Patil'; 'Jari Arkko'; 'pana@ietf.org' > >> Subject: RE: Ready for IETF LC > >> > >> We can prepare one. > >> > >> But just to streamline the process, please tell us if there is anything > >> else you need. > >> > >> Alper > >> > >> > >>> -----Original Message----- > >>> From: Mark Townsley [mailto:townsley@cisco.com] > >>> Sent: Tuesday, May 15, 2007 4:28 PM > >>> To: Alper Yegin > >>> Cc: 'Basavaraj Patil'; 'Jari Arkko'; pana@ietf.org > >>> Subject: Re: Ready for IETF LC > >>> > >>> Alper Yegin wrote: > >>> > >>>> Hi Mark, > >>>> > >>>> PANA framework and base specification documents are ready for the 2nd > >>>> > >>> IETF > >>> > >>>> Last Call. > >>>> > >>>> http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-08.txt > >>>> http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-15.txt > >>>> > >>>> Could you please issue the LC at your earliest convenience? > >>>> > >>>> > >>> Do you have a convenient link for me to point to that summarizes the > >>> significant changes since the last IETF LC? This would help in > >>> constructing the LC text. > >>> > >>> Thanks, > >>> > >>> - Mark > >>> > >>>> Regards, > >>>> > >>>> - PANA WG Chairs > >>>> > >>>> > >>>> > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 08 07:45:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwctz-0007cN-5k; Fri, 08 Jun 2007 07:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwctx-0007RG-Oc for pana@ietf.org; Fri, 08 Jun 2007 07:45:09 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwctv-0001Ww-Cd for pana@ietf.org; Fri, 08 Jun 2007 07:45:09 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2007 07:45:08 -0400 X-IronPort-AV: i="4.16,399,1175486400"; d="scan'208"; a="62281340:sNHT61159176" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l58Bj7vT008129; Fri, 8 Jun 2007 07:45:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l58Bj6Be001870; Fri, 8 Jun 2007 11:45:06 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 07:45:06 -0400 Received: from [10.83.1.98] ([10.83.1.98]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 07:45:05 -0400 Message-ID: <4669413C.3040704@cisco.com> Date: Fri, 08 Jun 2007 13:45:00 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1Hwama2OHL-0001YJ@mrelay.perfora.net> In-Reply-To: <0MKpCa-1Hwama2OHL-0001YJ@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 11:45:06.0089 (UTC) FILETIME=[75596190:01C7A9C2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2898; t=1181303107; x=1182167107; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20Ready=20for=20IETF=20LC |Sender:=20 |To:=20Alper=20Yegin=20; bh=G6vc8DQopEP0FiJqSPAogEoV9IwWx5aDi3V1uneQIBc=; b=eklrkxYwgugK6gxuanMaAQeHNAWXoqPHbCwcyr4szJPTwjQTynaLBmwkf81KAuY3uqrHYnip g+zHjwjo+lV8prr9+5lxgMTW/UZ8Zp51wyN8YVdr6+Z9ELAlGaTT0eFF; Authentication-Results: rtp-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: 'Jari Arkko' , 'Basavaraj Patil' , pana@ietf.org Subject: [Pana] Re: Ready for IETF LC X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Alper Yegin wrote: > Hi Mark, > > The last call has completed and we received comments from IANA and David > Black (will forward them to the list now.) > > Unless you/IESG has received any other, that's all we know of. We'll revise > the documents and resubmit. > Thanks, looking forward to the revision. > Could you please put the documents on the IESG agenda for the next call? > They already are. - Mark > Thanks. > > Alper > > >> -----Original Message----- >> From: Mark Townsley [mailto:townsley@cisco.com] >> Sent: Thursday, May 24, 2007 11:02 PM >> To: Alper Yegin >> Cc: 'Basavaraj Patil'; 'Jari Arkko'; pana@ietf.org >> Subject: Re: Ready for IETF LC >> >> Alper Yegin wrote: >> >>> Mark, >>> >>> Here it is, thanks to Yoshi: >>> >>> http://panasec.org/docs/listof-changes.txt >>> >>> >> Thank you Yoshi. >> >> I have submitted the Last Call request, you should see it on >> ietf-announce shortly. It will last two weeks, ending June 7, the date >> of the next IESG telechat. If the LC goes well, the PANA documents will >> be on the June 7 telechat for evaluation by the IESG. >> >> Thanks to everyone for all of the hard work and perseverance improving >> the PANA protocol and specifications. >> >> - Mark >> >> >>> Alper >>> >>> >>> >>>> -----Original Message----- >>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>>> Sent: Tuesday, May 15, 2007 4:42 PM >>>> To: 'Mark Townsley' >>>> Cc: 'Basavaraj Patil'; 'Jari Arkko'; 'pana@ietf.org' >>>> Subject: RE: Ready for IETF LC >>>> >>>> We can prepare one. >>>> >>>> But just to streamline the process, please tell us if there is anything >>>> else you need. >>>> >>>> Alper >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Mark Townsley [mailto:townsley@cisco.com] >>>>> Sent: Tuesday, May 15, 2007 4:28 PM >>>>> To: Alper Yegin >>>>> Cc: 'Basavaraj Patil'; 'Jari Arkko'; pana@ietf.org >>>>> Subject: Re: Ready for IETF LC >>>>> >>>>> Alper Yegin wrote: >>>>> >>>>> >>>>>> Hi Mark, >>>>>> >>>>>> PANA framework and base specification documents are ready for the 2nd >>>>>> >>>>>> >>>>> IETF >>>>> >>>>> >>>>>> Last Call. >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-08.txt >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-15.txt >>>>>> >>>>>> Could you please issue the LC at your earliest convenience? >>>>>> >>>>>> >>>>>> >>>>> Do you have a convenient link for me to point to that summarizes the >>>>> significant changes since the last IETF LC? This would help in >>>>> constructing the LC text. >>>>> >>>>> Thanks, >>>>> >>>>> - Mark >>>>> >>>>> >>>>>> Regards, >>>>>> >>>>>> - PANA WG Chairs >>>>>> >>>>>> >>>>>> >>>>>> >>> > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From dqaabound@ak-promotion.com Fri Jun 08 14:02:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwin5-0000oC-Bf for pana-archive@lists.ietf.org; Fri, 08 Jun 2007 14:02:27 -0400 Received: from static29.debica231.tnp.pl ([87.116.231.29] helo=ak-promotion.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwin1-0005do-BM for pana-archive@lists.ietf.org; Fri, 08 Jun 2007 14:02:27 -0400 Message-ID: <001701c7aa07$e35240a0$00a73fec@Jerzy> From: "Angel Battle" To: "pana-archive" Subject: Thanks, we are accepting your refinance appication Date: Fri, 8 Jun 2007 19:57:43 +1300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C7AA07.E35240A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.9 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ------=_NextPart_000_0014_01C7AA07.E35240A0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Your credit history doesn't matter to us! If your family OWN real estate and want IMMEDIATE money to spend ANY way = you like, or simply need to LOWER your monthly payments by a third or = more, here is our deal we can offer you TONIGHT (hurry, this tender will = expire THIS EVENING): $491,000+ debt AND EVEN MORE: After further review, our lenders have established the = lowest entire payment! Hurry, when our best deal is gone, it is gone. Simply fill out this = one-minute form... Do not worry about approval, your credit history will not disqualify = you! http://tstyutes.com/ ------=_NextPart_000_0014_01C7AA07.E35240A0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Your credit score = doesn't matter to us!
 
If your family OWN = property and want IMMEDIATE ready money to spend ANY way you like, or = simply wish to LOWER your payments by a third or more, here is best deal = we can offer you NOW (hurry, this deal will expire THIS = NIGHT):
 
$312,000+ = loan
 
AND EVEN MORE: After = further review, our lenders have set the lowest monthly = payments!
 
Hurry, when our best = deal is gone, it is gone. Simply fill out this short form... =
 
Don't worry about = approval, your your credit report will not disqualify you!
 
------=_NextPart_000_0014_01C7AA07.E35240A0-- From jcleavage@clearviewcatv.net Fri Jun 08 14:10:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwiv5-0001cR-TX for pana-archive@lists.ietf.org; Fri, 08 Jun 2007 14:10:43 -0400 Received: from 201-40-8-81.cpece700.dsl.brasiltelecom.net.br ([201.40.8.81] helo=clearviewcatv.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwiv2-0001uF-7b for pana-archive@lists.ietf.org; Fri, 08 Jun 2007 14:10:43 -0400 Message-ID: <001001c7a9df$2c7eb110$002a980c@sueli0i985608u> From: "Jerry Lozano" To: "pana-archive" Subject: Thank you, we will help you fight out the cash crunch Date: Fri, 8 Jun 2007 15:07:34 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C7A9DF.2C7EB110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.2963 X-Spam-Score: 2.7 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_000D_01C7A9DF.2C7EB110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit doesn't matter to us! If you OWN real estate and want IMMEDIATE ready money to spend ANY way = you like, or simply want to LOWER your entire payment by a third or = more, here is our best deal we can offer you NOW (hurry, this tender = will expire TONIGHT): $316,000+ debt AND EVEN MORE: After further review, our lenders have set the lowest = current payments! Hurry, when our best deal is gone, it is gone. Simply fill in this = one-minute form... Do not worry about approval, your credit score will not disqualify you! http://tstyutes.com/ ------=_NextPart_000_000D_01C7A9DF.2C7EB110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Your credit history = does not matter to us!
 
If you OWN property and = want IMMEDIATE money to spend ANY way you like, or simply wish to LOWER = your entire payment by a third or more, here is the deal we can offer = you THIS NIGHT (hurry, this offer will expire THIS = EVENING):
 
$389,000+ = loan
 
AND EVEN MORE: After = further review, our lenders have established the lowest entire = payment!
 
Hurry, when the deal is = gone, it is gone. Simply complete this user-friendly form... =
 
Don't worry about = approval, your credit history will not disqualify you!
 
------=_NextPart_000_000D_01C7A9DF.2C7EB110-- From pana-bounces@ietf.org Fri Jun 08 19:25:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwnpe-0004Z4-0P; Fri, 08 Jun 2007 19:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwnpc-0004YJ-EF; Fri, 08 Jun 2007 19:25:24 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwnpb-0004SP-34; Fri, 08 Jun 2007 19:25:24 -0400 Received: from [88.233.212.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1HwnpR3xK5-0002sv; Fri, 08 Jun 2007 19:25:21 -0400 From: "Alper Yegin" To: Date: Sat, 9 Jun 2007 02:25:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceoTW7ozcnfsFvKSXiVjGM7ajZdZAALQ1UAAF6l8HAAB7ZjoAAEDGjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-ID: <0MKp8S-1HwnpR3xK5-0002sv@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/W9oDugKQhu3zICYHPKtzVN/OsFHKd6dmetg6 +8XO8DITHN/wxVEoRigW+lxcZPgixq4eJQqdTIaRWVqDBkap8y KCYrkP2ShLDwmT7xC1B6Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: townsley@cisco.com, gen-art@ietf.org, jari.arkko@piuha.net, pana@ietf.org Subject: [Pana] FW: Gen-ART review of draft-ietf-pana-framework-08.txt X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org > > To: > > > > An EP is located between the access network (the topology within > reach > > of any client) and the accessed network (the topology within > reach of > > only authorized clients). It must be located strategically in a > local > > area network to minimize the access of unauthorized clients. It > is > > recommended but not mandated that the EP be on-path between the > > PaC and the PAA for the aforementioned reason. For example, the > > EP can be hosted on the switch that is directly connected to the > > clients in a wired network. That way the EP can drop > unauthorized > > packets before they reach any other client node or beyond the > > local area network. > > That's good. It would also help to show the traffic authorized by PANA > in figure 1 - it flows from the PaC (must be the endpoint) through the > EP (must be on-path) and onward (down-arrow from EP box). While we're > dealing with this figure, I think the IKE/4-way handshake label on > the Pac-to-EP link needs to be changed to be consistent with Section > 4's discussion of the various possible setup scenarios - use of IKE > is possible, but not required. RADIUS, Diameter, +-----+ PANA +-----+ LDAP, API, etc. +-----+ | PaC |<----------------->| PAA |<---------------->| AS | +-----+ +-----+ +-----+ ^ ^ ^ | . | | . +-----+ | | ........|.EP | | +--------->| . |<--------+ SNMP, API, etc. IKE, +-----+ 4-way handshake, . etc. . . v Data traffic > > To: > > > > In case cryptographic access control needs to be enabled after the > > PANA authentication, a secure association protocol runs between the > > PaC and the EP. Dynamic parameters required for that > > protocol (e.g., endpoint identity, shared secret) are derived from > > successful PANA authentication. For example, see > [I-D.ietf-pana-ipsec] > > for how it is done with IKE. The secure association protocol > exchange > > produces the required security associations between the PaC and the > EP to > > enable cryptographic data traffic protection. Per-packet > cryptographic > > data traffic protection introduces additional per-packet overhead > but the > > overhead exists only between the PaC and EP and will not affect > > communications beyond the EP.. > > "are derived from successful PANA authentication" --> "are derived from > successful PANA authentication; these parameters are used to > authenticate > the PaC to the EP and vice-versa as part of creating the security > association." > > "for how it is done with IKE" --> "for how it is done for IKE based on > using a key-generating EAP method for PANA between the PaC and PAA". > > There are two points I'm clarifying here: > - PANA is the primary authentication. The output of that EAP method > serves to authentication the security association in the context > of that primary authentication (i.e., Pac and EP do not > authenticate > from scratch independent of the PANA authentication). > - Remove any possibility of confusing PANA's use of EAP with the ability > to run EAP between the PaC and EP (e.g., EAP can be embedded in > IKEv2). > In case cryptographic access control needs to be enabled after the PANA authentication, a secure association protocol runs between the PaC and the EP. Dynamic parameters required for that protocol (e.g., endpoint identity, shared secret) are derived from successful PANA authentication; these parameters are used to authenticate the PaC to the EP and vice-versa as part of creating the security association. For example, see [I-D.ietf-pana-ipsec] for how it is done for IKE based on using a key-generating EAP method for PANA between the PaC and PAA. The secure association protocol exchange produces the required security associations between the PaC and the EP to enable cryptographic data traffic protection. Per-packet cryptographic data traffic protection introduces additional per-packet overhead but the overhead exists only between the PaC and EP and will not affect communications beyond the EP. Thank you. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From vtd@frontiernet.net Fri Jun 08 21:13:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwpWD-00089n-EG for pana-archive@lists.ietf.org; Fri, 08 Jun 2007 21:13:29 -0400 Received: from [189.157.15.138] (helo=dsl-189-157-15-138.prod-infinitum.com.mx) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwpWB-0003Fq-LL for pana-archive@lists.ietf.org; Fri, 08 Jun 2007 21:13:29 -0400 Message-ID: <466A1AC4.4080203@frontiernet.net> Date: Fri, 8 Jun 2007 20:13:08 -0700 From: Millie User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: barefoot linear Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 CAON Takes New Direction. Investors Are All Over It! Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% Volume Jumped through the roof today as CAON announced it has changed its direction and acquired Harbin Hongbo, as wells as its 12 patients for environmentally safe construction materials. Investors are already seeing the potential. We expect great things from CAON with big news expected Monday. Get on CAON first thing Monday! Jacques Foccart, "Mr. Do you think he cared when our first leader of the RPF, Fred Rwigyema died? He made his audience gasp when he declared France as the residence of "the number one promoter of corruption in Africa," and also the "biggest money launderer in the world. " Asked who decided it, he responds evasively that "the archives will one day answer your question", a fall-back position he often adopts. For us we are never closed to any body, we can sit down analyse it, see if its worth it and act accordingly. No international enquiry was ever held. France is intent at destroying our government, we do not see any need for keeping any relationship with a hostile country,' Nkusi is quoted saying in the release. Prunier has speculated that it might have been possible to hire mercenaries to shoot down the plane. Members of the Presidential Guard spotted them leaving Masaka Hill from where the missiles were fired. There was an open door connecting to the other room where my aides were sleeping and I saw them on the floor handcuffed at gun point. From uwrv@knology.net Sat Jun 09 09:58:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx1Se-0002Sp-IL for pana-archive@lists.ietf.org; Sat, 09 Jun 2007 09:58:36 -0400 Received: from [190.49.220.137] (helo=190-49-220-137.speedy.com.ar) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hx1Sd-0007pd-Pp for pana-archive@lists.ietf.org; Sat, 09 Jun 2007 09:58:36 -0400 Message-ID: <466AB218.1010701@knology.net> Date: Sat, 9 Jun 2007 10:58:48 -0300 From: Viola W. Guzman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: More information is available at the Michael Kingston Productions site. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 CAON Releases Fact Sheet For Investors Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% Read this over the weekend, you won't be sorry. CAON has changed direction and investors love it. Friday's volume went through the roof. Big news expected Monday. Set your marker for CAON first thing Monday! There is no fee to enter. I would hope that your setting has the following characteristics. It was fun, it was easy, it was cleansing. It will affect your characters. " Why not take a snapshot of the meditation corner in your home. Wives and Co-Parents: Is the father of your child doing an exceptional job in parenting? I recently ducked a "curve ball" that came out of nowhere in my personal life. These guidelines apply in general to other music players, such as the Sandisk Sansa and the Creative Zen Micro, which they found to produce similar volume levels. If a serious error or omission in such a report goes unnoticed by the clinical physician, there can be dire results. com All Rights Reserved. Expectations don't always pan out. Hallinan divides his time between Los Angeles and Southeast Asia, primarily Thailand, where he has lived off and on for more than twenty years. No particular piece of equipment is simulated in any of them, but the combined flexibility can generate some of the desirable aspects of great sounding analogue gear. Access Error Headline functionality has been disabled from your intranet. More information is available at the StealthPlug site. com All Rights Reserved. Doubt is a drag queen. Floor POD can be used as a simple multi-effect pedal for any guitar amp, a complete direct to PA and recording tone solution, or the ultimate headphone practice partner at home. Cut and Fxxk controls allow fine tuning of ultra-low and ultra-high frequencies. Failing equipment can be easily simulated and this allows plenty of creativity. I do a lot of public speaking, and what I try above all to convey is the idea that the number-one challenge of the entrepreneur is belief. I recently ducked a "curve ball" that came out of nowhere in my personal life. All music contracts from both volumes were drafted and authenticated by a registered Los Angeles based Entertainment Law Firm. The simple goal was to find the companies that could benefit from my product. Advanced features include a rule editor and a chord symbol lookup tool. I experienced some upsets. So I say, "Act your youth. Anyway, this experience gave me the a nudge I needed to write about how our defunct expectations can get in the way of our happiness if we let it. Word Association: How Your Mind Walks Your Talk - interesting experiment showing how thinking can affect your physical movement. He has been profiled on CNBC and CNN Financial Network, and has been a guest on Bloomberg radio and the Tom Joyner Morning Show. More information is available at the StealthPlug site. The intention of the gallery is to create a collage of serenity and calm. Also included are numerous bonus patches of special effects, doubled guitars, and more. A trial version of RetroBand and the free RetroBandLite version can be downloaded on-line at the Michael Kingston Productions website. Laura Nathanson is the author of The Portable Pediatrician, as well as several other books. Does this woman have pneumonia? The message really hit home on Saturday morning when a voice on the other end of the phone said ''. This Week: More carnival attractions at Mind Mart. Also included are numerous bonus patches of special effects, doubled guitars, and more. It may desirably enrich sterile sound sources. Please contact your system administrator to report this fault. If a serious error or omission in such a report goes unnoticed by the clinical physician, there can be dire results. And more importantly, my focus became clearer and clearer the more detritus I eliminated. Setting is, of course, the physical universe in which your story is set. It provides an almost inexhaustible source of details that can help you tell your story more vividly or give you an entirely new set of ideas. The report was ambiguous or incomplete, and the clinical physician did not clarify it. Their music using Trogotronic gear will constitute the release. Let's get real here, we are all busy people. Penny Archer is a Director of SmartDames FZ LLC, an international Email List Broker based in Dubai Media City, Dubai. It is an opportunity for artists to take advantage of all Austin has to offer in what is one of the most important music weeks of the year. This article has one comment so far! It wobbles into the room in a pair of stilettos and a rhinestone tiara and sings the torch song of reason. Other articles that she has written can be found at www. Photo capacity is based on iPod-viewable photos transferred from iTunes. Almost all new processors support SSE now. Word Association: How Your Mind Walks Your Talk - interesting experiment showing how thinking can affect your physical movement. From bgsyo@email.com Sun Jun 10 06:50:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxL08-0003FK-RM for pana-archive@lists.ietf.org; Sun, 10 Jun 2007 06:50:28 -0400 Received: from [85.104.133.124] (helo=dsl85-104-34172.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxL06-0003EX-Gd for pana-archive@lists.ietf.org; Sun, 10 Jun 2007 06:50:28 -0400 Message-ID: <466BD770.1050100@email.com> Date: Sun, 10 Jun 2007 13:50:24 +0300 From: Jasper E. Glass User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: End users can manipulate the flowchart, performing such actions as adding new elements, resizing and repositioning them, selecting items, and modifying them. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab CAON Releases Fact Sheet For Investors Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% Read this over the weekend, you won't be sorry. CAON has changed direction and investors love it. Friday's volume went through the roof. Big news expected Monday. Set your marker for CAON first thing Monday! But these gotchas are minor parts of the blog world, and you'll see the same tricks on the opinion pages of any newspaper. All rights reserved; reproduction in part or in whole without permission is prohibited. config may be configured where the requiresQuestionAndAnswer property is set to false. In this project, I'll use the Table Profile Provider Samples, which you'll find at asp. NET Profile provider, the Table Profile Provider Samples allow profile data to be stored in an easily readable format. As you can see ,the Product element has many attributes, the most important of which are Id and Name. NET temporary folder for the application. From nfnar@presstran.com Mon Jun 11 07:57:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxiWf-0006HN-80 for pana-archive@lists.ietf.org; Mon, 11 Jun 2007 07:57:37 -0400 Received: from [58.141.27.30] (helo=qlft) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxiWe-0002xK-JV for pana-archive@lists.ietf.org; Mon, 11 Jun 2007 07:57:37 -0400 Message-ID: <466D38AE.3020804@presstran.com> Date: Mon, 11 Jun 2007 20:57:34 +0900 From: extricate User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: demolition Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d CAON Now Holds 12 Environmental Patents! Investors Respond! Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% CAON acquires Harbin Hongbo and its 12 patents. This company's new direction was released in a fact sheet Friday. Investors are already jumping all over it. Read the release and get all over CAON first thing Monday! com News and information on this page is distributed by the companies featured through Actorschecklist. Falls in love with her student's father. He is insecure and considerate. In a single moment, all of the events literally smash together and create an outlandishly YouTube video that's doomed for fame. After his girlfriend Margot exploits him online, benedict can't tell if she loves him or hates him, so he tries to grow a mustache. They all share a similar dream, monologues and flashbacks of each actor are presented in a humorous as well as erotic form. Actors should be prepared to read from the script. He is short witted and bossy. She is extremely strong, you might say emotionally frozen. A truly multigenerational story, both in cast and audience appeal. When Milo gets nervous, he grabs his groin. He found that long search happiness, but he can't enjoy until he shares it with his mother and sister. org for more information. From rtut@eaton.com Tue Jun 12 11:31:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8LP-0001kI-UO for pana-archive@lists.ietf.org; Tue, 12 Jun 2007 11:31:43 -0400 Received: from [190.12.13.50] (helo=corp-190-12-13-50-uio.puntonet.ec) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hy8LO-0000bi-0K for pana-archive@lists.ietf.org; Tue, 12 Jun 2007 11:31:43 -0400 Message-ID: <466EBC61.7030102@eaton.com> Date: Tue, 12 Jun 2007 10:31:45 -0500 From: Magnus Williams User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: top-heavy Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 News Hits! New R&D Facility Engaged! Chan-On International Inc. Symbol: CAON Close: $0.73 News hits today on CAON and trading continues to warm up. Hitting highs of $0.90 today, we can see this building. Read the release and get on CAON first thing Tuesday. We can see this climbing all week! I think we are going to look at Mogulus not only for the things Max has just mentioned but also for things that this small companies do not maybe lack, but sometimes overlook. and individuals can learn from each other, work together, etc. The selection of the appropriate social software tool for the context and client is critical however, as well as ensuring its use is authentic and relevant. Additional Resources If you would like to read more about Babelgum, you might want to check out the following links:The Babelgum website Babelgumfan. In a world where content is everything and both design and technical issues play a somewhat secondary role - take YouTube as a case in point - this could well prove to be a fruitful strategy. Some respondents using social software for knowledge sharing reported that they still do not use it well. are really on the road-map. With relentless repetition and indoctrination they created the sense that these people were something less than human. However, Babelgum has managed to enter the scene with an edgy, cool independent feel that I hope it will further build on. org is published in some thirteen languages, and aims to have an impact not just on local level, but also a global one. The first option is to make use of the MixerCast Wizard, the quicker and simpler of the two editing approaches. And the easiest way to create fear in a population is to create a nefarious, shadowy 'Other', an Other so far removed from our beliefs, ethics and way of life as to seem all but inhuman. As you would expect, MixerCast widgets can be embedded in most websites, blogs and SNS with a simple copy-and-paste of a few lines of code. MyBlogLog is right now a positive enhancer of most any web site or blog desiring to increase its ability to build community and to give extra prominence and visibility to its own stakeholders. But whose interests does this apparent clash really serve? The forthcoming Muze Video collection should make for an impressive addition to the MixerCast line-up. They direct the traffic and bring the knowledge to you. And the easiest way to create fear in a population is to create a nefarious, shadowy 'Other', an Other so far removed from our beliefs, ethics and way of life as to seem all but inhuman. " Many respondents could be considered digitally literate and perhaps this has contributed to their early adoption of the technologies. RG: When did the vision come? Increased exposure and visibility is also possible as with MyBlogLog everyone is able to view what their readers have checked out in other communities. Anecdotal reports suggest that some teams felt controlled and resented this new requirement while others felt empowered as they engaged with the new technologies. So basically what Robin is talking about is that is that at the moment, on Mogulus. Max Haot: I was basically vice-president of digital media at Verizon business, which is the business division of Verizon. The original is copied, so remains unharmed, and should the original user delete any media from the source MixerCast, it will also become absent in any remixed versions. The following powerful mashup video argues the case far better than words alone might. " Naomi Wolf - The Beauty Myth Photo Credit: Adam Radosavljevic "No wonder our perception of beauty is distorted. RG: In which role did you play? Lifelong learning competence Individuals using social software are excited by its ability to inspire people to become more self-reliant learners and sharers of knowledge. The web, by giving as close to freedom of expression as we have yet seen, is an environment that fosters different perspectives. Max Haot: Yes, until the end of the year. RG: But you are charging them! RG: No, but we want to share with you the money we make , so that if we are successful you are too. And the easiest way to create fear in a population is to create a nefarious, shadowy 'Other', an Other so far removed from our beliefs, ethics and way of life as to seem all but inhuman. With relentless repetition and indoctrination they created the sense that these people were something less than human. towards making this a better world. I think that right there your competition has not done a great job so far, so you should take advantage of this instead of shooting forward for more. RG: Yeah, but we all wanna go pro-version! In the meantime contact details have been given on the Babelgum website for prospective content providers. From gtx@cableone.net Thu Jun 14 02:09:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyiWs-0002xn-AP for pana-archive@lists.ietf.org; Thu, 14 Jun 2007 02:09:58 -0400 Received: from [88.229.110.76] (helo=dsl88-229-28236.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HyiWq-0004gd-EH for pana-archive@lists.ietf.org; Thu, 14 Jun 2007 02:09:58 -0400 Received: from ees ([107.60.59.82]) by dsl88-229-28236.ttnet.net.tr (8.13.2/8.13.2) with SMTP id h5E6AMFC013549; Sat, 14 Jun 2003 09:10:22 +0300 Message-ID: <3EEABC32.1070100@cableone.net> Date: Sat, 14 Jun 2003 09:09:54 +0300 From: Juliet User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: grandma intermediary Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 CAON UP 45% In The Last Week! Chan-On International Inc. Symbol: CAON Close: $0.80 UP CAON continues to climb daily. Up 45% in the last 7 days as investors are excited about this company's new direction. Read the releases, consider the potential and get on CAON firs thing Thursday! It is not a game they are playing but a determined provocation of the police. Why the personalisation of the circumstances of capital? He has spent more than a total of three years in solitary confinement in conditions worse than the USA's infamous 'death rows'. Meanwhile, they are lavished with luxuries and messages from the leaders. on some level we all prioritise certain campaigns over others in order to be effective and not spread our resources too thin. Global IMC Network www. Refreshments will be provided. From byv@skynet.be Thu Jun 14 05:14:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylPF-000528-H8 for pana-archive@lists.ietf.org; Thu, 14 Jun 2007 05:14:17 -0400 Received: from [70.158.139.251] (helo=yjqpyf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HylPF-0004dO-60 for pana-archive@lists.ietf.org; Thu, 14 Jun 2007 05:14:17 -0400 Received: from zqaxb ([68.86.119.156]) by yjqpyf (8.13.3/8.13.3) with SMTP id l5E9IZrM054197; Thu, 14 Jun 2007 05:18:35 -0400 Message-ID: <467106DD.7060303@skynet.be> Date: Thu, 14 Jun 2007 05:14:05 -0400 From: Maude T. Blanchard User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: " Just because you stopped your last running program or missed several runs doesn't mean you have to quit altogether. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f CAON UP 45% In The Last Week! Chan-On International Inc. Symbol: CAON Close: $0.80 UP CAON continues to climb daily. Up 45% in the last 7 days as investors are excited about this company's new direction. Read the releases, consider the potential and get on CAON firs thing Thursday! The accessory line includes the ClearTouch Anti-Glare Screen Protector, which the company claims will allow you to view the iPhone's screen in sunlight and other outdoor conditions. Your government puts people in jail on the merest suspicion, refusing them lawyers, and either holding them indefinitely or deporting them in the dead of night. Go to the poll and weigh in. These strikes do not make for a sound foreign policy. But if you are trying to lose weight, this outstanding resource is invaluable. com Technorati Tags: article, copywritting, blog, blogging, headline, John Hocking, blogging-resources. Planned Parenthood offers unique content, which we think can be risky, but it begs the question of how profitable an MVNO must be to be successful. com Technorati Tags: article, copywritting, blog, blogging, headline, John Hocking, blogging-resources. comIf you are working at losing weight or just trying to learn more about nutrition in your diet, Fitday's free Diet Journal is a great tool. Amp'd's problem wasn't its lack of customers. Innocent MOVE family members have been kept in prison all these years despite the evidence, despite the facts and despite legal appeals. However, chatting on the Wing wasn't always perfect. There is not going to be some savior from the Democratic Party. After a few tries with similar results, I rarely even bothered to browse the Web on the Wing. " probably not happening. What if it was easy to set up? com Technorati Tags: blog, blogging, blogging tips, John Hocking, blogging-resources. com Technorati Tags: article, copywritting, blog, blogging, headline, John Hocking, blogging-resources. No anti-Bush progressive has made common cause with Al Qaeda, Hamas, the Islamic Movement of Uzbekistan or any other officially designated "terrorist" group. Cholesterol QuizLow Cholesterol DietCholesterol Podcast What's HotRunning For BeginnersWhat Is Running? There is no escaping it: the whole disastrous course of this Bush regime must be STOPPED. "Gas prices can only go up. This is a "bit" and not a regular weblog entry The universe, expanding beyond all understanding. Still, we worry that the company hasn't fulfilled its original mandate. So, is this really all that surprising? Plus, they have the bonus of a pleasurable shopping experience. Worst case, I have another couple of weeks to give a substantive response to their original e-mail. While the reception never affected the call quality, which was always solid and clear, it played a big part in Web browsing. Instead, the MVNO has taken great pains in creating its own unique phones. fascism in utah, who knew? Where to get buttons for your browser to submit your pages to all the leading buzz sites like Netscape, StumbleUpon, Reddit and dozens more! Maybe you have more than one. Before You Buy A Treadmill. This is a "bit" and not a regular weblog entry The wild risks, unexpected niches, and day-in-day-out grind behind making a dollar in New York. com Technorati Tags: wordpress, server, usb, installation, blog, blogs, blogging-resources. The iPhone FlexiSkin is also available in the accessory suite and is made from anti-static material, which will protect the phone from dust and the occasional bump. Raise money, lots of money. Your government puts people in jail on the merest suspicion, refusing them lawyers, and either holding them indefinitely or deporting them in the dead of night. There are plenty of times I don't do something, even though I know I should and that leads me to my next question - why do you think there's such a gap between intentions and actual behavior? Your government is moving each day closer to a theocracy, where a narrow and hateful brand of Christian fundamentalism will rule. While I appreciated the smartphone's touch screen, a few of my pals were less enthusiastic when they were accidentally redialed while the phone was in my purse. We think Helio should focus instead on bringing more handsets from South Korea to the U. Each page of your store will target different keywords. Choose your target market. Helio's pricing plan, which offers just about every service except calling in unlimited doses, is innovative, and the MVNO was one of the first companies to offer unlimited messaging. If you agree with this statement, add your name to it! So, whether you have a blog for fun or profit, this newly-developed system deserves your attention. According to Teleflip, the only flipMail requirement is that your phone supports SMS; you don't need to have a WAP browser or support Brew or Java apps to use the service. Who among us can say NO to having our incomes supplemented? here's a link to the video of a rave getting raided in utah. From pana-bounces@ietf.org Thu Jun 14 15:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvKY-0002iA-TL; Thu, 14 Jun 2007 15:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvKU-0002h5-IB; Thu, 14 Jun 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyvKU-0002WH-9d; Thu, 14 Jun 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 43D3032936; Thu, 14 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyvKU-0007aw-5d; Thu, 14 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pana@ietf.org Subject: [Pana] I-D ACTION:draft-ietf-pana-pana-16.txt X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : Protocol for Carrying Authentication for Network Access (PANA) Author(s) : D. Forsberg, et al. Filename : draft-ietf-pana-pana-16.txt Pages : 49 Date : 2007-6-14 This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP- based EAP lower layer that runs between the EAP peer and the EAP authenticator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pana-pana-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pana-pana-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-14144752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-pana-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-pana-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-14144752.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana --NextPart-- From pana-bounces@ietf.org Thu Jun 14 15:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvL5-0003QB-Nj; Thu, 14 Jun 2007 15:50:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvKz-0003FG-Qk; Thu, 14 Jun 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyvKy-0002zW-HN; Thu, 14 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 703522AC8A; Thu, 14 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyvKU-0007b2-6x; Thu, 14 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: pana@ietf.org Subject: [Pana] I-D ACTION:draft-ietf-pana-framework-09.txt X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : Protocol for Carrying Authentication for Network Access (PANA) Framework Author(s) : P. Jayaraman, et al. Filename : draft-ietf-pana-framework-09.txt Pages : 17 Date : 2007-6-14 This document defines the general PANA framework functional elements, high-level call flow, and deployment environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pana-framework-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pana-framework-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-14144940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-framework-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-framework-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-14144940.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana --NextPart-- From pana-bounces@ietf.org Thu Jun 14 17:30:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywtE-00087Z-7X; Thu, 14 Jun 2007 17:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywtC-00087Q-PV for pana@ietf.org; Thu, 14 Jun 2007 17:29:58 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HywtB-0000X2-G8 for pana@ietf.org; Thu, 14 Jun 2007 17:29:58 -0400 Received: from [88.233.33.160] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1Hywt50VSL-0001fB; Thu, 14 Jun 2007 17:29:57 -0400 From: "Alper Yegin" To: Date: Fri, 15 Jun 2007 00:29:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceuyyJ7Jauzx82TQjiqYUEbSFmxOw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-ID: <0MKpCa-1Hywt50VSL-0001fB@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19YmZDlWMh4AoIvc2S3gUCuofZnEbLEEckc8m3 dC5MYU/AXpc+SMLpZGNp6/uh+RQy0t6fcDxbIbxKVaNlgwjrBO EMLgp/WHFHOwSp1muDB0Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: jari.arkko@piuha.net, 'Basavaraj Patil' , pana@ietf.org Subject: [Pana] PANA WG I-Ds revised X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Mark, The I-Ds are revised based on the IETf LC feedback. Here they are: http://ietf.org/internet-drafts/draft-ietf-pana-framework-09.txt http://ietf.org/internet-drafts/draft-ietf-pana-pana-16.txt These are the versions to be used for IESG review. Thanks. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 15 19:01:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKna-0002mP-JC; Fri, 15 Jun 2007 19:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKnZ-0002je-FF; Fri, 15 Jun 2007 19:01:45 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzKnW-0002ca-IJ; Fri, 15 Jun 2007 19:01:45 -0400 Received: from [88.233.33.160] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1HzKnK1oUQ-0001e6; Fri, 15 Jun 2007 19:01:38 -0400 From: "Alper Yegin" To: "'Spencer Dawkins'" Date: Sat, 16 Jun 2007 02:01:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aceu/iITqYBWJwhQSFeqQGufG/bgOQAnfkTQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <136201c7aefd$bd295530$6901a8c0@china.huawei.com> Message-ID: <0MKpCa-1HzKnK1oUQ-0001e6@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+JyDGrJCeBdzdu0zBDXog2QoIAxtTc+EC/PFY HCOSXdV4HTewI6Z3dTcFnJ0H+TQ43ecp0UbYCb6K3eXyZYwCDV 0eK7AZq1hCq/TpxZG0bNQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Cc: 'Mark Townsley' , 'General Area Review Team' , 'Jari Arkko' , pana@ietf.org Subject: [Pana] RE: Gen-ART Review of draft-ietf-pana-pana-15 X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Spencer, Thank you again for helping us improve the document. Please see below for my notes. We had already revised the documents based on IETF LC comments and got on the IESG agenda for the next week's call. Sorry, I wasn't aware of your ongoing review and but I should have thought. No problem though. We'll revise the document one more time based on your feedback ASAP. Please see below and let us know. > Summary: This document is almost ready for publication as a Proposed > Standard. I do have some questions, but almost all involve either > clarifications beyond nits or 2119 language. In general, this document is > well-written, clean, and accessible for a non-specialist to understand. > > Comments > > OBTW, Alper's e-mail address seems to have changed since the draft was > submitted... Already taken care of on version 16. > > 2. Terminology > > Enforcement Point (EP): > > A node on the access network where per-packet enforcement policies > (i.e., filters) are applied on the inbound and outbound traffic of > access devices. The EP and the PAA may be co-located. EPs should > prevent data traffic from and to any unauthorized client unless > it's either PANA or one of the other allowed traffic types (e.g., > > Spencer (nit): c/it's/that data traffic is/ OK. > > ARP, IPv6 neighbor discovery, DHCP, etc.) > > 4.1. Authentication and Authorization Phase > > The PAA SHOULD limit the rate it processes incoming PANA-Client- > Initiation messages to provide robustness against denial-of service > (DoS) attacks. Details of rate limiting are outside the scope of > this specification. > > Spencer: Two concerns here - why is this a SHOULD, instead of a MUST (why > would you NOT do this?), but more importantly, I'm not sure how you > normatively require PAAs to do something that isn't described (how would > you > know if the PAA is not doing this?) You are right. It is meant to be a recommendation. Would we say "It is recommended that the PAA limits the rate ...."? > Actually, I'm also not entirely sure > how > this would provide robustness against denial-of-service attacks, either, > now > that I'm thinking of it (I tend to visualize DoS attacks as "packet > spraying", and DDoS botnets are certainly capable of overrunning almost > any > single receiver. You are right that it is not a 100% protection. But we thought it can help to some extent. > > If the PAA wants to stay stateless in response to a > PANA-Client-Initiation message, it SHOULD NOT include an EAP-Payload > AVP in the initial PANA-Auth-Request message, and it SHOULD NOT re- > > Spencer: both of these SHOULDs seem odd - aren't you just saying "if you > want to be stateless, here's how that works"? instead of normative > language... > Is using lower-case "should" sufficient? > transmit the message on a timer. For this reason, the PaC MUST > retransmit the PANA-Client-Initiation message until it receives the > second PANA-Auth-Request message (not a retransmission of the initial > one) from the PAA. > > It is possible that both the PAA and the PaC initiate the PANA > session at the same time, i.e., the PAA unsolicitedly sends the > initial PANA-Auth-Request message while the PaC sends a > PANA-Client-Initiation message. To resolve the race condition, the > PAA SHOULD silently discard the PANA-Client-Initiation message > > Spencer: this SHOULD seems odd. Why not a MUST - simply because you could > process the PANA-Client-Initiation message and end up with at least one > SA? > Or is there something else going on? I think MUST is fine. I don't remember intentionally making that a "SHOULD" instead of a "MUST." > > received from the PaC after it has sent the initial PANA-Auth-Request > message. The PAA uses the source IP address and the source port > number of the PANA-Client-Initiation message to identify the PaC > among multiple PANA-Client-Initiation messages sent from different > PaCs. > > 4.2. Access Phase > > Once the authentication and authorization phase successfully > completes, the PaC gains access to the network and can send and > receive IP data traffic through the EP(s) and the PANA session enters > the access phase. In this phase, PANA-Notification-Request and > PANA-Notification-Answer messages with 'P' (Ping) bit set (ping > request and ping answer messages, respectively) can be used for > testing the liveness of the PANA session on the PANA peer. Both the > PaC and the PAA are allowed to send a ping request to the > communicating peer whenever they need to make sure the availability > > Spencer (nit): /need to make sure/need to ensure/ OK. > > of the session on the peer and expect the peer to return a ping > answer message. The ping request and answer messages MUST be > protected with an AUTH AVP when a PANA SA is available. A ping > request MUST NOT be sent in the authentication and authorization > phase, re-authentication phase and termination phase. > > 4.3. Re-authentication Phase > > When the PaC initiates re-authentication, it sends a > PANA-Notification-Request message with 'A' bit set (a > > Spencer (nit): there are places in the text where the bit identifier is > immediately expanded, and places where it is not, but I'm not sure from > this > sentence whether the 'A' bit determines whether the message is a > re-authentication request message or not. If this could be a bit clearer, > that would be great. If you make sure that all the bit identifiers are > expanded, that would be great, too. I find the format "the 'R' (Request) > bit" to be the most usable format for the expansion. OK. We'll do that across the document. > > re-authentication request message) to the PAA. This message MUST > contain the session identifier assigned to the session being > re-authenticated. If the PAA already has an established PANA session > for the PaC with the matching session identifier, it MUST first > respond with a PANA-Notification-Answer message with 'A' bit set (a > re-authentication answer message), followed by a PANA-Auth-Request > message that starts a new EAP authentication. If the PAA cannot > identify the session, it MUST silently discard the message. The > first PANA-Auth-Request and PANA-Auth-Answer messages in the > re-authentication phase MUST have 'S' bit cleared and carry a Nonce > AVP. > > 6.2. PANA Message Header > > Message Type > > The Message Type field is two octets, and is used in order to > communicate the message type with the message. The 16-bit address > > Spencer: message type space? This isn't an address, is it? I think we can say "Message Type allocation is managed by IANA [ianaweb]." > > space is managed by IANA [ianaweb]. > > 7. PANA Messages > > Every PANA message defined MUST include a corresponding ABNF > > Spencer: this is probably not a 2119 MUST, I think. > I agree. We should use "must." > [RFC2234] specification, which is used to define the AVPs that MUST > or MAY be present. The following format is used in the definition: > > Spencer: This shouldn't be 2119 language. Aren't you saying "define the > AVPs > for that PANA message type, and whether or not each AVP is Mandatory", or > something like that? Yes, that's better. > > 8.5. Nonce AVP > > The length of the nonces are determined based on the available > pseudo-random functions (PRFs) and the degree of trust placed into > the two PaC and the PAA to compute random values. The length of the I just noticed the "two" above. I think it's extra. > random value for the nonce is determined whether > > Spencer (nit): determined in one of two ways, depending on whether OK. > > 1. The PaC and the PAA each are likely to be able to compute a > random nonce (according to [RFC4086]). The length of the nonce > has to be 1/2 the length of the PRF key (e.g., 10 octets in the > case of HMAC-SHA1). > > 2. The PaC and the PAA each are not trusted with regard to the > computation of a random nonce (according to [RFC4086]). The > length of the nonce has to have the full length of the PRF key > (e.g., 20 octets in the case of HMAC-SHA1). > > 8.6. Result-Code AVP > > PANA_AUTHENTICATION_REJECTED 1 > > Authentication has failed. When this error is returned, it is > assumed that authorization is automatically failed. > > Spencer: this is not entirely clear to me. Is it saying "the requestor can > assume that authorization has also failed"? Yes, that's what we meant to say. > which still seems odd to me - > if > you're not the entity you claim to be, how could this not be true? Mumble. Yes, it is always true that if the authentication fails, the client cannot be authorized for the service. But see, the reverse is not true. Even if the authentication succeeds, the authorization may fail for various reasons (e.g., joe is not allowed to access the corporate network on the weekends). > > 9. Retransmission Timers > > RT for each subsequent message transmission is based on the previous > > Spencer: is this "message retransmission"? If so, that might be clearer. OK, we shall say so. > > value of RT: > > RT = 2*RTprev + RAND*RTprev > > 10.2. PANA Message Header > > As defined in Section 6.2, the PANA message header contains two > > Spencer: this sentence just LOOKS wrong ("two", but looks like three > fields) - if it's off by one, that's a nit, but if it's not, it's more > than > a nit... Yes, iana review caught that as well. > > fields that requires IANA namespace management; the Version, Message > Type and Flags fields. > > 10.2.2. Message Type > > The Message Type namespace is used to identify PANA messages. Values > 0-65,519 are for permanent, standard message types, allocated by IETF > Consensus [IANA]. This document defines the Message Types 1-4. See > Section 7.1 through Section 7.7 for the assignment of the namespace > in this specification. > > The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) are > > Spencer: is this two values, or a range of values? I'm confused by "and" > versus "-". Shouldn't these two clauses match? True. We shall use "-" for both. > > reserved for experimental messages. As these codes are only for > experimental and testing purposes, no guarantee is made for > interoperability between the communicating PaC and PAA using > experimental commands, as outlined in [IANA-EXP]. > > 10.3.1. AVP Code > > AVPs may be allocated following Designated Expert with Specification > > Spencer: is this "Designated Expert Review"? Not sure if this is a nit or > not... Yes, I think it should be " Designated Expert Review." > > Required [IANA] or Standards Action. AVPs with 'M' bit set MUST be > allocated by Standards Action. > > 11. Security Considerations > > An important element in assessing security of PANA design and > deployment in a network is the presence of lower-layer (physical and > link-layer) security. In the context of this document, lower-layers > are said to be secure if they can prevent eavesdropping and spoofing > of packets. Examples of such networks are physically-secured DSL > networks and 3GPP2 networks with cryptographically-secured cdma2000 > link-layer. In these examples, the lower-layer security is enabled > even before running the first PANA-based authentication. In the > absence of such a pre-established secure channel, one needs to be > created in conjunction with PANA using a link-layer or network-layer > cryptographic mechanism (e.g., IPsec). > > Spencer: is this saying that you expect people to be able to set up an SA > before they start doing PANA? Does that seem realistic? There are such networks where some kind of lower-layer security exists even before L3 authentication. For example, in cdma2K networks, L2 is already ciphered. Nevertheless, the mobile terminal is expected to get authenticated and authorized for the L3 services separately. And in DSL networks, there is already some level of physical security prior to running the L3 access authentication. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sat Jun 16 05:34:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzUgD-0004JE-72; Sat, 16 Jun 2007 05:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzUgB-0004Is-6I; Sat, 16 Jun 2007 05:34:47 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzUgA-0005io-Nv; Sat, 16 Jun 2007 05:34:47 -0400 Received: from [88.233.33.160] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1HzUg21E4L-0002rX; Sat, 16 Jun 2007 05:34:46 -0400 From: "Alper Yegin" To: "'Spencer Dawkins'" Date: Sat, 16 Jun 2007 12:34:33 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcevzZLVd5+kLu5zQZ2EblvPFuXDggAKdUFw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <164501c7afcd$46f9f010$6901a8c0@china.huawei.com> Message-ID: <0MKp8S-1HzUg21E4L-0002rX@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18c4RSCjVySdRcYXordN7ZL3Y0+kIWfloiF87r i2AbYjuzhZTnzL1u9BwgrfQpIgkNwQNPXx/GHwuYfLKrScBMN+ B2D/Q4RzbyAtXQB7b4MBA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: 'Mark Townsley' , 'General Area Review Team' , 'Jari Arkko' , pana@ietf.org Subject: [Pana] RE: Gen-ART Review of draft-ietf-pana-pana-15 X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Spencer, Mark said if we can revise the spec by Monday, he can pass the revision to the IESG. Otherwise I guess either we miss this IESG call or do your revision along with IESG one... > >> 4.1. Authentication and Authorization Phase > >> > >> The PAA SHOULD limit the rate it processes incoming PANA-Client- > >> Initiation messages to provide robustness against denial-of service > >> (DoS) attacks. Details of rate limiting are outside the scope of > >> this specification. > >> > >> Spencer: Two concerns here - why is this a SHOULD, instead of a MUST > (why > >> would you NOT do this?), but more importantly, I'm not sure how you > >> normatively require PAAs to do something that isn't described (how > would > >> you > >> know if the PAA is not doing this?) > > > > You are right. It is meant to be a recommendation. Would we say "It is > > recommended that the PAA limits the rate ...."? > > This is actually a good TSV question, but what *I* was thinking was that > "rate limiting" is often described in more specific terms (like not > sending > errors more than once per second, etc.). If there's a rate you have in > mind, > it would be helpful for implementers to know that. Sorry, I have no specific recommendation. This is merely saying "remember to use rate limiting." If you think this is not worth saying because it is obvious and in the absence of any specific guidance not that useful, we can remove it. I'd not have any issues with that. If we cannot decide now, let's take it to IESG review and decide there. > >> If the PAA wants to stay stateless in response to a > >> PANA-Client-Initiation message, it SHOULD NOT include an EAP-Payload > >> AVP in the initial PANA-Auth-Request message, and it SHOULD NOT re- > >> > >> Spencer: both of these SHOULDs seem odd - aren't you just saying "if > you > >> want to be stateless, here's how that works"? instead of normative > >> language... > >> > > > > Is using lower-case "should" sufficient? > > I still think you're simply defining stateless operation. I'm thinking > "doesn't include"/"doesn't". Does that make sense? That's better. > > >> 7. PANA Messages > >> > >> Every PANA message defined MUST include a corresponding ABNF > >> > >> Spencer: this is probably not a 2119 MUST, I think. > >> > > I agree. We should use "must." > > I'm thinking something like "PANA message definitions include a > corresponding ..." - sometimes it's just a definition, not so much a > requirement or command. Certainly better! > > >> 8.6. Result-Code AVP > >> > >> PANA_AUTHENTICATION_REJECTED 1 > >> > >> Authentication has failed. When this error is returned, it is > >> assumed that authorization is automatically failed. > >> > >> Spencer: this is not entirely clear to me. Is it saying "the requestor > >> can > >> assume that authorization has also failed"? > > > > Yes, that's what we meant to say. > > > >> which still seems odd to me - > >> if > >> you're not the entity you claim to be, how could this not be true? > >> Mumble. > > > > Yes, it is always true that if the authentication fails, the client > cannot > > be authorized for the service. > > > > But see, the reverse is not true. Even if the authentication succeeds, > the > > authorization may fail for various reasons (e.g., joe is not allowed to > > access the corporate network on the weekends). > > That makes perfect sense to me. The text seems to be saying "well, the > authentication failed, but just in case, we checked authentication, too" - > that's what confused me. You mean "we checked authorization"? The latter is "authorization." How about: PANA_AUTHENTICATION_REJECTED 1 Authentication has failed. When authentication fails, authorization is automatically considered to have failed. Sorry, I couldn't come up with anything better... > > > >> 10.2.2. Message Type > >> > >> The Message Type namespace is used to identify PANA messages. > Values > >> 0-65,519 are for permanent, standard message types, allocated by > IETF > >> Consensus [IANA]. This document defines the Message Types 1-4. See > >> Section 7.1 through Section 7.7 for the assignment of the namespace > >> in this specification. > >> > >> The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) > are > >> > >> Spencer: is this two values, or a range of values? I'm confused by > "and" > >> versus "-". Shouldn't these two clauses match? > > > > True. We shall use "-" for both. > > Now that I know what the sentence is saying, I'd even suggest "The range > of > values ...", just so it's blindingly clear. Good idea. > > > >> 11. Security Considerations > >> > >> An important element in assessing security of PANA design and > >> deployment in a network is the presence of lower-layer (physical and > >> link-layer) security. In the context of this document, lower-layers > >> are said to be secure if they can prevent eavesdropping and spoofing > >> of packets. Examples of such networks are physically-secured DSL > >> networks and 3GPP2 networks with cryptographically-secured cdma2000 > >> link-layer. In these examples, the lower-layer security is enabled > >> even before running the first PANA-based authentication. In the > >> absence of such a pre-established secure channel, one needs to be > >> created in conjunction with PANA using a link-layer or network-layer > >> cryptographic mechanism (e.g., IPsec). > >> > >> Spencer: is this saying that you expect people to be able to set up an > SA > >> before they start doing PANA? Does that seem realistic? > > > > There are such networks where some kind of lower-layer security exists > > even > > before L3 authentication. For example, in cdma2K networks, L2 is already > > ciphered. Nevertheless, the mobile terminal is expected to get > > authenticated > > and authorized for the L3 services separately. And in DSL networks, > there > > is > > already some level of physical security prior to running the L3 access > > authentication. > > Yeah, I understood the L2 cases - sorry for not being clearer. What I was > trying to ask was about people really setting up *IPsec* SAs before doing > PANA. I cannot point at a concrete case like the L2 ones. I can only say we don't prevent such scenarios. > Thanks for the quick response, and again, I'm sorry my review was later > than > it should have been. See you in Chicago? Not a problem at all! See you in Chicago. Alper > > Spencer > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From ext@telefonica.net Sat Jun 16 12:17:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaxY-0004pm-1t for pana-archive@lists.ietf.org; Sat, 16 Jun 2007 12:17:08 -0400 Received: from [190.65.205.143] (helo=llqydqg) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzaxU-0006MT-Hm for pana-archive@lists.ietf.org; Sat, 16 Jun 2007 12:17:08 -0400 Received: from qou ([52.192.182.217]) by llqydqg with Microsoft SMTPSVC(5.0.2195.6713); Sat, 16 Jun 2007 11:14:15 -0500 Message-ID: <46740C57.1070300@telefonica.net> Date: Sat, 16 Jun 2007 11:14:15 -0500 From: Fletcher Brian User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: backside butterfingers Content-Type: multipart/related; boundary="------------060808080101020305000802" X-Spam-Score: 3.0 (+++) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 --------------060808080101020305000802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit traumatize
FOR THE REST OF THE MORNING.
THEY WILL GENERALLY AFFECT AREAS SOUTHWEST OF A CLEVELAND.
PATCHES OF RAIN HAD MOVED INTO THE EXTREME SOUTHWESTERN VALLEY EARLY THIS MORNING AND RAIN IS EXPECTED TO MOVE NORTH AND EASTWARD INCREASING TO SPREAD OVER THE ENTIRE VALLEY BY AFTERNOON.
LIGHT WINDS OVER THE AREA THIS MORNING. LOWER CLOUDS NEAR THE MOUNTAINS. CLOUDY SKIES WITH RAIN SPREADING OVER THE DELTA AND CONTINUING THROUGH THE MORNING.
FOR THE REST OF THE MORNING.
MORE RAIN THIS MORNING.
EXPECT CLOUDY SKIES WITH LIGHT RAIN AND AREAS OF PATCHY FOG. This file is usually updated about every two minutes. AS WELL AS RAIN AMOUNTS FROM A TRACE TO LESS THAN A TENTH OF INCH. OVERALL COVERAGE WILL BE LOW. LOW STRATUS CLOUDS FROM KING SALMON SOUTH TO WEST THIS MORNING WITH AREAS OF FOG REDUCING THE VISIBILITY ONE HALF OR LESS AT TIMES. OTHERWISE MOSTLY CLOUDY SKIES.
MORE RAIN THIS MORNING. LIGHT WINDS OVER THE AREA THIS MORNING.
MOSTLY CLOUDY SKIES WITH ISOLATED SHOWERS ENDING THIS MORNING. LIGHT WINDS ELSEWHERE.
LIGHT WINDS ELSEWHERE.
OTHERWISE MOSTLY CLOUDY SKIES.
RAINFALL TOTALS WITH THIS ACTIVITY WILL BE INCONSEQUENTIAL.
LOW CLOUDS AND PATCHY FOG NEAR THE SHORE AND CROSS SOUND. LIGHT WINDS OVER THE AREA THIS MORNING. This same information is available in other file formats including the XML based RSS and CAP formats. MOSTLY CLOUDY SKIES WITH CLOUDS DIMINISHING THROUGH THE MORNING.
LIGHT WINDS ELSEWHERE.
AS WELL AS RAIN AMOUNTS FROM A TRACE TO LESS THAN A TENTH OF INCH.
MORE RAIN CONTINUES TO MOVE ASHORE FROM NORTON SOUND ONTO THE SEWARD PENINSULA COAST. OTHERWISE MOSTLY CLOUDY SKIES.
FOR THE REST OF THE MORNING. CLOUDS DIMINISHING THROUGH THE MORNING. This file is usually updated about every two minutes. LOW CLOUDS AND PATCHY FOG NEAR THE SHORE. PATCHES OF RAIN HAD MOVED INTO THE EXTREME SOUTHWESTERN VALLEY EARLY THIS MORNING AND RAIN IS EXPECTED TO MOVE NORTH AND EASTWARD INCREASING TO SPREAD OVER THE ENTIRE VALLEY BY AFTERNOON. MOSTLY CLOUDY SKIES WITH THIN UPPER LEVEL CLOUDS.
--------------060808080101020305000802 Content-Type: image/gif; name="crayfish.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="crayfish.gif" R0lGODdhKgK+APUAAP///0Y5xBBaWF14swx3Ujs+U4VOay90f5BbMqhALwK4BomEpTVTGRpeQKFZ bI6OwHiDP3FQH51mWmZJO5RGRqSGJRW3JTqRmUxzIgGeLBN+A1ueLDtGMCWeYUN8WXKYh3xka0C6 I2E2KNVETn08PTU2pgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAKQK9AAAG/0CAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL jI2Oj5CRWQwaFhAQIUQZBJJWIp2gkQyjo3ClRZmhWSMkDACur6SwsQwKISBECgpNIr2fe6RXvmcU qsZisqdtykO4x1UcDBQJEbDJs66uu0O620m+vWMe4FPJVeQA4NFD5koKGxIA3UUeRuFF00izWOC/ VPtrNLyTsGEMQIPsmHRTkCGDEAH17qUbBmAdtSLBDnp7JsVfAgQJhWBjJsSCPCUS/TGI8DGkFQHo wknUN5LKr5v9hiCQtYSSSf8IFrxlECDAnj92EfRhDBal36dwLEE2OQjl6D+fELTs5EmLpBFdAIYW FZKzp8uuQy4FnQeAKDmnE1e2FNmOCFWOvHpx4GDXJVMiuDbaO6KXQ75rdrkuOQo3CcBskJ1QTEfE X7EnlABscCaEIafBRvgu3YdYXsENgkFT9rX3clfSfzWDQF2EgEyy6Krsow3WNk5/6AxTq2ZNsUiB BeV124Q7t2PFpd/NZgvANlnKQ3AKcV0TI16bvkb+zWbEUtZv2WWGT0qhbunFRe5Z9d73/eKZuJEm cK2EVKWvhAU4Wl8hYQUUStnlR0R77o1XiVrcKBCTc+UQodZC8mX4llz7YXP/hCz/ARBUfGUpwSBs ij0IlEmdJcjYdSKdddBd3z3hEXEEvsJOJRucJ+BET6kjRAIf1oVgZQkmkRSBp9CIJHZPktUakWa5 ogGAqkVJX4x+XQmAj4TFZAR/Om45Co8+epOSFgD12GKG6cW0l3BnneUlmHHid8RlypS2zyXcuPgk cENQGUuN/BAqxJLrvFaclZYgsSaURCxphJHoRTkfEfuxY02dkk6moBGWOqajRj9quWCOZbbKYqiT stqqX/69+mp8bBbhpYgwMpaTVZZ6yCWXt8JorKQrCdEoVSBa8KqEw8AV7T0sURANSU4iatSEsFTj KF3ZCPTNhGIOsSRpvFSm/96mOo2A47DZNpfli2YNqxlB+G3KrlTgjjfErqkCGeuil4IqRDxJQmmV nqbmiLBz8znlD3F91occwgIzrO7E/TZpnGaTkQskOwiMcKis2iIYskSGCjNTWaxFwCemRkAgsqhH yGxoRl5JOm+JNEE2y4Mp5Qa0XjJ72mcpsW28cdFIk9nqe5YYTaHGo3kM6Xn5/go0ANSgyLNPebLr BM1FVJ3y2ttO/PER0GIdxdiSZSkwE3SjZLWoQj4nNKx54WyvkXGTGLHZiTHF8zZ6fo1Z06ZIyPbk lKdMcbyVZ6755pzrBnnnoIcu+uikl2766ainrvrqrLfu+uuwxy777LTXbv/77bjnrvvuvPfu++/A By/88MQXb/zxyCev/PLMN+/889BHL/301Fdv/fXYZ6/99tx37/334Icv/vjkl2/++einz8gB7ANw ABvsv6/+/L0rYEEH8a8Rf/tbNEAUUfQL4OQcIgT+JeFaE9gCQ4bQvvwt4AGemoADmjABDvhvLALM YI0EQADquK+BQnjAAjwwigQCwAHFEJxCivC+/R1gABAcYQkNcDYiABCAncGf+zTIw0YQJQNg+eD+ hLAAAjngiCRICQKOuAQMFpCB8nvfAx7wgWs5YYJD+N//wqKLDOiwh2BkxDY6AMUnDqEeQjAAFtMD gQpIYI1HcCIAyGjGHcL/UIQkvGIRcFgUDCqAjmEMpCBwWJ0WGUF+IQRVEgcAggrwK45+9AYiWziF RwKgAFlsiyA3WYjSJMeQBCCKB0BAgoQ1YwDT8FZ/zsSiDaBmF54RJSkRJysP7YaTuOTD34SgohEJ QSwYLBHGzqaMSxxoHv8DgdRINQIGgctRZ8pFanJJzTpcbAlJnMwIRiCCaFjyDN501zPH1qZpVvOc iEhAeAgBAc6g853wjKc850nPetrznvjMpz73yc/MJWNXtOmnQCnXIMUAaqAIfcYwRHM5W7ZKOgmN KCgaAwDuKM07xZKoRhcBHMvQ6jEAANhGR4oIoMnFWgl5TM9IylJBlKgX/wx4pLDQ1tKaBkJRHFhS Q2nBU5v6tA+Tokg3wXY5nn7up0idQ2NCltSmFiJItHSqVKdK1apa9apYzapWt8rVrlIvql4NKxqy aTiwivWsWECiryi0rcQY8AhIHBlF9UaatwIAjWi1pwn5Qy9Y3YMU+UOCBCdIVondhyKjCCwApujO vMqTAROgoZYQh1MiIPIIJgRAKY9FS0XNApF3dKw9SzjZvBzrsgUTwhr7qrejKHaHUxStPIs4K74y YWCopccQJJsxsIqqBAaMHwxlG88pVpEIcOwsa3NLBAgOywEkIKuNDglFuxK3mqElghpR+DJf9YoI JVCCc1sFx9smyR/htf+sda9LzQEYYbDl7a5Qe0GAhijhhcYVyWAlM6H6ErC67IUnc0P1tI4SMgn4 9dRebPSyAzMwwBCOsIQnTOEKW/jCGM6whjfM4Q57+MMgDrGIR0ziEpv4xChOsYpXzOIWu/jFMI6x jGdM4xrb+MY4zrHqgqgHswbCnI94xxGYk9eVbqE9UjjQFSiwTCjw2G6KyKgiZiTSzgDZCphjm+Pu QNMw9MwCblrIRMbcnE3lY5XMyIoHCTxmw6QyXlR5cpy8AGYIfJLB6RANALw1ntjU+c5Xuw2lqGBn 6pi1NXtmBrOQcOX84IdiiTMyNPSciC1zQV+TSVZFG/Wtw0Z1naZS9H//VrQLab0UKmj+i3mC0tHu OnoU1erJx0q91rLSkmkjUZGa1+XXe+znWo9yUKTKDLVpgVoKq2YcW0nkil8/M7VYau1kqmXFjt12 ZWRWlyO8K4Juaa1fRIDHBjRU7AyNomTB6jKxtTPfZVvbJRLAmHx6u+5UK0NcvTraec2KqXHjbK0q jLTWkHMaXrPZHyXb0qwMSW9jrSvgTgC0u5H0CX597i53HpfDWZXlpTruKO7a5U0LzJdUjrMdWCG3 ohzOMHU33OMTb1JiQuqshEFVqOmxt7C+a0pFyU3hFroJrsoWVZm/RgNeesqghw4lSg8O2hTVlxZE 6mOlO33RR8CTzzZe/yiUbZ3lxzqWzno6cm1jhwRU0priRgEtU3LW7TLydNFsbbadxwgghJI63HO0 tPOWlswD+xCj3b6wifvFXhRfuqbgjq4tsYtePq7X3n2mdK/fpdFcp9Rm4XWkzEesCHrOsh0WlrBz Ka3P0lh5zydvnz3lPOyKFzzim+a1cmW7SOa4xmVYa2rDTy1HrZ735PnesVOkMPbELnPoaTYLCpza 9sjHG9OVizOVxoYUzm/tyDJGaXXbNvOE54sqXTr97PgL2ie0eb0b/m4lqBXndA8a2RGv2ZW12/A8 O9Rf5jpmqOENOgxAWCq3fn7TU6XxftJWNpEme6qVTQBHdPGRZXjne/+rURkAeH2jwETjAlV5cimS dkLQ1W7bB3efIHp0ADMGl2cCF2xqpIBlBoFVcEQpdHMAxy55M38g2GSGc3su83PloGgMQEPctYE+ eINIMEE6OIJS4HIJSCL/FxsQdx/Vxgcy2GrbN1dRmAcoyIGj8m6YkoVjYGk/CBD7tTxg6DcmWBVF 9zabw3+Rp2M2dYZw+FNyOId2eId4mIct5oNrQ0KuwFt6mAVvyARJqIWDyBGMNQpOVwaxxTYoND4f GDBpZXbyFX0F9FoAIENpOGeH+AzuJQR5BADbpTATMoIUOFxisIh50IJbsA7r1QUUmIl+qFpY9HNW w4NwAAKquIFbQFr/RPcb8zWCDOBCQ/BAD6CLs+AABiBdd0OASNBAr6gF98A/QyQEyAhZ6RImP8c+ xkgXgyVZhgVzYChFxzgEEiQESTR8mfJB7AgY65BZRPg0cTKMSoCMAACPeJZtMPVaB9CN+nVE4Kgd /adytGSM9ghfy2g24siHaFBEvlhRXGiKQaIu4RWNs+g02NFRBCgCwKVY+IVHQhBZVbh+GnlfxLhY IJlGGnh/OTd3AABcQpQ/U6SJ18Y3YniJoYVXrEh6PMh/R8A+d0Rb2HhCuxeLk+FCiDSTF3lEE3R/ BJkx6VWNKEmTTaggrrZDl/iRdzVDtSiQC0lLl4VGkSVZOhh1QkcH/8ZVbe/Hky/XCwfQkUvgdMkF e11IFm/pkdzYiCXElCSpKj95WXlJRf+Ijg/3lMZSkcTYj2lZky/jl0lQROOFXEN3OBRoQOOVjMlX k+pVR4h0XPfIlCFIkrXnljFJjUPgmb32gFEySUQAmVX0kJtXkjCIYM1lL+VVYCvXiWGAiuR1m5x1 lv5AAOmlBLQ1BHNJKao3eaB1mQzAATsJM6+nBMOZldn1CqLxiOwnfFDCCR0ZWB9ZnJ33d8/ImpEJ C/EFe294WZ94V7uljl/3kg9WR6DnnPHXlr3gECXQnVHUmtLWNaoxnIAZQlSZfuBHl7Q5BM6FV6K4 jrGim2BwWR9gjv/rqDDH8l9JUJ77FZpRRxj+9ZbVJVyLRQQm5JuGdV8stD/rWSar9VLqVx0OkVuX FZkTunoIlph35JnwpaF7M46smUgnQ6BVoQnxiZU++qN7p5FHwQkZcJemKQS8qY022TX+NaQ7dFl6 hkXpiJ43WZrk+AER+pB0x4GxaAaWaTDQyXNt8RnjmV2KyBcy+IKZmUUcpABqKkTsOEXHeApV6H9y 00EEEABRmQQgoIhD0GS52QtE4aeACo0gal4sZ3iIOUnVWRHOuZIQ43v6aZmJaJ7umTBzCgCLmpVA 2QyNBZHkIjGIWkiHhKIyuiph0oWI6kSZ+kF3NF6VOoRHU5mBVav/ADCoNDItclWHY4CUn7gAGACm tResIrBFNTqqHTGmPxmUyKVWU/BDFhBFJ1mMGDCtDigv2AZAGXCtAdBCUolNl8qQbXAAAWCnRDBc xhqSTLl5RPgJWySuH4qgM3msyNWt3toY1qquABaNa/l6/mcE40qNjcoOCcREW8o2jIqgC2CPvDhf fVQ52SqgRSCDWWpsY0ABWRoKlRo46DoEF7AADxSxWpCoRBYFGvtpI1s9sSpHgehTsTqzNnuzOJuz OotiFsoRC4QGMntW0PU8QYsH4KkFckYGRRtWGigJShmJcsCsnfGiAXopZZgETFQAGPQ/ddoBgGQE rVoE6dhIyAUC/1o7ZDE4Qcv4sUvUtG0htUD0s1zgtplkZZjnqNOaBHUqiIzkSFcQjYJaAVYAjUXw mubJRIskBG1Lt1/BEF/bQOtpRb5pBEeEC3yUqETwtWKQqJwgSdX4kagJgngQGz3yStsQShDBGeBA AibTq+4VNsV3dEJgZ6ZrQ6O0MZsHAqgEu51GBFVmBLc7E6w7AhIAArq7KAVlDWhyZ5tQFHgVeT0z C2CWcVKguyZHFw2zBbv7LlSwspJIVFawHKE0BA4YDsPrusWwU0mwvEKBusHbsNcgNNH0JbXrZc0S IV30GfVQSkfBunoAEMO2DQwhtY1RvCvRTJ5yd+1gHkCxEQRcIv+Duh2xC3SQpEwTwBgtIwStS3+P 8iD4KxbbccEMaX2+eyUXMgTAtAQGHAEbfCooUjNrcbfQFmxZQwRrcRJ+lcEmA4SRGET/ZcE4ZzLO 0Exs6CkqkgsEVBSuUYQJ3GnJ5mlDULx71sIMaKTP8hACUKq9kMF0ABAAFShiWyLcNMO9m7R1q1lR ssFS0XoLhwQ4JK+b0nhM4h/e0L6gKAHMKHnPhr0DkRz562BGQMXtFxu6IG5mjLc7nLynYMiHnDEY gW7B9oGf5A0QgcfzVkpqHHJOQsd3Rsns2amlEsmzcLfl+wvb1E0xpXNFgDGnC8iVx2VbkiZGUKpD kjMp1cRGWgT/PxwlOyPB2EvBaGuNjnkUpcIld0HLmgQFxTw4/iFNXbS0tUwqn8JxWAECqdAUMMUe RTXBuxICV/Z4sDAzRZwWYJzMuPIJVELM/bEjuYDC5nzBTLAz04x+gsrLv5At9mEJ1izA5iwodoBy pYAcJeHObTFKzpecAIAAFxG/azcEGefJ+8aBCr3Nr7EEEJ2dMKXQqfUenXzGTsDFs/IxGxDDPasa HlEnVAZRz3oPE416ihNuJvJ1a6xuAj3S29C8qZuZ4aHRaDi/s2ESf5y62dcfLS3KLkG9Hp2bULAP yMEZF62EcwDQkOEl+8xjRAECeBynclERuBYZsisE3oxMV53V/8q6KAlAJEtzVB+MQZYcpVhX0byk AO3kzQTdq02wzCHt1bOrhtOG0jNXzsqRjeFwF90xyloHGDRaJiBNEyZszdyQwtcRfHCGa53RTsqx CyCM1XjDEhVxeuKRGW5MBLGpjopGIHINAGHdRc3Q1ocAIf3pOX/SwK0MEWUQw1WQAK0QiZQQAmCi C6h7WAywebn3bSHF2w2smbjRbK3ghfmMefcX3Ljt2V19JtdsBEJthcOAdrm9iYMAU2j3hO7gvs7A sUFzgbxk3Lb9tvVw0A4qPJdQ3VPAEhdRBartaXpWVGs3NOYB34GzZ2fN3B+DCci9Gt3E2Rf1baDt xlnsNBQh3//jJwmsoUDNS74pWDDG8Re/Gxbja7zRhT22gMw7G+IiPuIkXuImfuKIgNewiDjcPbEv i+KoIziLfWmIs4vgEZE/6Akw3gmXChvzByLwcc5HcW6CjHumoTe3B61QO6M7zlG5SsyK7CTPVzQ5 lcA83MzzCoFVPt8HflhK2N5Njgc+CSwzom6nhp7m4h64THkU6iLdhHbpdoHKQN4GGuYlNaMq7nKf h+ZNbHfZonSqJ5DB0ufvkZxgbud3oJDALMfvWaCUsnPdwaA0qhJxB00tyZaIzlFQihNT2LtfJ6aG GXrSrX1OeZZQUtj28cqZ/ghYeKpiEy/JWuojg3ptzODF1q9x94wY4qFdH9upq+4HPgkGwiovU8iE /BWR+cfQkgllvz4840wGihOhr3COzZ5PhFrt2J7t2r7t3N7t3v7t4B7u4j7u5F7u5n7u6J7u6r7u 7N7u7v7u8B7v8j7v9F7v9n7v+J7v+r7v/N7v/v7vAC9iQQAAOw== --------------060808080101020305000802-- From pana-bounces@ietf.org Sat Jun 16 15:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzeFH-0003Jt-53; Sat, 16 Jun 2007 15:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzeFF-0003JU-6n; Sat, 16 Jun 2007 15:47:37 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzeFE-0007b9-Q5; Sat, 16 Jun 2007 15:47:37 -0400 Received: from [88.233.33.160] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1HzeEz0eA5-0001dX; Sat, 16 Jun 2007 15:47:32 -0400 From: "Alper Yegin" To: "'Spencer Dawkins'" Date: Sat, 16 Jun 2007 22:47:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcewCOre554xbiSKTqyOfpPZvl8DvAAREfRw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <167a01c7b008$9ace5970$6901a8c0@china.huawei.com> Message-ID: <0MKpCa-1HzeEz0eA5-0001dX@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19OuJEW6vxf8DdwVUR3HH1Gg12p3/yTuYdo8tc 7nJErhTi8vK2TXoqqEbIdnu0J7eKhRtgEEt4NK69ddRDsS2lsY 1kiD0IocVKiLarCsekeoQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: 'General Area Review Team' , 'Tim Polk' , pana@ietf.org, 'Jari Arkko' , 'Mark Townsley' , 'Sam Hartman' Subject: [Pana] RE: Gen-ART Review of draft-ietf-pana-pana-15 X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Spencer, Thanks for the quick responses -- over the weekend! > > PANA_AUTHENTICATION_REJECTED 1 > > > > Authentication has failed. When authentication fails, > authorization > > is automatically considered to have failed. > > > > Sorry, I couldn't come up with anything better... > > I'm still struggling with "automatically" (this is a lot less technical > than > you think!). "is also considered to have failed" seems more accurate to me, > but this isn't a big deal. That sounds good. > > >> >> 11. Security Considerations > >> >> > >> >> An important element in assessing security of PANA design and > >> >> deployment in a network is the presence of lower-layer (physical > >> >> and > >> >> link-layer) security. In the context of this document, > >> >> lower-layers > >> >> are said to be secure if they can prevent eavesdropping and > >> >> spoofing > >> >> of packets. Examples of such networks are physically-secured DSL > >> >> networks and 3GPP2 networks with cryptographically-secured > cdma2000 > >> >> link-layer. In these examples, the lower-layer security is > enabled > >> >> even before running the first PANA-based authentication. In the > >> >> absence of such a pre-established secure channel, one needs to be > >> >> created in conjunction with PANA using a link-layer or > >> >> network-layer > >> >> cryptographic mechanism (e.g., IPsec). > >> >> > >> >> Spencer: is this saying that you expect people to be able to set up > an > >> SA > >> >> before they start doing PANA? Does that seem realistic? > >> > > >> > There are such networks where some kind of lower-layer security > exists > >> > even > >> > before L3 authentication. For example, in cdma2K networks, L2 is > >> > already > >> > ciphered. Nevertheless, the mobile terminal is expected to get > >> > authenticated > >> > and authorized for the L3 services separately. And in DSL networks, > >> there > >> > is > >> > already some level of physical security prior to running the L3 > access > >> > authentication. > >> > >> Yeah, I understood the L2 cases - sorry for not being clearer. What I > was > >> trying to ask was about people really setting up *IPsec* SAs before > doing > >> PANA. > > > > I cannot point at a concrete case like the L2 ones. > > I can only say we don't prevent such scenarios. > > Well, yeah, but that's like saying SIP doesn't prevent the use of IPsec, > either. There is a confusion here, and let's see if we can improve the document to prevent it. There is either a secure channel (against eaves-dropping and spoofing) prior to running PANA (as in cdma2K and DSL networks), or one has to be established after successful PANA authentication. IPsec is given as an example protocol to establish such channel after PANA. I think in your understanding IPsec was used even before PANA authentication. But that's not what the document says. If that's clear, then I'd propose a revision on the last sentence as: In the absence of such a pre-established secure channel prior to running PANA, one needs to be created after the successful PANA authentication using a link-layer or network-layer cryptographic mechanism (e.g., IPsec). Does this help? Alper > > I'm sorry that I'm not making myself clearer here. What I'm trying to say > is > that the L2 cases you cite make total sense to me, but if it was common to > set up IPsec SAa with arbitrary endpoints on the Internet, the world would > be a different place. The use of IPsec seems to imply that the PANA client > can easily have some ability to share a key (either symmetric or > asymmetric) > with the PAA. Maybe this is true, in the PANA case, but it's sure not that > easy in the general case - that's why I'm confused. > > As I'm typing this, I'm wondering if you would do better with a > recommendation that says basically > > "PANA clients typically know whether their first-hop is L2-secure or not. > If > the PANA client is using a first-hop link that is not L2-secure, the PANA > client SHOULD use IPsec to establish a security association before the > first > PANA-based authentication". > > If this sounds like a good idea, great; if it doesn't sound like a good > idea, I'd be more comfortable just dropping "or network-layer" and "(e.g., > IPsec)". But fortunately, you have two SEC ADs AND Russ who can tell me > that > I'm nuts, so you don't have to say it... and at least two of them have > demonstrated running code that they can tell me I'm nuts :-) > > And thanks again. I'll be scribing (silently - scribes don't talk) on this > IESG telechat and look forward to seeing this draft on the agenda. > > Spencer > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sun Jun 17 06:18:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzrqH-0004l2-Ea; Sun, 17 Jun 2007 06:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzrqF-0004kl-AN; Sun, 17 Jun 2007 06:18:43 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzrqE-0001y2-0M; Sun, 17 Jun 2007 06:18:43 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5HAIGjD051178; Sun, 17 Jun 2007 06:18:16 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1HzrkG-0000GX-3r; Sun, 17 Jun 2007 06:12:32 -0400 Date: Sun, 17 Jun 2007 06:12:32 -0400 To: Alper Yegin Subject: Re: [Pana] RE: Gen-ART Review of draft-ietf-pana-pana-15 Message-ID: <20070617101231.GB29634@steelhead.localdomain> References: <136201c7aefd$bd295530$6901a8c0@china.huawei.com> <0MKpCa-1HzKnK1oUQ-0001e6@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0MKpCa-1HzKnK1oUQ-0001e6@mrelay.perfora.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -2.4 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'Mark Townsley' , 'General Area Review Team' , pana@ietf.org, 'Jari Arkko' , 'Spencer Dawkins' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Sat, Jun 16, 2007 at 02:01:26AM +0300, Alper Yegin wrote: (snip) > > > > 8.6. Result-Code AVP > > > > PANA_AUTHENTICATION_REJECTED 1 > > > > Authentication has failed. When this error is returned, it is > > assumed that authorization is automatically failed. > > > > Spencer: this is not entirely clear to me. Is it saying "the requestor can > > assume that authorization has also failed"? > > Yes, that's what we meant to say. To be clearer, shouldn't "the requestor" read "the PaC"? This is because the PaC is the entity that receives Result-Code AVP. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From yrioh@3074.com Sun Jun 17 17:34:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I02O5-0004p6-5i for pana-archive@lists.ietf.org; Sun, 17 Jun 2007 17:34:21 -0400 Received: from [66.110.228.14] (helo=66-110-228-14-pppoe-d.northstate.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I02O2-00062E-Qu for pana-archive@lists.ietf.org; Sun, 17 Jun 2007 17:34:21 -0400 Received: from xlyt.rfsno ([79.96.224.27]) by 66-110-228-14-pppoe-d.northstate.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 17 Jun 2007 17:34:17 -0400 Message-ID: <003101c7b127$420bd0e0$1be0604f@xlyt.rfsno> From: "Theresa" To: Subject: Theresa sent you a udpiss.hk! Greeting Date: Sun, 17 Jun 2007 17:34:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Surprise! You've just received a udpiss.hk! Greeting from from "Theresa" (yrioh@3074.com)! To view this greeting card, click on the following Web address at anytime within the next 30 days. http://udpiss.hk/?713076a3db573383e1a7a85955ab65e8517a32e Enjoy! The udpiss.hk! Greetings Team From erng@nni.com Mon Jun 18 03:31:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Bi8-00089C-SO for pana-archive@lists.ietf.org; Mon, 18 Jun 2007 03:31:40 -0400 Received: from 90-154-179-120.btc-net.bg ([90.154.179.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0Bi8-00030k-6o for pana-archive@lists.ietf.org; Mon, 18 Jun 2007 03:31:40 -0400 Received: from lgpr ([87.46.199.228]) by 90-154-179-120.btc-net.bg with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Jun 2007 10:31:42 +0300 Message-ID: <467634DE.3060104@nni.com> Date: Mon, 18 Jun 2007 10:31:42 +0300 From: Juliana Valenzuela User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: Computer service from Comtec. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Word Is Out, Big News Monday! Score One Inc. SREA $0.20 UP 33.3% This week's news has already been pushing SREA up. Word is out a BIG news release is expected Monday! Keep your eyes open and get on SREA Monday! Oh well, it looked pretty cool, though. comCoffeeForLessRitzCameraBeyond BlossomsMyCenturyGymDesigner Linens OutletMagsForLessFogDogMountains Plus Outdoor GearEverything FurnitureValueMagsBagsbuy. Imagery Rehearsal Therapy Improves Sleep In InsomniacsUIC Investigates Eye Infections Tied To Contact Lens UseHow Can I Make My Child A Lunch To Take To School? Latest Headlines Kensington QuickSeek FM Transmitter ReviewThu Nekst Kiler Ap - Truespel? Have a Skype-certified mobile device but no appropriate USB cable handy? The player supports background action. Source: siliconvalleysleuth. The product makes an excellent plain text editor, too - so, editing non-html files is no problem either. Instant messengers are like the second mobile phone for kids and young adults. Oh well, it looked pretty cool, though. Painting process: see - the entire painting process - click here. Asbjorn Lonvig's Art Portals - International An art portal is a portal for one specific user or group of users, a country, a city, a municipality, a museum, a company etc. Art, design, storytelling, fairy tales by Asbjorn Lonvig. Visit TamsPalm and have fun! It shows and it has links to those art works that might be relevant to that specific user. The files are selected with a dialogue that works like the Windows Common Dialogue. DragonEdit can open remote files and can also upload via FTP - the notebook can really stay at home now. Kunst Portal logoet til venstre er Septimus Severus buen i Forum Romanum, Rom. Source: siliconvalleysleuth. E-shop Art Works for Sale and Prices Site map GalleryNews GalleriNyt Art Galley Support MyGalleries worldwide Merchandise Artistic concept. Source: VoIP Now What are your thoughts? The files are selected with a dialogue that works like the Windows Common Dialogue. Regardless, this page will refresh when your submission is entered. Have a Skype-certified mobile device but no appropriate USB cable handy? However do the mobile companies have a firm enough understanding that they are ready to start providing content in a store front just yet? Rumor - Red Hat Is Next To Sign Up With MicrosoftDell - Insiders View On How To Work The SystemDual Widescreens RockUbuntu Linux Just Plain Rocks! Regardless, this page will refresh when your submission is entered. Regardless, this page will refresh when your submission is entered. It shows and it has links to those art works that might be relevant to that specific user. Kunst Portal logoet til venstre er Septimus Severus buen i Forum Romanum, Rom. However do the mobile companies have a firm enough understanding that they are ready to start providing content in a store front just yet? The Holy Grail of Synchronization? Imagery Rehearsal Therapy Improves Sleep In InsomniacsUIC Investigates Eye Infections Tied To Contact Lens UseHow Can I Make My Child A Lunch To Take To School? Regular expression searching is a feature I never saw before on a PalmOS editor. Related Links T-Mobile USA adds street level coverage maps Tracking children: Mobile's next big thing? Oh well, it looked pretty cool, though. Rumor - Red Hat Is Next To Sign Up With MicrosoftDell - Insiders View On How To Work The SystemDual Widescreens RockUbuntu Linux Just Plain Rocks! Two Qubits In Action, New Step Towards The Quantum ComputerNano Technique Allows Precise Injection Of Living CellsHow Do I Paint Over Old Paint? Skype Blogs has a post about a reviewer who managed to transfer music files to a Sony Mylo media player and wireless Skype VoIP phone via file transfer. Cool stuff for your Sony PSP! Cool stuff for your Sony PSP! Painting process: see - the entire painting process - click here. Want to see DragonEdit? From pana-bounces@ietf.org Mon Jun 18 05:55:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dwx-0003tA-J7; Mon, 18 Jun 2007 05:55:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dwv-0003qR-Fq; Mon, 18 Jun 2007 05:55:05 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Dwu-00075R-2A; Mon, 18 Jun 2007 05:55:05 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 18 Jun 2007 02:55:00 -0700 X-IronPort-AV: i="4.16,434,1175497200"; d="scan'208"; a="163027430:sNHT12147576813" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5I9t0ua020584; Mon, 18 Jun 2007 02:55:00 -0700 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5I9sxaI018062; Mon, 18 Jun 2007 09:54:59 GMT Received: from [64.103.29.79] ([64.103.29.79]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id l5I9sv717127; Mon, 18 Jun 2007 02:54:57 -0700 (PDT) Message-ID: <46765668.7060005@cisco.com> Date: Mon, 18 Jun 2007 11:54:48 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Spencer Dawkins References: <0MKp8S-1HzUg21E4L-0002rX@mrelay.perfora.net> <167a01c7b008$9ace5970$6901a8c0@china.huawei.com> In-Reply-To: <167a01c7b008$9ace5970$6901a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1192; t=1182160500; x=1183024500; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20Gen-ART=20Review=20of=20draft-ietf-pana-pana-15 |Sender:=20; bh=VOg5HSp036JdGXj60iJNCdFvVlf09s0ul2bR8G9JC6Q=; b=uODJT/QEmbFePmi6oDju57VW668erYLUZl9LTRlcO1UbDaA33andB/bTi4Qhy+dvFevwWo5+ 4VAZs4Ks4riKYf8XKBBgF2B4rDjpQfAN1DlF4swSTMGzn3u4HNPGXlK1evkOgXisF/lgSoG8AD xb0T5NjHRE96skqLngC3gC+ZI=; Authentication-Results: sj-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Tim Polk , 'General Area Review Team' , pana@ietf.org, 'Jari Arkko' , Sam Hartman Subject: [Pana] Re: Gen-ART Review of draft-ietf-pana-pana-15 X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Spencer Dawkins wrote: > Hi, Alper, > > (adding the security ADs as a heads-up on the last item in this note, > just because we're less than a week away from the telechat date for > this document). > > >> Hi Spencer, >> >> Mark said if we can revise the spec by Monday, he can pass the >> revision to >> the IESG. Otherwise I guess either we miss this IESG call or do your >> revision along with IESG one... > > As long as you're talking to Mark, we're good. > > I think we're well within the range of what the IESG can do with RFC > Editor notes (as things turned out, I think my original review > comments could have been handled this way, although sending the RFC > Editor a clean draft is always less error-prone). Right, I prefer to get documents as close to finished before the IESG reads it, as well as before it goes to the RFC Editor. Editor's notes are not something I like to rely on for more than a few tweaks. Given the speed in which Spencer, Yoshi and Alper seemed to be operating here, I thought that a new version by today would be a reasonable goal to shoot for. I'll let the IESG know that the new version is out. Thanks, - Mark _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Jun 18 10:15:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0I1K-0004Ep-Nj; Mon, 18 Jun 2007 10:15:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0I1J-0004Eg-HI; Mon, 18 Jun 2007 10:15:53 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0I1I-0003Ey-Lq; Mon, 18 Jun 2007 10:15:53 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm174676d645; Mon, 18 Jun 2007 22:27:18 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm04671d9ca; Fri, 15 Jun 2007 04:27:05 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 15 Jun 2007 04:27:05 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvKX-0002hM-01; Thu, 14 Jun 2007 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvKU-0002h5-IB; Thu, 14 Jun 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyvKU-0002WH-9d; Thu, 14 Jun 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 43D3032936; Thu, 14 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyvKU-0007aw-5d; Thu, 14 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.2 (++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: pana@ietf.org Subject: [Pana] I-D ACTION:draft-ietf-pana-pana-16.txt X-BeenThere: pana@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : Protocol for Carrying Authentication for Network Access (PANA) Author(s) : D. Forsberg, et al. Filename : draft-ietf-pana-pana-16.txt Pages : 49 Date : 2007-6-14 This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP- based EAP lower layer that runs between the EAP peer and the EAP authenticator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pana-pana-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pana-pana-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-14144752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-pana-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-pana-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-14144752.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana --NextPart-- From pana-bounces@ietf.org Mon Jun 18 16:14:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Nc8-0005n6-Gh; Mon, 18 Jun 2007 16:14:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NFf-000717-Pz; Mon, 18 Jun 2007 15:51:05 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0NFf-0004lU-Fd; Mon, 18 Jun 2007 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 13F2B2ACAB; Mon, 18 Jun 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0NEg-00088a-Gy; Mon, 18 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pana@ietf.org Subject: [Pana] I-D ACTION:draft-ietf-pana-pana-17.txt X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : Protocol for Carrying Authentication for Network Access (PANA) Author(s) : D. Forsberg, et al. Filename : draft-ietf-pana-pana-17.txt Pages : 49 Date : 2007-6-18 This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP- based EAP lower layer that runs between the EAP peer and the EAP authenticator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-17.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pana-pana-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pana-pana-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-18134914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-pana-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-pana-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-18134914.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana --NextPart-- From zpfq@cti-crm.com Tue Jun 19 10:09:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eOj-0004yf-GO for pana-archive@lists.ietf.org; Tue, 19 Jun 2007 10:09:33 -0400 Received: from [217.15.48.13] (helo=mfxqaro) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0eOg-0003YZ-OP for pana-archive@lists.ietf.org; Tue, 19 Jun 2007 10:09:33 -0400 Received: from [149.195.151.134] (helo=pez) by mfxqaro with smtp (Exim 4.66 (FreeBSD)) id 1I1c%D-0001Iq-M8; Tue, 19 Jun 2007 18:15:13 +0400 Message-ID: <001c01c7b27b$9ca0e4a0$8697c395@pez> From: "knapsack" To: Subject: He was born and raised JAMAICA. Date: Tue, 19 Jun 2007 18:10:38 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0018_01C7B29D.23AEDB20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4029.2901 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 ------=_NextPart_000_0018_01C7B29D.23AEDB20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0019_01C7B29D.23AFC580" ------=_NextPart_001_0019_01C7B29D.23AFC580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable She currently helps manage her daughter's career. It's also a great place to meet other artists, and network, especially = if you are a touring artist. Celeste is immature and kinky. Sing Karaoke for a million dollars! She is like Rashad's Psychologists. = This is a great opportunity, as there is no conflict with any other = performance jobs. In addition a stipend will be paid for each = performance. No other formats will be accepted. Willy's weallthy, successful older brother. The narrative spine is based = on a dream the author actually had. Forceful, intimidating. com News and information on this page is distributed by the companies = featured through Actorschecklist. "We give preference to Songsalive! No = other formats will be accepted. Helps support Willy financially. Auditions will be held by appt. Transformational, charismatic; has a quality all her own. Good guy with = no ambition whatsoever except to have the family he never had as a kid. = Struggling in her suburban marriage to Dave. Please include all contact = information. ProShip Entertainment's team of adjudicators holds = auditions across the United States, Canada, England, Europe, Australia = and New Zealand. Please bring a picture and resume, stapled together. ------=_NextPart_001_0019_01C7B29D.23AFC580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"hypocrisy"
She currently helps manage her = daughter's=20 career.
It's also a great place to meet other = artists, and=20 network, especially if you are a touring artist.
Celeste is immature and = kinky.
Sing Karaoke for a million dollars! She = is like=20 Rashad's Psychologists. This is a great opportunity, as there is no = conflict with=20 any other performance jobs. In addition a stipend will be paid for = each=20 performance.
No other formats will be = accepted.
Willy's weallthy, successful older = brother. The=20 narrative spine is based on a dream the author actually had. = Forceful,=20 intimidating.
com News and information on this page = is=20 distributed by the companies featured through Actorschecklist. "We give = preference=20 to Songsalive! No other formats will be accepted.
Helps support Willy = financially.
Auditions will be held by = appt.
Transformational, charismatic; has a = quality all=20 her own. Good guy with no ambition whatsoever except to have the family = he never had=20 as a kid. Struggling in her suburban marriage to Dave. Please include = all contact=20 information. ProShip Entertainment's team of adjudicators holds = auditions across the=20 United States, Canada, England, Europe, Australia and New = Zealand.
Please bring a picture and resume, = stapled=20 together.
------=_NextPart_001_0019_01C7B29D.23AFC580-- ------=_NextPart_000_0018_01C7B29D.23AEDB20 Content-Type: image/gif; name="plot.gif" Content-Transfer-Encoding: base64 Content-ID: <001701c7b27b$9c9c50c0$8697c395@pez> R0lGODlh5wK2APMAAP///2RcATqAEEI6NGMRDmUcFlReVlQZE0CDBFJjSwAAAAAAAAAAAAAAAAAA AAAAACwAAAAA5wK2AAAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9s1hny+bIDr9XeBgoOEKX99 RYeAEoiMHYsVkI4wjZM1ipVSmYWcnXKHE4oUmBabHKY6oACYiIt7G3uvoX+jMZmoL7cekkG4nr/A ZKSrhwWzqschjZXMscvEssqiuH2tp8vMoYwGBZLIItG+sLSnkbvRvcHq68LmqxUE2hnOIM/y23/x 0OT74sa11bzRg+XOUisDBLphQ3ZQHCSH7obh0ZPwFr97QsSx28gRiq53FP/0gbwgCx0ejNlA6guH 76IFkcT6PYxZrhbGkKUKSiRJc2HJCgMsCcWQD6bMj6PyEID5rSnFpLxGdpxK9YlLRSK/Sd16UmhK RPqC2kQ6blvSguNUaQVg9OjZoRGrtXQ1aeVanqvakt1aNKtaUf2WzkWnsarhwz4YfhtwFS1Br2Ml BJDwTx5gDoznNeNaCvDayZEuS/W1cKg1lcei5pRsdCdfeERNDw3ruDDi27hv0KU5oXLnuxOYoowM AIGEhDZlckCueRa0x8MvGKcMN3lNs25BgpUg9iZeCQeYiuarB0H41K8uHzJPmXFU27njyzcU0Xlw zcCPJ3SP/idIAfoV4N7/ad5VcJ51vFkDkXWoCGCeYMohqEF3kwwTEIAHtJffTRlOQOF3LTnYoYCK kXOIg70NCN98LLZYwkfMAHjcPI69lFACocVyk4wZ3uiTahOgmONf+EAHGQYiQkXYB75pR9QeAggJ QAEJAOnYdJRV+V6NM9oHIwatcenimGSeo1YFMk65FJX+FfgCaCS5ZIGDARSw5lwMnrBiVx2EGaEl ab7AZjj8/BFlcD6m55mhva2ppZhlRirpkPYEOUGda7ZZ3QuBlhClAJi2dcaGqVykx6GIdjOSU3kE amdFq00q66xbdErrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvs/7PQRivttNRWa+212Gar 7bbcduvtt+CGK+645JZr7rnopqvuuuy26+678MYr77z01mvvvfjmq+++/Pbr778AByywCqTSUDAJ Bw+ssLmu7VIknmnJaYjEC1eM7l6/lTTNeLFuGtKA9VgscrtI6RFAWOo9g3Ft2pCzJsgOX8oWiUru OfLNxV5V3nlNVvpOwywP1keHboL44H4NJYzz0sMyZCBbOmVspWzYOXI0zTFLICUAYlnE9NfQ7gZb cpvsWbI5Ijr6QSWd/mMz2HD3+qUFPXvHccerov0iBZ2uFPffy85taagKFVjw2bV8imnIluJEXmiA R56rhaeievKdLEj0Uf+UCJxs5it9U+aaSZKXXiarqBpsKqTXLNIpnCrGafrstNdu++245+7rXxd9 Sqefugefr4rOMKq17+wlI/zy9dadSZq2psgb89S7qwvindlX/fbqmpqyN6xzL/63vAsEvoTjpy8u IAeJCbT68Gd7vfacZRf//drOrz0qK+Pvf7SkKJlnwve/AirrTGQbIPoMyMAGOvCBEIygBCdIwQpa 8ILJupvU+uOzt2Hwg0jwYAsEmI+IuQIw/JkeCFcYBVZ9LmlTo9pWRIUgAsHGhizMYRMolwc44YcW 76vhTXwIovTsIzgCUqEOlxjCCvEmeTQCCDh0sp61/UgW8cgME7eYBB3/3QRLsXFOQEiHtyta8S1D aRIX1ziEQqHpjPaL4j3eRkaMCAZHbMxjRsSmtXPQTyPYgyOf6jQzPOrxkD0IyFailz05OjJv9TAF UmQUDzUi8pIyOI1c+HYNI4VxjtIon+soCSFMmjKTGwtS28RTxta5MZIlkoWrTklLVD7kVBbwHAfj +EMR1vKXXfyNdHzIwzoC85jITKYyl8nMZjrzmdCMpjSnSc1qWvOa2MymNrfJzW5685vgDKc4x0nO cprznOhMpzrXyc52AlNpdiiMMS+mwU5ahwAfSssF8OmEeW6vmLochDx9ibCAuiGGO2iGKl4WwyUh MU5lIx1zmODPGBDR/18w2hnKtELQKviyo3iAYi5cAFJhtlFirwgP0hyisUeQsaRWqKh0XkS6JIZL cODRkPdgusdCsa91INqbS8BI0qJSwpb+bFgjiOrK50jgQY/0DlQp1TKEjtEe3khbjmoWmiTRDwSM dKkpJnoCGv6qMRSYjlkHYoSrGkhtQruqVQnDEM4RzYTRCCtAEDolLcn0EZ4MVKLwpoFKPsqVBtCr kx7XR5VaEnJyaYRXg+qdyQrtshMRpaLsKp4rLsSuhfRrUxV7HRiYdWJ87UQsOdelRiqxAq+iUlVZ cpHYGvIrl+mcbeGyyap5clGcI6Q9hdI20WK2sINSaEXV9qMdNWqwEv/6hm3/2seJ1I9tusVcc35K gYu6CRVEzOgCJ1ClBFoGtrEKJAAms6ZB4VVGPjTkz3ixicVRlatPJRx68ItYnsbhhK1KU2xTUjTJ DPi4ipARqA48Gt9KFr1H6a3HuLQX77aycUg0EYE3oMYgGjhTMFRUKNIU3tqc6FK+AaTxMhtRvgm2 LIvFMGE31Smc1q83UTtvd9OrngyU0kiJrS51dllZ4RJ5MMcLFWY9/MmNzC3Il1oKWfuHAbcROK9C HvJXCsJIVrwGsGVM7KeyRtyuUHlsQtQAGFX1ZUjmV8psvsnzJkBUlq6YxeE7bU+GElb+IQnCOi4w 1MgWVKZ6tmg/5lP/dV/8xwWWeLyVqHN9xlsz/7JBcKlj6nGRlF2/EZqTAAhdg9vc5SbLVJKl8B1p p8c22C4lhWd2XJoz0KmupWx6dHrVh/YCPaAAedXz/SrdYOzcJi9Q1IGeMFuEU5055zioAn4s3hQs 6zbXT9K9bDUFiBfiDnB7KhZycZYr7YtPdQ5C6qW247acHFF/m5f7hBkonY1Xbb/51Ti0TVZk+Od1 i0bCof7tG49XbYji0swGmVMFLPxVyfqOst9QNaJiZ+194ltTs5A4GLvz7wCnLgCwUzSUGc3vBvn6 SRGHB/H6sxw0csRpoC41pQOly10X293EuYeqO+ehWN544nRln5jH/1yOQj084MHpGgFZ82p+X0Cw nkY5moLbWYxDj+p6PqJi380VVW9Ndu0+etLNl1exLzuFFc/l2Tc8iqOTvB9dTV1xzp1oSo18x412 E7ITTj8SD/rChcUnxajibHNfzulTN/yQQRlz5IGGREBEi8Rz8BCzK7rtRMe625bO9CMjyfAb3dKc gsvfBFuK9C6guAYm/4KVAkHTInh7Cc492uMpnjuLkgTrV6qxiJt72ZD3vI9pZmlOIO9ANl/9mNX6 bCGzni38KX4iwJqkrI/gYA8nmupH2DsbSD8LwN6AuQ/0g4djKR4+1b3ZLz6kRaZOylqE2DK/34bw 58b+yv+6Eawfwf/UxtP/lHUs8AGA4DCA1EUwHUV/vnU7BDgHgwdmgWNF9PdXDYgCBxiA3Bc8FQhR tpCAOiNJhLKBygYsa2ER73GBrqU8UAF2uaCA10coGJg5D2gtqVVSIjhcCPM9QSdiyhCDQOCCnpQI HYdGIYiCQBWARkgFh6M6N4gwsnIwA3hEM9ZGcbE/2PBzUTVfO5gNM9gQ9yVoBqMEmqSCbdZSmcVq L2VsTGgOM0hT9GUZW2iCSShE8MQ4JlCHfpBssUZuU2iBczga+SZnWqhiO1WIAPaAmpN7Tbg3XQRw XiRDsZaIfgZxf4gfdgcRr0R256MdcciHenKJjrhfpUcqXrhpPAD/c6ZhiPwFd/LHd2xngNFlcAoy V9cDgBjnM4PYUE4Bae0jaG2SUSaSJ041iKLYEljYFGiBjMOIZ3rYfMfoRAs0iSuIX261NpDji4o4 E8I4Y6hGaWSmQqFoP8VUhCEWiImhQF6RjYqiWXLFEsnIeWkHgkBUTzVEjy6nXooEhpxBFuHmjVf2 b+9IZAGkjqTRYwkUS3wlJ68oiAiXdpsijW7BZLOmbO6YIAxZgkiIh0FVNglijtYWUURSIRo5QpN2 JMkWY9DYMnGxiQ5pbBxJEBV5eTHZHLOmP/rYjXPUj76IcquzjVXTi46AU8YkQPuTjLhIIw4FieEz htGohiYZlGwn/5NL2Xy4CEPcyJOViDEEcmhIFos5tyojuQIG+ZTRqI5dyYpkCYt2I4vhKHDeqET4 2JIURpVG5I9OyZAlJxs6OWH8iBIAuZMoCYhFaZeBCZFNKYh7iJcU6YyKaZh8F48ropVm0XuGGJU2 hnilEozRMYWSeIgzOWpoyWKix4eJuRcsxYJmGBMS6WYkhECAKTVns5CttJc/x4/5uGmROR5yuBkL uBpbqZAbFJAq+ZZoGYlXhpWfyVHpp5CRWSMqA2nCaY7y2IYzgFMpVpIpyTJ9eYmtiJT0hYoxUTei qZhsiQ2FM4o1+Ep+qSp1+ZrBuV+yqZ2mRhrySWlms5y3BJJJRf9FmjgKCqFcgVia6rl4yHmUxchb zLmbLGhCa/kwZxlHrpmd/rmIfihKEzWO66gUu7QT04mFGSBtf0IKwIOV5AmbzEBWZJiDQIiAIcZs 2omQQ6mbnUicYQaFlUiiiHVZmQCiJNmTPUgESqOfCrpVS9ZPhfh3ockqCIGeSekC/Jcx7zCi1kij 7EALLppmSnqMKCWL8LgGEYqk1Xk61NkrT+pOWbCiZpqmWTh/aNoGPHorFKqmW3CjoxKEYOqlR4Va aCJSzpJPAIMKKNqIH4UCyeVfC4JmbSB9PPU8+mcEftVtcyF3+tgPkkqShNovjqkflECnYdlRiUKn HnNiOOYjJmD/DKR6oBnhhpSZnqOZVkvwqe0IQ5JaAGwiVgEmA/JVAmVKMrCpGyZRjdfxNhUhgsCj nETXG9wlizQ3YM3FAYSToXyEdC+oe2pyocm6eotjDBhqG7r5dBI4k28KAmFymSEhGBT4rXsSri3X ND3ZKvCQKbYqrZdjrfgZaQZFjKnhoVyxmpVSV8cKYiLkJxw6dGkCsIeaVsRkisP0lYGpYHT3QpJF d8ghkViHfkHjhOgDbJqzcMiqjTE0rti5cKwEgU9FAZXRmRHrOX7BkmNFLDooZnQWKvGHlaiSa033 J9VBJ9wJb5RInNPpDM+3qxcgs+3pMQLmcgFYa5g5cB5SpP8R/2rBZSdTRHD3wZurZ7K4x1Gh9IYK R7KrAj1qJXieaUxKJpBD1YeOQXLAiEuGJ7VnGZXrlUFo1GvbZiR0ex/flQF1xm4jyFt5JrYnQW93 KgISy3EdJ3aPloWiRrFj04+IACB7l20yBjXJd7UyA31a+wFiy7VM65bOh7c5KWjzamv42bnc8Y1q i459RHM01EEzxa4+Kq0Va7eq9DtXOl5K+5XcCnhggm92RwyWJ7Rd+2OSKHbYJkd32yWMu25h9LhQ +3v99WA4IaVPhzyt9UkaMbIForGSB7kkBn+aom/8BJQ3xjkSi7qyhqHjBjvgaQr4JylcVz+gp2ei +ry/c5jSOv9u4mmPMyNviakXnvF8ITcCBbtvTZY6ruKnUIHAY6PAlou3KweVfaBg1gtk0isz2ktr YsdQQrocvIeq3IsgkIuwDDWp+TslYFk0jld3xkZzTUuzJ6xWkBe+y5LBJgdLWCZHytUpkWuVHgy4 S4uo6bhIaaVSrVEYUPeglYPAacPCXQVqE9Ahm4vET5O1vQe8J0xaEtEpxgG+/uR1iCJ4HNgnTdes 9qvF43GsJ0yloUMhRWu6gwttrnocqjdngYIq2nuFXRssvAe3Zwx7NXN1lrd9y7h7KymCiXlXOkqw XEx+wuat6aszh3LH1dcCM5yn/wHGTXXB1fUyHup17+sCz9foS5CsSkfDxuNXSYcMs+MGAIr8SF6H JZc8GN47eY6FdncTypESeUVzOC9rUgxKNasplgbHif5XUYmpBmFpqSYcU7Gbo1+2sZynnx7qcz4B iADXt9ySzLbQpaUzzN1DpevDv9VJzrWzzONizuSCziwKqnL6CXH6zvI8z/Rcz/Z8z/icz/q8z/zc z/78zwAd0AI90ARd0AZ90Aid0Aq90Azd0A790BAd0RI90RRd0RZ90Rid0Rq90Rzd0R790SAd0iI9 0iRd0iZ90iid0iq90izd0i790jAd0zI90zRd0zZ90zid0zq90xQQAQA7 V^% --%^V9^%-- From cdt@hurontel.on.ca Wed Jun 20 03:28:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ubw-0007Ka-Pf for pana-archive@lists.ietf.org; Wed, 20 Jun 2007 03:28:16 -0400 Received: from [85.105.33.200] (helo=dsl.static8510533200.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0ubv-0006qe-91 for pana-archive@lists.ietf.org; Wed, 20 Jun 2007 03:28:16 -0400 Received: from [35.105.53.104] (helo=fjysq) by dsl.static8510533200.ttnet.net.tr with smtp (Exim 4.66 (FreeBSD)) id 1I1d0-0003PG-Sn; Wed, 20 Jun 2007 10:29:22 +0300 Message-ID: <000c01c7b30c$81c77360$68356923@fjysq> From: "Freeman" To: Subject: sixteen purist Date: Wed, 20 Jun 2007 10:27:50 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C7B325.A70430A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2578 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2578 X-Spam-Score: 1.0 (+) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca ------=_NextPart_000_0008_01C7B325.A70430A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C7B325.A7084F50" ------=_NextPart_001_0009_01C7B325.A7084F50 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Like their lifestyle that has been branded immoral, this is the theme of = many spiteful and hilarious songs composed by local artistes in Northern = Uganda. But we should respect what they stand for and understand that every = organisation communicates their plans as and when they wish to," she = said diplomatically. He draws people's attention either through a = thoroughfare or loud music from his car stereo that usually rent the = air. And as the international conference on HIV pandemic went into its second = day, anti-Aids campaigners expressed their concern about the = unpopularity of female condom. Dasebre Ewusie appealed to African = leaders to speed up the resolution of conflicts and ensure rapid = development of the continent through intra trade. PAFA has a seven member Board of Governors including a lawyer, a medical = doctor, a banker and educationists. Despite an almost two-year-long investigation of the Mabula murder, no = one has been arrested yet in connection with her death. Rwanda has always been commitment to pursuing good foreign policies and = has excellent relations with her neighbours. No clear signs of = mutilation of the remains - unless the actual dismemberment was regarded = as mutilation - were found, Ludik added. Their situation is appalling = but we haven't been able to do anything to help them. The money will = also help create employment and reduce poverty. HOME Southern Africa = Namibia Women and Gender Crime and Corruption An End to the Energy = Crisis? The Ugandan women also want financial bodies such as the Uganda Revenue = Authority, Uganda Export Promotions Board and banks to sensitise women = on gender-finance related issues. There's also the impact of the war - = our culture has sort of eroded . "It is an issue of partnership to cleanse the society of these social = vices. All the honey is removed from the honeycomb and the comb softened by = soaking it in warm water dissolving all the honey and pollen. Dapaah stressed the need to break the chain of poverty and gender = inequality. Speaking at the second meeting of the Confederacy in Cape Coast on = Friday, Dasebre Ewusie expressed the hope that Mrs. After much research = and consultation Thari Ya Sechaba was born. "There is no child protection system in Guinea, HRW said. The = inheritance law ensures that throughout Sierra Leone women have access = to the property they are rightfully entitled to when their husband dies, = without interference from extended family members. The gathering took = place under the motto "World Market, Opportunities and Challenges". = David Apuuli, also said it is difficult in African societies for women = to propose use of condom to their husbands. "It was later that we got to know that it was to honour him on the = occasion of his child's christening. Relevant Links Southern Africa = Botswana Company News Women and Gender Lenong warns that if two awards = serving the same purpose exist in the future there will be no need to = stage this event. And he did this perfectly that none of the several people who come in = contact with him, one way or the other, has a cause to doubt his claim = to be a mere deceit. ------=_NextPart_001_0009_01C7B325.A7084F50 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
3D"acclaimed"
Like their lifestyle that has been = branded immoral,=20 this is the theme of many spiteful and hilarious songs composed by local = artistes in=20 Northern Uganda.
But we should respect what they stand = for and=20 understand that every organisation communicates their plans as and when = they wish=20 to," she said diplomatically. He draws people's attention either through = a=20 thoroughfare or loud music from his car stereo that usually rent the=20 air.
And as the international conference on = HIV pandemic=20 went into its second day, anti-Aids campaigners expressed their concern = about the=20 unpopularity of female condom. Dasebre Ewusie appealed to African = leaders to speed=20 up the resolution of conflicts and ensure rapid development of the = continent through=20 intra trade.
PAFA has a seven member Board of = Governors=20 including a lawyer, a medical doctor, a banker and = educationists.
Despite an almost two-year-long = investigation of=20 the Mabula murder, no one has been arrested yet in connection with = her=20 death.
Rwanda has always been commitment to = pursuing good=20 foreign policies and has excellent relations with her neighbours. No = clear signs of=20 mutilation of the remains - unless the actual dismemberment was regarded = as=20 mutilation - were found, Ludik added. Their situation is appalling but = we haven't=20 been able to do anything to help them. The money will also help create = employment=20 and reduce poverty. HOME Southern Africa Namibia Women and Gender Crime = and=20 Corruption An End to the Energy Crisis?
The Ugandan women also want financial = bodies such=20 as the Uganda Revenue Authority, Uganda Export Promotions Board and = banks to=20 sensitise women on gender-finance related issues. There's also the = impact of the war=20 - our culture has sort of eroded .
"It is an issue of partnership to = cleanse the=20 society of these social vices.
All the honey is removed from the = honeycomb and the=20 comb softened by soaking it in warm water dissolving all the honey = and=20 pollen.
Dapaah stressed the need to break the = chain of=20 poverty and gender inequality.
Speaking at the second meeting of the = Confederacy=20 in Cape Coast on Friday, Dasebre Ewusie expressed the hope that Mrs. = After much=20 research and consultation Thari Ya Sechaba was born.
"There is no child protection system in = Guinea, HRW=20 said. The inheritance law ensures that throughout Sierra Leone women = have access to=20 the property they are rightfully entitled to when their husband dies, = without=20 interference from extended family members. The gathering took place = under the motto=20 "World Market, Opportunities and Challenges". David Apuuli, also said it = is=20 difficult in African societies for women to propose use of condom to = their=20 husbands.
"It was later that we got to know that = it was to=20 honour him on the occasion of his child's christening. Relevant Links = Southern=20 Africa Botswana Company News Women and Gender Lenong warns that if two = awards=20 serving the same purpose exist in the future there will be no need to = stage this=20 event.
And he did this perfectly that none of = the several=20 people who come in contact with him, one way or the other, has a cause = to doubt his=20 claim to be a mere deceit.
------=_NextPart_001_0009_01C7B325.A7084F50-- ------=_NextPart_000_0008_01C7B325.A70430A0 Content-Type: image/gif; name="misinterpretation.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c7b30c$81b2d9f0$68356923@fjysq> R0lGODlhIQEXAfUAAP///1/Q1MJJndh41mCQYXGDkoYoJHt3N4u+mXCaxrtJh1lyrognVEa1saI2 OX+uwa47Z4B4ZXZLgWOamsaXuJKaeaOkto9/ZIyifoZTMLxVuK+Yk1+gb38pPp8/Pkuf319sj23Q mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAIQEXAQAG/0CAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL jI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipegasAgIWCFWxXbAItkMEubpPH6pPCBmNrAau tbgEv12vtrYcQrrQALkNCBQDs0Mf2pIIAQG3QhMZw8RDzbnH0MhEwEwPgAZG2OhO2FoCRc7SRcjT 1ddEtm1rMiHQg27fwIkjhw8AMw67pKmjB+WdG20SACywmCReEXtIoDUwV6TXEAkGNoJM0nCIvnW4 9iFZYBLAQCUfxAHiKASkR/+SRNbBjCnkWrCA2j4wEMKzyLhhUEQSeUozm9KUB5UM06DBGACIQ5+J nIWNZs2rKgM06QouXbSwRBaUXJKg17g/IH1+DGkEplGkSRnEyyuEw1NWGpyoo9aT6kCTHlcS2crW JUWiQGOxqpqtiNomtdpOFEuNQhG5AZUgqMmK3cM6hCfvPTLxMoCjQmoKGWwOnL4hiZuEJTvX5u6e WpfAhdu4dckOKdv+QvBS7LHSp5MmVV3kZ2jqzNvEHvITOe3RTlPLA+CtLQfoUBUjAWkSsnkk5Wn3 nf/0CPQFtny2RHAuPXOMgTNpd9MReglhAT90jHccO3wtgZtx8iBkBHyI9WX/W3j05TahZOQptx+F DgHASl3qDSGgEgQWhqB14QGQQHHzafOecw4xQx1ss5WI4olKXKibij16k08RMYoV1nD3iYhhZMkp sRw039y3XW7QJRDgWj4iIBSENR555Ec6xtcTM7a9ISGSQyJYIwDXIABdbtrdGUt72HBAjgEDePgk lmTZacCWR5I44XnRuCVgiENA94F0S4SJmYG5fDMAQFJ2lkSDKQYVIULMdPeRLY3OWSePed5X6m7k RKXLiwiwsqAW6OWRKQKbKlqpqWuyOecapK6UX48RyXTFm77AAWqPqDYr7bTUVmvttdiWMawox/pK xbFVPBlKgAnNsi0Uq3bA/4W3ZHTrBbhUiCuNppxeQu6r5zrRa60dnLWsFfBC4a5wTwQshbwE0Eup JS/uM4wDVgTa4plRsFslwOs18RsR/W6J5KTdWCHvxgBgsEnDBJDjgMTItnkEyyJql0B+5bLGyspR zqgaBgZ0TMTM/bL7E3FOJpsLB5qS1/GWPYOsZLwQflWEyZqgXJ7EbBrgchG9Uo2nNguUx+dqvZDj AUDYaL31Rzz7nFvYQXs79H21iYU0r0J62jMRDUcV9d1dnxz1EFgPrsQ1bbfI91z5xeI4AR2sfcSx iS4xd6j6FQisETSH+3cAFvTKCcpFmAYtARlIznm/nnrGOIPRSkF5kPhl5v9WslJvrjt7fRl8qUwk j15EBKUHi7rqdOJIccMjgcvmFLPHOTkAFFBwyyyp55q7bOp1PrzvOgMfSsPEE2G6xVwrP8RSQjR8 Y+MpYhBB9gJ7WrlWHlQPrRAXSkTEb6YzAAMUtKj2GSEC4JOIOmQEioYdoHg9kl/qmjAA61XAABI4 ywfClpH2JeQBH2jeMCBgPcxlL18qyuBjOOgldkFgSCdsVGFAV8GTaCdvBgyXDIMnuHpg4AATbIIF MViSsHnGFiAkDytImDNlNUGFccGgl66wwLDQMA48zJYWt8hFbXXRDQcgBxN78sMgvqGMC1TNBTBI sS2g8IuyeEB7iBDGEZ7/DwFohElYClKGPOKOQWuEIhjeCEcpeEmOByHRGEEiFIoQgI84+QAIiIir YdnjVm4sZBgOGYBEImGRUTMaJJOgjUl2MAuqu2QbsUBITT6hALSbClCssw89NkEbCShA+VDJhFFi yEa6LABHXjSSIWQgAhGwACwM58otwNJFkjFA/wqjR3ogbwg3WtwHo4A8X9YklxEQpkWISZ5jJtMr 4WtmF57GuSNggGT9uCY2PcOnJD7hXN5EwjiJUEw4xamV6nQCO7vTLa/xg5BHGugqD4pP5elyAg/Y 5xD6Kc0LXACd6QwoFuTYkQyFBB0oTCiOlJOvfNpkgxGAqESF0M/bWDQ0/xoNQ0Q70jgSWVOeIlVc Ev74KaR0CgAz5V1uIDmwjMZ0ChC9WG/waLSY5CunrbMSFBAwv5RqEAQpDeoHc1LOl77KqEeNgkq9 kSXuuYapN02HE6D6051ONQIdSGlJsFoQjiARAKM0AAQgsAFKATSsRRhrJ9GXud8hISlYddFI2cAT XwJWEojd5R0SCULHPvayn0KAPTHL2c569rOgDa1oR0va0pr2tKhNrWpXy9rWuva1sI2tbGdL29ra 9ra4zW22iqXb3RaLsIUwCo96awVmpYG3X6jTnYj7L+nBLiKNlGeGxhYG4DI3swOFlZqEBdK6OWRf TDDuqWQY3utmAbnS+P9T4UTlv5gorFa/QhEyYmU88nInNdoYLrQwaV58pQ9zcoJQw3wXm5SRY73s LS9gPmAraNpCG39lbYHnE8ojvJfAs0kZEbCGKvv21KetI11/M0xh9jLnwvEFSlg4LCYPlziqv+yb eZNUrvCxOFUWrhiJN9zEZOi0JjImz6Z0i14Ds6IDLOuwLY3wXgWr+L/cPVe6YAxkwyEZZuZVmSwC V6nf2rg3LjYC4vbWViAzA8JEWBmWZ6yGIv+XC2Y6K3/ZTOc621kNTgvyqVBlxgPdmREDvFduGoDA 4froeAyN8J/twD6gfCABheaRr9K6aESc0jxHutx5gpLFSv9BAi1c7ND/bPFDZm7P04RoITtzUkdJ k/qBCdYcqg8xR5tMoNXOvV0uLDvrPlw6VJCB30fVwete7+HXs7BZrtNZbGPnAdmdMrRbA+vsQIBa s4P9qavxCMQlE6HZ1b6DONnZFO8w453eNmy4BVHudbv73fCOt7wV4106IaACp3hQafVMb/SEjqrT NEJTmrKFql6hohf9qhP0LVo51lqJCfQQAELA8LguYeB4jXTEFXgZqsbVpEyxnF75qnDQjDai3vCk EDTOzXWEYHgXL8I7JqDxFzJhInys1wSuyhSCJ2EDgjLargHAcNBKdBY0J4/Nbx6RlxNBskfAuC+X LtVvF0V9IAj5E4Ae/5S6QWMCFH/6zueszqw0bOr9RofThwD1jA1h5kWg+rSfkXPlSRKvPv+5qftB hLCzfewDyfrb1YntxhZBAQebOMzvO3iakwPxsiLcSHshVyhw3bB8J0LRiyN4rTcTkdjwJeT9tvaV pzjkt6bvPYeC5TO1nQmXT2fmh1B0q26p80DVqFoUcngTQcjvKsIwEeAerxUvNrF5R8Lml+NE4LMC BDcEAO6Tr8Wjh6P3RMDAUGqzjn8j0MlCuBG4dwqXekE/IBlJQFYWnui36ALsDC/PQC5N/WwdBPRI x40BRk/N9rOeqk1QeLYgflOwNVT1fMVxI4S1eRznSENnOsEHfVtySv+aRXgpZw+HcSwQAQYXiHQF SGxPp18DoX4LmAUGIIEYIgEXQIL8xkUypiZtMH6MogstdVjDNwcr+A4tOG+McGk7yIOKIAEVwIJA aAkdoBJFmIRKuIRM2IRO+IRQGIVSOIVUWIVWeIVYmIVauIVciAj30wn5dShntTvWRQU/WC1fWAeK xgv5FTTtc2YQ1xvyUQVn2GaEkIZ0sIZrtRerZh+adnNWUIfHdYdBMl83gwZ9UyNKtmQ8dQS6MSlC pTetITpMdzQv0ja30jR7YjnLZgSAwzLqEn0fJghfaGQGgDMkFWZNkIjBd4pLlUYT0Wn+YRINwxoA oGZphzTmgIk3ATT/TrMmSQET5YE+nzgLS+Mx0KIkZSgHpXg1lagLzhALY2YVYNMbfIILZoNgmEER stgd6pJDMOYBiRdLNYEaPfEZDwZhHjGMU2CMj5gNzHCNg1CKb/YEzhA6YxaK2mFENCYazng6keNI /+ME/AiO2iaOAOZ70lOOrjM9/pSQSYA0+GiM6uMahDgkYQGB5AcN9wgzoag7rGg+xnNC6rYEG9SQ rdMa1bMwFbKQQ2COOZSOH6BhD2kxBCCRFUSRE+N2gfCF3zcEGjmD0Eh0RbAUmbY4iweUPVaSpHQm q0ZRQqA/6AMT+gYpGsEOu6dZIURo6yiHgAiUs9BonXImyxgHqpYQ/2xnNkFJJM9wj0X5SwXUN1B3 RxJ0GQi1QQI0ReyBRMpGPdYzlTcJOj1xQQN0E2HDAKqWkD9pAPlTciGBkyUEAGL5S9nklYMgaEPw QCP0jEO5eRlxlIqldbCmlGQ0P3YZBWAjRdhwVzgEkVaii0NwQYJEHtfGO3zZAA0QRkNAQo7jBDgZ Kr/2TfGIlo0wmqu3C25JBJ+5j2KzTQBgnNQDClo5AQXRlbPkBcPpmocAnVXgmV9zkkdUlp+gV38p nqHAnbLFm+bZhezZnqCwRs2iIHdXSNrReQJYgWAAn1mgP3S0BaaUSWxYn/QpM8+EcvLIP6xwTFNj amKATAuqBeAEoP9T8Gj0WQTPdCps9xTHxHB49BuqMwEYME29EEz1pyLmpEyzYFCJ1o1PlyEgFELD g6LzkEZQsFCfEF3bohu5xCAtqnkk4aG9VAEiCk4qZTkZ4FUp2oBFc5OlpwRtx5chtEtH+h1LepeQ YKDkRAQXECzvVKXSxV9lZXpDcFG7+BL5IqK6UaIAYFFTAxZvUQRNmgSvl5T9Yw9/ZaOFIFhhWoNb 6iPoRktgVRJtpGdHuqCNiAQiKnNNwKbZB08NCHZO8KRaGaXGlHB+NaF4Sgi+FHpS2qcVFmtNiQTZ VU4fBQWJeoNMwKhDoKK19HVxigRQt1U5IVmWKh0AlamaSjtSGiz/aBWoh7VKQaZfanWmRnAkaqqq scCqsxcFsRpYu/pPTCmokbCpIRh8vKp9Y1KjwPqC8KJ9TlIpcFV5baWme9VXt6Csj/oEsQqlSbcb JKdwNGqSkkCtsvGHoMoE8ol7MvaT7uRU4PpxOqWmQmCuQoCuHCeDkpRVrvGiACBZ77oSh+qI82qg 6xeH15put6Qg+noENXd5eKRWbmCwUpCwSVV2heeQS+WtZ9Cx1+lE7vmyMJtb+DcZw6AAy+Se64kF 91mZj3ezJROvL3OA8ocRc+ppOdtc80SGbroLuXINhUaNH6CC2dQUNrN/NntdvmKnXwASldmaENuA j9SjMJZNL8Ii/61otT47CDIYCQjxDtiQgVGyfUA7VUXQtQWknWHRUlA3qObAszwpCDUoBBJIdohw ENSFoDULYNWkPXT7M+20bHkrtm0VmtJRVFZCgyF4ghqUfgIbDzB1KY1UGiyjuaLYCDzBkgCAD1or e1TAtY/bsrqmt4vlIsQJcRvXgIzhEIWGgiclhCTYBMRApToTuv/QmrjKbkGSgaqbYPUmBa5LhsP2 R/0zqGFKs8TwCgSDIpBiEt9oMeUwS9vHT5xjFoR7CE2RfwyBORuoa8MRcH9rtw+Jt0UyuwaEuqm7 DF/5t/UxIsBbiLEWuBpBQI9wuh5IHqr7EBjrsu0QXmMDv8ImKv9zMr2nEZP2YLktSY5SQiVM8MDh O1GvO7mKYLg19hUZGBylsrhAu8BMcLhKOxrhIVw/oR2CgRqP4rex9CGzsb38u8ExMg//CxQpIcCP QComBBWJsbpVegTumwVLm61iBgzDFRg/8SIDQQ5ckbbtdTu5C8VBvL9w4r1s8VX1JrplUbqe4CPr Ww9LPEhZUIsQd8USl2gt5Rgw5r1EV3Jvag7W0Cyv0biAdbsx6waALJ1EfFJ+sm0dxqCeNciekGe3 kCbxESZ2KV1ewBx6qAdHyw5rdnoXSRKgqSjddcnjqMhLsFxrcLzL2Ih448eFUDmfXKrfapKiuCe1 Wym5AlCmjGf/PtZyawgyhTyPX2IVpsirSBytJ6UdkeFl4XXLCiSIrHQis1LBh4KMFKaOGwcXSbNg jzicmcwGmGnNowavbCmx3CMdhGXJhGIOtvKI+pVsM5m9JrYrozvNC3IowewQwQiDVcc3q7wb8vm3 tPbIsAK5zUvOQiJehdV12lsr9JwN7ZyONFl11vQys2sr5NIToJm/9ZgfZOmFe9GXeFvQxQosCD3O 4UM0MNYtafOVE93M/Ty53mMscyhmkyHEnfgHrkyzS8l8OEHSsbTPMgElPdI0t/KNcQI+jYQp0dx6 H+xcEffCgmrGmOMTjIxn9xILn3xoTmzM8qnBsLuR0JXD/ELN/0b91VL1pkPx0r9kHzy6O3NXj2UN l+dYy9baB99M0lrNurLsMSUddL+D0kgQ19q5kd8KjdkMtWxNuU391m9IiccIptU70KMl1HhE1D+j iTd9wdWki2vmMZqoIRCJ1OSlMIjNZrwYRW5o1mYQN84cdKIcyLANb4EG2pxwvH5QnnZKo5B5b/Sb CIiJmbwECLbtN2rQmOfGvjMUOhYEGI8AbbjSk2ysBnLnNSMTquU7CM6NV7g2ym8QT7ApBLLZC3g6 nXBCnn85FYwrBtP9O+uQRTcBnotwbYXMaqoXQUDkFr7qBd0mdJZYlYFEzS5K38FHQuVpTOnNOSq0 v6rpBOrp2v/0AJk6BZOJIN+rpjuvNkHch69mZZta2QT7DV1DUZUgNorPebcJiUL/vR2SpJrog9td J0MTQEMaeSS4N+FnmdKugUZgizy6ITY9sllK8OGU5iBRUr72AGsWjOJspOKmFGpC5CMvniwxrtw6 VeOWJgQhQMWpp88Q/OIajkP1xFXcFD4irlM8ieTmjcdPsKX4hXuvqhofKydDwWv52gintGpbbmjc huEmPdJg/iLjJ+RbTZQJaaN8eWuwQuBq7gRs3hnG2gTrPSMUQecaa+fDl2yZtefLmt89jpRDAG5+ 1NK0V+SGTt4mzpZz0ugxo6hMEOlORA90XgRWfgjNClRRehf/o24Zr87jRHChkQjC0iPqWB4OIZoB BVC+W1VMCYpMyuTgSqCi4s3qFnJOYhxKHEBxFACiQuDrNtIItW4ThIbrDnJuG5jh8joEvq5QlYJu ONZ3q5oBxi7XTHab5SNNzM6AHLcExX7sAiHtS0DtxRzU124B2U413A6/m3DcOMrpSRGhHrRVTMDu m44F5PMF8D524zpjN7RLauGcb5DsRbuFrV0GtwnbI6+2SrivqfgFZwc1VndaDyfZalDxl/vann59 BUhtptWBOn1eUdAUIT8GLZ/zL79vqh0qTOV/P50EHWgRxLOZ2fdH8RS2PYFAxGOjQz/gJNd+Lru2 j2VXaTmM/+fmgP7mtAYQ9EA1WPjJsqsq9a5qb1a/c0uAjjg/Qu/Kvnt0Wj73tBYp6SfifWfvBEBf HrEHqIb/cjCD8A1ZwEU1KDp/cifb1Ehc0NbVFNBZ+FkcPohf9ExvHnxUswpAsHr96aV1f52Esku5 45ktcEUAnQyIw+5u9ie4wp6vXQpgs6LR56aVfA+8d6sv7XZRBK8vL0OA+EK7ij1CgPHLTLbh9YDF +0u/42k9BLMucAMY/D5qGTIUFsa/uyucFXXx+axw+2lr7qS/80qseqCcwt4fgAiQTf1TdE38O93/ fHjKET2OtoyUx+dv9EYABBnD0AAwHpFJJTIyXD6hUelxkKb8TLFZ7Zbb9X7BYfGYLB4gmgbQtdx2 v+Fx+Zw+RQ9Bdf2e3/f/AQMFBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7PT9BQ0VHSUtNT1FT VVdZW11fYWNlZ2lrbW9xc3V3eXt9f4GDhYeJi42PkZOVl5mbnZ+ho6Wnqautr7Gztbe5u72/wcPF x8nLzc/R09XX2dvd3+Hj5efp6+3v8fP19/n7+4IAADs=^% --%^V9^%-- From pana-bounces@ietf.org Thu Jun 21 09:34:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1MnR-0004kT-7h; Thu, 21 Jun 2007 09:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1MnP-0004iP-Bj; Thu, 21 Jun 2007 09:33:59 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1MnO-0004aT-3C; Thu, 21 Jun 2007 09:33:59 -0400 Received: from [195.55.76.26] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1I1MnD0CWc-0001Y9; Thu, 21 Jun 2007 09:33:54 -0400 From: "Alper Yegin" To: "'Jari Arkko'" , Date: Thu, 21 Jun 2007 16:33:39 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace0A7uuomtoFMhmSfiY7GPMsFVNdAABPZuQ In-Reply-To: Message-ID: <0MKpCa-1I1MnD0CWc-0001Y9@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/3XFxzNLqj4DzFJbGdJTp+aiUaVY8EALZWwVK Xzia1x/CPKmiHhe3jEeJ2F8ay/a2RFgEMc+irkNOzNBZ+cMr/P NNO4gkQkLekZgIzTgXfTQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: pana@ietf.org, draft-ietf-pana-framework@tools.ietf.org, basavaraj.patil@nokia.com Subject: [Pana] RE: COMMENT: draft-ietf-pana-framework X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org No problem. Alper > Comment: > Great work, guys. This is much simpler than what we had > in the initial version. > > Nit: In -framework, Section 2: > > When cryptographic access control is used, a secure association > protocol (e.g., [RFC2409], [RFC4306], [802.11i]) needs to run > between the PaC and EP. > > I would suggest deleting the references or replacing them with > a reference to RFC 3748 or an informational reference to eap-keying. > The reason is to avoid any possibility of misunderstanding > whether PANA works out-of-the-box with, say 802.11i SAP. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From zicxp@arcor.de Thu Jun 21 14:10:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1R7Q-0001O4-BB for pana-archive@lists.ietf.org; Thu, 21 Jun 2007 14:10:56 -0400 Received: from [87.251.131.46] (helo=saltar-gw.lan-expert.ru.131.251.87.in-addr.arpa) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1R7O-0005he-Qn for pana-archive@lists.ietf.org; Thu, 21 Jun 2007 14:10:56 -0400 Received: from rgclp.qrw ([28.149.138.208]) by saltar-gw.lan-expert.ru.131.251.87.in-addr.arpa with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Jun 2007 22:10:53 +0400 Message-ID: <001d01c7b42f$818ef200$d08a951c@rgclp.qrw> From: "Job" To: Subject: RE: Date: Thu, 21 Jun 2007 22:10:53 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4029.2901 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db With Penis Enlarge Patch you will see your cock getting bigger, thicker, and stronger. http://www.dragut.hk/ From bpx@gmail.com Fri Jun 22 01:43:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1bvH-0002Ju-U9 for pana-archive@lists.ietf.org; Fri, 22 Jun 2007 01:43:07 -0400 Received: from [195.182.10.22] (helo=elt-ttk.eltc.ru) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1bvG-0003PN-9R for pana-archive@lists.ietf.org; Fri, 22 Jun 2007 01:43:07 -0400 Received: from [111.31.43.29] (helo=otze) by elt-ttk.eltc.ru with smtp (Exim 4.62 (FreeBSD)) id 1I2Pj-0005lt-Gy; Sun, 24 Jun 2007 13:42:11 +0400 Message-ID: <467E3C51.1000304@gmail.com> Date: Sun, 24 Jun 2007 13:41:37 +0400 From: Jess F. Evans User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: I agree with their sentiments. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 SREA UP Another 36.36%. Read This Hit List! Score One Inc. (SREA) Close: $0.60 UP 36.36% In the last two days SREA has been on the watch list of OTCPicks.com, OTCStockExchange.com, and Boonmarket.com rocketing it over 200%. Need we say more? Get on SREA and ride the wave. Season the resulting chopped tomatoes with a little olive oil, some salt and some pepper, a little freshly shredded basil, and they're ready to go over the bread. COPYRIGHT ASBJORN LONVIG see Asbjorn Lonvig's Copyright and Business Concept Another site focuses on writings, news and lecturing www. So after setting up our pc's, we found out that the wrong hard drives were installed. The IfElseActivity will execute your check and then decide whether it will continue to the next check based on the Evaluation property you implemented. Make Sure You Brush CorrectlyDo You Floss Enough? dk By means of the newest technology and ancient portrait art using computer, paintbrush and acrylic on canvas Morten has developed his own very unique style in portrait painting. Download e-shop brochure. Open this properties file and include a wrapper. Make Sure You Brush CorrectlyDo You Floss Enough? lu Paris - Rueil-Malmaison France - L'Art Pour Tous Paris - Vauhallan France - Artabus Paris France - Listoo ArtExpo Paris France - ArtsCad Paris France - AllArtOnline Paris France - Poosteers. He perdido a mis padres. Ich bin im Phuket Krankenhaus. Do you know who I am? the other stone is a strong "technical" manager! ExecutionContextManager; manager. My Permissions wizard exited with error "Access denied" . net worker process and restarting vs. in English and French Headquarters in Peppard, near Henley, UK www. Open this properties file and include a wrapper. To my amazement, South-Africa wasn't listed in the country dropdown! org - ADN Network Manila, Philippines ArtFreaks Buenos Aires Argentina, South America - ArgentinArtes Noosa, Queensland Australia - Noosa Gallery Toronto Ontario, Canada - Portfolios. com dedicated to a collection of independent world artists online who wish to promote themselves to a global audience in English Headquarters in Coton, Cambridge, UK www. com a complete gallery solution to artists on the Web. From pana-bounces@ietf.org Fri Jun 22 07:54:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1hij-0006ug-2T; Fri, 22 Jun 2007 07:54:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1hii-0006rY-48 for pana@ietf.org; Fri, 22 Jun 2007 07:54:32 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1hig-00057o-Jk for pana@ietf.org; Fri, 22 Jun 2007 07:54:32 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2007 04:54:30 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHNVe0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,451,1175497200"; d="scan'208"; a="496810517:sNHT58206444" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5MBsTLP023067; Fri, 22 Jun 2007 04:54:29 -0700 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5MBsPka006644; Fri, 22 Jun 2007 11:54:29 GMT Received: from [192.168.0.100] (ams3-vpn-dhcp4564.cisco.com [10.61.81.211]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id l5MBsN700911; Fri, 22 Jun 2007 04:54:23 -0700 (PDT) Message-ID: <467BB868.2050601@cisco.com> Date: Fri, 22 Jun 2007 13:54:16 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: pana@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2662; t=1182513269; x=1183377269; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20IESG=20Review=20of=20protocol=20and=20framework=20documents |Sender:=20; bh=YHYxJ7zQr+AiKlzoKQjLYvLmsMybpkX0YIZF4COs0ew=; b=LNR3PDnaA36RmnuxrkwMQRQcfe/IDYw/1C3NhWYH45r0D4eVrR+A8/rMDgnFXZuTDo4+1oS2 tPoxkZcy3N3DfcW2Qzsf58nwZAgk5hCSUyA5eSDfI7NVuu644itBaFeP; Authentication-Results: sj-dkim-4; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Jari Arkko Subject: [Pana] IESG Review of protocol and framework documents X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org PANA Folks, Yesterday, the IESG balloted draft-ietf-pana-pana-17.txt (Proposed Standard) and draft-ietf-pana-framework-09.txt (Informational RFC). While there are a handful of DISCUSS positions that we need to work through, all of you who worked hard on this revision should be commended. In particular, a rare word of praise from Sam Hartman: "[2007-06-21] First, I'd like to compliment Mark and the PANA working group on the excellent work they have done over the last year. I fully expected to be unable to support publication of PANA when it came to the IESG. While I do have some blocking comments, I think they are easy to resolve and expect to be able to remove my discuss when that happens. What an excellent job making PANA easier to understand and removing complexity." I would like to especially thank Yoshi, Alper, Raj and Jari for all of their hard work and perseverance, and the WG for their patience during this process. But there is still a final hurdle to leap. The IESG ballot (one ballot for both documents) detail is here: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1723&filename=draft-ietf-pana-framework There are 3 Discuss positions which need to move to Yes or No-Obj for the document to pass. If any one moves to Abstain, then the document will be in danger of not passing as there are a number of "open positions" here (all documents require 1 Yes and 2/3 of IESG members voting Yes or No-Obj). Dan is asking about SNMP. I understand that we have gone in circles with respect to whether SNMP is required to be implemented or not, and it looks like the result was confusing to Dan. We either need to revive the SNMP document, or kill it off completely in the WG and in these specs. Magnus has concerns about languages. I remember a review we did with the ltru chairs which perhaps we never fully closed the loop on, please contact Martin Duerst duerst@it.aoyama.ac.jp and Magnus directly to sort this out. Sam seems most concerned about: - Versioning - IP address reconfig - underlying link security - which messages need an AUTH attribute and which do not, explicitly - new hash algorithm migration - discussion in the security considerations, moving some "requirements" to "tradeoffs" I think all of these can be resolved with some discussion and one more revision on the text, as such I have moved the documents to Revised ID Needed. Once we have a new version which alleviates the concerns listed here and the ADs have changed their position to Yes or No-Obj, the documents will be approved. - Mark _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From slnk@cfa.harvard.edu Fri Jun 22 15:37:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ox5-0005YU-4J for pana-archive@lists.ietf.org; Fri, 22 Jun 2007 15:37:51 -0400 Received: from [88.245.111.55] (helo=lbrayiy) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I1ox2-00073f-HP for pana-archive@lists.ietf.org; Fri, 22 Jun 2007 15:37:51 -0400 Received: (qmail 20150 invoked from network); Fri, 22 Jun 2007 22:37:57 +0300 Received: from unknown (HELO hznj) (43.41.223.140) by lbrayiy with SMTP; Fri, 22 Jun 2007 22:37:57 +0300 Message-ID: <001f01c7b504$d59cd3f0$8cdf292b@hznj> From: "Clayton D. Miranda" To: Subject: It takes more than just the inability to pry your butt out of the recliner to give a damn one way or another for me to count a man as an ally. Date: Fri, 22 Jun 2007 22:37:57 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C7B51D.FADE7330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 3.6 (+++) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 ------=_NextPart_000_001B_01C7B51D.FADE7330 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C7B51D.FAE15960" ------=_NextPart_001_001C_01C7B51D.FAE15960 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable This will make regular strength tea. There were a couple of large-ish projects I'd hoped to complete over = this past week but didn't. Sara over at Orcinus did an excellent job of = putting this incident in its appropriate broader context of = authoritarianism and eliminationist rhetoric. UPDATE: Oh, I know there's a whole lot of discussion about blogger codes = of ethics and comment policies and such. Joan Walsh had a decent write-up about her reaction to it. it earns its name with guests. I shall try to have that be a = monotonically decreasing number for the next little while and see if I = can whack away at it in pieces. This kind of crap must not go = unanswered. Joan Walsh had a decent write-up about her reaction to it. ------=_NextPart_001_001C_01C7B51D.FAE15960 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
3D"mummy"
This will make regular strength = tea.
There were a couple of large-ish = projects I'd hoped=20 to complete over this past week but didn't. Sara over at Orcinus did an = excellent=20 job of putting this incident in its appropriate broader context of = authoritarianism=20 and eliminationist rhetoric.
UPDATE: Oh, I know there's a whole lot = of=20 discussion about blogger codes of ethics and comment policies and = such.
Joan Walsh had a decent write-up about = her reaction=20 to it.
it earns its name with guests. I shall = try to have=20 that be a monotonically decreasing number for the next little while and = see if I can=20 whack away at it in pieces. This kind of crap must not go unanswered. = Joan Walsh had=20 a decent write-up about her reaction to it.
------=_NextPart_001_001C_01C7B51D.FAE15960-- ------=_NextPart_000_001B_01C7B51D.FADE7330 Content-Type: image/gif; name="Miss.gif" Content-Transfer-Encoding: base64 Content-ID: <001a01c7b504$d58e5500$8cdf292b@hznj> R0lGODlhhQHkAPUAAP///2dxIA5McW+uJlx3HF4Xdi9eOomdJFRuIHlPdx9FL5J1Q05Mb11ViZZC hmdkTQyBNTVvIDI8eYM4W3aFFk9lfwYWOUk+fEsub3hWUxxcgk+YaEgyjQFgdSxuhZOFjGAViEpi LZhtkCwaYniqQmt5fgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAhQHkAAAG/0CAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL jI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6h1DKl4q6yNDRUfCyVMBAdODUQQQ65EBlQQChAG DAzAdLGztXyzRr5FuHO8RBpZ1JAJBRwaEUMVJQsfGx1CxQYGEtYAIRQHH00VROVJIVQdEMTHyFv7 SB8JlCQAJ45clgrydunjNyUcPCfS5GATsu7KxEYlJhSQAIHAAyEJKQoxlk7DOgJCAjIJCaAiNAAG bi0oopEjk5daSKozsiDBBP8lLyvCpIKwiL5jEpZk3GiEmRGGRGbOgSr0SIEmUBmp7CXEacuRT6X5 /KnEa0WoBg68I+KTG4SISHAeedC26pFiQ0wWeagk6y8qJbwCmJjUHIC1QuhOcEvE4Yan/5zM3HCx C9Uh73wS4dC04BBg6CQUVrR1Ly0DegHgtDdkAtkky1CfNQI3JVMAUpOsVsu3gjYJHbwBLVKRt2sl EGILLbZTiHEiG4MP+cDXGuEhIZ4DYClcSOxnkaED7y7kdGokcJGNv7lq1fl3rpFF757c/MhjDETb LTQBg4aOH3l3mi9IVRTAAT1NkEEGS8TGwGzRHOFfRzcVYcCBCaZEBEpKvCb/UnkJMqiEg2epsw6G PonY338eefcQXgZMUOAQBwpBVmkcDpFbEaMVUdqKAEbFzH6Y/TUBiwEOl5RQISIzYY6PcQWAjNUw ckFwdLkyGUOhFYegTw8kicSOEBJRGwBXARABXUtAxZqNGg4h5hFB+SiFUD3CFWCacS5AywbIPLBP nkaUNqdgQ/TIFnRXrlkaougR8VEB9JSGBDBLYpZgmEPQMwSkdUKi5UhlFinnnDxVKYSiuGk2xEYQ DMBmX0UEQISIhi7xElQeIiGYUELpKQSfUZ02hIi0FQqrrEVA+tURHi47a1eSNSZErKje9VVFOzp1 kVlgqZoIZ0S4Ut06WemZ/y0RfD0LAKsAuJrXW3JZGKGcI7l1QL2f8aMBr0wUVMx57h4mqRDkCuGA izC5Uu+ZAOhrRJRGEDkBpxETsfAQFBO3l5y1cLbvxn2ZWBFAFz/gbRECP2iYuIhw5GgCugDQriv6 mYSAwZ86O125YiiqlgjxCYGBzOvyaLIRvf4zcFUmrXMA0RMYwAzSCahEHUXWPByFX21eDcHMfx1R FdVWfyQB2UxkSkR8JSTpKLsDf+bxIgBmvYTJBlAgSIhDXHAnwcdi8e8QKYqZd895DRXH4lQo+JFU HlmqxbSvPCJ45px37vnnoEdRWaKhl256GDlWfPrqrGORehVJty7750lnlf9BARnsOvvup+9oL1sM XMDACBZ8Y0AHRPKu/CkQv4z4BYUp8BnyyS9vvSjNO04E9BIUD/P14JeS/UVpjjDM9+GnD0pmKe9S BDcMWJAP+urXv8kCRGfwgIevv2v+RVGznwBXpwEPDPCACEygAhfIwAY68IEQjKAEJ0jBClrwghjM oAY3yMEOevCDIAyhCEdIwhKa8IQoTKEKV8jCFuYhNC6MYRhKIkPr/Wdka4ChF+A1BjHdkAEkG0fd zME3xPWqejUkA9ZolgakNEcJSHMCD8NQtUSNjS5MtNnTcGaynQEAbbsgTxLRUBWffeEYeeHWlPQn hAsgyXJmY9kaY1cFZBX/DADM8ArOjqCSOfVvjGXw1FNMAg2TCOBNAcHYENhGpyIIYDpgesBMGoXF JlQFZWHaERbh2ATXiEmQROjYHvfSR01yEpBhwFbWnPK0BxiwJSbpmzQkJ0mpqDIBznql3VLympn8 R1Z6Y0JV5JUbYOKyXU9YkFGMycoHacCVXDtcnMpjJ1SiYWQMcIb2nhUsG7FGmYPBJjIbV7Yp3apg /Pqeh5AFF985IQRvwgwQsymVknggSVHjh2tCUAES2BEAJLOmGqQiF6GQAE5GqFwCGODOVRUhSR4K SN4WKkxpInSadMQK2HQEFg0UkmlVC4elTinQLryOoNv7EDUBkK3UNRQA/9D7DERTCgCFWtKi5gwc vjg6BF0uQZFCOGm4jEHOt9EUcSUtwwN4A6bEFINeQrhd7uRHLSMslX1J6IlUQ0m/KXTMS5gEmkYn ctWwslSeUcVd/HjxVTONM6lfOAAJ8veLmIhJeMT7Bnrm2jQfBe8NfP1nFEApV7o6L14jwStVwTWE g8LVg4SL60sfe0EkZsGxlBVDQzEQqyp8KbMgzIyFGABVYUYDq6DlIIIM6zyScu1eABBsai0YETHx w7XUg21GZwvBFMUTGywZ5B3jpaB48taCfLFjd4LLI25ENqrHzWD+9rchvSYhZ36hbnQx2D4iBCAD A/GK9OJIE6Bu14LGTf9JLIxyKaal97wt3Ch850vf+tr3vvjNr373y9/++ve/AA6wgAdM4AIb+MAI TrCCF8zgBu/3hwEFlDp8mk+1EKGfgLSsmbQ1QY4o1Bdb9EUsl4pZq/WEpGDbT18fMUU8aHinRUin AquCLIaIGAkBusDm2kveh0YCT3JwbVGbsNuf1i95HoqIbEuAjAAiYcVH2ACTRxdXNDBkslV4iS+k bIDKnOkBTz3nVJkAMVQlYKu/S59HF1DYW6HDrr3A64XvdgQGoSN1OClBBY4XlTYnwVIjaAJmBRI8 EG8HHaC81J2hW2gtAPpTe0aemfh6rDe3KLHDo6oSIAYV8BY60MaTdPr/rpohpy46cKIBtTmo5+S5 WDpJOy5nYtRSaj4iSwKqhkluNSUvJCSAe6Dmcgd2fZjP1jUmUf11qj91vG72RCAMEhyumU3sw9Ra TLAeDZVNleZkby7XzbaspZVmvs+9BjSvi/UQIBA1QiYBL9NU97UeKteL1pl0vWB3q0nwgeMoAQPc 814JPspSufa7VwzJAAaGIHDSttrg/kZCtN/1KYcTDplgi/W2hTBoKREB4KJRXROOUTlUd29+qJgT sqjBLHyz92BImMhW4OXlWuP4KsMrl74JJuQHbGR44/2Vc87pPhgDIOgWL45UZIuvpKiasUgt+jR7 1LEjbNbHqil3V43A/1lgJirnAKg6KcraVOcxYCselR8EmAHK2i1KpfN4Dy/pyJldsVooQrYjNYTO s8S8HLrr7kq4i+OEDMDPe3gcfDU/Q9p9od1aI+q1aopg+LQDECuNP3u51P6K1SpI1rnB9TCkDHfc vDsqLieO0qe7BOjlepvQgHKcRU+NUAlrQ7OCRu3FheUiCO71siGc5H5R8tSb0Ub/zIrrx1uN54Ie 3xAgfQSvnPrIX6wJrGL1Pd9mXiOk+nzbBMAr2df9WWl81VHT5Vu30P04FLBNEahc6P8nfYG63mzu LkIIZC+Fg7/3pgSzfqFQOes1BMOwdnDlUQ4mCUyXCMcnBismY3Eggf9TIF9QUGSnw39dUDNm8IBh wHRCBgcWSAW3ZQUYuEHMBQnrEoJpMCdipAWewoJxIIOL0CsBQRBCwHy7cgskMGiucRtCEAvhsAsk 8Rf1lmVDdlD7NCV8QhdCWAX/x4FKEEt/5CM0Aw4GOBgUaFwocYVGAQFE1Uk1sXFQoIFcIIWWYIME sQCPwXwM8S+8ARCJ4RMg8B/fEA65sRAGsHDmwFRGVIdO4C/sMiVhQofrcHZrOIX/khZYZwQpqHpw OEut0QtZk4hHtxA/pRjyFF65MQznMIKKUYfAZQWWswo4KAaeiBOReAjEEi+69Bjzg0Z5kR3v0G9z mCbkgUzXIQTZgVD/dFEAjYIVQwYPNyIE9AANZmQS8GRhRkcEPoUE3ZRTaEKJCeABy3At1GCBhcgn C+ALeQiG/mBki9RTRKB2YbgEpViN1wiNyigs2mAEPmWO4QhLtCiAfcCHQyCF2Th5xPcl8tIfEgAV GCcu/ZMRfFiFaYZ3sYVQyPAoUxgTMgF5jmhaPMVG/YE4DaAMtDBvTyAYYpKHxYAUTOAVOcISqSiL HVIoHOgzVIggIAOQRWCSdZUXMWFshJAwIDEPhuEmNBEn3fCR3VYRfmME29ANgVhUcrgnQiAcpSF2 adQO7tAunPSAQsEXk/J2HMORTmApdsQXuygQMIdHUhd+VlEoXAWN/4M4h6XnFdumAe0gWoWgKCxx iCgZVF/iGioCK5dWHiWADTohdz05GHsJRZ8hE5qhlDU1EgTRl0kwTG8DhJ+ykY1Zk89GLcTCAAgR DoxJlimJlWJpDn/JBGO4l2xJBC02LOAReGgZdZ95BKWZKKPBEGaYB2UkLn7BPh4iMUVAGXX1RH3X GvpCgXmyFj8RIOQiDSY2Dg+pFnA5BNxwBMrZF7zBFovRLI6xS06wGBURYeWiQ0wQnDyllRS3BDh5 WG2Jlae0I3oYcn2IWuozHr2HH6cZc09Ai/BBBq24BcBxBupJEvkxBRORPG6pHYg1JjGGH7RxnxMk kl41QDHCoDOEIv9GZaALOAoneAX/l0HNM59uMJum0IBeYCu9R0HN82Js4KGRgKJl4Bf2KDsq2mO/ SQpYQwUiAIF1wKFbUKOhAKJOwCRzNJZ8OYKfxUbrVnzU4jKkE0tGYEfWYKSGM1FTQINbtAYsOBPw RkSEYzlNOi0DomFaGiR+sEm/kH/iWAWGxBqYJEnjKCSA4nwcl6ZSgSVZsxVtqoCrcqa18UkzUxqy cY5OIEg0qATlUEkc06cUeKFMYDkdgDl4VKefYSKL1yl7ihsl4KgNUnYwJaeBygbMxBfOBE0i0TeN KJ42swSxNJTENAQDwDJMBktKsHQrNRHN5HevNXRhORirWlUNYxL/oPoEstqafgcVQymN68ZM2Cl+ RFYExlRRFpU4u0Coggd3KmYEnUUtZJKowwd3m7oG4hR6BfQAFRFLzJiTuxAR2jSFEwp4MRp26cAE D/FN4skXfhGN1hWvx2qi1yJOYedj7dqHk2gU5nqv8VCu82SPfDNLE8BPROgA0OCUw0Ws9touz/hk dMaPe4BFDEVQhPSfFIEMg4YoSTKi2xRRzTgkfmoEOtqQQYV64VKxHUeSLGux4/kEH2alMaZSYtI0 LtULG8uhJDkrWOZkEdErHZE10JBi0JJQqMdkzkSBRCtWF8uy0LBjRAKyAZEBIiubR3UoA3Oy1ZRj QYVFWOtxMOM7/zAbng/iAcYgb0uws1DhCnphANimtOHZEmr7VyP5UFnDo7Akt7c6GIVzrM0HFaiy s7uqtsm6CwrFt3HAVNfHUk+1L69Cn8nCgmO2r0V1JhczgvvoLn7YjOoKuGOZs7+QeZPLBKTrIW9R OP8Esul6s0xAVt4hedV0ucDaEkslh/9qFa1rVa9Lqr7SZZIynX4QWHVlpGwLAKxGBJTmBHmFCVuR vCxTWJ+XAW8GZ5gWk6kSuOZgVyEoSGxmvH/2aYgXaVHRvGJgvafGBHxmCVPUatNECnfGqGR2l/2C DmdVfZz5btgrBfbbessWd2wAZvjLOvz2opXgvWIAchUaMNu6O/+QqV+P28Bs4IGgMMEUrAYW7AnZ ygivJwZuSgcjCAgvSoGfgMB98MFhEFmRVARdKLJdkGiG8KJgY1aG4aSSsE8obA0e1X6Cu8F70G6+ 4H8Rx1JX6BQH+IAJW8Q9qgZL/BoEeAUvygvwS8SF6YQJQXuQiK92UFxJFi/BNXpOUWHM6MUZwAur 2xUtKq6tkQH71wTM1zhwOE1JRhchAXQAlE+suZByojVCQH8D1yFu/Hn4goUGGH1DoseoG143xYjI t39nHE52LF6ILMeOHFuQrCv/8xntdltevG4RUQseRX9REnw4JQio4niGDABqp2dNFo0XkwGba6u3 i3+0OCWxjMH/lNt8A4oLr/EaEaDKorxWCNh8gUmrLctwKCdfEciJ67Z2exYxUdOLuuLMitjLNvIA sgxmaiKRrRzNsITNuRw7llfMEpAwaOpJsrym1CIUgbEqzuWWhoAqs8IXYiyLVeE71tvH29GiLUGZ P7q/QOqq1PR5hFxTWAwPoqertbq72wRHiCxjIFgzeShlaEQo6KiRpipNS7c/6puYRxDHr8xR50aY n+JQQ8AhOqquqaPQSIBdCNkHqCJbw1ABCHpH7aIRdkKVbhmVibE/+XkElVGVfuch32XN/8Ncwhcm GhFrljNeN41jQO3URlDTCEqvEseJ/tzTtaWTthKecQy3g/ga/9I7s6ZJBKiaMjotBF9NTT0Shj0y rIPQNBD9caW30kwMAE9oqkRQo2RRE7ErckKgo/bgIUAJauBoITVJBPu31vlIreC4h0vwgz2ChqJr NAXTcWZ50uh6GHPFi5TNC1g8hOLJh0Lh1/pLBLk2SrT8xE2Iev8DjjjTkoZgORD9iab9tYb4q8KU FqJViBMAiG0i2AWqiZSYiBaQireZPew7j1HAXHq4cOKKGH+2hg5Lk59LXMINxqR9LbitrUYc3NWT 3JhYMMydBKmoepecOQW4OgA5whmcoU1AhqWAqBkM0i+9BPRtBSasB7d3397RBMyNRPtdBfDt339r Bv5MBwvOCv/z0RQCbjOuoaK8ENU5wRxUAA9Mthz5oWHwKSSosQTaIQ/RwS7f0QVAbAZTlOJf0OB4 8CQfybQiHiL7rJrTMSAwISM0lJJ2yDHn2gs7DgBtzccisZckMhIlEcIUATlHngT/6xNPIgQbQB04 rgYSSgZcnAZfOph4QEmP0qYzfqvkoZlgLihDZhWUlBiaWcCC+9/K6yhaMsbdWxiWJadxHiVItCPv SKt4WKkhvmmbopOMWnVdwou0aHOu+SeK3Rz2YJPGuCZRZi+Q+pt7EoyRWalPEOhtZOd6IC2WMsJm SwS5ytDWwKRLcBsBEhi0cLJCc6vVOipFtTR7o0q+wLSWVRr/uYJHfmLrSxAiKlOsWSJrBaIXAYAi B+2aa04gSW4Nxq53LddtMFFE7igtXZHsW9nBb60HOBlQAp2WnE3Lptc4BJcE5WkzBcHqsJW/wNsu 6MI1FigU5kIqSFQa0ADrZ24E7eIt0nC0smYNzGnD0Am1b1hsRrdtaBGblK4a4GnuD9HfRwS1d7BE sLsEK43M6o4bH/A0MotErHIuPAKYMOEVL3gzq9JF+j0zNZPxTTvZVQQA+Fig4qDySl7xchMXsuYc 6TEiPCYSOc/OqZl6OwMXtXA0V7QV4nClnfR3er0HUFouSm4pmtQsGj/wnc0u5mEX5+HrZyuRFqvI bYtFzaTk/1EFtqwZGEMEluFZhfxuN7TmrLBhm0Z4qwj5EnEd7ixVC1RdqruaTEahUCxOB3ZKBafU 353imoBy7ZOT4JEQSQuALOuyHCZySJCkyzzh5+eR5JI/aNgWTBVr1rgAp5nKNn8iG0+QSZIyp6XQ SgpES1EPo+F84FKPpGnE0X/L+d8Dy2xkS17HbLLvBGqaOfa0QCi8Xfhq3/WzYg9cCN2dOVh/gYCQ /IvAgln+81v3BSoDw6EA+0dw3pZxBdwv1F3AuFmg/ZSHBdki/lpA/p+QFbuiZ8pbFdTLo592YeHG vlZAvaLTBYRvBX7RceoLBAbAkFg0HhcHkqiYMTyPx1LF0P8hMgDL6DZK7Wi4xSfhETaf0Wk193BY JI5C48W4KVU1efDQnZg8yrguJCRGFIbuvvKK3v7C4AhHzvomjMYCjyDWNjnX8PaIFor+ngwIiuiK NuzwitoaiR5K5+oSFwEeKM8SBiUsFdEu4TqJi4tzST4mKsWOUolKhvZus5rCei00AbCIQAGUJwwy iOSIMLC1wz6OGEwfEoYBCLPT9RYxh8rDfIs09bgMMGh3asi4XkYg/CuyjgizIfieISrBICE1JeCK cKNVJFq3hweGONyS4dw8I97MuINnjGVLNCCJjOt3hB80adJAiWrIpYAEBoa0aQTgzY8Th+mG9CSC dEs8c4z/hvgEuqGbvVwwAThBI6mf1S0QMGCAMCDQg54/DxVBOcSpSCM1JarlQ0nmEAxR4ALoeBMA 1rpb8KX1iEYs2QQ6XSZWzCcM06FGOk4DxTAkFw4zAXyi9sEPoKNGLi/dxQ7qY5s49ZTBii+MBSNf Ym0JSPEAtwyhATBdC8ApPqEoS+w1jRVXxijA5faNHeav7jRCES+Wbow4a4JF8nLbI5CIiAkZHnwX VEgBBKqoNWhkEpPI9SERz4f5jk+fTriR7TEQtYAJ+DSC+RoiOnJKIWMYoZw7QqQC38HOCO4Gc8M7 /8gh460HDbCHsYfMQPCkNFRaYMDpSFzjAM7+sK5BIvKS/2MPQIjoLDwzyDMvCkxkdGQI9+RRBQ0Y iYjAQBGj4ijADeFgLQwATdvQEiOGiUg3DTwwwi0DhGStRc2qHAJFINvT8ghFQFnNjF6A+jCNIUcs 0c0zwAkhigQaeNMMPRjAZ4IQlilHzNM4eaeBCogACoKJ0MsTpmXkTCNBJzMyxcA6AZDyiPSI4Wqp iqjhRFPFarRT1FFJNUYPfbhQ0s3y7NDo1DbYU+NR5aKAoI13CG0SgPhIhKLUX4ENVthhibVSx2JF JQTZZZlt1gxVOyHO2TPEI/ZTNbSa9ldoiWlTW2C53UTab8kF4Fo0Jiggol+ZFDZcTigDwK1y6TWC hHrDaP902HapLZVSzIqd15j1KsO3k4Cg+AdWKE01oI14jQApgVyJKC8guyKO5R2BjTjk4h+Ltbgd tRyW1g8QQJm4hAGF8JWch8+gWLRihNo1JZhjnBmAClZGTJN2XM7s4bYMfigBda0gosoF9oJAoCck 0COEh+N1apsEPIgXAqd/02DqE7lYgAGsiQSAnqd7dCUkQI5eNxOu9fH66yLeJeYddc3Y+mkXvcaZ LaSHGDtrpjMCuqa+T+SYrcFnApqTms+DW62vlckZgA4iWPwDpiPf2wB+EK+ciAKK1msCDCQwhYgK Ni9Bm7j3IGilnWKhk3WdRB75SKvpHqbs3IVYRAg3Cnr/oKO8MpGjHA0k7QPQGAeFeDZUCXAelxJO T70xB4cyxfqnLEek8AC9h4WL6KObPur2vp+zznVcz039CnUJCfVy0I8/s9/yGaWIu4rWG2joJGmw GwIF2OIU0sVkYl4awtYQtrwi8C5W32AIBB33GDlV52i44YJjhhICClDgRPGwWgZUtoB4RbAmIixh Je7GAQ1k7oPc8xoJOQOaCfroClFwIYrMIJx8uGoIP/RDGAglisixkAhGdEgBZFgEnqlwAwVUk77k VQQP1kskmBDiNtSyh0WJZIFXmOJS5tc/2s0JGh1BCugAcArEBKInIGxGHKpXvyxOkAFTFM7T1rcj 4mXF/3R15NGTBqMPt8DFQz08gnv+EoUv8i+OdEEiAETxOkCCApKjy811ZLYdNXWSRaXr4vMCF8YN LaMIZQzcGR+Yxsz4ryltfKAN44jJ5dQxJVHwnh7dkoA+ruyP7QhkJXUyDuwZMgxxU2PBSunIW0qz CKTkwiSTU71GRNIISczNEI3JSWsk5ZOrS07NYjfOIhVNJBoZkeEUMkYtFsEBAvpA5LgntBdyoZ5D WEUsDSeNklFmYzK0Izl8aaU1DsEBBljZPckBT1cAkTdqA4hE9UnRweTjoRtACqrm8iUzvDM5QzuW JKn4uuT05YWYCE1tEJFSUZa0pSvFV08wJ7ZQ+JIB6/8TY0hEApcEQKB1coBbT12ROMXFw2VPE8oG oYTTM9SsiG1Qqid3iNBUbnSMQjiaBHIaBqfC5WHzShoRiorII1x1pHcwToTuGLZZBq4dPfUGW9cJ RgHdARToJIJS9XFWfGFAAxCw0E6ls4HWjcKYpYuCG8xnl8LGQrFMK8cEwlmmbcqBsIZ17BbcSk0x bvZxn9vNrw6qLbd91mCY4wjnLGFabzSibqxdA21tm1vk5Za3vfXtb0llK+AOl7jFNe4aIBCBFZ3h tMclhuKcG13pckIbFDwOby3ZDcOuqKgMQEmn1Dld8Y43Da7lTTw2kKHvakAAWCzaRWREBMy9YyWc Uy//dvIggBuRl7/9/YqR9BKQPOAjDwZA4PboS6OMTUdamEBKNLxlGpAWx78V9q+tGOAABjCEV6xp bj9qo2HKmLZLaftrh0TsT3l4oMRrrSFav7GFQDrsCDKz8I2layBh6mTCWjXDYXW5vzxASHh9uVeq 4KEfUQhYIFQdwhL6JBwd6yfA3lUTpMSHYy1H1z08fquPw9DlZ+r1MUKIMId2+jEyH0FGKwsTPGRy ByuHkXkPGNEXt5xn3+ppbQERbhMY4Jow8HmPThrHOATNBroVmlbMjQ3Y0MzmDBQgA4HOhJ4xDdzo 1KVAURhBorew6YIsOnAX+AmoH7vov0DrUTrxzqjZtUgEVF8u07W2NaTKwiAHnWuttC0DPljNCmA4 yRGkGEP4ANCuD9+a2XkeSG23AA7lZVWSFOkUcYQQjmeDb5rN9va3wR1ucY+b3OU297nRnW51r5vd 7Xb3u+Edb3nPm971tve98Z1vfe+b3/32978BHnCBD5zgBTf4wRGecIUvnOENd/jDIR5xiU+c4hW3 +MUxnnGNb5zjHff4x0EecpGPnOQlN/nJUZ5yla+c5S13+cthHvPfBgEAOw==^% --%^V9^%-- From fdn@divine.com Sat Jun 23 05:59:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I22P0-0001u9-Q6 for pana-archive@lists.ietf.org; Sat, 23 Jun 2007 05:59:34 -0400 Received: from [210.116.133.125] (helo=vwfcdp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I22Ov-0001cT-BY for pana-archive@lists.ietf.org; Sat, 23 Jun 2007 05:59:34 -0400 Received: from vceyx ([154.163.231.115]) by vwfcdp with Microsoft SMTPSVC(6.0.3790.211); Sat, 23 Jun 2007 18:58:49 +0900 Message-ID: <467CEED9.3080506@divine.com> Date: Sat, 23 Jun 2007 18:58:49 +0900 From: Annie Womack User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: sporadic rock Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb SREA Acquires $75 Million Dollar Asset! Score One Inc.(SREA) $0.30 News hit just after close. SREA has acquired the $75 Million peace of land for the new "Recreation Town" in Dalian. This new project mimics a Facility in "Shui On" that profited more than $100 Million USD. SREA is going to go through the roof after this hits investors this weekend. Get on SREA at open on Monday! After school we would go out to the date palm grove with the freshly caught fish from the river Hidekel, which we would barbeque in the fields over an open fire. Very little information has come out of the meeting in New York, which has been held behind closed doors, but the United Nations is expected to announce a resumption of further talks soon. I'm sure it will be over soon once money has been paid and statements of regret signed. recovery and competitive capability". It's a nerve-wracking time for everyone, especially for women and their families who always worry. This was normal in our air force; we flew what was available. During a visit to Bulgaria last week, US President George W Bush appealed for the release of the medics. "Since last week's events it's been extremely difficult to arrange that given the change of procedures, and change of authorities. No peace is possible in the Middle East without solving their problems. Sainsbury's releases its first quarter results on Wednesday, and is tipped to have seen further growth, driven in part by greater demand for organic and its premium Taste The Difference range. She raised US concerns about the flow of foreign fighters into Iraq. Some people are happy with this and some are not. "It would be easy to blame Hamas, Fatah, or the two together and to announce our support for one or the other," the daily says. The US administration has made it clear, however, that it is looking to expand cultural exchanges between the two nations. This is the fundamental stumbling block to the problem that has defied diplomats for decades and continues to do so. I took off without a pause. From pana-bounces@ietf.org Sat Jun 23 18:32:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2E9s-0000gC-QP; Sat, 23 Jun 2007 18:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2E9r-0000g6-M1 for pana@ietf.org; Sat, 23 Jun 2007 18:32:43 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2E9q-0006AA-C7 for pana@ietf.org; Sat, 23 Jun 2007 18:32:43 -0400 Received: from [88.235.57.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1I2E9g3LM6-0001co; Sat, 23 Jun 2007 18:32:39 -0400 From: "Alper Yegin" To: "'Mark Townsley'" , Subject: RE: [Pana] IESG Review of protocol and framework documents Date: Sun, 24 Jun 2007 01:32:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace0xB3OLd5/4N5mTyulJMX6KrkE7QBHxQug In-Reply-To: <467BB868.2050601@cisco.com> Message-ID: <0MKpCa-1I2E9g3LM6-0001co@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+Mx+t47carrYQ+4Z7t2hjyeK3V7OW5VAPtlFz xXIWWgod8LVz3F56SYPKzIYk8SIi98K2uigILcM/8MN9g2D1+D LGLRBupltMAxcW2ct/ePw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'Jari Arkko' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hello Mark and Dan, > Dan is asking about SNMP. I understand that we have gone in circles with > respect to whether SNMP is required to be implemented or not, and it > looks like the result was confusing to Dan. We either need to revive the > SNMP document, or kill it off completely in the WG and in these specs. The WG was originally scoped to work only on the PaC-to-PAA protocol (PANA). Later the WG was asked by our previous AD to also define at least one protocol for the PAA-to-EP leg. We ended up embarking on that work to define a complete picture. Irrespective of the EAP peer (e.g., PaC) to authenticator (e.g., PAA) protocol (e.g., PANA, PKMv2, IEEE 802.1X, HRPD), there is need for an authenticator to enforcement point protocol when the two are separated. Today there are numerous protocols used for that (e.g., R6 in WiMAX, CAPWAP in WiFi, Rp in 3GPP2, and IETF's upcoming ANCP in DSL). Defining an architecture-neutral protocol is a good task, but I'd say it's better scoped as a work item for a separate WG. For that reason, I'm leaning towards putting that work aside for PANA WG. If and when IETF decides to tackle generic authenticator to enforcement point protocol, draft-ietf-pana-snmp can be a useful starting point. Let's see if there is any objection from the WG. And Dan, would that (removing pana-snmp references from our documents) an acceptable resolution to your Discuss comment? Regards, Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sun Jun 24 03:18:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2MMO-0008J1-5C; Sun, 24 Jun 2007 03:18:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2MMM-0008Ip-6T for pana@ietf.org; Sun, 24 Jun 2007 03:18:10 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2MMK-0002S2-Ms for pana@ietf.org; Sun, 24 Jun 2007 03:18:10 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5O7HQsQ078122; Sun, 24 Jun 2007 03:17:26 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1I2MIO-0002Bn-V5; Sun, 24 Jun 2007 03:14:04 -0400 Date: Sun, 24 Jun 2007 03:14:02 -0400 To: Mark Townsley , magnus.westerlund@ericsson.com Subject: Re: [Pana] IESG Review of protocol and framework documents Message-ID: <20070624071402.GC7164@steelhead.localdomain> References: <467BB868.2050601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <467BB868.2050601@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -2.4 (--) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: Jari Arkko , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Ansering to Magnus Westerlund's comment: >Magnus Westerlund: > >Discuss [2007-06-20]: >What language is used to provide the declarations present in section 7.2 to 7.7? >A reference to the defintion of this language is required. (Mark: I believe this comment is different from the language issue we discussed in the past about Notification AVP which was removed from the specification.) The language used to provide the declarations present in section 7.2 to 7.7 (and 7.1 as well) is ABNF. We have some text on this in section 7: " PANA message definitions include a corresponding ABNF [RFC4234] specification, which is used to define the AVPs for that PANA message type, and whether or not each AVP is Mandatory. The following format is used in the definition: " I think we can revise this text to address your comment: " PANA message definitions include a corresponding ABNF [RFC4234] specification, which is used to define the AVPs for that PANA message type, and whether or not each AVP is Mandatory. The following format is used in the definition described in Sections 7.1 through 7.7: " > >Section 9. > >There is unclarity on if IRT is absolute time value or an amount of time. Based >on the formulas the later, but that is not clear in the text definitions. Also >the definition of RT is a bit of. RT is the amount of time from the previous >transmission, while the intitial defintion may mislead one to think it is an >absolute time. How about revising the RT and IRT definition as follows? from: " RT Retransmission timeout IRT Initial retransmission time " to: " RT Retransmission timeout from the previous (re)transmission IRT Base value for RT for the initial retransmission " Also, the following text should be revised: " RT for the first message transmission is based on IRT: RT = IRT + RAND*IRT " to: " RT for the first message retransmission is based on IRT: RT = IRT + RAND*IRT " Best Regards, Yoshihiro Ohba On Fri, Jun 22, 2007 at 01:54:16PM +0200, Mark Townsley wrote: > > PANA Folks, > > Yesterday, the IESG balloted draft-ietf-pana-pana-17.txt (Proposed > Standard) and draft-ietf-pana-framework-09.txt (Informational RFC). > While there are a handful of DISCUSS positions that we need to work > through, all of you who worked hard on this revision should be > commended. In particular, a rare word of praise from Sam Hartman: > > "[2007-06-21] First, I'd like to compliment Mark and the PANA working > group on the > excellent work they have done over the last year. I fully expected to > be unable to support publication of PANA when it came to the IESG. > While I do have some blocking comments, I think they are easy to > resolve and expect to be able to remove my discuss when that happens. > What an excellent job making PANA easier to understand and removing > complexity." > > I would like to especially thank Yoshi, Alper, Raj and Jari for all of > their hard work and perseverance, and the WG for their patience during > this process. > > But there is still a final hurdle to leap. The IESG ballot (one ballot > for both documents) detail is here: > > https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1723&filename=draft-ietf-pana-framework > > There are 3 Discuss positions which need to move to Yes or No-Obj for > the document to pass. If any one moves to Abstain, then the document > will be in danger of not passing as there are a number of "open > positions" here (all documents require 1 Yes and 2/3 of IESG members > voting Yes or No-Obj). > > Dan is asking about SNMP. I understand that we have gone in circles with > respect to whether SNMP is required to be implemented or not, and it > looks like the result was confusing to Dan. We either need to revive the > SNMP document, or kill it off completely in the WG and in these specs. > > Magnus has concerns about languages. I remember a review we did with the > ltru chairs which perhaps we never fully closed the loop on, please > contact Martin Duerst duerst@it.aoyama.ac.jp and Magnus directly to sort > this out. > > Sam seems most concerned about: > - Versioning > - IP address reconfig > - underlying link security > - which messages need an AUTH attribute and which do not, explicitly > - new hash algorithm migration > - discussion in the security considerations, moving some "requirements" > to "tradeoffs" > > I think all of these can be resolved with some discussion and one more > revision on the text, as such I have moved the documents to Revised ID > Needed. Once we have a new version which alleviates the concerns listed > here and the ADs have changed their position to Yes or No-Obj, the > documents will be approved. > > - Mark > > > > > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sun Jun 24 03:23:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2MRe-0000nU-03; Sun, 24 Jun 2007 03:23:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2MRd-0000mv-9u for pana@ietf.org; Sun, 24 Jun 2007 03:23:37 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I2MRb-0002dA-PK for pana@ietf.org; Sun, 24 Jun 2007 03:23:37 -0400 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5O7I4F8078125; Sun, 24 Jun 2007 03:18:04 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1I2MJ1-0002Bu-CA; Sun, 24 Jun 2007 03:14:43 -0400 Date: Sun, 24 Jun 2007 03:14:41 -0400 To: Mark Townsley , lars.eggert@nokia.com Subject: Re: [Pana] IESG Review of protocol and framework documents Message-ID: <20070624071441.GD7164@steelhead.localdomain> References: <467BB868.2050601@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <467BB868.2050601@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Jari Arkko , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Answering to Lars Eggert's comments: >Lars Eggert: > >Comment [2007-06-20]: >Section 4.1., paragraph 12: >> It is possible that both the PAA and the PaC initiate the PANA >> session at the same time, i.e., the PAA unsolicitedly sends the >> initial PANA-Auth-Request message while the PaC sends a >> PANA-Client-Initiation message. To resolve the race condition, the >> PAA MUST silently discard the PANA-Client-Initiation message received >> from the PaC after it has sent the initial PANA-Auth-Request message. > > And what must the PaC do when it receives the PANA-Auth-Request from > the PAA that it didn't expect to get in response to its > PANA-Client-Initiation message? In this case, the PaC will think that another PANA session is initiated by the PAA it did not expect to get in response to its PCI message. For that PAA, the following rule in Section 4.1 shall apply: " When the PaC receives the initial PANA-Auth-Request message from a PAA, it responds with a PANA-Auth-Answer message, if it wishes to continue the PANA session. " I think that we can further clarify the text to describe the behavior when it does not wish to continue the PANA session as follows: " When the PaC receives the initial PANA-Auth-Request message from a PAA, it responds with a PANA-Auth-Answer message, if it wishes to continue the PANA session. Otherwise, it silently discards the PANA-Auth-Request message. " >Section 6.1., paragraph 2: > >> For any PANA message sent from the peer that has initiated the PANA >> session, the UDP source port is set to any number and the destination >> port is set to the assigned PANA port number (to be assigned by >> IANA). > > > "source port is set to any number" - it'd probably be good if the node > were able to receive packets sent to that port. > > Also, to make this work, you need to also require that all peers > listen on the PANA port. How about revising Section 4.1 as follows? from: " 6.1. IP and UDP Headers Any PANA message is unicast between the PaC and the PAA. For any PANA message sent from the peer that has initiated the PANA session, the UDP source port is set to any number and the destination port is set to the assigned PANA port number (to be assigned by IANA). For any PANA message sent from the other peer, the source port is set to the assigned PANA port number (to be assigned by IANA) and the destination port is copied from the source port of the last received message. In case both the PaC and PAA initiates the session (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request messages cross each other), then the PaC is identified as the initiator. " to: " 6.1. IP and UDP Headers Any PANA message is unicast between the PaC and the PAA. For any PANA message sent from the peer that has initiated the PANA session, the UDP source port is set to any number on which the peer can receive incoming PANA messages and the destination port is set to the assigned PANA port number (to be assigned by IANA). For any PANA message sent from the other peer, the source port is set to the assigned PANA port number (to be assigned by IANA) and the destination port is copied from the source port of the last received message. In case both the PaC and PAA initiates the session (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request messages cross each other), then the PaC is identified as the initiator. All PANA peers MUST listen on the assigned PANA port number (to be assigned by IANA). " >Section 7., paragraph 7: >> message-name = PANA-name > > ABNF warning: rule message-name previously referred to as Message-Name OK, s/message-type/Message-Name/. Best Regards, Yoshihiro Ohba On Fri, Jun 22, 2007 at 01:54:16PM +0200, Mark Townsley wrote: > > PANA Folks, > > Yesterday, the IESG balloted draft-ietf-pana-pana-17.txt (Proposed > Standard) and draft-ietf-pana-framework-09.txt (Informational RFC). > While there are a handful of DISCUSS positions that we need to work > through, all of you who worked hard on this revision should be > commended. In particular, a rare word of praise from Sam Hartman: > > "[2007-06-21] First, I'd like to compliment Mark and the PANA working > group on the > excellent work they have done over the last year. I fully expected to > be unable to support publication of PANA when it came to the IESG. > While I do have some blocking comments, I think they are easy to > resolve and expect to be able to remove my discuss when that happens. > What an excellent job making PANA easier to understand and removing > complexity." > > I would like to especially thank Yoshi, Alper, Raj and Jari for all of > their hard work and perseverance, and the WG for their patience during > this process. > > But there is still a final hurdle to leap. The IESG ballot (one ballot > for both documents) detail is here: > > https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1723&filename=draft-ietf-pana-framework > > There are 3 Discuss positions which need to move to Yes or No-Obj for > the document to pass. If any one moves to Abstain, then the document > will be in danger of not passing as there are a number of "open > positions" here (all documents require 1 Yes and 2/3 of IESG members > voting Yes or No-Obj). > > Dan is asking about SNMP. I understand that we have gone in circles with > respect to whether SNMP is required to be implemented or not, and it > looks like the result was confusing to Dan. We either need to revive the > SNMP document, or kill it off completely in the WG and in these specs. > > Magnus has concerns about languages. I remember a review we did with the > ltru chairs which perhaps we never fully closed the loop on, please > contact Martin Duerst duerst@it.aoyama.ac.jp and Magnus directly to sort > this out. > > Sam seems most concerned about: > - Versioning > - IP address reconfig > - underlying link security > - which messages need an AUTH attribute and which do not, explicitly > - new hash algorithm migration > - discussion in the security considerations, moving some "requirements" > to "tradeoffs" > > I think all of these can be resolved with some discussion and one more > revision on the text, as such I have moved the documents to Revised ID > Needed. Once we have a new version which alleviates the concerns listed > here and the ADs have changed their position to Yes or No-Obj, the > documents will be approved. > > - Mark > > > > > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sun Jun 24 03:26:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2MUU-0001HI-T4; Sun, 24 Jun 2007 03:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2MUT-0001HA-UU for pana@ietf.org; Sun, 24 Jun 2007 03:26:33 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2MUT-0004Kb-J4 for pana@ietf.org; Sun, 24 Jun 2007 03:26:33 -0400 Received: from [88.235.57.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1I2MUJ3nNM-0001aT; Sun, 24 Jun 2007 03:26:31 -0400 From: "Alper Yegin" To: "'Romascanu, Dan \(Dan\)'" , "'Mark Townsley'" Subject: RE: [Pana] IESG Review of protocol and framework documents Date: Sun, 24 Jun 2007 10:26:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace0xB3OLd5/4N5mTyulJMX6KrkE7QBHxQugAA+jYyAAAvbtcA== In-Reply-To: Message-ID: <0MKpCa-1I2MUJ3nNM-0001aT@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+2IsfyJAeeIC5NhRbObIrpFKvAirxWmkZ6Qku rBdlZt+7KlS75/gc3k0NdDh0VkCKIlLgE2c/FU2nYY77hmVmwe DwA5OBynvEkvT1IMp6yLA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: 'Jari Arkko' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Dan, RADIUS, Diameter, +-----+ PANA +-----+ LDAP, API, etc. +-----+ | PaC |<----------------->| PAA |<------------------->| AS | +-----+ +-----+ +-----+ ^ ^ | | | +-----+ | IKE, +-------->| EP |<--------+ SNMP, API, etc. 4-way handshake, +-----+ etc. . . . v Data traffic According to our framework, as illustrated above, PANA is part of a larger picture that includes other protocols running between various entities. While the core protocol work of PANA WG is running between PaC and PAA, we are also showing protocols between PAA-to-AS, PAA-to-EP, and PaC-to-EP. The PaC-to-EP protocol is very much access technology specific. E.g., PKMv2 in WiMAX, 802.1X 4-way handshake in WiFi, etc. We list them informatively. The PAA-to-EP protocol is also architecture specific. WiMAX uses R6, some WiFis uses CAPWAP, some ADSL would be using ANCP, etc. I think what we can do is, like we did for the PaC-to-EP protocols, we can informatively list the protocols (excluding SNMP) that are used for the PAA-to-EP leg. Alper > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Sunday, June 24, 2007 8:57 AM > To: Alper Yegin; Mark Townsley > Cc: Jari Arkko; pana@ietf.org > Subject: RE: [Pana] IESG Review of protocol and framework documents > > > And Dan, would that (removing pana-snmp references from our > > documents) an acceptable resolution to your Discuss comment? > > > > Do you mean removing the references to draft-ietf-pana-snmp, or removing > any reference to using SNMP as the protocol for an authenticator to > enforcement point when the two are separated? > > If you eliminate the reference but still mention SNMP as an optional > solution for PAA-to-EP communication you would need to add some more > information (even high level) about how this is supposed to work (I > could not understand this in the absence of the now Dead draft). You > must show in Section 2 of draft-ietf-pana-framework and in Section 11.6 > in draft-ietf-pana-pana what kind of SNMP entities (agents, managers) > need to be implemented and how these are mapped in the PANA entities (in > the server for PANA, in per-packet access control entities) when these > are separated. > > If you completely eliminate SNMP you are left with answering the > question of what will be the PAA-to-EP communication protocol. > > Dan > > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Sunday, June 24, 2007 1:32 AM > > To: 'Mark Townsley'; Romascanu, Dan (Dan) > > Cc: 'Jari Arkko'; pana@ietf.org > > Subject: RE: [Pana] IESG Review of protocol and framework documents > > > > Hello Mark and Dan, > > > > > Dan is asking about SNMP. I understand that we have gone in circles > > > with respect to whether SNMP is required to be implemented > > or not, and > > > it looks like the result was confusing to Dan. We either need to > > > revive the SNMP document, or kill it off completely in the > > WG and in these specs. > > > > The WG was originally scoped to work only on the PaC-to-PAA > > protocol (PANA). > > Later the WG was asked by our previous AD to also define at > > least one protocol for the PAA-to-EP leg. We ended up > > embarking on that work to define a complete picture. > > > > Irrespective of the EAP peer (e.g., PaC) to authenticator > > (e.g., PAA) protocol (e.g., PANA, PKMv2, IEEE 802.1X, HRPD), > > there is need for an authenticator to enforcement point > > protocol when the two are separated. > > Today there are numerous protocols used for that (e.g., R6 in > > WiMAX, CAPWAP in WiFi, Rp in 3GPP2, and IETF's upcoming ANCP > > in DSL). Defining an architecture-neutral protocol is a good > > task, but I'd say it's better scoped as a work item for a separate WG. > > > > For that reason, I'm leaning towards putting that work aside > > for PANA WG. If and when IETF decides to tackle generic > > authenticator to enforcement point protocol, > > draft-ietf-pana-snmp can be a useful starting point. > > > > Let's see if there is any objection from the WG. > > > > And Dan, would that (removing pana-snmp references from our > > documents) an acceptable resolution to your Discuss comment? > > > > Regards, > > > > Alper > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sun Jun 24 09:53:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SX7-00006h-It; Sun, 24 Jun 2007 09:53:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SX5-00006c-9D for pana@ietf.org; Sun, 24 Jun 2007 09:53:39 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2SX4-0004vY-Nr for pana@ietf.org; Sun, 24 Jun 2007 09:53:39 -0400 Received: from [88.235.57.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1I2SWu0w2E-0002tb; Sun, 24 Jun 2007 09:53:35 -0400 From: "Alper Yegin" To: "'Sam Hartman'" Date: Sun, 24 Jun 2007 16:53:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace0xB3OLd5/4N5mTyulJMX6KrkE7QBjZhjw In-Reply-To: <467BB868.2050601@cisco.com> Message-ID: <0MKp8S-1I2SWu0w2E-0002tb@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+mU11Brv3JtpTg27OC+I6ntJ+LpajDU6TBwsA i5NH0iSmRJBAbcm1puQz3BPmH3scKOOFJlVOfjS8+vlz0ppxrP +ItnAqA5vcgDVvzMhxNrA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: 'Mark Townsley' , 'Jari Arkko' , pana@ietf.org Subject: [Pana] Sam's IESG comments X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Sam, Thank you for the review and comments. Please see below for proposed resolutions and let us know what you think. Discuss [2007-06-21]: First, I'd like to compliment Mark and the PANA working group on the excellent work they have done over the last year. I fully expected to be unable to support publication of PANA when it came to the IESG. While I do have some blocking comments, I think they are easy to resolve and expect to be able to remove my discuss when that happens. What an excellent job making PANA easier to understand and removing complexity. -> Thank you. What must a receiver do if it receives a PANA message with unknown version? How is the version field actually useful? (How do you get backward compatibility if you discard packets with unknown version?) -> I think version number must be updated only when we are about to introduce an incompatible change. So I think (not sure though), if an implementation receives a message with an unknown version number, it shall silently ignore the message. I think a peer with version N+M cannot really speak to another peer with version N unless the former implementation can also behave like version N. -> Does this make sense? The framework document says that sometimes a PAC is expected to reconfigure its address after PANA. The PANA protocol has no normative discussion of this. In order to get interoperable implementations, you need to clearly indicate when address configuration is required. Perhaps you are deferring this to future documents. If so, then the framework should indicate that unless a PAC implements a protocol extension that mandates address reconfiguration and that protocol extension is used, then the PAC need not do address configuration. Or, if address reconfig is supported in the base protocol, you need to have normative language describing it. -> We had thought about it and even designed an AVP to tell PaC what mechanism to use for re-configuration. Version 12 of the spec included not only an indication that the PaC shall reconfigure a new IP address but also the name of the mechanism to use (DHCPv4, DHCPv6, stateless addr. autconf, IKEv2, etc.). -> Then we realized we were stepping outside the scope of the access authentication, and we decided to remove it. We decided that anything with IP address configuration is outside the scope. -> Would you suggest we re-introduce what we had but only with a one-bit info that says "PaC shall configure a new IP address" (without enumerating any specific address config mechanisms)? The framework document talked about a lot of options having to do with the underlying link and security. It seems that the mandatory to implement behavior from the protocol document is support for integrity of PANA messages using EAP methods that produce MSKs but no mandatory to implement support for link security either at layer 2 or 3. If so, please make this clear in the framework document. If not, explain what I'm missing. -> That's right. -> In the introduction section, we had said: PANA is intended to be used in any access network regardless of the underlying security. For example, the network might be physically secured, or secured by means of cryptographic mechanisms after the successful client-network authentication. -> How about if we extend it to say: PANA is intended to be used in any access network regardless of the underlying security. For example, the network might be physically secured, or secured by means of cryptographic mechanisms after the successful client-network authentication. While mandatory to implement behavior for a PANA deployment is the integrity of PANA messages when the EAP method produces MSK, there is no mandatory to implement support for network security either at the link-layer or network-layer. Section 5.5 of the protocol document should include a rule that messages expected to have an auth attribute but which do not do so MUST be discarded. You need to specify which messages are expected to have auth attributes (presumably all of them after a completed authentication with an EAP method that generates an MSK). -> We shall change o When an AUTH AVP is included, the AVP value matches the hash value computed against the received message. -> To O Once the PANA authentication succeeds using a key-generating EAP method, the PANA-Auth-Request message that carries the EAP Success and any subsequent message in that session contain an AUTH AVP. The AVP value matches the hash value computed against the received message. Please describe how PANA will migrate to a new hash. You need a negotiation mechanism so that one side can determine the capabilities of the other and so that you can maintain backward compatibility when deploynig a new hash or PRF. -> I'll leave that to Yoshi as he's the one who introduced the algorithm AVP inspired from IKEv2. But in general let me ask: Does that mean we shall let PAA send "a list of algorithms" and PaC choose one during the very first PANA message exchange? I am not sure the algorithm AVP quite gives you this. Also, you SHOULD protect your negotiation after the fact so that if an attacker modifies the unprotected negotiation then the modification will be detected. -> We already include the negotiated algorithm in the very first authenticated PANA message exchange (the one that carries the EAP success from the PAA to the PaC, and its response). I'm particularly concerned that even if the algorithm AVP is sufficient, you recommend against using it unless the link is secured. That seems highly problematic; protected negotiation is a better solution. -> We allow inclusion of the Algorithm AVP in the very first message, so that in case of a mismatch the PaC can decide not to continue. But in case the link is not secured, that "early negotiation" is susceptible to spoofing. So we wanted to warn the deployments. Would you recommend we remove that warning? And would that not have an impact on the PaCs being turned down due to a spoofed message? I am uncomfortable with the claim in the protocol document's security consideration section that physical security provides protection of confidentiality and spoofing. I'm not really sure that is true in any reasonable sense for DSL lines. I think a better way to state this is that the environment provides adequate protection against spoofing and confidentiality based on the operational needs of the environment. Similarly, I'm concerned that the blanket claim that if a link does not provide security then security is required at a higher layer. I agree that PANA integrity protection is required, but for example I don't see why data origin authentication or connectionless integrity is required for most Internet traffic. I think the security considerations section could be reworked to talk a lot more about tradeoffs and a lot less about hard requirements. Some hard requirements are probably still necessary. -> We can remove references to any specific network types (DSL/3GPP2), and physical vs. cryptographic security. -> I think what we are really concerned is data origin authentication, integrity and replay protection (not confidentiality, like the current spec is saying). Those are important, because they are the primary tools for enforcement points in policing the data traffic. Unless there is a way to perform data origin authentication, the enforcement points cannot distinguish traffic of authenticated clients from unauthenticated clients. -> Based on these, I'd propose we change An important element in assessing security of PANA design and deployment in a network is the presence of lower-layer (physical and link-layer) security. In the context of this document, lower-layers are said to be secure if they can prevent eavesdropping and spoofing of packets. Examples of such networks are physically-secured DSL networks and 3GPP2 networks with cryptographically-secured cdma2000 link-layer. In these examples, the lower-layer security is enabled even before running the first PANA-based authentication. In the absence of such a pre-established secure channel prior to running PANA, one needs to be created after the successful PANA authentication using a link-layer or network-layer cryptographic mechanism (e.g., IPsec). -> To An important element in assessing security of PANA design and deployment in a network is the presence of data origin authentication, integrity and replay protection by the lower-layers. In some networks, this level of security is already enabled even before running the first PANA-based authentication. In the absence of such a pre-established secure channel prior to running PANA, one needs to be created after the successful PANA authentication using a link-layer or network-layer cryptographic mechanism (e.g., IPsec). I am uncomfortable with the recommendation of eap methods like md5 even when link security is available. Can you please work with the EAP and EMU working groups and see if they support this recommendation in the framework document? -> We didn't really mean to recommend use of any EAP method. For that, we shall remove the statement "For example, weak authentication methods, such as EAP-MD5, may be used for such networks but not for the others." Comment [2007-06-21]: The PANA protocol document says that the derivation of keys for use in setting up or binding to link or layer 3 security is out of scope. That's fine and probably even a good idea. however there needs to be a single document that specifies this derivation that all the uses of the PANA SA end up referring to. IT would be inappropriate for the PANA IPsec document to use one method and say a method to set up preshared secrets for 802.11I to use another mechanism that might interact badly with the ipsec mechanism. -> Would the following take care of this? -> Currently PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID) -> We could change this to: PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID) PANA_SECASSOC_KEY = prf+(PANA_AUTH_KEY, Key_Name) -> The PANA_SECASSOC_KEY SHALL be used as the root key for any secure association key management for securing link-layer or network-layer. Key_ Name is a string and it SHALL be assigned by a separate specification that describes how PANA-generated keys are used with the specific secure association protocol (e.g., "SECURE ASSOCIATION ROOT KEY FOR IKE-IPSEC", "SECURE ASSOCIATION ROOT KEY FOR IEEE 802.11I".) -> We also need to change Section 11.5 accordingly (last sentence especially). -> Does this make sense? Thank you. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sun Jun 24 09:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SZL-0000xC-KC; Sun, 24 Jun 2007 09:55:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SZL-0000x7-5a for pana@ietf.org; Sun, 24 Jun 2007 09:55:59 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2SZI-0005C8-NM for pana@ietf.org; Sun, 24 Jun 2007 09:55:59 -0400 Received: from [88.235.57.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1I2SZA1Rda-0001ci; Sun, 24 Jun 2007 09:55:54 -0400 From: "Alper Yegin" To: "'Romascanu, Dan \(Dan\)'" , "'Mark Townsley'" Subject: RE: [Pana] IESG Review of protocol and framework documents Date: Sun, 24 Jun 2007 16:55:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace0xB3OLd5/4N5mTyulJMX6KrkE7QBHxQugAA+jYyAAAvbtcAADg4oQAArl1QA= In-Reply-To: Message-ID: <0MKpCa-1I2SZA1Rda-0001ci@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/m0BkrwF80KIqU/niTwsKYy0qieB68wUiAl2L Q5yvStSLzFk1ZHxzgw6Kgu/tvP0O1QefsKvZNAEzGfZvJ9g6bE kIcfwEY9dgHeuFErv2p3w== X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: 'Jari Arkko' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Thank you Dan. Alper > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Sunday, June 24, 2007 11:46 AM > To: Alper Yegin; Mark Townsley > Cc: Jari Arkko; pana@ietf.org > Subject: RE: [Pana] IESG Review of protocol and framework documents > > Hi Alper, > > Thanks, this makes sense to me now. > > If what is left in the two documents is either no mention of SNMP or > mentioning something on the lines of 'SNMP was considered as a possible > solution for PAA-to-EP communication which may be subject to future > work' - this would allow me clear the DISCUSS. > > Dan > > > > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Sunday, June 24, 2007 10:26 AM > > To: Romascanu, Dan (Dan); 'Mark Townsley' > > Cc: 'Jari Arkko'; pana@ietf.org > > Subject: RE: [Pana] IESG Review of protocol and framework documents > > > > Hi Dan, > > > > > > RADIUS, > > Diameter, > > +-----+ PANA +-----+ LDAP, API, > > etc. +-----+ > > | PaC |<----------------->| PAA > > |<------------------->| AS | > > +-----+ +-----+ > > +-----+ > > ^ ^ > > | | > > | +-----+ | > > IKE, +-------->| EP |<--------+ SNMP, API, etc. > > 4-way handshake, +-----+ > > etc. . > > . > > . > > v > > Data traffic > > > > > > > > > > According to our framework, as illustrated above, PANA is > > part of a larger picture that includes other protocols > > running between various entities. > > > > While the core protocol work of PANA WG is running between > > PaC and PAA, we are also showing protocols between PAA-to-AS, > > PAA-to-EP, and PaC-to-EP. > > > > The PaC-to-EP protocol is very much access technology > > specific. E.g., PKMv2 in WiMAX, 802.1X 4-way handshake in > > WiFi, etc. We list them informatively. > > > > The PAA-to-EP protocol is also architecture specific. WiMAX > > uses R6, some WiFis uses CAPWAP, some ADSL would be using ANCP, etc. > > > > I think what we can do is, like we did for the PaC-to-EP > > protocols, we can informatively list the protocols (excluding > > SNMP) that are used for the PAA-to-EP leg. > > > > > > Alper > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: Sunday, June 24, 2007 8:57 AM > > > To: Alper Yegin; Mark Townsley > > > Cc: Jari Arkko; pana@ietf.org > > > Subject: RE: [Pana] IESG Review of protocol and framework documents > > > > > > > And Dan, would that (removing pana-snmp references from our > > > > documents) an acceptable resolution to your Discuss comment? > > > > > > > > > > Do you mean removing the references to draft-ietf-pana-snmp, or > > > removing any reference to using SNMP as the protocol for an > > > authenticator to enforcement point when the two are separated? > > > > > > If you eliminate the reference but still mention SNMP as an > > optional > > > solution for PAA-to-EP communication you would need to add > > some more > > > information (even high level) about how this is supposed to work (I > > > could not understand this in the absence of the now Dead > > draft). You > > > must show in Section 2 of draft-ietf-pana-framework and in Section > > > 11.6 in draft-ietf-pana-pana what kind of SNMP entities (agents, > > > managers) need to be implemented and how these are mapped > > in the PANA > > > entities (in the server for PANA, in per-packet access control > > > entities) when these are separated. > > > > > > If you completely eliminate SNMP you are left with answering the > > > question of what will be the PAA-to-EP communication protocol. > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > Sent: Sunday, June 24, 2007 1:32 AM > > > > To: 'Mark Townsley'; Romascanu, Dan (Dan) > > > > Cc: 'Jari Arkko'; pana@ietf.org > > > > Subject: RE: [Pana] IESG Review of protocol and framework > > documents > > > > > > > > Hello Mark and Dan, > > > > > > > > > Dan is asking about SNMP. I understand that we have gone in > > > > > circles with respect to whether SNMP is required to be > > implemented > > > > or not, and > > > > > it looks like the result was confusing to Dan. We > > either need to > > > > > revive the SNMP document, or kill it off completely in the > > > > WG and in these specs. > > > > > > > > The WG was originally scoped to work only on the > > PaC-to-PAA protocol > > > > (PANA). > > > > Later the WG was asked by our previous AD to also define at least > > > > one protocol for the PAA-to-EP leg. We ended up embarking on that > > > > work to define a complete picture. > > > > > > > > Irrespective of the EAP peer (e.g., PaC) to authenticator (e.g., > > > > PAA) protocol (e.g., PANA, PKMv2, IEEE 802.1X, HRPD), > > there is need > > > > for an authenticator to enforcement point protocol when > > the two are > > > > separated. > > > > Today there are numerous protocols used for that (e.g., > > R6 in WiMAX, > > > > CAPWAP in WiFi, Rp in 3GPP2, and IETF's upcoming ANCP in DSL). > > > > Defining an architecture-neutral protocol is a good task, but I'd > > > > say it's better scoped as a work item for a separate WG. > > > > > > > > For that reason, I'm leaning towards putting that work aside for > > > > PANA WG. If and when IETF decides to tackle generic > > authenticator to > > > > enforcement point protocol, draft-ietf-pana-snmp can be a useful > > > > starting point. > > > > > > > > Let's see if there is any objection from the WG. > > > > > > > > And Dan, would that (removing pana-snmp references from our > > > > documents) an acceptable resolution to your Discuss comment? > > > > > > > > Regards, > > > > > > > > Alper > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Jun 25 07:46:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n1N-0002YB-TP; Mon, 25 Jun 2007 07:46:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n1M-0002Y5-Qp for pana@ietf.org; Mon, 25 Jun 2007 07:46:16 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n1M-000544-0m for pana@ietf.org; Mon, 25 Jun 2007 07:46:16 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7378220407; Mon, 25 Jun 2007 13:46:15 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-f8-467fab0708c4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 53185201A8; Mon, 25 Jun 2007 13:46:15 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 13:46:14 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 13:46:14 +0200 Message-ID: <467FAB06.3040106@ericsson.com> Date: Mon, 25 Jun 2007 13:46:14 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Pana] IESG Review of protocol and framework documents References: <467BB868.2050601@cisco.com> <20070624071402.GC7164@steelhead.localdomain> In-Reply-To: <20070624071402.GC7164@steelhead.localdomain> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 11:46:14.0610 (UTC) FILETIME=[6F369B20:01C7B71E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Mark Townsley , Jari Arkko , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Yoshihiro Ohba skrev: > Ansering to Magnus Westerlund's comment: > >> Magnus Westerlund: >> >> Discuss [2007-06-20]: >> What language is used to provide the declarations present in section 7.2 to 7.7? >> A reference to the defintion of this language is required. > > (Mark: I believe this comment is different from the language issue we > discussed in the past about Notification AVP which was removed from > the specification.) > > The language used to provide the declarations present in section 7.2 > to 7.7 (and 7.1 as well) is ABNF. We have some text on this in > section 7: If it intends to be ABNF according to RFC 4234 then you need to address the definitions. RFC 4234 ABNF does not allow for the "::=" in declarations. So please add the clarification that it is ABNF for all these sections and ensure that it really is ABNF and passes a parser, like Bill's: http://rtg.ietf.org/~fenner/abnf.cgi I think the changes for retransmission will address my issue.. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Jun 25 08:27:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nf3-0008Pv-Jy; Mon, 25 Jun 2007 08:27:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nf2-0008Pn-UV for pana@ietf.org; Mon, 25 Jun 2007 08:27:16 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2nf1-00039a-Ht for pana@ietf.org; Mon, 25 Jun 2007 08:27:16 -0400 Received: from steelhead.localdomain (tarij-95.tari.toshiba.com [172.30.24.143]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5PCQfMH081634; Mon, 25 Jun 2007 08:26:42 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1I2neQ-0003UZ-PE; Mon, 25 Jun 2007 08:26:38 -0400 Date: Mon, 25 Jun 2007 08:26:38 -0400 To: Magnus Westerlund Subject: Re: [Pana] IESG Review of protocol and framework documents Message-ID: <20070625122638.GB13067@steelhead.localdomain> References: <467BB868.2050601@cisco.com> <20070624071402.GC7164@steelhead.localdomain> <467FAB06.3040106@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <467FAB06.3040106@ericsson.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -2.4 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Mark Townsley , Yoshihiro Ohba , Jari Arkko , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Thank you for your response. I see what you mean. As you pointed out, the defined language itself is not really ABNF (I apologize that my statement in my previous email was incorrect.) So the correct statement should be that the language used in sections 7.1 through 7.7 is defined in section 7 using ABNF (that is why the defined language contains "::=" while ABNF does not.) So the third paragraph in Section 7 should be revised from: " PANA message definitions include a corresponding ABNF [RFC4234] specification, which is used to define the AVPs for that PANA message type, and whether or not each AVP is Mandatory. The following format is used in the definition: " to: " The language used for PANA message definitions (i.e., AVPs for that PANA message type, and whether or not each AVP is Mandatory) in Sections 7.1 through 7.7 is defined using ABNF [RFC4234] as follows: " I also checked the language definition against Bill's ABNF parser (thank you for the URL), and found some minor correction. I'll fix it as well. I'll also reflect the changes regarding retransmissions. I hope all of your issues are addressed now. Yoshihiro Ohba On Mon, Jun 25, 2007 at 01:46:14PM +0200, Magnus Westerlund wrote: > Yoshihiro Ohba skrev: > > Ansering to Magnus Westerlund's comment: > > > >> Magnus Westerlund: > >> > >> Discuss [2007-06-20]: > >> What language is used to provide the declarations present in section 7.2 to 7.7? > >> A reference to the defintion of this language is required. > > > > (Mark: I believe this comment is different from the language issue we > > discussed in the past about Notification AVP which was removed from > > the specification.) > > > > The language used to provide the declarations present in section 7.2 > > to 7.7 (and 7.1 as well) is ABNF. We have some text on this in > > section 7: > > If it intends to be ABNF according to RFC 4234 then you need to address > the definitions. RFC 4234 ABNF does not allow for the "::=" in > declarations. So please add the clarification that it is ABNF for all > these sections and ensure that it really is ABNF and passes a parser, > like Bill's: > http://rtg.ietf.org/~fenner/abnf.cgi > > > I think the changes for retransmission will address my issue.. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Jun 25 09:08:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oIe-0003VL-Lb; Mon, 25 Jun 2007 09:08:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oId-0003VF-Rt for pana@ietf.org; Mon, 25 Jun 2007 09:08:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2oIb-0007sN-4R for pana@ietf.org; Mon, 25 Jun 2007 09:08:11 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9486A21044; Mon, 25 Jun 2007 15:08:08 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-1b-467fbe38c8ea Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7ECC520FCD; Mon, 25 Jun 2007 15:08:08 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 15:08:08 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 15:08:07 +0200 Message-ID: <467FBE37.4050702@ericsson.com> Date: Mon, 25 Jun 2007 15:08:07 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Pana] IESG Review of protocol and framework documents References: <467BB868.2050601@cisco.com> <20070624071402.GC7164@steelhead.localdomain> <467FAB06.3040106@ericsson.com> <20070625122638.GB13067@steelhead.localdomain> In-Reply-To: <20070625122638.GB13067@steelhead.localdomain> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 13:08:07.0964 (UTC) FILETIME=[DFCCEDC0:01C7B729] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Mark Townsley , Jari Arkko , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Yoshihiro Ohba skrev: > Thank you for your response. > > I see what you mean. > > As you pointed out, the defined language itself is not really ABNF (I > apologize that my statement in my previous email was incorrect.) > > So the correct statement should be that the language used in sections > 7.1 through 7.7 is defined in section 7 using ABNF (that is why the > defined language contains "::=" while ABNF does not.) > > So the third paragraph in Section 7 should be revised > > from: > > " > PANA message definitions include a corresponding ABNF [RFC4234] > specification, which is used to define the AVPs for that PANA message > type, and whether or not each AVP is Mandatory. The following format > is used in the definition: > " > > to: > > " > The language used for PANA message definitions (i.e., AVPs for that > PANA message type, and whether or not each AVP is Mandatory) in > Sections 7.1 through 7.7 is defined using ABNF [RFC4234] as > follows: > " I didn't fully understand what you attempted to do. However, I think there are still some flaws in the definition of the language used in section 7.1-7.7. The white spaceing rules are missing. you have nothing thatindicates that for example "[ EAP-Payload ]" is allowed, while [EAP-Payload] would. Also line breaks need to be handled. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Jun 25 10:20:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pQx-000409-Gf; Mon, 25 Jun 2007 10:20:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pQw-0003xk-0h for pana@ietf.org; Mon, 25 Jun 2007 10:20:50 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I2pQu-0003uz-3o for pana@ietf.org; Mon, 25 Jun 2007 10:20:49 -0400 Received: from steelhead.localdomain (tarij-95.tari.toshiba.com [172.30.24.143]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5PEKVN0082029; Mon, 25 Jun 2007 10:20:31 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1I2pQa-0003jW-Bn; Mon, 25 Jun 2007 10:20:28 -0400 Date: Mon, 25 Jun 2007 10:20:28 -0400 To: Alper Yegin Subject: Algorithm negotiation [was Re: [Pana] Sam's IESG comments] Message-ID: <20070625142028.GD13067@steelhead.localdomain> References: <467BB868.2050601@cisco.com> <0MKp8S-1I2SWu0w2E-0002tb@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0MKp8S-1I2SWu0w2E-0002tb@mrelay.perfora.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: 0.1 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: 'Mark Townsley' , 'Jari Arkko' , 'Sam Hartman' , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org I agree with Sam's suggestion. My detailed analysis and remedy is shown below. It is true that in the current PANA specification, neither the PAA offers multiple choices of algorithms nor the PaC is allowed to tell the PAA the algorithms it supports. The PAA forces the PaC to use a single set of algorithms (one for integrity algorithm and the other for PRF) in a particular PANA session. In that sense, there is no algorithm negotiation mechanism defined for PANA. The PAA can indicate which set of algorithms needs to be used by the PaC in the first (unprotected) PANA-Auth-Request message so that the PaC can decide to continue the PANA session, but this is not a full algorithm negotiation. I fully understand Sam's concern on how a smooth migration from an old algorithm to a new one can be done. I think we should follow Sam's suggestion to define a mechanism for algorithm negotiation. As Sam commented, this requires a mechanism to protect the negotiation (after a PANA_AUTH_KEY is generated) to make sure we don't introduce a bidding down attack here. (Note that in a bidding down attack, an attacker can modify the list of algorithms offered by the PAA to swamp the PaC to agree upon a weaker algorithm). Here is how it works without adding much complexity. [1] Split Algorithm AVP into two: Integrity-Algorithm AVP and PRF-Algorithm AVP, where each AVP contains a single Unsigned16 integer value. [2] The algorithm negotiation is performed in the initial PAR-PAN exchange (with the 'S' bit set). When a PANA SA is needed, the initial PAR MUST contain one or more Integrity-Algorithm AVPs and one or more PRF-Algorithm AVPs supported by the PAA. The initial PAN sent in response to such a PAR contains only one Integrity-Algorithm AVP and only one PRF-Algorithm AVP supported and chosen by the PaC. [3] When a PANA SA is needed, in the final PAR-PAN exchange of the authentication and authorization phase (with 'C' bit set), the PAR contains only one Integrity-Algorithm AVP and only one PRF-Algorithm AVP chosen by the PaC in the initial PAR-PAN exchange. The AUTH AVP contained in such PAR and PAN messages is computed differently than that of other messages to include the initial (unprotected) PAR-PAN exchange as follows: AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU, PANA_PDU_for_initial_PAR, PANA_PDU_for_initial_PAN) For other messages, AUTH AVP value is computed in the same way as defined in the current specification: AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU) This way, even if an attacker alters the list of algorithms in the initial unprotectged PAR, the alteration can be detected in the final PAR/PAN exchange. This mechanism would also allow future extention to PANA to allow other types of negotiations to be peformed in the initial PAR/PAN exchange and then protected in the final PAR/PAN exchange. Best Regards, Yoshihiro Ohba On Sun, Jun 24, 2007 at 04:53:14PM +0300, Alper Yegin wrote: > Hi Sam, > > Thank you for the review and comments. Please see below for proposed > resolutions and let us know what you think. > > Discuss [2007-06-21]: > First, I'd like to compliment Mark and the PANA working group on the > excellent work they have done over the last year. I fully expected to > be unable to support publication of PANA when it came to the IESG. > While I do have some blocking comments, I think they are easy to > resolve and expect to be able to remove my discuss when that happens. > What an excellent job making PANA easier to understand and removing > complexity. > > -> Thank you. > > What must a receiver do if it receives a PANA message with unknown > version? How is the version field actually useful? (How do you get > backward compatibility if you discard packets with unknown version?) > > -> I think version number must be updated only when we are about to > introduce an incompatible change. So I think (not sure though), if an > implementation receives a message with an unknown version number, it shall > silently ignore the message. I think a peer with version N+M cannot really > speak to another peer with version N unless the former implementation can > also behave like version N. > > -> Does this make sense? > > > > The framework document says that sometimes a PAC is expected to > reconfigure its address after PANA. The PANA protocol has no > normative discussion of this. In order to get interoperable > implementations, you need to clearly indicate when address > configuration is required. Perhaps you are deferring this to future > documents. If so, then the framework should indicate that unless a > PAC implements a protocol extension that mandates address > reconfiguration and that protocol extension is used, then the PAC need > not do address configuration. Or, if address reconfig is supported in > the base protocol, you need to have normative language describing it. > > -> We had thought about it and even designed an AVP to tell PaC what > mechanism to use for re-configuration. Version 12 of the spec included not > only an indication that the PaC shall reconfigure a new IP address but also > the name of the mechanism to use (DHCPv4, DHCPv6, stateless addr. autconf, > IKEv2, etc.). > > -> Then we realized we were stepping outside the scope of the access > authentication, and we decided to remove it. We decided that anything with > IP address configuration is outside the scope. > > -> Would you suggest we re-introduce what we had but only with a one-bit > info that says "PaC shall configure a new IP address" (without enumerating > any specific address config mechanisms)? > > > The framework document talked about a lot of options having to do with > the underlying link and security. It seems that the mandatory to > implement behavior from the protocol document is support for integrity > of PANA messages using EAP methods that produce MSKs but no mandatory > to implement support for link security either at layer 2 or 3. If so, > please make this clear in the framework document. If not, explain > what I'm missing. > > -> That's right. > > -> In the introduction section, we had said: > > PANA is intended to be used in any access network regardless of the > underlying security. For example, the network might be physically > secured, or secured by means of cryptographic mechanisms after the > successful client-network authentication. > > -> How about if we extend it to say: > > PANA is intended to be used in any access network regardless of the > underlying security. For example, the network might be physically > secured, or secured by means of cryptographic mechanisms after the > successful client-network authentication. While mandatory to > implement behavior for a PANA deployment is the integrity > of PANA messages when the EAP method produces MSK, there is no > mandatory to implement support for network security either at > the link-layer or network-layer. > > > > > > Section 5.5 of the protocol document should include a rule that > messages expected to have an auth attribute but which do not do so > MUST be discarded. You need to specify which messages are expected to > have auth attributes (presumably all of them after a completed > authentication with an EAP method that generates an MSK). > > -> We shall change > > o When an AUTH AVP is included, the AVP value matches the hash value > computed against the received message. > > -> To > > > O Once the PANA authentication succeeds using a key-generating EAP > method, the PANA-Auth-Request message that carries the EAP Success > and any subsequent message in that session contain an AUTH AVP. > The AVP value matches the hash value computed against the received > message. > > > Please describe how PANA will migrate to a new hash. You need a > negotiation mechanism so that one side can determine the capabilities > of the other and so that you can maintain backward compatibility when > deploynig a new hash or PRF. > > -> I'll leave that to Yoshi as he's the one who introduced the algorithm AVP > inspired from IKEv2. But in general let me ask: Does that mean we shall let > PAA send "a list of algorithms" and PaC choose one during the very first > PANA message exchange? > > > I am not sure the algorithm AVP quite gives you this. > Also, you SHOULD protect your negotiation after the fact so that if an > attacker > modifies the unprotected negotiation then the modification will be detected. > > -> We already include the negotiated algorithm in the very first > authenticated PANA message exchange (the one that carries the EAP success > from the PAA to the PaC, and its response). > > I'm particularly concerned that even if the algorithm AVP is sufficient, > you > recommend against using it unless the link is secured. That seems highly > problematic; protected negotiation is a better solution. > > -> We allow inclusion of the Algorithm AVP in the very first message, so > that in case of a mismatch the PaC can decide not to continue. But in case > the link is not secured, that "early negotiation" is susceptible to > spoofing. So we wanted to warn the deployments. Would you recommend we > remove that warning? And would that not have an impact on the PaCs being > turned down due to a spoofed message? > > I am uncomfortable with the claim in the protocol document's security > consideration section that physical security provides protection of > confidentiality and spoofing. I'm not really sure that is true in any > reasonable sense for DSL lines. I think a better way to state this is > that the environment provides adequate protection against spoofing and > confidentiality based on the operational needs of the environment. > > Similarly, I'm concerned that the blanket claim that if a link does > not provide security then security is required at a higher layer. I > agree that PANA integrity protection is required, but for example I > don't see why data origin authentication or connectionless integrity > is required for most Internet traffic. I think the security > considerations section could be reworked to talk a lot more about > tradeoffs and a lot less about hard requirements. > Some hard requirements are probably still necessary. > > -> We can remove references to any specific network types (DSL/3GPP2), and > physical vs. cryptographic security. > > -> I think what we are really concerned is data origin authentication, > integrity and replay protection (not confidentiality, like the current spec > is saying). Those are important, because they are the primary tools for > enforcement points in policing the data traffic. Unless there is a way to > perform data origin authentication, the enforcement points cannot > distinguish traffic of authenticated clients from unauthenticated clients. > > -> Based on these, I'd propose we change > > An important element in assessing security of PANA design and > deployment in a network is the presence of lower-layer (physical and > link-layer) security. In the context of this document, lower-layers > are said to be secure if they can prevent eavesdropping and spoofing > of packets. Examples of such networks are physically-secured DSL > networks and 3GPP2 networks with cryptographically-secured cdma2000 > link-layer. In these examples, the lower-layer security is enabled > even before running the first PANA-based authentication. In the > absence of such a pre-established secure channel prior to running > PANA, one needs to be created after the successful PANA > authentication using a link-layer or network-layer cryptographic > mechanism (e.g., IPsec). > > -> To > > An important element in assessing security of PANA design and > deployment in a network is the presence of data origin authentication, > integrity and replay protection by the lower-layers. In some networks, > this level of security is already enabled even before running the > first PANA-based authentication. In the absence of such a > pre-established secure channel prior to running PANA, one needs to be > created after the successful PANA authentication using a link-layer or > network-layer cryptographic mechanism (e.g., IPsec). > > > > I am uncomfortable with the recommendation of eap methods like md5 > even when link security is available. Can you please work with the > EAP and EMU working groups and see if they support this recommendation > in the framework document? > > > -> We didn't really mean to recommend use of any EAP method. For that, we > shall remove the statement "For example, weak authentication methods, such > as EAP-MD5, may be used for such networks but not for the others." > > > > > Comment [2007-06-21]: > The PANA protocol document says that the derivation of keys for use in > setting up or binding to link or layer 3 security is out of scope. > That's fine and probably even a good idea. however there needs to be > a single document that specifies this derivation that all the uses of > the PANA SA end up referring to. IT would be inappropriate for the > PANA IPsec document to use one method and say a method to set up > preshared secrets for 802.11I to use another mechanism that might > interact badly with the ipsec mechanism. > > -> Would the following take care of this? > > -> Currently > > PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID) > > -> We could change this to: > > PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID) > PANA_SECASSOC_KEY = prf+(PANA_AUTH_KEY, Key_Name) > > -> The PANA_SECASSOC_KEY SHALL be used as the root key for any secure > association key management for securing link-layer or network-layer. Key_ > Name is a string and it SHALL be assigned by a separate specification that > describes how PANA-generated keys are used with the specific secure > association protocol (e.g., "SECURE ASSOCIATION ROOT KEY FOR IKE-IPSEC", > "SECURE ASSOCIATION ROOT KEY FOR IEEE 802.11I".) > > -> We also need to change Section 11.5 accordingly (last sentence > especially). > > -> Does this make sense? > > Thank you. > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Jun 25 10:43:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pn9-0007zH-6g; Mon, 25 Jun 2007 10:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pn8-0007zB-HI for pana@ietf.org; Mon, 25 Jun 2007 10:43:46 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2pn8-0008V0-3u for pana@ietf.org; Mon, 25 Jun 2007 10:43:46 -0400 Received: from steelhead.localdomain (tarij-95.tari.toshiba.com [172.30.24.143]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5PEhRC2082141; Mon, 25 Jun 2007 10:43:27 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1I2pml-0003mD-TZ; Mon, 25 Jun 2007 10:43:23 -0400 Date: Mon, 25 Jun 2007 10:43:23 -0400 To: Magnus Westerlund Subject: Re: [Pana] IESG Review of protocol and framework documents Message-ID: <20070625144323.GE13067@steelhead.localdomain> References: <467BB868.2050601@cisco.com> <20070624071402.GC7164@steelhead.localdomain> <467FAB06.3040106@ericsson.com> <20070625122638.GB13067@steelhead.localdomain> <467FBE37.4050702@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <467FBE37.4050702@ericsson.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -2.4 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Mark Townsley , Yoshihiro Ohba , Jari Arkko , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org OK. We will add explicit rules for white spaceing and line breaks in the language definition. Thank you very much, Yoshihiro Ohba On Mon, Jun 25, 2007 at 03:08:07PM +0200, Magnus Westerlund wrote: > Yoshihiro Ohba skrev: > > Thank you for your response. > > > > I see what you mean. > > > > As you pointed out, the defined language itself is not really ABNF (I > > apologize that my statement in my previous email was incorrect.) > > > > So the correct statement should be that the language used in sections > > 7.1 through 7.7 is defined in section 7 using ABNF (that is why the > > defined language contains "::=" while ABNF does not.) > > > > So the third paragraph in Section 7 should be revised > > > > from: > > > > " > > PANA message definitions include a corresponding ABNF [RFC4234] > > specification, which is used to define the AVPs for that PANA message > > type, and whether or not each AVP is Mandatory. The following format > > is used in the definition: > > " > > > > to: > > > > " > > The language used for PANA message definitions (i.e., AVPs for that > > PANA message type, and whether or not each AVP is Mandatory) in > > Sections 7.1 through 7.7 is defined using ABNF [RFC4234] as > > follows: > > " > > I didn't fully understand what you attempted to do. However, I think > there are still some flaws in the definition of the language used in > section 7.1-7.7. > > The white spaceing rules are missing. you have nothing thatindicates > that for example "[ EAP-Payload ]" is allowed, while [EAP-Payload] > would. Also line breaks need to be handled. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Jun 25 17:35:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2wDb-0002Vp-Vd; Mon, 25 Jun 2007 17:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2wDa-0002UM-BT for pana@ietf.org; Mon, 25 Jun 2007 17:35:30 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2wDZ-0003NZ-Ai for pana@ietf.org; Mon, 25 Jun 2007 17:35:29 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 25 Jun 2007 14:35:28 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKbRf0arR7O6h2dsb2JhbABBjl4BAQkOLA X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="164136059:sNHT36730674" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5PLZSSW000499; Mon, 25 Jun 2007 14:35:28 -0700 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5PLZRka002871; Mon, 25 Jun 2007 21:35:27 GMT Received: from [128.107.113.79] (dhcp-128-107-113-79.cisco.com [128.107.113.79]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id l5PLZR723902; Mon, 25 Jun 2007 14:35:27 -0700 (PDT) Message-ID: <467FF654.7080406@cisco.com> Date: Mon, 25 Jun 2007 19:07:32 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Alper Yegin References: <0MKp8S-1I2SWu0w2E-0002tb@mrelay.perfora.net> In-Reply-To: <0MKp8S-1I2SWu0w2E-0002tb@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2560; t=1182807328; x=1183671328; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20Sam's=20IESG=20comments |Sender:=20; bh=QfDowEFO+hSt/RdMp/xtAW27LAEthuj768FcST8WqMA=; b=0Bqqsr6P131wUuwNICv3KQEPTjCqMmjeCQJBjrjjZBX7UGEKKA1N8/B4TJAAPvj6IjQDJhiz PFqOBHMhrn1NXz2gpAmT83CVCjTRZYnq2QQYC9jmNaFsxBaqLnhSsgft; Authentication-Results: sj-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'Jari Arkko' , 'Sam Hartman' , pana@ietf.org Subject: [Pana] Re: Sam's IESG comments X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Alper Yegin wrote: > The framework document says that sometimes a PAC is expected to > reconfigure its address after PANA. The PANA protocol has no > normative discussion of this. In order to get interoperable > implementations, you need to clearly indicate when address > configuration is required. Perhaps you are deferring this to future > documents. If so, then the framework should indicate that unless a > PAC implements a protocol extension that mandates address > reconfiguration and that protocol extension is used, then the PAC need > not do address configuration. Or, if address reconfig is supported in > the base protocol, you need to have normative language describing it. > > -> We had thought about it and even designed an AVP to tell PaC what > mechanism to use for re-configuration. Version 12 of the spec included not > only an indication that the PaC shall reconfigure a new IP address but also > the name of the mechanism to use (DHCPv4, DHCPv6, stateless addr. autconf, > IKEv2, etc.). > > -> Then we realized we were stepping outside the scope of the access > authentication, and we decided to remove it. We decided that anything with > IP address configuration is outside the scope. > > -> Would you suggest we re-introduce what we had but only with a one-bit > info that says "PaC shall configure a new IP address" (without enumerating > any specific address config mechanisms)? > Sam, the notification of an IP address change in the PANA protocol itself was among the items that we removed in order to reduce PANA's complexity. If the IP address changes for some reason, whether it is configured via DHCP, SA, IKE, IPCP, or manually, PANA would need to react like any other protocol that would be affected (e.g., TCP) by this. I believe we discussed that ending the current session and restarting PANA would be a perfectly reasonable thing to do, but not certain that this made it into the text. You suggest that PANA try and indicate when address configuration is required. Trying to enumerate this is due to the number of environments PANA wishes to applicable in and the number of ways an address may be configured sends the author and the reader out into the weeds rather quickly. Rather, I believe in the base framework and protocol spec it is sufficient to say that the IP address may change, and if it does PANA needs to know this and may need to restart. Specific "PANA with Foo" specifications may make this recommendation more precise if need be. - Mark _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Jun 25 20:41:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2z7E-0005aS-1g; Mon, 25 Jun 2007 20:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2z7C-0005aN-Eq for pana@ietf.org; Mon, 25 Jun 2007 20:41:06 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2z7C-00075A-0u for pana@ietf.org; Mon, 25 Jun 2007 20:41:06 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 02:40:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pana] Re: Sam's IESG comments Date: Tue, 26 Jun 2007 02:40:59 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02604A9FE8F@FTRDMEL2.rd.francetelecom.fr> In-Reply-To: <467FF654.7080406@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pana] Re: Sam's IESG comments Thread-Index: Ace3cMOgYhIBoH1bQlKgDuSN7jFxsgAFpAhA References: <0MKp8S-1I2SWu0w2E-0002tb@mrelay.perfora.net> <467FF654.7080406@cisco.com> From: "MORAND Lionel RD-CORE-ISS" To: "Mark Townsley" , "Alper Yegin" X-OriginalArrivalTime: 26 Jun 2007 00:40:56.0858 (UTC) FILETIME=[A8CAC7A0:01C7B78A] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Sam Hartman , Jari Arkko , pana@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org I think that this could be clarified saying that the IP address = reconfiguration would be not required by the PANA protocol itself but by = some network configurations or any other reason outside the PANA scope. = The requirement would not be on the PaC but on the node hosting the PaC = (actually the IP address is allocated to the node). BR, Lionel=20 > -----Message d'origine----- > De : Mark Townsley [mailto:townsley@cisco.com]=20 > Envoy=E9 : lundi 25 juin 2007 19:08 > =C0 : Alper Yegin > Cc : 'Jari Arkko'; 'Sam Hartman'; pana@ietf.org > Objet : [Pana] Re: Sam's IESG comments >=20 > Alper Yegin wrote: > > The framework document says that sometimes a PAC is expected to=20 > > reconfigure its address after PANA. The PANA protocol has no=20 > > normative discussion of this. In order to get interoperable=20 > > implementations, you need to clearly indicate when address=20 > > configuration is required. Perhaps you are deferring this=20 > to future=20 > > documents. If so, then the framework should indicate that unless a=20 > > PAC implements a protocol extension that mandates address=20 > > reconfiguration and that protocol extension is used, then=20 > the PAC need=20 > > not do address configuration. Or, if address reconfig is=20 > supported in=20 > > the base protocol, you need to have normative language=20 > describing it. > > > > -> We had thought about it and even designed an AVP to tell PaC what > > mechanism to use for re-configuration. Version 12 of the=20 > spec included=20 > > not only an indication that the PaC shall reconfigure a new=20 > IP address=20 > > but also the name of the mechanism to use (DHCPv4, DHCPv6,=20 > stateless=20 > > addr. autconf, IKEv2, etc.). > > > > -> Then we realized we were stepping outside the scope of the access > > authentication, and we decided to remove it. We decided=20 > that anything=20 > > with IP address configuration is outside the scope. > > > > -> Would you suggest we re-introduce what we had but only with a=20 > > -> one-bit > > info that says "PaC shall configure a new IP address" (without=20 > > enumerating any specific address config mechanisms)? > > =20 > Sam, the notification of an IP address change in the PANA=20 > protocol itself was among the items that we removed in order=20 > to reduce PANA's complexity. If the IP address changes for=20 > some reason, whether it is configured via DHCP, SA, IKE,=20 > IPCP, or manually, PANA would need to react like any other=20 > protocol that would be affected (e.g., TCP) by this. I=20 > believe we discussed that ending the current session and=20 > restarting PANA would be a perfectly reasonable thing to do,=20 > but not certain that this made it into the text. >=20 > You suggest that PANA try and indicate when address=20 > configuration is required. Trying to enumerate this is due to=20 > the number of environments PANA wishes to applicable in and=20 > the number of ways an address may be configured sends the=20 > author and the reader out into the weeds rather quickly.=20 > Rather, I believe in the base framework and protocol spec it=20 > is sufficient to say that the IP address may change, and if=20 > it does PANA needs to know this and may need to restart.=20 > Specific "PANA with Foo"=20 > specifications may make this recommendation more precise if need be. >=20 > - Mark >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From nzqo@stilesmachinery.com Tue Jun 26 07:52:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I39bB-0006Qd-TH for pana-archive@lists.ietf.org; Tue, 26 Jun 2007 07:52:45 -0400 Received: from [222.102.89.181] (helo=ycigqa) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I39ay-0006dc-Of for pana-archive@lists.ietf.org; Tue, 26 Jun 2007 07:52:45 -0400 Received: from [57.208.117.44] (helo=qvcp) by ycigqa with smtp (Exim 4.66 (FreeBSD)) id 1I3Ac%-0007dw-9S; Tue, 26 Jun 2007 20:55:50 +0900 Message-ID: <4680FE01.6010603@stilesmachinery.com> Date: Tue, 26 Jun 2007 20:52:33 +0900 From: Anthony Harding User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pana-archive@lists.ietf.org Subject: automation crowbar Content-Type: multipart/mixed; boundary="------------050308010504050505030707" X-Spam-Score: 2.5 (++) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 --------------050308010504050505030707 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit --------------050308010504050505030707 Content-Type: application/pdf; name="journal.EFXLN.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="journal.EFXLN.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDY1MSAxNjFdCi9Dcm9w Qm94IFswIDAgNjUxIDE2MV0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo2NTEgMCAwIDE2MSAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDY1MQovSGVpZ2h0 IDE2MQovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr Vbrldr1fsFhsVjslls1ntFptVrtltt1vuFxuVzul1u13vF5vV7vlXdh+wGAdkQwLsVKpwcJxN9xk gdmLwuNyU2SaTw2IADsSeCP2JzaThedwGHxcH0scx+Vy9JxGpy1FU02UypieVy2Ph2tgWc3GT30p x+zz2W0m9guaP2Vhp+hunjeu1dI1ua18Y5F/k+xhWX42Z5mmhm0hOzheggmD22PdnahWHzO7ge4z fx3/1jym4O683x53GSbxIU76FsXADENs/jqIe/aRucj8AI3AzRQEkb2IOyrisW7DwIXB6DPIhUFv fEMKws8TEu+zr0O+zD7RajMSPQ47kNE96CQ6g8JgA/D1PoAD/oEUz8Ns0EdupEKEv2wcZo7BsPMz A6IxugT1PmiESRyjjVODEDjoJLEpvChUPyRLsRxBJL4OxFUfSlF03StC0LumzcaRzNsvILIsNOQ/ cgyNIkeR8h0ktSziC0I1TztHE09Piz7xT9Icptc9sqPNObAAA5jOyqg8SPizr8IGPzhUuw8goE0D LVFH0tPXLjzzwg0WSnITOoE2i/1egkxoREL0VdT6CQXE9b00gblTfZSJvxUkWNs0kay9PkftDPL1 T2z6B0jKFLQU/lFUPSbqV3CVovXbFcT491UWRHVLSOgc50ugtN11bVPOvFddR271SuSw5Uz9VtVv lPNYIRL9aMzWzsNJULS17C0y1c8r/t1TUBRQ0GF2Xj0B2dg0EINTjk2rALzz077PUhcTtSNQce1B cTMug7UJTBnN5IK2lhSLVKEylDt7WGxTNr+5jEYhJV61/VtYzNMiEy/aUavNpMH4jO+gagiE5N7C bmSrWjq4/szFUE88Z11OyGQm0+V3lnshQPIsoIZNFFMg81LV27w/PdmVcZ5HSEW9oKD6HY6J6Tfj cOdp3I5ThGdcWgzSs8+EO608syorYu2bSAGySbs83xh0VJzp0MbbdYcdstuOd3fu/Du3I1o1i7FO tPm7d9zaWk8Jn0p7vWfEypTOqSdPHN6rTXJag9O/YnWNR8Nou0+F60ga31MRc/UddYt03TNnUkea dknCIj2BU+WjTXYu08Ts1tUjZvpGAv4//G0ez1fL8m0GmUKfAhrDVMmHOSv196/2LsCVE+o9LhUk PzbA6xVJ02uNXdHAoSarHusWMqv1eL5YTEhfeZp0pWj+swVA4BzbJ11oDUoRl+Bx2joCL/B8yCpV cKnO0+oiMFnxI0WRBptMHGHwfNrCOFcJ4oRRilFOKkVYrRXixFmLUW4uRdi9F+MEYYxRjjJGWM0Z 40RpjVGuNkbY3RvjhHGOUc46R1jtHePEeY9R7j5H2P0f5ASBkFIOQkhZDSHkRImRUi5GSNkdI+SE kZJSTkpJWS0hkgimWMcA1MT5LyfhOqtHb3iPG3hVJ45pqmBklhuRuEsoJYEjRDKQjsQiLLklWSNT LxVAmZYFDuDsv1kpAO6qmVEsZkEZleelADq24smNKapjq7nuEZNKrlBK41OuMW3KdPcEIVMBh8rU 1Ll5kznJFKI4yRjDJKmckqHZt3inEQ0zQ+jPYVNyOQc1Gy8HRvJla4ZATinnmGV8YuYatZ0ULI8e uUblXR0FZq9ZcjSnqz3UjQZgMLjtz9aLQQiU13sHnTaiFI6wqGUpIwiZDZ9Em0VfsQZpzAnW0beN SNwdH34z9lMfGcBxGAtknstulVRSKyzog0x3VOGuVDPeh02lNqE1MQ6xxeraiHP0YKYkwykZgvAV Wbek9RqyRDocY9EzuJsJ0VvS+aVMVD1nNw86qpDKRUfUxVifkA5otlriKasTzKy2Drsn5zEE3imB ogsOehirDU5nuaSm9jJ1UReynNGRDpd2WR6aevz2ZqHxpRYS0hOXnQdmyr6VS7ZdLyhVKuzxl7JV Nto8+0tty+2bX4ey2NQaY0mWHMe3Fwy40BmVcS5FyblXLuZc251z7oEUVPMC6N1St0cbwkmyc1an p+OTcKv1DrR3WvIS5GE7DlrJfk6V+lEiGqJmNJk2J/ry31JVQ57lnzTNicrexLt7a7GgoQtu+Zw7 7YHJLKK3iqb9WZe+j6/zumBIGk8b3AaOlUHylfgjDlxzY4LOVCu+ljKOu6SCgZvCGV3Kot5hvDuL 6j34f5YuaqxMXXtuFbShCu2XrAxhj9+MmVwY0QQ7XCt/6zLkWQYvAuDMgZPqO4XBbgptz+onXbJD XjoWhcLQjF2UMwUyvE/y+CqXlt8y24ardSiKY7vlmHODn7WTzpNmebWDclr9OsynOecc/EPvHn/Q Wg9CaF0NofRGidFaL0Zo3R2j9IaR0lpPSmldLaX0xpnTWm9Oad09p/UGodRaj1JqXU2p9Uap1Vqv VmrdKSjndNK9+eC6aBK3l832ti3TFL1YZedjTHmBk29MluuCga6IjcZBmyKZFP2NXauFtiLbMyIW DXhJNnmwwczvYOwni2uJZtkm7vSPbKJE9RwSviL4u3FTsjE9G8ka2ptIsWOSNbtKEp806uamb03d Rciba3VHJ4CzU3qEcAVEo5eIxNa5XpNecvrcxDFhSeY4xhDloGEkr3tupoD+laLY3tfN2smeGu2e wnzMmbLIFCmuddvU02eS/SbvgoNhjyHQPdS9LrU4YIZXTiVy+uN9s1neoWqa9X9Wi5Ev+gyOkDLJ btiHhhg1588So7On3EnxZ6cSqdG/FZunrdIhhMOXEccc60RJX6izEp67Ij4zrW+p4C6rP+Gpiukd 2pg+xhkvSYvJe5O2HKoF0VcnHOLFGEGflUR2cJ+VaXVqOZNzJKfbjmdwPIo97t2EnqxsfRCtZvJy 4PWmouhVon2Kl6lNFmvJureuv34KziU6COO2vA84TB9t+PYxQmFaF30z/m2d5+7EruMvsRhhLbOW ToB+Ek+xr11edNQixc8fruEzHO73yt7OTxNL2vURordj+ZCPb0ZFDyd4+EiMd7w/r0IzBh9KrwBV ju874FYn6O/fMk8vrl2G6EjliPYGXnCFCkaOkDQuQKkkSGsveF3DgrHpaPjPqHNkrvLvDkGpbIKK 9IKQDnvvgj/n0l0GjlwlxuyOeFeOjEtMMPfM6LNPhGbDSkcvNGFk7kSMBOet/QeOPwaPwDdl0Nqw PGgOpuDOTFKwElNP2GZQTIjGlP4j8nNIgH7QOinrzwEN+sIwIvOnWtqwCwWHnt+FpszOklkFzKWE vQHvklxL2wKm4OWlVkvGVvxOAFPKWjtQQwrnjslruIdNgsiHMsup2DBwDETLtkcQZraoDFjkSPkD xw3QeMLt+wdvqwmHtu/vxvyDzFAFKD1QQiEGFl7GSv2qrvakamQl6Giw+CmrvPIQtKWtqw4xHqoN 0uNNyGqv9J3xSpln2G4IHQIQjQ3OGRMkBxTuroEHZRbwRQumZQ9PnILJPEHwOm3i/xIPnEgQWp5O TFnPnJSDPwSRBl6mHl3j1RvCHQdPXrvMyMNrPODP7D5jRoDOgiEIgr4nDwJtAkpEcmOOswnkNQol +uTj5pxEhHUxNimFmucwEG1xlxZvMRzNgmJEARKIBHnseloREDBQhF8FfQ0qIH/OCDzlJR1GGJVw 4RTx4D3uYQ6wNkSwqs8pismRtGrIiOzmnw/kemQnsG6qJQ2FpHAmpEeoSngFsRjCFyTOGIcMbmaM 0j9mNQNoVuSFVR3u3pcnEkcF7uCLMHaJNv4SBxVEVpwMGSXt6yHHGOfn+GHO/E/x2qIMWjlQKwGP UCKREprSVLBRGmlmgogLguvEtMPyauOrXO8mdSBEnxrvLEEw5n5DXxukPq7kkPKjeubS5idPDsXG Bj0wjjbwknEPZviiKxVDywhzCC8RbFkQzw2i4RlJ0zPKGmRGZGlImMIR0OPHRS3EgSFzRxFi4j2D zQjx1x9tXH4vCzizkTkzlTlzmTmoomtzTovubCOnACnx5mPGou0HwiLQqjlTpiiJMyeScRZC9zsi XTviNzqiakhsPzwy4n5szHAOJiVN5ifzzPTPqK9iKzulVHKClT3PLO/TyDUEht8TLiKSTN1kFz6i Pz0EICVrRk/rAL5R0BUyNOrSoUDiJGAUECSk7oeNoz8GYwxTtFZCG0NR7ONNmxXN1T4FRmhxFjbR sOA0Cz60UH2kJ0HFWj2LRrgTcGuDZwTkyFnD2KgzgIRrxjYzxFWngOWnoQSCQ0IlDygGhUBJSmAU D0Jv0CQE2oFjUkKtjHYD9k+wim0jW0LFNH3oGkwmcUOsVuvRGCkKUULjIRqTKFgIP00HLU4uhTdq nQ+m3LASRmpulpNUxnu1BUnROvQkiTgvOun0fQ7lVUgv3qZJNDZrAIfrpmCIPoQEPVLj9GvzJO5T fIR09U0mBOJ0pRnDxUqwviQD9nvIBUtLWOikRTrjcuNwxGBPOJiEoLDEoTgzBGrF1DDE6U1FSJ+j 11Yocz1CJUwVOvSkdUdCa0ATVJqxqGKU8oOUVMsFeR1VOs5unp7k6FcFSRwlt0ZO5OQDYzajQUiF tK60kJy1FnCmQ1jG0xx0Vl3VtxG1LLLpxU8G+DxkK08Di1X1SRxMGVKGMlTyRjNVLlh0jGjV1UKE P0LE5FcVj1nLVUgjdoYNAqTrsTHSaruETULDRjv1BJhrAVTVdFZ2V1WwBkiGaVwzBmuUzkqksRxW W2NWEE4VrrQ1MleUzkOT5UlE2Du1KTotAEgzbsN1smU0ZU9LN1Bqs0awdVaJNKfEZWUTqoG10GGW pzjqaF3lBV4SuSalVVOmgE+lUR+180+Hvzg2UPglxIHpfsGW2RIqZVRWERwvf1tlNoYQfoPx0UsF TkzoR1w2I2NWMnR2NnvVTVm2HRRWYlcWZx21HQfLLVxlj1zvK2xWXRFHYKnK605v0Q9rUVjEUV92 cUrNAUVEFkF171TmSVkWV2eFU2lz5n20f1ASEN0SoT8iHk/29lkUtV/H6KRWwGTFalkjaFzQPJy2 0KrIKVFs9UF2kRWO8HUn3suVMxO1KqnT+mukfSsRnLa1RnI3JkUXKujVQV/UykQEKzIys2f2+3eT 1GqVeUOHR3MxzFJQPSH3OkcXcwyO10p0v0VXT2a0/MCkYqCEBROxRO/TaoD3ZONTxJXx+2rIg3eE KXflRz5DxXADg2x0XkdT5ne1oXz0tqknCK6kgV1Gr2QSSU9lBKooIm03SkzW4PsV8F5YJ2eVJ26s 7RWUjWBX0USLKWD2Gz1YTEYk8EV1DX4XD30t04LqckGzUrVXBWG2yyh3MTdSTUKHKlqkG3QELwxx 0rQKomXUxYKEgSeEEji2UHf1zraxVutYtSk4Mu0PIIV4OveXBJ6iQU5mE4SFRlE08WPD6FP2t0+v mUJTd5I4YKa41WB0d4jO5x1XqpgvpUd4emD17qYkCGeUcvhuoUhXfm+WA29M+4sFWp24R01ZFp5G CWGDBVUxLHZkJ4wuh0ZY+xEPv4uw7ljKun4KkHs4423LeL1saEcuWRsQbFhrv4dYyO83aLOVYq0F O01pjYT49mdY+kxY/oP29mV1pH15rZCS8iP0GCL3Ek8ob3jMCzvWtZ1LU1bY1LRWpxMTq4y3+4+X kXsveZAi132nf1UnVX4noLZLxz2Uy5iUXGvX212ZlGeYARtx3Y65o3cklWW08mE0QY+rvpuy7iQx QVqO2XklNZA4OIU3QZCYQCnEpZLM1YBELM3s7t0on6RKUUEot2IWOKgX5ti4vlF2QkPPPUuWw1py 5EkXSi56EDt5FZqnu5WClu5znNXSv6u6waw6xax6yCeLp6WMw0bo7Xes2ia2mZ5OwTViTt7a0Cd6 3iVZd54pUrxa2UTuA6+owbAYxRmLP2raVN+kHU/jgIhi/T0iSGkKupvGylm6jXIMbsFbBP0qQ7Mo u67w7sabC667EQiCNYZKtiUaf7FEXq0RKKcjRZDXinaQVkLJoIgvl7SYRnxkRZcTybJDe7KDVm6K AvuWvG1XnVfDiPL6uOEwLI5VPGCXPaSZcO+whbEObLVsiliXiHMO/3abITLkpP7UQlYokMkwh5zH dKuqfZ5kyDLDlNfTKkujeavnLwovbEhMLK0bnzVbavpDVVhbWEQb5jvGK0Bn1FP4w7DRZYZKAH6p 46QqK7lbIwfbYI31PJ2UA8CKe7qQmbrOKIapcFRNfydyovjpsm2auCHkCwrbVGayup2p17Xyyjgr 2JhcHKu126IGtj0rV7WRBqWFDQepfHQ3PDBkU8cN+yqb/zd8A7BjmZDKX68xm354ZU+8GQE8HG41 bbvyD7qpuo6rDr1arcxU47Z0SmUoBQ3p7ICnxQP2438bNPiW5u9RWcYZTbX4pRmPbMKcvRtKgH9o Ks+cfXXxUoMDFQo8n75ZZNyE/topUEQ9EruQ6DuJTEU8mbk8qoB1FJtSOFJ7juikJDV3hxLo6Ktb kjQwXUSmqHIRjmi81LQRz8KSnUBSE15XOdJMIOzP4dLRW4Etyc/yhQ7t0HMjV8jQhb6Lg9EYcOWa jmqlXx389XOdI9oocORMCJwpg6mpzYE5xxUjd5GKSYcDaDXpi79o37udczoZwxKdR9t1u9bqJcql ipq9oQamsoVqgsUJVbed3dkoNDC9eKPc4y4Hv8djj74DhvY8jeAW7Ypss0/DTEh9np2btSIeAL3d +vPsh8ELJa5HBRqFLxzpdkUoJvCbknYy69mWzbnKHwW5aWKdU9cn7DA9grFym9Xce3V594RsqSne UWOdzEbKbL4taNpGnZpboeXzQMumD9geDPQK0Wong8gkkPCDsZqlsIIIK73s6Xl0mqZDI+MDj+aP Fke8EcW+Pl5sixrG7uo3O+yJyamI5tfFHY1oRLP+X+4Ox7fslHDLAIa7sVi9HE8FdLfp7eURUEGE 4uzeGeE+VGeLXyMJjdAbB7PDtsKH4D1IATyNdDoiQe4cDm6fPW5N0oNbRQ8e5KVFGnaei+/7xnP+ SdW4Etw8Ybc9LUafLCk9G69JZOelufR0RCZQ5tSEZ1cI5+JFl+itOq2bOay/nfn/ofo/pfp/qfq/ rfr/sfs/tft/ufu/vfv/wfw/xfx/yfy/zfz/0f0/1f1/2f2/3f3/4f4/5f5/6f6/7f7osCAgCmVu ZHN0cmVhbQplbmRvYmoKMTAgMCBvYmoKNTQwMAplbmRvYmoKMTEgMCBvYmoKWyAvSW5kZXhlZCAv RGV2aWNlUkdCIDI1NSAxNCAwIFIgXQplbmRvYmoKMTIgMCBvYmoKPDwKL0ZpbHRlciBbIC9MWldE ZWNvZGUgXQovV2lkdGggMTA2Ci9IZWlnaHQgMjYKL0NvbG9yU3BhY2UgMTEgMCBSCi9CaXRzUGVy Q29tcG9uZW50IDgKL0xlbmd0aCAxMyAwIFIKPj4Kc3RyZWFtCoA/4FA4JBYNB4RCYVC4ZDYdD4hE YlE4pFYtF4xFX7G3y+ny8Hk8XK7nU8Xq8n4/X494853a635MX0+32/ptCZi/Hk85RMYzBZS/Z3PX 3Bps/n2/JrN4XR5i/aPSafUKPTH/VZs+pnWH9HXy9Hq9KjSXfIXW8XfKX5R5/bbdb7c3W44Vas1k nVOn0crFCpl4r264m68Xu9GC1WexmQzGGzGSxWQyVYtVOrlqrna8HW93w+GAyF8yGkznG7HQ6HW6 Gs2mu1HA3Wq12033C4tnsGu1Ww22w6XZLnc71mulqzWo0Gk4m3pXM9LAs2KvmO1Gi2W43tu3G632 9r9W1Go0mzHXwymeymrcnW8nhtXG3nE4Wa1Wo4nI5mcy2pG366HacpjmcYpbl2XB8HufJqm2ahUF 2WpKlqVBemWYR4nkeS2LhDUNw4hBuG+cRXFuWjzGUVBgFsXhoGOchznMoJynedZVFgWJgGcyJlma WxfFkWRclkzJ1Hse57F2Yhcmeahpl6Zxjl+ZJhLwTpGlaUpaF4XpbGCXpXl2Wxtm0bpYFoWZgGUX Z5nmejaHAYRkmOWZomIcp2nQ5x6leYZdkiU5RlAVJWFOW5XFcWJZmWaJlF0YZbmgZ5pnwfJ7mYaJ lmQaxpGqchvGIY5jmGZxiFOXZaGCxTwmy/hqm4aBgmOYBzHScz+NQc5mNaX5qmabZxPgcxwv5Dth 2IuCZn3Ih7K4riBqcp5/H6hixn2/ipJmfR6nusMi0kfMiW1bSNn8ztJI8ricqkrh6SLdZ7Hqex7H msM8XQpT+KPeF3HvfZ8nxd57JmfNsyIzt7ptSVyHxDNi4ZhuHYfiGI4lieKYqg98SIjp9Ieo5648 pKioKqKlJzjisWlk+LZVleWQ2tRgmGYhkmY4xsGoZxuGsZxrmmbJvmyYhmGMsp3mSZ5kmgaJpuub 5rm8bGQGi8JkmUZppmwaRpm2a56QOrhtHMcU3mMY0dFcWZaF+YRhmeaRoHEcpwtOdOW7ru27oi/h kGQZeYGKXJglwWBiF4Y5omebpwm6UxYFOdcZaoZm1mQW5dF6UBWk8e1/GobBp6oZxomsaBcGEXpv nKcc8P5xBslkXBcF0XZglAUxRlWWJYFyYBb6uaBvsDvHheH4iCX2fCdnmcx1HLkHNnsdSSHUdp0p zjx7GybZunAchx3fbJ8Hscp0HL4HVLDa+DKqeV/HWdp3LCex5HoeZ0nWdVJX5457+L/v/MsGGMIY wuxdDBFeLkVg8R6DyGMM0ZIuxjC4QCMQsA9RsjaG2KhGg0Elk2H6McZsAxgi7FCJoVTuxbrZHo/+ FkLYXEJG0dYa41htjWG4NUcw7h0KyHMNQbLVxujYK0Poao1hrjjHIOUrg5x1DnO6N4aYzxrjsHcO xkEL4sRZf+syLUXYvRfjBGGMUY2HjwHePEcA4xwvjeWPId47h4jtXkPNlBVSYlLWiQU/j6ijQej3 HtA4+Y/x7KOPopS51xFWIMPkjpU4/D9PIsuDy0CjlQjyQ1Zw/I+j+Xyt8nMfCBSBj2SljRXJBxcL dBWT60H1PqjuwtDioBnCSEwJkTYpBPikF+LUWowhcDKGgMweqBxkjVc+MwaBi2amyG8NkcA5RvDe G+a8bY4B0DpHUKIWwrRGipE4McaoxyWD4FqMwYinhlC0FyLwYAyRjDCVAL9tQuBei4FCJ4VjMhjD 0XiMuYwzxsmxguK4YIuRbjKGMzMZ47h4DuGiNEao4BvIteWksbAxDIC3F8Lccw5x0PfGSM4ZQzjE DjNSNY15sRtSMH0O+Mw1DWjNGe0cZAzxnDTGcZwzhHhlDUGYLMXYshaDFF/RoYAnBPilGWNMaFLB ltIVeL8XqRxbi9FyvIeQ6h1jrF+30vAnhejEGEcYaowVPE0H2SEeZtBvzIGYM8+aBx8HBHeNGIIs xiC7pqMwU4sxXiySeKEVQrZ1C7FMKwV4tRdC2GLO5hCxBwTPoUNYbLrhji+Gy4p+w6h5ruF4MwZA vBhDEF0MAYUHBqDITmNAawzWpDSOoNgYoyxiC3qIK+AZrhqjzMKKVFBq0FjcG2NIbY1RojXGfNJp 42hsDBM/S4eElkWjnGuOQb5kBjiZFiKcVYwZ2KeN8OlsgyxpWwGoNYatYhkjSdEiUdj72EWiF8M5 m40BsjXFcLwXIohViuTUPOBoxBSisFIJ0UIoBPChFaM00ZQx3D0HeJsVwnjzDJHMOwdaiRpVVGAO gdQ6j+RVHgN5xV7BsDaOxPx+bHlbC+GIL4Yp55ijTFeLQW7GhsQ0FSLAVAmBQiYE0JUUg7jM0eHU NdXwpRfCxMak8Y9jVMi4F8MEUahcpC/GCMXLIxxkxDWI8Acj2hvjqHYOodGGB2UNxQNuJg5x8j7k MvYjbCC5jZv+wgzq3l91oYG5tBBHh2lmyIPEecCl3LXQuPJ8dJnolDfzHdgKax5jYcUSwfI5B0jk q0Owco5h0DnVmvlCw88PDrh5pqbA7x2DkfISAeMcB4aEs6vteC+zOItHEMYY4xhlDMbcYhXA0hrK +YRENY5Ty1DnNMuQrw68MPkHWTQfjCLOj1WuV5fK8h6H2NLFV5L7x2twHCOAcI3xzjlHVqwcY3G4 jkzKmseg5R0zXHeO2SpNjuDiMWMccu5yQDviGTmQpNNjx3kPIohE72jjOOMNkaU4BpC/GeMISooB LCUFAJQYauxyDrHOggfNLsIinEsLcXAuROCdE8LgXYw1NVlGWMcSQqhRCgFmKLjAkg6CZEcKgV4s RJCjE8JcVIn1TjAEiJUShwxXqGF27oWYvxjC+HCOccQ1hvDVFzUURYoxLDuJ4NQbY0xcDAFyIsR4 lBHCZESOAb4441DnpGM0SInRIC9GQMcWIxRaiOE8I8RgnxIiAFEJgSwpBQChFcK8WAtxc7nHUNIb AzxKCYEoKYVAsxQirFAKwXItBemOJyLAXYrQ+ifEnV0ZcVB2X5FiJwUgm3dCtEiJ4RaBRiUQGmMQ ZRoBoDKEiKwTJdRWjPoeNkcY30aO6tJ1sXrr4D1FFryYWdQBSitFOIXrwtUoi8u8m/3g1RpTXboQ Kho8rz0+UUMgZoxRXuVyyMMeS2hWDFF4K6Xc6xeifFuK2QxkIhRdwfBkAtQdqBYdrV7Dya4dgdIZ wawaw4IeKBRdYzpnq+wbgbJmikiGhxIbqlweKiYcR1AcCkIZAZw1ia4dTt4cKapp4baC4bYbYdrV SrQdw+wcjWIkxIoeDQqzY/wdQqQ8ifgegdKbB+wdBfrN5kAmj1gkreotA1AdAbYcJnKiTyR0aGYa qyo5wezQgeA+wcRC4eaNIb6uhjRVbsb7gYQa4bobwrwzIdqDh3494wIbYcx5YcYczjol6fgewZYb Cm5nijoc8HgeJ7IbcH7bh8bdwl5bIeqhihqN4dKKsBAeCJIchCweJbp64gYlSSCRg8ijocw3TMQb wfArQaCZrdwdLcgcQaIbga4oIhihiNAcocRq4aStAcZ5ikgZ4aobTsQ+MGYdrTAcodgeKKwpMUR7 YbiDAuQcBrYbwbgcTMwcKJEDqiIbokAeQ/jTodB2YXj9gZDWIeB94d57QuSaIbocgcQuYbprIaqI aaIcIaAa5TSygZxtorQfYdIdoc4ZAZRRadhuAcQXwaQZgZhrYo5BQbS1RR5JZpIaqtRpYaYX46IY IZQXoaAaYasUCHIdIYQaoZwZhm5PAYIaAZoUgVoVIXQXwX44Z2QYQXwdQeDMgdodoYYYoZTWCkga AXL9oW40DXgY4WwYaXa5zVgc6KQa6YZ/iMggrcocgYAYgYYT4VRzRIgZBz4UwWQUwz6gqZI7QcB0 IaA2YbBNQegXQX5BwXhtAWoXbGAXgYZSwXZJxJQaI4wZgSwWgVAaIbAbEMSbAdhFKehPb1ijo1Qb QawSQTYTAQwVITwT4WAUptQYSIbLihAZZvqsyXIUx64cYdAb4XrKaxAWakIZIVD+wXb35kAVIWpG oZAYBtoaiXgX0J4WIXgVoUgVQUgXIYaoYY4ZQd6lwb7TIWgZoYgwIcLeDjYaAUgWQVQXYXoYKDQV oWJEYcQdAbyIY90nQY4W6goVgYYXQUgXAVIXAX4XIV6goTQVwVIY4ZckgaYbRb8p4graUUCRhhQm xkArRjQfTSzWsCTFYeg/kTIzge0/KRgoJ+YebPBfoagcgbpdqUyP6SojYtUHLsDQh9ArQo6nRbpk hbre6QYqiShZcUBkA/kUA/gdYdwdLSSDytCVtE4qsJTPBSQd1HSnQtVC8T4fItQqlEpaBhDWrgTh E+1JNJVJdJlJtJ1J9KFKNKVKYgggIAplbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjMyMzQKZW5k b2JqCjE0IDAgb2JqCjw8Ci9MZW5ndGggMTUgMCBSCj4+CnN0cmVhbQr////N8REpvpAI4Yr+2h0t fJisUMrRxWdu5Kv10QVt1D05oi9Ky+3b089m0aqD/yYcrHfmfTxO7CH54vL/T8c9iGls0zRZrggo FdrTmNr5tYZxmwSt6fHP49PC4yKJIKvzjH4o5S0xDkML4dzm25FsTCxx+hViyfk2jNxYFfwECYiC Mm6wY33zb1/PVTpgwoeNM4GjlkuczNd4Je10Kff9rClrXYzpUPtIIFGDgRMKDkeMsd7YTaqwxtCe O/mVOKW+pAJLjVNH1nSYWfWrZATy8LXQyQN7ecpLFwVFrT7ra+Lut3BB/ke2lqCrQgWwNPZlBb9p gDgzzFA5Ef13/Gla6iHLLB8S4razjvi4Pi2vpDJuDrOnQoD4e5L1845fTXmBGaahLIlX3xhQmFZ9 R/uwtglkXUzlVcd3S7oGqwiALCImzU6wJS7Idccf8w8apMUkCSNw7nk4ZsTzbHD87JweE2ptw4+c jAVjq/lzxp0466dcXJbVlPyaiGgKhFWno2gSECuhrLinEGOggyo+vBXmGXF87gZ4iI7gkxM1O7ae TcfK73SCloXmNwgQdsUlXN6X2M2eUFYtMelAZyT3BnK/0GEzUvi5OC/CSaaHbwJmBtozpSuJ0l1z E8WYC8sKypxs/u9ktyiUeXE6AeA8aOcXm4xDJV+hmXNnMn4zPEjPqUe+Df/monlY3Ho4GeIgMX6s dKQMFT5/fXD+sK1Hf1aOPmSNJQYGfeKBtvtk1i3jg6GIj7fGDzQ3DeTkVWQ646KeccekeEWH+fuD XtGwQVRRyuQJkPQ+xwIiq1eG5jophazxKSQ2sR0xNHwC5L5XNog7QBgwfuAyoYyJKHPDUfhvQiKU eNOyqQcurOzsBCJ0P2ONcOFtooL6K6pt7/xlXz+H87dbpWFi0w5OvxJxM1LUwcK2LmQ4KZDjln/g /N4fhNHX33Y5QklIkQlaAj2t1/5wjS3UxlZlqu3kiurCqm+UgU8Ku5FUAyJeXiWbC/2ae4rHUFEe tfsMmob3XTBm8bIKZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9iago3NjgKZW5kb2JqCnhyZWYKMCAx NgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAwMTAgMDAwMDAgbiAKMDAwMDAwMDE4NSAwMDAw MCBuIAowMDAwMDAwMjM0IDAwMDAwIG4gCjAwMDAwMDAyOTMgMDAwMDAgbiAKMDAwMDAwMDQ5NyAw MDAwMCBuIAowMDAwMDAwNTgwIDAwMDAwIG4gCjAwMDAwMDA1OTggMDAwMDAgbiAKMDAwMDAwMDYz NiAwMDAwMCBuIAowMDAwMDAwNzQ0IDAwMDAwIG4gCjAwMDAwMDYzMjUgMDAwMDAgbiAKMDAwMDAw NjM0NiAwMDAwMCBuIAowMDAwMDA2Mzk3IDAwMDAwIG4gCjAwMDAwMDk3NzAgMDAwMDAgbiAKMDAw MDAwOTc5MSAwMDAwMCBuIAowMDAwMDEwNjE0IDAwMDAwIG4gCnRyYWlsZXIKPDwKL1NpemUgMTYK L0luZm8gMSAwIFIKL1Jvb3QgMiAwIFIKPj4Kc3RhcnR4cmVmCjEwNjM0CiUlRU9GCg== --------------050308010504050505030707-- From ict@dart.com.au Wed Jun 27 02:36:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3R8y-00013Y-Sj for pana-archive@lists.ietf.org; Wed, 27 Jun 2007 02:36:48 -0400 Received: from 172-103.onebb.com ([202.180.172.103]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3R8x-0004fQ-6K for pana-archive@lists.ietf.org; Wed, 27 Jun 2007 02:36:48 -0400 Message-ID: <000e01c7b8c9$70e806a0$072f393c@familyla0f4161> From: "Orville Ragland" To: "pana-archive" Subject: Thanks for your recent refinance application, we are ready to lend you some cash Date: Wed, 27 Jun 2007 14:39:20 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C7B8C9.70E806A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.1081 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.181 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 ------=_NextPart_000_000B_01C7B8C9.70E806A0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Your credit history doesn't matter to us! If you OWN real estate and want IMMEDIATE money to spend ANY way you = like, or simply wish to LOWER your current payments by a third or more, = here is the deal we can offer you THIS NIGHT (hurry, this tender will = expire THIS NIGHT): $298,000+ debt AND EVEN MORE: After further review, our lenders have set the lowest = monthly payments! Hurry, when our best deal is gone, it is gone. Simply finish this = elementary form... Don't worry about approval, your credit history will not disqualify you! http://milliaiemiilia.com/ ------=_NextPart_000_000B_01C7B8C9.70E806A0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
Your your credit report = doesn't matter to us!
 
If your family OWN real = estate and want IMMEDIATE money to spend ANY way you like, or simply = need to LOWER your monthly payments by a third or more, here is best = deal we can offer you TODAY (hurry, this deal will expire THIS = NIGHT):
 
$442,000+ = debt
 
AND EVEN MORE: After = further review, our lenders have set the lowest payments!
 
Hurry, when best deal = is gone, it is gone. Simply fill out this plain form... =
 
Don't worry about = approval, your credit will not disqualify you!
 
------=_NextPart_000_000B_01C7B8C9.70E806A0-- From qswfq@curriebishopservices.com Thu Jun 28 13:14:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3xZt-0003v0-EI for pana-archive@lists.ietf.org; Thu, 28 Jun 2007 13:14:45 -0400 Received: from host-81-190-74-230.gdynia.mm.pl ([81.190.74.230]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I3xZt-0008Gf-0K for pana-archive@lists.ietf.org; Thu, 28 Jun 2007 13:14:45 -0400 Received: from pxo.yni ([92.188.93.109]) by host-81-190-74-230.gdynia.mm.pl with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 19:14:23 +0200 Message-ID: <000b01c7b9a7$c618f5b0$6d5dbc5c@pxo.yni> From: "123greetings.com" To: Subject: You've received a postcard from a family member! Date: Thu, 28 Jun 2007 19:14:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 2.8 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Good day. Your family member has sent you an ecard from 123greetings.com. Send free ecards from 123greetings.com with your choice of colors, words and music. Your ecard will be available with us for the next 30 days. If you wish to keep the ecard longer, you may save it on your computer or take a print. To view your ecard, choose from any of the following options: -------- OPTION 1 -------- Click on the following Internet address or copy & paste it into your browser's address box. http://212.87.103.23/?a1823497b969c2b1c85da463c5c036b -------- OPTION 2 -------- Copy & paste the ecard number in the "View Your Card" box at http://212.87.103.23/ Your ecard number is a1823497b969c2b1c85da463c5c036b Best wishes, Postmaster, 123greetings.com From ncatastrophe@3rivers.net Fri Jun 29 10:15:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4HFV-0005wr-Hm for pana-archive@lists.ietf.org; Fri, 29 Jun 2007 10:15:01 -0400 Received: from [89.156.38.177] (helo=3rivers.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I4HFU-0005pY-Mz for pana-archive@lists.ietf.org; Fri, 29 Jun 2007 10:15:01 -0400 Message-ID: <001001c7ba68$ac21cd50$0628d5c4@padnmd9j1opmv0> From: "Frances Lovell" To: "pana-archive" Subject: Fw: Thanks, we accepted your refinance appication Date: Fri, 29 Jun 2007 16:13:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C7BA68.AC21CD50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.2969 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.1106 X-Antivirus: avast! (VPS 000752-4, 29/06/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 ------=_NextPart_000_000D_01C7BA68.AC21CD50 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Your credit history does not matter to us! If you OWN real estate and want IMMEDIATE pin money to spend ANY way you = like, or simply want to LOWER your entire payment by a third or more, = here is our best deal we can offer you NOW (hurry, this lot will expire = TONIGHT): $349,000+ loan AND EVEN MORE: After further review, our lenders have set the lowest = entire payment! Hurry, when best deal is gone, it is gone. Simply finish this one-minute = form... Do not worry about approval, your credit history will not disqualify = you! http://trylapjkfdterz.com/ ------=_NextPart_000_000D_01C7BA68.AC21CD50 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Your credit history = doesn't matter to us!
 
If you OWN real estate and = want IMMEDIATE pin money to spend ANY way you like, or simply want to = LOWER your monthly payments by a third or more, here is best deal we can = offer you THIS EVENING (hurry, this deal will expire = TONIGHT):
 
$358,000+ = loan
 
AND EVEN MORE: After = further review, our lenders have set the lowest payments!
 
Hurry, when our deal is = gone, it is gone. Simply fill in this short form...
 
Don't worry about = approval, your your credit report will not disqualify you!
 
------=_NextPart_000_000D_01C7BA68.AC21CD50-- From chocochipcookiedp@yahoo.co.uk Fri Jun 29 14:27:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LCA-0001k9-Eb for PANA-ARCHIVE@LISTS.IETF.ORG; Fri, 29 Jun 2007 14:27:50 -0400 Received: from [60.19.207.92] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4LC9-0005EN-HO for PANA-ARCHIVE@LISTS.IETF.ORG; Fri, 29 Jun 2007 14:27:50 -0400 Received: from aokqiijzu2 (unknown [178.181.213.120]) by smtp58 (Coremail) with SMTP id OPOp2jy3axKJIHyz.1 for ; Mon, 30 Jun 2008 02:24:41 +0800 (CST) X-Originating-IP: [178.181.213.120] Subject: =?iso-2022-jp?B?GyRCOiMkSiRpISYhJiEqISkbKEI=?= From: =?shift-jis?B?bm9yaWth?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8C1B2.D4664230" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C8C1B2.D4664230 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCJSglcyVIJWohPEw1TkEkRyEiJSglbSUoJW0kSj13QC1DIyRIRD5AXE8iTW08aCRqSnxCaiRO JTslQyUvJTkkN0p8QmohKiEqISobKEINCg0KGyRCNHw0VjhCRGokQCQrJGkhIjojJCwlQSVjJXMl OSF5GyhCDQoNChskQiUoJXMlSCVqITxMNU5BJE8kMyRBJGkkKyRpGyhCDQpodHRwOi8vc2VyZWJ1 LmJpei9jYXMvP2FzMTMNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KGyRCIUolYSE8JWtHWz8uRGQ7XyRyJDQ0 dUs+JE5KfSRPJDMkQSRpJF4kRyFLGyhCDQptYWtpX25vZGEyMUB5YWhvby5jby51ayANCg== ------=_NextPart_000_0006_01C8C1B2.D4664230 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjc2OSIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj IiBzaXplPTI+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPg0KPERJVj48 Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIA0Kc2l6ZT0yPhskQiUoJXMlSCVqITxMNU5BJEchIiUo JW0lKCVtJEo9d0AtQyMkSEQ+QFxPIk1tPGgkakp8QmokTiU7JUMlLyU5JDdKfEJqISohKiEqGyhC PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPhsk QjR8NFY4QkRqJEAkKyRpISI6IyQsJUElYyVzJTkheRsoQjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj4bJEIlKCVzJUglaiE8TDVOQSRPJDMkQSRp JCskaRsoQjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0bJEJBV0JOGyhCPjxBIA0KaHJl Zj0iaHR0cDovL3NlcmVidS5iaXovY2FzLz9hczEzIj5odHRwOi8vc2VyZWJ1LmJpei9jYXMvP2Fz MTM8L0E+PEEgDQpocmVmPSJodHRwOi8vd3d3Lml3eHl6LmNvbS9jYXMvP2FzMTMiPjwvQT48L0ZP TlQ+PEEgDQpocmVmPSJodHRwOi8vY2I0MDUuaXB0aW1lLm9yZy9zZXJlYnUvP2FzMTMiPjwvQT48 QlI+PEEgDQpocmVmPSJodHRwOi8vdmx6aC5jb20vP2FzMTMiPjwvQT48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8 RElWPjxGT05UIHNpemU9Mj4bJEIhSiVhITwla0dbPy5EZDtfJHIkNDR1Sz4kTkp9JE8kMyRBJGkk XiRHIUsbKEI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxBIGhyZWY9Im1haWx0bzptYWtpX25vZGEyMUB5 YWhvby5jby51ayI+bWFraV9ub2RhMjFAeWFob28uY28udWs8L0E+IA0KPEJSPjwvRElWPjwvRElW PjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0006_01C8C1B2.D4664230--