From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 2 07:11:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11090 for ; Tue, 2 Sep 2003 07:11:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u93x-0003ms-00 for forces-archive@IETF.ORG; Tue, 02 Sep 2003 07:11:05 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19u93w-0003ml-00 for forces-archive@IETF.ORG; Tue, 02 Sep 2003 07:11:04 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00B2DAC8@cherry.ease.lsoft.com>; Tue, 2 Sep 2003 7:11:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53508165 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 2 Sep 2003 07:11:01 -0400 Received: from 163.162.42.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Sep 2003 07:11:01 -0400 Received: from iowa2k01b.cselt.it (iowa2k01b.cselt.it [163.162.242.204]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0HKL006A92ZSTE@dns2.cselt.it> for FORCES@PEACH.EASE.LSOFT.COM; Tue, 02 Sep 2003 13:09:29 +0200 (MEST) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Tue, 02 Sep 2003 13:10:54 +0200 Received: from EXC2K01A.cselt.it ([163.162.4.34]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Tue, 02 Sep 2003 13:10:13 +0200 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K01A.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Tue, 02 Sep 2003 12:22:58 +0200 MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: normal Priority: normal Thread-Topic: Unsubscribe Thread-Index: AcNraq2fk37CLWjwSkSnfOWQJpc8VgDCRuGwALHNpcA= content-class: urn:content-classes:message X-OriginalArrivalTime: 02 Sep 2003 10:22:58.0221 (UTC) FILETIME=[2E1E25D0:01C3713C] Message-ID: <3549E655A098D2458CE15E0BE3A7D45043000E@EXC2K01B.cselt.it> Date: Tue, 2 Sep 2003 12:14:54 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Salamandra Paolo Subject: Unsubscribe To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 12 02:36:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10487 for ; Fri, 12 Sep 2003 02:36:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xhY3-0002ic-00 for forces-archive@IETF.ORG; Fri, 12 Sep 2003 02:36:51 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19xhY3-0002iY-00 for forces-archive@IETF.ORG; Fri, 12 Sep 2003 02:36:51 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00B76B3F@cherry.ease.lsoft.com>; Fri, 12 Sep 2003 2:36:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54750159 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 12 Sep 2003 02:36:50 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 12 Sep 2003 02:36:50 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8BFuqQ06959 for ; Thu, 11 Sep 2003 15:56:53 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8BFruI08121 for ; Thu, 11 Sep 2003 15:53:57 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003091108591032528 for ; Thu, 11 Sep 2003 08:59:10 -0700 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Sep 2003 08:59:10 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [FORCES] Protocol Selection Process Discussion Thread-Index: AcNraq2nGmx0d2E/RXuAEbkp2z7Y4wNEfurA X-OriginalArrivalTime: 11 Sep 2003 15:59:10.0806 (UTC) FILETIME=[A3A21760:01C3787D] Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F465@orsmsx409.jf.intel.com> Date: Thu, 11 Sep 2003 08:59:10 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Protocol Selection Process Discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable All, September 15, the deadline for the selection procedural=20 discussion end date, is rapidly approaching. Thus far we have received comments from Avri suggesting going with a combination process (see below). Patrick & I will be taking the recommendation below and working with the ADs to specify the exact process=20 starting on the 15th. I urge anyone who has any other=20 suggestions to please comment asap. Thanks, David > -----Original Message----- > From: avri [mailto:avri@psg.com]=20 > Sent: Monday, August 25, 2003 5:27 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Protocol Selection Process Discussion >=20 >=20 > Hi, >=20 > You list 3 methods. I propose that you use two of the the methods and > hold the third in reserve. >=20 > I..e Require each of the proponent groups to submit a d evaluation > draft of their protocol against the requirements and discuss this on > the WG list for some bounded time; e.g. a month. If consensus is > reached n the list then you have selection. If it doesn't, at that > point create the committee. They can take the protocols, the > evaluations and the comments made by the WG and come up with a > recommendation, again in some measure of bounded time. >=20 > In any case i suggest the group use 2 out of three. Even if the WG > decides to go straight to committee, I believe the proponents should > create the evaluation drafts. And of course I believe those > evaluations should be discussed on the list. >=20 > I don't think, btw, that it should fall only on the authors to create > these evaluation drafts. If they can get others who support their > proposal to contribute to them, I think that is good. >=20 >=20 > a. >=20 > On tisdag, aug 26, 2003, at 00:49 Asia/Seoul, Putzolu, David wrote: >=20 > > At least three methods of protocol selection are possible: > > > > Evaluation committee: Choose a committee of experts that > > examine the proposed protocols and make a recommendation to the > > working group. Experts are drawn from a set of volunteers > > and are approved by the chairs and ADs. The experts > > evaluate protocol proposals and make a recommendation > > to the WG. The WG would then have a brief discussion period > > followed by a consensus call by the chairs. > > > > Protocol evaluation draft: The authors of each protocol proposal > > are asked to contribute to a draft that includes a > > section dedicated to each protocol. In the relevant section > > the authors of each protocol show on a point-by-point basis > > how their protocol meets the requirements and fits into the > > framework. Once completed, the WG reviews the draft, which > > is followed by a consensus call by the chairs. > > > > WG discussion: The WG as a whole holds a discussion on the > > mailing list of the merits of each protocol proposal. At > > the end of the discussion, the chairs make a consensus call. > > >=20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 12 09:51:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22542 for ; Fri, 12 Sep 2003 09:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xoL3-0006jT-00 for forces-archive@IETF.ORG; Fri, 12 Sep 2003 09:51:53 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19xoL2-0006jE-00 for forces-archive@IETF.ORG; Fri, 12 Sep 2003 09:51:52 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00B7803F@cherry.ease.lsoft.com>; Fri, 12 Sep 2003 9:51:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54789714 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 12 Sep 2003 09:51:11 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 12 Sep 2003 09:41:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21673; Fri, 12 Sep 2003 09:41:03 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200309121341.JAA21673@ietf.org> Date: Fri, 12 Sep 2003 09:41:03 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wang-forces-grmp-00.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : General Router Management Protocol (GRMP) Version 1 Author(s) : W. Wang et al. Filename : draft-wang-forces-grmp-00.txt Pages : 67 Date : 2003-9-12 This document defines the General Router Management Protocol (GRMP) Version 1. This protocol is based on an open programmable router architecture defined in the ForCES requirements in RFC xxxx and in the ForCES framework. GRMP protocol is designed to meet all the requirements for the ForCES protocol at Fp reference point in the ForCES architecture, where the ForCES protocol acts as a base protocol and ForCES FE model acts as a data model for this protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wang-forces-grmp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-wang-forces-grmp-00.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-wang-forces-grmp-00.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: <2003-9-12084449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wang-forces-grmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-wang-forces-grmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-12084449.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 12 11:13:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28031 for ; Fri, 12 Sep 2003 11:13:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xpbp-0000FQ-00 for forces-archive@IETF.ORG; Fri, 12 Sep 2003 11:13:17 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19xpbo-0000FN-00 for forces-archive@IETF.ORG; Fri, 12 Sep 2003 11:13:16 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00B78D1B@cherry.ease.lsoft.com>; Fri, 12 Sep 2003 11:13:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54796544 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 12 Sep 2003 11:12:21 -0400 Received: from 194.196.100.234 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 12 Sep 2003 11:12:21 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h8CFCJMD072122 for ; Fri, 12 Sep 2003 17:12:19 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8CFCJUm250934 for ; Fri, 12 Sep 2003 17:12:19 +0200 Received: from zurich.ibm.com (dhcp222-47.zurich.ibm.com [9.4.222.47]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA152350 for ; Fri, 12 Sep 2003 17:12:19 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <52D13A805349A249960B9943E5590BD881F465@orsmsx409.jf.intel.com> Content-Type: multipart/alternative; boundary="------------010005010903060802050602" Approved-By: Robert Haas Message-ID: <3F61E253.8000903@zurich.ibm.com> Date: Fri, 12 Sep 2003 17:12:19 +0200 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: Protocol Selection Process Discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --------------010005010903060802050602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by d12lmsgate.de.ibm.com id h8CFCJMD072122 Content-Transfer-Encoding: quoted-printable David, The "Protocol evaluation draft" and/or the "WG discussion" methods seem=20 fine. For the sake of transparency the "Evaluation committee" should be=20 avoided. Regards, -Robert Putzolu, David wrote: >All, > >September 15, the deadline for the selection procedural=20 >discussion end date, is rapidly approaching. Thus far >we have received comments from Avri suggesting going >with a combination process (see below). > >Patrick & I will be taking the recommendation below >and working with the ADs to specify the exact process=20 >starting on the 15th. I urge anyone who has any other=20 >suggestions to please comment asap. > >Thanks, >David > > =20 > >>-----Original Message----- >>From: avri [mailto:avri@psg.com]=20 >>Sent: Monday, August 25, 2003 5:27 PM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Re: [FORCES] Protocol Selection Process Discussion >> >> >>Hi, >> >>You list 3 methods. I propose that you use two of the the methods and >>hold the third in reserve. >> >>I..e Require each of the proponent groups to submit a d evaluation >>draft of their protocol against the requirements and discuss this on >>the WG list for some bounded time; e.g. a month. If consensus is >>reached n the list then you have selection. If it doesn't, at that >>point create the committee. They can take the protocols, the >>evaluations and the comments made by the WG and come up with a >>recommendation, again in some measure of bounded time. >> >>In any case i suggest the group use 2 out of three. Even if the WG >>decides to go straight to committee, I believe the proponents should >>create the evaluation drafts. And of course I believe those >>evaluations should be discussed on the list. >> >>I don't think, btw, that it should fall only on the authors to create >>these evaluation drafts. If they can get others who support their >>proposal to contribute to them, I think that is good. >> >> >>a. >> >>On tisdag, aug 26, 2003, at 00:49 Asia/Seoul, Putzolu, David wrote: >> >> =20 >> >>>At least three methods of protocol selection are possible: >>> >>>Evaluation committee: Choose a committee of experts that >>> examine the proposed protocols and make a recommendation to the >>> working group. Experts are drawn from a set of volunteers >>> and are approved by the chairs and ADs. The experts >>> evaluate protocol proposals and make a recommendation >>> to the WG. The WG would then have a brief discussion period >>> followed by a consensus call by the chairs. >>> >>>Protocol evaluation draft: The authors of each protocol proposal >>> are asked to contribute to a draft that includes a >>> section dedicated to each protocol. In the relevant section >>> the authors of each protocol show on a point-by-point basis >>> how their protocol meets the requirements and fits into the >>> framework. Once completed, the WG reviews the draft, which >>> is followed by a consensus call by the chairs. >>> >>>WG discussion: The WG as a whole holds a discussion on the >>> mailing list of the merits of each protocol proposal. At >>> the end of the discussion, the chairs make a consensus call. >>> >>> =20 >>> > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------010005010903060802050602 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit David,
The "Protocol evaluation draft" and/or the "WG discussion" methods seem fine. For the sake of transparency the "Evaluation committee" should be avoided.

Regards,
-Robert

Putzolu, David wrote:
All,

September 15, the deadline for the selection procedural
discussion end date, is rapidly approaching.  Thus far
we have received comments from Avri suggesting going
with a combination process (see below).

Patrick & I will be taking the recommendation below
and working with the ADs to specify the exact process
starting on the 15th.  I urge anyone who has any other
suggestions to please comment asap.

Thanks,
David

  
-----Original Message-----
From: avri [mailto:avri@psg.com]
Sent: Monday, August 25, 2003 5:27 PM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] Protocol Selection Process Discussion


Hi,

You list 3 methods.  I propose that you use two of the the methods and
hold the third in reserve.

I..e Require each of the proponent groups to submit a d evaluation
draft of their protocol against the requirements and discuss this on
the WG list for some bounded time; e.g. a month.  If consensus is
reached n the list then you have selection.  If it doesn't, at that
point create the committee.  They can take the protocols, the
evaluations and the comments made by the WG and come up with a
recommendation, again in some measure of bounded time.

In any case i suggest the group use 2 out of three.  Even if the WG
decides to go straight to committee, I believe the proponents should
create the evaluation drafts.  And of course I believe those
evaluations should be discussed on the list.

I don't think, btw, that it should fall only on the authors to create
these evaluation drafts.  If they can get others who support their
proposal to contribute to them, I think that is good.


a.

On tisdag, aug 26, 2003, at 00:49 Asia/Seoul, Putzolu, David wrote:

    
At least three methods of protocol selection are possible:

Evaluation committee:  Choose a committee of experts that
    examine the proposed protocols and make a recommendation to the
    working group.  Experts are drawn from a set of volunteers
    and are approved by the chairs and ADs.  The experts
    evaluate protocol proposals and make a recommendation
    to the WG.  The WG would then have a brief discussion period
    followed by a consensus call by the chairs.

Protocol evaluation draft: The authors of each protocol proposal
    are asked to contribute to a draft that includes a
    section dedicated to each protocol.  In the relevant section
    the authors of each protocol show on a point-by-point basis
    how their protocol meets the requirements and fits into the
    framework.  Once completed, the WG reviews the draft, which
    is followed by a consensus call by the chairs.

WG discussion: The WG as a whole holds a discussion on the
    mailing list of the merits of each protocol proposal. At
    the end of the discussion, the chairs make a consensus call.

      


  

--
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

--------------010005010903060802050602-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 15 10:00:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29766 for ; Mon, 15 Sep 2003 10:00:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yttu-0001Yv-00 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 10:00:22 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19yttu-0001Ym-00 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 10:00:22 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00B8D7A3@cherry.ease.lsoft.com>; Mon, 15 Sep 2003 10:00:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55077550 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 10:00:13 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Sep 2003 10:00:09 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003091507053154:11145 ; Mon, 15 Sep 2003 07:05:31 -0700 References: <52D13A805349A249960B9943E5590BD881F3D1@orsmsx409.jf.intel.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/15/2003 07:05:31 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/15/2003 07:05:32 AM, Serialize complete at 09/15/2003 07:05:32 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1063632456.1078.96.camel@jzny.localdomain> Date: Mon, 15 Sep 2003 10:00:07 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Selection Process Discussion To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F3D1@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit No committees please. The mailing list is pretty much dead other than from people who believe certain things so i am not sure where you will unbiased experts - if you can it will help incase of deadlocks. Posting to the mailing list will get the usual suspects responding anyways. I think the requirements draft should be applied. We shouldnt stop some protocol doing a lot of of slicing and dicing but that should get no bonus in the evaluation. cheers, jamal On Mon, 2003-08-25 at 11:49, Putzolu, David wrote: > All, > > The requirements document has gone to IESG review and appears > complete, and the framework, delta a couple of final > topics recently raised, is approaching the same state. With the > model draft accepted as a WG document, and at least two protocol > proposals on the table, it is time to start thinking about > how we will go about protocol selection. > > At least three methods of protocol selection are possible: > > Evaluation committee: Choose a committee of experts that > examine the proposed protocols and make a recommendation to the > working group. Experts are drawn from a set of volunteers > and are approved by the chairs and ADs. The experts > evaluate protocol proposals and make a recommendation > to the WG. The WG would then have a brief discussion period > followed by a consensus call by the chairs. > > Protocol evaluation draft: The authors of each protocol proposal > are asked to contribute to a draft that includes a > section dedicated to each protocol. In the relevant section > the authors of each protocol show on a point-by-point basis > how their protocol meets the requirements and fits into the > framework. Once completed, the WG reviews the draft, which > is followed by a consensus call by the chairs. > > WG discussion: The WG as a whole holds a discussion on the > mailing list of the merits of each protocol proposal. At > the end of the discussion, the chairs make a consensus call. > > Please comment on the procedures above or suggest an alternate > procedure. We would like to reach a consensus on this topic by > September 15 so please comment on this in a timely fashion. > Completion of this topic will also signal the start of > protocol selection (and the date by which protocol submissions > should be in place). > > Thanks, > David & Patrick From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 15 10:10:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01665 for ; Mon, 15 Sep 2003 10:10:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yu3w-0002nc-00 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 10:10:44 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19yu3w-0002nV-00 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 10:10:44 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00B8D831@cherry.ease.lsoft.com>; Mon, 15 Sep 2003 10:10:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55077628 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 10:10:33 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Sep 2003 10:00:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29815; Mon, 15 Sep 2003 10:00:26 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200309151400.KAA29815@ietf.org> Date: Mon, 15 Sep 2003 10:00:25 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gopal-forces-fact-05.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ForwArding and Control ElemenT protocol (FACT) Author(s) : A. Audu, R. Gopal Filename : draft-gopal-forces-fact-05.txt Pages : 48 Date : 2003-9-15 This document defines the FACT protocol that is designed for communicating between Forwarding Element and Control Elements inside a network element. This protocol addresses all the requirements described in the Forces [3] requirements document. This document also specifies architectural attributes necessary in an implementation of FACT to ensure correct and secure protocol operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gopal-forces-fact-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-gopal-forces-fact-05.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-gopal-forces-fact-05.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: <2003-9-15100337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gopal-forces-fact-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-gopal-forces-fact-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-15100337.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 15 10:47:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29769 for ; Mon, 15 Sep 2003 10:00:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yttv-0001Z1-00 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 10:00:23 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19yttu-0001Ym-01 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 10:00:22 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00B8D8A8@cherry.ease.lsoft.com>; Mon, 15 Sep 2003 10:00:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55077557 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 10:00:16 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Sep 2003 10:00:16 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003091507053529:11146 ; Mon, 15 Sep 2003 07:05:35 -0700 References: Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/15/2003 07:05:35 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/15/2003 07:05:39 AM, Serialize complete at 09/15/2003 07:05:39 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1063632603.1076.98.camel@jzny.localdomain> Date: Mon, 15 Sep 2003 10:00:11 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: propose change to address multicast security issue Comments: cc: msec@securemulticast.org, Ran Canetti , Thomas Hardjono To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Lilly, I am not sure if i responded on this or not; if not i apologize too swamped at work. Heres the best alternative IMO; i am crossposting this to the msec wg mailing list (also CCing the WG chairs in case the mailing list is closed). To the folks in MSEC we need your help to come up with good wording in regards to Multicast and security. To break it down, the 4 options that have to be met are: 1. No security - this is pretty obvious, so dont address this. 2. Data integrity - signatures etc. 3. Data authentication - encryption 4. Both integrity and authentication I have read some of the MSEC drafts which are on the last call. From what i read, 2-4 above are requirements that can be met for multicast using IPSEC. The only open issue seems to be that of source-authentication which is still a "work-in-progress" in the form of the TESLA protocol. I have been challenged that if you use both IPsec and Multicast then it can only be done with no replay protection and no automatic rekeying. My reading of those drafts leads me to believe this is based on old data. So the MSEC folks, can you please help us with the above given the status quo or soon tobe status quo? Secondly, what is the status of your different soon-to-be RFCs? What is the scope of your new recharter? cheers, jamal On Fri, 2003-08-29 at 14:39, Yang, Lily L wrote: > Hi, Jamal -- > > I don't think I am making any specific assumptions here. I am merely ducumenting the fact that IPsec itself may not be sufficient and MSEC WG is looking at the issues. I do intend to leave all the details to the protocol discussion. > > I am glad that you brought this important issue to our attention at the first place. So it just puzzles me why we shouldn't at least capture this high level issue in the framework so that protocol designers are aware of it. > > Lily > > > --Original Message-- > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > Sent: Thursday, August 28, 2003 9:40 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: propose change to address multicast security issue > > > > > > Lily, > > > > Unless you are making assumptions about how multicast is to be > > used with IPSEC in a Forces protocol, you shouldnt be pointing > > out issues with "multicast and IPSEC"; just as you shouldnt > > be worrying > > about TLS and its unfitness in some unicast protocol usage. Leave that > > to the protocol discussion. > > > > cheers, > > jamal > > > > PS: MSEC IETF group completed its chartered work and was shutdown. So > > all those docs are awaiting IESG approval to go RFC. Theres a recent > > activity to recharter MSEC. > > > > On Thu, 2003-08-28 at 12:26, Yang, Lily L wrote: > > > Hi, Jamal -- > > > But I believe it is also very important to point > > > out the fact that IPsec itself does not fully address > > > multicast security issues (that is exactly why there is MSEC > > > group working on these issues). So it is simply not sufficient > > > to just say "use IPsec for multicast". > > > > > > Lily > > > > > > > --Original Message-- > > > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > > Sent: Thursday, August 28, 2003 4:09 AM > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > Subject: Re: propose change to address multicast security issue > > > > > > > > > > > > Hi Lilly, > > > > > > > > Sorry - meant to respond to your earlier yesterday, but work > > > > comes first. > > > > > > > > The text i see fit is: > > > > "While TLS supports only unicast, IPsec can support both > > unicast and > > > > multicast transports." > > > > > > > > Lets leave the rest of the discussion to protocol time. > > > > > > > > cheers, > > > > jamal > > > > > > > > On Wed, 27 Aug 2003, Yang, Lily L wrote: > > > > > > > > > To address the issue over multicast security, I propose the > > > > following changes to framework section 7.2.3: > > > > > > > > > > [old 3rd paragraph] > > > > > "IPsec can support both unicast and multicast transport. When > > > > > multicast is used, IPsec can be used with manual > > keying with no > > > > > replay protection and no automatic rekeying. This > > meets the > > > > > confidentiality and integrity requirements. Multicast-based > > > > > solutions relying on IPsec should specify how rekeying > > > > and replay > > > > > protection are provided. " > > > > > > > > > > [ new text ] > > > > > "IPsec can support both unicast and multicast transport. > > > > However, RFC 2401 [14] acknowledged that it did not specify > > > > complete support for IP multicast. At the time this document > > > > was published, MSEC working group is actively working on > > > > standardizing protocols to provide multicast security [17]. > > > > Multicast-based solutions relying on IPsec should specify how > > > > to meet the security requirements in [3]. " > > > > > > > > > > Adding the following to Section 9: Informative References: > > > > > [17] Hardjono, T. and Weis, B. "The Multicast Security > > > > Architecture", work in progress, August 2003, > > > > . > > > > > > > > > > I would like the two of you and the WG review this. If > > > > satisfactory, I would roll all the recent changes per > > > > discussion on the list into v09 and ask for IESG review on it. > > > > > > > > > > Thanks, > > > > > > > > > > Lily > > > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 15 20:52:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04927 for ; Mon, 15 Sep 2003 20:52:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z454-00017M-00 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 20:52:34 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19z453-00017J-00 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 20:52:33 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00B95365@cherry.ease.lsoft.com>; Mon, 15 Sep 2003 20:52:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55129968 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 20:52:32 -0400 Received: from 63.78.179.217 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Sep 2003 20:52:32 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8G0qVG29235 for ; Mon, 15 Sep 2003 19:52:31 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 15 Sep 2003 19:52:27 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 15 Sep 2003 17:51:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Protocol Selection Process Discussion Thread-Index: AcNraPGqMQNOJgIiQ+q/49RdWH79bQQg5NEw X-OriginalArrivalTime: 16 Sep 2003 00:51:53.0484 (UTC) FILETIME=[B886B4C0:01C37BEC] Approved-By: ram.gopal@NOKIA.COM Message-ID: Date: Mon, 15 Sep 2003 20:51:48 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "(Ram Gopal )" Subject: Re: Protocol Selection Process Discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I agree to avri's view. Regards Ramg > -----Original Message----- > From: ext avri [mailto:avri@psg.com] > Sent: Monday, August 25, 2003 8:27 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Protocol Selection Process Discussion >=20 >=20 > Hi, >=20 > You list 3 methods. I propose that you use two of the the methods and > hold the third in reserve. >=20 > I..e Require each of the proponent groups to submit a d evaluation > draft of their protocol against the requirements and discuss this on > the WG list for some bounded time; e.g. a month. If consensus is > reached n the list then you have selection. If it doesn't, at that > point create the committee. They can take the protocols, the > evaluations and the comments made by the WG and come up with a > recommendation, again in some measure of bounded time. >=20 > In any case i suggest the group use 2 out of three. Even if the WG > decides to go straight to committee, I believe the proponents should > create the evaluation drafts. And of course I believe those > evaluations should be discussed on the list. >=20 > I don't think, btw, that it should fall only on the authors to create > these evaluation drafts. If they can get others who support their > proposal to contribute to them, I think that is good. >=20 >=20 > a. >=20 > On tisdag, aug 26, 2003, at 00:49 Asia/Seoul, Putzolu, David wrote: >=20 > > At least three methods of protocol selection are possible: > > > > Evaluation committee: Choose a committee of experts that > > examine the proposed protocols and make a recommendation to the > > working group. Experts are drawn from a set of volunteers > > and are approved by the chairs and ADs. The experts > > evaluate protocol proposals and make a recommendation > > to the WG. The WG would then have a brief discussion period > > followed by a consensus call by the chairs. > > > > Protocol evaluation draft: The authors of each protocol proposal > > are asked to contribute to a draft that includes a > > section dedicated to each protocol. In the relevant section > > the authors of each protocol show on a point-by-point basis > > how their protocol meets the requirements and fits into the > > framework. Once completed, the WG reviews the draft, which > > is followed by a consensus call by the chairs. > > > > WG discussion: The WG as a whole holds a discussion on the > > mailing list of the merits of each protocol proposal. At > > the end of the discussion, the chairs make a consensus call. > > >=20 From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 15 22:29:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07377 for ; Mon, 15 Sep 2003 22:29:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z5aq-00021E-00 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 22:29:29 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19z5aq-00021B-00 for forces-archive@IETF.ORG; Mon, 15 Sep 2003 22:29:28 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00B954D5@cherry.ease.lsoft.com>; Mon, 15 Sep 2003 22:29:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55138689 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 22:28:45 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Sep 2003 22:28:44 -0400 Received: from psg.com ([147.28.0.62]) by psg.com with esmtp (Exim 4.22) id 19z5a7-000MN2-NX for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Sep 2003 02:28:44 +0000 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Approved-By: avri Message-ID: <5A82600E-E7ED-11D7-8358-000393CC2112@psg.com> Date: Tue, 16 Sep 2003 11:27:44 +0900 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: avri Subject: Re: Protocol Selection Process Discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, While I agree that committees are a second choice, sometimes they are=20 necessary. As for not finding unbiased people, I disagree. I expect=20 that there are folks around who can look at these objectively. There=20 are quite a number of knowledgeable participants on this list who do=20 not seem to have any of the bones to pick regarding the protocol=20 choice. I would trust the chairs and ADs to find a selection of such=20 folks if the need arises. And the proponents of the protocols would be=20= able to recognize whether this was a truly unbiased group. So, if we=20 get to the point of needing a committee, I expect one could be=20 assembled. In terms of the public discussions I will be especially interested=20 hearing in the opinions of people already working on, and implementing,=20= solutions for ForCES type scenarios. I will also be interested in=20 seeing an analysis done by hardware savvy people of issues relating to=20= the degree of ease or difficulty they would have with each of the the 3=20= proposals in hardware. A question: Is the decision going to be an all or nothing decision for=20= one protocol? Having read all three proposals, I am at the point of=20 seeing advantages to all three and weakness is all (not ready to write=20= it up, just hand waving at the moment). While the three protocols have=20= different approaches, and thus I see the group as having to pick one=20 approach, I am hoping that the best elements of each can be worked into=20= the protocol that makes it on to the standards track. a. On m=E5ndag, sep 15, 2003, at 23:00 Asia/Seoul, Jamal Hadi Salim wrote: > No committees please. The mailing list is pretty much dead other > than from people who believe certain things so i am not sure where you > will unbiased experts - if you can it will help incase of deadlocks. > Posting to the mailing list will get the usual suspects responding > anyways. > I think the requirements draft should be applied. We shouldnt stop > some protocol doing a lot of of slicing and dicing but that should get > no bonus in the evaluation. > > cheers, > jamal > > > On Mon, 2003-08-25 at 11:49, Putzolu, David wrote: From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 16 10:10:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14802 for ; Tue, 16 Sep 2003 10:10:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zGXa-0002CL-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 10:10:51 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zGXa-0002CH-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 10:10:50 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00B96E6C@cherry.ease.lsoft.com>; Tue, 16 Sep 2003 10:10:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55204730 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Sep 2003 10:10:48 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Sep 2003 10:10:39 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5406913 for forces@peach.ease.lsoft.com; Tue, 16 Sep 2003 10:10:39 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> Date: Tue, 16 Sep 2003 10:10:21 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list In conversations about one of the protocols that has been proposed, an element of the requirements document was pointed out to me: 10) In a ForCES NE, the FEs MUST be able to provide their topology information (topology by which the FEs in the NE are connected) to the CE(s). I consider this a seriously broken requirement. Cards have minimal (if any) way to know what they are plugged into. Even if a true backplane (as opposed to ethernet switching) is used, the FEs do not generally have any sensible way to know what is reachable over the backplane. In fact, I would consider that this should be archtiecturally out of scope. Understanding / discovering what the links between FEs interconnect is a CE task, not an FE task. It may be too late to remove this from the document. However, as a mandatory requirement on FEs it is a serious mistake. I very much apologize for not having noticed and raised this issue earlier. It is possible that something other than what I am reading is meant by this requirement. If so, it needs to be stated very differently. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 16 10:31:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17565 for ; Tue, 16 Sep 2003 10:31:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zGrv-0002st-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 10:31:51 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zGru-0002sj-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 10:31:50 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00B97091@cherry.ease.lsoft.com>; Tue, 16 Sep 2003 10:31:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55205601 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Sep 2003 10:31:47 -0400 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Sep 2003 10:31:47 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8GEVkwA016227 for ; Tue, 16 Sep 2003 09:31:46 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <5A82600E-E7ED-11D7-8358-000393CC2112@psg.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds951.usa.alcatel.com id h8GEVkwA016227 Approved-By: Alex Audu Message-ID: <3F671ED1.66F9E05B@alcatel.com> Date: Tue, 16 Sep 2003 09:31:45 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Protocol Selection Process Discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hello Avri, I think this is a workable plan. The draft as to how each protocol meets requirements will certainly help. Other than how requirements are met, ar= e there any other set of criteria (tangible and intangible) that the selection process will be based on? I am also thinking of simplicity (complexity), robustness, agility (potential processing speed), flexibility,..) Regards, Alex. avri wrote: > Hi, > > While I agree that committees are a second choice, sometimes they are > necessary. As for not finding unbiased people, I disagree. I expect > that there are folks around who can look at these objectively. There > are quite a number of knowledgeable participants on this list who do > not seem to have any of the bones to pick regarding the protocol > choice. I would trust the chairs and ADs to find a selection of such > folks if the need arises. And the proponents of the protocols would be > able to recognize whether this was a truly unbiased group. So, if we > get to the point of needing a committee, I expect one could be > assembled. > > In terms of the public discussions I will be especially interested > hearing in the opinions of people already working on, and implementing, > solutions for ForCES type scenarios. I will also be interested in > seeing an analysis done by hardware savvy people of issues relating to > the degree of ease or difficulty they would have with each of the the 3 > proposals in hardware. > > A question: Is the decision going to be an all or nothing decision for > one protocol? Having read all three proposals, I am at the point of > seeing advantages to all three and weakness is all (not ready to write > it up, just hand waving at the moment). While the three protocols have > different approaches, and thus I see the group as having to pick one > approach, I am hoping that the best elements of each can be worked into > the protocol that makes it on to the standards track. > > a. > > On m=E5ndag, sep 15, 2003, at 23:00 Asia/Seoul, Jamal Hadi Salim wrote: > > > No committees please. The mailing list is pretty much dead other > > than from people who believe certain things so i am not sure where yo= u > > will unbiased experts - if you can it will help incase of deadlocks. > > Posting to the mailing list will get the usual suspects responding > > anyways. > > I think the requirements draft should be applied. We shouldnt stop > > some protocol doing a lot of of slicing and dicing but that should ge= t > > no bonus in the evaluation. > > > > cheers, > > jamal > > > > > > On Mon, 2003-08-25 at 11:49, Putzolu, David wrote: From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 16 11:00:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20237 for ; Tue, 16 Sep 2003 11:00:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zHJz-0003nB-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 11:00:51 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zHJz-0003n8-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 11:00:51 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00B97256@cherry.ease.lsoft.com>; Tue, 16 Sep 2003 11:00:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55206847 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Sep 2003 11:00:36 -0400 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Sep 2003 11:00:35 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8GF0ZwA021682 for ; Tue, 16 Sep 2003 10:00:35 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3F672591.7E70C921@alcatel.com> Date: Tue, 16 Sep 2003 10:00:33 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Joel, I agree; this type of information has global scope (in terms of the CE set and its FEs) and should be kept in the CE. However, all hope is not lost. An FE should be able to keep information pertaining to whom it speaks with directly. Frankly any object in any sort of list should be able to store pointers to its next or previous neighbors. And it can be argued that this is the best place to keep that information. The CE or some management entity can set the next neighbor information up. The CE should be able to query the FEs for that information. In this model, if the CE is involved in setting neighbors up, then CE will have that knowledge also. If not, then the CE can request for the information. That also may mean that we are keeping that information in two places. Regards, Alex. "Joel M. Halpern" wrote: > In conversations about one of the protocols that has been proposed, an > element of the requirements document was pointed out to me: > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). > > I consider this a seriously broken requirement. Cards have minimal (if > any) way to know what they are plugged into. Even if a true backplane (as > opposed to ethernet switching) is used, the FEs do not generally have any > sensible way to know what is reachable over the backplane. > > In fact, I would consider that this should be archtiecturally out of > scope. Understanding / discovering what the links between FEs interconnect > is a CE task, not an FE task. > > It may be too late to remove this from the document. > However, as a mandatory requirement on FEs it is a serious mistake. > > I very much apologize for not having noticed and raised this issue earlier. > > It is possible that something other than what I am reading is meant by this > requirement. If so, it needs to be stated very differently. > > Yours, > Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 16 12:00:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23815 for ; Tue, 16 Sep 2003 12:00:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zIG6-0004sv-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 12:00:54 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zIG5-0004ss-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 12:00:53 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00B97A6B@cherry.ease.lsoft.com>; Tue, 16 Sep 2003 12:00:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55209040 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Sep 2003 12:00:14 -0400 Received: from 198.24.6.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Sep 2003 12:00:14 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h8GG0EAP010066 for ; Tue, 16 Sep 2003 11:00:14 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 16 Sep 2003 11:00:11 -0500 Received: from ericsson.com (142.133.72.81 [142.133.72.81]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id SXLS02PY; Tue, 16 Sep 2003 12:02:32 -0400 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, fr, de, no, nn, sv, MIME-Version: 1.0 References: <5A82600E-E7ED-11D7-8358-000393CC2112@psg.com> <3F671ED1.66F9E05B@alcatel.com> Content-Type: multipart/alternative; boundary="------------070901080602040301000303" Approved-By: Jon Maloy Message-ID: <3F67337E.5060005@ericsson.com> Date: Tue, 16 Sep 2003 11:59:58 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jon Maloy Subject: Re: Protocol Selection Process Discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --------------070901080602040301000303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by imr2.ericy.com id h8GG0EAP010066 Content-Transfer-Encoding: quoted-printable I think it is too early to do any selection of protocol yet.=20 For IETF-58 I am now writing a formal draft for how TIPC can be used as a base protocol for the Forces protocol, and if=20 adopted, this would have an effect on what an upper layer protocol would need to contain.=20 There are several good reasons to consider TIPC, as I see it:=20 it is an existing product, and it solves all the topology issues=20 (inluding requirement 10, which is Joel's concern) in a very=20 simple way.=20 I would rather that the WG does not rush to a decision at a time when we still don't have all the facts on the table. Regards /Jon Maloy Alex Audu wrote: Hello Avri, I think this is a workable plan. The draft as to how each protocol meets requirements will certainly help. Other than how requirements are met, are there any other set of criteria (tangible and intangible) that the selection process will be based on? I am also thinking of simplicity (complexity), robustness, agility (potential processing speed), flexibility,..) Regards, Alex. avri wrote: =20 Hi, While I agree that committees are a second choice, sometimes they are necessary. As for not finding unbiased people, I disagree. I expect that there are folks around who can look at these objectively. There are quite a number of knowledgeable participants on this list who do not seem to have any of the bones to pick regarding the protocol choice. I would trust the chairs and ADs to find a selection of such folks if the need arises. And the proponents of the protocols would be able to recognize whether this was a truly unbiased group. So, if we get to the point of needing a committee, I expect one could be assembled. In terms of the public discussions I will be especially interested hearing in the opinions of people already working on, and implementing, solutions for ForCES type scenarios. I will also be interested in seeing an analysis done by hardware savvy people of issues relating to the degree of ease or difficulty they would have with each of the the 3 proposals in hardware. A question: Is the decision going to be an all or nothing decision for one protocol? Having read all three proposals, I am at the point of seeing advantages to all three and weakness is all (not ready to write it up, just hand waving at the moment). While the three protocols have different approaches, and thus I see the group as having to pick one approach, I am hoping that the best elements of each can be worked into the protocol that makes it on to the standards track. a. On m=E5ndag, sep 15, 2003, at 23:00 Asia/Seoul, Jamal Hadi Salim wrote: =20 No committees please. The mailing list is pretty much dead other than from people who believe certain things so i am not sure where you will unbiased experts - if you can it will help incase of deadlocks. Posting to the mailing list will get the usual suspects responding anyways. I think the requirements draft should be applied. We shouldnt stop some protocol doing a lot of of slicing and dicing but that should get no bonus in the evaluation. cheers, jamal On Mon, 2003-08-25 at 11:49, Putzolu, David wrote : =20 --------------070901080602040301000303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I think it is too early to do any selection of protocol yet.
For IETF-58 I am now writing a formal draft for how TIPC
can be used as a base protocol for the Forces protocol, and if
adopted, this would have an effect on what an upper layer
protocol would need to contain.
There are several good reasons to consider TIPC, as I see it:
it is an existing product, and it solves all the topology issues
(inluding requirement 10, which is Joel's concern) in a very
simple way.
I would rather that the WG does not rush to a decision at a time
when we still don't have all the facts on the table.

Regards /Jon Maloy


Alex Audu wrote:
Hello Avri,

I think this is a workable plan.  The draft as to how each protocol meets
requirements will certainly help. Other than how requirements are met, are
there
any other set of criteria (tangible and intangible) that the selection
process will
be based on?  I am also thinking of simplicity (complexity), robustness,
agility (potential processing speed), flexibility,..)

Regards,
Alex.

avri wrote:

  
Hi,

While I agree that committees are a second choice, sometimes they are
necessary.  As for not finding unbiased people, I disagree.  I expect
that there are folks around who can look at these objectively.  There
are quite a number of knowledgeable participants on this list who do
not seem to have any of the bones to pick regarding the protocol
choice.  I would trust the chairs and ADs to find a selection of such
folks if the need arises.  And the proponents of the protocols would be
able to recognize whether this was a truly unbiased group.  So, if we
get to the point of needing a committee, I expect one could be
assembled.

In terms of the public discussions I will be especially interested
hearing in the opinions of people already working on, and implementing,
solutions for ForCES type scenarios.  I will also be interested in
seeing an analysis done by hardware savvy people of issues relating to
the degree of ease or difficulty they would have with each of the the 3
proposals in hardware.

A question:  Is the decision going to be an all or nothing decision for
one protocol?  Having read all three proposals, I am at the point of
seeing advantages to all three and weakness is all (not ready to write
it up, just hand waving at the moment).  While the three protocols have
different approaches, and thus I see the group as having to pick one
approach, I am hoping that the best elements of each can be worked into
the protocol that makes it on to the standards track.

a.

On måndag, sep 15, 2003, at 23:00 Asia/Seoul, Jamal Hadi Salim wrote:

    
No committees please. The mailing list is pretty much dead other
than from people who believe certain things so i am not sure where you
will unbiased experts - if you can it will help incase of deadlocks.
Posting to the mailing list will get the usual suspects responding
anyways.
I think the requirements draft should be applied. We shouldnt stop
some protocol doing a lot of of slicing and dicing but that should get
no bonus in the evaluation.

cheers,
jamal


On Mon, 2003-08-25 at 11:49, Putzolu, David wrote
:

--------------070901080602040301000303-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 16 20:46:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21417 for ; Tue, 16 Sep 2003 20:46:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zQSc-0005Y3-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 20:46:22 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zQSb-0005Y0-00 for forces-archive@IETF.ORG; Tue, 16 Sep 2003 20:46:22 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00B9A6E3@cherry.ease.lsoft.com>; Tue, 16 Sep 2003 20:46:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55109877 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Sep 2003 20:46:20 -0400 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Sep 2003 20:46:20 -0400 Received: from wwm2([218.108.158.4]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm43f67cc28; Wed, 17 Sep 2003 08:45:17 +0800 References: <52D13A805349A249960B9943E5590BD881F465@orsmsx409.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Approved-By: Weiming Wang Message-ID: <013401c37cb4$3913c3e0$020aa8c0@wwm2> Date: Wed, 17 Sep 2003 08:39:57 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Protocol Selection Process Discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SWYgd2UgY2FuIGZpbmQgZW5vdWdoIG1lbWJlcnMgZm9yIGV2YWx1YXRpb24gY29tbWl0dGVlLCB0 aGUgd29ycmllZCBwb3NzaWJsZSBiaWFzIGVmZmVjdCBjYW4gIA0KYmUgbG93ZWQgYnkgZmlsdGVy aW5nIHRoZSBldmFsdWF0aW9uIHJlc3VsdHMgc3VjaCBhcyB0byBkaXNjYXJkIHNvbWUgcmVzdWx0 IHRoYXQgYmlhc2VkIGZyb20gdGhlIGF2ZXJhZ2UgdGhlIG1vc3QuIA0KDQpDYW4gd2UgYWxzbyBs ZWFybiBzb21lIGZyb20gb3RoZXIgSUVURiBXR3MgcmVmZXJpbmcgdG8gdGhlIHByb3RvY29sIHNl bGVjdGlvbiBwcm9jZXNzPw0KDQpSZWdhcmRzLA0KV2VpbWluZw0KLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLSANCkZyb206ICJQdXR6b2x1LCBEYXZpZCIgPGRhdmlkLnB1dHpvbHVAaW50ZWwu Y29tPg0KVG86IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQpTZW50OiBUaHVyc2RheSwg U2VwdGVtYmVyIDExLCAyMDAzIDExOjU5IFBNDQpTdWJqZWN0OiBSZTogUHJvdG9jb2wgU2VsZWN0 aW9uIFByb2Nlc3MgRGlzY3Vzc2lvbg0KDQoNCkFsbCwNCg0KU2VwdGVtYmVyIDE1LCB0aGUgZGVh ZGxpbmUgZm9yIHRoZSBzZWxlY3Rpb24gcHJvY2VkdXJhbCANCmRpc2N1c3Npb24gZW5kIGRhdGUs IGlzIHJhcGlkbHkgYXBwcm9hY2hpbmcuICBUaHVzIGZhcg0Kd2UgaGF2ZSByZWNlaXZlZCBjb21t ZW50cyBmcm9tIEF2cmkgc3VnZ2VzdGluZyBnb2luZw0Kd2l0aCBhIGNvbWJpbmF0aW9uIHByb2Nl c3MgKHNlZSBiZWxvdykuDQoNClBhdHJpY2sgJiBJIHdpbGwgYmUgdGFraW5nIHRoZSByZWNvbW1l bmRhdGlvbiBiZWxvdw0KYW5kIHdvcmtpbmcgd2l0aCB0aGUgQURzIHRvIHNwZWNpZnkgdGhlIGV4 YWN0IHByb2Nlc3MgDQpzdGFydGluZyBvbiB0aGUgMTV0aC4gIEkgdXJnZSBhbnlvbmUgd2hvIGhh cyBhbnkgb3RoZXIgDQpzdWdnZXN0aW9ucyB0byBwbGVhc2UgY29tbWVudCBhc2FwLg0KDQpUaGFu a3MsDQpEYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGF2cmkg W21haWx0bzphdnJpQHBzZy5jb21dIA0KPiBTZW50OiBNb25kYXksIEF1Z3VzdCAyNSwgMjAwMyA1 OjI3IFBNDQo+IFRvOiBGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00NCj4gU3ViamVjdDogUmU6 IFtGT1JDRVNdIFByb3RvY29sIFNlbGVjdGlvbiBQcm9jZXNzIERpc2N1c3Npb24NCj4gDQo+IA0K PiBIaSwNCj4gDQo+IFlvdSBsaXN0IDMgbWV0aG9kcy4gIEkgcHJvcG9zZSB0aGF0IHlvdSB1c2Ug dHdvIG9mIHRoZSB0aGUgbWV0aG9kcyBhbmQNCj4gaG9sZCB0aGUgdGhpcmQgaW4gcmVzZXJ2ZS4N Cj4gDQo+IEkuLmUgUmVxdWlyZSBlYWNoIG9mIHRoZSBwcm9wb25lbnQgZ3JvdXBzIHRvIHN1Ym1p dCBhIGQgZXZhbHVhdGlvbg0KPiBkcmFmdCBvZiB0aGVpciBwcm90b2NvbCBhZ2FpbnN0IHRoZSBy ZXF1aXJlbWVudHMgYW5kIGRpc2N1c3MgdGhpcyBvbg0KPiB0aGUgV0cgbGlzdCBmb3Igc29tZSBi b3VuZGVkIHRpbWU7IGUuZy4gYSBtb250aC4gIElmIGNvbnNlbnN1cyBpcw0KPiByZWFjaGVkIG4g dGhlIGxpc3QgdGhlbiB5b3UgaGF2ZSBzZWxlY3Rpb24uICBJZiBpdCBkb2Vzbid0LCBhdCB0aGF0 DQo+IHBvaW50IGNyZWF0ZSB0aGUgY29tbWl0dGVlLiAgVGhleSBjYW4gdGFrZSB0aGUgcHJvdG9j b2xzLCB0aGUNCj4gZXZhbHVhdGlvbnMgYW5kIHRoZSBjb21tZW50cyBtYWRlIGJ5IHRoZSBXRyBh bmQgY29tZSB1cCB3aXRoIGENCj4gcmVjb21tZW5kYXRpb24sIGFnYWluIGluIHNvbWUgbWVhc3Vy ZSBvZiBib3VuZGVkIHRpbWUuDQo+IA0KPiBJbiBhbnkgY2FzZSBpIHN1Z2dlc3QgdGhlIGdyb3Vw IHVzZSAyIG91dCBvZiB0aHJlZS4gIEV2ZW4gaWYgdGhlIFdHDQo+IGRlY2lkZXMgdG8gZ28gc3Ry YWlnaHQgdG8gY29tbWl0dGVlLCBJIGJlbGlldmUgdGhlIHByb3BvbmVudHMgc2hvdWxkDQo+IGNy ZWF0ZSB0aGUgZXZhbHVhdGlvbiBkcmFmdHMuICBBbmQgb2YgY291cnNlIEkgYmVsaWV2ZSB0aG9z ZQ0KPiBldmFsdWF0aW9ucyBzaG91bGQgYmUgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0Lg0KPiANCj4g SSBkb24ndCB0aGluaywgYnR3LCB0aGF0IGl0IHNob3VsZCBmYWxsIG9ubHkgb24gdGhlIGF1dGhv cnMgdG8gY3JlYXRlDQo+IHRoZXNlIGV2YWx1YXRpb24gZHJhZnRzLiAgSWYgdGhleSBjYW4gZ2V0 IG90aGVycyB3aG8gc3VwcG9ydCB0aGVpcg0KPiBwcm9wb3NhbCB0byBjb250cmlidXRlIHRvIHRo ZW0sIEkgdGhpbmsgdGhhdCBpcyBnb29kLg0KPiANCj4gDQo+IGEuDQo+IA0KPiBPbiB0aXNkYWcs IGF1ZyAyNiwgMjAwMywgYXQgMDA6NDkgQXNpYS9TZW91bCwgUHV0em9sdSwgRGF2aWQgd3JvdGU6 DQo+IA0KPiA+IEF0IGxlYXN0IHRocmVlIG1ldGhvZHMgb2YgcHJvdG9jb2wgc2VsZWN0aW9uIGFy ZSBwb3NzaWJsZToNCj4gPg0KPiA+IEV2YWx1YXRpb24gY29tbWl0dGVlOiAgQ2hvb3NlIGEgY29t bWl0dGVlIG9mIGV4cGVydHMgdGhhdA0KPiA+ICAgICBleGFtaW5lIHRoZSBwcm9wb3NlZCBwcm90 b2NvbHMgYW5kIG1ha2UgYSByZWNvbW1lbmRhdGlvbiB0byB0aGUNCj4gPiAgICAgd29ya2luZyBn cm91cC4gIEV4cGVydHMgYXJlIGRyYXduIGZyb20gYSBzZXQgb2Ygdm9sdW50ZWVycw0KPiA+ICAg ICBhbmQgYXJlIGFwcHJvdmVkIGJ5IHRoZSBjaGFpcnMgYW5kIEFEcy4gIFRoZSBleHBlcnRzDQo+ ID4gICAgIGV2YWx1YXRlIHByb3RvY29sIHByb3Bvc2FscyBhbmQgbWFrZSBhIHJlY29tbWVuZGF0 aW9uDQo+ID4gICAgIHRvIHRoZSBXRy4gIFRoZSBXRyB3b3VsZCB0aGVuIGhhdmUgYSBicmllZiBk aXNjdXNzaW9uIHBlcmlvZA0KPiA+ICAgICBmb2xsb3dlZCBieSBhIGNvbnNlbnN1cyBjYWxsIGJ5 IHRoZSBjaGFpcnMuDQo+ID4NCj4gPiBQcm90b2NvbCBldmFsdWF0aW9uIGRyYWZ0OiBUaGUgYXV0 aG9ycyBvZiBlYWNoIHByb3RvY29sIHByb3Bvc2FsDQo+ID4gICAgIGFyZSBhc2tlZCB0byBjb250 cmlidXRlIHRvIGEgZHJhZnQgdGhhdCBpbmNsdWRlcyBhDQo+ID4gICAgIHNlY3Rpb24gZGVkaWNh dGVkIHRvIGVhY2ggcHJvdG9jb2wuICBJbiB0aGUgcmVsZXZhbnQgc2VjdGlvbg0KPiA+ICAgICB0 aGUgYXV0aG9ycyBvZiBlYWNoIHByb3RvY29sIHNob3cgb24gYSBwb2ludC1ieS1wb2ludCBiYXNp cw0KPiA+ICAgICBob3cgdGhlaXIgcHJvdG9jb2wgbWVldHMgdGhlIHJlcXVpcmVtZW50cyBhbmQg Zml0cyBpbnRvIHRoZQ0KPiA+ICAgICBmcmFtZXdvcmsuICBPbmNlIGNvbXBsZXRlZCwgdGhlIFdH IHJldmlld3MgdGhlIGRyYWZ0LCB3aGljaA0KPiA+ICAgICBpcyBmb2xsb3dlZCBieSBhIGNvbnNl bnN1cyBjYWxsIGJ5IHRoZSBjaGFpcnMuDQo+ID4NCj4gPiBXRyBkaXNjdXNzaW9uOiBUaGUgV0cg YXMgYSB3aG9sZSBob2xkcyBhIGRpc2N1c3Npb24gb24gdGhlDQo+ID4gICAgIG1haWxpbmcgbGlz dCBvZiB0aGUgbWVyaXRzIG9mIGVhY2ggcHJvdG9jb2wgcHJvcG9zYWwuIEF0DQo+ID4gICAgIHRo ZSBlbmQgb2YgdGhlIGRpc2N1c3Npb24sIHRoZSBjaGFpcnMgbWFrZSBhIGNvbnNlbnN1cyBjYWxs Lg0KPiA+DQo+ From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 17 00:31:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28456 for ; Wed, 17 Sep 2003 00:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zTyA-0000Im-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 00:31:10 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zTyA-0000Ij-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 00:31:10 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00B9B94C@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 0:31:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55138290 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 00:28:38 -0400 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 00:28:37 -0400 Received: from wwm1([218.108.154.223]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm333f68003f; Wed, 17 Sep 2003 12:27:32 +0800 References: <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Approved-By: Weiming Wang Message-ID: <004801c37cd4$138e9c10$3d19fea9@wwm1> Date: Wed, 17 Sep 2003 12:27:59 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Requirements Comments: cc: wmwang@mail.hzic.edu.cn To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SGkgSm9lbCwNCg0KSSB3YXMgaGF2aW5nIHRoZSBzYW1lIGZlZWxpbmcgYXMgeW91cnMgcmVnYXJk aW5nIHdobyBzaG91bGQgbWFuYWdlIHRoZSBGRSBjb25uZWN0aW9uLCANCndoZW4gSSBjb21wYXJl ZCBGb3JDRVMgYXJjaGl0ZWN0dXJlIHdpdGggY3VycmVudCBwb3B1bGFyIGJhY2twbGFuZSBiYXNl ZCBtYWNoaW5lIGJveCwNCndoaWNoIHN1cHBvcnQgUG5QIGZ1bmN0aW9uLiBJIHRob3VnaHQgdGhh dCBGRSBtaWdodCBub3QgYmUgYWJsZSB0byBwZXJmb3JtIFBuUCBieSBpdHNlbGYsIGluc3RlYWQN Cml0IHNob3VsZCByZWx5IG9uIENFIHRvIGRvIHRoaXMuIA0KDQpCdXQgbGF0ZXIgSSBjaGFuZ2Vk IHRoZSBtaW5kLCBJIGZvdW5kIGluIEZvckNFUywgQ0UgaXMgZXZlbiBtb3JlIGF3YXkgZnJvbSBw ZXJmb3JtaW5nDQp0aGlzLiAgQ0UgaGFzIHRoZSBwb3dlciB0byBmaW5kIEZFcyBjb25uZWN0ZWQg d2l0aCBpdCBidXQgaGFzIGxpdHRsZSBwb3dlciB0byBkaXNjb3ZlciBob3cgRkVzIGFyZSANCmlu dGVyY29ubmVjdGVkIHdpdGggb3RoZXIgRkVzLiBUaGVyZWZvcmUsIGlmIHdlIHJlbHkgb24gQ0Ug dG8gZGlzY292ZXIgaW50ZXJjb25uZWN0aW9ucyBvZiBGRXMsIG9ubHkgdHdvIHdheXMgYXJlIGFw cGxpY2FibGUsDQpvbmUgaXMgbWFudWFsbHkgdG8gc2V0IGl0IG9uIENFLCB0aGUgb3RoZXIgaXMg dG8gc3RhcnQgdGhlIEZFIGZpcnN0IHRoZW4gdG8gY29tbWFuZCB0aGUgRkUgdG8gZG8gc29tZSBk aXNjb3ZlcnksIHdoaWNoIHNob3VsZA0KYmUgcGVyZm9ybWVkIGFmdGVyIHByZS1hc3NvY2lhdGlv bmcgcGhhc2UuIA0KDQpJdCBpcyB0cnVlIHRoYXQgdG8gbGV0IEZFIHRvIGF1dG8tZGlzY292ZXIg dGhlIGNvbm5lY3Rpb24gaXMgYSB0b3VnaCB0YXNrIGZvciBGRSwgYnV0IEkgdGhpbmsgdGhhdCBp cyB0aGUgbW9zdCB3ZSBjYW4gZG8uIA0KTWF5YmUgbWFudWFsIHdheXMgYXJlIHN0aWxsIGltcG9y dGFudCBjaG9pY2VzIGluIG1hbnkgY2FzZXMgdG8gZG8gdGhpcy4gDQoNCkkgYWxzbyB0aGluayBh IHN5c3RlbSBjb21wb3NlZCBvZiBGRXMgYW5kIGNvbm5lY3RlZCB2aWEgYSBiYWNrcGxhbmUgaXMg aW4gZmFjdCBhIHB1cmUgZGlzdHJpYnV0ZWQgc3lzdGVtLCB3aXRoIG5vIG1hc3Rlcg0KIGluIGl0 LCB3aGljaCBpcyBkaWZmZXJlbnQgZnJvbSBjdXJyZW50IGNlbnRyYWxpemVkIGJhY2twbGFuZSBz eXN0ZW0sIHRoZXJlZm9yZSwgdG8gZGVzaWduIHNvbWUgTDIgIG9yIGV2ZW4gTDEgcHJvdG9jb2wg DQp0byBzdXBwb3J0IEZFIGNvbm5lY3Rpb24gYXV0byBkaXNjb3ZlcnkgaXMgc3RpbGwgcG9zc2li bGUuIA0KDQpJIGFncmVlIHdpdGggQWxleCB0aGF0IGFsbCBGRXMgYXJlIGJldHRlciB0byBtYWlu dGFpbiBhIGdsb2JhbCBGRSB0b3BvbG9neSBpbmZvIGFzIHdlbGwgYXMgQ0UgbWFpbnRhaW4gaXQu IA0KDQpCZXN0IHJlZ2FyZHMsDQpXZWltaW5nDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KRnJvbTogIkpvZWwgTS4gSGFscGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NClRvOiA8 Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NPg0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDE2 LCAyMDAzIDEwOjEwIFBNDQpTdWJqZWN0OiBSZXF1aXJlbWVudHMNCg0KDQo+IEluIGNvbnZlcnNh dGlvbnMgYWJvdXQgb25lIG9mIHRoZSBwcm90b2NvbHMgdGhhdCBoYXMgYmVlbiBwcm9wb3NlZCwg YW4NCj4gZWxlbWVudCBvZiB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IHdhcyBwb2ludGVkIG91 dCB0byBtZToNCj4gDQo+ICAgICAxMCkgSW4gYSBGb3JDRVMgTkUsIHRoZSBGRXMgTVVTVCBiZSBh YmxlIHRvIHByb3ZpZGUgdGhlaXIgdG9wb2xvZ3kNCj4gICAgIGluZm9ybWF0aW9uICh0b3BvbG9n eSBieSB3aGljaCB0aGUgRkVzIGluIHRoZSBORSBhcmUgY29ubmVjdGVkKSB0bw0KPiAgICAgdGhl IENFKHMpLg0KPiANCj4gSSBjb25zaWRlciB0aGlzIGEgc2VyaW91c2x5IGJyb2tlbiByZXF1aXJl bWVudC4gIENhcmRzIGhhdmUgbWluaW1hbCAoaWYNCj4gYW55KSB3YXkgdG8ga25vdyB3aGF0IHRo ZXkgYXJlIHBsdWdnZWQgaW50by4gIEV2ZW4gaWYgYSB0cnVlIGJhY2twbGFuZSAoYXMNCj4gb3Bw b3NlZCB0byBldGhlcm5ldCBzd2l0Y2hpbmcpIGlzIHVzZWQsIHRoZSBGRXMgZG8gbm90IGdlbmVy YWxseSBoYXZlIGFueQ0KPiBzZW5zaWJsZSB3YXkgdG8ga25vdyB3aGF0IGlzIHJlYWNoYWJsZSBv dmVyIHRoZSBiYWNrcGxhbmUuDQo+IA0KPiBJbiBmYWN0LCBJIHdvdWxkIGNvbnNpZGVyIHRoYXQg dGhpcyBzaG91bGQgYmUgYXJjaHRpZWN0dXJhbGx5IG91dCBvZg0KPiBzY29wZS4gIFVuZGVyc3Rh bmRpbmcgLyBkaXNjb3ZlcmluZyB3aGF0IHRoZSBsaW5rcyBiZXR3ZWVuIEZFcyBpbnRlcmNvbm5l Y3QNCj4gaXMgYSBDRSB0YXNrLCBub3QgYW4gRkUgdGFzay4NCj4gDQo+IEl0IG1heSBiZSB0b28g bGF0ZSB0byByZW1vdmUgdGhpcyBmcm9tIHRoZSBkb2N1bWVudC4NCj4gSG93ZXZlciwgYXMgYSBt YW5kYXRvcnkgcmVxdWlyZW1lbnQgb24gRkVzIGl0IGlzIGEgc2VyaW91cyBtaXN0YWtlLg0KPiAN Cj4gDQo+IEkgdmVyeSBtdWNoIGFwb2xvZ2l6ZSBmb3Igbm90IGhhdmluZyBub3RpY2VkIGFuZCBy YWlzZWQgdGhpcyBpc3N1ZSBlYXJsaWVyLg0KPiANCj4gSXQgaXMgcG9zc2libGUgdGhhdCBzb21l dGhpbmcgb3RoZXIgdGhhbiB3aGF0IEkgYW0gcmVhZGluZyBpcyBtZWFudCBieSB0aGlzDQo+IHJl cXVpcmVtZW50LiAgSWYgc28sIGl0IG5lZWRzIHRvIGJlIHN0YXRlZCB2ZXJ5IGRpZmZlcmVudGx5 Lg0KPiANCj4gWW91cnMsDQo+IEpvZWwgTS4gSGFscGVybg0KPiA= From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 17 01:13:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29488 for ; Wed, 17 Sep 2003 01:13:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zUd0-0000gs-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 01:13:22 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zUcz-0000gn-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 01:13:21 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00B9BD62@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 1:13:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55142310 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 01:12:40 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 01:12:40 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8H5AIG00367 for ; Wed, 17 Sep 2003 05:10:20 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8H57KC23931 for ; Wed, 17 Sep 2003 05:07:21 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003091622123731493 for ; Tue, 16 Sep 2003 22:12:37 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Sep 2003 22:12:38 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Protocol Selection Process Discussion Thread-Index: AcN8X1HbBtWr8sxlQBiu8p278vRdBwAeK8Jw X-OriginalArrivalTime: 17 Sep 2003 05:12:38.0262 (UTC) FILETIME=[4FF42160:01C37CDA] Approved-By: "Yang, Lily L" Message-ID: Date: Tue, 16 Sep 2003 22:12:37 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Protocol Selection Process Discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I don't think we need to see separate draft as to how each protocol = meets requirements -- instead, each protocol should have one section = near the end addressing directly and concisely as how all the = requirements are met.=20 I also believe that meeting requirements might not be the only factor to = consider in this process -- because I am sure the protocol designers = must have worked hard to ensure that their protocol does meet the = requirements! So if all solutions meet our requirements, great, but what = do we do? There might be other factors outside of the requirements = people care about, like what Alex suggested below. Other things like = implementation experience (running code) also help. Personally, I would rather not see ourselves going to the committee = approach if we can avoid it -- it also sounds too procedure-oriented and = behind-the-door for me.=20 Lily -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu Sent: Tuesday, September 16, 2003 7:32 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Protocol Selection Process Discussion Hello Avri, I think this is a workable plan. The draft as to how each protocol = meets requirements will certainly help. Other than how requirements are met, = are there any other set of criteria (tangible and intangible) that the selection process will be based on? I am also thinking of simplicity (complexity), robustness, agility (potential processing speed), flexibility,..) Regards, Alex. avri wrote: > Hi, > > While I agree that committees are a second choice, sometimes they are > necessary. As for not finding unbiased people, I disagree. I expect > that there are folks around who can look at these objectively. There > are quite a number of knowledgeable participants on this list who do > not seem to have any of the bones to pick regarding the protocol > choice. I would trust the chairs and ADs to find a selection of such > folks if the need arises. And the proponents of the protocols would = be > able to recognize whether this was a truly unbiased group. So, if we > get to the point of needing a committee, I expect one could be > assembled. > > In terms of the public discussions I will be especially interested > hearing in the opinions of people already working on, and = implementing, > solutions for ForCES type scenarios. I will also be interested in > seeing an analysis done by hardware savvy people of issues relating to > the degree of ease or difficulty they would have with each of the the = 3 > proposals in hardware. > > A question: Is the decision going to be an all or nothing decision = for > one protocol? Having read all three proposals, I am at the point of > seeing advantages to all three and weakness is all (not ready to write > it up, just hand waving at the moment). While the three protocols = have > different approaches, and thus I see the group as having to pick one > approach, I am hoping that the best elements of each can be worked = into > the protocol that makes it on to the standards track. > > a. > > On m=E5ndag, sep 15, 2003, at 23:00 Asia/Seoul, Jamal Hadi Salim = wrote: > > > No committees please. The mailing list is pretty much dead other > > than from people who believe certain things so i am not sure where = you > > will unbiased experts - if you can it will help incase of deadlocks. > > Posting to the mailing list will get the usual suspects responding > > anyways. > > I think the requirements draft should be applied. We shouldnt stop > > some protocol doing a lot of of slicing and dicing but that should = get > > no bonus in the evaluation. > > > > cheers, > > jamal > > > > > > On Mon, 2003-08-25 at 11:49, Putzolu, David wrote: From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 17 08:17:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08067 for ; Wed, 17 Sep 2003 08:17:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zbFy-0004xw-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 08:18:02 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zbFx-0004xq-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 08:18:01 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00B9E906@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 8:18:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55179964 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 08:17:59 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 08:17:59 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5409872; Wed, 17 Sep 2003 08:17:58 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> Date: Wed, 17 Sep 2003 08:17:30 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <004801c37cd4$138e9c10$3d19fea9@wwm1> Precedence: list The more I think about this, the less I think that FE topology is ever a natural FE function. It may be an LFB function. that is, 1) one could imagine that some of the topology discovery protocols are suitable for running on an FE 2) If so, the enabling and activation of such a function would be up to the CE 3) The control of the processing of such a function, and the fetching of the results, would use the normal forces protocol for (optionally) creating, setting, and querying an LFB. 4) Thus, in that siutation, there is no FORCES protocol requirement to be met. It has been suggested to me that in some situations FEs would be configured with their adjacency topology. I had initially agreed that as a corner case that could happen. The more I think about it, the less I like it. That kind of configuration is very error prone. If one is using a backplane with slots, or an ethernet switch, or ... then when one adds a component to the system, all the other components must be reconfigured!! This is actually an invitation to non-functional solutions. The requirement seems to be based on a view that it is somehow natural for an FE to know its connectivity topology. In reality, cards have a great deal of trouble knowing what is reachable over each of their ports. They rely on applications (routing protocols, neighbor discovery protocols, reachabbility discovery protocols) to find this out. Well such protocols MAY be delegated to the FE by the CE, if the FE happens to have such support, that is an LFB not a FORCES protocol requirement. And, given the range of protocols and range of maturity for those protocols, I would not want to mandate including such an LFB in the first release of the FORCES LFB library. And no, such an LFB does not meet the requirement as written, since the requirement is a protocol requirement. Yours, Joel M. Halpern At 12:27 PM 9/17/2003 +0800, Weiming Wang wrote: >Hi Joel, > >I was having the same feeling as yours regarding who should manage the FE >connection, >when I compared ForCES architecture with current popular backplane based >machine box, >which support PnP function. I thought that FE might not be able to perform >PnP by itself, instead >it should rely on CE to do this. > >But later I changed the mind, I found in ForCES, CE is even more away from >performing >this. CE has the power to find FEs connected with it but has little power >to discover how FEs are >interconnected with other FEs. Therefore, if we rely on CE to discover >interconnections of FEs, only two ways are applicable, >one is manually to set it on CE, the other is to start the FE first then >to command the FE to do some discovery, which should >be performed after pre-associationg phase. > >It is true that to let FE to auto-discover the connection is a tough task >for FE, but I think that is the most we can do. >Maybe manual ways are still important choices in many cases to do this. > >I also think a system composed of FEs and connected via a backplane is in >fact a pure distributed system, with no master > in it, which is different from current centralized backplane system, > therefore, to design some L2 or even L1 protocol >to support FE connection auto discovery is still possible. > >I agree with Alex that all FEs are better to maintain a global FE topology >info as well as CE maintain it. > >Best regards, >Weiming >----- Original Message ----- >From: "Joel M. Halpern" >To: >Sent: Tuesday, September 16, 2003 10:10 PM >Subject: Requirements > > > > In conversations about one of the protocols that has been proposed, an > > element of the requirements document was pointed out to me: > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > information (topology by which the FEs in the NE are connected) to > > the CE(s). > > > > I consider this a seriously broken requirement. Cards have minimal (if > > any) way to know what they are plugged into. Even if a true backplane (as > > opposed to ethernet switching) is used, the FEs do not generally have any > > sensible way to know what is reachable over the backplane. > > > > In fact, I would consider that this should be archtiecturally out of > > scope. Understanding / discovering what the links between FEs interconnect > > is a CE task, not an FE task. > > > > It may be too late to remove this from the document. > > However, as a mandatory requirement on FEs it is a serious mistake. > > > > > > I very much apologize for not having noticed and raised this issue earlier. > > > > It is possible that something other than what I am reading is meant by this > > requirement. If so, it needs to be stated very differently. > > > > Yours, > > Joel M. Halpern > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 17 11:53:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18467 for ; Wed, 17 Sep 2003 11:53:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zecq-0000N7-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 11:53:52 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zecp-0000N3-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 11:53:51 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00B9F29D@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 11:53:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55194397 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 11:53:49 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 11:53:49 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003091708590922:13001 ; Wed, 17 Sep 2003 08:59:09 -0700 References: <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/17/2003 08:59:09 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/17/2003 08:59:11 AM, Serialize complete at 09/17/2003 08:59:11 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1063814026.1029.25.camel@jzny.localdomain> Date: Wed, 17 Sep 2003 11:53:46 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2003-09-17 at 08:17, Joel M. Halpern wrote: > The more I think about this, the less I think that FE topology is ever a > natural FE function. > It may be an LFB function. that is, > 1) one could imagine that some of the topology discovery protocols are > suitable for running on an FE > 2) If so, the enabling and activation of such a function would be up to the CE > 3) The control of the processing of such a function, and the fetching of > the results, would use the normal forces protocol for (optionally) > creating, setting, and querying an LFB. > 4) Thus, in that siutation, there is no FORCES protocol requirement to be met. > I think your premise #1) is the problem. An example would be useful: Imagine two line cards on a single chasis, an incoming packet could either be either switched/routed localy or across the backplane to the second line card. There has to be knowledge where that second card is. You could be simplistic and make that a basic L2 functionality or intelligent and actually teach the line card how/where to send. I am using L3 as an example but such knowledge would be useful for any LFB. > It has been suggested to me that in some situations FEs would be configured > with their adjacency topology. Calling it an adjacency topology is probably a little overkill. Refer to the example above. > I had initially agreed that as a corner > case that could happen. The more I think about it, the less I like > it. That kind of configuration is very error prone. If one is using a > backplane with slots, or an ethernet switch, or ... then when one adds a > component to the system, all the other components must be > reconfigured!! The only time i see a reconfig happening is when new line cards are plugged/removed or when links go down or up. The later may not be necessary. If these events are gonna be happening all the time, then the overall system may certainly be overloaded. > This is actually an invitation to non-functional solutions. > You may have a valid point in that there maybe line cards that may not be able to use that topology intelligence. Maybe we should add capability bits so that FE can tell the CEs what they can do. Note as pointed earlier, the CEs can teach the FEs about this topology. You seem to be saying thiongs will be non-functional because you disagree with any such knowledge to be known by the FE. For this i will have to agree with the two other people who disagreed/responded to you. Alex, note i agreed with you - theres hope for the world ;-> > The requirement seems to be based on a view that it is somehow natural for > an FE to know its connectivity topology. In reality, cards have a great > deal of trouble knowing what is reachable over each of their ports. They > rely on applications (routing protocols, neighbor discovery protocols, > reachabbility discovery protocols) to find this out. Well such protocols > MAY be delegated to the FE by the CE, if the FE happens to have such > support, that is an LFB not a FORCES protocol requirement. And, given the > range of protocols and range of maturity for those protocols, I would not > want to mandate including such an LFB in the first release of the FORCES > LFB library. > Again this is based on the premise #1 that you made which is false. CEs can teach FEs about the topology if they are unable to discover it. cheers, jamal > And no, such an LFB does not meet the requirement as written, since the > requirement is a protocol requirement. > > Yours, > Joel M. Halpern > > At 12:27 PM 9/17/2003 +0800, Weiming Wang wrote: > >Hi Joel, > > > >I was having the same feeling as yours regarding who should manage the FE > >connection, > >when I compared ForCES architecture with current popular backplane based > >machine box, > >which support PnP function. I thought that FE might not be able to perform > >PnP by itself, instead > >it should rely on CE to do this. > > > >But later I changed the mind, I found in ForCES, CE is even more away from > >performing > >this. CE has the power to find FEs connected with it but has little power > >to discover how FEs are > >interconnected with other FEs. Therefore, if we rely on CE to discover > >interconnections of FEs, only two ways are applicable, > >one is manually to set it on CE, the other is to start the FE first then > >to command the FE to do some discovery, which should > >be performed after pre-associationg phase. > > > >It is true that to let FE to auto-discover the connection is a tough task > >for FE, but I think that is the most we can do. > >Maybe manual ways are still important choices in many cases to do this. > > > >I also think a system composed of FEs and connected via a backplane is in > >fact a pure distributed system, with no master > > in it, which is different from current centralized backplane system, > > therefore, to design some L2 or even L1 protocol > >to support FE connection auto discovery is still possible. > > > >I agree with Alex that all FEs are better to maintain a global FE topology > >info as well as CE maintain it. > > > >Best regards, > >Weiming > >----- Original Message ----- > >From: "Joel M. Halpern" > >To: > >Sent: Tuesday, September 16, 2003 10:10 PM > >Subject: Requirements > > > > > > > In conversations about one of the protocols that has been proposed, an > > > element of the requirements document was pointed out to me: > > > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > > information (topology by which the FEs in the NE are connected) to > > > the CE(s). > > > > > > I consider this a seriously broken requirement. Cards have minimal (if > > > any) way to know what they are plugged into. Even if a true backplane (as > > > opposed to ethernet switching) is used, the FEs do not generally have any > > > sensible way to know what is reachable over the backplane. > > > > > > In fact, I would consider that this should be archtiecturally out of > > > scope. Understanding / discovering what the links between FEs interconnect > > > is a CE task, not an FE task. > > > > > > It may be too late to remove this from the document. > > > However, as a mandatory requirement on FEs it is a serious mistake. > > > > > > > > > I very much apologize for not having noticed and raised this issue earlier. > > > > > > It is possible that something other than what I am reading is meant by this > > > requirement. If so, it needs to be stated very differently. > > > > > > Yours, > > > Joel M. Halpern > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 17 13:16:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20615 for ; Wed, 17 Sep 2003 13:16:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zfuj-0001BR-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 13:16:25 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 19zfuj-0001BO-00 for forces-archive@IETF.ORG; Wed, 17 Sep 2003 13:16:25 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00B9F974@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 13:16:24 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55201334 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 13:15:03 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 13:15:03 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5410754 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 13:15:03 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> Date: Wed, 17 Sep 2003 13:14:16 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1063814026.1029.25.camel@jzny.localdomain> Precedence: list I presume I am misunderstanding something in your example. The requirement is about inter-FE topology knowledge being delivered by FEs. As such, to apply it to your example I must presme that the two line cards are two FEs. (At which point the fact that they are in one chassis is almost irrelevant.) I do not see how / why either line card would know, a priori, anything about the other line card. I do not see that the line cards can or should make the kind of decision you refer to without the CE involvement. It is the CEs job to set up the processing of packets on the FE. The CE needs to determine the topology, using any means at its disposal. Such means include configuration, discovery protocols, and maybe other means. I do not see why in the example you give there is any knowledge likely to reside in each FE about the topology which connects it to other FEs. Now, if you are describing a case where the chassis in question is considered a single, two-port FE then we are talking about the capabilities of an FE and the topology of the LFBs within the FE. The knowledge that a FE has two ports, and that an FE can accept a packet from one port and send it out another port is indeed part of the FE knowledge, and should (and will be) represented be the intra-FE information in FORCES. The requirement is about topology between FEs. That is why I object to it. Yours, Joel M. Halpern At 11:53 AM 9/17/2003 -0400, you wrote: >On Wed, 2003-09-17 at 08:17, Joel M. Halpern wrote: > > The more I think about this, the less I think that FE topology is ever a > > natural FE function. > > It may be an LFB function. that is, > > 1) one could imagine that some of the topology discovery protocols are > > suitable for running on an FE > > 2) If so, the enabling and activation of such a function would be up to > the CE > > 3) The control of the processing of such a function, and the fetching of > > the results, would use the normal forces protocol for (optionally) > > creating, setting, and querying an LFB. > > 4) Thus, in that siutation, there is no FORCES protocol requirement to > be met. > > > >I think your premise #1) is the problem. An example would be useful: >Imagine two line cards on a single chasis, an incoming packet could >either be either switched/routed localy or across the backplane to the >second line card. There has to be knowledge where that second card is. >You could be simplistic and make that a basic L2 functionality or >intelligent and actually teach the line card how/where to send. >I am using L3 as an example but such knowledge would be useful for any >LFB. From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 18 11:10:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16863 for ; Thu, 18 Sep 2003 11:10:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A00Qk-0007Hx-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 11:10:50 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A00Qj-0007He-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 11:10:50 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00BA900E@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 11:10:46 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55324185 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 11:10:44 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 11:10:44 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003091808163239:222 ; Thu, 18 Sep 2003 08:16:32 -0700 References: <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/18/2003 08:16:32 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/18/2003 08:16:34 AM, Serialize complete at 09/18/2003 08:16:34 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1063897842.1031.15.camel@jzny.localdomain> Date: Thu, 18 Sep 2003 11:10:42 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2003-09-17 at 13:14, Joel M. Halpern wrote: > I presume I am misunderstanding something in your example. > The requirement is about inter-FE topology knowledge being delivered by FEs. > As such, to apply it to your example I must presme that the two line cards > are two FEs. (At which point the fact that they are in one chassis is > almost irrelevant.) nod. > I do not see how / why either line card would know, a priori, anything > about the other line card. They dont. > I do not see that the line cards can or should make the kind of decision > you refer to without the CE involvement. > > It is the CEs job to set up the > processing of packets on the FE. The CE needs to determine the topology, > using any means at its disposal. Such means include configuration, > discovery protocols, and maybe other means. nod again. > I do not see why in the example you give there is any knowledge likely to > reside in each FE about the topology which connects it to other FEs. The knowledge would reside in the CE. The CE teaches an FE about other FE "topologies". There are other ways where the FE may get involved, but no need to go into them. > Now, if you are describing a case where the chassis in question is > considered a single, two-port FE then we are talking about the capabilities > of an FE and the topology of the LFBs within the FE. The knowledge that a > FE has two ports, and that an FE can accept a packet from one port and send > it out another port is indeed part of the FE knowledge, and should (and > will be) represented be the intra-FE information in FORCES. > The requirement is about topology between FEs. That is why I object to it. Ok, now i see why we are not syncing.... I think maybe the confusion (at least on my part) is what "topology" means in this context. In the previous email i refered to what you described as topology was overkill. I see "topology" as what you describe as "intra-FE" information. I have a feeling this may also be the impression of other people who posted their opinions earlier. At least i hope thats what they meant ;-> If thats the case we should clarify the text with "intra-FE" context. If thats not what was meant ( i dont remember the history behind this requirement - I think Todd added this) then it is a showstopper. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 18 11:18:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17676 for ; Thu, 18 Sep 2003 11:18:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A00YB-0007XX-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 11:18:31 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A00YA-0007XT-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 11:18:31 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00BA913A@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 11:18:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55324587 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 11:18:22 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 11:18:21 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5413428 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 11:18:22 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030918111645.0216bfd0@mail.stevecrocker.com> Date: Thu, 18 Sep 2003 11:17:57 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1063897842.1031.15.camel@jzny.localdomain> Precedence: list The requirements document in requirement 10 is clearly discussing inter-FE connectivity / topology. That is why I object to it. Intra-FE topology (ie LFB topology) is clearly within scope and something that must be communicated (and in some cases manipulated) by the protocol. Yours, Joel M. Halpern At 11:10 AM 9/18/2003 -0400, you wrote: >Ok, now i see why we are not syncing.... >I think maybe the confusion (at least on my part) is what "topology" >means in this context. In the previous email i refered to what you >described as topology was overkill. I see "topology" as what you >describe as "intra-FE" information. I have a feeling this may also be >the impression of other people who posted their opinions earlier. At >least i hope thats what they meant ;-> If thats the case we should >clarify the text with "intra-FE" context. If thats not what was meant ( >i dont remember the history behind this requirement - I think Todd added >this) then it is a showstopper. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 18 13:42:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25281 for ; Thu, 18 Sep 2003 13:42:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A02nv-0006kB-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 13:42:55 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A02nu-0006k5-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 13:42:54 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00BAA72B@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 13:42:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55346219 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 13:42:32 -0400 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 13:42:32 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8IHgWwA018201 for ; Thu, 18 Sep 2003 12:42:32 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030918111645.0216bfd0@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3F69EE85.1C4D01E6@alcatel.com> Date: Thu, 18 Sep 2003 12:42:29 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Joel, I am trying to understand the reason for your objection to inter-FE topology. Is it that this information is not useful, or is it that it is kept in the wrong place? Inter-FE topology in an NE is certainly useful. It lets us configure FEs that cooperate in an NE to solve a particular problem by bringing more processing power to bear on that problem. Such topology can be dynamically configured according to the problem at hand or service to be provided. CE can configure the topology, and hence is aware of it. A scenario that may occur is the CE going out of service momentarily. CE should be able to query the FEs for this topology information when it comes back in service. Regards, Alex. "Joel M. Halpern" wrote: > The requirements document in requirement 10 is clearly discussing inter-FE > connectivity / topology. That is why I object to it. > Intra-FE topology (ie LFB topology) is clearly within scope and something > that must be communicated (and in some cases manipulated) by the protocol. > Yours, > Joel M. Halpern > > At 11:10 AM 9/18/2003 -0400, you wrote: > > >Ok, now i see why we are not syncing.... > >I think maybe the confusion (at least on my part) is what "topology" > >means in this context. In the previous email i refered to what you > >described as topology was overkill. I see "topology" as what you > >describe as "intra-FE" information. I have a feeling this may also be > >the impression of other people who posted their opinions earlier. At > >least i hope thats what they meant ;-> If thats the case we should > >clarify the text with "intra-FE" context. If thats not what was meant ( > >i dont remember the history behind this requirement - I think Todd added > >this) then it is a showstopper. > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 19 12:30:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08245 for ; Fri, 19 Sep 2003 12:08:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A05PX-0005Ho-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 16:29:55 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A05Cn-00043i-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 16:16:45 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00BABD6B@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 16:16:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55361561 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 16:15:59 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 16:15:59 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5430193 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 16:15:58 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030918111645.0216bfd0@mail.stevecrocker.com> <5.1.0.14.0.20030918151134.022463b0@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030918161405.02234e08@mail.stevecrocker.com> Date: Thu, 18 Sep 2003 16:15:33 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3F6A0FBC.A45C698B@alcatel.com> Precedence: list I am not arguing that the inter-FE is not important. It is vital. Without knowledge of this topology the CE can not do its job. What I am saying is that the FE is not the component to look to for assistance in getting this knowledge. And the requirement mandates that the protocol have mechanisms for having the FE provide this information. This tends to lead to extra protocol mechanisms to solve a problem that does not even need to be addressed. Yours, Joel M. Halpern At 03:04 PM 9/18/2003 -0500, you wrote: >It is clear that the inter-FE topology influences the beahvior of the NE. >If that is the case, I think it makes sense for that topology to be queried >so as to shed light on that behavior. > >This topology or connectivity information is soft state information. It could >instruct FE-A to apply process X on packets ingressing on port M and >egress those packets on port N (onward to FE-B which in turn applies >process Z before forwarding to the next router). > >Yes, CE keeps this configuration info for its records. But you have to provide >a way for this information to be recovered just in case CE's record of that >information is lost. I think this is important. > >Regards, >Alex. From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 19 12:32:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08357 for ; Fri, 19 Sep 2003 12:08:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A057f-0003cv-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 16:11:27 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A050v-0002rr-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 16:04:29 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00BABD02@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 16:04:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55360079 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 16:04:21 -0400 Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 16:04:16 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8IK4FLX001990 for ; Thu, 18 Sep 2003 15:04:15 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030918111645.0216bfd0@mail.stevecrocker.com> <5.1.0.14.0.20030918151134.022463b0@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3F6A0FBC.A45C698B@alcatel.com> Date: Thu, 18 Sep 2003 15:04:12 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit It is clear that the inter-FE topology influences the beahvior of the NE. If that is the case, I think it makes sense for that topology to be queried so as to shed light on that behavior. This topology or connectivity information is soft state information. It could instruct FE-A to apply process X on packets ingressing on port M and egress those packets on port N (onward to FE-B which in turn applies process Z before forwarding to the next router). Yes, CE keeps this configuration info for its records. But you have to provide a way for this information to be recovered just in case CE's record of that information is lost. I think this is important. Regards, Alex. "Joel M. Halpern" wrote: > There are multiple reasons for my objection. > > I start from the view that this information can almost never be accurately > known by the FE. If it is statically configured, it could have been better > configured at the CE. If it is known by a protocol, that is either a > protocol the CE runs, or a protocol provided by an LFB, which should be > configured and accessed (via FORCES) by the CE, not a special separate > FORCES protocol mechanism. > > Note that information from the FE indicating that it is connected to a > backplane in a specific chassis is not topology information, and is > ptoentially useful. I don't think we need special protocol mechanisms for > that, but it is much more useful than an inter-FE topology information from > the FEs. > > Remember that we are trying to support cases where as much of the > intelligence as possible is in the CE. neighbor discovery, and even > nieghbor configuration, belongs with the intelligence. > > The CE is responsible for enabling the FEs to do their job. It is > absolutely true that the CE will need to know the inter-FE topology. But > that does not mean that there is a requirement on the FORCES protocol for > FEs to be able to provide this information. > > While it is probably true that in some corner case the FE as an entity > might have this information, it seems unreasonable to mandate additional > complexity in the FORCES protocol to cover such a corner case. > Note that with an LFB library and both FE and LFB attribute extensibility, > it is possible for the FORCES system as a solution to represent such > knowledge where it exists. However, the requirement is much more demanding > than that. > > Yours, > Joel M. Halpern > > PS: I have an image of information going from an FE to a CE saying > "I have a serial port. It is not connected to a multi-access converter, > and I think the entity on the other end is Harry." > The CE would be better off determining this itself rather than trying > to determine what reliance to place on such configured information. > > At 12:42 PM 9/18/2003 -0500, you wrote: > >Hello Joel, > > > >I am trying to understand the reason for your objection to inter-FE topology. > >Is it that this information is not useful, or is it that it is kept in the > >wrong place? > > > >Inter-FE topology in an NE is certainly useful. It lets us configure FEs that > >cooperate in an NE to solve a particular problem by bringing more processing > >power to bear on that problem. > > > >Such topology can be dynamically configured according to the problem at > >hand or service to be provided. CE can configure the topology, and hence > >is aware of it. A scenario that may occur is the CE going out of service > >momentarily. CE should be able to query the FEs for this topology information > > > >when it comes back in service. > > > >Regards, > >Alex. > > > > > >"Joel M. Halpern" wrote: > > > > > The requirements document in requirement 10 is clearly discussing inter-FE > > > connectivity / topology. That is why I object to it. > > > Intra-FE topology (ie LFB topology) is clearly within scope and something > > > that must be communicated (and in some cases manipulated) by the protocol. > > > Yours, > > > Joel M. Halpern > > > > > > At 11:10 AM 9/18/2003 -0400, you wrote: > > > > > > >Ok, now i see why we are not syncing.... > > > >I think maybe the confusion (at least on my part) is what "topology" > > > >means in this context. In the previous email i refered to what you > > > >described as topology was overkill. I see "topology" as what you > > > >describe as "intra-FE" information. I have a feeling this may also be > > > >the impression of other people who posted their opinions earlier. At > > > >least i hope thats what they meant ;-> If thats the case we should > > > >clarify the text with "intra-FE" context. If thats not what was meant ( > > > >i dont remember the history behind this requirement - I think Todd added > > > >this) then it is a showstopper. > > > > > > > >cheers, > > > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 19 12:32:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07136 for ; Fri, 19 Sep 2003 12:06:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0AJZ-0001sT-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 21:44:05 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0A1q-0007Gq-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 21:25:46 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00BAE36A@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 21:25:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55391017 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 21:25:39 -0400 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 21:25:39 -0400 Received: from wwm2([218.108.152.67]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jmd3f6a785e; Fri, 19 Sep 2003 09:24:35 +0800 References: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030918111645.0216bfd0@mail.stevecrocker.com> <5.1.0.14.0.20030918151134.022463b0@mail.stevecrocker.com> <5.1.0.14.0.20030918161405.02234e08@mail.stevecrocker.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Approved-By: Weiming Wang Message-ID: <00a101c37e4c$0356f2b0$020aa8c0@wwm2> Date: Fri, 19 Sep 2003 09:19:02 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Requirements Comments: cc: wmwang@mail.hzic.edu.cn To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SSAgZ2V0IGEgbGl0dGxlIG1vcmUgdW5kZXJzdGFuZGluZyB3aGF0IEpvZWwgbWVhbnMuIE1heWJl IHRoZSBmb2N1cyBwb2ludCB3aXRoIHRoZSByZXF1aXJlbWVudA0KDQoxMCkgSW4gYSBGb3JDRVMg TkUsIHRoZSBGRXMgTVVTVCBiZSBhYmxlIHRvIHByb3ZpZGUgdGhlaXIgdG9wb2xvZ3kNCiAgICBp bmZvcm1hdGlvbiAodG9wb2xvZ3kgYnkgd2hpY2ggdGhlIEZFcyBpbiB0aGUgTkUgYXJlIGNvbm5l Y3RlZCkgdG8NCiAgICB0aGUgQ0UocykuDQoNCmlzIHRoZSB3b3JkICJNVVNUIi4gSWYgaXQgaXMg YSB3ZWFrZXIgd29yZCwgdGhpbmdzIG1heWJlIGJldHRlciwgc2luY2UgaW4gbWFueSBjYXNlcywg bmVpdGhlciANCkNFIG5vciBGRSBjYW4gYXV0b21hdGljYWxseSBkaXNjb3ZlciB0aGUgKGludGVy LSlGRQ0KdG9wb2xvZ3ksIHRoZXJlZm9yZSBtYW51YWwgY29uZmlndXJhdGlvbiBpcyB0aGUgbGFz dCBjaG9pY2UuIEluIHRoZXNlIGNhc2VzLCBpdCBpcyBib3JpbmcgdG8gYXNrIHNvIG1hbnkgIGlu ZGl2aWR1YWwgDQpGRXMgdG8gcHJvdmlkZSB0aGVpciB0b3BvbG9neSBpbmZvcm1hdGlvbiwgd2l0 aCB0aGUgaW5mb3JtYXRpb24gaXMgaW4gZmFjdCBhbHNvIG1hbnVhbGx5IGtleWVkIGluIGluIGlu ZGl2aWR1YWwgRkVzIG9yDQpGRSBtYW5hZ2Vycy4gSW5zdGVhZCwgdG8gbGV0IENFIGRvIGl0IGlz IGVhc2llci4NCg0KSWYgaXQgaXMgbm90IGEgIk1VU1QiIHJlcXVpcmVtZW50LCB0aGUgc2NlbmFy aW8gbWF5IGJlIGxpa2UgIkNFIHF1ZXJ5IEZFIGZvciB0b3BvbG9neSBpbmZvLiBJZiBGRSBjYW5u b3QgcHJvdmlkZSwgDQp0aGF0J3Mgb2ssIENFIHdpbGwgYXNrIG90aGVycyhzdWNoIGFzIENFIG1h bmFnZXIgb3IgYWRtaW5pc3RyYXRvcikgdG8gcHJvdmlkZSBpdC4gIg0KDQpBcyBhIHJlc3VsdCwg bXkgb3BpbmlvbiBpcyB0aGUgcmVxdWlyZW1lbnQgaXMgc3RpbGwgbmVjZXNzYXJ5LCBidXQgaXQg c2hvdWxkIG5vdCBiZSAiTVVTVCIgb25lLiANCg0KQmVzaWRlcywgSSdtIHRoaW5raW5nIChhbHNv IHJlZmxlY3RlZCBpbiBHUk1QIHByb3RvY29sKSBpZiBpdCBpcyBlYXNpZXIgdG8gdW5kZXJzdGFu ZCBGRSB0b3BvbG9neSBwcm9jZXNzaW5nIGJ5IA0KZGl2aWRpbmcgdGhlIHByb2Nlc3MgaW50byB0 d28gc2NvcGVzOg0KMSkgRkUgdG9wb2xvZ3kgY2FwYWJpbGl0eSBpbmZvIGNvbGxlY3Rpb247IHRo YXQgaXMgaG93IEZFcyBhcmUgcGh5c2ljYWxseSBpbnRlcmNvbm5lY3RlZC4gDQoyKSBGRSB0b3Bv bG9neSBjb25maWd1cmF0aW9uKGJ5IENFKTsgdGhhdCBpcyBob3cgQ0Ugd291bGQgbGlrZSB0byB1 c2UgdGhlIHBoeXNpY2FsIHRvcG9sb2d5LiBJdCBpcyBub3QgbmVlZGVkIHRvIGJlIHRoZSBzYW1l IGFzIHBoeXNpY2FsIA0KdG9wb2xvZ3ksIGluc3RlYWQgaXQgY2FuIGJlIGEgc3Vic2V0IG9mIHRo ZSBwaHlzaWNhbCB0b3BvbG9neS4gVGhpcyB3b3JraW5nIHRvcG9sb2d5IGNhbiBiZSAgY2hhbmdl ZCBvbiB0aGUgZmx5LCB3aXRoaW4gdGhlIHNjb3BlIG9mIHBoeXNpY2FsDQpzY29wZS4gDQoNCkFu b3RoZXIgcXVlc3Rpb24gcmFpc2VkIGJ5IEpvZWw6ICJJZiBvbmUgaXMgdXNpbmcgYSBiYWNrcGxh bmUgd2l0aCBzbG90cywgb3IgYW4gZXRoZXJuZXQgc3dpdGNoLCBvciAuLi4gdGhlbiB3aGVuIG9u ZSBhZGRzIGENCmNvbXBvbmVudCB0byB0aGUgc3lzdGVtLCBhbGwgdGhlIG90aGVyIGNvbXBvbmVu dHMgbXVzdCBiZSByZWNvbmZpZ3VyZWQhISIgIA0KSSB0aGluayB0aGlzIGlzIG5vdCBhIHByb2Js ZW0uIEl0J3MgdHJ1ZSB0aGUgdG9wb2xvZ3kgb2Ygb3RoZXIgRkVzIHdpbGwgY2hhbmdlLCBidXQg aXQncyBub3QgbmVjZXNzYXJ5IHRvIHJlY29uZmlndXJlIGl0LiANCkl0IG9ubHkgbmVlZHMgdG8g YmUgaW5mb3JtZWQgb2YgdGhpcyBjaGFuZ2UgdmlhIHNvbWUgQ0UgKGJyb2FkY2FzdCkgbWVzc2Fn ZSwgdGhlbiAgdGhlIGluZGl2aWR1YWwgRkUgY2FuIHVwZ3JhZGUgaXQuDQoNClJlZ2FyZHMsDQp3 ZWltaW5nDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0u IEhhbHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQpUbzogPEZPUkNFU0BQRUFDSC5FQVNF LkxTT0ZULkNPTT4NClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE5LCAyMDAzIDQ6MTUgQU0NClN1 YmplY3Q6IFJlOiBSZXF1aXJlbWVudHMNCg0KDQo+IEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGUg aW50ZXItRkUgaXMgbm90IGltcG9ydGFudC4gIEl0IGlzIHZpdGFsLiAgV2l0aG91dA0KPiBrbm93 bGVkZ2Ugb2YgdGhpcyB0b3BvbG9neSB0aGUgQ0UgY2FuIG5vdCBkbyBpdHMgam9iLg0KPiANCj4g V2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IHRoZSBGRSBpcyBub3QgdGhlIGNvbXBvbmVudCB0byBs b29rIHRvIGZvcg0KPiBhc3Npc3RhbmNlIGluIGdldHRpbmcgdGhpcyBrbm93bGVkZ2UuICBBbmQg dGhlIHJlcXVpcmVtZW50IG1hbmRhdGVzIHRoYXQNCj4gdGhlIHByb3RvY29sIGhhdmUgbWVjaGFu aXNtcyBmb3IgaGF2aW5nIHRoZSBGRSBwcm92aWRlIHRoaXMgaW5mb3JtYXRpb24uDQo+IFRoaXMg dGVuZHMgdG8gbGVhZCB0byBleHRyYSBwcm90b2NvbCBtZWNoYW5pc21zIHRvIHNvbHZlIGEgcHJv YmxlbSB0aGF0DQo+IGRvZXMgbm90IGV2ZW4gbmVlZCB0byBiZSBhZGRyZXNzZWQuDQo+IA0KPiBZ b3VycywNCj4gSm9lbCBNLiBIYWxwZXJuDQo+IA0KPiBBdCAwMzowNCBQTSA5LzE4LzIwMDMgLTA1 MDAsIHlvdSB3cm90ZToNCj4gPkl0IGlzIGNsZWFyIHRoYXQgdGhlIGludGVyLUZFIHRvcG9sb2d5 IGluZmx1ZW5jZXMgdGhlIGJlYWh2aW9yIG9mIHRoZSBORS4NCj4gPklmIHRoYXQgaXMgdGhlIGNh c2UsIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgZm9yIHRoYXQgdG9wb2xvZ3kgdG8gYmUgcXVlcmll ZA0KPiA+c28gYXMgdG8gc2hlZCBsaWdodCBvbiB0aGF0IGJlaGF2aW9yLg0KPiA+DQo+ID5UaGlz IHRvcG9sb2d5IG9yIGNvbm5lY3Rpdml0eSBpbmZvcm1hdGlvbiBpcyBzb2Z0IHN0YXRlIGluZm9y bWF0aW9uLiBJdCBjb3VsZA0KPiA+aW5zdHJ1Y3QgRkUtQSB0byBhcHBseSBwcm9jZXNzIFggb24g cGFja2V0cyBpbmdyZXNzaW5nIG9uICBwb3J0IE0gYW5kDQo+ID5lZ3Jlc3MgdGhvc2UgcGFja2V0 cyBvbiBwb3J0IE4gKG9ud2FyZCB0byBGRS1CIHdoaWNoIGluIHR1cm4gYXBwbGllcw0KPiA+cHJv Y2VzcyBaIGJlZm9yZSBmb3J3YXJkaW5nIHRvIHRoZSBuZXh0IHJvdXRlcikuDQo+ID4NCj4gPlll cywgQ0Uga2VlcHMgdGhpcyBjb25maWd1cmF0aW9uIGluZm8gZm9yIGl0cyByZWNvcmRzLiBCdXQg eW91IGhhdmUgdG8gcHJvdmlkZQ0KPiA+YSB3YXkgZm9yIHRoaXMgaW5mb3JtYXRpb24gdG8gYmUg cmVjb3ZlcmVkIGp1c3QgaW4gY2FzZSBDRSdzIHJlY29yZCBvZiB0aGF0DQo+ID5pbmZvcm1hdGlv biBpcyBsb3N0LiBJIHRoaW5rIHRoaXMgaXMgaW1wb3J0YW50Lg0KPiA+DQo+ID5SZWdhcmRzLA0K PiA+QWxleC4= From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 19 13:20:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08543 for ; Fri, 19 Sep 2003 12:08:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A04Ol-0007E6-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 15:25:03 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A04Lg-000709-00 for forces-archive@IETF.ORG; Thu, 18 Sep 2003 15:21:53 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00BABBC5@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 15:21:52 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55356378 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 15:18:53 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 15:18:53 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5430032 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 15:18:53 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030918111645.0216bfd0@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030918151134.022463b0@mail.stevecrocker.com> Date: Thu, 18 Sep 2003 15:18:27 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3F69EE85.1C4D01E6@alcatel.com> Precedence: list There are multiple reasons for my objection. I start from the view that this information can almost never be accurately known by the FE. If it is statically configured, it could have been better configured at the CE. If it is known by a protocol, that is either a protocol the CE runs, or a protocol provided by an LFB, which should be configured and accessed (via FORCES) by the CE, not a special separate FORCES protocol mechanism. Note that information from the FE indicating that it is connected to a backplane in a specific chassis is not topology information, and is ptoentially useful. I don't think we need special protocol mechanisms for that, but it is much more useful than an inter-FE topology information from the FEs. Remember that we are trying to support cases where as much of the intelligence as possible is in the CE. neighbor discovery, and even nieghbor configuration, belongs with the intelligence. The CE is responsible for enabling the FEs to do their job. It is absolutely true that the CE will need to know the inter-FE topology. But that does not mean that there is a requirement on the FORCES protocol for FEs to be able to provide this information. While it is probably true that in some corner case the FE as an entity might have this information, it seems unreasonable to mandate additional complexity in the FORCES protocol to cover such a corner case. Note that with an LFB library and both FE and LFB attribute extensibility, it is possible for the FORCES system as a solution to represent such knowledge where it exists. However, the requirement is much more demanding than that. Yours, Joel M. Halpern PS: I have an image of information going from an FE to a CE saying "I have a serial port. It is not connected to a multi-access converter, and I think the entity on the other end is Harry." The CE would be better off determining this itself rather than trying to determine what reliance to place on such configured information. At 12:42 PM 9/18/2003 -0500, you wrote: >Hello Joel, > >I am trying to understand the reason for your objection to inter-FE topology. >Is it that this information is not useful, or is it that it is kept in the >wrong place? > >Inter-FE topology in an NE is certainly useful. It lets us configure FEs that >cooperate in an NE to solve a particular problem by bringing more processing >power to bear on that problem. > >Such topology can be dynamically configured according to the problem at >hand or service to be provided. CE can configure the topology, and hence >is aware of it. A scenario that may occur is the CE going out of service >momentarily. CE should be able to query the FEs for this topology information > >when it comes back in service. > >Regards, >Alex. > > >"Joel M. Halpern" wrote: > > > The requirements document in requirement 10 is clearly discussing inter-FE > > connectivity / topology. That is why I object to it. > > Intra-FE topology (ie LFB topology) is clearly within scope and something > > that must be communicated (and in some cases manipulated) by the protocol. > > Yours, > > Joel M. Halpern > > > > At 11:10 AM 9/18/2003 -0400, you wrote: > > > > >Ok, now i see why we are not syncing.... > > >I think maybe the confusion (at least on my part) is what "topology" > > >means in this context. In the previous email i refered to what you > > >described as topology was overkill. I see "topology" as what you > > >describe as "intra-FE" information. I have a feeling this may also be > > >the impression of other people who posted their opinions earlier. At > > >least i hope thats what they meant ;-> If thats the case we should > > >clarify the text with "intra-FE" context. If thats not what was meant ( > > >i dont remember the history behind this requirement - I think Todd added > > >this) then it is a showstopper. > > > > > >cheers, > > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 19 14:23:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18482 for ; Fri, 19 Sep 2003 14:23:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Puc-0007hb-00 for forces-archive@IETF.ORG; Fri, 19 Sep 2003 14:23:22 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0PuS-0007gu-00 for forces-archive@IETF.ORG; Fri, 19 Sep 2003 14:23:12 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00BB170F@cherry.ease.lsoft.com>; Fri, 19 Sep 2003 14:21:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55457030 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 19 Sep 2003 14:16:37 -0400 Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 19 Sep 2003 14:16:32 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8JFQKLX019032 for ; Fri, 19 Sep 2003 10:26:20 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030918111645.0216bfd0@mail.stevecrocker.com> <5.1.0.14.0.20030918151134.022463b0@mail.stevecrocker.com> <5.1.0.14.0.20030918161405.02234e08@mail.stevecrocker.com> <00a101c37e4c$0356f2b0$020aa8c0@wwm2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3F6B201B.D3DAE407@alcatel.com> Date: Fri, 19 Sep 2003 10:26:19 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I read that requirement differently. Every FE object contains data which stores its connectivity information with its neighbors. Null connectivity will be valid in the case of a stand-alone FE. All the requirement says is the FE must be able to report that information when queried. It doesn't mandate any discovery mechanisms or any thing like that. Regards, Alex. Weiming Wang wrote: > I get a little more understanding what Joel means. Maybe the focus point with the requirement > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). > > is the word "MUST". If it is a weaker word, things maybe better, since in many cases, neither > CE nor FE can automatically discover the (inter-)FE > topology, therefore manual configuration is the last choice. In these cases, it is boring to ask so many individual > FEs to provide their topology information, with the information is in fact also manually keyed in in individual FEs or > FE managers. Instead, to let CE do it is easier. > > If it is not a "MUST" requirement, the scenario may be like "CE query FE for topology info. If FE cannot provide, > that's ok, CE will ask others(such as CE manager or administrator) to provide it. " > > As a result, my opinion is the requirement is still necessary, but it should not be "MUST" one. > > Besides, I'm thinking (also reflected in GRMP protocol) if it is easier to understand FE topology processing by > dividing the process into two scopes: > 1) FE topology capability info collection; that is how FEs are physically interconnected. > 2) FE topology configuration(by CE); that is how CE would like to use the physical topology. It is not needed to be the same as physical > topology, instead it can be a subset of the physical topology. This working topology can be changed on the fly, within the scope of physical > scope. > > Another question raised by Joel: "If one is using a backplane with slots, or an ethernet switch, or ... then when one adds a > component to the system, all the other components must be reconfigured!!" > I think this is not a problem. It's true the topology of other FEs will change, but it's not necessary to reconfigure it. > It only needs to be informed of this change via some CE (broadcast) message, then the individual FE can upgrade it. > > Regards, > weiming > > ----- Original Message ----- > From: "Joel M. Halpern" > To: > Sent: Friday, September 19, 2003 4:15 AM > Subject: Re: Requirements > > > I am not arguing that the inter-FE is not important. It is vital. Without > > knowledge of this topology the CE can not do its job. > > > > What I am saying is that the FE is not the component to look to for > > assistance in getting this knowledge. And the requirement mandates that > > the protocol have mechanisms for having the FE provide this information. > > This tends to lead to extra protocol mechanisms to solve a problem that > > does not even need to be addressed. > > > > Yours, > > Joel M. Halpern > > > > At 03:04 PM 9/18/2003 -0500, you wrote: > > >It is clear that the inter-FE topology influences the beahvior of the NE. > > >If that is the case, I think it makes sense for that topology to be queried > > >so as to shed light on that behavior. > > > > > >This topology or connectivity information is soft state information. It could > > >instruct FE-A to apply process X on packets ingressing on port M and > > >egress those packets on port N (onward to FE-B which in turn applies > > >process Z before forwarding to the next router). > > > > > >Yes, CE keeps this configuration info for its records. But you have to provide > > >a way for this information to be recovered just in case CE's record of that > > >information is lost. I think this is important. > > > > > >Regards, > > >Alex. From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 20 04:34:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27874 for ; Sat, 20 Sep 2003 04:34:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0dCU-0001Te-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 04:34:42 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0dCJ-0001TH-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 04:34:31 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00BBAD04@cherry.ease.lsoft.com>; Sat, 20 Sep 2003 4:33:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55525692 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 04:33:46 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 20 Sep 2003 04:33:46 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8JHawf21746 for ; Fri, 19 Sep 2003 17:36:58 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8JHXwI14899 for ; Fri, 19 Sep 2003 17:33:59 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003091910391712754 for ; Fri, 19 Sep 2003 10:39:17 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 19 Sep 2003 10:39:17 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37ED4.F31E8992" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Re: Requirements Thread-Index: AcN+1PLjndkdI7kPQCaxIU9LWQSFVg== X-OriginalArrivalTime: 19 Sep 2003 17:39:17.0548 (UTC) FILETIME=[F33C2EC0:01C37ED4] Approved-By: "Deleganes, Ellen M" Message-ID: <42050DF556283A4D977B111EB7063208015A9602@orsmsx407.jf.intel.com> Date: Fri, 19 Sep 2003 10:39:17 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C37ED4.F31E8992 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with those who have stated the architecture requirement in section 5, #10 (shown below) puts an unnecessary burden on the FEs and is not required in order to perform topology discovery. I also agree that other solutions are available that do not require this functionality of the FE (e.g. the CE could perform the discovery, it might be entered manually, some other manager could do the discovery). =20 10) In a ForCES NE, the FEs MUST be able to provide their topology information (topology by which the FEs in the NE are connected) to the CE(s). =20 I suspect based on a protocol requirement #10 (shown below) that the intent was that some mechanism to report topology information from the FE to the CE must exist. However, nowhere in the document does it state that that FE functionality is optional. I believe that clarification should be added.=20 =20 10)Topology Exchange=20 The ForCES protocol MUST allow the FEs to provide their topology=20 information (topology by which the FEs in the NE are connected) to=20 the CE(s). (refer to section 5, requirement# 10) =20 One suggestion is to rewrite requirement #10 in section 5 to be similar to item 10) Topology Exchange and perhaps add the qualifier that the FEs are NOT REQUIRED to be able to provide topology information to the CEs. =20 Regards, Ellen Deleganes =20 ------_=_NextPart_001_01C37ED4.F31E8992 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with those = who have stated the architecture requirement in section 5, #10 (shown below) puts = an unnecessary burden on the FEs and is not required in order to perform topology discovery. I also agree = that other solutions are available that do not require this functionality of = the FE (e.g. the CE could perform the discovery, it might be entered manually, some = other manager could do the discovery).

 

10) In a ForCES NE, = the FEs MUST be able to provide their topology

    = information (topology by which the FEs in the NE are connected) to

    = the CE(s).

 

I suspect based on = a protocol requirement #10 (shown below) that the intent was that some = mechanism to report topology information from the FE to the CE must exist. = However, nowhere in the document does it state that that FE functionality is = optional. I believe that clarification should be added.

 

10)Topology = Exchange

   The = ForCES protocol MUST allow the FEs to provide their topology

   = information (topology by which the FEs in the NE are connected) to

   the = CE(s). (refer to section 5, requirement# 10)

 

One suggestion is = to rewrite requirement #10 in section 5 to be similar to item 10) Topology Exchange = and perhaps add the qualifier that the FEs are NOT REQUIRED to be able to provide topology information to the = CEs. 

 

Regards,

Ellen = Deleganes

 

=00 ------_=_NextPart_001_01C37ED4.F31E8992-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 20 19:22:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26439 for ; Sat, 20 Sep 2003 19:22:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0r45-0002ZG-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 19:22:57 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0r3v-0002Xz-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 19:22:47 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00BC07A0@cherry.ease.lsoft.com>; Sat, 20 Sep 2003 19:21:58 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55582757 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 19:19:24 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 20 Sep 2003 19:19:24 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5480411 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 19:19:24 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030916100505.0211d188@mail.stevecrocker.com> <5.1.0.14.0.20030917080919.021ee940@mail.stevecrocker.com> <5.1.0.14.0.20030917130910.021efba0@mail.stevecrocker.com> <5.1.0.14.0.20030918111645.0216bfd0@mail.stevecrocker.com> <5.1.0.14.0.20030918151134.022463b0@mail.stevecrocker.com> <5.1.0.14.0.20030918161405.02234e08@mail.stevecrocker.com> <00a101c37e4c$0356f2b0$020aa8c0@wwm2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030920191539.0188b640@mail.stevecrocker.com> Date: Sat, 20 Sep 2003 19:18:53 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3F6B201B.D3DAE407@alcatel.com> Precedence: list As judged by the protocols being brought forward, people are reading the requirement as mandating special protocol mechanisms for reporting this "connectivity". As this information will almost never exist, I object strongly to special mechanisms to support reporting such information. Removing the requirement will a) remove the incentive for special mechanisms b) likely cause us to recognize that attributes about such information a optional extensions, not core value. Both of these are good results. If there is anything we have learned in IETF protocol design it is that extra mechanisms for rare cases are generally a bad idea. Yours, Joel M. Halpern At 10:26 AM 9/19/2003 -0500, you wrote: >I read that requirement differently. Every FE object contains data which >stores its connectivity information with its neighbors. Null connectivity >will be valid in the case of a stand-alone FE. All the requirement says is >the FE must be able to report that information when queried. It doesn't >mandate any discovery mechanisms or any thing like that. > >Regards, >Alex. > >Weiming Wang wrote: > > > I get a little more understanding what Joel means. Maybe the focus > point with the requirement > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > information (topology by which the FEs in the NE are connected) to > > the CE(s). > > > > is the word "MUST". If it is a weaker word, things maybe better, since > in many cases, neither > > CE nor FE can automatically discover the (inter-)FE > > topology, therefore manual configuration is the last choice. In these > cases, it is boring to ask so many individual > > FEs to provide their topology information, with the information is in > fact also manually keyed in in individual FEs or > > FE managers. Instead, to let CE do it is easier. > > > > If it is not a "MUST" requirement, the scenario may be like "CE query > FE for topology info. If FE cannot provide, > > that's ok, CE will ask others(such as CE manager or administrator) to > provide it. " > > > > As a result, my opinion is the requirement is still necessary, but it > should not be "MUST" one. > > > > Besides, I'm thinking (also reflected in GRMP protocol) if it is easier > to understand FE topology processing by > > dividing the process into two scopes: > > 1) FE topology capability info collection; that is how FEs are > physically interconnected. > > 2) FE topology configuration(by CE); that is how CE would like to use > the physical topology. It is not needed to be the same as physical > > topology, instead it can be a subset of the physical topology. This > working topology can be changed on the fly, within the scope of physical > > scope. > > > > Another question raised by Joel: "If one is using a backplane with > slots, or an ethernet switch, or ... then when one adds a > > component to the system, all the other components must be reconfigured!!" > > I think this is not a problem. It's true the topology of other FEs will > change, but it's not necessary to reconfigure it. > > It only needs to be informed of this change via some CE (broadcast) > message, then the individual FE can upgrade it. > > > > Regards, > > weiming > > > > ----- Original Message ----- > > From: "Joel M. Halpern" > > To: > > Sent: Friday, September 19, 2003 4:15 AM > > Subject: Re: Requirements > > > > > I am not arguing that the inter-FE is not important. It is > vital. Without > > > knowledge of this topology the CE can not do its job. > > > > > > What I am saying is that the FE is not the component to look to for > > > assistance in getting this knowledge. And the requirement mandates that > > > the protocol have mechanisms for having the FE provide this information. > > > This tends to lead to extra protocol mechanisms to solve a problem that > > > does not even need to be addressed. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 03:04 PM 9/18/2003 -0500, you wrote: > > > >It is clear that the inter-FE topology influences the beahvior of > the NE. > > > >If that is the case, I think it makes sense for that topology to be > queried > > > >so as to shed light on that behavior. > > > > > > > >This topology or connectivity information is soft state information. > It could > > > >instruct FE-A to apply process X on packets ingressing on port M and > > > >egress those packets on port N (onward to FE-B which in turn applies > > > >process Z before forwarding to the next router). > > > > > > > >Yes, CE keeps this configuration info for its records. But you have > to provide > > > >a way for this information to be recovered just in case CE's record > of that > > > >information is lost. I think this is important. > > > > > > > >Regards, > > > >Alex. From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 20 19:34:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26965 for ; Sat, 20 Sep 2003 19:34:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0rFT-0002jU-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 19:34:43 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0rFI-0002jL-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 19:34:32 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00BC0B6B@cherry.ease.lsoft.com>; Sat, 20 Sep 2003 19:34:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55583077 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 19:31:54 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 20 Sep 2003 19:31:54 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8KNTXo28360 for ; Sat, 20 Sep 2003 23:29:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8KNQYH24197 for ; Sat, 20 Sep 2003 23:26:34 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092016315324426 for ; Sat, 20 Sep 2003 16:31:53 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 20 Sep 2003 16:31:53 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37FCF.5F799C97" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Requirements Thread-Index: AcN+1PLjndkdI7kPQCaxIU9LWQSFVgA92aDA X-OriginalArrivalTime: 20 Sep 2003 23:31:53.0217 (UTC) FILETIME=[5F68D710:01C37FCF] Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00A0A28@orsmsx410.jf.intel.com> Date: Sat, 20 Sep 2003 16:31:53 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C37FCF.5F799C97 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The intent of this requirement was not to mandate all FEs to have this information, as is suggested in section 5 # 10, but to support protocol mechanisms to obtain this information from FEs if it is available, as is stated in section 7 # 10. I agree that the text in section 5 # 10 needs to be modified to bring out the correct intent, which is stated in section 7 # 10. As for the history, this requirement has been around since version 02 of the draft back in Feb 2002. =20 Since the Requirements is already in the RFC queue, I was wondering if it is possible to make any edits at this point without causing a lot of delays. Any advise David, Patrick ?? =20 Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M Sent: Friday, September 19, 2003 10:39 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Requirements I agree with those who have stated the architecture requirement in section 5, #10 (shown below) puts an unnecessary burden on the FEs and is not required in order to perform topology discovery. I also agree that other solutions are available that do not require this functionality of the FE (e.g. the CE could perform the discovery, it might be entered manually, some other manager could do the discovery). =20 10) In a ForCES NE, the FEs MUST be able to provide their topology information (topology by which the FEs in the NE are connected) to the CE(s). =20 I suspect based on a protocol requirement #10 (shown below) that the intent was that some mechanism to report topology information from the FE to the CE must exist. However, nowhere in the document does it state that that FE functionality is optional. I believe that clarification should be added.=20 =20 10)Topology Exchange=20 The ForCES protocol MUST allow the FEs to provide their topology=20 information (topology by which the FEs in the NE are connected) to=20 the CE(s). (refer to section 5, requirement# 10) =20 One suggestion is to rewrite requirement #10 in section 5 to be similar to item 10) Topology Exchange and perhaps add the qualifier that the FEs are NOT REQUIRED to be able to provide topology information to the CEs. =20 Regards, Ellen Deleganes =20 ------_=_NextPart_001_01C37FCF.5F799C97 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
The=20 intent of this requirement was not to mandate all FEs to have this=20 information, as is suggested in section 5 # 10,
but to=20 support protocol mechanisms to obtain this information from FEs if it is = available, as is stated in section 7 # 10.
I=20 agree that the text in section 5 # 10 needs to be modified to bring out = the=20 correct intent, which is stated in section 7 # 10.
As for=20 the history, this requirement has been around since version 02 of the = draft back=20 in Feb 2002.
 
Since=20 the Requirements is already in the RFC queue, I was wondering if it is = possible=20 to make any edits at this point
without causing a lot of delays. Any advise = David,=20 Patrick ??
 
Thanks
Hormuzd
-----Original Message-----
From: = Forwarding and=20 Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On = Behalf=20 Of Deleganes, Ellen M
Sent: Friday, September 19, 2003 = 10:39=20 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: = [FORCES]=20 Requirements

I agree with = those who=20 have stated the architecture requirement in section 5, #10 (shown = below) puts=20 an unnecessary burden on the FEs and is not = required in=20 order to perform topology discovery. I also agree that other solutions = are=20 available that do not require this functionality of the FE (e.g. the = CE could=20 perform the discovery, it might be entered manually, some other = manager could=20 do the discovery).

 

10) In a ForCES = NE, the=20 FEs MUST be able to provide their topology

   =20 information (topology by which the FEs in the NE are = connected)=20 to

    the=20 CE(s).

 

I suspect based = on a=20 protocol requirement #10 (shown below) that the intent was that some = mechanism=20 to report topology information from the FE to the CE must exist. = However,=20 nowhere in the document does it state that that FE functionality is = optional.=20 I believe that clarification should be added.

 

10)Topology = Exchange=20

   The = ForCES=20 protocol MUST allow the FEs to provide = their topology=20

   = information=20 (topology by which the FEs in the NE are = connected)=20 to

   the = CE(s).=20 (refer to section 5, requirement# 10)

 

One suggestion = is to=20 rewrite requirement #10 in section 5 to be similar to item 10) = Topology=20 Exchange and perhaps add the qualifier that the FEs are NOT = REQUIRED to be=20 able to provide topology information to the CEs.  =

 

Regards,

Ellen=20 Deleganes

 

------_=_NextPart_001_01C37FCF.5F799C97-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 20 19:58:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27689 for ; Sat, 20 Sep 2003 19:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0rc5-0002zD-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 19:58:05 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0rbu-0002z8-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 19:57:54 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00BC0EEB@cherry.ease.lsoft.com>; Sat, 20 Sep 2003 19:57:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55584723 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 19:56:39 -0400 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 20 Sep 2003 19:56:39 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id h8KNv4B30480 for ; Sat, 20 Sep 2003 16:57:04 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Sat, 20 Sep 2003 16:57:04 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00A0A28@orsmsx410.jf.intel.com> Precedence: list Hormuzd, Talk to Todd - i think he was the one who added this. And i think it was meant to imply intra-FE not inter-FE topology. Either it should be clarified to be intra-FE (which i agree is LFB specific) or totaly removed. I dont think we should stop anyone from implementing it if they wish but it should not be on a protocol check list. cheers, jamal On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > The intent of this requirement was not to mandate all FEs to have this > information, as is suggested in section 5 # 10, > but to support protocol mechanisms to obtain this information from FEs > if it is available, as is stated in section 7 # 10. > I agree that the text in section 5 # 10 needs to be modified to bring > out the correct intent, which is stated in section 7 # 10. > As for the history, this requirement has been around since version 02 of > the draft back in Feb 2002. > > Since the Requirements is already in the RFC queue, I was wondering if > it is possible to make any edits at this point > without causing a lot of delays. Any advise David, Patrick ?? > > Thanks > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M > Sent: Friday, September 19, 2003 10:39 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Requirements > > > > I agree with those who have stated the architecture requirement in > section 5, #10 (shown below) puts an unnecessary burden on the FEs and > is not required in order to perform topology discovery. I also agree > that other solutions are available that do not require this > functionality of the FE (e.g. the CE could perform the discovery, it > might be entered manually, some other manager could do the discovery). > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > information (topology by which the FEs in the NE are connected) to > > the CE(s). > > > > I suspect based on a protocol requirement #10 (shown below) that the > intent was that some mechanism to report topology information from the > FE to the CE must exist. However, nowhere in the document does it state > that that FE functionality is optional. I believe that clarification > should be added. > > > > 10)Topology Exchange > > The ForCES protocol MUST allow the FEs to provide their topology > > information (topology by which the FEs in the NE are connected) to > > the CE(s). (refer to section 5, requirement# 10) > > > > One suggestion is to rewrite requirement #10 in section 5 to be similar > to item 10) Topology Exchange and perhaps add the qualifier that the FEs > are NOT REQUIRED to be able to provide topology information to the CEs. > > > > > Regards, > > Ellen Deleganes > > > > From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 20 20:36:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29040 for ; Sat, 20 Sep 2003 20:36:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0sDQ-0003U8-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 20:36:40 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0sDF-0003TX-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 20:36:29 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00BC1599@cherry.ease.lsoft.com>; Sat, 20 Sep 2003 20:35:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55586189 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 20:35:09 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 20 Sep 2003 20:35:09 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8L0Wmo12536 for ; Sun, 21 Sep 2003 00:32:48 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8L0TmH11683 for ; Sun, 21 Sep 2003 00:29:48 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092017350721541 for ; Sat, 20 Sep 2003 17:35:07 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 20 Sep 2003 17:35:07 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Requirements Thread-Index: AcN/0wGJNjIhQDEUS3eZEjqir85a1wABD9uw X-OriginalArrivalTime: 21 Sep 2003 00:35:07.0998 (UTC) FILETIME=[354677E0:01C37FD8] Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00A0A29@orsmsx410.jf.intel.com> Date: Sat, 20 Sep 2003 17:35:08 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Jamal, The text for this requirement has always been inter-FE topology (since v-02). I am pretty sure but I'll check with Todd anyways on this. If we do not provide protocol mechanisms to support this, then there will=20 have to be non-standard ways to obtain this information from the FEs which provide this info, which we would like to avoid. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Saturday, September 20, 2003 4:57 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Requirements Hormuzd, Talk to Todd - i think he was the one who added this. And i think it was meant to imply intra-FE not inter-FE topology. Either it should be clarified to be intra-FE (which i agree is LFB specific) or totaly removed. I dont think we should stop anyone from implementing it if they wish but it should not be on a protocol check list. cheers, jamal On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > The intent of this requirement was not to mandate all FEs to have this > information, as is suggested in section 5 # 10, > but to support protocol mechanisms to obtain this information from FEs > if it is available, as is stated in section 7 # 10. > I agree that the text in section 5 # 10 needs to be modified to bring > out the correct intent, which is stated in section 7 # 10. > As for the history, this requirement has been around since version 02 of > the draft back in Feb 2002. > > Since the Requirements is already in the RFC queue, I was wondering if > it is possible to make any edits at this point > without causing a lot of delays. Any advise David, Patrick ?? > > Thanks > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M > Sent: Friday, September 19, 2003 10:39 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Requirements > > > > I agree with those who have stated the architecture requirement in > section 5, #10 (shown below) puts an unnecessary burden on the FEs and > is not required in order to perform topology discovery. I also agree > that other solutions are available that do not require this > functionality of the FE (e.g. the CE could perform the discovery, it > might be entered manually, some other manager could do the discovery). > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > information (topology by which the FEs in the NE are connected) to > > the CE(s). > > > > I suspect based on a protocol requirement #10 (shown below) that the > intent was that some mechanism to report topology information from the > FE to the CE must exist. However, nowhere in the document does it state > that that FE functionality is optional. I believe that clarification > should be added. > > > > 10)Topology Exchange > > The ForCES protocol MUST allow the FEs to provide their topology > > information (topology by which the FEs in the NE are connected) to > > the CE(s). (refer to section 5, requirement# 10) > > > > One suggestion is to rewrite requirement #10 in section 5 to be similar > to item 10) Topology Exchange and perhaps add the qualifier that the FEs > are NOT REQUIRED to be able to provide topology information to the CEs. > > > > > Regards, > > Ellen Deleganes > > > > From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 20 20:47:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29291 for ; Sat, 20 Sep 2003 20:47:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0sO5-0003b9-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 20:47:41 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0sNv-0003b4-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 20:47:31 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00BC173F@cherry.ease.lsoft.com>; Sat, 20 Sep 2003 20:47:26 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55587272 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 20:47:24 -0400 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 20 Sep 2003 20:47:24 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id h8L0lpt30736 for ; Sat, 20 Sep 2003 17:47:51 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Sat, 20 Sep 2003 17:47:51 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00A0A29@orsmsx410.jf.intel.com> Precedence: list Hormuzd, Can you provide an example - maybe that will clarify it for me. Is the information you refer to not available at the CE or what does having it at the FE buy you? Could the CE teach the FE? cheers, jamal On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > Jamal, > > The text for this requirement has always been inter-FE topology (since > v-02). > I am pretty sure but I'll check with Todd anyways on this. > > If we do not provide protocol mechanisms to support this, then there > will > have to be non-standard ways to obtain this information from the FEs > which > provide this info, which we would like to avoid. > > Thanks > Hormuzd > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Saturday, September 20, 2003 4:57 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Requirements > > > Hormuzd, > > Talk to Todd - i think he was the one who added this. And i think > it was meant to imply intra-FE not inter-FE topology. > Either it should be clarified to be intra-FE (which i agree is LFB > specific) or totaly removed. I dont think we should stop anyone from > implementing it if they wish but it should not be on a protocol check > list. > > cheers, > jamal > > On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > The intent of this requirement was not to mandate all FEs to have this > > information, as is suggested in section 5 # 10, > > but to support protocol mechanisms to obtain this information from FEs > > if it is available, as is stated in section 7 # 10. > > I agree that the text in section 5 # 10 needs to be modified to bring > > out the correct intent, which is stated in section 7 # 10. > > As for the history, this requirement has been around since version 02 > of > > the draft back in Feb 2002. > > > > Since the Requirements is already in the RFC queue, I was wondering if > > it is possible to make any edits at this point > > without causing a lot of delays. Any advise David, Patrick ?? > > > > Thanks > > Hormuzd > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M > > Sent: Friday, September 19, 2003 10:39 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] Requirements > > > > > > > > I agree with those who have stated the architecture requirement in > > section 5, #10 (shown below) puts an unnecessary burden on the FEs and > > is not required in order to perform topology discovery. I also agree > > that other solutions are available that do not require this > > functionality of the FE (e.g. the CE could perform the discovery, it > > might be entered manually, some other manager could do the discovery). > > > > > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > > > information (topology by which the FEs in the NE are connected) to > > > > the CE(s). > > > > > > > > I suspect based on a protocol requirement #10 (shown below) that the > > intent was that some mechanism to report topology information from the > > FE to the CE must exist. However, nowhere in the document does it > state > > that that FE functionality is optional. I believe that clarification > > should be added. > > > > > > > > 10)Topology Exchange > > > > The ForCES protocol MUST allow the FEs to provide their topology > > > > information (topology by which the FEs in the NE are connected) to > > > > the CE(s). (refer to section 5, requirement# 10) > > > > > > > > One suggestion is to rewrite requirement #10 in section 5 to be > similar > > to item 10) Topology Exchange and perhaps add the qualifier that the > FEs > > are NOT REQUIRED to be able to provide topology information to the > CEs. > > > > > > > > > > Regards, > > > > Ellen Deleganes > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 20 20:57:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29673 for ; Sat, 20 Sep 2003 20:57:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0sXq-0003k1-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 20:57:46 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0sXf-0003jv-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 20:57:35 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00BC1898@cherry.ease.lsoft.com>; Sat, 20 Sep 2003 20:57:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55587563 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 20:57:30 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 20 Sep 2003 20:57:30 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5481405 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 20:57:30 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030920205230.022876c0@mail.stevecrocker.com> Date: Sat, 20 Sep 2003 20:57:10 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00A0A29@orsmsx410.jf.intel. com> Precedence: list A large part of my problem with this requirement is that it leads sensible implementors (such as yourself) to think that they need special protocol mechanisms to support this. It also leads sensible FE implementors to think that they are somehow required to provide this implementation. 1) FE's better not be required to provide inter-FE topology information. 2) Allowing FEs which have such information to provide it does not require special protocol mechanisms in any reasonably designed protocol. CEs will need to ask FEs for many pieces of FE level information. If we must have a requirement in this area at all, it should be a requirement that the set of FE information a CE can query should include support for optional information about inter-FE connectivity. (A CE should not be required to ask about this, an FE should not be required to provide this, and it really should not be treated as special information requiring special protocol support mechanisms. Another way of looking at this is that there are many kinds of information that an FE might be able to provide that might or might not be communicable in the initial set of information mandated for CE-FE querying. For lots of reasons, the protocol MUST be extensible. Making support of this information important relative to selecting / defining the protocol seems a serious mistake. Yours, Joel M. Halpern At 05:35 PM 9/20/2003 -0700, you wrote: >The text for this requirement has always been inter-FE topology (since >v-02). >I am pretty sure but I'll check with Todd anyways on this. > >If we do not provide protocol mechanisms to support this, then there >will >have to be non-standard ways to obtain this information from the FEs >which >provide this info, which we would like to avoid. > >Thanks >Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 20 20:58:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29721 for ; Sat, 20 Sep 2003 20:58:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0sYz-0003ke-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 20:58:57 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0sYo-0003ka-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 20:58:46 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00BC19B5@cherry.ease.lsoft.com>; Sat, 20 Sep 2003 20:58:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55587600 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 20:58:40 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 20 Sep 2003 20:58:40 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5481410 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 20:58:39 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <9CB758BBEE58754F8F33234D75B9F4B00A0A29@orsmsx410.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030920205730.022a78e0@mail.stevecrocker.com> Date: Sat, 20 Sep 2003 20:58:20 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list One important aspect here is that the CE need never teach the FE about the topology between FEs. The FE needs to know which exist to send a packet out, with what headers. The FE does not care "who" is receiving that packet. The CE cares a great deal. Yours, Joel M. Halpern At 05:47 PM 9/20/2003 -0700, you wrote: >Hormuzd, > >Can you provide an example - maybe that will clarify it for me. >Is the information you refer to not available at the CE or what >does having it at the FE buy you? Could the CE teach the FE? > >cheers, >jamal > >On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > Jamal, > > > > The text for this requirement has always been inter-FE topology (since > > v-02). > > I am pretty sure but I'll check with Todd anyways on this. > > > > If we do not provide protocol mechanisms to support this, then there > > will > > have to be non-standard ways to obtain this information from the FEs > > which > > provide this info, which we would like to avoid. > > > > Thanks > > Hormuzd > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > Sent: Saturday, September 20, 2003 4:57 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] Requirements > > > > > > Hormuzd, > > > > Talk to Todd - i think he was the one who added this. And i think > > it was meant to imply intra-FE not inter-FE topology. > > Either it should be clarified to be intra-FE (which i agree is LFB > > specific) or totaly removed. I dont think we should stop anyone from > > implementing it if they wish but it should not be on a protocol check > > list. > > > > cheers, > > jamal > > > > On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > The intent of this requirement was not to mandate all FEs to have this > > > information, as is suggested in section 5 # 10, > > > but to support protocol mechanisms to obtain this information from FEs > > > if it is available, as is stated in section 7 # 10. > > > I agree that the text in section 5 # 10 needs to be modified to bring > > > out the correct intent, which is stated in section 7 # 10. > > > As for the history, this requirement has been around since version 02 > > of > > > the draft back in Feb 2002. > > > > > > Since the Requirements is already in the RFC queue, I was wondering if > > > it is possible to make any edits at this point > > > without causing a lot of delays. Any advise David, Patrick ?? > > > > > > Thanks > > > Hormuzd > > > > > > -----Original Message----- > > > From: Forwarding and Control Element Separation > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M > > > Sent: Friday, September 19, 2003 10:39 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > I agree with those who have stated the architecture requirement in > > > section 5, #10 (shown below) puts an unnecessary burden on the FEs and > > > is not required in order to perform topology discovery. I also agree > > > that other solutions are available that do not require this > > > functionality of the FE (e.g. the CE could perform the discovery, it > > > might be entered manually, some other manager could do the discovery). > > > > > > > > > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > > > > > information (topology by which the FEs in the NE are connected) to > > > > > > the CE(s). > > > > > > > > > > > > I suspect based on a protocol requirement #10 (shown below) that the > > > intent was that some mechanism to report topology information from the > > > FE to the CE must exist. However, nowhere in the document does it > > state > > > that that FE functionality is optional. I believe that clarification > > > should be added. > > > > > > > > > > > > 10)Topology Exchange > > > > > > The ForCES protocol MUST allow the FEs to provide their topology > > > > > > information (topology by which the FEs in the NE are connected) to > > > > > > the CE(s). (refer to section 5, requirement# 10) > > > > > > > > > > > > One suggestion is to rewrite requirement #10 in section 5 to be > > similar > > > to item 10) Topology Exchange and perhaps add the qualifier that the > > FEs > > > are NOT REQUIRED to be able to provide topology information to the > > CEs. > > > > > > > > > > > > > > > Regards, > > > > > > Ellen Deleganes > > > > > > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Sat Sep 20 21:35:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00681 for ; Sat, 20 Sep 2003 21:35:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0t8J-00047b-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 21:35:27 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A0t88-00047Y-00 for forces-archive@IETF.ORG; Sat, 20 Sep 2003 21:35:16 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00BC1BDF@cherry.ease.lsoft.com>; Sat, 20 Sep 2003 21:35:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55590717 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 20 Sep 2003 21:34:50 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 20 Sep 2003 21:34:50 -0400 Received: from psg.com ([147.28.0.62]) by psg.com with esmtp (Exim 4.22) id 1A0t7g-000FGB-Ez for FORCES@PEACH.EASE.LSOFT.COM; Sun, 21 Sep 2003 01:34:49 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Approved-By: avri Message-ID: Date: Sun, 21 Sep 2003 10:33:42 +0900 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: avri Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030920205230.022876c0@mail.stevecrocker.com> Precedence: list Content-Transfer-Encoding: quoted-printable On s=F6ndag, sep 21, 2003, at 09:57 Asia/Seoul, Joel M. Halpern wrote: > A large part of my problem with this requirement is that it leads=20 > sensible > implementors (such as yourself) to think that they need special=20 > protocol > mechanisms to support this. It also leads sensible FE implementors to > think that they are somehow required to provide this implementation. > > 1) FE's better not be required to provide inter-FE topology=20 > information. It is not the FE that is required to provide the information. It is the protocol that is required to provide a means for the FE to=20 provide the information. The two are very different. > > 2) Allowing FEs which have such information to provide it does not=20 > require > special protocol mechanisms in any reasonably designed protocol. There has to be some mechanism. While I prefer general mechanisms that=20= allow for various kinds on info to be provided. I think this is one=20 type of information that should be conveyed if available. > CEs will > need to ask FEs for many pieces of FE level information. If we must=20= > have a > requirement in this area at all, it should be a requirement that the=20= > set of > FE information a CE can query should include support for optional > information about inter-FE connectivity. What info is provided is optional. The protocol mechanism should not=20 be. > (A CE should not be required to > ask about this, an FE should not be required to provide this, and it=20= > really > should not be treated as special information requiring special = protocol > support mechanisms. As I read it the FE is not required to provide it., Nor is the CE=20 required to request it. The protocol is required to enable providing it. > > Another way of looking at this is that there are many kinds of=20 > information > that an FE might be able to provide that might or might not be=20 > communicable > in the initial set of information mandated for CE-FE querying. For=20 > lots of > reasons, the protocol MUST be extensible. Perhaps there are other sorts of information that would be useful for=20 the FE to provide. In which the mechanisms for providing this info=20 should be flexible. If the FE has this info because they have been=20 configured by the FE manager to have it, it is only reasonable that=20 there should be a way to convey it to the CE. > Making support of this > information important relative to selecting / defining the protocol=20 > seems a > serious mistake. I disagree. I think the protocol should be required to have a means to=20= transfer any information that might be useful in defining the FE=20 topology. I am definitely in favor of leaving the requirement in. And if the=20 'best' protocol is best in all ways except that it it not able to=20 transfer this information then the WG can consider whether it really=20 cares at that time. Personally I would prefer a protocol that did=20 allow this information to be transfered. a.= From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 22 14:18:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28551 for ; Mon, 22 Sep 2003 14:18:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1VH2-0003gu-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 14:19:00 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1VGs-0003Yw-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 14:18:50 -0400 Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00BD6E22@cherry.ease.lsoft.com>; Mon, 22 Sep 2003 14:17:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55668602 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Sep 2003 12:49:39 -0400 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 22 Sep 2003 12:49:39 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8MGncwA019432 for ; Mon, 22 Sep 2003 11:49:38 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B00A0A29@orsmsx410.jf.intel.com> <5.1.0.14.0.20030920205730.022a78e0@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3F6F2820.51BB9A93@alcatel.com> Date: Mon, 22 Sep 2003 11:49:36 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Not if the behavior of a group of FEs depends on their connectivity! If CE can configure that behavior, then the CE better be able to teach each FE in that group their connectivity information. Regards, Alex. "Joel M. Halpern" wrote: > One important aspect here is that the CE need never teach the FE about the > topology between FEs. The FE needs to know which exist to send a packet > out, with what headers. The FE does not care "who" is receiving that > packet. The CE cares a great deal. > > Yours, > Joel M. Halpern > > At 05:47 PM 9/20/2003 -0700, you wrote: > >Hormuzd, > > > >Can you provide an example - maybe that will clarify it for me. > >Is the information you refer to not available at the CE or what > >does having it at the FE buy you? Could the CE teach the FE? > > > >cheers, > >jamal > > > >On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > Jamal, > > > > > > The text for this requirement has always been inter-FE topology (since > > > v-02). > > > I am pretty sure but I'll check with Todd anyways on this. > > > > > > If we do not provide protocol mechanisms to support this, then there > > > will > > > have to be non-standard ways to obtain this information from the FEs > > > which > > > provide this info, which we would like to avoid. > > > > > > Thanks > > > Hormuzd > > > -----Original Message----- > > > From: Forwarding and Control Element Separation > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > > Sent: Saturday, September 20, 2003 4:57 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: Re: [FORCES] Requirements > > > > > > > > > Hormuzd, > > > > > > Talk to Todd - i think he was the one who added this. And i think > > > it was meant to imply intra-FE not inter-FE topology. > > > Either it should be clarified to be intra-FE (which i agree is LFB > > > specific) or totaly removed. I dont think we should stop anyone from > > > implementing it if they wish but it should not be on a protocol check > > > list. > > > > > > cheers, > > > jamal > > > > > > On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > > > The intent of this requirement was not to mandate all FEs to have this > > > > information, as is suggested in section 5 # 10, > > > > but to support protocol mechanisms to obtain this information from FEs > > > > if it is available, as is stated in section 7 # 10. > > > > I agree that the text in section 5 # 10 needs to be modified to bring > > > > out the correct intent, which is stated in section 7 # 10. > > > > As for the history, this requirement has been around since version 02 > > > of > > > > the draft back in Feb 2002. > > > > > > > > Since the Requirements is already in the RFC queue, I was wondering if > > > > it is possible to make any edits at this point > > > > without causing a lot of delays. Any advise David, Patrick ?? > > > > > > > > Thanks > > > > Hormuzd > > > > > > > > -----Original Message----- > > > > From: Forwarding and Control Element Separation > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M > > > > Sent: Friday, September 19, 2003 10:39 AM > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > > > > > I agree with those who have stated the architecture requirement in > > > > section 5, #10 (shown below) puts an unnecessary burden on the FEs and > > > > is not required in order to perform topology discovery. I also agree > > > > that other solutions are available that do not require this > > > > functionality of the FE (e.g. the CE could perform the discovery, it > > > > might be entered manually, some other manager could do the discovery). > > > > > > > > > > > > > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > > > > > > > information (topology by which the FEs in the NE are connected) to > > > > > > > > the CE(s). > > > > > > > > > > > > > > > > I suspect based on a protocol requirement #10 (shown below) that the > > > > intent was that some mechanism to report topology information from the > > > > FE to the CE must exist. However, nowhere in the document does it > > > state > > > > that that FE functionality is optional. I believe that clarification > > > > should be added. > > > > > > > > > > > > > > > > 10)Topology Exchange > > > > > > > > The ForCES protocol MUST allow the FEs to provide their topology > > > > > > > > information (topology by which the FEs in the NE are connected) to > > > > > > > > the CE(s). (refer to section 5, requirement# 10) > > > > > > > > > > > > > > > > One suggestion is to rewrite requirement #10 in section 5 to be > > > similar > > > > to item 10) Topology Exchange and perhaps add the qualifier that the > > > FEs > > > > are NOT REQUIRED to be able to provide topology information to the > > > CEs. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Ellen Deleganes > > > > > > > > > > > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 22 14:27:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28889 for ; Mon, 22 Sep 2003 14:27:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1VOt-0004LH-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 14:27:07 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1VOj-0004Kk-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 14:26:57 -0400 Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00BD6F7F@cherry.ease.lsoft.com>; Mon, 22 Sep 2003 14:26:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55668960 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Sep 2003 12:57:28 -0400 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 22 Sep 2003 12:57:28 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8MGvRwA020912 for ; Mon, 22 Sep 2003 11:57:27 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3F6F29F5.52EFDAB4@alcatel.com> Date: Mon, 22 Sep 2003 11:57:25 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jamal, Don't forget that the CE may lose this information by it going out of service. It is possible this information may have been stored in a more persistent storage from which the CE could refresh the lost information. But there is no guarrantee that will be most current. The best place to get the most current information is from the element whose current behavior is determined by this information. And that is the FE. Regards, Alex. Jamal Hadi Salim wrote: > Hormuzd, > > Can you provide an example - maybe that will clarify it for me. > Is the information you refer to not available at the CE or what > does having it at the FE buy you? Could the CE teach the FE? > > cheers, > jamal > > On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > Jamal, > > > > The text for this requirement has always been inter-FE topology (since > > v-02). > > I am pretty sure but I'll check with Todd anyways on this. > > > > If we do not provide protocol mechanisms to support this, then there > > will > > have to be non-standard ways to obtain this information from the FEs > > which > > provide this info, which we would like to avoid. > > > > Thanks > > Hormuzd > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > Sent: Saturday, September 20, 2003 4:57 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] Requirements > > > > > > Hormuzd, > > > > Talk to Todd - i think he was the one who added this. And i think > > it was meant to imply intra-FE not inter-FE topology. > > Either it should be clarified to be intra-FE (which i agree is LFB > > specific) or totaly removed. I dont think we should stop anyone from > > implementing it if they wish but it should not be on a protocol check > > list. > > > > cheers, > > jamal > > > > On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > The intent of this requirement was not to mandate all FEs to have this > > > information, as is suggested in section 5 # 10, > > > but to support protocol mechanisms to obtain this information from FEs > > > if it is available, as is stated in section 7 # 10. > > > I agree that the text in section 5 # 10 needs to be modified to bring > > > out the correct intent, which is stated in section 7 # 10. > > > As for the history, this requirement has been around since version 02 > > of > > > the draft back in Feb 2002. > > > > > > Since the Requirements is already in the RFC queue, I was wondering if > > > it is possible to make any edits at this point > > > without causing a lot of delays. Any advise David, Patrick ?? > > > > > > Thanks > > > Hormuzd > > > > > > -----Original Message----- > > > From: Forwarding and Control Element Separation > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M > > > Sent: Friday, September 19, 2003 10:39 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > I agree with those who have stated the architecture requirement in > > > section 5, #10 (shown below) puts an unnecessary burden on the FEs and > > > is not required in order to perform topology discovery. I also agree > > > that other solutions are available that do not require this > > > functionality of the FE (e.g. the CE could perform the discovery, it > > > might be entered manually, some other manager could do the discovery). > > > > > > > > > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > > > > > information (topology by which the FEs in the NE are connected) to > > > > > > the CE(s). > > > > > > > > > > > > I suspect based on a protocol requirement #10 (shown below) that the > > > intent was that some mechanism to report topology information from the > > > FE to the CE must exist. However, nowhere in the document does it > > state > > > that that FE functionality is optional. I believe that clarification > > > should be added. > > > > > > > > > > > > 10)Topology Exchange > > > > > > The ForCES protocol MUST allow the FEs to provide their topology > > > > > > information (topology by which the FEs in the NE are connected) to > > > > > > the CE(s). (refer to section 5, requirement# 10) > > > > > > > > > > > > One suggestion is to rewrite requirement #10 in section 5 to be > > similar > > > to item 10) Topology Exchange and perhaps add the qualifier that the > > FEs > > > are NOT REQUIRED to be able to provide topology information to the > > CEs. > > > > > > > > > > > > > > > Regards, > > > > > > Ellen Deleganes > > > > > > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 22 16:34:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09080 for ; Mon, 22 Sep 2003 16:34:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1XOS-0006Q0-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 16:34:48 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1XOH-0006D0-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 16:34:37 -0400 Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00BD8939@cherry.ease.lsoft.com>; Mon, 22 Sep 2003 16:31:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55663938 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Sep 2003 14:23:22 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 22 Sep 2003 14:23:22 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5491234 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Sep 2003 14:23:21 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <9CB758BBEE58754F8F33234D75B9F4B00A0A29@orsmsx410.jf.intel.com> <5.1.0.14.0.20030920205730.022a78e0@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030922142127.022fe980@mail.stevecrocker.com> Date: Mon, 22 Sep 2003 14:23:03 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3F6F2820.51BB9A93@alcatel.com> Precedence: list I disagree. It is quite likely that the desired behavior depends upon the topology. The CE determines the Topology The CE selects the Desired Behavior The CE teaches (directs) the FE in how to behave. The CE never tells the FE what the topology is, because that does not matter to the FE. What matters to the FE is how it should behave. Provided from the CE. Yours, Joel M. Halpern At 11:49 AM 9/22/2003 -0500, you wrote: >Not if the behavior of a group of FEs depends on their connectivity! If CE can >configure that behavior, then the CE better be able to teach each FE in that >group their connectivity information. > >Regards, >Alex. > >"Joel M. Halpern" wrote: > > > One important aspect here is that the CE need never teach the FE about the > > topology between FEs. The FE needs to know which exist to send a packet > > out, with what headers. The FE does not care "who" is receiving that > > packet. The CE cares a great deal. > > > > Yours, > > Joel M. Halpern > > > > At 05:47 PM 9/20/2003 -0700, you wrote: > > >Hormuzd, > > > > > >Can you provide an example - maybe that will clarify it for me. > > >Is the information you refer to not available at the CE or what > > >does having it at the FE buy you? Could the CE teach the FE? > > > > > >cheers, > > >jamal > > > > > >On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > > > Jamal, > > > > > > > > The text for this requirement has always been inter-FE topology (since > > > > v-02). > > > > I am pretty sure but I'll check with Todd anyways on this. > > > > > > > > If we do not provide protocol mechanisms to support this, then there > > > > will > > > > have to be non-standard ways to obtain this information from the FEs > > > > which > > > > provide this info, which we would like to avoid. > > > > > > > > Thanks > > > > Hormuzd > > > > -----Original Message----- > > > > From: Forwarding and Control Element Separation > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > > > Sent: Saturday, September 20, 2003 4:57 PM > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > Hormuzd, > > > > > > > > Talk to Todd - i think he was the one who added this. And i think > > > > it was meant to imply intra-FE not inter-FE topology. > > > > Either it should be clarified to be intra-FE (which i agree is LFB > > > > specific) or totaly removed. I dont think we should stop anyone from > > > > implementing it if they wish but it should not be on a protocol check > > > > list. > > > > > > > > cheers, > > > > jamal > > > > > > > > On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > > > > > The intent of this requirement was not to mandate all FEs to have > this > > > > > information, as is suggested in section 5 # 10, > > > > > but to support protocol mechanisms to obtain this information > from FEs > > > > > if it is available, as is stated in section 7 # 10. > > > > > I agree that the text in section 5 # 10 needs to be modified to bring > > > > > out the correct intent, which is stated in section 7 # 10. > > > > > As for the history, this requirement has been around since version 02 > > > > of > > > > > the draft back in Feb 2002. > > > > > > > > > > Since the Requirements is already in the RFC queue, I was > wondering if > > > > > it is possible to make any edits at this point > > > > > without causing a lot of delays. Any advise David, Patrick ?? > > > > > > > > > > Thanks > > > > > Hormuzd > > > > > > > > > > -----Original Message----- > > > > > From: Forwarding and Control Element Separation > > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M > > > > > Sent: Friday, September 19, 2003 10:39 AM > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > > > > > > > > > I agree with those who have stated the architecture requirement in > > > > > section 5, #10 (shown below) puts an unnecessary burden on the > FEs and > > > > > is not required in order to perform topology discovery. I also agree > > > > > that other solutions are available that do not require this > > > > > functionality of the FE (e.g. the CE could perform the discovery, it > > > > > might be entered manually, some other manager could do the > discovery). > > > > > > > > > > > > > > > > > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > > > > > > > > > information (topology by which the FEs in the NE are > connected) to > > > > > > > > > > the CE(s). > > > > > > > > > > > > > > > > > > > > I suspect based on a protocol requirement #10 (shown below) that the > > > > > intent was that some mechanism to report topology information > from the > > > > > FE to the CE must exist. However, nowhere in the document does it > > > > state > > > > > that that FE functionality is optional. I believe that clarification > > > > > should be added. > > > > > > > > > > > > > > > > > > > > 10)Topology Exchange > > > > > > > > > > The ForCES protocol MUST allow the FEs to provide their topology > > > > > > > > > > information (topology by which the FEs in the NE are connected) to > > > > > > > > > > the CE(s). (refer to section 5, requirement# 10) > > > > > > > > > > > > > > > > > > > > One suggestion is to rewrite requirement #10 in section 5 to be > > > > similar > > > > > to item 10) Topology Exchange and perhaps add the qualifier that the > > > > FEs > > > > > are NOT REQUIRED to be able to provide topology information to the > > > > CEs. > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Ellen Deleganes > > > > > > > > > > > > > > > > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 22 18:13:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14494 for ; Mon, 22 Sep 2003 18:13:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Yw0-0006u1-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 18:13:32 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1Yvz-0006tN-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 18:13:31 -0400 Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00BDA0CB@cherry.ease.lsoft.com>; Mon, 22 Sep 2003 18:13:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55676202 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Sep 2003 18:02:10 -0400 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 22 Sep 2003 18:02:05 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8MM24Bx021587 for ; Mon, 22 Sep 2003 17:02:05 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B00A0A29@orsmsx410.jf.intel.com> <5.1.0.14.0.20030920205730.022a78e0@mail.stevecrocker.com> <5.1.0.14.0.20030922142127.022fe980@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3F6F715C.3B09F7AD@alcatel.com> Date: Mon, 22 Sep 2003 17:02:04 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit How would the CE best direct the behavior of FEs if not through topology configuration? The control of the inter-FE topology and its consequences should not be too different from those of the intra-FE topology. In the latter, the CE could set the LFBs up in ways to achieve certain behaviors. We could take a different tack for inter-FE topology,.. but why? Regards, Alex. "Joel M. Halpern" wrote: > I disagree. > It is quite likely that the desired behavior depends upon the topology. > The CE determines the Topology > The CE selects the Desired Behavior > The CE teaches (directs) the FE in how to behave. > > The CE never tells the FE what the topology is, because that does not > matter to the FE. What matters to the FE is how it should > behave. Provided from the CE. > > Yours, > Joel M. Halpern > > At 11:49 AM 9/22/2003 -0500, you wrote: > >Not if the behavior of a group of FEs depends on their connectivity! If CE can > >configure that behavior, then the CE better be able to teach each FE in that > >group their connectivity information. > > > >Regards, > >Alex. > > > >"Joel M. Halpern" wrote: > > > > > One important aspect here is that the CE need never teach the FE about the > > > topology between FEs. The FE needs to know which exist to send a packet > > > out, with what headers. The FE does not care "who" is receiving that > > > packet. The CE cares a great deal. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 05:47 PM 9/20/2003 -0700, you wrote: > > > >Hormuzd, > > > > > > > >Can you provide an example - maybe that will clarify it for me. > > > >Is the information you refer to not available at the CE or what > > > >does having it at the FE buy you? Could the CE teach the FE? > > > > > > > >cheers, > > > >jamal > > > > > > > >On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > > > > > Jamal, > > > > > > > > > > The text for this requirement has always been inter-FE topology (since > > > > > v-02). > > > > > I am pretty sure but I'll check with Todd anyways on this. > > > > > > > > > > If we do not provide protocol mechanisms to support this, then there > > > > > will > > > > > have to be non-standard ways to obtain this information from the FEs > > > > > which > > > > > provide this info, which we would like to avoid. > > > > > > > > > > Thanks > > > > > Hormuzd > > > > > -----Original Message----- > > > > > From: Forwarding and Control Element Separation > > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > > > > Sent: Saturday, September 20, 2003 4:57 PM > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > > > > Hormuzd, > > > > > > > > > > Talk to Todd - i think he was the one who added this. And i think > > > > > it was meant to imply intra-FE not inter-FE topology. > > > > > Either it should be clarified to be intra-FE (which i agree is LFB > > > > > specific) or totaly removed. I dont think we should stop anyone from > > > > > implementing it if they wish but it should not be on a protocol check > > > > > list. > > > > > > > > > > cheers, > > > > > jamal > > > > > > > > > > On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > > > > > > > The intent of this requirement was not to mandate all FEs to have > > this > > > > > > information, as is suggested in section 5 # 10, > > > > > > but to support protocol mechanisms to obtain this information > > from FEs > > > > > > if it is available, as is stated in section 7 # 10. > > > > > > I agree that the text in section 5 # 10 needs to be modified to bring > > > > > > out the correct intent, which is stated in section 7 # 10. > > > > > > As for the history, this requirement has been around since version 02 > > > > > of > > > > > > the draft back in Feb 2002. > > > > > > > > > > > > Since the Requirements is already in the RFC queue, I was > > wondering if > > > > > > it is possible to make any edits at this point > > > > > > without causing a lot of delays. Any advise David, Patrick ?? > > > > > > > > > > > > Thanks > > > > > > Hormuzd > > > > > > > > > > > > -----Original Message----- > > > > > > From: Forwarding and Control Element Separation > > > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M > > > > > > Sent: Friday, September 19, 2003 10:39 AM > > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > > > > > > > > > > > > > I agree with those who have stated the architecture requirement in > > > > > > section 5, #10 (shown below) puts an unnecessary burden on the > > FEs and > > > > > > is not required in order to perform topology discovery. I also agree > > > > > > that other solutions are available that do not require this > > > > > > functionality of the FE (e.g. the CE could perform the discovery, it > > > > > > might be entered manually, some other manager could do the > > discovery). > > > > > > > > > > > > > > > > > > > > > > > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > > > > > > > > > > > > information (topology by which the FEs in the NE are > > connected) to > > > > > > > > > > > > the CE(s). > > > > > > > > > > > > > > > > > > > > > > > > I suspect based on a protocol requirement #10 (shown below) that the > > > > > > intent was that some mechanism to report topology information > > from the > > > > > > FE to the CE must exist. However, nowhere in the document does it > > > > > state > > > > > > that that FE functionality is optional. I believe that clarification > > > > > > should be added. > > > > > > > > > > > > > > > > > > > > > > > > 10)Topology Exchange > > > > > > > > > > > > The ForCES protocol MUST allow the FEs to provide their topology > > > > > > > > > > > > information (topology by which the FEs in the NE are connected) to > > > > > > > > > > > > the CE(s). (refer to section 5, requirement# 10) > > > > > > > > > > > > > > > > > > > > > > > > One suggestion is to rewrite requirement #10 in section 5 to be > > > > > similar > > > > > > to item 10) Topology Exchange and perhaps add the qualifier that the > > > > > FEs > > > > > > are NOT REQUIRED to be able to provide topology information to the > > > > > CEs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Ellen Deleganes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 22 20:07:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18387 for ; Mon, 22 Sep 2003 20:07:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1ain-0000Ri-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 20:08:01 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1ain-0000Rc-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 20:08:01 -0400 Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00BDAAFD@cherry.ease.lsoft.com>; Mon, 22 Sep 2003 20:07:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55688956 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Sep 2003 20:07:44 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 22 Sep 2003 20:07:44 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5491959 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Sep 2003 20:07:43 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <9CB758BBEE58754F8F33234D75B9F4B00A0A29@orsmsx410.jf.intel.com> <5.1.0.14.0.20030920205730.022a78e0@mail.stevecrocker.com> <5.1.0.14.0.20030922142127.022fe980@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030922195626.0188d8c0@mail.stevecrocker.com> Date: Mon, 22 Sep 2003 20:07:16 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3F6F715C.3B09F7AD@alcatel.com> Precedence: list I am sorry, but I am afraid I am misunderstanding you. The CE uses the FORCES (Fp) protocol to direct the FE. It uses the knowledge of the inter-FE topology which it gleans from a combination of configuration and discovery protocols (of which there are many). Such discovery protocols are the kinds of things CEs run (they send the packets out through and receive response from the FE, but the CE has the protocol machinery. While there may be devices where inter-FE topology is controllable, such control is outside of the scope of FORCES. We are controlling individual FEs. [It is possible that there will be LFBs that can be used to assist in such functions. It is possible that there will be other protocols that are supported by the CEs or FEs to do such things. However, that is not the domain of FORCES.] In contrast, the intra-FE operations are the domain of FORCES. Some folks actually asked that we leave control of intra-FE topology out of the work. We have decided that intra-FE topology is within scope. (With the caveat that not all FEs will support that, and that even FEs which support reconfigurable intra-FE topology will have restrictions on what can be set up.) Other than static configuration (which is highly error prone) there is no obvious way for FEs to know their inter-FE topology. You suggested earlier that FEs should have this static configuration rather than CEs. I think it is more reasonable to put that on the CE, but that is something reasonable folks can differ on. Part of what causes me concern about this protocol requirement is that as written it has prompted several protocol proposals to include explicit mechanisms for addressing this "need". I do not object to including in the set of attributes an FE might have optional attributes about known FE adjacency. However, a) that needs to be optional, and the current wording makes it look mandatory b) it should be worded in a way that does not encourage the creation of special protocol mechanisms. By this I mean that the wording should be about the system / solution enabling the transfer of the information, not about the protocol having the ability to carry it. (And no, that distinction should not matter. It observably does matter since two different proposals have fallen into this trap. And at least one responded that they need to keep the special mechanism to meet the requirements when I questioned the authors about it.) Yours, Joel M. Halpern At 05:02 PM 9/22/2003 -0500, you wrote: >How would the CE best direct the behavior of FEs if not through topology >configuration? The control of the inter-FE topology and its consequences >should not be too different from those of the intra-FE topology. In the >latter, >the CE could set the LFBs up in ways to achieve certain behaviors. We could >take a different tack for inter-FE topology,.. but why? > >Regards, >Alex. > >"Joel M. Halpern" wrote: > > > I disagree. > > It is quite likely that the desired behavior depends upon the topology. > > The CE determines the Topology > > The CE selects the Desired Behavior > > The CE teaches (directs) the FE in how to behave. > > > > The CE never tells the FE what the topology is, because that does not > > matter to the FE. What matters to the FE is how it should > > behave. Provided from the CE. > > > > Yours, > > Joel M. Halpern > > > > At 11:49 AM 9/22/2003 -0500, you wrote: > > >Not if the behavior of a group of FEs depends on their connectivity! > If CE can > > >configure that behavior, then the CE better be able to teach each FE > in that > > >group their connectivity information. > > > > > >Regards, > > >Alex. > > > > > >"Joel M. Halpern" wrote: > > > > > > > One important aspect here is that the CE need never teach the FE > about the > > > > topology between FEs. The FE needs to know which exist to send a > packet > > > > out, with what headers. The FE does not care "who" is receiving that > > > > packet. The CE cares a great deal. > > > > > > > > Yours, > > > > Joel M. Halpern > > > > > > > > At 05:47 PM 9/20/2003 -0700, you wrote: > > > > >Hormuzd, > > > > > > > > > >Can you provide an example - maybe that will clarify it for me. > > > > >Is the information you refer to not available at the CE or what > > > > >does having it at the FE buy you? Could the CE teach the FE? > > > > > > > > > >cheers, > > > > >jamal > > > > > > > > > >On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > > > > > > > Jamal, > > > > > > > > > > > > The text for this requirement has always been inter-FE topology > (since > > > > > > v-02). > > > > > > I am pretty sure but I'll check with Todd anyways on this. > > > > > > > > > > > > If we do not provide protocol mechanisms to support this, then > there > > > > > > will > > > > > > have to be non-standard ways to obtain this information from > the FEs > > > > > > which > > > > > > provide this info, which we would like to avoid. > > > > > > > > > > > > Thanks > > > > > > Hormuzd > > > > > > -----Original Message----- > > > > > > From: Forwarding and Control Element Separation > > > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > > > > > Sent: Saturday, September 20, 2003 4:57 PM > > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > > > > > > > Hormuzd, > > > > > > > > > > > > Talk to Todd - i think he was the one who added this. And i think > > > > > > it was meant to imply intra-FE not inter-FE topology. > > > > > > Either it should be clarified to be intra-FE (which i agree is LFB > > > > > > specific) or totaly removed. I dont think we should stop anyone > from > > > > > > implementing it if they wish but it should not be on a protocol > check > > > > > > list. > > > > > > > > > > > > cheers, > > > > > > jamal > > > > > > > > > > > > On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > > > > > > > > > The intent of this requirement was not to mandate all FEs to have > > > this > > > > > > > information, as is suggested in section 5 # 10, > > > > > > > but to support protocol mechanisms to obtain this information > > > from FEs > > > > > > > if it is available, as is stated in section 7 # 10. > > > > > > > I agree that the text in section 5 # 10 needs to be modified > to bring > > > > > > > out the correct intent, which is stated in section 7 # 10. > > > > > > > As for the history, this requirement has been around since > version 02 > > > > > > of > > > > > > > the draft back in Feb 2002. > > > > > > > > > > > > > > Since the Requirements is already in the RFC queue, I was > > > wondering if > > > > > > > it is possible to make any edits at this point > > > > > > > without causing a lot of delays. Any advise David, Patrick ?? > > > > > > > > > > > > > > Thanks > > > > > > > Hormuzd > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Forwarding and Control Element Separation > > > > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, > Ellen M > > > > > > > Sent: Friday, September 19, 2003 10:39 AM > > > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree with those who have stated the architecture > requirement in > > > > > > > section 5, #10 (shown below) puts an unnecessary burden on the > > > FEs and > > > > > > > is not required in order to perform topology discovery. I > also agree > > > > > > > that other solutions are available that do not require this > > > > > > > functionality of the FE (e.g. the CE could perform the > discovery, it > > > > > > > might be entered manually, some other manager could do the > > > discovery). > > > > > > > > > > > > > > > > > > > > > > > > > > > > 10) In a ForCES NE, the FEs MUST be able to provide their > topology > > > > > > > > > > > > > > information (topology by which the FEs in the NE are > > > connected) to > > > > > > > > > > > > > > the CE(s). > > > > > > > > > > > > > > > > > > > > > > > > > > > > I suspect based on a protocol requirement #10 (shown below) > that the > > > > > > > intent was that some mechanism to report topology information > > > from the > > > > > > > FE to the CE must exist. However, nowhere in the document does it > > > > > > state > > > > > > > that that FE functionality is optional. I believe that > clarification > > > > > > > should be added. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 10)Topology Exchange > > > > > > > > > > > > > > The ForCES protocol MUST allow the FEs to provide their > topology > > > > > > > > > > > > > > information (topology by which the FEs in the NE are > connected) to > > > > > > > > > > > > > > the CE(s). (refer to section 5, requirement# 10) > > > > > > > > > > > > > > > > > > > > > > > > > > > > One suggestion is to rewrite requirement #10 in section 5 to be > > > > > > similar > > > > > > > to item 10) Topology Exchange and perhaps add the qualifier > that the > > > > > > FEs > > > > > > > are NOT REQUIRED to be able to provide topology information > to the > > > > > > CEs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Ellen Deleganes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 22 23:24:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05961 for ; Mon, 22 Sep 2003 23:24:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1dn1-00073X-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 23:24:35 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1dn0-00073K-00 for forces-archive@IETF.ORG; Mon, 22 Sep 2003 23:24:34 -0400 Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00BDBA6D@cherry.ease.lsoft.com>; Mon, 22 Sep 2003 23:24:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55704207 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Sep 2003 23:24:34 -0400 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 22 Sep 2003 23:24:33 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h8N3OQok010649 for ; Tue, 23 Sep 2003 03:24:26 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8N3J8i11739 for ; Tue, 23 Sep 2003 03:19:08 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092220243115018 for ; Mon, 22 Sep 2003 20:24:31 -0700 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Sep 2003 20:24:31 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Internet-Draft Cutoff Dates for Minneapolis, MN, USA Thread-Index: AcOBRcj91c7WjgDcQviSK/0nEXEWpgAO+5Bw X-OriginalArrivalTime: 23 Sep 2003 03:24:31.0925 (UTC) FILETIME=[34462650:01C38182] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F4C3@orsmsx409.jf.intel.com> Date: Mon, 22 Sep 2003 20:24:31 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: FW: Internet-Draft Cutoff Dates for Minneapolis, MN, USA To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable FYI. Cheers, David -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] On Behalf Of Internet-Drafts Administrator Sent: Monday, September 22, 2003 11:47 AM Subject: Internet-Draft Cutoff Dates for Minneapolis, MN, USA=20 NOTE: There are two (2) Internet-Draft Cutoff dates October 20th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, October 20th,=20 at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. =20 As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, October 13th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of October 20th will NOT be accepted. October 27th: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, October 27th, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_58.html From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 01:50:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11673 for ; Tue, 23 Sep 2003 01:50:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1g4f-0005Ob-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 01:50:57 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1g4e-0005OY-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 01:50:56 -0400 Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00BDD3AB@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 1:50:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55722006 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 01:50:56 -0400 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 01:50:55 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h8N5pH3D021468 for ; Tue, 23 Sep 2003 05:51:17 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8N5jTi19912 for ; Tue, 23 Sep 2003 05:45:29 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092222505331680 for ; Mon, 22 Sep 2003 22:50:53 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Sep 2003 22:50:53 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Requirements Thread-Index: AcN/21gTJNF+cK2VQSKELA0NxXHFnwBuL2Hw X-OriginalArrivalTime: 23 Sep 2003 05:50:53.0163 (UTC) FILETIME=[A64CBBB0:01C38196] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00A0844@orsmsx410.jf.intel.com> Date: Mon, 22 Sep 2003 22:50:52 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Joel I understand your concern regarding the architectural requirement (sec 5, #10) and I think we could clarify the text there, if still possible...or may be use the Framework draft to clarify this? Lily, any ideas? However, I believe that the protocol requirement text is fine and it should remain. From what I have heard so far, you agree that a) all FEs have this info, b) some FEs might acquire this thru some inter-FE discovery protocol or via FE manager and they should not be precluded from ForCES, c) CE needs this info. If you agree with a, b & c then it is natural to have some protocol mechanism to support this (whether it is a general or special mechanism is a separate issue)...unless you want to have a non-standard way to do this, which defeats the purpose of ForCES. You have also agreed that it is ok to have some optional mechanism for this. Now if you were in the Requirements team, which unfortunately you were not :), would you rather define optional requirements or mandatory ones ? This has a direct impact on the protocol design and interoperability. Also, I don't remember there having been any arguments or big discussions around this requirement before atleast in the design team. The only feeback we had received was from the IESG was to clarify the text in the Protocol Req section 7, which we did.=20 I hope you will understand my point of view. Thanks a lot Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Saturday, September 20, 2003 5:57 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Requirements A large part of my problem with this requirement is that it leads sensible implementors (such as yourself) to think that they need special protocol mechanisms to support this. It also leads sensible FE implementors to think that they are somehow required to provide this implementation. 1) FE's better not be required to provide inter-FE topology information. 2) Allowing FEs which have such information to provide it does not require special protocol mechanisms in any reasonably designed protocol. CEs will need to ask FEs for many pieces of FE level information. If we must have a requirement in this area at all, it should be a requirement that the set of FE information a CE can query should include support for optional information about inter-FE connectivity. (A CE should not be required to ask about this, an FE should not be required to provide this, and it really should not be treated as special information requiring special protocol support mechanisms. Another way of looking at this is that there are many kinds of information that an FE might be able to provide that might or might not be communicable in the initial set of information mandated for CE-FE querying. For lots of reasons, the protocol MUST be extensible. Making support of this information important relative to selecting / defining the protocol seems a serious mistake. Yours, Joel M. Halpern At 05:35 PM 9/20/2003 -0700, you wrote: >The text for this requirement has always been inter-FE topology (since >v-02). >I am pretty sure but I'll check with Todd anyways on this. > >If we do not provide protocol mechanisms to support this, then there >will >have to be non-standard ways to obtain this information from the FEs >which >provide this info, which we would like to avoid. > >Thanks >Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 07:25:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07453 for ; Tue, 23 Sep 2003 07:25:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1lIw-0004d0-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 07:26:02 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1lIv-0004cu-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 07:26:02 -0400 Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00BDF00A@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 7:26:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55757833 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 07:25:59 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 07:25:59 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5500557 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 07:25:59 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030923072023.0203d770@mail.stevecrocker.com> Date: Tue, 23 Sep 2003 07:25:30 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9CB758BBEE58754F8F33234D75B9F4B00A0844@orsmsx410.jf.intel. com> Precedence: list I do not agree that all FEs have this (inter-FE topology information). I have agreed that some FEs may have it. And that having standard FE attributes to represent this is probably useful. I do not agree that there is value in the requirement. It will not help us choose among protocols. It has already demonstrated a drive to cause protocol elements that are not needed. However, I have said enough for a while. The working group nee3ds to decide a) whether to fix the requirement in the I-D b) whether to clarify some other way what is needed / wanted to meet the requirement or whether the group actively likes the requirement. Yours, Joel M. Halpern At 10:50 PM 9/22/2003 -0700, you wrote: >Hi Joel > >I understand your concern regarding the architectural requirement (sec >5, #10) and I think we could clarify the text there, if still >possible...or may be use the Framework draft to clarify this? Lily, any >ideas? >However, I believe that the protocol requirement text is fine and it >should remain. From what I have heard so far, you agree that a) all FEs >have this info, b) some FEs might acquire this thru some inter-FE >discovery protocol or via FE manager and they should not be precluded >from ForCES, c) CE needs this info. If you agree with a, b & c then it >is natural to have some protocol mechanism to support this (whether it >is a general or special mechanism is a separate issue)...unless you want >to have a non-standard way to do this, which defeats the purpose of >ForCES. You have also agreed that it is ok to have some optional >mechanism for this. Now if you were in the Requirements team, which >unfortunately you were not :), would you rather define optional >requirements or mandatory ones ? This has a direct impact on the >protocol design and interoperability. > >Also, I don't remember there having been any arguments or big >discussions around this requirement before atleast in the design team. >The only feeback we had received was from the IESG was to clarify the >text in the Protocol Req section 7, which we did. > >I hope you will understand my point of view. >Thanks a lot >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Saturday, September 20, 2003 5:57 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] Requirements > >A large part of my problem with this requirement is that it leads >sensible >implementors (such as yourself) to think that they need special protocol >mechanisms to support this. It also leads sensible FE implementors to >think that they are somehow required to provide this implementation. > >1) FE's better not be required to provide inter-FE topology information. > >2) Allowing FEs which have such information to provide it does not >require >special protocol mechanisms in any reasonably designed protocol. CEs >will >need to ask FEs for many pieces of FE level information. If we must >have a >requirement in this area at all, it should be a requirement that the set >of >FE information a CE can query should include support for optional >information about inter-FE connectivity. (A CE should not be required >to >ask about this, an FE should not be required to provide this, and it >really >should not be treated as special information requiring special protocol >support mechanisms. > >Another way of looking at this is that there are many kinds of >information >that an FE might be able to provide that might or might not be >communicable >in the initial set of information mandated for CE-FE querying. For lots >of >reasons, the protocol MUST be extensible. Making support of this >information important relative to selecting / defining the protocol >seems a >serious mistake. > >Yours, >Joel M. Halpern > >At 05:35 PM 9/20/2003 -0700, you wrote: > >The text for this requirement has always been inter-FE topology (since > >v-02). > >I am pretty sure but I'll check with Todd anyways on this. > > > >If we do not provide protocol mechanisms to support this, then there > >will > >have to be non-standard ways to obtain this information from the FEs > >which > >provide this info, which we would like to avoid. > > > >Thanks > >Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 10:43:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17248 for ; Tue, 23 Sep 2003 10:43:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1oNo-0000rR-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 10:43:17 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1oNo-0000rH-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 10:43:16 -0400 Received: from grape.ease.lsoft.com (209.119.0.34) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00BE03B4@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 10:43:15 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55768453 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 10:43:13 -0400 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 10:43:09 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h8NEh7wA019583 for ; Tue, 23 Sep 2003 09:43:08 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <9CB758BBEE58754F8F33234D75B9F4B00A0A29@orsmsx410.jf.intel.com> <5.1.0.14.0.20030920205730.022a78e0@mail.stevecrocker.com> <5.1.0.14.0.20030922142127.022fe980@mail.stevecrocker.com> <5.1.0.14.0.20030922195626.0188d8c0@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3F705BFB.AFE5999A@alcatel.com> Date: Tue, 23 Sep 2003 09:43:07 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I think I see where the problem is. Our use of the term "topology" may need to be put in the proper context. A network of routers has a topology to it. We can break this up into cooperating Autonomous Systems (ASs) with each AS consisting of a set of routers controlled by a single administrative authority. Routers withing an AS can run neighbor discovery protocols to determine the topology of the AS. This is inter-router connectivity whithin an AS. The ASs also run discovery protocols (e.g EGP) to discover neighboring ASs. This is inter-AS topology discovery. The ForCEs specification has allowed us to take an NE ( e.g. a router) and distribute its control and forwarding elements over a local area network. One of the driving forces for this is scalability. A resulting benefit is that we can group a set of forwarding elements (in an NE) to cooperate in solving a problem or providing some service. There is a topology involved here. The FEs should know how to forward the packets to the next FE in this cooperating unit to achieve the set goal. This topology is configured, *not* discovered. This is the topology I think the ForCEs requirement is talking about. Regards, Alex. "Joel M. Halpern" wrote: > I am sorry, but I am afraid I am misunderstanding you. > The CE uses the FORCES (Fp) protocol to direct the FE. > It uses the knowledge of the inter-FE topology which it gleans from a > combination of configuration and discovery protocols (of which there are > many). Such discovery protocols are the kinds of things CEs run (they send > the packets out through and receive response from the FE, but the CE has > the protocol machinery. > > While there may be devices where inter-FE topology is controllable, such > control is outside of the scope of FORCES. We are controlling individual > FEs. > [It is possible that there will be LFBs that can be used to assist in such > functions. It is possible that there will be other protocols that are > supported by the CEs or FEs to do such things. However, that is not the > domain of FORCES.] > In contrast, the intra-FE operations are the domain of FORCES. Some folks > actually asked that we leave control of intra-FE topology out of the > work. We have decided that intra-FE topology is within scope. (With the > caveat that not all FEs will support that, and that even FEs which support > reconfigurable intra-FE topology will have restrictions on what can be set up.) > > Other than static configuration (which is highly error prone) there is no > obvious way for FEs to know their inter-FE topology. You suggested earlier > that FEs should have this static configuration rather than CEs. I think it > is more reasonable to put that on the CE, but that is something reasonable > folks can differ on. > > Part of what causes me concern about this protocol requirement is that as > written it has prompted several protocol proposals to include explicit > mechanisms for addressing this "need". I do not object to including in the > set of attributes an FE might have optional attributes about known FE > adjacency. However, > a) that needs to be optional, and the current wording makes it look mandatory > b) it should be worded in a way that does not encourage the creation of > special protocol mechanisms. By this I mean that the wording should be > about the system / solution enabling the transfer of the information, not > about the protocol having the ability to carry it. (And no, that > distinction should not matter. It observably does matter since two > different proposals have fallen into this trap. And at least one responded > that they need to keep the special mechanism to meet the requirements when > I questioned the authors about it.) > > Yours, > Joel M. Halpern > > At 05:02 PM 9/22/2003 -0500, you wrote: > >How would the CE best direct the behavior of FEs if not through topology > >configuration? The control of the inter-FE topology and its consequences > >should not be too different from those of the intra-FE topology. In the > >latter, > >the CE could set the LFBs up in ways to achieve certain behaviors. We could > >take a different tack for inter-FE topology,.. but why? > > > >Regards, > >Alex. > > > >"Joel M. Halpern" wrote: > > > > > I disagree. > > > It is quite likely that the desired behavior depends upon the topology. > > > The CE determines the Topology > > > The CE selects the Desired Behavior > > > The CE teaches (directs) the FE in how to behave. > > > > > > The CE never tells the FE what the topology is, because that does not > > > matter to the FE. What matters to the FE is how it should > > > behave. Provided from the CE. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 11:49 AM 9/22/2003 -0500, you wrote: > > > >Not if the behavior of a group of FEs depends on their connectivity! > > If CE can > > > >configure that behavior, then the CE better be able to teach each FE > > in that > > > >group their connectivity information. > > > > > > > >Regards, > > > >Alex. > > > > > > > >"Joel M. Halpern" wrote: > > > > > > > > > One important aspect here is that the CE need never teach the FE > > about the > > > > > topology between FEs. The FE needs to know which exist to send a > > packet > > > > > out, with what headers. The FE does not care "who" is receiving that > > > > > packet. The CE cares a great deal. > > > > > > > > > > Yours, > > > > > Joel M. Halpern > > > > > > > > > > At 05:47 PM 9/20/2003 -0700, you wrote: > > > > > >Hormuzd, > > > > > > > > > > > >Can you provide an example - maybe that will clarify it for me. > > > > > >Is the information you refer to not available at the CE or what > > > > > >does having it at the FE buy you? Could the CE teach the FE? > > > > > > > > > > > >cheers, > > > > > >jamal > > > > > > > > > > > >On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > > > > > > > > > Jamal, > > > > > > > > > > > > > > The text for this requirement has always been inter-FE topology > > (since > > > > > > > v-02). > > > > > > > I am pretty sure but I'll check with Todd anyways on this. > > > > > > > > > > > > > > If we do not provide protocol mechanisms to support this, then > > there > > > > > > > will > > > > > > > have to be non-standard ways to obtain this information from > > the FEs > > > > > > > which > > > > > > > provide this info, which we would like to avoid. > > > > > > > > > > > > > > Thanks > > > > > > > Hormuzd > > > > > > > -----Original Message----- > > > > > > > From: Forwarding and Control Element Separation > > > > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > > > > > > Sent: Saturday, September 20, 2003 4:57 PM > > > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > > > > > > > > > > Hormuzd, > > > > > > > > > > > > > > Talk to Todd - i think he was the one who added this. And i think > > > > > > > it was meant to imply intra-FE not inter-FE topology. > > > > > > > Either it should be clarified to be intra-FE (which i agree is LFB > > > > > > > specific) or totaly removed. I dont think we should stop anyone > > from > > > > > > > implementing it if they wish but it should not be on a protocol > > check > > > > > > > list. > > > > > > > > > > > > > > cheers, > > > > > > > jamal > > > > > > > > > > > > > > On Sat, 20 Sep 2003, Khosravi, Hormuzd M wrote: > > > > > > > > > > > > > > > The intent of this requirement was not to mandate all FEs to have > > > > this > > > > > > > > information, as is suggested in section 5 # 10, > > > > > > > > but to support protocol mechanisms to obtain this information > > > > from FEs > > > > > > > > if it is available, as is stated in section 7 # 10. > > > > > > > > I agree that the text in section 5 # 10 needs to be modified > > to bring > > > > > > > > out the correct intent, which is stated in section 7 # 10. > > > > > > > > As for the history, this requirement has been around since > > version 02 > > > > > > > of > > > > > > > > the draft back in Feb 2002. > > > > > > > > > > > > > > > > Since the Requirements is already in the RFC queue, I was > > > > wondering if > > > > > > > > it is possible to make any edits at this point > > > > > > > > without causing a lot of delays. Any advise David, Patrick ?? > > > > > > > > > > > > > > > > Thanks > > > > > > > > Hormuzd > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Forwarding and Control Element Separation > > > > > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, > > Ellen M > > > > > > > > Sent: Friday, September 19, 2003 10:39 AM > > > > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > > > > Subject: Re: [FORCES] Requirements > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree with those who have stated the architecture > > requirement in > > > > > > > > section 5, #10 (shown below) puts an unnecessary burden on the > > > > FEs and > > > > > > > > is not required in order to perform topology discovery. I > > also agree > > > > > > > > that other solutions are available that do not require this > > > > > > > > functionality of the FE (e.g. the CE could perform the > > discovery, it > > > > > > > > might be entered manually, some other manager could do the > > > > discovery). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 10) In a ForCES NE, the FEs MUST be able to provide their > > topology > > > > > > > > > > > > > > > > information (topology by which the FEs in the NE are > > > > connected) to > > > > > > > > > > > > > > > > the CE(s). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I suspect based on a protocol requirement #10 (shown below) > > that the > > > > > > > > intent was that some mechanism to report topology information > > > > from the > > > > > > > > FE to the CE must exist. However, nowhere in the document does it > > > > > > > state > > > > > > > > that that FE functionality is optional. I believe that > > clarification > > > > > > > > should be added. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 10)Topology Exchange > > > > > > > > > > > > > > > > The ForCES protocol MUST allow the FEs to provide their > > topology > > > > > > > > > > > > > > > > information (topology by which the FEs in the NE are > > connected) to > > > > > > > > > > > > > > > > the CE(s). (refer to section 5, requirement# 10) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One suggestion is to rewrite requirement #10 in section 5 to be > > > > > > > similar > > > > > > > > to item 10) Topology Exchange and perhaps add the qualifier > > that the > > > > > > > FEs > > > > > > > > are NOT REQUIRED to be able to provide topology information > > to the > > > > > > > CEs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Ellen Deleganes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Tue Sep 23 20:21:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14277 for ; Tue, 23 Sep 2003 20:21:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1xPP-0001CP-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 20:21:32 -0400 Received: from grape.ease.lsoft.com ([209.119.1.39]) by ietf-mx with esmtp (Exim 4.12) id 1A1xPP-0001CL-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 20:21:31 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <5.0038A36E@grape.ease.lsoft.com>; Tue, 23 Sep 2003 20:21:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55814932 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 20:21:31 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 20:21:31 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 1A1xPO-0004t3-5t for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Sep 2003 00:21:30 +0000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Approved-By: Avri Doria Message-ID: <3A8CF0DC-EE24-11D7-81AB-000393CC2112@acm.org> Date: Wed, 24 Sep 2003 09:15:39 +0900 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030923072023.0203d770@mail.stevecrocker.com> Precedence: list Content-Transfer-Encoding: 7bit On tisdag, sep 23, 2003, at 20:25 Asia/Seoul, Joel M. Halpern wrote: > However, I have said enough for a while. The working group nee3ds to > decide > a) whether to fix the requirement in the I-D There are actually two requirements in the ID > 5. Architectural Requirements > > The following are the architectural requirements: ... > > 10) In a ForCES NE, the FEs MUST be able to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). > and > 7. ForCES Protocol Requirements > 10)Topology Exchange > The ForCES protocol MUST allow the FEs to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). (refer to section 5, requirement# 10) So far, I have mostly been arguing about the second item, the protocol requirement. I don't believe it needs to be fixed. Though i would not disagree with a should instead of a MUST. Though i am not sure there is effectively any real difference in an informational draft. (RFC2119 language does not really pertain to Informational requirements except in so far as the WG continues to support that language and its intent.) I still think that any ForCES protocol should support the ability to report information about the inter-fe topology, especially if it was configured via a management interface to have this information. On the other hand, the architectural requirement is probably more of an issue. While I do think that the FE should have the information about its connectivity to other FEs, I can see how this might not always be possible unless an inter-FE discovery protocol where to be used. Again I am not sure what the force of an architectural requirement is, though I am sure that defining an inter-FE discovery protocol, while perhaps a good idea, is not in the charter for this group at this time. So this may be a moot point, i.e it may not really matter what it says, except perhaps as an incentive to people to think about the problems and ways to engineer solutions to them. > b) whether to clarify some other way what is needed / wanted to meet > the > requirement I am fine with leaving it as is, but as i mentioned have not objection to bumping the protocol requirement down to a lowercase should. > or whether the group actively likes the requirement. > > I believe that the architectural requirements is functionality that a fully capable FE should have, and that ForCES protocol should have the ability to convey that information. So, to answer the question, I actively like the requirement. a. From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 21:06:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15713 for ; Tue, 23 Sep 2003 21:06:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1y6k-0001gx-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 21:06:18 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1y6j-0001gu-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 21:06:18 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00BE26F1@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 21:06:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55817832 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 21:06:15 -0400 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 21:06:15 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8O11Ld14590 for ; Wed, 24 Sep 2003 01:01:21 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.py.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8O15mO20124 for ; Wed, 24 Sep 2003 01:05:48 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092318061326255 for ; Tue, 23 Sep 2003 18:06:13 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 23 Sep 2003 18:06:13 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: framework change in light of discussion on FE-topology Thread-Index: AcOCOAxHzGswHZatQQCGp2ljBvcrnA== X-OriginalArrivalTime: 24 Sep 2003 01:06:13.0733 (UTC) FILETIME=[0C944950:01C38238] Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FEFA@orsmsx410.jf.intel.com> Date: Tue, 23 Sep 2003 18:06:13 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: framework change in light of discussion on FE-topology To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi,=20 In light of the recent discussion on FE-topology, I suggest the = following change in framework draft to better clarify the issue. End of Section 3.2 "Forwarding Elements and Fi reference point" [old] When it is necessary to forward packets between FEs, the CE needs to = understand the FE topology. The FE topology can be queried from the FEs = by CEs.=20 [new] When it is necessary to forward packets between FEs, the CE needs to = understand the FE topology. The FE topology may be queried from the FEs = by the CEs via ForCES protocol, but all the FEs are not required to = provide that information to the CEs. So the FE topology information may = also be gathered by other means outside of the ForCES protocol (like = inter-FE topology discovery protocol).=20 Does it reflect the consensus in the WG? Lily From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 21:12:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15854 for ; Tue, 23 Sep 2003 21:12:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yCd-0001k0-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 21:12:23 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1yCc-0001jx-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 21:12:22 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00BE2855@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 21:12:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55818904 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 21:12:22 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 21:12:22 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8O1A0v25154 for ; Wed, 24 Sep 2003 01:10:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8O16xs13085 for ; Wed, 24 Sep 2003 01:06:59 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092318122007956 for ; Tue, 23 Sep 2003 18:12:20 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 23 Sep 2003 18:12:20 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Requirements Thread-Index: AcOBxXqtwLZLy0eyRMmvsOPRoYFv/wATFphAAAmWwZA= X-OriginalArrivalTime: 24 Sep 2003 01:12:20.0532 (UTC) FILETIME=[E7355F40:01C38238] Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FEFB@orsmsx410.jf.intel.com> Date: Tue, 23 Sep 2003 18:12:20 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: FW: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Our mail server has been acting very badly lately -- I didn't see this = email posted to the list even after 4 hours and so here it is again -- I = believe what I said here basically concurs with Avri and Ellen.=20 -----Original Message----- From: Yang, Lily L=20 Sent: Tuesday, September 23, 2003 1:52 PM To: 'Forwarding and Control Element Separation' Subject: RE: Requirements Joel -- Sorry to ping you again when you are already tired of talking = :-) When you said, "a) whether to fix the requirement in the I-D", did you = mean the architectural requirement (section 5, #10) or the protocol = requirement (section 7, #10), or both? I do believe there is different = implications here depending on which one you were talking about. What I heard so far on this thread is that some FEs may have inter-FE = topology info but all FEs do not. So the protocol MUST support "inter-FE = topology query/reply" in case some FEs are capable of providing that = info to CE. Architecturally, it is optional whether or not to use such = protocol mechanism -- as long as somehow CE can gather this infomation, = either by explicitly query over ForCES protocol, or by static = configuration, or by some dynamic discovery mechanism outside of ForCES. = So I think a simple "inter-FE topology query/reply" is indeed required = in the ForCES protocol. But if FE can't provide that info, the burden is = on CE to gather that info by other means.=20 I would like to see some consensus on this so that I can make sure the = framework draft accurately reflects it. Lily > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > Sent: Tuesday, September 23, 2003 4:26 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Requirements >=20 >=20 > I do not agree that all FEs have this (inter-FE topology=20 > information). I > have agreed that some FEs may have it. And that having standard FE > attributes to represent this is probably useful. > I do not agree that there is value in the requirement. It=20 > will not help us > choose among protocols. It has already demonstrated a drive to cause > protocol elements that are not needed. >=20 > However, I have said enough for a while. The working group=20 > nee3ds to decide > a) whether to fix the requirement in the I-D > b) whether to clarify some other way what is needed / wanted=20 > to meet the > requirement > or whether the group actively likes the requirement. >=20 > Yours, > Joel M. Halpern >=20 > At 10:50 PM 9/22/2003 -0700, you wrote: > >Hi Joel > > > >I understand your concern regarding the architectural=20 > requirement (sec > >5, #10) and I think we could clarify the text there, if still > >possible...or may be use the Framework draft to clarify=20 > this? Lily, any > >ideas? > >However, I believe that the protocol requirement text is fine and it > >should remain. From what I have heard so far, you agree that=20 > a) all FEs > >have this info, b) some FEs might acquire this thru some inter-FE > >discovery protocol or via FE manager and they should not be precluded > >from ForCES, c) CE needs this info. If you agree with a, b &=20 > c then it > >is natural to have some protocol mechanism to support this=20 > (whether it > >is a general or special mechanism is a separate=20 > issue)...unless you want > >to have a non-standard way to do this, which defeats the purpose of > >ForCES. You have also agreed that it is ok to have some optional > >mechanism for this. Now if you were in the Requirements team, which > >unfortunately you were not :), would you rather define optional > >requirements or mandatory ones ? This has a direct impact on the > >protocol design and interoperability. > > > >Also, I don't remember there having been any arguments or big > >discussions around this requirement before atleast in the=20 > design team. > >The only feeback we had received was from the IESG was to clarify the > >text in the Protocol Req section 7, which we did. > > > >I hope you will understand my point of view. > >Thanks a lot > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Saturday, September 20, 2003 5:57 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] Requirements > > > >A large part of my problem with this requirement is that it leads > >sensible > >implementors (such as yourself) to think that they need=20 > special protocol > >mechanisms to support this. It also leads sensible FE=20 > implementors to > >think that they are somehow required to provide this implementation. > > > >1) FE's better not be required to provide inter-FE topology=20 > information. > > > >2) Allowing FEs which have such information to provide it does not > >require > >special protocol mechanisms in any reasonably designed protocol. CEs > >will > >need to ask FEs for many pieces of FE level information. If we must > >have a > >requirement in this area at all, it should be a requirement=20 > that the set > >of > >FE information a CE can query should include support for optional > >information about inter-FE connectivity. (A CE should not=20 > be required > >to > >ask about this, an FE should not be required to provide this, and it > >really > >should not be treated as special information requiring=20 > special protocol > >support mechanisms. > > > >Another way of looking at this is that there are many kinds of > >information > >that an FE might be able to provide that might or might not be > >communicable > >in the initial set of information mandated for CE-FE=20 > querying. For lots > >of > >reasons, the protocol MUST be extensible. Making support of this > >information important relative to selecting / defining the protocol > >seems a > >serious mistake. > > > >Yours, > >Joel M. Halpern > > > >At 05:35 PM 9/20/2003 -0700, you wrote: > > >The text for this requirement has always been inter-FE=20 > topology (since > > >v-02). > > >I am pretty sure but I'll check with Todd anyways on this. > > > > > >If we do not provide protocol mechanisms to support this,=20 > then there > > >will > > >have to be non-standard ways to obtain this information=20 > from the FEs > > >which > > >provide this info, which we would like to avoid. > > > > > >Thanks > > >Hormuzd >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 21:23:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16572 for ; Tue, 23 Sep 2003 21:23:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yN4-000201-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 21:23:10 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1yN3-0001zy-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 21:23:09 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00BE27B5@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 21:23:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55819264 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 21:23:06 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 21:23:06 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8O1KEv29653 for ; Wed, 24 Sep 2003 01:20:14 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8O1HDs18263 for ; Wed, 24 Sep 2003 01:17:13 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092318223521390 for ; Tue, 23 Sep 2003 18:22:35 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 23 Sep 2003 18:22:35 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: propose change to address multicast security issue Thread-Index: AcN7kbh6tOxEyyDFSjWcnXOIxC+6vAGp+KiQ X-OriginalArrivalTime: 24 Sep 2003 01:22:35.0143 (UTC) FILETIME=[558B9170:01C3823A] Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FEFC@orsmsx410.jf.intel.com> Date: Tue, 23 Sep 2003 18:22:34 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: propose change to address multicast security issue To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Jamal --=20 Since the real issue is going to be addressed else where (i.e., = protocol) anyway, I don't want us to hold up the framework draft too = long unless there is sth fundamentally incorrect here. This is what I = suggest in the security section regarding multicast and IPsec, I hope = you would agree that it is objective enough :-) "IPsec can support both unicast and multicast transport. At the time = this document was published, MSEC working group is actively working on = standardizing protocols to provide multicast security [17]. = Multicast-based solutions relying on IPsec should specify how to meet = the security requirements in [3]. " Lily > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim > Sent: Monday, September 15, 2003 7:00 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: propose change to address multicast security issue >=20 >=20 > Lilly, >=20 > I am not sure if i responded on this or not; if not i apologize > too swamped at work. > Heres the best alternative IMO; i am crossposting this to the msec > wg mailing list (also CCing the WG chairs in case the mailing list is > closed). To the folks in MSEC we need your help to come up with good > wording in regards to Multicast and security. To break it down, the > 4 options that have to be met are: >=20 > 1. No security - this is pretty obvious, so dont address this. > 2. Data integrity - signatures etc. > 3. Data authentication - encryption > 4. Both integrity and authentication >=20 > I have read some of the MSEC drafts which are on the last call. From > what i read, 2-4 above are requirements that can be met for multicast > using IPSEC. > The only open issue seems to be that of source-authentication which is > still a "work-in-progress" in the form of the TESLA protocol. >=20 > I have been challenged that if you use both IPsec and=20 > Multicast then it > can only be done with no replay protection and no automatic rekeying. > My reading of those drafts leads me to believe this is based on old > data. > So the MSEC folks, can you please help us with the above given > the status quo or soon tobe status quo? > Secondly, what is the status of your different soon-to-be RFCs? > What is the scope of your new recharter? >=20 > cheers, > jamal >=20 > On Fri, 2003-08-29 at 14:39, Yang, Lily L wrote: > > Hi, Jamal -- > > > > I don't think I am making any specific assumptions here. I=20 > am merely ducumenting the fact that IPsec itself may not be=20 > sufficient and MSEC WG is looking at the issues. I do intend=20 > to leave all the details to the protocol discussion. > > > > I am glad that you brought this important issue to our=20 > attention at the first place. So it just puzzles me why we=20 > shouldn't at least capture this high level issue in the=20 > framework so that protocol designers are aware of it. > > > > Lily > > > > > --Original Message-- > > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > Sent: Thursday, August 28, 2003 9:40 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: Re: propose change to address multicast security issue > > > > > > > > > Lily, > > > > > > Unless you are making assumptions about how multicast is to be > > > used with IPSEC in a Forces protocol, you shouldnt be pointing > > > out issues with "multicast and IPSEC"; just as you shouldnt > > > be worrying > > > about TLS and its unfitness in some unicast protocol=20 > usage. Leave that > > > to the protocol discussion. > > > > > > cheers, > > > jamal > > > > > > PS: MSEC IETF group completed its chartered work and was=20 > shutdown. So > > > all those docs are awaiting IESG approval to go RFC.=20 > Theres a recent > > > activity to recharter MSEC. > > > > > > On Thu, 2003-08-28 at 12:26, Yang, Lily L wrote: > > > > Hi, Jamal -- > > > > But I believe it is also very important to point > > > > out the fact that IPsec itself does not fully address > > > > multicast security issues (that is exactly why there is MSEC > > > > group working on these issues). So it is simply not sufficient > > > > to just say "use IPsec for multicast". > > > > > > > > Lily > > > > > > > > > --Original Message-- > > > > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > > > Sent: Thursday, August 28, 2003 4:09 AM > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > Subject: Re: propose change to address multicast=20 > security issue > > > > > > > > > > > > > > > Hi Lilly, > > > > > > > > > > Sorry - meant to respond to your earlier yesterday, but work > > > > > comes first. > > > > > > > > > > The text i see fit is: > > > > > "While TLS supports only unicast, IPsec can support both > > > unicast and > > > > > multicast transports." > > > > > > > > > > Lets leave the rest of the discussion to protocol time. > > > > > > > > > > cheers, > > > > > jamal > > > > > > > > > > On Wed, 27 Aug 2003, Yang, Lily L wrote: > > > > > > > > > > > To address the issue over multicast security, I propose the > > > > > following changes to framework section 7.2.3: > > > > > > > > > > > > [old 3rd paragraph] > > > > > > "IPsec can support both unicast and multicast=20 > transport. When > > > > > > multicast is used, IPsec can be used with manual > > > keying with no > > > > > > replay protection and no automatic rekeying. This > > > meets the > > > > > > confidentiality and integrity requirements. =20 > Multicast-based > > > > > > solutions relying on IPsec should specify how rekeying > > > > > and replay > > > > > > protection are provided. " > > > > > > > > > > > > [ new text ] > > > > > > "IPsec can support both unicast and multicast transport. > > > > > However, RFC 2401 [14] acknowledged that it did not specify > > > > > complete support for IP multicast. At the time this document > > > > > was published, MSEC working group is actively working on > > > > > standardizing protocols to provide multicast security [17]. > > > > > Multicast-based solutions relying on IPsec should specify how > > > > > to meet the security requirements in [3]. " > > > > > > > > > > > > Adding the following to Section 9: Informative References: > > > > > > [17] Hardjono, T. and Weis, B. "The Multicast Security > > > > > Architecture", work in progress, August 2003, > > > > > . > > > > > > > > > > > > I would like the two of you and the WG review this. If > > > > > satisfactory, I would roll all the recent changes per > > > > > discussion on the list into v09 and ask for IESG review on it. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Lily > > > > > > > > > > > > > > >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 21:54:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18184 for ; Tue, 23 Sep 2003 21:54:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yrb-0002Vf-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 21:54:43 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1yra-0002Vc-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 21:54:42 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00BE2812@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 21:54:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55821884 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 21:54:25 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 21:54:25 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5510465 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 21:54:24 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030923215110.022bc5e8@mail.stevecrocker.com> Date: Tue, 23 Sep 2003 21:54:03 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: FW: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D2714FEFB@orsmsx410.jf.intel. com> Precedence: list Actually, this implication is what concerns me. There must be a mechanism for the CE to query FE attributes. I would sincerely hope that such attributes would be extensible. It would seem sensible that one portion of those attributes could and would be used to reflect whatever knowledge about inter-FE topology the FE had. Thus, the information would be accessible. But there would not be a inter-FE topology query/reply in the protocol. The protocol would have FE attribute query / reply, which would cover many cases. Yours, Joel M. Halpern PS: I like your proposed rewording of the framework text. PPS: I truly am sorry to raise this so late. It wasn't until reviewing protocol proposals that I realized the implication of the requirements text. At 06:12 PM 9/23/2003 -0700, you wrote: >Our mail server has been acting very badly lately -- I didn't see this >email posted to the list even after 4 hours and so here it is again -- I >believe what I said here basically concurs with Avri and Ellen. > >-----Original Message----- >From: Yang, Lily L >Sent: Tuesday, September 23, 2003 1:52 PM >To: 'Forwarding and Control Element Separation' >Subject: RE: Requirements > > >Joel -- Sorry to ping you again when you are already tired of talking :-) > >When you said, "a) whether to fix the requirement in the I-D", did you >mean the architectural requirement (section 5, #10) or the protocol >requirement (section 7, #10), or both? I do believe there is different >implications here depending on which one you were talking about. > >What I heard so far on this thread is that some FEs may have inter-FE >topology info but all FEs do not. So the protocol MUST support "inter-FE >topology query/reply" in case some FEs are capable of providing that info >to CE. Architecturally, it is optional whether or not to use such protocol >mechanism -- as long as somehow CE can gather this infomation, either by >explicitly query over ForCES protocol, or by static configuration, or by >some dynamic discovery mechanism outside of ForCES. > >So I think a simple "inter-FE topology query/reply" is indeed required in >the ForCES protocol. But if FE can't provide that info, the burden is on >CE to gather that info by other means. > >I would like to see some consensus on this so that I can make sure the >framework draft accurately reflects it. > >Lily > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > > Sent: Tuesday, September 23, 2003 4:26 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: Requirements > > > > > > I do not agree that all FEs have this (inter-FE topology > > information). I > > have agreed that some FEs may have it. And that having standard FE > > attributes to represent this is probably useful. > > I do not agree that there is value in the requirement. It > > will not help us > > choose among protocols. It has already demonstrated a drive to cause > > protocol elements that are not needed. > > > > However, I have said enough for a while. The working group > > nee3ds to decide > > a) whether to fix the requirement in the I-D > > b) whether to clarify some other way what is needed / wanted > > to meet the > > requirement > > or whether the group actively likes the requirement. > > > > Yours, > > Joel M. Halpern > > > > At 10:50 PM 9/22/2003 -0700, you wrote: > > >Hi Joel > > > > > >I understand your concern regarding the architectural > > requirement (sec > > >5, #10) and I think we could clarify the text there, if still > > >possible...or may be use the Framework draft to clarify > > this? Lily, any > > >ideas? > > >However, I believe that the protocol requirement text is fine and it > > >should remain. From what I have heard so far, you agree that > > a) all FEs > > >have this info, b) some FEs might acquire this thru some inter-FE > > >discovery protocol or via FE manager and they should not be precluded > > >from ForCES, c) CE needs this info. If you agree with a, b & > > c then it > > >is natural to have some protocol mechanism to support this > > (whether it > > >is a general or special mechanism is a separate > > issue)...unless you want > > >to have a non-standard way to do this, which defeats the purpose of > > >ForCES. You have also agreed that it is ok to have some optional > > >mechanism for this. Now if you were in the Requirements team, which > > >unfortunately you were not :), would you rather define optional > > >requirements or mandatory ones ? This has a direct impact on the > > >protocol design and interoperability. > > > > > >Also, I don't remember there having been any arguments or big > > >discussions around this requirement before atleast in the > > design team. > > >The only feeback we had received was from the IESG was to clarify the > > >text in the Protocol Req section 7, which we did. > > > > > >I hope you will understand my point of view. > > >Thanks a lot > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > > >Sent: Saturday, September 20, 2003 5:57 PM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] Requirements > > > > > >A large part of my problem with this requirement is that it leads > > >sensible > > >implementors (such as yourself) to think that they need > > special protocol > > >mechanisms to support this. It also leads sensible FE > > implementors to > > >think that they are somehow required to provide this implementation. > > > > > >1) FE's better not be required to provide inter-FE topology > > information. > > > > > >2) Allowing FEs which have such information to provide it does not > > >require > > >special protocol mechanisms in any reasonably designed protocol. CEs > > >will > > >need to ask FEs for many pieces of FE level information. If we must > > >have a > > >requirement in this area at all, it should be a requirement > > that the set > > >of > > >FE information a CE can query should include support for optional > > >information about inter-FE connectivity. (A CE should not > > be required > > >to > > >ask about this, an FE should not be required to provide this, and it > > >really > > >should not be treated as special information requiring > > special protocol > > >support mechanisms. > > > > > >Another way of looking at this is that there are many kinds of > > >information > > >that an FE might be able to provide that might or might not be > > >communicable > > >in the initial set of information mandated for CE-FE > > querying. For lots > > >of > > >reasons, the protocol MUST be extensible. Making support of this > > >information important relative to selecting / defining the protocol > > >seems a > > >serious mistake. > > > > > >Yours, > > >Joel M. Halpern > > > > > >At 05:35 PM 9/20/2003 -0700, you wrote: > > > >The text for this requirement has always been inter-FE > > topology (since > > > >v-02). > > > >I am pretty sure but I'll check with Todd anyways on this. > > > > > > > >If we do not provide protocol mechanisms to support this, > > then there > > > >will > > > >have to be non-standard ways to obtain this information > > from the FEs > > > >which > > > >provide this info, which we would like to avoid. > > > > > > > >Thanks > > > >Hormuzd > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 22:15:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18781 for ; Tue, 23 Sep 2003 22:15:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zBl-0002j4-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 22:15:33 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1zBh-0002j1-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 22:15:31 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00BE287E@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 22:15:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55824647 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 22:15:29 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 22:14:25 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8O2C1v15900 for ; Wed, 24 Sep 2003 02:12:01 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8O290s08763 for ; Wed, 24 Sep 2003 02:09:00 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092319142211012 for ; Tue, 23 Sep 2003 19:14:22 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 23 Sep 2003 19:14:21 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: FW: Requirements Thread-Index: AcOCPtZSI+xbPdwvQJS0JVGME8vz0QAAIYsw X-OriginalArrivalTime: 24 Sep 2003 02:14:21.0931 (UTC) FILETIME=[9155CBB0:01C38241] Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FEFD@orsmsx410.jf.intel.com> Date: Tue, 23 Sep 2003 19:14:21 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: FW: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Joel --=20 But I thought we agree (at least within the FE model design team, from = our previous conference calls) that FE-topology is outside of the FE = model, and so inter-FE topology info is not going to be part of the FE = attributes as we define today. Therefore, explicit topology query/reply = must be provided by the base protocol itself, because you aren't going = to get that directly from FE model. Now, having said that, I agree with you that IF some specialized LFB is = chartered with some kind of discovery function, then the FE topology = info can be indirectly but effectively gathered by querying the = attributes of such LFB -- but that is a big "IF" and is only one of the = many possible approaches. So to cover the case when some FEs indeed have such topology info with = them, a simple topology query/reply will do the work. Oh, you don't need to apologize -- the most probable outcome of a = "draft" design is -- Oops, it doesn't work! Always better know that = today than tomorrow though.=20 Lily=20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > Sent: Tuesday, September 23, 2003 6:54 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: FW: Requirements >=20 >=20 > Actually, this implication is what concerns me. >=20 > There must be a mechanism for the CE to query FE attributes. > I would sincerely hope that such attributes would be extensible. > It would seem sensible that one portion of those attributes=20 > could and would > be used to reflect whatever knowledge about inter-FE topology=20 > the FE had. > Thus, the information would be accessible. > But there would not be a inter-FE topology query/reply in the=20 > protocol. > The protocol would have FE attribute query / reply, which=20 > would cover many > cases. >=20 > Yours, > Joel M. Halpern >=20 > PS: I like your proposed rewording of the framework text. >=20 > PPS: I truly am sorry to raise this so late. It wasn't until=20 > reviewing > protocol proposals that I realized the implication of the=20 > requirements text. >=20 > At 06:12 PM 9/23/2003 -0700, you wrote: > >Our mail server has been acting very badly lately -- I=20 > didn't see this > >email posted to the list even after 4 hours and so here it=20 > is again -- I > >believe what I said here basically concurs with Avri and Ellen. > > > >-----Original Message----- > >From: Yang, Lily L > >Sent: Tuesday, September 23, 2003 1:52 PM > >To: 'Forwarding and Control Element Separation' > >Subject: RE: Requirements > > > > > >Joel -- Sorry to ping you again when you are already tired=20 > of talking :-) > > > >When you said, "a) whether to fix the requirement in the=20 > I-D", did you > >mean the architectural requirement (section 5, #10) or the protocol > >requirement (section 7, #10), or both? I do believe there=20 > is different > >implications here depending on which one you were talking about. > > > >What I heard so far on this thread is that some FEs may have inter-FE > >topology info but all FEs do not. So the protocol MUST=20 > support "inter-FE > >topology query/reply" in case some FEs are capable of=20 > providing that info > >to CE. Architecturally, it is optional whether or not to use=20 > such protocol > >mechanism -- as long as somehow CE can gather this=20 > infomation, either by > >explicitly query over ForCES protocol, or by static=20 > configuration, or by > >some dynamic discovery mechanism outside of ForCES. > > > >So I think a simple "inter-FE topology query/reply" is=20 > indeed required in > >the ForCES protocol. But if FE can't provide that info, the=20 > burden is on > >CE to gather that info by other means. > > > >I would like to see some consensus on this so that I can=20 > make sure the > >framework draft accurately reflects it. > > > >Lily > > > > > -----Original Message----- > > > From: Forwarding and Control Element Separation > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > > > Sent: Tuesday, September 23, 2003 4:26 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: Re: Requirements > > > > > > > > > I do not agree that all FEs have this (inter-FE topology > > > information). I > > > have agreed that some FEs may have it. And that having=20 > standard FE > > > attributes to represent this is probably useful. > > > I do not agree that there is value in the requirement. It > > > will not help us > > > choose among protocols. It has already demonstrated a=20 > drive to cause > > > protocol elements that are not needed. > > > > > > However, I have said enough for a while. The working group > > > nee3ds to decide > > > a) whether to fix the requirement in the I-D > > > b) whether to clarify some other way what is needed / wanted > > > to meet the > > > requirement > > > or whether the group actively likes the requirement. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 10:50 PM 9/22/2003 -0700, you wrote: > > > >Hi Joel > > > > > > > >I understand your concern regarding the architectural > > > requirement (sec > > > >5, #10) and I think we could clarify the text there, if still > > > >possible...or may be use the Framework draft to clarify > > > this? Lily, any > > > >ideas? > > > >However, I believe that the protocol requirement text is=20 > fine and it > > > >should remain. From what I have heard so far, you agree that > > > a) all FEs > > > >have this info, b) some FEs might acquire this thru some inter-FE > > > >discovery protocol or via FE manager and they should not=20 > be precluded > > > >from ForCES, c) CE needs this info. If you agree with a, b & > > > c then it > > > >is natural to have some protocol mechanism to support this > > > (whether it > > > >is a general or special mechanism is a separate > > > issue)...unless you want > > > >to have a non-standard way to do this, which defeats the=20 > purpose of > > > >ForCES. You have also agreed that it is ok to have some optional > > > >mechanism for this. Now if you were in the Requirements=20 > team, which > > > >unfortunately you were not :), would you rather define optional > > > >requirements or mandatory ones ? This has a direct impact on the > > > >protocol design and interoperability. > > > > > > > >Also, I don't remember there having been any arguments or big > > > >discussions around this requirement before atleast in the > > > design team. > > > >The only feeback we had received was from the IESG was=20 > to clarify the > > > >text in the Protocol Req section 7, which we did. > > > > > > > >I hope you will understand my point of view. > > > >Thanks a lot > > > >Hormuzd > > > > > > > >-----Original Message----- > > > >From: Forwarding and Control Element Separation > > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > > > >Sent: Saturday, September 20, 2003 5:57 PM > > > >To: FORCES@PEACH.EASE.LSOFT.COM > > > >Subject: Re: [FORCES] Requirements > > > > > > > >A large part of my problem with this requirement is that it leads > > > >sensible > > > >implementors (such as yourself) to think that they need > > > special protocol > > > >mechanisms to support this. It also leads sensible FE > > > implementors to > > > >think that they are somehow required to provide this=20 > implementation. > > > > > > > >1) FE's better not be required to provide inter-FE topology > > > information. > > > > > > > >2) Allowing FEs which have such information to provide=20 > it does not > > > >require > > > >special protocol mechanisms in any reasonably designed=20 > protocol. CEs > > > >will > > > >need to ask FEs for many pieces of FE level information.=20 > If we must > > > >have a > > > >requirement in this area at all, it should be a requirement > > > that the set > > > >of > > > >FE information a CE can query should include support for optional > > > >information about inter-FE connectivity. (A CE should not > > > be required > > > >to > > > >ask about this, an FE should not be required to provide=20 > this, and it > > > >really > > > >should not be treated as special information requiring > > > special protocol > > > >support mechanisms. > > > > > > > >Another way of looking at this is that there are many kinds of > > > >information > > > >that an FE might be able to provide that might or might not be > > > >communicable > > > >in the initial set of information mandated for CE-FE > > > querying. For lots > > > >of > > > >reasons, the protocol MUST be extensible. Making support of this > > > >information important relative to selecting / defining=20 > the protocol > > > >seems a > > > >serious mistake. > > > > > > > >Yours, > > > >Joel M. Halpern > > > > > > > >At 05:35 PM 9/20/2003 -0700, you wrote: > > > > >The text for this requirement has always been inter-FE > > > topology (since > > > > >v-02). > > > > >I am pretty sure but I'll check with Todd anyways on this. > > > > > > > > > >If we do not provide protocol mechanisms to support this, > > > then there > > > > >will > > > > >have to be non-standard ways to obtain this information > > > from the FEs > > > > >which > > > > >provide this info, which we would like to avoid. > > > > > > > > > >Thanks > > > > >Hormuzd > > > >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 22:31:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19447 for ; Tue, 23 Sep 2003 22:31:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zQq-0002xZ-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 22:31:08 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1zQp-0002xW-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 22:31:07 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00BE2981@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 22:31:08 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55825192 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 22:31:07 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 22:31:07 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5510509 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 22:31:06 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030923222759.02212540@mail.stevecrocker.com> Date: Tue, 23 Sep 2003 22:30:44 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: FW: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D2714FEFD@orsmsx410.jf.intel. com> Precedence: list I would tend to treat the entire issue of inter-FE topology as out of scope for the initial FORCES work. I would expect CEs to either be configured with the topology information, or to run any one of the many topology discovery protocols. This led me to consider it to be out of scope for the model. However, folks want some information about inter-FE topology to be within scope for FORCES. If so, I would place it as FE attributes. Yours, Joel M. Halpern At 07:14 PM 9/23/2003 -0700, you wrote: >Joel -- >But I thought we agree (at least within the FE model design team, from our >previous conference calls) that FE-topology is outside of the FE model, >and so inter-FE topology info is not going to be part of the FE attributes >as we define today. Therefore, explicit topology query/reply must be >provided by the base protocol itself, because you aren't going to get that >directly from FE model. >Now, having said that, I agree with you that IF some specialized LFB is >chartered with some kind of discovery function, then the FE topology info >can be indirectly but effectively gathered by querying the attributes of >such LFB -- but that is a big "IF" and is only one of the many possible >approaches. >So to cover the case when some FEs indeed have such topology info with >them, a simple topology query/reply will do the work. > >Oh, you don't need to apologize -- the most probable outcome of a "draft" >design is -- Oops, it doesn't work! Always better know that today than >tomorrow though. > >Lily > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > > Sent: Tuesday, September 23, 2003 6:54 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: FW: Requirements > > > > > > Actually, this implication is what concerns me. > > > > There must be a mechanism for the CE to query FE attributes. > > I would sincerely hope that such attributes would be extensible. > > It would seem sensible that one portion of those attributes > > could and would > > be used to reflect whatever knowledge about inter-FE topology > > the FE had. > > Thus, the information would be accessible. > > But there would not be a inter-FE topology query/reply in the > > protocol. > > The protocol would have FE attribute query / reply, which > > would cover many > > cases. > > > > Yours, > > Joel M. Halpern > > > > PS: I like your proposed rewording of the framework text. > > > > PPS: I truly am sorry to raise this so late. It wasn't until > > reviewing > > protocol proposals that I realized the implication of the > > requirements text. > > > > At 06:12 PM 9/23/2003 -0700, you wrote: > > >Our mail server has been acting very badly lately -- I > > didn't see this > > >email posted to the list even after 4 hours and so here it > > is again -- I > > >believe what I said here basically concurs with Avri and Ellen. > > > > > >-----Original Message----- > > >From: Yang, Lily L > > >Sent: Tuesday, September 23, 2003 1:52 PM > > >To: 'Forwarding and Control Element Separation' > > >Subject: RE: Requirements > > > > > > > > >Joel -- Sorry to ping you again when you are already tired > > of talking :-) > > > > > >When you said, "a) whether to fix the requirement in the > > I-D", did you > > >mean the architectural requirement (section 5, #10) or the protocol > > >requirement (section 7, #10), or both? I do believe there > > is different > > >implications here depending on which one you were talking about. > > > > > >What I heard so far on this thread is that some FEs may have inter-FE > > >topology info but all FEs do not. So the protocol MUST > > support "inter-FE > > >topology query/reply" in case some FEs are capable of > > providing that info > > >to CE. Architecturally, it is optional whether or not to use > > such protocol > > >mechanism -- as long as somehow CE can gather this > > infomation, either by > > >explicitly query over ForCES protocol, or by static > > configuration, or by > > >some dynamic discovery mechanism outside of ForCES. > > > > > >So I think a simple "inter-FE topology query/reply" is > > indeed required in > > >the ForCES protocol. But if FE can't provide that info, the > > burden is on > > >CE to gather that info by other means. > > > > > >I would like to see some consensus on this so that I can > > make sure the > > >framework draft accurately reflects it. > > > > > >Lily > > > > > > > -----Original Message----- > > > > From: Forwarding and Control Element Separation > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > > > > Sent: Tuesday, September 23, 2003 4:26 AM > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > Subject: Re: Requirements > > > > > > > > > > > > I do not agree that all FEs have this (inter-FE topology > > > > information). I > > > > have agreed that some FEs may have it. And that having > > standard FE > > > > attributes to represent this is probably useful. > > > > I do not agree that there is value in the requirement. It > > > > will not help us > > > > choose among protocols. It has already demonstrated a > > drive to cause > > > > protocol elements that are not needed. > > > > > > > > However, I have said enough for a while. The working group > > > > nee3ds to decide > > > > a) whether to fix the requirement in the I-D > > > > b) whether to clarify some other way what is needed / wanted > > > > to meet the > > > > requirement > > > > or whether the group actively likes the requirement. > > > > > > > > Yours, > > > > Joel M. Halpern > > > > > > > > At 10:50 PM 9/22/2003 -0700, you wrote: > > > > >Hi Joel > > > > > > > > > >I understand your concern regarding the architectural > > > > requirement (sec > > > > >5, #10) and I think we could clarify the text there, if still > > > > >possible...or may be use the Framework draft to clarify > > > > this? Lily, any > > > > >ideas? > > > > >However, I believe that the protocol requirement text is > > fine and it > > > > >should remain. From what I have heard so far, you agree that > > > > a) all FEs > > > > >have this info, b) some FEs might acquire this thru some inter-FE > > > > >discovery protocol or via FE manager and they should not > > be precluded > > > > >from ForCES, c) CE needs this info. If you agree with a, b & > > > > c then it > > > > >is natural to have some protocol mechanism to support this > > > > (whether it > > > > >is a general or special mechanism is a separate > > > > issue)...unless you want > > > > >to have a non-standard way to do this, which defeats the > > purpose of > > > > >ForCES. You have also agreed that it is ok to have some optional > > > > >mechanism for this. Now if you were in the Requirements > > team, which > > > > >unfortunately you were not :), would you rather define optional > > > > >requirements or mandatory ones ? This has a direct impact on the > > > > >protocol design and interoperability. > > > > > > > > > >Also, I don't remember there having been any arguments or big > > > > >discussions around this requirement before atleast in the > > > > design team. > > > > >The only feeback we had received was from the IESG was > > to clarify the > > > > >text in the Protocol Req section 7, which we did. > > > > > > > > > >I hope you will understand my point of view. > > > > >Thanks a lot > > > > >Hormuzd > > > > > > > > > >-----Original Message----- > > > > >From: Forwarding and Control Element Separation > > > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > > > > >Sent: Saturday, September 20, 2003 5:57 PM > > > > >To: FORCES@PEACH.EASE.LSOFT.COM > > > > >Subject: Re: [FORCES] Requirements > > > > > > > > > >A large part of my problem with this requirement is that it leads > > > > >sensible > > > > >implementors (such as yourself) to think that they need > > > > special protocol > > > > >mechanisms to support this. It also leads sensible FE > > > > implementors to > > > > >think that they are somehow required to provide this > > implementation. > > > > > > > > > >1) FE's better not be required to provide inter-FE topology > > > > information. > > > > > > > > > >2) Allowing FEs which have such information to provide > > it does not > > > > >require > > > > >special protocol mechanisms in any reasonably designed > > protocol. CEs > > > > >will > > > > >need to ask FEs for many pieces of FE level information. > > If we must > > > > >have a > > > > >requirement in this area at all, it should be a requirement > > > > that the set > > > > >of > > > > >FE information a CE can query should include support for optional > > > > >information about inter-FE connectivity. (A CE should not > > > > be required > > > > >to > > > > >ask about this, an FE should not be required to provide > > this, and it > > > > >really > > > > >should not be treated as special information requiring > > > > special protocol > > > > >support mechanisms. > > > > > > > > > >Another way of looking at this is that there are many kinds of > > > > >information > > > > >that an FE might be able to provide that might or might not be > > > > >communicable > > > > >in the initial set of information mandated for CE-FE > > > > querying. For lots > > > > >of > > > > >reasons, the protocol MUST be extensible. Making support of this > > > > >information important relative to selecting / defining > > the protocol > > > > >seems a > > > > >serious mistake. > > > > > > > > > >Yours, > > > > >Joel M. Halpern > > > > > > > > > >At 05:35 PM 9/20/2003 -0700, you wrote: > > > > > >The text for this requirement has always been inter-FE > > > > topology (since > > > > > >v-02). > > > > > >I am pretty sure but I'll check with Todd anyways on this. > > > > > > > > > > > >If we do not provide protocol mechanisms to support this, > > > > then there > > > > > >will > > > > > >have to be non-standard ways to obtain this information > > > > from the FEs > > > > > >which > > > > > >provide this info, which we would like to avoid. > > > > > > > > > > > >Thanks > > > > > >Hormuzd > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 23 23:00:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21032 for ; Tue, 23 Sep 2003 23:00:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zt3-0003SZ-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 23:00:17 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A1zt1-0003SW-00 for forces-archive@IETF.ORG; Tue, 23 Sep 2003 23:00:15 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00BE2B29@cherry.ease.lsoft.com>; Tue, 23 Sep 2003 23:00:15 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55827739 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Sep 2003 22:59:55 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Sep 2003 22:59:55 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8O2vXv29054 for ; Wed, 24 Sep 2003 02:57:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8O2sWs27563 for ; Wed, 24 Sep 2003 02:54:32 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092319595407522 for ; Tue, 23 Sep 2003 19:59:54 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 23 Sep 2003 19:59:54 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: FW: Requirements Thread-Index: AcOCQ+0kjGmiZJK/QO+rhI0OwlDl/QAAZ0Kw X-OriginalArrivalTime: 24 Sep 2003 02:59:54.0046 (UTC) FILETIME=[EDCD75E0:01C38247] Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FEFE@orsmsx410.jf.intel.com> Date: Tue, 23 Sep 2003 19:59:53 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: FW: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Ok, now I understand why you want to place it as FE attributes. But that = seems at odd with the current assumptions FE model team is using to = build the FE model. This seems like a partitioning problem -- someone = has to take it, either 1)the FE model, or 2)the protocol, or 3) entirely = outside of ForCES. Logically, I don't think it belong to FE model, just like LFB (intra-FE) = topology does not belong to LFB (that is, FE logical functional block) = model. 2) seems like a reasonable solution because it shouldn't add = terrible amount of complexity to ForCES protocol either. Pushing it = entirely outside of ForCES might be an option too, but that might be a = radical limitation to some people.=20 Lily > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > Sent: Tuesday, September 23, 2003 7:31 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: FW: Requirements >=20 >=20 > I would tend to treat the entire issue of inter-FE topology=20 > as out of scope > for the initial FORCES work. I would expect CEs to either be=20 > configured > with the topology information, or to run any one of the many topology > discovery protocols. > This led me to consider it to be out of scope for the model. >=20 > However, folks want some information about inter-FE topology=20 > to be within > scope for FORCES. If so, I would place it as FE attributes. >=20 > Yours, > Joel M. Halpern >=20 > At 07:14 PM 9/23/2003 -0700, you wrote: > >Joel -- > >But I thought we agree (at least within the FE model design=20 > team, from our > >previous conference calls) that FE-topology is outside of=20 > the FE model, > >and so inter-FE topology info is not going to be part of the=20 > FE attributes > >as we define today. Therefore, explicit topology query/reply must be > >provided by the base protocol itself, because you aren't=20 > going to get that > >directly from FE model. > >Now, having said that, I agree with you that IF some=20 > specialized LFB is > >chartered with some kind of discovery function, then the FE=20 > topology info > >can be indirectly but effectively gathered by querying the=20 > attributes of > >such LFB -- but that is a big "IF" and is only one of the=20 > many possible > >approaches. > >So to cover the case when some FEs indeed have such topology=20 > info with > >them, a simple topology query/reply will do the work. > > > >Oh, you don't need to apologize -- the most probable outcome=20 > of a "draft" > >design is -- Oops, it doesn't work! Always better know that=20 > today than > >tomorrow though. > > > >Lily > > > > > -----Original Message----- > > > From: Forwarding and Control Element Separation > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > > > Sent: Tuesday, September 23, 2003 6:54 PM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: Re: FW: Requirements > > > > > > > > > Actually, this implication is what concerns me. > > > > > > There must be a mechanism for the CE to query FE attributes. > > > I would sincerely hope that such attributes would be extensible. > > > It would seem sensible that one portion of those attributes > > > could and would > > > be used to reflect whatever knowledge about inter-FE topology > > > the FE had. > > > Thus, the information would be accessible. > > > But there would not be a inter-FE topology query/reply in the > > > protocol. > > > The protocol would have FE attribute query / reply, which > > > would cover many > > > cases. > > > > > > Yours, > > > Joel M. Halpern > > > > > > PS: I like your proposed rewording of the framework text. > > > > > > PPS: I truly am sorry to raise this so late. It wasn't until > > > reviewing > > > protocol proposals that I realized the implication of the > > > requirements text. > > > > > > At 06:12 PM 9/23/2003 -0700, you wrote: > > > >Our mail server has been acting very badly lately -- I > > > didn't see this > > > >email posted to the list even after 4 hours and so here it > > > is again -- I > > > >believe what I said here basically concurs with Avri and Ellen. > > > > > > > >-----Original Message----- > > > >From: Yang, Lily L > > > >Sent: Tuesday, September 23, 2003 1:52 PM > > > >To: 'Forwarding and Control Element Separation' > > > >Subject: RE: Requirements > > > > > > > > > > > >Joel -- Sorry to ping you again when you are already tired > > > of talking :-) > > > > > > > >When you said, "a) whether to fix the requirement in the > > > I-D", did you > > > >mean the architectural requirement (section 5, #10) or=20 > the protocol > > > >requirement (section 7, #10), or both? I do believe there > > > is different > > > >implications here depending on which one you were talking about. > > > > > > > >What I heard so far on this thread is that some FEs may=20 > have inter-FE > > > >topology info but all FEs do not. So the protocol MUST > > > support "inter-FE > > > >topology query/reply" in case some FEs are capable of > > > providing that info > > > >to CE. Architecturally, it is optional whether or not to use > > > such protocol > > > >mechanism -- as long as somehow CE can gather this > > > infomation, either by > > > >explicitly query over ForCES protocol, or by static > > > configuration, or by > > > >some dynamic discovery mechanism outside of ForCES. > > > > > > > >So I think a simple "inter-FE topology query/reply" is > > > indeed required in > > > >the ForCES protocol. But if FE can't provide that info, the > > > burden is on > > > >CE to gather that info by other means. > > > > > > > >I would like to see some consensus on this so that I can > > > make sure the > > > >framework draft accurately reflects it. > > > > > > > >Lily > > > > > > > > > -----Original Message----- > > > > > From: Forwarding and Control Element Separation > > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel=20 > M. Halpern > > > > > Sent: Tuesday, September 23, 2003 4:26 AM > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > Subject: Re: Requirements > > > > > > > > > > > > > > > I do not agree that all FEs have this (inter-FE topology > > > > > information). I > > > > > have agreed that some FEs may have it. And that having > > > standard FE > > > > > attributes to represent this is probably useful. > > > > > I do not agree that there is value in the requirement. It > > > > > will not help us > > > > > choose among protocols. It has already demonstrated a > > > drive to cause > > > > > protocol elements that are not needed. > > > > > > > > > > However, I have said enough for a while. The working group > > > > > nee3ds to decide > > > > > a) whether to fix the requirement in the I-D > > > > > b) whether to clarify some other way what is needed / wanted > > > > > to meet the > > > > > requirement > > > > > or whether the group actively likes the requirement. > > > > > > > > > > Yours, > > > > > Joel M. Halpern > > > > > > > > > > At 10:50 PM 9/22/2003 -0700, you wrote: > > > > > >Hi Joel > > > > > > > > > > > >I understand your concern regarding the architectural > > > > > requirement (sec > > > > > >5, #10) and I think we could clarify the text there, if still > > > > > >possible...or may be use the Framework draft to clarify > > > > > this? Lily, any > > > > > >ideas? > > > > > >However, I believe that the protocol requirement text is > > > fine and it > > > > > >should remain. From what I have heard so far, you agree that > > > > > a) all FEs > > > > > >have this info, b) some FEs might acquire this thru=20 > some inter-FE > > > > > >discovery protocol or via FE manager and they should not > > > be precluded > > > > > >from ForCES, c) CE needs this info. If you agree with a, b & > > > > > c then it > > > > > >is natural to have some protocol mechanism to support this > > > > > (whether it > > > > > >is a general or special mechanism is a separate > > > > > issue)...unless you want > > > > > >to have a non-standard way to do this, which defeats the > > > purpose of > > > > > >ForCES. You have also agreed that it is ok to have=20 > some optional > > > > > >mechanism for this. Now if you were in the Requirements > > > team, which > > > > > >unfortunately you were not :), would you rather=20 > define optional > > > > > >requirements or mandatory ones ? This has a direct=20 > impact on the > > > > > >protocol design and interoperability. > > > > > > > > > > > >Also, I don't remember there having been any arguments or big > > > > > >discussions around this requirement before atleast in the > > > > > design team. > > > > > >The only feeback we had received was from the IESG was > > > to clarify the > > > > > >text in the Protocol Req section 7, which we did. > > > > > > > > > > > >I hope you will understand my point of view. > > > > > >Thanks a lot > > > > > >Hormuzd > > > > > > > > > > > >-----Original Message----- > > > > > >From: Forwarding and Control Element Separation > > > > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of=20 > Joel M. Halpern > > > > > >Sent: Saturday, September 20, 2003 5:57 PM > > > > > >To: FORCES@PEACH.EASE.LSOFT.COM > > > > > >Subject: Re: [FORCES] Requirements > > > > > > > > > > > >A large part of my problem with this requirement is=20 > that it leads > > > > > >sensible > > > > > >implementors (such as yourself) to think that they need > > > > > special protocol > > > > > >mechanisms to support this. It also leads sensible FE > > > > > implementors to > > > > > >think that they are somehow required to provide this > > > implementation. > > > > > > > > > > > >1) FE's better not be required to provide inter-FE topology > > > > > information. > > > > > > > > > > > >2) Allowing FEs which have such information to provide > > > it does not > > > > > >require > > > > > >special protocol mechanisms in any reasonably designed > > > protocol. CEs > > > > > >will > > > > > >need to ask FEs for many pieces of FE level information. > > > If we must > > > > > >have a > > > > > >requirement in this area at all, it should be a requirement > > > > > that the set > > > > > >of > > > > > >FE information a CE can query should include support=20 > for optional > > > > > >information about inter-FE connectivity. (A CE should not > > > > > be required > > > > > >to > > > > > >ask about this, an FE should not be required to provide > > > this, and it > > > > > >really > > > > > >should not be treated as special information requiring > > > > > special protocol > > > > > >support mechanisms. > > > > > > > > > > > >Another way of looking at this is that there are=20 > many kinds of > > > > > >information > > > > > >that an FE might be able to provide that might or=20 > might not be > > > > > >communicable > > > > > >in the initial set of information mandated for CE-FE > > > > > querying. For lots > > > > > >of > > > > > >reasons, the protocol MUST be extensible. Making=20 > support of this > > > > > >information important relative to selecting / defining > > > the protocol > > > > > >seems a > > > > > >serious mistake. > > > > > > > > > > > >Yours, > > > > > >Joel M. Halpern > > > > > > > > > > > >At 05:35 PM 9/20/2003 -0700, you wrote: > > > > > > >The text for this requirement has always been inter-FE > > > > > topology (since > > > > > > >v-02). > > > > > > >I am pretty sure but I'll check with Todd anyways on this. > > > > > > > > > > > > > >If we do not provide protocol mechanisms to support this, > > > > > then there > > > > > > >will > > > > > > >have to be non-standard ways to obtain this information > > > > > from the FEs > > > > > > >which > > > > > > >provide this info, which we would like to avoid. > > > > > > > > > > > > > >Thanks > > > > > > >Hormuzd > > > > > > > > >=20 From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 24 01:23:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27193 for ; Wed, 24 Sep 2003 01:23:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A227l-0005FR-00 for forces-archive@IETF.ORG; Wed, 24 Sep 2003 01:23:37 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A227k-0005FO-00 for forces-archive@IETF.ORG; Wed, 24 Sep 2003 01:23:36 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00BE2FCB@cherry.ease.lsoft.com>; Wed, 24 Sep 2003 1:23:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55850344 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Sep 2003 01:23:35 -0400 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 24 Sep 2003 01:23:34 -0400 Received: from wwm1([218.108.149.66]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm243f718cdb; Wed, 24 Sep 2003 13:22:27 +0800 References: <26BDFAFFB541B047B24179002EBE6D2714FEFE@orsmsx410.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Approved-By: Weiming Wang Message-ID: <005b01c3825b$e703da10$3d19fea9@wwm1> Date: Wed, 24 Sep 2003 13:22:52 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: FW: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SSBkb24ndCB0aGluayBpdCBuZWVkcyB0byBiZSBjaGFuZ2VkIGEgbG90IGluIGN1cnJlbnQgRm9y Q0VTIGRvY3VtZW50LiBGRSB0b3BvbG9neSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMgaW4g Rm9yQ0VTIHByb3RvY29sIGNhbiBhbHNvIGJlIHJlbWFpbmVkLCBvbmx5IHdpdGggdGhlIHJlc3Bv bnNlIG1lc3NhZ2UgYmVpbmcgYWRkZWQgd2l0aCBhbiBpdGVtIHRvIHRlbGwgQ0UgdGhhdCB0aGUg RkUgbm93IGNhbiBub3QgdGVsbCB0aGUgdG9wb2xvZ3kuIA0KDQpXZSBjYW4gdHJlYXQgdGhlIEZF IHRvcG9sb2d5IGFzIGEga2luZCBvZiBGRSBhdHRyaWJ1dGUod2hpY2ggZGlmZmVycyBmcm9tIExG QiBhdHRyaWJ1dGVzIGFuZCBjYW4gYmUgb3V0IG9mIHNjb3BlIG9mIEZFIG1vZGVsKSwgYnV0IHRo ZXJlJ3Mgbm8gaGFybSB0byB0cmVhdCBpdCBqdXN0IGFzIEZFIHRvcG9sb2d5LiBJIGRvbid0IHRo aW5rIHdlIG5lZWQgdG8gc2F2ZSAibWVzc2FnZSB0eXBlIiBzcGFjZSwgZm9yIHRoZXkgYXJlIGVu b3VnaC4gQWN0dWFsbHkgRkUgY2FwYWJpbGl0eSBpcyBhbHNvIGEga2luZCBvZiBGRSBhdHRyaWJ1 dGUsIGJ1dCB3ZSBzZXBlcmF0ZSBmcm9tIGl0LCB3aGljaCBzZWVtcyBuaWNlci4gDQoNClJlZ2Fy ZHMsDQp3ZWltaW5nDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJZ YW5nLCBMaWx5IEwiIDxsaWx5LmwueWFuZ0BpbnRlbC5jb20+DQpUbzogPEZPUkNFU0BQRUFDSC5F QVNFLkxTT0ZULkNPTT4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI0LCAyMDAzIDEwOjU5 IEFNDQpTdWJqZWN0OiBSZTogRlc6IFJlcXVpcmVtZW50cw0KDQoNCk9rLCBub3cgSSB1bmRlcnN0 YW5kIHdoeSB5b3Ugd2FudCB0byBwbGFjZSBpdCBhcyBGRSBhdHRyaWJ1dGVzLiBCdXQgdGhhdCBz ZWVtcyBhdCBvZGQgd2l0aCB0aGUgY3VycmVudCBhc3N1bXB0aW9ucyBGRSBtb2RlbCB0ZWFtIGlz IHVzaW5nIHRvIGJ1aWxkIHRoZSBGRSBtb2RlbC4gVGhpcyBzZWVtcyBsaWtlIGEgcGFydGl0aW9u aW5nIHByb2JsZW0gLS0gc29tZW9uZSBoYXMgdG8gdGFrZSBpdCwgZWl0aGVyIDEpdGhlIEZFIG1v ZGVsLCBvciAyKXRoZSBwcm90b2NvbCwgb3IgMykgZW50aXJlbHkgb3V0c2lkZSBvZiBGb3JDRVMu DQpMb2dpY2FsbHksIEkgZG9uJ3QgdGhpbmsgaXQgYmVsb25nIHRvIEZFIG1vZGVsLCBqdXN0IGxp a2UgTEZCIChpbnRyYS1GRSkgdG9wb2xvZ3kgZG9lcyBub3QgYmVsb25nIHRvIExGQiAodGhhdCBp cywgRkUgbG9naWNhbCBmdW5jdGlvbmFsIGJsb2NrKSBtb2RlbC4gMikgc2VlbXMgbGlrZSBhIHJl YXNvbmFibGUgc29sdXRpb24gYmVjYXVzZSBpdCBzaG91bGRuJ3QgYWRkIHRlcnJpYmxlIGFtb3Vu dCBvZiBjb21wbGV4aXR5IHRvIEZvckNFUyBwcm90b2NvbCBlaXRoZXIuIFB1c2hpbmcgaXQgZW50 aXJlbHkgb3V0c2lkZSBvZiBGb3JDRVMgbWlnaHQgYmUgYW4gb3B0aW9uIHRvbywgYnV0IHRoYXQg bWlnaHQgYmUgYSByYWRpY2FsIGxpbWl0YXRpb24gdG8gc29tZSBwZW9wbGUuIA0KDQpMaWx5DQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRm9yd2FyZGluZyBhbmQgQ29u dHJvbCBFbGVtZW50IFNlcGFyYXRpb24NCj4gW21haWx0bzpGT1JDRVNAUEVBQ0guRUFTRS5MU09G VC5DT01dT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KPiBTZW50OiBUdWVzZGF5LCBTZXB0 ZW1iZXIgMjMsIDIwMDMgNzozMSBQTQ0KPiBUbzogRk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09N DQo+IFN1YmplY3Q6IFJlOiBGVzogUmVxdWlyZW1lbnRzDQo+IA0KPiANCj4gSSB3b3VsZCB0ZW5k IHRvIHRyZWF0IHRoZSBlbnRpcmUgaXNzdWUgb2YgaW50ZXItRkUgdG9wb2xvZ3kgDQo+IGFzIG91 dCBvZiBzY29wZQ0KPiBmb3IgdGhlIGluaXRpYWwgRk9SQ0VTIHdvcmsuICBJIHdvdWxkIGV4cGVj dCBDRXMgdG8gZWl0aGVyIGJlIA0KPiBjb25maWd1cmVkDQo+IHdpdGggdGhlIHRvcG9sb2d5IGlu Zm9ybWF0aW9uLCBvciB0byBydW4gYW55IG9uZSBvZiB0aGUgbWFueSB0b3BvbG9neQ0KPiBkaXNj b3ZlcnkgcHJvdG9jb2xzLg0KPiBUaGlzIGxlZCBtZSB0byBjb25zaWRlciBpdCB0byBiZSBvdXQg b2Ygc2NvcGUgZm9yIHRoZSBtb2RlbC4NCj4gDQo+IEhvd2V2ZXIsIGZvbGtzIHdhbnQgc29tZSBp bmZvcm1hdGlvbiBhYm91dCBpbnRlci1GRSB0b3BvbG9neSANCj4gdG8gYmUgd2l0aGluDQo+IHNj b3BlIGZvciBGT1JDRVMuICBJZiBzbywgSSB3b3VsZCBwbGFjZSBpdCBhcyBGRSBhdHRyaWJ1dGVz Lg0KPiANCj4gWW91cnMsDQo+IEpvZWwgTS4gSGFscGVybg0KPiANCj4gQXQgMDc6MTQgUE0gOS8y My8yMDAzIC0wNzAwLCB5b3Ugd3JvdGU6DQo+ID5Kb2VsIC0tDQo+ID5CdXQgSSB0aG91Z2h0IHdl IGFncmVlIChhdCBsZWFzdCB3aXRoaW4gdGhlIEZFIG1vZGVsIGRlc2lnbiANCj4gdGVhbSwgZnJv bSBvdXINCj4gPnByZXZpb3VzIGNvbmZlcmVuY2UgY2FsbHMpIHRoYXQgRkUtdG9wb2xvZ3kgaXMg b3V0c2lkZSBvZiANCj4gdGhlIEZFIG1vZGVsLA0KPiA+YW5kIHNvIGludGVyLUZFIHRvcG9sb2d5 IGluZm8gaXMgbm90IGdvaW5nIHRvIGJlIHBhcnQgb2YgdGhlIA0KPiBGRSBhdHRyaWJ1dGVzDQo+ ID5hcyB3ZSBkZWZpbmUgdG9kYXkuIFRoZXJlZm9yZSwgZXhwbGljaXQgdG9wb2xvZ3kgcXVlcnkv cmVwbHkgbXVzdCBiZQ0KPiA+cHJvdmlkZWQgYnkgdGhlIGJhc2UgcHJvdG9jb2wgaXRzZWxmLCBi ZWNhdXNlIHlvdSBhcmVuJ3QgDQo+IGdvaW5nIHRvIGdldCB0aGF0DQo+ID5kaXJlY3RseSBmcm9t IEZFIG1vZGVsLg0KPiA+Tm93LCBoYXZpbmcgc2FpZCB0aGF0LCBJIGFncmVlIHdpdGggeW91IHRo YXQgSUYgc29tZSANCj4gc3BlY2lhbGl6ZWQgTEZCIGlzDQo+ID5jaGFydGVyZWQgd2l0aCBzb21l IGtpbmQgb2YgZGlzY292ZXJ5IGZ1bmN0aW9uLCB0aGVuIHRoZSBGRSANCj4gdG9wb2xvZ3kgaW5m bw0KPiA+Y2FuIGJlIGluZGlyZWN0bHkgYnV0IGVmZmVjdGl2ZWx5IGdhdGhlcmVkIGJ5IHF1ZXJ5 aW5nIHRoZSANCj4gYXR0cmlidXRlcyBvZg0KPiA+c3VjaCBMRkIgLS0gYnV0IHRoYXQgaXMgYSBi aWcgIklGIiBhbmQgaXMgb25seSBvbmUgb2YgdGhlIA0KPiBtYW55IHBvc3NpYmxlDQo+ID5hcHBy b2FjaGVzLg0KPiA+U28gdG8gY292ZXIgdGhlIGNhc2Ugd2hlbiBzb21lIEZFcyBpbmRlZWQgaGF2 ZSBzdWNoIHRvcG9sb2d5IA0KPiBpbmZvIHdpdGgNCj4gPnRoZW0sIGEgc2ltcGxlIHRvcG9sb2d5 IHF1ZXJ5L3JlcGx5IHdpbGwgZG8gdGhlIHdvcmsuDQo+ID4NCj4gPk9oLCB5b3UgZG9uJ3QgbmVl ZCB0byBhcG9sb2dpemUgLS0gdGhlIG1vc3QgcHJvYmFibGUgb3V0Y29tZSANCj4gb2YgYSAiZHJh ZnQiDQo+ID5kZXNpZ24gaXMgLS0gT29wcywgaXQgZG9lc24ndCB3b3JrISBBbHdheXMgYmV0dGVy IGtub3cgdGhhdCANCj4gdG9kYXkgdGhhbg0KPiA+dG9tb3Jyb3cgdGhvdWdoLg0KPiA+DQo+ID5M aWx5DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBG b3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbg0KPiA+ID4gW21haWx0bzpG T1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT01dT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0K PiA+ID4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDIzLCAyMDAzIDY6NTQgUE0NCj4gPiA+IFRv OiBGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00NCj4gPiA+IFN1YmplY3Q6IFJlOiBGVzogUmVx dWlyZW1lbnRzDQo+ID4gPg0KPiA+ID4NCj4gPiA+IEFjdHVhbGx5LCB0aGlzIGltcGxpY2F0aW9u IGlzIHdoYXQgY29uY2VybnMgbWUuDQo+ID4gPg0KPiA+ID4gVGhlcmUgbXVzdCBiZSBhIG1lY2hh bmlzbSBmb3IgdGhlIENFIHRvIHF1ZXJ5IEZFIGF0dHJpYnV0ZXMuDQo+ID4gPiBJIHdvdWxkIHNp bmNlcmVseSBob3BlIHRoYXQgc3VjaCBhdHRyaWJ1dGVzIHdvdWxkIGJlIGV4dGVuc2libGUuDQo+ ID4gPiBJdCB3b3VsZCBzZWVtIHNlbnNpYmxlIHRoYXQgb25lIHBvcnRpb24gb2YgdGhvc2UgYXR0 cmlidXRlcw0KPiA+ID4gY291bGQgYW5kIHdvdWxkDQo+ID4gPiBiZSB1c2VkIHRvIHJlZmxlY3Qg d2hhdGV2ZXIga25vd2xlZGdlIGFib3V0IGludGVyLUZFIHRvcG9sb2d5DQo+ID4gPiB0aGUgRkUg aGFkLg0KPiA+ID4gVGh1cywgdGhlIGluZm9ybWF0aW9uIHdvdWxkIGJlIGFjY2Vzc2libGUuDQo+ ID4gPiBCdXQgdGhlcmUgd291bGQgbm90IGJlIGEgaW50ZXItRkUgdG9wb2xvZ3kgcXVlcnkvcmVw bHkgaW4gdGhlDQo+ID4gPiBwcm90b2NvbC4NCj4gPiA+IFRoZSBwcm90b2NvbCB3b3VsZCBoYXZl IEZFIGF0dHJpYnV0ZSBxdWVyeSAvIHJlcGx5LCB3aGljaA0KPiA+ID4gd291bGQgY292ZXIgbWFu eQ0KPiA+ID4gY2FzZXMuDQo+ID4gPg0KPiA+ID4gWW91cnMsDQo+ID4gPiBKb2VsIE0uIEhhbHBl cm4NCj4gPiA+DQo+ID4gPiBQUzogSSBsaWtlIHlvdXIgcHJvcG9zZWQgcmV3b3JkaW5nIG9mIHRo ZSBmcmFtZXdvcmsgdGV4dC4NCj4gPiA+DQo+ID4gPiBQUFM6IEkgdHJ1bHkgYW0gc29ycnkgdG8g cmFpc2UgdGhpcyBzbyBsYXRlLiAgSXQgd2Fzbid0IHVudGlsDQo+ID4gPiByZXZpZXdpbmcNCj4g PiA+IHByb3RvY29sIHByb3Bvc2FscyB0aGF0IEkgcmVhbGl6ZWQgdGhlIGltcGxpY2F0aW9uIG9m IHRoZQ0KPiA+ID4gcmVxdWlyZW1lbnRzIHRleHQuDQo+ID4gPg0KPiA+ID4gQXQgMDY6MTIgUE0g OS8yMy8yMDAzIC0wNzAwLCB5b3Ugd3JvdGU6DQo+ID4gPiA+T3VyIG1haWwgc2VydmVyIGhhcyBi ZWVuIGFjdGluZyB2ZXJ5IGJhZGx5IGxhdGVseSAtLSBJDQo+ID4gPiBkaWRuJ3Qgc2VlIHRoaXMN Cj4gPiA+ID5lbWFpbCBwb3N0ZWQgdG8gdGhlIGxpc3QgZXZlbiBhZnRlciA0IGhvdXJzIGFuZCBz byBoZXJlIGl0DQo+ID4gPiBpcyBhZ2FpbiAtLSBJDQo+ID4gPiA+YmVsaWV2ZSB3aGF0IEkgc2Fp ZCBoZXJlIGJhc2ljYWxseSBjb25jdXJzIHdpdGggQXZyaSBhbmQgRWxsZW4uDQo+ID4gPiA+DQo+ ID4gPiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID5Gcm9tOiBZYW5nLCBMaWx5 IEwNCj4gPiA+ID5TZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjMsIDIwMDMgMTo1MiBQTQ0KPiA+ ID4gPlRvOiAnRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24nDQo+ID4g PiA+U3ViamVjdDogUkU6IFJlcXVpcmVtZW50cw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPkpv ZWwgLS0gU29ycnkgdG8gcGluZyB5b3UgYWdhaW4gd2hlbiB5b3UgYXJlIGFscmVhZHkgdGlyZWQN Cj4gPiA+IG9mIHRhbGtpbmcgOi0pDQo+ID4gPiA+DQo+ID4gPiA+V2hlbiB5b3Ugc2FpZCwgImEp IHdoZXRoZXIgdG8gZml4IHRoZSByZXF1aXJlbWVudCBpbiB0aGUNCj4gPiA+IEktRCIsIGRpZCB5 b3UNCj4gPiA+ID5tZWFuIHRoZSBhcmNoaXRlY3R1cmFsIHJlcXVpcmVtZW50IChzZWN0aW9uIDUs ICMxMCkgb3IgDQo+IHRoZSBwcm90b2NvbA0KPiA+ID4gPnJlcXVpcmVtZW50IChzZWN0aW9uIDcs ICMxMCksIG9yIGJvdGg/ICBJIGRvIGJlbGlldmUgdGhlcmUNCj4gPiA+IGlzIGRpZmZlcmVudA0K PiA+ID4gPmltcGxpY2F0aW9ucyBoZXJlIGRlcGVuZGluZyBvbiB3aGljaCBvbmUgeW91IHdlcmUg dGFsa2luZyBhYm91dC4NCj4gPiA+ID4NCj4gPiA+ID5XaGF0IEkgaGVhcmQgc28gZmFyIG9uIHRo aXMgdGhyZWFkIGlzIHRoYXQgc29tZSBGRXMgbWF5IA0KPiBoYXZlIGludGVyLUZFDQo+ID4gPiA+ dG9wb2xvZ3kgaW5mbyBidXQgYWxsIEZFcyBkbyBub3QuIFNvIHRoZSBwcm90b2NvbCBNVVNUDQo+ ID4gPiBzdXBwb3J0ICJpbnRlci1GRQ0KPiA+ID4gPnRvcG9sb2d5IHF1ZXJ5L3JlcGx5IiBpbiBj YXNlIHNvbWUgRkVzIGFyZSBjYXBhYmxlIG9mDQo+ID4gPiBwcm92aWRpbmcgdGhhdCBpbmZvDQo+ ID4gPiA+dG8gQ0UuIEFyY2hpdGVjdHVyYWxseSwgaXQgaXMgb3B0aW9uYWwgd2hldGhlciBvciBu b3QgdG8gdXNlDQo+ID4gPiBzdWNoIHByb3RvY29sDQo+ID4gPiA+bWVjaGFuaXNtIC0tIGFzIGxv bmcgYXMgc29tZWhvdyBDRSBjYW4gZ2F0aGVyIHRoaXMNCj4gPiA+IGluZm9tYXRpb24sIGVpdGhl ciBieQ0KPiA+ID4gPmV4cGxpY2l0bHkgcXVlcnkgb3ZlciBGb3JDRVMgcHJvdG9jb2wsIG9yIGJ5 IHN0YXRpYw0KPiA+ID4gY29uZmlndXJhdGlvbiwgb3IgYnkNCj4gPiA+ID5zb21lIGR5bmFtaWMg ZGlzY292ZXJ5IG1lY2hhbmlzbSBvdXRzaWRlIG9mIEZvckNFUy4NCj4gPiA+ID4NCj4gPiA+ID5T byBJIHRoaW5rIGEgc2ltcGxlICJpbnRlci1GRSB0b3BvbG9neSBxdWVyeS9yZXBseSIgaXMNCj4g PiA+IGluZGVlZCByZXF1aXJlZCBpbg0KPiA+ID4gPnRoZSBGb3JDRVMgcHJvdG9jb2wuIEJ1dCBp ZiBGRSBjYW4ndCBwcm92aWRlIHRoYXQgaW5mbywgdGhlDQo+ID4gPiBidXJkZW4gaXMgb24NCj4g PiA+ID5DRSB0byBnYXRoZXIgdGhhdCBpbmZvIGJ5IG90aGVyIG1lYW5zLg0KPiA+ID4gPg0KPiA+ ID4gPkkgd291bGQgbGlrZSB0byBzZWUgc29tZSBjb25zZW5zdXMgb24gdGhpcyBzbyB0aGF0IEkg Y2FuDQo+ID4gPiBtYWtlIHN1cmUgdGhlDQo+ID4gPiA+ZnJhbWV3b3JrIGRyYWZ0IGFjY3VyYXRl bHkgcmVmbGVjdHMgaXQuDQo+ID4gPiA+DQo+ID4gPiA+TGlseQ0KPiA+ID4gPg0KPiA+ID4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogRm9yd2FyZGluZyBh bmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24NCj4gPiA+ID4gPiBbbWFpbHRvOkZPUkNFU0BQ RUFDSC5FQVNFLkxTT0ZULkNPTV1PbiBCZWhhbGYgT2YgSm9lbCANCj4gTS4gSGFscGVybg0KPiA+ ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyMywgMjAwMyA0OjI2IEFNDQo+ID4gPiA+ ID4gVG86IEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTQ0KPiA+ID4gPiA+IFN1YmplY3Q6IFJl OiBSZXF1aXJlbWVudHMNCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBkbyBub3Qg YWdyZWUgdGhhdCBhbGwgRkVzIGhhdmUgdGhpcyAoaW50ZXItRkUgdG9wb2xvZ3kNCj4gPiA+ID4g PiBpbmZvcm1hdGlvbikuICBJDQo+ID4gPiA+ID4gaGF2ZSBhZ3JlZWQgdGhhdCBzb21lIEZFcyBt YXkgaGF2ZSBpdC4gIEFuZCB0aGF0IGhhdmluZw0KPiA+ID4gc3RhbmRhcmQgRkUNCj4gPiA+ID4g PiBhdHRyaWJ1dGVzIHRvIHJlcHJlc2VudCB0aGlzIGlzIHByb2JhYmx5IHVzZWZ1bC4NCj4gPiA+ ID4gPiBJIGRvIG5vdCBhZ3JlZSB0aGF0IHRoZXJlIGlzIHZhbHVlIGluIHRoZSByZXF1aXJlbWVu dC4gIEl0DQo+ID4gPiA+ID4gd2lsbCBub3QgaGVscCB1cw0KPiA+ID4gPiA+IGNob29zZSBhbW9u ZyBwcm90b2NvbHMuICBJdCBoYXMgYWxyZWFkeSBkZW1vbnN0cmF0ZWQgYQ0KPiA+ID4gZHJpdmUg dG8gY2F1c2UNCj4gPiA+ID4gPiBwcm90b2NvbCBlbGVtZW50cyB0aGF0IGFyZSBub3QgbmVlZGVk Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSG93ZXZlciwgSSBoYXZlIHNhaWQgZW5vdWdoIGZvciBh IHdoaWxlLiAgVGhlIHdvcmtpbmcgZ3JvdXANCj4gPiA+ID4gPiBuZWUzZHMgdG8gZGVjaWRlDQo+ ID4gPiA+ID4gYSkgd2hldGhlciB0byBmaXggdGhlIHJlcXVpcmVtZW50IGluIHRoZSBJLUQNCj4g PiA+ID4gPiBiKSB3aGV0aGVyIHRvIGNsYXJpZnkgc29tZSBvdGhlciB3YXkgd2hhdCBpcyBuZWVk ZWQgLyB3YW50ZWQNCj4gPiA+ID4gPiB0byBtZWV0IHRoZQ0KPiA+ID4gPiA+IHJlcXVpcmVtZW50 DQo+ID4gPiA+ID4gb3Igd2hldGhlciB0aGUgZ3JvdXAgYWN0aXZlbHkgbGlrZXMgdGhlIHJlcXVp cmVtZW50Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gWW91cnMsDQo+ID4gPiA+ID4gSm9lbCBNLiBI YWxwZXJuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBBdCAxMDo1MCBQTSA5LzIyLzIwMDMgLTA3MDAs IHlvdSB3cm90ZToNCj4gPiA+ID4gPiA+SGkgSm9lbA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ SSB1bmRlcnN0YW5kIHlvdXIgY29uY2VybiByZWdhcmRpbmcgdGhlIGFyY2hpdGVjdHVyYWwNCj4g PiA+ID4gPiByZXF1aXJlbWVudCAoc2VjDQo+ID4gPiA+ID4gPjUsICMxMCkgYW5kIEkgdGhpbmsg d2UgY291bGQgY2xhcmlmeSB0aGUgdGV4dCB0aGVyZSwgaWYgc3RpbGwNCj4gPiA+ID4gPiA+cG9z c2libGUuLi5vciBtYXkgYmUgdXNlIHRoZSBGcmFtZXdvcmsgZHJhZnQgdG8gY2xhcmlmeQ0KPiA+ ID4gPiA+IHRoaXM/IExpbHksIGFueQ0KPiA+ID4gPiA+ID5pZGVhcz8NCj4gPiA+ID4gPiA+SG93 ZXZlciwgSSBiZWxpZXZlIHRoYXQgdGhlIHByb3RvY29sIHJlcXVpcmVtZW50IHRleHQgaXMNCj4g PiA+IGZpbmUgYW5kIGl0DQo+ID4gPiA+ID4gPnNob3VsZCByZW1haW4uIEZyb20gd2hhdCBJIGhh dmUgaGVhcmQgc28gZmFyLCB5b3UgYWdyZWUgdGhhdA0KPiA+ID4gPiA+IGEpIGFsbCBGRXMNCj4g PiA+ID4gPiA+aGF2ZSB0aGlzIGluZm8sIGIpIHNvbWUgRkVzIG1pZ2h0IGFjcXVpcmUgdGhpcyB0 aHJ1IA0KPiBzb21lIGludGVyLUZFDQo+ID4gPiA+ID4gPmRpc2NvdmVyeSBwcm90b2NvbCBvciB2 aWEgRkUgbWFuYWdlciBhbmQgdGhleSBzaG91bGQgbm90DQo+ID4gPiBiZSBwcmVjbHVkZWQNCj4g PiA+ID4gPiA+ZnJvbSBGb3JDRVMsIGMpIENFIG5lZWRzIHRoaXMgaW5mby4gSWYgeW91IGFncmVl IHdpdGggYSwgYiAmDQo+ID4gPiA+ID4gYyB0aGVuIGl0DQo+ID4gPiA+ID4gPmlzIG5hdHVyYWwg dG8gaGF2ZSBzb21lIHByb3RvY29sIG1lY2hhbmlzbSB0byBzdXBwb3J0IHRoaXMNCj4gPiA+ID4g PiAod2hldGhlciBpdA0KPiA+ID4gPiA+ID5pcyBhIGdlbmVyYWwgb3Igc3BlY2lhbCBtZWNoYW5p c20gaXMgYSBzZXBhcmF0ZQ0KPiA+ID4gPiA+IGlzc3VlKS4uLnVubGVzcyB5b3Ugd2FudA0KPiA+ ID4gPiA+ID50byBoYXZlIGEgbm9uLXN0YW5kYXJkIHdheSB0byBkbyB0aGlzLCB3aGljaCBkZWZl YXRzIHRoZQ0KPiA+ID4gcHVycG9zZSBvZg0KPiA+ID4gPiA+ID5Gb3JDRVMuIFlvdSBoYXZlIGFs c28gYWdyZWVkIHRoYXQgaXQgaXMgb2sgdG8gaGF2ZSANCj4gc29tZSBvcHRpb25hbA0KPiA+ID4g PiA+ID5tZWNoYW5pc20gZm9yIHRoaXMuIE5vdyBpZiB5b3Ugd2VyZSBpbiB0aGUgUmVxdWlyZW1l bnRzDQo+ID4gPiB0ZWFtLCB3aGljaA0KPiA+ID4gPiA+ID51bmZvcnR1bmF0ZWx5IHlvdSB3ZXJl IG5vdCA6KSwgd291bGQgeW91IHJhdGhlciANCj4gZGVmaW5lIG9wdGlvbmFsDQo+ID4gPiA+ID4g PnJlcXVpcmVtZW50cyBvciBtYW5kYXRvcnkgb25lcyA/IFRoaXMgaGFzIGEgZGlyZWN0IA0KPiBp bXBhY3Qgb24gdGhlDQo+ID4gPiA+ID4gPnByb3RvY29sIGRlc2lnbiBhbmQgaW50ZXJvcGVyYWJp bGl0eS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPkFsc28sIEkgZG9uJ3QgcmVtZW1iZXIgdGhl cmUgaGF2aW5nIGJlZW4gYW55IGFyZ3VtZW50cyBvciBiaWcNCj4gPiA+ID4gPiA+ZGlzY3Vzc2lv bnMgYXJvdW5kIHRoaXMgcmVxdWlyZW1lbnQgYmVmb3JlIGF0bGVhc3QgaW4gdGhlDQo+ID4gPiA+ ID4gZGVzaWduIHRlYW0uDQo+ID4gPiA+ID4gPlRoZSBvbmx5IGZlZWJhY2sgd2UgaGFkIHJlY2Vp dmVkIHdhcyBmcm9tIHRoZSBJRVNHIHdhcw0KPiA+ID4gdG8gY2xhcmlmeSB0aGUNCj4gPiA+ID4g PiA+dGV4dCBpbiB0aGUgUHJvdG9jb2wgUmVxIHNlY3Rpb24gNywgd2hpY2ggd2UgZGlkLg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+SSBob3BlIHlvdSB3aWxsIHVuZGVyc3RhbmQgbXkgcG9pbnQg b2Ygdmlldy4NCj4gPiA+ID4gPiA+VGhhbmtzIGEgbG90DQo+ID4gPiA+ID4gPkhvcm11emQNCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ ID4gPkZyb206IEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uDQo+ID4g PiA+ID4gPlttYWlsdG86Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NXSBPbiBCZWhhbGYgT2Yg DQo+IEpvZWwgTS4gSGFscGVybg0KPiA+ID4gPiA+ID5TZW50OiBTYXR1cmRheSwgU2VwdGVtYmVy IDIwLCAyMDAzIDU6NTcgUE0NCj4gPiA+ID4gPiA+VG86IEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZU LkNPTQ0KPiA+ID4gPiA+ID5TdWJqZWN0OiBSZTogW0ZPUkNFU10gUmVxdWlyZW1lbnRzDQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID5BIGxhcmdlIHBhcnQgb2YgbXkgcHJvYmxlbSB3aXRoIHRoaXMg cmVxdWlyZW1lbnQgaXMgDQo+IHRoYXQgaXQgbGVhZHMNCj4gPiA+ID4gPiA+c2Vuc2libGUNCj4g PiA+ID4gPiA+aW1wbGVtZW50b3JzIChzdWNoIGFzIHlvdXJzZWxmKSB0byB0aGluayB0aGF0IHRo ZXkgbmVlZA0KPiA+ID4gPiA+IHNwZWNpYWwgcHJvdG9jb2wNCj4gPiA+ID4gPiA+bWVjaGFuaXNt cyB0byBzdXBwb3J0IHRoaXMuICBJdCBhbHNvIGxlYWRzIHNlbnNpYmxlIEZFDQo+ID4gPiA+ID4g aW1wbGVtZW50b3JzIHRvDQo+ID4gPiA+ID4gPnRoaW5rIHRoYXQgdGhleSBhcmUgc29tZWhvdyBy ZXF1aXJlZCB0byBwcm92aWRlIHRoaXMNCj4gPiA+IGltcGxlbWVudGF0aW9uLg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+MSkgRkUncyBiZXR0ZXIgbm90IGJlIHJlcXVpcmVkIHRvIHByb3ZpZGUg aW50ZXItRkUgdG9wb2xvZ3kNCj4gPiA+ID4gPiBpbmZvcm1hdGlvbi4NCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPjIpIEFsbG93aW5nIEZFcyB3aGljaCBoYXZlIHN1Y2ggaW5mb3JtYXRpb24gdG8g cHJvdmlkZQ0KPiA+ID4gaXQgZG9lcyBub3QNCj4gPiA+ID4gPiA+cmVxdWlyZQ0KPiA+ID4gPiA+ ID5zcGVjaWFsIHByb3RvY29sIG1lY2hhbmlzbXMgaW4gYW55IHJlYXNvbmFibHkgZGVzaWduZWQN Cj4gPiA+IHByb3RvY29sLiAgQ0VzDQo+ID4gPiA+ID4gPndpbGwNCj4gPiA+ID4gPiA+bmVlZCB0 byBhc2sgRkVzIGZvciBtYW55IHBpZWNlcyBvZiBGRSBsZXZlbCBpbmZvcm1hdGlvbi4NCj4gPiA+ ICBJZiB3ZSBtdXN0DQo+ID4gPiA+ID4gPmhhdmUgYQ0KPiA+ID4gPiA+ID5yZXF1aXJlbWVudCBp biB0aGlzIGFyZWEgYXQgYWxsLCBpdCBzaG91bGQgYmUgYSByZXF1aXJlbWVudA0KPiA+ID4gPiA+ IHRoYXQgdGhlIHNldA0KPiA+ID4gPiA+ID5vZg0KPiA+ID4gPiA+ID5GRSBpbmZvcm1hdGlvbiBh IENFIGNhbiBxdWVyeSBzaG91bGQgaW5jbHVkZSBzdXBwb3J0IA0KPiBmb3Igb3B0aW9uYWwNCj4g PiA+ID4gPiA+aW5mb3JtYXRpb24gYWJvdXQgaW50ZXItRkUgY29ubmVjdGl2aXR5LiAgKEEgQ0Ug c2hvdWxkIG5vdA0KPiA+ID4gPiA+IGJlIHJlcXVpcmVkDQo+ID4gPiA+ID4gPnRvDQo+ID4gPiA+ ID4gPmFzayBhYm91dCB0aGlzLCBhbiBGRSBzaG91bGQgbm90IGJlIHJlcXVpcmVkIHRvIHByb3Zp ZGUNCj4gPiA+IHRoaXMsIGFuZCBpdA0KPiA+ID4gPiA+ID5yZWFsbHkNCj4gPiA+ID4gPiA+c2hv dWxkIG5vdCBiZSB0cmVhdGVkIGFzIHNwZWNpYWwgaW5mb3JtYXRpb24gcmVxdWlyaW5nDQo+ID4g PiA+ID4gc3BlY2lhbCBwcm90b2NvbA0KPiA+ID4gPiA+ID5zdXBwb3J0IG1lY2hhbmlzbXMuDQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID5Bbm90aGVyIHdheSBvZiBsb29raW5nIGF0IHRoaXMgaXMg dGhhdCB0aGVyZSBhcmUgDQo+IG1hbnkga2luZHMgb2YNCj4gPiA+ID4gPiA+aW5mb3JtYXRpb24N Cj4gPiA+ID4gPiA+dGhhdCBhbiBGRSBtaWdodCBiZSBhYmxlIHRvIHByb3ZpZGUgdGhhdCBtaWdo dCBvciANCj4gbWlnaHQgbm90IGJlDQo+ID4gPiA+ID4gPmNvbW11bmljYWJsZQ0KPiA+ID4gPiA+ ID5pbiB0aGUgaW5pdGlhbCBzZXQgb2YgaW5mb3JtYXRpb24gbWFuZGF0ZWQgZm9yIENFLUZFDQo+ ID4gPiA+ID4gcXVlcnlpbmcuICBGb3IgbG90cw0KPiA+ID4gPiA+ID5vZg0KPiA+ID4gPiA+ID5y ZWFzb25zLCB0aGUgcHJvdG9jb2wgTVVTVCBiZSBleHRlbnNpYmxlLiAgTWFraW5nIA0KPiBzdXBw b3J0IG9mIHRoaXMNCj4gPiA+ID4gPiA+aW5mb3JtYXRpb24gaW1wb3J0YW50IHJlbGF0aXZlIHRv IHNlbGVjdGluZyAvIGRlZmluaW5nDQo+ID4gPiB0aGUgcHJvdG9jb2wNCj4gPiA+ID4gPiA+c2Vl bXMgYQ0KPiA+ID4gPiA+ID5zZXJpb3VzIG1pc3Rha2UuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID5Zb3VycywNCj4gPiA+ID4gPiA+Sm9lbCBNLiBIYWxwZXJuDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID5BdCAwNTozNSBQTSA5LzIwLzIwMDMgLTA3MDAsIHlvdSB3cm90ZToNCj4gPiA+ID4gPiA+ ID5UaGUgdGV4dCBmb3IgdGhpcyByZXF1aXJlbWVudCBoYXMgYWx3YXlzIGJlZW4gaW50ZXItRkUN Cj4gPiA+ID4gPiB0b3BvbG9neSAoc2luY2UNCj4gPiA+ID4gPiA+ID52LTAyKS4NCj4gPiA+ID4g PiA+ID5JIGFtIHByZXR0eSBzdXJlIGJ1dCBJJ2xsIGNoZWNrIHdpdGggVG9kZCBhbnl3YXlzIG9u IHRoaXMuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+SWYgd2UgZG8gbm90IHByb3ZpZGUg cHJvdG9jb2wgbWVjaGFuaXNtcyB0byBzdXBwb3J0IHRoaXMsDQo+ID4gPiA+ID4gdGhlbiB0aGVy ZQ0KPiA+ID4gPiA+ID4gPndpbGwNCj4gPiA+ID4gPiA+ID5oYXZlIHRvIGJlIG5vbi1zdGFuZGFy ZCB3YXlzIHRvIG9idGFpbiB0aGlzIGluZm9ybWF0aW9uDQo+ID4gPiA+ID4gZnJvbSB0aGUgRkVz DQo+ID4gPiA+ID4gPiA+d2hpY2gNCj4gPiA+ID4gPiA+ID5wcm92aWRlIHRoaXMgaW5mbywgd2hp Y2ggd2Ugd291bGQgbGlrZSB0byBhdm9pZC4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID5U aGFua3MNCj4gPiA+ID4gPiA+ID5Ib3JtdXpkDQo+ID4gPiA+ID4NCj4gPiA+DQo+ From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 24 07:02:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06681 for ; Wed, 24 Sep 2003 07:02:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A27Q9-0001mW-00 for forces-archive@IETF.ORG; Wed, 24 Sep 2003 07:02:57 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A27Q8-0001mT-00 for forces-archive@IETF.ORG; Wed, 24 Sep 2003 07:02:56 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00BE339C@cherry.ease.lsoft.com>; Wed, 24 Sep 2003 7:02:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55879185 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Sep 2003 07:02:55 -0400 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 24 Sep 2003 07:02:54 -0400 Received: from localhost (hadi@localhost) by znyx.com (8.11.6/8.11.6) with ESMTP id h8OB3wK29291 for ; Wed, 24 Sep 2003 04:03:58 -0700 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Salim Message-ID: Date: Wed, 24 Sep 2003 04:03:58 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: Re: FW: Requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <005b01c3825b$e703da10$3d19fea9@wwm1> Precedence: list I was hoping to keep away from this discussion because it seemed to be going into cycles. The problem with all the rebutals to Joel seem to be centred around the world of L3 routing. If Forces is done right, L3 is merely an LFB. Any config about what nexthop a packet should head to are LFB specific .. etc. And the danger(to interoperability) with all this is there are is more than one way to do it. Insisting on Inter-FE topology info as part of the Forces protocol is too implementation specific and L3 (read: LFB) specific. The detail is trivial to add to a protocol (at least trivial for netlink2) - its whether it is useful in general or implementation specific. I wish someone would provide an example where it is useful. OTOH, there is a definete need to find out how the FEs and CEs within the NE are connected )nothing to do with LFBs). And there MAY be a need for the FE to know about these details - another implementation specific. Having said all that, I dont think we oughta go into details of how it should be implemented - whether as an FE attribute or a separate message (who cares). Both meet the requirement. And when it gets implemented whether it is done by teaching the FEs or these extra smart FEs somehow know all clever tricks they can pull off a hat. That is also implementation specific. I definetely think the requirement should be watered down to a lower case "should" or totaly removed. It's good to see the list alive once in a while. cheers, jamal On Wed, 24 Sep 2003, Weiming Wang wrote: > I don't think it needs to be changed a lot in current ForCES document. FE topology query and response messages in ForCES protocol can also be remained, only with the response message being added with an item to tell CE that the FE now can not tell the topology. > > We can treat the FE topology as a kind of FE attribute(which differs from LFB attributes and can be out of scope of FE model), but there's no harm to treat it just as FE topology. I don't think we need to save "message type" space, for they are enough. Actually FE capability is also a kind of FE attribute, but we seperate from it, which seems nicer. > > Regards, > weiming > > > ----- Original Message ----- > From: "Yang, Lily L" > To: > Sent: Wednesday, September 24, 2003 10:59 AM > Subject: Re: FW: Requirements > > > Ok, now I understand why you want to place it as FE attributes. But that seems at odd with the current assumptions FE model team is using to build the FE model. This seems like a partitioning problem -- someone has to take it, either 1)the FE model, or 2)the protocol, or 3) entirely outside of ForCES. > Logically, I don't think it belong to FE model, just like LFB (intra-FE) topology does not belong to LFB (that is, FE logical functional block) model. 2) seems like a reasonable solution because it shouldn't add terrible amount of complexity to ForCES protocol either. Pushing it entirely outside of ForCES might be an option too, but that might be a radical limitation to some people. > > Lily > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > > Sent: Tuesday, September 23, 2003 7:31 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: FW: Requirements > > > > > > I would tend to treat the entire issue of inter-FE topology > > as out of scope > > for the initial FORCES work. I would expect CEs to either be > > configured > > with the topology information, or to run any one of the many topology > > discovery protocols. > > This led me to consider it to be out of scope for the model. > > > > However, folks want some information about inter-FE topology > > to be within > > scope for FORCES. If so, I would place it as FE attributes. > > > > Yours, > > Joel M. Halpern > > > > At 07:14 PM 9/23/2003 -0700, you wrote: > > >Joel -- > > >But I thought we agree (at least within the FE model design > > team, from our > > >previous conference calls) that FE-topology is outside of > > the FE model, > > >and so inter-FE topology info is not going to be part of the > > FE attributes > > >as we define today. Therefore, explicit topology query/reply must be > > >provided by the base protocol itself, because you aren't > > going to get that > > >directly from FE model. > > >Now, having said that, I agree with you that IF some > > specialized LFB is > > >chartered with some kind of discovery function, then the FE > > topology info > > >can be indirectly but effectively gathered by querying the > > attributes of > > >such LFB -- but that is a big "IF" and is only one of the > > many possible > > >approaches. > > >So to cover the case when some FEs indeed have such topology > > info with > > >them, a simple topology query/reply will do the work. > > > > > >Oh, you don't need to apologize -- the most probable outcome > > of a "draft" > > >design is -- Oops, it doesn't work! Always better know that > > today than > > >tomorrow though. > > > > > >Lily > > > > > > > -----Original Message----- > > > > From: Forwarding and Control Element Separation > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > > > > Sent: Tuesday, September 23, 2003 6:54 PM > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > Subject: Re: FW: Requirements > > > > > > > > > > > > Actually, this implication is what concerns me. > > > > > > > > There must be a mechanism for the CE to query FE attributes. > > > > I would sincerely hope that such attributes would be extensible. > > > > It would seem sensible that one portion of those attributes > > > > could and would > > > > be used to reflect whatever knowledge about inter-FE topology > > > > the FE had. > > > > Thus, the information would be accessible. > > > > But there would not be a inter-FE topology query/reply in the > > > > protocol. > > > > The protocol would have FE attribute query / reply, which > > > > would cover many > > > > cases. > > > > > > > > Yours, > > > > Joel M. Halpern > > > > > > > > PS: I like your proposed rewording of the framework text. > > > > > > > > PPS: I truly am sorry to raise this so late. It wasn't until > > > > reviewing > > > > protocol proposals that I realized the implication of the > > > > requirements text. > > > > > > > > At 06:12 PM 9/23/2003 -0700, you wrote: > > > > >Our mail server has been acting very badly lately -- I > > > > didn't see this > > > > >email posted to the list even after 4 hours and so here it > > > > is again -- I > > > > >believe what I said here basically concurs with Avri and Ellen. > > > > > > > > > >-----Original Message----- > > > > >From: Yang, Lily L > > > > >Sent: Tuesday, September 23, 2003 1:52 PM > > > > >To: 'Forwarding and Control Element Separation' > > > > >Subject: RE: Requirements > > > > > > > > > > > > > > >Joel -- Sorry to ping you again when you are already tired > > > > of talking :-) > > > > > > > > > >When you said, "a) whether to fix the requirement in the > > > > I-D", did you > > > > >mean the architectural requirement (section 5, #10) or > > the protocol > > > > >requirement (section 7, #10), or both? I do believe there > > > > is different > > > > >implications here depending on which one you were talking about. > > > > > > > > > >What I heard so far on this thread is that some FEs may > > have inter-FE > > > > >topology info but all FEs do not. So the protocol MUST > > > > support "inter-FE > > > > >topology query/reply" in case some FEs are capable of > > > > providing that info > > > > >to CE. Architecturally, it is optional whether or not to use > > > > such protocol > > > > >mechanism -- as long as somehow CE can gather this > > > > infomation, either by > > > > >explicitly query over ForCES protocol, or by static > > > > configuration, or by > > > > >some dynamic discovery mechanism outside of ForCES. > > > > > > > > > >So I think a simple "inter-FE topology query/reply" is > > > > indeed required in > > > > >the ForCES protocol. But if FE can't provide that info, the > > > > burden is on > > > > >CE to gather that info by other means. > > > > > > > > > >I would like to see some consensus on this so that I can > > > > make sure the > > > > >framework draft accurately reflects it. > > > > > > > > > >Lily > > > > > > > > > > > -----Original Message----- > > > > > > From: Forwarding and Control Element Separation > > > > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel > > M. Halpern > > > > > > Sent: Tuesday, September 23, 2003 4:26 AM > > > > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > > > > Subject: Re: Requirements > > > > > > > > > > > > > > > > > > I do not agree that all FEs have this (inter-FE topology > > > > > > information). I > > > > > > have agreed that some FEs may have it. And that having > > > > standard FE > > > > > > attributes to represent this is probably useful. > > > > > > I do not agree that there is value in the requirement. It > > > > > > will not help us > > > > > > choose among protocols. It has already demonstrated a > > > > drive to cause > > > > > > protocol elements that are not needed. > > > > > > > > > > > > However, I have said enough for a while. The working group > > > > > > nee3ds to decide > > > > > > a) whether to fix the requirement in the I-D > > > > > > b) whether to clarify some other way what is needed / wanted > > > > > > to meet the > > > > > > requirement > > > > > > or whether the group actively likes the requirement. > > > > > > > > > > > > Yours, > > > > > > Joel M. Halpern > > > > > > > > > > > > At 10:50 PM 9/22/2003 -0700, you wrote: > > > > > > >Hi Joel > > > > > > > > > > > > > >I understand your concern regarding the architectural > > > > > > requirement (sec > > > > > > >5, #10) and I think we could clarify the text there, if still > > > > > > >possible...or may be use the Framework draft to clarify > > > > > > this? Lily, any > > > > > > >ideas? > > > > > > >However, I believe that the protocol requirement text is > > > > fine and it > > > > > > >should remain. From what I have heard so far, you agree that > > > > > > a) all FEs > > > > > > >have this info, b) some FEs might acquire this thru > > some inter-FE > > > > > > >discovery protocol or via FE manager and they should not > > > > be precluded > > > > > > >from ForCES, c) CE needs this info. If you agree with a, b & > > > > > > c then it > > > > > > >is natural to have some protocol mechanism to support this > > > > > > (whether it > > > > > > >is a general or special mechanism is a separate > > > > > > issue)...unless you want > > > > > > >to have a non-standard way to do this, which defeats the > > > > purpose of > > > > > > >ForCES. You have also agreed that it is ok to have > > some optional > > > > > > >mechanism for this. Now if you were in the Requirements > > > > team, which > > > > > > >unfortunately you were not :), would you rather > > define optional > > > > > > >requirements or mandatory ones ? This has a direct > > impact on the > > > > > > >protocol design and interoperability. > > > > > > > > > > > > > >Also, I don't remember there having been any arguments or big > > > > > > >discussions around this requirement before atleast in the > > > > > > design team. > > > > > > >The only feeback we had received was from the IESG was > > > > to clarify the > > > > > > >text in the Protocol Req section 7, which we did. > > > > > > > > > > > > > >I hope you will understand my point of view. > > > > > > >Thanks a lot > > > > > > >Hormuzd > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Forwarding and Control Element Separation > > > > > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of > > Joel M. Halpern > > > > > > >Sent: Saturday, September 20, 2003 5:57 PM > > > > > > >To: FORCES@PEACH.EASE.LSOFT.COM > > > > > > >Subject: Re: [FORCES] Requirements > > > > > > > > > > > > > >A large part of my problem with this requirement is > > that it leads > > > > > > >sensible > > > > > > >implementors (such as yourself) to think that they need > > > > > > special protocol > > > > > > >mechanisms to support this. It also leads sensible FE > > > > > > implementors to > > > > > > >think that they are somehow required to provide this > > > > implementation. > > > > > > > > > > > > > >1) FE's better not be required to provide inter-FE topology > > > > > > information. > > > > > > > > > > > > > >2) Allowing FEs which have such information to provide > > > > it does not > > > > > > >require > > > > > > >special protocol mechanisms in any reasonably designed > > > > protocol. CEs > > > > > > >will > > > > > > >need to ask FEs for many pieces of FE level information. > > > > If we must > > > > > > >have a > > > > > > >requirement in this area at all, it should be a requirement > > > > > > that the set > > > > > > >of > > > > > > >FE information a CE can query should include support > > for optional > > > > > > >information about inter-FE connectivity. (A CE should not > > > > > > be required > > > > > > >to > > > > > > >ask about this, an FE should not be required to provide > > > > this, and it > > > > > > >really > > > > > > >should not be treated as special information requiring > > > > > > special protocol > > > > > > >support mechanisms. > > > > > > > > > > > > > >Another way of looking at this is that there are > > many kinds of > > > > > > >information > > > > > > >that an FE might be able to provide that might or > > might not be > > > > > > >communicable > > > > > > >in the initial set of information mandated for CE-FE > > > > > > querying. For lots > > > > > > >of > > > > > > >reasons, the protocol MUST be extensible. Making > > support of this > > > > > > >information important relative to selecting / defining > > > > the protocol > > > > > > >seems a > > > > > > >serious mistake. > > > > > > > > > > > > > >Yours, > > > > > > >Joel M. Halpern > > > > > > > > > > > > > >At 05:35 PM 9/20/2003 -0700, you wrote: > > > > > > > >The text for this requirement has always been inter-FE > > > > > > topology (since > > > > > > > >v-02). > > > > > > > >I am pretty sure but I'll check with Todd anyways on this. > > > > > > > > > > > > > > > >If we do not provide protocol mechanisms to support this, > > > > > > then there > > > > > > > >will > > > > > > > >have to be non-standard ways to obtain this information > > > > > > from the FEs > > > > > > > >which > > > > > > > >provide this info, which we would like to avoid. > > > > > > > > > > > > > > > >Thanks > > > > > > > >Hormuzd > > > > > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 24 11:04:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20383 for ; Wed, 24 Sep 2003 11:04:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2BCF-0005cW-00 for forces-archive@IETF.ORG; Wed, 24 Sep 2003 11:04:51 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2BCE-0005cT-00 for forces-archive@IETF.ORG; Wed, 24 Sep 2003 11:04:50 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00BE391B@cherry.ease.lsoft.com>; Wed, 24 Sep 2003 11:04:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55892591 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Sep 2003 11:04:31 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 24 Sep 2003 11:04:31 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8NKnXF21584 for ; Tue, 23 Sep 2003 20:49:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8NKkWI16331 for ; Tue, 23 Sep 2003 20:46:32 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092313515322815 for ; Tue, 23 Sep 2003 13:51:53 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 23 Sep 2003 13:51:53 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Requirements Thread-Index: AcOBxXqtwLZLy0eyRMmvsOPRoYFv/wATFphA X-OriginalArrivalTime: 23 Sep 2003 20:51:53.0857 (UTC) FILETIME=[84FBFF10:01C38214] Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FEF3@orsmsx410.jf.intel.com> Date: Tue, 23 Sep 2003 13:51:53 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Joel -- Sorry to ping you again when you are already tired of talking = :-) When you said, "a) whether to fix the requirement in the I-D", did you = mean the architectural requirement (section 5, #10) or the protocol = requirement (section 7, #10), or both? I do believe there is different = implications here depending on which one you were talking about. What I heard so far on this thread is that some FEs may have inter-FE = topology info but all FEs do not. So the protocol MUST support "inter-FE = topology query/reply" in case some FEs are capable of providing that = info to CE. Architecturally, it is optional whether or not to use such = protocol mechanism -- as long as somehow CE can gather this infomation, = either by explicitly query over ForCES protocol, or by static = configuration, or by some dynamic discovery mechanism outside of ForCES. = So I think a simple "inter-FE topology query/reply" is indeed required = in the ForCES protocol. But if FE can't provide that info, the burden is = on CE to gather that info by other means.=20 I would like to see some consensus on this so that I can make sure the = framework draft accurately reflects it. Lily > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > Sent: Tuesday, September 23, 2003 4:26 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Requirements >=20 >=20 > I do not agree that all FEs have this (inter-FE topology=20 > information). I > have agreed that some FEs may have it. And that having standard FE > attributes to represent this is probably useful. > I do not agree that there is value in the requirement. It=20 > will not help us > choose among protocols. It has already demonstrated a drive to cause > protocol elements that are not needed. >=20 > However, I have said enough for a while. The working group=20 > nee3ds to decide > a) whether to fix the requirement in the I-D > b) whether to clarify some other way what is needed / wanted=20 > to meet the > requirement > or whether the group actively likes the requirement. >=20 > Yours, > Joel M. Halpern >=20 > At 10:50 PM 9/22/2003 -0700, you wrote: > >Hi Joel > > > >I understand your concern regarding the architectural=20 > requirement (sec > >5, #10) and I think we could clarify the text there, if still > >possible...or may be use the Framework draft to clarify=20 > this? Lily, any > >ideas? > >However, I believe that the protocol requirement text is fine and it > >should remain. From what I have heard so far, you agree that=20 > a) all FEs > >have this info, b) some FEs might acquire this thru some inter-FE > >discovery protocol or via FE manager and they should not be precluded > >from ForCES, c) CE needs this info. If you agree with a, b &=20 > c then it > >is natural to have some protocol mechanism to support this=20 > (whether it > >is a general or special mechanism is a separate=20 > issue)...unless you want > >to have a non-standard way to do this, which defeats the purpose of > >ForCES. You have also agreed that it is ok to have some optional > >mechanism for this. Now if you were in the Requirements team, which > >unfortunately you were not :), would you rather define optional > >requirements or mandatory ones ? This has a direct impact on the > >protocol design and interoperability. > > > >Also, I don't remember there having been any arguments or big > >discussions around this requirement before atleast in the=20 > design team. > >The only feeback we had received was from the IESG was to clarify the > >text in the Protocol Req section 7, which we did. > > > >I hope you will understand my point of view. > >Thanks a lot > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Saturday, September 20, 2003 5:57 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] Requirements > > > >A large part of my problem with this requirement is that it leads > >sensible > >implementors (such as yourself) to think that they need=20 > special protocol > >mechanisms to support this. It also leads sensible FE=20 > implementors to > >think that they are somehow required to provide this implementation. > > > >1) FE's better not be required to provide inter-FE topology=20 > information. > > > >2) Allowing FEs which have such information to provide it does not > >require > >special protocol mechanisms in any reasonably designed protocol. CEs > >will > >need to ask FEs for many pieces of FE level information. If we must > >have a > >requirement in this area at all, it should be a requirement=20 > that the set > >of > >FE information a CE can query should include support for optional > >information about inter-FE connectivity. (A CE should not=20 > be required > >to > >ask about this, an FE should not be required to provide this, and it > >really > >should not be treated as special information requiring=20 > special protocol > >support mechanisms. > > > >Another way of looking at this is that there are many kinds of > >information > >that an FE might be able to provide that might or might not be > >communicable > >in the initial set of information mandated for CE-FE=20 > querying. For lots > >of > >reasons, the protocol MUST be extensible. Making support of this > >information important relative to selecting / defining the protocol > >seems a > >serious mistake. > > > >Yours, > >Joel M. Halpern > > > >At 05:35 PM 9/20/2003 -0700, you wrote: > > >The text for this requirement has always been inter-FE=20 > topology (since > > >v-02). > > >I am pretty sure but I'll check with Todd anyways on this. > > > > > >If we do not provide protocol mechanisms to support this,=20 > then there > > >will > > >have to be non-standard ways to obtain this information=20 > from the FEs > > >which > > >provide this info, which we would like to avoid. > > > > > >Thanks > > >Hormuzd >=20 From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 24 16:18:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05882 for ; Wed, 24 Sep 2003 16:18:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2G5W-00022h-00 for forces-archive@IETF.ORG; Wed, 24 Sep 2003 16:18:14 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2G5U-000226-00 for forces-archive@IETF.ORG; Wed, 24 Sep 2003 16:18:12 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00BE3FEB@cherry.ease.lsoft.com>; Wed, 24 Sep 2003 16:17:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55919027 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Sep 2003 16:16:33 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 24 Sep 2003 16:16:32 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8OKEAO12491 for ; Wed, 24 Sep 2003 20:14:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8OKB7803881 for ; Wed, 24 Sep 2003 20:11:07 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092413162921443 for ; Wed, 24 Sep 2003 13:16:29 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 24 Sep 2003 13:16:27 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C382D8.BC11903A" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: yes Thread-Topic: framework v09 uploaded, ready for IESG review Thread-Index: AcOC2LwMzzGmGGbDTuOzZ727kIhSFQ== X-OriginalArrivalTime: 24 Sep 2003 20:16:27.0892 (UTC) FILETIME=[BC393B40:01C382D8] Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FF08@orsmsx410.jf.intel.com> Date: Wed, 24 Sep 2003 13:16:27 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: framework v09 uploaded, ready for IESG review To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C382D8.BC11903A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 I just uploaded v09 of the framework draft. There are limited changes = comparing to v08, and all are driven by discussion in the mailing list. = Here is a summary of the changes.=20 1) Section 3.2 End of first paragraph: clarify virtualization's = potential impact on ForCES. 2) 2) end of Section 3.2: clarify on the FE topology info gathering: 3) Section 4.2.1: clarify proximity focus on "very close". 4)"Section 4.3.2: point out the impact on FE topology due to the FE = up/down event 5) Section 8.2.3: clarify around multicast security issue The detailed [old] versus [new] text are provided below for your = evaluation. Lily <>=20 -------------------------------------------Detailed change log = ---------- 1) Section 3.2 End of first paragraph: clarify virtualization's = potential impact on ForCES. [old] "FE virtualization should occur only in the pre-association phase = and hence has no impact on ForCES."=20 [new] "If FE virtualization occur only in the pre-association phase, it = has no impact on ForCES. However, if FE virtualization results in = dynamic resource change on FE during post-associaiton phase, the FE = model needs to be able to report such capability and the ForCES protocol = needs to be able to inform the CE of such change via asynchrounous = messages."=20 2) end of Section 3.2: clarify on the FE topology info gathering: [old] When it is necessary to forward packets between FEs, the CE = needs to understand the FE topology. The FE topology can be queried = from the FEs by CEs.=20 [new] When it is necessary to forward packets between FEs, the CE = needs to understand the FE topology. The FE topology may be queried = from the FEs by the CEs via ForCES protocol, but all the FEs are not = required to provide that information to the CEs. So the FE topology = information may also be gathered by other means outside of the ForCES = protocol (like inter-FE topology discovery protocol).=20 3) Section 4.2.1: clarify proximity focus on "very close". [old] "The ForCES Working Group has made a conscious decision that the = first version of ForCES will not be designed to support configurations = where the CE and FE are located arbitrarily in the network. In = particular, ForCES is intended for "very close" CE/FE localities in IP = networks, as defined by ForCES Applicability Statement ([7]). "=20 [new] "The ForCES Working Group has made a conscious decision that the = first version of ForCES will be focused on very close" CE/FE localities = in IP networks, as defined by ForCES Applicability Statement ([7]). "=20 4)"Section 4.3.2: point out the impact on FE topology due to the FE = up/down event 4.3.2 Add a sentence at the end of the first paragraph:=20 [new] "When an FE leaves or join an existing NE that is already in = post-association phase, the CE needs to be aware of the impact on FE = topology and deals with the change accordingly. "=20 5) Section 8.2.3: on multicast security [old]"IPsec can support both unicast and multicast transport. When = multicast is used, IPsec can be used with manual keying with no replay = protection and no automatic rekeying. This meets the confidentiality = and integrity requirements. Multicast-based solutions relying on IPsec = should specify how rekeying and replay protection are provided. " [new] "IPsec can support both unicast and multicast transport. At the = time this document was published, MSEC working group is actively working = on standardizing protocols to provide multicast security [17]. = Multicast-based solutions relying on IPsec should specify how to meet = the security requirements in [3]."=20 ------_=_NextPart_001_01C382D8.BC11903A Content-Type: text/plain; name="draft-ietf-forces-framework-09.txt" Content-Description: draft-ietf-forces-framework-09.txt Content-Disposition: attachment; filename="draft-ietf-forces-framework-09.txt" Content-Transfer-Encoding: base64 DQogICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTC4gWWFuZyANCiAgICBFeHBpcmF0aW9uOiBNYXJjaCAyMDA0ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEludGVsIENvcnAuIA0KICAgIEZpbGU6IGRyYWZ0LWlldGYt Zm9yY2VzLWZyYW1ld29yay0wOS50eHQgICAgICAgICAgICAgICAgICAgUi4gRGFudHUgDQogICAg V29ya2luZyBHcm91cDogRm9yQ0VTICAgICAgICAgICAgICAgICAgICAgICAgICBVbml2LiBvZiBO b3J0aCBUZXhhcyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFQuIEFuZGVyc29uIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW50ZWwgQ29ycC4gDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBH b3BhbCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE5va2lhIA0KICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAyMDAzIA0KICANCiAgICAg ICAgRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykgRnJh bWV3b3JrIA0KICAgICANCiAgICAgDQogICAgIA0KICAgICAgICAgICAgICAgICAgICBkcmFmdC1p ZXRmLWZvcmNlcy1mcmFtZXdvcmstMDkudHh0IA0KICAgICANCiAgICAgDQogICAgIA0KICAgICAN CiBTdGF0dXMgb2YgdGhpcyBNZW1vIA0KICAgICANCiAgICBUaGlzIGRvY3VtZW50IGlzIGFuIElu dGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggDQogICAgYWxsIHBy b3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2LiAgSW50ZXJuZXQtRHJhZnRzIGFyZSAN CiAgICB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBG b3JjZSAoSUVURiksIA0KICAgIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5v dGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gDQogICAgZGlzdHJpYnV0ZSB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuIA0KICAgICANCiAgICBJbnRlcm5ldC1EcmFmdHMg YXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCANCiAgICBtb250 aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIA0K ICAgIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIElu dGVybmV0LURyYWZ0cyANCiAgICBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgYGB3b3JrIGluIA0KICAgIHByb2dyZXNzLicnIA0KICAgICANCiAgICBU aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgDQog ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiANCiAgICAgDQog ICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBh Y2Nlc3NlZCBhdCAgDQogICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogICAg IA0KIENvcHlyaWdodCBOb3RpY2UgIA0KICAgICANCiAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRl cm5ldCBTb2NpZXR5ICgyMDAzKS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIA0KICAgICANCiBBYnN0 cmFjdCANCiAgDQogICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBhcmNoaXRlY3R1cmFsIGZy YW1ld29yayBmb3IgdGhlIEZvckNFUyANCiAgICAoRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVt ZW50IFNlcGFyYXRpb24pIG5ldHdvcmsgZWxlbWVudHMsIGFuZCANCiAgICBpZGVudGlmaWVzIHRo ZSBhc3NvY2lhdGVkIGVudGl0aWVzIGFuZCB0aGUgaW50ZXJhY3Rpb25zIGFtb25nIHRoZW0uIA0K ICAgICANCiBUYWJsZSBvZiBDb250ZW50cyANCiAgDQogICANCiBJbnRlcm5ldCBEcmFmdCAgICAg ICAgIEZvckNFUyBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAyMDAzIA0KICAN CiAgDQogICAgIA0KICAgIDEuIERlZmluaXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgICAyLiBJbnRyb2R1Y3Rpb24gdG8gRm9yd2Fy ZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gDQogICAgKEZvckNFUykuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41IA0KICAg IDMuIEFyY2hpdGVjdHVyZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uOSANCiAgICAgICAzLjEuIENvbnRyb2wgRWxlbWVudHMgYW5kIEZyIFJlZmVyZW5j ZSBQb2ludC4uLi4uLi4uLi4uLi4uLi4uMTAgDQogICAgICAgMy4yLiBGb3J3YXJkaW5nIEVsZW1l bnRzIGFuZCBGaSByZWZlcmVuY2UgcG9pbnQuLi4uLi4uLi4uLi4uLjExIA0KICAgICAgIDMuMy4g Q0UgTWFuYWdlcnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4x NCANCiAgICAgICAzLjQuIEZFIE1hbmFnZXJzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMTQgDQogICAgNC4gT3BlcmF0aW9uYWwgUGhhc2VzLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE1IA0KICAgICAgIDQuMS4gUHJlLWFzc29j aWF0aW9uIFBoYXNlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNSANCiAgICAg ICAgICA0LjEuMS4gRmwgUmVmZXJlbmNlIFBvaW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTUgDQogICAgICAgICAgNC4xLjIuIEZmIFJlZmVyZW5jZSBQb2ludC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2IA0KICAgICAgICAgIDQuMS4zLiBGYyBSZWZlcmVuY2Ug UG9pbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNyANCiAgICAgICA0LjIuIFBv c3QtYXNzb2NpYXRpb24gUGhhc2UgYW5kIEZwIHJlZmVyZW5jZSBwb2ludC4uLi4uLi4uLi4uMTcg DQogICAgICAgICAgNC4yLjEuIFByb3hpbWl0eSBhbmQgSW50ZXJjb25uZWN0IGJldHdlZW4gQ0Vz IGFuZCBGRXMuLi4uLjE3IA0KICAgICAgICAgIDQuMi4yLiBBc3NvY2lhdGlvbiBFc3RhYmxpc2ht ZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xOCANCiAgICAgICAgICA0LjIuMy4gU3RlYWR5 LXN0YXRlIENvbW11bmljYXRpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkgDQogICAgICAg ICAgNC4yLjQuIERhdGEgUGFja2V0cyBhY3Jvc3MgRnAgcmVmZXJlbmNlIHBvaW50Li4uLi4uLi4u Li4uLjIwIA0KICAgICAgICAgIDQuMi41LiBQcm94eSBGRS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4yMSANCiAgICAgICA0LjMuIEFzc29jaWF0aW9uIFJlLWVzdGFi bGlzaG1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjEgDQogICAgICAgICAgNC4zLjEu IENFIGdyYWNlZnVsIHJlc3RhcnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIyIA0K ICAgICAgICAgIDQuMy4yLiBGRSByZXN0YXJ0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4yMyANCiAgICA1LiBBcHBsaWNhYmlsaXR5IHRvIFJGQzE4MTIuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjQgDQogICAgICAgNS4xLiBHZW5lcmFsIFJvdXRl ciBSZXF1aXJlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI0IA0KICAgICAgIDUu Mi4gTGluayBMYXllci4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4yNiANCiAgICAgICA1LjMuIEludGVybmV0IExheWVyIFByb3RvY29scy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMjYgDQogICAgICAgNS40LiBJbnRlcm5ldCBMYXllciBGb3J3YXJk aW5nLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI3IA0KICAgICAgIDUuNS4gVHJhbnNw b3J0IExheWVyLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yOCANCiAg ICAgICA1LjYuIEFwcGxpY2F0aW9uIExheWVyIC0tIFJvdXRpbmcgUHJvdG9jb2xzLi4uLi4uLi4u Li4uLi4uLi4uMjggDQogICAgICAgNS43LiBBcHBsaWNhdGlvbiBMYXllciAtLSBOZXR3b3JrIE1h bmFnZW1lbnQgUHJvdG9jb2wuLi4uLi4uLjI4IA0KICAgIDYuIFN1bW1hcnkuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yOSANCiAgICA3LiBBY2tu b3dsZWRnZW1lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MjkgDQogICAgOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjI5IA0KICAgICAgIDguMS4gQW5hbHlzaXMgb2YgUG90ZW50aWFsIFRo cmVhdHMgSW50cm9kdWNlZCBieSBGb3JDRVMuLi4uLi4zMCANCiAgICAgICAgICA4LjEuMS4gIkpv aW4iIG9yICJSZW1vdmUiIE1lc3NhZ2UgRmxvb2Rpbmcgb24gQ0VzLi4uLi4uLi4uMzAgDQogICAg ICAgICAgOC4xLjIuIEltcGVyc29uYXRpb24gQXR0YWNrLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjMwIA0KICAgICAgICAgIDguMS4zLiBSZXBsYXkgQXR0YWNrLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zMCANCiAgICAgICAgICA4LjEuNC4gQXR0YWNrIGR1cmlu ZyBGYWlsIE92ZXIuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzEgDQogICAgICAgICAgOC4x LjUuIERhdGEgSW50ZWdyaXR5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMx IA0KICAgICAgICAgIDguMS42LiBEYXRhIENvbmZpZGVudGlhbGl0eS4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4zMSANCiAgICAgICAgICA4LjEuNy4gU2hhcmluZyBzZWN1cml0eSBwYXJh bWV0ZXJzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzIgDQogICAgICAgICAgOC4xLjguIERlbmlh bCBvZiBTZXJ2aWNlIEF0dGFjayB2aWEgRXh0ZXJuYWwgSW50ZXJmYWNlLi4uLjMyIA0KICAgICAg IDguMi4gU2VjdXJpdHkgUmVjb21tZW5kYXRpb25zIGZvciBGb3JDRVMuLi4uLi4uLi4uLi4uLi4u Li4uLi4zMiANCiAgICAgICAgICA4LjIuMS4gU2VjdXJpdHkgQ29uZmlndXJhdGlvbi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMzMgDQogICAgICAgICAgOC4yLjIuIFVzaW5nIFRMUyB3aXRo IEZvckNFUy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMzIA0KICAgICAgICAgIDguMi4z LiBVc2luZyBJUHNlYyB3aXRoIEZvckNFUy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zNCAN CiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgTWFyY2ggICAgMjAwNCAgICAgICAg ICAgICAgICAgICBbUGFnZSAyXSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZy YW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAgICA5LiBO b3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMzYgDQogICAgMTAuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjM2IA0KICAgIDExLiBBdXRob3JzJyBBZGRyZXNzZXMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zNyANCiAgICAxMi4gSW50ZWxsZWN0 dWFsIFByb3BlcnR5IFJpZ2h0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzggDQog ICAgMTMuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjM4IA0KICAgICANCiAgICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1l bnQgIA0KICAgICAgICAgDQogICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCANCiAgICAiU0hPVUxEIiwgIlNIT1VMRCBO T1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIA0KICAgIHRoaXMg ZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOS4g DQogICAgIA0KIDEuIERlZmluaXRpb25zIA0KICAgICANCiAgICBBIHNldCBvZiB0ZXJtaW5vbG9n eSBhc3NvY2lhdGVkIHdpdGggdGhlIEZvckNFUyByZXF1aXJlbWVudHMgaXMgDQogICAgZGVmaW5l ZCBpbiBbM10gYW5kIHdlIG9ubHkgaW5jbHVkZSB0aGUgZGVmaW5pdGlvbnMgdGhhdCBhcmUgbW9z dCANCiAgICByZWxldmFudCB0byB0aGlzIGRvY3VtZW50IGhlcmUuICANCiAgICAgDQogICAgQWRk cmVzc2FibGUgRW50aXR5IChBRSkgLSBBbiBlbnRpdHkgdGhhdCBpcyBkaXJlY3RseSBhZGRyZXNz YWJsZSANCiAgICBnaXZlbiBzb21lIGludGVyY29ubmVjdCB0ZWNobm9sb2d5LiAgRm9yIGV4YW1w bGUsIG9uIElQIG5ldHdvcmtzLCANCiAgICBpdCBpcyBhIGRldmljZSB0byB3aGljaCB3ZSBjYW4g Y29tbXVuaWNhdGUgdXNpbmcgYW4gSVAgYWRkcmVzczsgb24gDQogICAgYSBzd2l0Y2ggZmFicmlj LCBpdCBpcyBhIGRldmljZSB0byB3aGljaCB3ZSBjYW4gY29tbXVuaWNhdGUgdXNpbmcgYSANCiAg ICBzd2l0Y2ggZmFicmljIHBvcnQgbnVtYmVyLiAgDQogICAgIA0KICAgIFBoeXNpY2FsIEZvcndh cmRpbmcgRWxlbWVudCAoUEZFKSAtIEFuIEFFIHRoYXQgaW5jbHVkZXMgaGFyZHdhcmUgDQogICAg dXNlZCB0byBwcm92aWRlIHBlci1wYWNrZXQgcHJvY2Vzc2luZyBhbmQgaGFuZGxpbmcuICBUaGlz IGhhcmR3YXJlIA0KICAgIG1heSBjb25zaXN0IG9mIChidXQgaXMgbm90IGxpbWl0ZWQgdG8pIG5l dHdvcmsgcHJvY2Vzc29ycywgQVNJQ3MgDQogICAgKEFwcGxpY2F0aW9uLVNwZWNpZmljIEludGVn cmF0ZWQgQ2lyY3VpdHMpLCBvciBnZW5lcmFsIHB1cnBvc2UgDQogICAgcHJvY2Vzc29ycywgaW5z dGFsbGVkIG9uIGxpbmUgY2FyZHMsIGRhdWdodGVyIGJvYXJkcywgbWV6emFuaW5lIA0KICAgIGNh cmRzLCBvciBpbiBzdGFuZC1hbG9uZSBib3hlcy4gDQogICAgICAgICANCiAgICBQRkUgUGFydGl0 aW9uIC0gQSBsb2dpY2FsIHBhcnRpdGlvbiBvZiBhIFBGRSBjb25zaXN0aW5nIG9mIHNvbWUgDQog ICAgc3Vic2V0IG9mIGVhY2ggb2YgdGhlIHJlc291cmNlcyAoZS5nLiwgcG9ydHMsIG1lbW9yeSwg Zm9yd2FyZGluZyANCiAgICB0YWJsZSBlbnRyaWVzKSBhdmFpbGFibGUgb24gdGhlIFBGRS4gIFRo aXMgY29uY2VwdCBpcyBhbmFsb2dvdXMgdG8gDQogICAgdGhhdCBvZiB0aGUgcmVzb3VyY2VzIGFz c2lnbmVkIHRvIGEgdmlydHVhbCBzd2l0Y2hpbmcgZWxlbWVudCBhcyANCiAgICBkZXNjcmliZWQg aW4gWzhdLiAgDQogICAgICAgICANCiAgICBQaHlzaWNhbCBDb250cm9sIEVsZW1lbnQgKFBDRSkg LSBBbiBBRSB0aGF0IGluY2x1ZGVzIGhhcmR3YXJlIHVzZWQgDQogICAgdG8gcHJvdmlkZSBjb250 cm9sIGZ1bmN0aW9uYWxpdHkuICBUaGlzIGhhcmR3YXJlIHR5cGljYWxseSBpbmNsdWRlcyANCiAg ICBhIGdlbmVyYWwgcHVycG9zZSBwcm9jZXNzb3IuICANCiAgICAgICAgIA0KICAgIFBDRSBQYXJ0 aXRpb24gLSBBIGxvZ2ljYWwgcGFydGl0aW9uIG9mIGEgUENFIGNvbnNpc3Rpbmcgb2Ygc29tZSAN CiAgICBzdWJzZXQgb2YgZWFjaCBvZiB0aGUgcmVzb3VyY2VzIGF2YWlsYWJsZSBvbiB0aGUgUENF LiAgDQogICAgICAgICANCiAgICBGb3J3YXJkaW5nIEVsZW1lbnQgKEZFKSAtIEEgbG9naWNhbCBl bnRpdHkgdGhhdCBpbXBsZW1lbnRzIHRoZSANCiAgICBGb3JDRVMgcHJvdG9jb2wuICBGRXMgdXNl IHRoZSB1bmRlcmx5aW5nIGhhcmR3YXJlIHRvIHByb3ZpZGUgcGVyLQ0KICAgIHBhY2tldCBwcm9j ZXNzaW5nIGFuZCBoYW5kbGluZyBhcyBkaXJlY3RlZCBieSBhIENFIHZpYSB0aGUgRm9yQ0VTIA0K ICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAgICAgICAg ICAgICAgICAgIFtQYWdlIDNdICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJh bWV3b3JrICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0KICAgIHByb3Rv Y29sLiAgRkVzIG1heSBoYXBwZW4gdG8gYmUgYSBzaW5nbGUgYmxhZGUgKG9yIFBGRSksIGEgDQog ICAgcGFydGl0aW9uIG9mIGEgUEZFIG9yIG11bHRpcGxlIFBGRXMuIA0KICAgICANCiAgICBDb250 cm9sIEVsZW1lbnQgKENFKSAtIEEgbG9naWNhbCBlbnRpdHkgdGhhdCBpbXBsZW1lbnRzIHRoZSBG b3JDRVMgDQogICAgcHJvdG9jb2wgYW5kIHVzZXMgaXQgdG8gaW5zdHJ1Y3Qgb25lIG9yIG1vcmUg RkVzIGhvdyB0byBwcm9jZXNzIA0KICAgIHBhY2tldHMuICBDRXMgaGFuZGxlIGZ1bmN0aW9uYWxp dHkgc3VjaCBhcyB0aGUgZXhlY3V0aW9uIG9mIGNvbnRyb2wgDQogICAgYW5kIHNpZ25hbGluZyBw cm90b2NvbHMuICBDRXMgbWF5IGNvbnNpc3Qgb2YgUENFIHBhcnRpdGlvbnMgb3IgDQogICAgd2hv bGUgUENFcy4gDQogICAgICAgICANCiAgICBGb3JDRVMgTmV0d29yayBFbGVtZW50IChORSkgLSBB biBlbnRpdHkgY29tcG9zZWQgb2Ygb25lIG9yIG1vcmUgQ0VzIA0KICAgIGFuZCBvbmUgb3IgbW9y ZSBGRXMuICBUbyBlbnRpdGllcyBvdXRzaWRlIGFuIE5FLCB0aGUgTkUgcmVwcmVzZW50cyANCiAg ICBhIHNpbmdsZSBwb2ludCBvZiBtYW5hZ2VtZW50LiAgU2ltaWxhcmx5LCBhbiBORSB1c3VhbGx5 IGhpZGVzIGl0cyANCiAgICBpbnRlcm5hbCBvcmdhbml6YXRpb24gZnJvbSBleHRlcm5hbCBlbnRp dGllcy4gIA0KICAgICAgICAgDQogICAgUHJlLWFzc29jaWF0aW9uIFBoYXNlIC0gVGhlIHBlcmlv ZCBvZiB0aW1lIGR1cmluZyB3aGljaCBhbiBGRSANCiAgICBNYW5hZ2VyIChzZWUgYmVsb3cpIGFu ZCBhIENFIE1hbmFnZXIgKHNlZSBiZWxvdykgYXJlIGRldGVybWluaW5nIA0KICAgIHdoaWNoIEZF IGFuZCBDRSBzaG91bGQgYmUgcGFydCBvZiB0aGUgc2FtZSBuZXR3b3JrIGVsZW1lbnQuIA0KICAg ICAgICAgDQogICAgUG9zdC1hc3NvY2lhdGlvbiBQaGFzZSAtIFRoZSBwZXJpb2Qgb2YgdGltZSBk dXJpbmcgd2hpY2ggYW4gRkUgZG9lcyANCiAgICBrbm93IHdoaWNoIENFIGlzIHRvIGNvbnRyb2wg aXQgYW5kIHZpY2UgdmVyc2EsIGluY2x1ZGluZyB0aGUgdGltZSANCiAgICBkdXJpbmcgd2hpY2gg dGhlIENFIGFuZCBGRSBhcmUgZXN0YWJsaXNoaW5nIGNvbW11bmljYXRpb24gd2l0aCBvbmUgDQog ICAgYW5vdGhlci4gIA0KICAgICAgICAgDQogICAgRm9yQ0VTIFByb3RvY29sIC0gV2hpbGUgdGhl cmUgbWF5IGJlIG11bHRpcGxlIHByb3RvY29scyB1c2VkIHdpdGhpbiANCiAgICB0aGUgb3ZlcmFs bCBGb3JDRVMgYXJjaGl0ZWN0dXJlLCB0aGUgdGVybSAiRm9yQ0VTIHByb3RvY29sIiByZWZlcnMg DQogICAgb25seSB0byB0aGUgRm9yQ0VTIHBvc3QtYXNzb2NpYXRpb24gcGhhc2UgcHJvdG9jb2wg KHNlZSBiZWxvdykuICANCiAgICAgICAgIA0KICAgIEZvckNFUyBQb3N0LUFzc29jaWF0aW9uIFBo YXNlIFByb3RvY29sIC0gVGhlIHByb3RvY29sIHVzZWQgZm9yIA0KICAgIHBvc3QtYXNzb2NpYXRp b24gcGhhc2UgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIENFcyBhbmQgRkVzLiAgVGhpcyANCiAgICBw cm90b2NvbCBkb2VzIG5vdCBhcHBseSB0byBDRS10by1DRSBjb21tdW5pY2F0aW9uLCBGRS10by1G RSANCiAgICBjb21tdW5pY2F0aW9uLCBub3IgdG8gY29tbXVuaWNhdGlvbiBiZXR3ZWVuIEZFIGFu ZCBDRSBtYW5hZ2Vycy4gIA0KICAgIFRoZSBGb3JDRVMgcHJvdG9jb2wgaXMgYSBtYXN0ZXItc2xh dmUgcHJvdG9jb2wgaW4gd2hpY2ggRkVzIGFyZSANCiAgICBzbGF2ZXMgYW5kIENFcyBhcmUgbWFz dGVycy4gICBUaGlzIHByb3RvY29sIGluY2x1ZGVzIGJvdGggdGhlIA0KICAgIG1hbmFnZW1lbnQg b2YgdGhlIGNvbW11bmljYXRpb24gY2hhbm5lbCAoZS5nLiwgY29ubmVjdGlvbiANCiAgICBlc3Rh Ymxpc2htZW50LCBoZWFydGJlYXRzKSBhbmQgdGhlIGNvbnRyb2wgbWVzc2FnZXMgdGhlbXNlbHZl cy4gIA0KICAgIFRoaXMgcHJvdG9jb2wgY291bGQgYmUgYSBzaW5nbGUgcHJvdG9jb2wgb3IgY291 bGQgY29uc2lzdCBvZiANCiAgICBtdWx0aXBsZSBwcm90b2NvbHMgd29ya2luZyB0b2dldGhlciwg YW5kIG1heSBiZSB1bmljYXN0IGJhc2VkIG9yIA0KICAgIG11bHRpY2FzdCBiYXNlZC4gQSBzZXBh cmF0ZSBwcm90b2NvbCBkb2N1bWVudCB3aWxsIHNwZWNpZnkgdGhpcyANCiAgICBpbmZvcm1hdGlv bi4gDQogICAgICAgICANCiAgICBGRSBNYW5hZ2VyIC0gQSBsb2dpY2FsIGVudGl0eSB0aGF0IG9w ZXJhdGVzIGluIHRoZSBwcmUtYXNzb2NpYXRpb24gDQogICAgcGhhc2UgYW5kIGlzIHJlc3BvbnNp YmxlIGZvciBkZXRlcm1pbmluZyB0byB3aGljaCBDRShzKSBhbiBGRSANCiAgICBzaG91bGQgY29t bXVuaWNhdGUuICBUaGlzIHByb2Nlc3MgaXMgY2FsbGVkIENFIGRpc2NvdmVyeSBhbmQgbWF5IA0K ICAgIGludm9sdmUgdGhlIEZFIG1hbmFnZXIgbGVhcm5pbmcgdGhlIGNhcGFiaWxpdGllcyBvZiBh dmFpbGFibGUgQ0VzLiAgDQogICAgQW4gRkUgbWFuYWdlciBtYXkgdXNlIGFueXRoaW5nIGZyb20g YSBzdGF0aWMgY29uZmlndXJhdGlvbiB0byBhIA0KICAgIHByZS1hc3NvY2lhdGlvbiBwaGFzZSBw cm90b2NvbCAoc2VlIGJlbG93KSB0byBkZXRlcm1pbmUgd2hpY2ggQ0UocykgDQogICAgdG8gdXNl OyBob3dldmVyLCB0aGlzIGlzIGN1cnJlbnRseSBvdXQgb2Ygc2NvcGUuICBCZWluZyBhIGxvZ2lj YWwgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIE1hcmNoICAgIDIwMDQgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNF0gICANCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNF UyBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAyMDAzIA0KICANCiAgDQogICAg ZW50aXR5LCBhbiBGRSBtYW5hZ2VyIG1pZ2h0IGJlIHBoeXNpY2FsbHkgY29tYmluZWQgd2l0aCBh bnkgb2YgdGhlIA0KICAgIG90aGVyIGxvZ2ljYWwgZW50aXRpZXMgbWVudGlvbmVkIGluIHRoaXMg c2VjdGlvbi4gIA0KICAgICAgICAgDQogICAgQ0UgTWFuYWdlciAtIEEgbG9naWNhbCBlbnRpdHkg dGhhdCBvcGVyYXRlcyBpbiB0aGUgcHJlLWFzc29jaWF0aW9uICANCiAgICBwaGFzZSBhbmQgaXMg cmVzcG9uc2libGUgZm9yIGRldGVybWluaW5nIHRvIHdoaWNoIEZFKHMpIGEgQ0Ugc2hvdWxkIA0K ICAgIGNvbW11bmljYXRlLiAgVGhpcyBwcm9jZXNzIGlzIGNhbGxlZCBGRSBkaXNjb3ZlcnkgYW5k IG1heSBpbnZvbHZlIA0KICAgIHRoZSBDRSBtYW5hZ2VyIGxlYXJuaW5nIHRoZSBjYXBhYmlsaXRp ZXMgb2YgYXZhaWxhYmxlIEZFcy4gIEEgQ0UgDQogICAgbWFuYWdlciBtYXkgdXNlIGFueXRoaW5n IGZyb20gYSBzdGF0aWMgY29uZmlndXJhdGlvbiB0byBhIHByZS0NCiAgICBhc3NvY2lhdGlvbiBw aGFzZSBwcm90b2NvbCAoc2VlIGJlbG93KSB0byBkZXRlcm1pbmUgd2hpY2ggRkUgdG8gDQogICAg dXNlLCBob3dldmVyIHRoaXMgaXMgY3VycmVudGx5IG91dCBvZiBzY29wZS4gICBCZWluZyBhIGxv Z2ljYWwgDQogICAgZW50aXR5LCBhIENFIG1hbmFnZXIgbWlnaHQgYmUgcGh5c2ljYWxseSBjb21i aW5lZCB3aXRoIGFueSBvZiB0aGUgDQogICAgb3RoZXIgbG9naWNhbCBlbnRpdGllcyBtZW50aW9u ZWQgaW4gdGhpcyBzZWN0aW9uLiAgDQogICAgICAgICANCiAgICBQcmUtYXNzb2NpYXRpb24gUGhh c2UgUHJvdG9jb2wgLSBBIHByb3RvY29sIGJldHdlZW4gRkUgbWFuYWdlcnMgYW5kIA0KICAgIENF IG1hbmFnZXJzIHRoYXQgaXMgdXNlZCB0byBkZXRlcm1pbmUgd2hpY2ggQ0VzIG9yIEZFcyB0byB1 c2UuICBBIA0KICAgIHByZS1hc3NvY2lhdGlvbiBwaGFzZSBwcm90b2NvbCBtYXkgaW5jbHVkZSBh IENFIGFuZC9vciBGRSANCiAgICBjYXBhYmlsaXR5IGRpc2NvdmVyeSBtZWNoYW5pc20uICBOb3Rl IHRoYXQgdGhpcyBjYXBhYmlsaXR5IA0KICAgIGRpc2NvdmVyeSBwcm9jZXNzIGlzIHdob2xseSBz ZXBhcmF0ZSBmcm9tIChhbmQgZG9lcyBub3QgcmVwbGFjZSkgDQogICAgdGhhdCB1c2VkIHdpdGhp biB0aGUgRm9yQ0VTIHByb3RvY29sLiAgSG93ZXZlciwgdGhlIHR3byBjYXBhYmlsaXR5IA0KICAg IGRpc2NvdmVyeSBtZWNoYW5pc21zIG1heSB1dGlsaXplIHRoZSBzYW1lIEZFIG1vZGVsLiAgIA0K ICAgICAgICAgDQogICAgRkUgTW9kZWwgLSBBIG1vZGVsIHRoYXQgZGVzY3JpYmVzIHRoZSBsb2dp Y2FsIHByb2Nlc3NpbmcgZnVuY3Rpb25zIA0KICAgIG9mIGFuIEZFLiAgDQogICAgICAgICANCiAg ICBGb3JDRVMgUHJvdG9jb2wgRWxlbWVudCAtIEFuIEZFIG9yIENFLiAgDQogICAgIA0KICAgIElu dHJhLUZFIHRvcG9sb2d5IC0NICAgICAgICAgICAgICAgICAgICAgIC0gUmVwcmVzZW50YXRpb24g b2YgaG93IGEgc2luZ2xlIEZFIGlzIHJlYWxpemVkIA0KICAgIGJ5IGNvbWJpbmluZyBwb3NzaWJs eSBtdWx0aXBsZSBsb2dpY2FsIGZ1bmN0aW9uYWwgYmxvY2tzIGFsb25nIA0KICAgIG11bHRpcGxl IGRhdGEgcGF0aC4gVGhpcyBpcyBkZWZpbmVkIGJ5IHRoZSBGRSBtb2RlbC4gIA0KICANCiAgICBG RSBUb3BvbG9neSAtLSBSZXByZXNlbnRhdGlvbiBvZiBob3cgdGhlIG11bHRpcGxlIEZFcyBpbiBh IHNpbmdsZSANCiAgICBORSBhcmUgaW50ZXJjb25uZWN0ZWQuICBTb21ldGltZXMgaXQgaXMgY2Fs bGVkIGludGVyLUZFIHRvcG9sb2d5LCANCiAgICB0byBiZSBkaXN0aW5ndWlzaGVkIGZyb20gaW50 cmEtRkUgdG9wb2xvZ3kgdXNlZCBieSB0aGUgRkUgbW9kZWwuIA0KICAgICANCiAgICBJbnRlci1G RSB0b3BvbG9neSAtIHNlZSBGRSBUb3BvbG9neS4gDQogICAgIA0KIDIuIEludHJvZHVjdGlvbiB0 byBGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiAoRm9yQ0VTKSAgDQog IA0KICAgIEFuIElQIG5ldHdvcmsgZWxlbWVudCAoTkUpIGFwcGVhcnMgdG8gZXh0ZXJuYWwgZW50 aXRpZXMgYXMgYSANCiAgICBtb25vbGl0aGljIHBpZWNlIG9mIG5ldHdvcmsgZXF1aXBtZW50LCBl LmcuLCBhIHJvdXRlciwgTkFULCANCiAgICBmaXJld2FsbCwgb3IgbG9hZCBiYWxhbmNlci4gIElu dGVybmFsbHksIGhvd2V2ZXIsIGFuIElQIG5ldHdvcmsgDQogICAgZWxlbWVudCAoTkUpIChzdWNo IGFzIGEgcm91dGVyKSBpcyBjb21wb3NlZCBvZiBudW1lcm91cyBsb2dpY2FsbHkgDQogICAgc2Vw YXJhdGVkIGVudGl0aWVzIHRoYXQgY29vcGVyYXRlIHRvIHByb3ZpZGUgYSBnaXZlbiBmdW5jdGlv bmFsaXR5IA0KICAgIChzdWNoIGFzIHJvdXRpbmcpLiAgVHdvIHR5cGVzIG9mIG5ldHdvcmsgZWxl bWVudCBjb21wb25lbnRzIGV4aXN0OiANCiAgICBjb250cm9sIGVsZW1lbnQgKENFKSBpbiBjb250 cm9sIHBsYW5lIGFuZCBmb3J3YXJkaW5nIGVsZW1lbnQgKEZFKSANCiAgICBpbiBmb3J3YXJkaW5n IHBsYW5lIChvciBkYXRhIHBsYW5lKS4gIEZvcndhcmRpbmcgZWxlbWVudHMgdHlwaWNhbGx5IA0K ICAgIGFyZSBBU0lDLCBuZXR3b3JrLXByb2Nlc3Nvciwgb3IgZ2VuZXJhbC1wdXJwb3NlIHByb2Nl c3Nvci1iYXNlZCANCiAgICBkZXZpY2VzIHRoYXQgaGFuZGxlIGRhdGEgcGF0aCBvcGVyYXRpb25z IGZvciBlYWNoIHBhY2tldC4gIENvbnRyb2wgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBF eHBpcmVzIE1hcmNoICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0gICANCiBJbnRl cm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIFNlcHRl bWJlciAyMDAzIA0KICANCiAgDQogICAgZWxlbWVudHMgYXJlIHR5cGljYWxseSBiYXNlZCBvbiBn ZW5lcmFsLXB1cnBvc2UgcHJvY2Vzc29ycyB0aGF0IA0KICAgIHByb3ZpZGUgY29udHJvbCBmdW5j dGlvbmFsaXR5IGxpa2Ugcm91dGluZyBhbmQgc2lnbmFsaW5nIHByb3RvY29scy4gDQogICAgIA0K ICAgIEZvckNFUyBhaW1zIHRvIGRlZmluZSBhIGZyYW1ld29yayBhbmQgYXNzb2NpYXRlZCBwcm90 b2NvbChzKSB0byANCiAgICBzdGFuZGFyZGl6ZSBpbmZvcm1hdGlvbiBleGNoYW5nZSBiZXR3ZWVu IHRoZSBjb250cm9sIGFuZCBmb3J3YXJkaW5nIA0KICAgIHBsYW5lLiAgSGF2aW5nIHN0YW5kYXJk IG1lY2hhbmlzbXMgYWxsb3dzIENFcyBhbmQgRkVzIHRvIGJlY29tZSANCiAgICBwaHlzaWNhbGx5 IHNlcGFyYXRlZCBzdGFuZGFyZCBjb21wb25lbnRzLiAgVGhpcyBwaHlzaWNhbCBzZXBhcmF0aW9u IA0KICAgIGFjY3J1ZXMgc2V2ZXJhbCBiZW5lZml0cyB0byB0aGUgRm9yQ0VTIGFyY2hpdGVjdHVy ZS4gIFNlcGFyYXRlIA0KICAgIGNvbXBvbmVudHMgd291bGQgYWxsb3cgY29tcG9uZW50IHZlbmRv cnMgdG8gc3BlY2lhbGl6ZSBpbiBvbmUgDQogICAgY29tcG9uZW50IHdpdGhvdXQgaGF2aW5nIHRv IGJlY29tZSBleHBlcnRzIGluIGFsbCBjb21wb25lbnRzLiANCiAgICBTdGFuZGFyZCBwcm90b2Nv bCBhbHNvIGFsbG93cyB0aGUgQ0VzIGFuZCBGRXMgZnJvbSBkaWZmZXJlbnQgDQogICAgY29tcG9u ZW50IHZlbmRvcnMgdG8gaW50ZXJvcGVyYXRlIHdpdGggZWFjaCBvdGhlciBhbmQgaGVuY2UgaXQg DQogICAgYmVjb21lcyBwb3NzaWJsZSBmb3Igc3lzdGVtIHZlbmRvcnMgdG8gaW50ZWdyYXRlIHRv Z2V0aGVyIHRoZSBDRXMgDQogICAgYW5kIEZFcyBmcm9tIGRpZmZlcmVudCBjb21wb25lbnQgc3Vw cGxpZXJzLiAgVGhpcyBpbnRlcm9wZXJhYmlsaXR5IA0KICAgIHRyYW5zbGF0ZXMgaW50byBtb3Jl IGRlc2lnbiBjaG9pY2VzIGFuZCBmbGV4aWJpbGl0eSBmb3IgdGhlIHN5c3RlbSANCiAgICB2ZW5k b3JzLiAgT3ZlcmFsbCwgRm9yQ0VTIHdpbGwgZW5hYmxlIHJhcGlkIGlubm92YXRpb24gaW4gYm90 aCB0aGUgDQogICAgY29udHJvbCBhbmQgZm9yd2FyZGluZyBwbGFuZXMgd2hpbGUgbWFpbnRhaW5p bmcgaW50ZXJvcGVyYWJpbGl0eS4gIA0KICAgIFNjYWxhYmlsaXR5IGlzIGFsc28gZWFzaWx5IHBy b3ZpZGVkIGJ5IHRoaXMgYXJjaGl0ZWN0dXJlIGluIHRoYXQgDQogICAgYWRkaXRpb25hbCBmb3J3 YXJkaW5nIG9yIGNvbnRyb2wgY2FwYWNpdHkgY2FuIGJlIGFkZGVkIHRvIGV4aXN0aW5nIA0KICAg IG5ldHdvcmsgZWxlbWVudHMgd2l0aG91dCB0aGUgbmVlZCBmb3IgZm9ya2xpZnQgdXBncmFkZXMu IA0KICAgICANCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgIHwgIENvbnRyb2wgQmxhZGUgQSAgICAgIHwg ICAgICAgfCAgQ29udHJvbCBCbGFkZSBCICAgICAgfCANCiAgICAgICAgIHwgICAgICAgKENFKSAg ICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAoQ0UpICAgICAgICAgfCANCiAgICAgICAgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAN CiAgICAgICAgICAgICAgICAgXiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgIHwg DQogICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8 IA0KICAgICAgICAgICAgICAgICB8ICAgViAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ViANCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSANCiAgICAgICAgIHwgICAgICAgICAgICAgICBTd2l0Y2ggRmFicmljIEJh Y2twbGFuZSAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgICAgICAgICBe ICB8ICAgICAgICAgICAgXiAgfCAgICAgICAgICAgICAgICAgICBeICB8ICAgICAgICAgDQogICAg ICAgICAgICAgICAgfCAgfCAgICAgICAgICAgIHwgIHwgICAgIC4gLiAuICAgICAgICAgfCAgfCAg ICAgICAgIA0KICAgICAgICAgICAgICAgIHwgIFYgICAgICAgICAgICB8ICBWICAgICAgICAgICAg ICAgICAgIHwgIFYgICAgICAgICANCiAgICAgICAgICAgIC0tLS0tLS0tLS0tLSAgICAtLS0tLS0t LS0tLS0gICAgICAgICAgIC0tLS0tLS0tLS0tLSAgICAgDQogICAgICAgICAgICB8Um91dGVyICAg IHwgICAgfFJvdXRlciAgICB8ICAgICAgICAgICB8Um91dGVyICAgIHwgDQogICAgICAgICAgICB8 QmxhZGUgIzEgIHwgICAgfEJsYWRlICMyICB8ICAgICAgICAgICB8QmxhZGUgI04gIHwgDQogICAg ICAgICAgICB8ICAgKEZFKSAgIHwgICAgfCAgIChGRSkgICB8ICAgICAgICAgICB8ICAgKEZFKSAg IHwgDQogICAgICAgICAgICAtLS0tLS0tLS0tLS0gICAgLS0tLS0tLS0tLS0tICAgICAgICAgICAt LS0tLS0tLS0tLS0gICAgIA0KICAgICAgICAgICAgICAgIF4gIHwgICAgICAgICAgICBeICB8ICAg ICAgICAgICAgICAgICAgIF4gIHwgICAgICAgICANCiAgICAgICAgICAgICAgICB8ICB8ICAgICAg ICAgICAgfCAgfCAgICAgLiAuIC4gICAgICAgICB8ICB8ICAgICAgICAgDQogICAgICAgICAgICAg ICAgfCAgViAgICAgICAgICAgIHwgIFYgICAgICAgICAgICAgICAgICAgfCAgViAgICAgICAgIA0K ICAgICAgICAgIA0KICAgICAgICAgRmlndXJlIDEuIEEgcm91dGVyIGNvbmZpZ3VyYXRpb24gZXhh bXBsZSB3aXRoIHNlcGFyYXRlIGJsYWRlcy4gDQogIA0KICAgIE9uZSBleGFtcGxlIG9mIHN1Y2gg cGh5c2ljYWwgc2VwYXJhdGlvbiBpcyBhdCB0aGUgYmxhZGUgbGV2ZWwuIA0KICAgIEZpZ3VyZSAx IHNob3dzIHN1Y2ggYW4gZXhhbXBsZSBjb25maWd1cmF0aW9uIG9mIGEgcm91dGVyLCB3aXRoIHR3 byANCiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgTWFyY2ggICAgMjAwNCAgICAg ICAgICAgICAgICAgICBbUGFnZSA2XSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VT IEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAgICBj b250cm9sIGJsYWRlcyBhbmQgbXVsdGlwbGUgZm9yd2FyZGluZyBibGFkZXMsIGFsbCBpbnRlcmNv bm5lY3RlZCANCiAgICBpbnRvIGEgc3dpdGNoIGZhYnJpYyBiYWNrcGxhbmUuICBJbiBzdWNoIGEg Y2hhc3NpcyBjb25maWd1cmF0aW9uLCANCiAgICB0aGUgY29udHJvbCBibGFkZXMgYXJlIHRoZSBD RXMgd2hpbGUgdGhlIHJvdXRlciBibGFkZXMgYXJlIEZFcywgYW5kIA0KICAgIHRoZSBzd2l0Y2gg ZmFicmljIGJhY2twbGFuZSBwcm92aWRlcyB0aGUgcGh5c2ljYWwgaW50ZXJjb25uZWN0IGZvciAN CiAgICBhbGwgdGhlIGJsYWRlcy4gIENvbnRyb2wgYmxhZGUgQSBtYXkgYmUgdGhlIHByaW1hcnkg Q0Ugd2hpbGUgDQogICAgY29udHJvbCBibGFkZSBCIG1heSBiZSB0aGUgYmFja3VwIENFIHByb3Zp ZGluZyByZWR1bmRhbmN5LiAgSXQgaXMgDQogICAgYWxzbyBwb3NzaWJsZSB0byBoYXZlIGEgcmVk dW5kYW50IHN3aXRjaCBmYWJyaWMgZm9yIGhpZ2ggDQogICAgYXZhaWxhYmlsaXR5IHN1cHBvcnQu ICBSb3V0ZXJzIHRvZGF5IHdpdGggdGhpcyBraW5kIG9mIA0KICAgIGNvbmZpZ3VyYXRpb24gdXNl IHByb3ByaWV0YXJ5IGludGVyZmFjZXMgZm9yIG1lc3NhZ2luZyBiZXR3ZWVuIENFcyANCiAgICBh bmQgRkVzLiAgVGhlIGdvYWwgb2YgRm9yQ0VTIGlzIHRvIHJlcGxhY2Ugc3VjaCBwcm9wcmlldGFy eSANCiAgICBpbnRlcmZhY2VzIHdpdGggYSBzdGFuZGFyZCBwcm90b2NvbC4gIFdpdGggYSBzdGFu ZGFyZCBwcm90b2NvbCBsaWtlIA0KICAgIEZvckNFUyBpbXBsZW1lbnRlZCBvbiBhbGwgYmxhZGVz LCBpdCBiZWNvbWVzIHBvc3NpYmxlIGZvciBjb250cm9sIA0KICAgIGJsYWRlcyBmcm9tIHZlbmRv ciBYIGFuZCBmb3J3YXJkaW5nIGJsYWRlcyBmcm9tIHZlbmRvciBZIHRvIHdvcmsgDQogICAgc2Vh bWxlc3NseSB0b2dldGhlciBpbiBvbmUgY2hhc3Npcy4gIA0KICANCiAgDQogICAgICAgICAtLS0t LS0tICAgICAgICAgLS0tLS0tLSANCiAgICAgICAgIHwgQ0UxIHwgICAgICAgICB8IENFMiB8IA0K ICAgICAgICAgLS0tLS0tLSAgICAgICAgIC0tLS0tLS0gDQogICAgICAgICAgICBeICAgICAgICAg ICAgICAgXiANCiAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgViAg ICAgICAgICAgICAgIFYgDQogICAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09IEV0aGVybmV0IA0KICAgICAgICAgXiAgICAgICBeICAgICAgIC4gLiAuICAgXiAN CiAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgIHwgDQogICAgICAgICBWICAgICAgIFYg ICAgICAgICAgICAgICBWIA0KICAgICAgLS0tLS0tLSAgLS0tLS0tLSAgICAgICAgIC0tLS0tLS0t IA0KICAgICAgfCBGRSMxfCAgfCBGRSMyfCAgICAgICAgIHwgRkUjbiB8IA0KICAgICAgLS0tLS0t LSAgLS0tLS0tLSAgICAgICAgIC0tLS0tLS0tIA0KICAgICAgICBeICB8ICAgICBeICB8ICAgICAg ICAgICAgXiAgfCAgICAgICAgIA0KICAgICAgICB8ICB8ICAgICB8ICB8ICAgICAgICAgICAgfCAg fCAgICAgICAgIA0KICAgICAgICB8ICBWICAgICB8ICBWICAgICAgICAgICAgfCAgViAgICAgICAg IA0KICAgICAgICAgIA0KICAgICAgICAgRmlndXJlIDIuIEEgcm91dGVyIGNvbmZpZ3VyYXRpb24g ZXhhbXBsZSB3aXRoIHNlcGFyYXRlIGJveGVzLiANCiAgICAgDQogICAgQW5vdGhlciBsZXZlbCBv ZiBwaHlzaWNhbCBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIENFcyBhbmQgRkVzIGNhbiBiZSANCiAg ICBhdCB0aGUgYm94IGxldmVsLiAgSW4gc3VjaCBjb25maWd1cmF0aW9uLCBhbGwgdGhlIENFcyBh bmQgRkVzIGFyZSANCiAgICBwaHlzaWNhbGx5IHNlcGFyYXRlZCBib3hlcywgaW50ZXJjb25uZWN0 ZWQgd2l0aCBzb21lIGtpbmQgb2YgaGlnaCANCiAgICBzcGVlZCBMQU4gY29ubmVjdGlvbiAobGlr ZSBHaWdhYml0IEV0aGVybmV0KS4gIFRoZXNlIHNlcGFyYXRlZCBDRXMgDQogICAgYW5kIEZFcyBh cmUgb25seSBvbmUgaG9wIGF3YXkgZnJvbSBlYWNoIG90aGVyIHdpdGhpbiBhIGxvY2FsIGFyZWEg DQogICAgbmV0d29yay4gIFRoZSBDRXMgYW5kIEZFcyBjb21tdW5pY2F0ZSB0byBlYWNoIG90aGVy IGJ5IHJ1bm5pbmcgDQogICAgRm9yQ0VTLCBhbmQgdGhlIGNvbGxlY3Rpb24gb2YgdGhlc2UgQ0Vz IGFuZCBGRXMgdG9nZXRoZXIgYmVjb21lIG9uZSANCiAgICByb3V0aW5nIHVuaXQgdG8gdGhlIGV4 dGVybmFsIHdvcmxkLiBGaWd1cmUgMiBzaG93cyBzdWNoIGFuIGV4YW1wbGUuIA0KICAgICANCiAg ICBJbiBib3RoIGV4YW1wbGVzIHNob3duIGhlcmUsIHRoZSBzYW1lIHBoeXNpY2FsIGludGVyY29u bmVjdCBpcyB1c2VkIA0KICAgIGZvciBib3RoIENFLXRvLUZFIGFuZCBGRS10by1GRSBjb21tdW5p Y2F0aW9uLiAgSG93ZXZlciwgdGhhdCBkb2VzIA0KICAgIG5vdCBoYXZlIHRvIGJlIHRoZSBjYXNl LiAgT25lIHJlYXNvbiB0byB1c2UgZGlmZmVyZW50IGludGVyY29ubmVjdHMgDQogIA0KICANCiBZ YW5nLCBldCBhbC4gICAgICBFeHBpcmVzIE1hcmNoICAgIDIwMDQgICAgICAgICAgICAgICAgICAg W1BhZ2UgN10gICANCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGcmFtZXdvcmsgICAg ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDAzIA0KICANCiAgDQogICAgaXMgdGhhdCBDRS10by1G RSBpbnRlcmNvbm5lY3QgZG9lcyBub3QgaGF2ZSB0byBiZSBhcyBmYXN0IGFzIHRoZSANCiAgICBG RS10by1GRSBpbnRlcmNvbm5lY3QsIHNvIHRoZSBtb3JlIGV4cGVuc2l2ZSBmYXN0IGNvbm5lY3Rp b25zIGNhbiANCiAgICBiZSBzYXZlZCBmb3IgRkUtdG8tRkUuICBUaGUgc2VwYXJhdGUgaW50ZXJj b25uZWN0cyBtYXkgYWxzbyBwcm92aWRlIA0KICAgIHJlbGlhYmlsaXR5IGFuZCByZWR1bmRhbmN5 IGJlbmVmaXRzIGZvciB0aGUgTkUuIA0KICANCiAgICBTb21lIGV4YW1wbGVzIG9mIGNvbnRyb2wg ZnVuY3Rpb25zIHRoYXQgY2FuIGJlIGltcGxlbWVudGVkIGluIHRoZSANCiAgICBDRSBpbmNsdWRl IHJvdXRpbmcgcHJvdG9jb2xzIGxpa2UgUklQLCBPU1BGIGFuZCBCR1AsIGNvbnRyb2wgYW5kIA0K ICAgIHNpZ25hbGluZyBwcm90b2NvbHMgbGlrZSBSU1ZQIChSZXNvdXJjZSBSZXNlcnZhdGlvbiBQ cm90b2NvbCksIExEUCANCiAgICAoTGFiZWwgRGlzdHJpYnV0aW9uIFByb3RvY29sKSBmb3IgTVBM UywgZXRjLiAgRXhhbXBsZXMgb2YgDQogICAgZm9yd2FyZGluZyBmdW5jdGlvbnMgaW4gdGhlIEZF IGluY2x1ZGUgTFBNIChsb25nZXN0IHByZWZpeCBtYXRjaCkgDQogICAgZm9yd2FyZGVyLCBjbGFz c2lmaWVycywgdHJhZmZpYyBzaGFwZXIsIG1ldGVyLCBOQVQgKE5ldHdvcmsgQWRkcmVzcyANCiAg ICBUcmFuc2xhdG9ycyksIGV0Yy4gIEZpZ3VyZSAzIHByb3ZpZGVzIGV4YW1wbGUgZnVuY3Rpb25z IGluIGJvdGggQ0UgDQogICAgYW5kIEZFLiAgQW55IGdpdmVuIE5FIG1heSBjb250YWluIG9uZSBv ciBtYW55IG9mIHRoZXNlIENFIGFuZCBGRSANCiAgICBmdW5jdGlvbnMgaW4gaXQuICBUaGUgZGlh Z3JhbSBhbHNvIHNob3dzIHRoYXQgRm9yQ0VTIHByb3RvY29sIGlzIA0KICAgIHVzZWQgdG8gdHJh bnNwb3J0IGJvdGggdGhlIGNvbnRyb2wgbWVzc2FnZXMgZm9yIEZvckNFUyBpdHNlbGYgYW5kIA0K ICAgIHRoZSBkYXRhIHBhY2tldHMgdGhhdCBhcmUgb3JpZ2luYXRlZC9kZXN0aW5lZCBmcm9tL3Rv IHRoZSBjb250cm9sIA0KICAgIGZ1bmN0aW9ucyBpbiBDRSAoZS5nLiwgcm91dGluZyBwYWNrZXRz KS4gIFNlY3Rpb24gNC4yLjQgcHJvdmlkZXMgDQogICAgbW9yZSBkZXRhaWwgb24gdGhpcy4gIA0K ICAgICANCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gDQogICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAg ICAgfCAgICAgICB8IA0KICAgICAgICAgfE9TUEYgICB8UklQICAgIHxCR1AgICAgfFJTVlAgICB8 TERQICAgIHwuIC4gLiAgfCANCiAgICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAg ICAgfCAgICAgICB8ICAgICAgIHwgDQogICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgfCAgICAgICAgICAgICAgIEZvckNF UyBJbnRlcmZhY2UgICAgICAgICAgICAgICAgfCANCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBeICAgXiAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgRm9yQ0VTICB8ICAgfGRhdGEgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnRyb2wgfCAgIHxwYWNrZXRzICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICBtZXNz YWdlc3wgICB8KGUuZy4sIHJvdXRpbmcgcGFja2V0cykgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB2ICAgdiANCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICB8ICAgICAgICAgICAgICAgRm9yQ0VTIElu dGVyZmFjZSAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgIHwgICAgICAgfCAgICAgICB8 ICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgICAgIHwgDQogICAgICAgICB8TFBNIEZ3ZHxNZXRl ciAgfFNoYXBlciB8TkFUICAgIHxDbGFzc2ktfC4gLiAuICB8IA0KICAgICAgICAgfCAgICAgICB8 ICAgICAgIHwgICAgICAgfCAgICAgICB8ZmllciAgIHwgICAgICAgfCANCiAgICAgICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICB8 ICAgICAgICAgICAgICAgRkUgcmVzb3VyY2VzICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAg ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAg ICAgDQogICAgICAgICAgICAgICAgIEZpZ3VyZSAzLiBFeGFtcGxlcyBvZiBDRSBhbmQgRkUgZnVu Y3Rpb25zIA0KICAgICANCiAgICAgDQogICAgQSBzZXQgb2YgcmVxdWlyZW1lbnRzIGZvciBjb250 cm9sIGFuZCBmb3J3YXJkaW5nIHNlcGFyYXRpb24gaXMgDQogICAgaWRlbnRpZmllZCBpbiBbM10u ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIEZvckNFUyBhcmNoaXRlY3R1cmUgDQogICAgdGhh dCBzYXRpc2ZpZXMgdGhlIGFyY2hpdGVjdHVyYWwgcmVxdWlyZW1lbnRzIG9mIHRoYXQgZG9jdW1l bnQgYW5kIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0 ICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBG b3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0K ICAgIGRlZmluZXMgYSBmcmFtZXdvcmsgZm9yIEZvckNFUyBuZXR3b3JrIGVsZW1lbnRzIGFuZCB0 aGUgYXNzb2NpYXRlZCANCiAgICBlbnRpdGllcyB0byBmYWNpbGl0YXRlIHByb3RvY29sIGRlZmlu aXRpb24uICBXaGVuZXZlciBuZWNlc3NhcnksIA0KICAgIHRoaXMgZG9jdW1lbnQgdXNlcyBtYW55 IGV4YW1wbGVzIHRvIGlsbHVzdHJhdGUgdGhlIGlzc3VlcyBhbmQvb3IgDQogICAgcG9zc2libGUg c29sdXRpb25zIGluIEZvckNFUy4gIFRoZXNlIGV4YW1wbGVzIGFyZSBpbnRlbmRlZCB0byBiZSAN CiAgICBqdXN0IGV4YW1wbGVzLCBhbmQgc2hvdWxkIG5vdCBiZSB0YWtlbiBhcyB0aGUgb25seSBv ciBkZWZpbml0ZSB3YXlzIA0KICAgIG9mIGRvaW5nIGNlcnRhaW4gdGhpbmdzLiAgSXQgaXMgZXhw ZWN0ZWQgdGhhdCBzZXBhcmF0ZSBkb2N1bWVudCANCiAgICB3aWxsIGJlIHByb2R1Y2VkIGJ5IHRo ZSBGb3JDRVMgd29ya2luZyBncm91cCB0byBzcGVjaWZ5IHRoZSBGb3JDRVMgDQogICAgcHJvdG9j b2wocykuIA0KICAgICANCiAzLiBBcmNoaXRlY3R1cmUgDQogIA0KICAgIFRoaXMgc2VjdGlvbiBk ZWZpbmVzIHRoZSBGb3JDRVMgYXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmsgYW5kIHRoZSANCiAgICBh c3NvY2lhdGVkIGxvZ2ljYWwgY29tcG9uZW50cy4gIFRoaXMgRm9yQ0VTIGZyYW1ld29yayBkZWZp bmVzIA0KICAgIGNvbXBvbmVudHMgb2YgRm9yQ0VTIE5FcyBpbmNsdWRpbmcgc2V2ZXJhbCBhbmNp bGxhcnkgY29tcG9uZW50cy4gIA0KICAgIFRoZXNlIGNvbXBvbmVudHMgbWF5IGJlIGNvbm5lY3Rl ZCBpbiBkaWZmZXJlbnQga2luZHMgb2YgdG9wb2xvZ2llcyANCiAgICBmb3IgZmxleGlibGUgcGFj a2V0IHByb2Nlc3NpbmcuICANCiAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgRm9yQ0VTIE5ldHdvcmsgRWxlbWVudCAgICAgICAgICAgICAgfCANCiAgICAg LS0tLS0tLS0tLS0tLS0gICBGYyAgICB8IC0tLS0tLS0tLS0tLS0tICAgICAgLS0tLS0tLS0tLS0t LS0gIHwgDQogICAgIHwgQ0UgTWFuYWdlciB8LS0tLS0tLS0tKy18ICAgICBDRSAxICAgfC0tLS0t LXwgICAgQ0UgMiAgICB8ICB8IA0KICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAgIHwgfCAgICAg ICAgICAgIHwgIEZyICB8ICAgICAgICAgICAgfCAgfCANCiAgICAgICAgICAgfCAgICAgICAgICAg ICAgICB8IC0tLS0tLS0tLS0tLS0tICAgICAgLS0tLS0tLS0tLS0tLS0gIHwgDQogICAgICAgICAg IHwgRmwgICAgICAgICAgICAgfCAgICAgICAgIHwgIHwgICAgRnAgICAgICAgLyAgICAgICAgICB8 IA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgRnB8ICB8LS0tLS0tLS0tLXwg LyAgICAgICAgICAgfCANCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAg ICAgICAgICAgICB8LyAgICAgICAgICAgIHwgDQogICAgICAgICAgIHwgICAgICAgICAgICAgICAg fCAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgICAgICAgICB8ICAg ICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICBGcCAgICAgL3wtLS0tfCAgICAgICAgfCANCiAg ICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgLy0tLS0tLS0tLyAgICAgIHwg ICAgICAgIHwgDQogICAgIC0tLS0tLS0tLS0tLS0tICAgICBGZiAgfCAtLS0tLS0tLS0tLS0tLSAg ICAgIC0tLS0tLS0tLS0tLS0tICB8IA0KICAgICB8IEZFIE1hbmFnZXIgfC0tLS0tLS0tLSstfCAg ICAgRkUgMSAgIHwgIEZpICB8ICAgICBGRSAyICAgfCAgfCANCiAgICAgLS0tLS0tLS0tLS0tLS0g ICAgICAgICB8IHwgICAgICAgICAgICB8LS0tLS0tfCAgICAgICAgICAgIHwgIHwgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAtLS0tLS0tLS0tLS0tLSAgICAgIC0tLS0tLS0tLS0tLS0t ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHwgIHwgIHwgIHwgICAgICAgICAg fCAgfCAgfCAgfCAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0rLS0rLS0r LS0rLS0tLS0tLS0tLSstLSstLSstLSstLS0tLSANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgfCAgfCAgfCAgICAgICAgICB8ICB8ICB8ICB8IA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICB8ICB8ICB8ICAgICAgICAgIHwgIHwgIHwgIHwgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmkvZiAgICAgICAgICAgICAgICAgICBGaS9mIA0KICAg ICANCiAgICAgICAgICAgICAgICAgRmlndXJlIDQuIEZvckNFUyBBcmNoaXRlY3R1cmFsIERpYWdy YW0gDQogICAgIA0KICAgIFRoZSBkaWFncmFtIGluIEZpZ3VyZSA0IHNob3dzIHRoZSBsb2dpY2Fs IGNvbXBvbmVudHMgb2YgdGhlIEZvckNFUyANCiAgICBhcmNoaXRlY3R1cmUgYW5kIHRoZWlyIHJl bGF0aW9uc2hpcHMuICBUaGVyZSBhcmUgdHdvIGtpbmRzIG9mIA0KICAgIGNvbXBvbmVudHMgaW5z aWRlIGEgRm9yQ0VTIG5ldHdvcmsgZWxlbWVudDogY29udHJvbCBlbGVtZW50IChDRSkgDQogICAg YW5kIGZvcndhcmRpbmcgZWxlbWVudCAoRkUpLiAgVGhlIGZyYW1ld29yayBhbGxvd3MgbXVsdGlw bGUgDQogICAgaW5zdGFuY2VzIG9mIENFIGFuZCBGRSBpbnNpZGUgb25lIE5FLiAgRWFjaCBGRSBj b250YWlucyBvbmUgb3IgbW9yZSANCiAgICBwaHlzaWNhbCBtZWRpYSBpbnRlcmZhY2VzIGZvciBy ZWNlaXZpbmcgYW5kIHRyYW5zbWl0dGluZyBwYWNrZXRzIA0KICANCiAgDQogWWFuZywgZXQgYWwu ICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDldICAg DQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAg ICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0KICAgIGZyb20vdG8gdGhlIGV4dGVybmFsIHdvcmxk LiAgVGhlIGFnZ3JlZ2F0aW9uIG9mIHRoZXNlIEZFIGludGVyZmFjZXMgDQogICAgYmVjb21lcyB0 aGUgTkUncyBleHRlcm5hbCBpbnRlcmZhY2VzLiAgSW4gYWRkaXRpb24gdG8gdGhlIGV4dGVybmFs IA0KICAgIGludGVyZmFjZXMsIHRoZXJlIG11c3QgYWxzbyBleGlzdCBzb21lIGtpbmQgb2YgaW50 ZXJjb25uZWN0IHdpdGhpbiANCiAgICB0aGUgTkUgc28gdGhhdCB0aGUgQ0UgYW5kIEZFIGNhbiBj b21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIsIGFuZCANCiAgICBvbmUgRkUgY2FuIGZvcndhcmQg cGFja2V0cyB0byBhbm90aGVyIEZFLiAgVGhlIGRpYWdyYW0gYWxzbyBzaG93cyANCiAgICB0d28g ZW50aXRpZXMgb3V0c2lkZSBvZiB0aGUgRm9yQ0VTIE5FOiBDRSBNYW5hZ2VyIGFuZCBGRSBNYW5h Z2VyLiAgDQogICAgVGhlc2UgdHdvIGVudGl0aWVzIHByb3ZpZGUgY29uZmlndXJhdGlvbiB0byB0 aGUgY29ycmVzcG9uZGluZyBDRSBvciANCiAgICBGRSBpbiB0aGUgcHJlLWFzc29jaWF0aW9uIHBo YXNlIChzZWUgU2VjdGlvbiA0LjEpLiAgVGhlcmUgaXMgbm8gDQogICAgZGVmaW5lZCByb2xlIGZv ciBGRSBNYW5hZ2VyIGFuZCBDRSBNYW5hZ2VyIGluIHBvc3QtYXNzb2NpYXRpb24gDQogICAgcGhh c2UsIHRodXMgdGhlc2UgbG9naWNhbCBjb21wb25lbnRzIGFyZSBub3QgY29uc2lkZXJlZCBwYXJ0 IG9mIHRoZSANCiAgICBGb3JDRVMgTkUuICANCiAgICAgDQogICAgRm9yIGNvbnZlbmllbmNlLCB0 aGUgbG9naWNhbCBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGVzZSBjb21wb25lbnRzIA0KICAgIGFy ZSBsYWJlbGVkIGJ5IHJlZmVyZW5jZSBwb2ludHMgRnAsIEZjLCBGZiwgRnIsIEZsLCBhbmQgRmks IGFzIA0KICAgIHNob3duIGluIEZpZ3VyZSA0LiAgVGhlIEZFIGV4dGVybmFsIGludGVyZmFjZXMg YXJlIGxhYmVsZWQgYXMgRmkvZi4gDQogICAgTW9yZSBkZXRhaWwgaXMgcHJvdmlkZWQgaW4gU2Vj dGlvbiAzIGFuZCA0IGZvciBlYWNoIG9mIHRoZXNlIA0KICAgIHJlZmVyZW5jZSBwb2ludHMuICBB bGwgdGhlc2UgcmVmZXJlbmNlIHBvaW50cyBhcmUgaW1wb3J0YW50IGluIA0KICAgIHVuZGVyc3Rh bmRpbmcgdGhlIEZvckNFUyBhcmNoaXRlY3R1cmUsIGhvd2V2ZXIsIHRoZSBGb3JDRVMgcHJvdG9j b2wgDQogICAgaXMgb25seSBkZWZpbmVkIG92ZXIgb25lIHJlZmVyZW5jZSBwb2ludCAtLSBGcC4g IA0KICAgICANCiAgICBUaGUgaW50ZXJmYWNlIGJldHdlZW4gdHdvIEZvckNFUyBORXMgaXMgaWRl bnRpY2FsIHRvIHRoZSBpbnRlcmZhY2UgDQogICAgYmV0d2VlbiB0d28gY29udmVudGlvbmFsIHJv dXRlcnMgYW5kIHRoZXNlIHR3byBORXMgZXhjaGFuZ2UgdGhlIA0KICAgIHByb3RvY29sIHBhY2tl dHMgdGhyb3VnaCB0aGUgZXh0ZXJuYWwgaW50ZXJmYWNlcyBhdCBGaS9mLiAgRm9yQ0VTIA0KICAg IE5FcyBjb25uZWN0IHRvIGV4aXN0aW5nIHJvdXRlcnMgdHJhbnNwYXJlbnRseS4gDQogIA0KIDMu MS4gQ29udHJvbCBFbGVtZW50cyBhbmQgRnIgUmVmZXJlbmNlIFBvaW50IA0KICAgICANCiAgICBJ dCBpcyBub3QgbmVjZXNzYXJ5IHRvIGRlZmluZSBhbnkgcHJvdG9jb2xzIGFjcm9zcyB0aGUgRnIg cmVmZXJlbmNlIA0KICAgIHBvaW50IHRvIGVuYWJsZSBjb250cm9sIGFuZCBmb3J3YXJkaW5nIHNl cGFyYXRpb24gZm9yIHNpbXBsZSANCiAgICBjb25maWd1cmF0aW9ucyBsaWtlIHNpbmdsZSBDRSBh bmQgbXVsdGlwbGUgRkVzLiAgSG93ZXZlciwgdGhpcyANCiAgICBhcmNoaXRlY3R1cmUgcGVybWl0 cyBtdWx0aXBsZSBDRXMgdG8gYmUgcHJlc2VudCBpbiBhIG5ldHdvcmsgDQogICAgZWxlbWVudC4g IEluIGNhc2VzIHdoZXJlIGFuIGltcGxlbWVudGF0aW9uIHVzZXMgbXVsdGlwbGUgQ0VzLCB0aGUg DQogICAgaW52YXJpYW50IHRoYXQgdGhlIENFcyBhbmQgRkVzIHRvZ2V0aGVyIGFwcGVhciBhcyBh IHNpbmdsZSBORSBtdXN0IA0KICAgIGJlIG1haW50YWluZWQuIA0KICAgICANCiAgICBNdWx0aXBs ZSBDRXMgbWF5IGJlIHVzZWQgZm9yIHJlZHVuZGFuY3ksIGxvYWQgc2hhcmluZywgZGlzdHJpYnV0 ZWQgDQogICAgY29udHJvbCwgb3Igb3RoZXIgcHVycG9zZXMuICBSZWR1bmRhbmN5IGlzIHRoZSBj YXNlIHdoZXJlIG9uZSBvciANCiAgICBtb3JlIENFcyBhcmUgcHJlcGFyZWQgdG8gdGFrZSBvdmVy IHNob3VsZCBhbiBhY3RpdmUgQ0UgZmFpbC4gIExvYWQgDQogICAgc2hhcmluZyBpcyB0aGUgY2Fz ZSB3aGVyZSB0d28gb3IgbW9yZSBDRXMgYXJlIGNvbmN1cnJlbnRseSBhY3RpdmUgDQogICAgYW5k IGFueSByZXF1ZXN0IHRoYXQgY2FuIGJlIHNlcnZpY2VkIGJ5IG9uZSBvZiB0aGUgQ0VzIGNhbiBh bHNvIGJlIA0KICAgIHNlcnZpY2VkIGJ5IGFueSBvZiB0aGUgb3RoZXIgQ0VzLiAgRm9yIGJvdGgg cmVkdW5kYW5jeSBhbmQgbG9hZCANCiAgICBzaGFyaW5nLCB0aGUgQ0VzIGludm9sdmVkIGFyZSBl cXVpdmFsZW50bHkgY2FwYWJsZS4gIFRoZSBvbmx5IA0KICAgIGRpZmZlcmVuY2UgYmV0d2VlbiB0 aGVzZSB0d28gY2FzZXMgaXMgaW4gdGVybXMgb2YgaG93IG1hbnkgYWN0aXZlIA0KICAgIENFcyB0 aGVyZSBhcmUuICBEaXN0cmlidXRlZCBjb250cm9sIGlzIHRoZSBjYXNlIHdoZXJlIHR3byBvciBt b3JlIA0KICAgIENFcyBhcmUgY29uY3VycmVudGx5IGFjdGl2ZSBidXQgY2VydGFpbiByZXF1ZXN0 cyBjYW4gb25seSBiZSANCiAgICBzZXJ2aWNlZCBieSBjZXJ0YWluIENFcy4gDQogIA0KICANCiAg DQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAgICAgICAgICAgICAg ICAgIFtQYWdlIDEwXSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29y ayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAgICBXaGVuIG11bHRp cGxlIENFcyBhcmUgZW1wbG95ZWQgaW4gYSBGb3JDRVMgTkUsIHRoZWlyIGludGVybmFsIA0KICAg IG9yZ2FuaXphdGlvbiBpcyBjb25zaWRlcmVkIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIHRoYXQg aXMgYmV5b25kIA0KICAgIHRoZSBzY29wZSBvZiBGb3JDRVMuICBDRXMgYXJlIHdob2xseSByZXNw b25zaWJsZSBmb3IgY29vcmRpbmF0aW5nIA0KICAgIGFtb25nc3QgdGhlbXNlbHZlcyB2aWEgdGhl IEZyIHJlZmVyZW5jZSBwb2ludCB0byBwcm92aWRlIA0KICAgIGNvbnNpc3RlbmN5IGFuZCBzeW5j aHJvbml6YXRpb24uICBIb3dldmVyLCBGb3JDRVMgZG9lcyBub3QgZGVmaW5lIA0KICAgIHRoZSBp bXBsZW1lbnRhdGlvbiBvciBwcm90b2NvbHMgdXNlZCBiZXR3ZWVuIENFcywgbm9yIGRvZXMgaXQg DQogICAgZGVmaW5lIGhvdyB0byBkaXN0cmlidXRlIGZ1bmN0aW9uYWxpdHkgYW1vbmcgQ0VzLiAg TmV2ZXJ0aGVsZXNzLCANCiAgICBGb3JDRVMgd2lsbCBzdXBwb3J0IG1lY2hhbmlzbXMgZm9yIENF IHJlZHVuZGFuY3kgb3IgZmFpbCBvdmVyLCBhbmQgDQogICAgaXQgaXMgZXhwZWN0ZWQgdGhhdCB2 ZW5kb3JzIHdpbGwgcHJvdmlkZSByZWR1bmRhbmN5IG9yIGZhaWwgb3ZlciANCiAgICBzb2x1dGlv bnMgd2l0aGluIHRoaXMgZnJhbWV3b3JrLiANCiAgDQogIA0KIDMuMi4gRm9yd2FyZGluZyBFbGVt ZW50cyBhbmQgRmkgcmVmZXJlbmNlIHBvaW50IA0KICAgICANCiAgICBBbiBGRSBpcyBhIGxvZ2lj YWwgZW50aXR5IHRoYXQgaW1wbGVtZW50cyB0aGUgRm9yQ0VTIHByb3RvY29sIGFuZCANCiAgICB1 c2VzIHRoZSB1bmRlcmx5aW5nIGhhcmR3YXJlIHRvIHByb3ZpZGUgcGVyLXBhY2tldCBwcm9jZXNz aW5nIGFuZCANCiAgICBoYW5kbGluZyBhcyBkaXJlY3RlZCBieSBhIENFLiAgSXQgaXMgcG9zc2li bGUgdG8gcGFydGl0aW9uIG9uZSANCiAgICBwaHlzaWNhbCBGRSBpbnRvIG11bHRpcGxlIGxvZ2lj YWwgRkVzLiAgSXQgaXMgYWxzbyBwb3NzaWJsZSBmb3Igb25lIA0KICAgIEZFIHRvIHVzZSBtdWx0 aXBsZSBwaHlzaWNhbCBGRXMuICBUaGUgbWFwcGluZyBiZXR3ZWVuIHBoeXNpY2FsIA0KICAgIEZF KHMpIGFuZCB0aGUgbG9naWNhbCBGRShzKSBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIEZvckNFUy4g IEZvciANCiAgICBleGFtcGxlLCBhIGxvZ2ljYWwgcGFydGl0aW9uIG9mIGEgcGh5c2ljYWwgRkUg Y2FuIGJlIGNyZWF0ZWQgYnkgDQogICAgYXNzaWduaW5nIHNvbWUgcG9ydGlvbiBvZiBlYWNoIG9m IHRoZSByZXNvdXJjZXMgKGUuZy4sIHBvcnRzLCANCiAgICBtZW1vcnksIGZvcndhcmRpbmcgdGFi bGUgZW50cmllcykgYXZhaWxhYmxlIG9uIHRoZSBwaHlzaWNhbCBGRSB0byANCiAgICBlYWNoIG9m IHRoZSBsb2dpY2FsIEZFcy4gIFN1Y2ggY29uY2VwdCBvZiBGRSB2aXJ0dWFsaXphdGlvbiBpcyAN CiAgICBhbmFsb2dvdXMgdG8gYSB2aXJ0dWFsIHN3aXRjaGluZyBlbGVtZW50IGFzIGRlc2NyaWJl ZCBpbiBbOF0uICBJZiANCiAgICBGRSB2aXJ0dWFsaXphdGlvbiBvY2N1cnMgb25seSBpbiB0aGUg cHJlLWFzc29jaWF0aW9uIHBoYXNlLCBpdCBoYXMgDQogICAgbm8gaW1wYWN0IG9uIEZvckNFUy4g SG93ZXZlciwgaWYgRkUgdmlydHVhbGl6YXRpb24gcmVzdWx0cyBpbiANCiAgICBkeW5hbWljIHJl c291cmNlIGNoYW5nZSBvbiBGRSBkdXJpbmcgcG9zdC1hc3NvY2lhaXRvbiBwaGFzZSwgdGhlIEZF IA0KICAgIG1vZGVsIG5lZWRzIHRvIGJlIGFibGUgdG8gcmVwb3J0IHN1Y2ggY2FwYWJpbGl0eSBh bmQgdGhlIEZvckNFUyANCiAgICBwcm90b2NvbCBuZWVkcyB0byBiZSBhYmxlIHRvIGluZm9ybSB0 aGUgQ0Ugb2Ygc3VjaCBjaGFuZ2UgdmlhIA0KICAgIGFzeW5jaHJvbm91cyBtZXNzYWdlcyAoc2Vl IFszXSwgU2VjdGlvbiA1LCByZXF1aXJlbWVudCAjNikuIA0KICAgICANCiAgICBGRXMgcGVyZm9y bSBhbGwgcGFja2V0IHByb2Nlc3NpbmcgZnVuY3Rpb25zIGFzIGRpcmVjdGVkIGJ5IENFcy4gIA0K ICAgIEZFcyBoYXZlIG5vIGluaXRpYXRpdmUgb2YgdGhlaXIgb3duLiAgSW5zdGVhZCwgRkVzIGFy ZSBzbGF2ZXMgYW5kIA0KICAgIG9ubHkgZG8gYXMgdGhleSBhcmUgdG9sZC4gIEZFcyBtYXkgY29t bXVuaWNhdGUgd2l0aCBvbmUgb3IgbW9yZSBDRXMgDQogICAgY29uY3VycmVudGx5IGFjcm9zcyBy ZWZlcmVuY2UgcG9pbnQgRnAuICBGRXMgaGF2ZSBubyBub3Rpb24gb2YgQ0UgDQogICAgcmVkdW5k YW5jeSwgbG9hZCBzaGFyaW5nLCBvciBkaXN0cmlidXRlZCBjb250cm9sLiAgSW5zdGVhZCwgRkVz IA0KICAgIGFjY2VwdCBjb21tYW5kcyBmcm9tIGFueSBDRSBhdXRob3JpemVkIHRvIGNvbnRyb2wg dGhlbSwgYW5kIGl0IGlzIA0KICAgIHVwIHRvIHRoZSBDRXMgdG8gY29vcmRpbmF0ZSBhbW9uZyB0 aGVtc2VsdmVzIHRvIGFjaGlldmUgcmVkdW5kYW5jeSwgDQogICAgbG9hZCBzaGFyaW5nIG9yIGRp c3RyaWJ1dGVkIGNvbnRyb2wuICBUaGUgaWRlYSBpcyB0byBrZWVwIEZFcyBhcyANCiAgICBzaW1w bGUgYW5kIGR1bWIgYXMgcG9zc2libGUgc28gdGhhdCBGRXMgY2FuIGZvY3VzIHRoZWlyIHJlc291 cmNlIG9uIA0KICAgIHRoZSBwYWNrZXQgcHJvY2Vzc2luZyBmdW5jdGlvbnMuICANCiAgICAgDQog ICAgRm9yIGV4YW1wbGUsIGluIEZpZ3VyZSA1LCBGRTEgYW5kIEZFMiBjYW4gYmUgY29uZmlndXJl ZCB0byBhY2NlcHQgDQogICAgY29tbWFuZHMgZnJvbSBib3RoIHRoZSBwcmltYXJ5IENFIChDRTEp IGFuZCB0aGUgYmFja3VwIENFIChDRTIpLiAgDQogICAgVXBvbiBkZXRlY3Rpb24gb2YgQ0UxIGZh aWx1cmUsIHBlcmhhcHMgYWNyb3NzIHRoZSBGciBvciBGcCANCiAgDQogIA0KIFlhbmcsIGV0IGFs LiAgICAgIEV4cGlyZXMgTWFyY2ggICAgMjAwNCAgICAgICAgICAgICAgICAgICBbUGFnZSAxMV0g ICANCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGcmFtZXdvcmsgICAgICAgICAgICAg ICAgIFNlcHRlbWJlciAyMDAzIA0KICANCiAgDQogICAgcmVmZXJlbmNlIHBvaW50LCBDRTIgaXMg Y29uZmlndXJlZCB0byB0YWtlIG92ZXIgYWN0aXZpdGllcyBvZiBDRTEuICANCiAgICBUaGlzIGlz IGJleW9uZCB0aGUgc2NvcGUgb2YgRm9yQ0VTIGFuZCBpcyBub3QgZGlzY3Vzc2VkIGZ1cnRoZXIu IA0KICAgICANCiAgICBEaXN0cmlidXRlZCBjb250cm9sIGNhbiBiZSBhY2hpZXZlZCBpbiB0aGUg c2ltaWxhciBmYXNoaW9uLCB3aXRob3V0IA0KICAgIG11Y2ggaW50ZWxsaWdlbmNlIG9uIHRoZSBw YXJ0IG9mIEZFcy4gIEZvciBleGFtcGxlLCBGRXMgY2FuIGJlIA0KICAgIGNvbmZpZ3VyZWQgdG8g ZGV0ZWN0IFJTVlAgYW5kIEJHUCBwcm90b2NvbCBwYWNrZXRzLCBhbmQgZm9yd2FyZCANCiAgICBS U1ZQIHBhY2tldHMgdG8gb25lIENFIGFuZCBCR1AgcGFja2V0cyB0byBhbm90aGVyIENFLiAgSGVu Y2UsIEZFcyANCiAgICBtYXkgbmVlZCB0byBkbyBwYWNrZXQgZmlsdGVyaW5nIGZvciBmb3J3YXJk aW5nIHBhY2tldHMgdG8gc3BlY2lmaWMgDQogICAgQ0VzLiANCiAgICAgDQogICAgICAgICAgICAg ICAgIC0tLS0tLS0gICBGciAgLS0tLS0tLSANCiAgICAgICAgICAgICAgICAgfCBDRTEgfCAtLS0t LS18IENFMiB8IA0KICAgICAgICAgICAgICAgICAtLS0tLS0tICAgICAgIC0tLS0tLS0gDQogICAg ICAgICAgICAgICAgICAgfCAgIFwgICAgICAvICAgfCANCiAgICAgICAgICAgICAgICAgICB8ICAg IFwgICAgLyAgICB8IA0KICAgICAgICAgICAgICAgICAgIHwgICAgIFwgIC8gICAgIHwgDQogICAg ICAgICAgICAgICAgICAgfCAgICAgIFwvRnAgICAgfCANCiAgICAgICAgICAgICAgICAgICB8ICAg ICAgL1wgICAgICB8IA0KICAgICAgICAgICAgICAgICAgIHwgICAgIC8gIFwgICAgIHwgDQogICAg ICAgICAgICAgICAgICAgfCAgICAvICAgIFwgICAgfCANCiAgICAgICAgICAgICAgICAgLS0tLS0t LSAgRmkgICAtLS0tLS0tIA0KICAgICAgICAgICAgICAgICB8IEZFMSB8PC0tLS0tPnwgRkUyIHwg DQogICAgICAgICAgICAgICAgIC0tLS0tLS0gICAgICAgLS0tLS0tLSANCiAgDQogICAgICAgICAg ICAgICAgICAgIEZpZ3VyZSA1LiBDRSByZWR1bmRhbmN5IGV4YW1wbGUuIA0KICAgICANCiAgICBU aGlzIGFyY2hpdGVjdHVyZSBwZXJtaXRzIG11bHRpcGxlIEZFcyB0byBiZSBwcmVzZW50IGluIGFu IE5FLiBbM10gDQogICAgZGljdGF0ZXMgdGhhdCB0aGUgRm9yQ0VTIHByb3RvY29sIG11c3QgYmUg YWJsZSB0byBzY2FsZSB0byBhdCBsZWFzdCANCiAgICBodW5kcmVkcyBvZiBGRXMgKHNlZSBbM10g U2VjdGlvbiA1LCByZXF1aXJlbWVudCAjMTEpLiAgRWFjaCBvZiANCiAgICB0aGVzZSBGRXMgbWF5 IHBvdGVudGlhbGx5IGhhdmUgYSBkaWZmZXJlbnQgc2V0IG9mIHBhY2tldCBwcm9jZXNzaW5nIA0K ICAgIGZ1bmN0aW9ucywgd2l0aCBkaWZmZXJlbnQgbWVkaWEgaW50ZXJmYWNlcy4gIEZFcyBhcmUg cmVzcG9uc2libGUgDQogICAgZm9yIGJhc2ljIG1haW50ZW5hbmNlIG9mIGxheWVyLTIgY29ubmVj dGl2aXR5IHdpdGggb3RoZXIgRkVzIGFuZCANCiAgICB3aXRoIGV4dGVybmFsIGVudGl0aWVzLiAg TWFueSBsYXllci0yIG1lZGlhIGluY2x1ZGUgc29waGlzdGljYXRlZCANCiAgICBjb250cm9sIHBy b3RvY29scy4gIFRoZSBGT1JDRVMgcHJvdG9jb2wgKG92ZXIgdGhlIEZwIHJlZmVyZW5jZSANCiAg ICBwb2ludCkgd2lsbCBiZSBhYmxlIHRvIGNhcnJ5IG1lc3NhZ2VzIGZvciBzdWNoIHByb3RvY29s cyBzbyB0aGF0LCANCiAgICBpbiBrZWVwaW5nIHdpdGggdGhlIGR1bWIgRkUgbW9kZWwsIHRoZSBD RSBjYW4gcHJvdmlkZSBhcHByb3ByaWF0ZSANCiAgICBpbnRlbGxpZ2VuY2UgYW5kIGNvbnRyb2wg b3ZlciB0aGVzZSBtZWRpYS4gDQogICAgIA0KICAgIFdoZW4gbXVsdGlwbGUgRkVzIGFyZSBwcmVz ZW50LCBGb3JDRVMgcmVxdWlyZXMgdGhhdCBwYWNrZXRzIG11c3QgYmUgDQogICAgYWJsZSB0byBh cnJpdmUgYXQgdGhlIE5FIGJ5IG9uZSBGRSBhbmQgbGVhdmUgdGhlIE5FIHZpYSBhIGRpZmZlcmVu dCANCiAgICBGRSAoU2VlIFszXSwgU2VjdGlvbiA1LCBSZXF1aXJlbWVudCAjMykuICBQYWNrZXRz IHRoYXQgZW50ZXIgdGhlIE5FIA0KICAgIHZpYSBvbmUgRkUgYW5kIGxlYXZlIHRoZSBORSB2aWEg YSBkaWZmZXJlbnQgRkUgYXJlIHRyYW5zZmVycmVkIA0KICAgIGJldHdlZW4gRkVzIGFjcm9zcyB0 aGUgRmkgcmVmZXJlbmNlIHBvaW50LiAgRmkgcmVmZXJlbmNlIHBvaW50IA0KICAgIGNvdWxkIGJl IHVzZWQgYnkgRkVzIHRvIGRpc2NvdmVyeSB0aGVpciAoaW50ZXItRkUpIHRvcG9sb2d5LCANCiAg ICBwZXJoYXBzIGR1cmluZyBwcmUtYXNzb2NpYXRpb24gcGhhc2UuICBUaGUgRmkgcmVmZXJlbmNl IHBvaW50IGlzIGEgDQogICAgc2VwYXJhdGUgcHJvdG9jb2wgZnJvbSB0aGUgRnAgcmVmZXJlbmNl IHBvaW50IGFuZCBpcyBub3QgY3VycmVudGx5IA0KICAgIGRlZmluZWQgYnkgdGhlIEZvckNFUyBh cmNoaXRlY3R1cmUuIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAg ICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXSAgIA0KIEludGVybmV0IERyYWZ0ICAg ICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQog IA0KICANCiAgICAgDQogICAgRkVzIGNvdWxkIGJlIGNvbm5lY3RlZCBpbiBkaWZmZXJlbnQga2lu ZHMgb2YgdG9wb2xvZ2llcyBhbmQgcGFja2V0IA0KICAgIHByb2Nlc3NpbmcgbWF5IHNwcmVhZCBh Y3Jvc3Mgc2V2ZXJhbCBGRXMgaW4gdGhlIHRvcG9sb2d5LiAgSGVuY2UsIA0KICAgIGxvZ2ljYWwg cGFja2V0IGZsb3cgbWF5IGJlIGRpZmZlcmVudCBmcm9tIHBoeXNpY2FsIEZFIHRvcG9sb2d5LiAN CiAgICBGaWd1cmUgNiBwcm92aWRlcyBzb21lIHRvcG9sb2d5IGV4YW1wbGVzLiAgV2hlbiBpdCBp cyBuZWNlc3NhcnkgdG8gDQogICAgZm9yd2FyZCBwYWNrZXRzIGJldHdlZW4gRkVzLCB0aGUgQ0Ug bmVlZHMgdG8gdW5kZXJzdGFuZCB0aGUgRkUgDQogICAgdG9wb2xvZ3kuICBUaGUgRkUgdG9wb2xv Z3kgbWF5IGJlIHF1ZXJpZWQgZnJvbSB0aGUgRkVzIGJ5IHRoZSBDRXMgDQogICAgdmlhIEZvckNF UyBwcm90b2NvbCwgYnV0IHRoZSBGRXMgYXJlIG5vdCByZXF1aXJlZCB0byBwcm92aWRlIHRoYXQg DQogICAgaW5mb3JtYXRpb24gdG8gdGhlIENFcy4gU28sIHRoZSBGRSB0b3BvbG9neSBpbmZvcm1h dGlvbiBtYXkgYWxzbyBiZSANCiAgICBnYXRoZXJlZCBieSBvdGhlciBtZWFucyBvdXRzaWRlIG9m IHRoZSBGb3JDRVMgcHJvdG9jb2wgKGxpa2UgaW50ZXItDQogICAgRkUgdG9wb2xvZ3kgZGlzY292 ZXJ5IHByb3RvY29sKS4gIA0KICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgQ0UgICAgICAgfCAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg ICAgIC0tLS0tLS0tLS0tLS0tLS0tICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg IF4gICAgICBeICAgICAgXiANCiAgICAgICAgICAgICAgICAgICAgICAgICAvICAgICAgIHwgICAg ICAgXCANCiAgICAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgIHYgICAgICAgIFwgDQogICAg ICAgICAgICAgICAgICAgICAgIC8gICAgICAtLS0tLS0tICAgICAgXCANCiAgICAgICAgICAgICAg ICAgICAgICAvICAgICstPnwgRkUzIHw8LSsgICAgXCANCiAgICAgICAgICAgICAgICAgICAgIC8g ICAgIHwgIHwgICAgIHwgIHwgICAgIFwgDQogICAgICAgICAgICAgICAgICAgIHYgICAgICB8ICAt LS0tLS0tICB8ICAgICAgdiANCiAgICAgICAgICAgICAgICAgIC0tLS0tLS0gIHwgICAgICAgICAg IHwgIC0tLS0tLS0gDQogICAgICAgICAgICAgICAgICB8IEZFMSB8PC0rICAgICAgICAgICArLT58 IEZFMiB8IA0KICAgICAgICAgICAgICAgICAgfCAgICAgfDwtLS0tLS0tLS0tLS0tLS0+fCAgICAg fCANCiAgICAgICAgICAgICAgICAgIC0tLS0tLS0gICAgICAgICAgICAgICAgIC0tLS0tLS0gDQog ICAgICAgICAgICAgICAgICAgICBeICB8ICAgICAgICAgICAgICAgICAgIF4gIHwgDQogICAgICAg ICAgICAgICAgICAgICB8ICB8ICAgICAgICAgICAgICAgICAgIHwgIHwgDQogICAgICAgICAgICAg ICAgICAgICB8ICB2ICAgICAgICAgICAgICAgICAgIHwgIHYgDQogICAgIA0KICAgICAgICAgICAg ICAgICAoYSkgRnVsbCBtZXNoIGFtb25nIEZFMSwgRkUyIGFuZCBGRTMuIA0KICANCiAgICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0gICAgICAgICAgICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgfCAgIENFICAgIHwgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgLS0tLS0tLS0tLS0gICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgIF4gXiAg ICAgICBeIF4gDQogICAgICAgICAgICAgICAgICAgICAgIC8gIHwgICAgICAgfCAgXCANCiAgICAg ICAgICAgICAgICAvLS0tLS0tICAgfCAgICAgICB8ICAgLS0tLS0tXCANCiAgICAgICAgICAgICAg ICB2ICAgICAgICAgdiAgICAgICB2ICAgICAgICAgIHYgDQogICAgICAgICAgICAtLS0tLS0tICAg LS0tLS0tLSAgIC0tLS0tLS0gICAtLS0tLS0tIA0KICAgICAgICAgICAgfCBGRTEgfDwtPnwgRkUy IHw8LT58IEZFMyB8PC0+fCBGRTQgfCANCiAgICAgICAgICAgIC0tLS0tLS0gICAtLS0tLS0tICAg LS0tLS0tLSAgIC0tLS0tLS0gDQogICAgICAgICAgICAgIF4gIHwgICAgIF4gIHwgICAgICAgXiAg fCAgICAgXiAgfCANCiAgICAgICAgICAgICAgfCAgfCAgICAgfCAgfCAgICAgICB8ICB8ICAgICB8 ICB8IA0KICAgICAgICAgICAgICB8ICB2ICAgICB8ICB2ICAgICAgIHwgIHYgICAgIHwgIHYgDQog ICAgIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAg ICAgICAgICAgICAgICAgIFtQYWdlIDEzXSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9y Q0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAg ICAgICAgICAgICAgICAgKGIpIE11bHRpcGxlIEZFcyBpbiBhIGRhaXN5IGNoYWluIA0KICANCiAg DQogIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4gfCANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IHYgDQogICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0gICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgfCAgIEZFMSAgIHw8LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS18ICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0t LS0gICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg XiAgICBeICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgLyAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIA0KICAgICAgICAgICAg ICAgICAgIHwgXiAgIC8gICAgICAgIFwgICBeIHwgICAgICAgICAgICAgICAgICAgViANCiAgICAg ICAgICAgICAgICAgICB2IHwgIHYgICAgICAgICAgdiAgfCB2ICAgICAgICAgICAgICAgIC0tLS0t LS0tLS0gDQogICAgICAgICAgICAgICAgIC0tLS0tLS0tLSAgICAgICAgLS0tLS0tLS0tICAgICAg ICAgICAgICB8ICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8IEZFMiAgIHwgICAgICAgIHwg IEZFMyAgfDwtLS0tLS0tLS0tLS0+fCAgIENFICAgfCANCiAgICAgICAgICAgICAgICAgLS0tLS0t LS0tICAgICAgICAtLS0tLS0tLS0gICAgICAgICAgICAgIHwgICAgICAgIHwgDQogICAgICAgICAg ICAgICAgICAgICBeICBeICAgICAgICAgIF4gICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0t IA0KICAgICAgICAgICAgICAgICAgICAgfCAgIFwgICAgICAgIC8gICAgICAgICAgICAgICAgICAg ICAgICBeICBeIA0KICAgICAgICAgICAgICAgICAgICAgfCAgICBcICAgICAgLyAgICAgICAgICAg ICAgICAgICAgICAgICB8ICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICB2ICAgICB2ICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgIC0t LS0tLS0tLS0tICAgICAgICAgICAgICAgICAgICAgICB8ICB8IA0KICAgICAgICAgICAgICAgICAg ICAgfCAgIHwgICBGRTQgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18ICB8ICAgIA0KICAgICAg ICAgICAgICAgICAgICAgfCAgIC0tLS0tLS0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgICB8 IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwgIF4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHYgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgfC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18IA0KICAgICANCiAgICAgICAgICAg ICAgICAgKGMpIE11bHRpcGxlIEZFcyBjb25uZWN0ZWQgYnkgYSByaW5nIA0KICAgICANCiAgICAg ICAgICAgICAgICAgRmlndXJlIDYuIFNvbWUgZXhhbXBsZXMgb2YgRkUgdG9wb2xvZ3kuIA0KICAg ICANCiAzLjMuQ0UgTWFuYWdlcnMgDQogICAgIA0KICAgIENFIG1hbmFnZXJzIGFyZSByZXNwb25z aWJsZSBmb3IgZGV0ZXJtaW5pbmcgd2hpY2ggRkVzIGEgQ0Ugc2hvdWxkIA0KICAgIGNvbnRyb2wu ICBJdCBpcyBsZWdpdGltYXRlIGZvciBDRSBtYW5hZ2VycyB0byBiZSBoYXJkLWNvZGVkIHdpdGgg DQogICAgdGhlIGtub3dsZWRnZSBvZiB3aXRoIHdoaWNoIEZFcyBpdHMgQ0VzIHNob3VsZCBjb21t dW5pY2F0ZSB3aXRoLiAgQSANCiAgICBDRSBtYW5hZ2VyIG1heSBhbHNvIGJlIHBoeXNpY2FsbHkg ZW1iZWRkZWQgaW50byBhIENFIGFuZCBiZSANCiAgICBpbXBsZW1lbnRlZCBhcyBhIHNpbXBsZSBr ZXlwYWQgb3Igb3RoZXIgZGlyZWN0IGNvbmZpZ3VyYXRpb24gDQogICAgbWVjaGFuaXNtIG9uIHRo ZSBDRS4gIEZpbmFsbHksIENFIG1hbmFnZXJzIG1heSBiZSBwaHlzaWNhbGx5IGFuZCANCiAgICBs b2dpY2FsbHkgc2VwYXJhdGUgZW50aXRpZXMgdGhhdCBjb25maWd1cmUgdGhlIENFIHdpdGggRkUg DQogICAgaW5mb3JtYXRpb24gdmlhIHN1Y2ggbWVjaGFuaXNtcyBhcyBDT1BTLVBSIFs2XSBvciBT Tk1QIFs0XS4gDQogICAgIA0KIDMuNC4gRkUgTWFuYWdlcnMgDQogICAgIA0KICAgIEZFIG1hbmFn ZXJzIGFyZSByZXNwb25zaWJsZSBmb3IgZGV0ZXJtaW5pbmcgd2l0aCB3aGljaCBDRSBhbnkgDQog ICAgcGFydGljdWxhciBGRSBzaG91bGQgaW5pdGlhbGx5IGNvbW11bmljYXRlLiAgTGlrZSBDRSBt YW5hZ2Vycywgbm8gDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIE1hcmNoICAg IDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdICAgDQogSW50ZXJuZXQgRHJhZnQgICAg ICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMyANCiAg DQogIA0KICAgIHJlc3RyaWN0aW9ucyBhcmUgcGxhY2VkIG9uIGhvdyBhbiBGRSBtYW5hZ2VyIGRl Y2lkZXMgd2l0aCB3aGljaCBDRSANCiAgICBpdHMgRkVzIHNob3VsZCBjb21tdW5pY2F0ZSwgbm9y IGFyZSByZXN0cmljdGlvbnMgcGxhY2VkIG9uIGhvdyBGRSANCiAgICBtYW5hZ2VycyBhcmUgaW1w bGVtZW50ZWQuICBFYWNoIEZFIHNob3VsZCBoYXZlIG9uZSBhbmQgb25seSBvbmUgRkUgDQogICAg bWFuYWdlciwgd2hpbGUgZGlmZmVyZW50IEZFcyBtYXkgaGF2ZSB0aGUgc2FtZSBvciBkaWZmZXJl bnQgRkUgDQogICAgbWFuYWdlcihzKS4gIEVhY2ggbWFuYWdlciBjYW4gY2hvb3NlIHRvIGV4aXN0 IGFuZCBvcGVyYXRlIA0KICAgIGluZGVwZW5kZW50bHkgb2Ygb3RoZXIgbWFuYWdlci4gDQogIA0K IDQuIE9wZXJhdGlvbmFsIFBoYXNlcyANCiAgICAgDQogICAgQm90aCBGRXMgYW5kIENFcyByZXF1 aXJlIHNvbWUgY29uZmlndXJhdGlvbiBpbiBwbGFjZSBiZWZvcmUgdGhleSANCiAgICBjYW4gc3Rh cnQgaW5mb3JtYXRpb24gZXhjaGFuZ2UgYW5kIGZ1bmN0aW9uIGFzIGEgY29oZXJlbnQgbmV0d29y ayANCiAgICBlbGVtZW50LiAgVHdvIG9wZXJhdGlvbmFsIHBoYXNlcyBhcmUgaWRlbnRpZmllZCBp biB0aGlzIGZyYW1ld29yazogDQogICAgcHJlLWFzc29jaWF0aW9uIGFuZCBwb3N0LWFzc29jaWF0 aW9uLiAgDQogICAgIA0KIDQuMS5QcmUtYXNzb2NpYXRpb24gUGhhc2UgDQogIA0KICAgIFByZS1h c3NvY2lhdGlvbiBwaGFzZSBpcyB0aGUgcGVyaW9kIG9mIHRpbWUgZHVyaW5nIHdoaWNoIGFuIEZF IA0KICAgIE1hbmFnZXIgYW5kIGEgQ0UgTWFuYWdlciBhcmUgZGV0ZXJtaW5pbmcgd2hpY2ggRkUg YW5kIENFIHNob3VsZCBiZSANCiAgICBwYXJ0IG9mIHRoZSBzYW1lIG5ldHdvcmsgZWxlbWVudC4g IFRoZSBwcm90b2NvbHMgdXNlZCBkdXJpbmcgdGhpcyANCiAgICBwaGFzZSBtYXkgaW5jbHVkZSBh bGwgb3Igc29tZSBvZiB0aGUgbWVzc2FnZSBleGNoYW5nZSBvdmVyIEZsLCBGZiANCiAgICBhbmQg RmMgcmVmZXJlbmNlIHBvaW50cy4gIEhvd2V2ZXIsIGFsbCB0aGVzZSBtYXkgYmUgb3B0aW9uYWwg YW5kIA0KICAgIG5vbmUgb2YgdGhpcyBpcyB3aXRoaW4gdGhlIHNjb3BlIG9mIEZvckNFUyBwcm90 b2NvbC4gDQogICAgIA0KIDQuMS4xLiBGbCBSZWZlcmVuY2UgUG9pbnQgDQogIA0KICAgIENFIG1h bmFnZXJzIGFuZCBGRSBtYW5hZ2VycyBtYXkgY29tbXVuaWNhdGUgYWNyb3NzIHRoZSBGbCByZWZl cmVuY2UgDQogICAgcG9pbnQgaW4gdGhlIHByZS1hc3NvY2lhdGlvbiBwaGFzZSBpbiBvcmRlciB0 byBkZXRlcm1pbmUgd2hpY2ggQ0VzIA0KICAgIGFuZCBGRXMgc2hvdWxkIGNvbW11bmljYXRlIHdp dGggZWFjaCBvdGhlci4gIENvbW11bmljYXRpb24gYWNyb3NzIA0KICAgIHRoZSBGbCByZWZlcmVu Y2UgcG9pbnQgaXMgb3B0aW9uYWwgaW4gdGhpcyBhcmNoaXRlY3R1cmUuICBObyANCiAgICByZXF1 aXJlbWVudHMgYXJlIHBsYWNlZCBvbiB0aGlzIHJlZmVyZW5jZSBwb2ludC4gDQogIA0KICAgIENF IG1hbmFnZXJzIGFuZCBGRSBtYW5hZ2VycyBtYXkgYmUgb3BlcmF0ZWQgYnkgZGlmZmVyZW50IGVu dGl0aWVzLiAgDQogICAgVGhlIG9wZXJhdG9yIG9mIHRoZSBDRSBtYW5hZ2VyIG1heSBub3Qgd2Fu dCB0byBkaXZ1bGdlLCBleGNlcHQgdG8gDQogICAgc3BlY2lmaWVkIEZFIG1hbmFnZXJzLCBhbnkg Y2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBDRXMgaXQgbWFuYWdlcy4gICANCiAgICBTaW1pbGFybHks IHRoZSBvcGVyYXRvciBvZiB0aGUgRkUgbWFuYWdlciBtYXkgbm90IHdhbnQgdG8gZGl2dWxnZSAN CiAgICBGRSBjaGFyYWN0ZXJpc3RpY3MsIGV4Y2VwdCB0byBhdXRob3JpemVkIGVudGl0aWVzLiAg QXMgc3VjaCwgQ0UgDQogICAgbWFuYWdlcnMgYW5kIEZFIG1hbmFnZXJzIG1heSBuZWVkIHRvIGF1 dGhlbnRpY2F0ZSBvbmUgYW5vdGhlci4gICANCiAgICBTdWJzZXF1ZW50IGNvbW11bmljYXRpb24g YmV0d2VlbiBDRSBtYW5hZ2VycyBhbmQgRkUgbWFuYWdlcnMgbWF5IA0KICAgIHJlcXVpcmUgb3Ro ZXIgc2VjdXJpdHkgZnVuY3Rpb25zIHN1Y2ggYXMgcHJpdmFjeSwgbm9uLXJlcHVkaWF0aW9uLCAN CiAgICBmcmVzaG5lc3MsIGFuZCBpbnRlZ3JpdHkuIA0KICAgICANCiAgICAgICAgIEZFIE1hbmFn ZXIgICAgICBGRSAgICAgICAgICAgICAgIENFIE1hbmFnZXIgICAgIENFIA0KICAgICAgICAgIHwg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCANCiAgICAgICAg ICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgDQogICAg ICAgICAgfChzZWN1cml0eSBleGNoYW5nZSkgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0K ICAgICAgICAgMXw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAg fCANCiAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgIHwgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIE1hcmNoICAgIDIwMDQg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTVdICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBG b3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0K ICAgICAgICAgIHwoYSBsaXN0IG9mIENFcyBhbmQgdGhlaXIgYXR0cmlidXRlcykgICAgICAgICAg fCANCiAgICAgICAgIDJ8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAg ICAgIHwgDQogICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8IA0KICAgICAgICAgIHwoYSBsaXN0IG9mIEZFcyBhbmQgdGhlaXIgYXR0cmlidXRl cykgICAgICAgICAgfCANCiAgICAgICAgIDN8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LT58ICAgICAgICAgICAgIHwgDQogICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICB8IA0KICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgfCANCiAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS1G bC0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgIHwgDQogICAgIA0KICAgICAgRmlndXJlIDcuIEFu IGV4YW1wbGUgb2YgbWVzc2FnZSBleGNoYW5nZSBvdmVyIEZsIHJlZmVyZW5jZSBwb2ludCANCiAg ICAgDQogICAgT25jZSB0aGUgbmVjZXNzYXJ5IHNlY3VyaXR5IGZ1bmN0aW9ucyBoYXZlIGJlZW4g cGVyZm9ybWVkLCB0aGUgQ0UgDQogICAgYW5kIEZFIG1hbmFnZXJzIGNvbW11bmljYXRlIHRvIGRl dGVybWluZSB3aGljaCBDRXMgYW5kIEZFcyBzaG91bGQgDQogICAgY29tbXVuaWNhdGUgd2l0aCBl YWNoIG90aGVyLiAgQXQgdGhlIHZlcnkgbWluaW11bSwgdGhlIENFIGFuZCBGRSANCiAgICBtYW5h Z2VycyBuZWVkIHRvIGxlYXJuIG9mIHRoZSBleGlzdGVuY2Ugb2YgYXZhaWxhYmxlIEZFcyBhbmQg Q0VzIA0KICAgIHJlc3BlY3RpdmVseS4gIFRoaXMgZGlzY292ZXJ5IHByb2Nlc3MgbWF5IGVudGFp bCBvbmUgb3IgYm90aCANCiAgICBtYW5hZ2VycyBsZWFybmluZyB0aGUgY2FwYWJpbGl0aWVzIG9m IHRoZSBkaXNjb3ZlcmVkIEZvckNFUyANCiAgICBwcm90b2NvbCBlbGVtZW50cy4gIEZpZ3VyZSA3 IHNob3dzIGFuIGV4YW1wbGUgb2YgcG9zc2libGUgbWVzc2FnZSANCiAgICBleGNoYW5nZSBiZXR3 ZWVuIENFIG1hbmFnZXIgYW5kIEZFIG1hbmFnZXIgb3ZlciBGbCByZWZlcmVuY2UgcG9pbnQuIA0K ICAgICANCiA0LjEuMi4gRmYgUmVmZXJlbmNlIFBvaW50IA0KICAgICANCiAgICBUaGUgRmYgcmVm ZXJlbmNlIHBvaW50IGlzIHVzZWQgdG8gaW5mb3JtIGZvcndhcmRpbmcgZWxlbWVudHMgb2YgdGhl IA0KICAgIGFzc29jaWF0aW9uIGRlY2lzaW9ucyBtYWRlIGJ5IHRoZSBGRSBtYW5hZ2VyIGluIHBy ZS1hc3NvY2lhdGlvbiANCiAgICBwaGFzZS4gIE9ubHkgYXV0aG9yaXplZCBlbnRpdGllcyBtYXkg aW5zdHJ1Y3QgYW4gRkUgd2l0aCByZXNwZWN0IHRvIA0KICAgIHdoaWNoIENFIHNob3VsZCBjb250 cm9sIGl0LiAgVGhlcmVmb3JlLCBwcml2YWN5LCBpbnRlZ3JpdHksIA0KICAgIGZyZXNobmVzcywg YW5kIGF1dGhlbnRpY2F0aW9uIGFyZSBuZWNlc3NhcnkgYmV0d2VlbiB0aGUgRkUgbWFuYWdlciAN CiAgICBhbmQgRkVzIHdoZW4gdGhlIEZFIG1hbmFnZXIgaXMgcmVtb3RlIHRvIHRoZSBGRS4gIE9u Y2UgdGhlIA0KICAgIGFwcHJvcHJpYXRlIHNlY3VyaXR5IGhhcyBiZWVuIGVzdGFibGlzaGVkLCB0 aGUgRkUgbWFuYWdlciBpbnN0cnVjdHMgDQogICAgdGhlIEZFcyBhY3Jvc3MgdGhpcyByZWZlcmVu Y2UgcG9pbnQgdG8gam9pbiBhIG5ldyBORSBvciB0byANCiAgICBkaXNjb25uZWN0IGZyb20gYW4g ZXhpc3RpbmcgTkUuIFRoZSBGRSBNYW5hZ2VyIGNvdWxkIGFsc28gYXNzaWduIA0KICAgIHVuaXF1 ZSBGRSBpZGVudGlmaWVycyB0byB0aGUgRkVzIHVzaW5nIHRoaXMgcmVmZXJlbmNlIHBvaW50LiAg VGhlIA0KICAgIEZFIGlkZW50aWZpZXJzIGFyZSB1c2VmdWwgaW4gcG9zdCBhc3NvY2lhdGlvbiBw aGFzZSB0byBleHByZXNzIEZFIA0KICAgIHRvcG9sb2d5LiAgRmlndXJlIDggc2hvd3MgZXhhbXBs ZSBvZiBtZXNzYWdlIGV4Y2hhbmdlIG92ZXIgRmYgDQogICAgcmVmZXJlbmNlIHBvaW50LiANCiAg DQogICAgICAgICBGRSBNYW5hZ2VyICAgICAgRkUgICAgICAgICAgICAgICBDRSBNYW5hZ2VyICAg ICBDRSANCiAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgfCANCiAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgfCANCiAgICAgICAgICB8KHNlY3VyaXR5IGV4Y2hhbmdlKSAgICAgICAgICAgIHwo c2VjdXJpdHkgZXhjaGFuZ2UpIA0KICAgICAgICAgMXw8LS0tLS0tLS0tLS0tPnxhdXRoZW50aWNh dGlvbiAxfDwtLS0tLS0tLS0tLT58YXV0aGVudGljYXRpb24NCiAgICAgICAgICB8ICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCANCiAgICAgICAgICB8KEZFIElE LCBhdHRyaWJ1dGVzKSAgICAgICAgICAgIHwoQ0UgSUQsIGF0dHJpYnV0ZXMpIA0KICAgICAgICAg Mnw8LS0tLS0tLS0tLS0tLXxyZXF1ZXN0ICAgICAgICAyfDwtLS0tLS0tLS0tLT58cmVxdWVzdCAN CiAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg fCANCiAgICAgICAgIDN8LS0tLS0tLS0tLS0tLT58cmVzcG9uc2UgICAgICAgM3wtLS0tLS0tLS0t LS0+fHJlc3BvbnNlIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAg ICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDE2XSAgIA0KIEludGVybmV0IERyYWZ0ICAg ICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQog IA0KICANCiAgICAgICAgICB8KGNvcnJlc3BvbmRpbmcgQ0UgSUQpICAgICAgICAgIHwoY29ycmVz cG9uZGluZyBGRSBJRCkgDQogICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgIHwgDQogICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgIHwgDQogICAgICAgICAgfDwtLS0tLUZmLS0tLS0+fCAgICAgICAg ICAgICAgICB8PC0tLS0tRmMtLS0tPnwgDQogICAgIA0KICAgICAgICAgICAgICAgICAgICAgRmln dXJlIDguIEV4YW1wbGVzIG9mIG1lc3NhZ2UgZXhjaGFuZ2UgDQogICAgICAgICAgICAgICAgICAg ICAgICBvdmVyIEZmIGFuZCBGYyByZWZlcmVuY2UgcG9pbnRzLiANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgTm90ZSB0aGF0IHRoZSBGRSBtYW5hZ2VyIGZ1 bmN0aW9uIG1heSBiZSBjby1sb2NhdGVkIHdpdGggdGhlIEZFIA0KICAgIChzdWNoIGFzIGJ5IG1h bnVhbCBrZXlwYWQgZW50cnkgb2YgdGhlIENFIElQIGFkZHJlc3MpLCBpbiB3aGljaCANCiAgICBj YXNlIHRoaXMgcmVmZXJlbmNlIHBvaW50IGlzIHJlZHVjZWQgdG8gYSBidWlsdC1pbiBmdW5jdGlv bi4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICANCiA0 LjEuMy4gRmMgUmVmZXJlbmNlIFBvaW50IA0KICAgICANCiAgICBUaGUgRmMgcmVmZXJlbmNlIHBv aW50IGlzIHVzZWQgdG8gaW5mb3JtIGNvbnRyb2wgZWxlbWVudHMgb2YgdGhlIA0KICAgIGFzc29j aWF0aW9uIGRlY2lzaW9ucyBtYWRlIGJ5IENFIG1hbmFnZXJzIGluIHByZS1hc3NvY2lhdGlvbiBw aGFzZS4gDQogICAgV2hlbiB0aGUgQ0UgbWFuYWdlciBpcyByZW1vdGUsIG9ubHkgYXV0aG9yaXpl ZCBlbnRpdGllcyBtYXkgDQogICAgaW5zdHJ1Y3QgYSBDRSB0byBjb250cm9sIGNlcnRhaW4gRkVz LiAgUHJpdmFjeSwgaW50ZWdyaXR5LCANCiAgICBmcmVzaG5lc3MgYW5kIGF1dGhlbnRpY2F0aW9u IGFyZSBhbHNvIHJlcXVpcmVkIGFjcm9zcyB0aGlzIA0KICAgIHJlZmVyZW5jZSBwb2ludCBpbiBz dWNoIGEgY29uZmlndXJhdGlvbi4gIE9uY2UgYXBwcm9wcmlhdGUgc2VjdXJpdHkgDQogICAgaGFz IGJlZW4gZXN0YWJsaXNoZWQsIHRoZSBDRSBtYW5hZ2VyIGluc3RydWN0cyBDRXMgYXMgdG8gd2hp Y2ggRkVzIA0KICAgIHRoZXkgc2hvdWxkIGNvbnRyb2wgYW5kIGhvdyB0aGV5IHNob3VsZCBjb250 cm9sIHRoZW0uICBGaWd1cmUgOCANCiAgICBzaG93cyBleGFtcGxlIG9mIG1lc3NhZ2UgZXhjaGFu Z2Ugb3ZlciBGYyByZWZlcmVuY2UgcG9pbnQuIA0KICANCiAgICBBcyB3aXRoIHRoZSBGRSBtYW5h Z2VyIGFuZCBGRXMsIGNvbmZpZ3VyYXRpb25zIGFyZSBwb3NzaWJsZSB3aGVyZSANCiAgICB0aGUg Q0UgbWFuYWdlciBhbmQgQ0UgYXJlIGNvLWxvY2F0ZWQgYW5kIG5vIHByb3RvY29sIGlzIHVzZWQg Zm9yIA0KICAgIHRoaXMgZnVuY3Rpb24uIA0KICAgICANCiA0LjIuIFBvc3QtYXNzb2NpYXRpb24g UGhhc2UgYW5kIEZwIHJlZmVyZW5jZSBwb2ludCANCiAgICAgDQogICAgUG9zdC1hc3NvY2lhdGlv biBwaGFzZSBpcyB0aGUgcGVyaW9kIG9mIHRpbWUgZHVyaW5nIHdoaWNoIGFuIEZFIGFuZCANCiAg ICBDRSBoYXZlIGJlZW4gY29uZmlndXJlZCB3aXRoIGluZm9ybWF0aW9uIG5lY2Vzc2FyeSB0byBj b250YWN0IGVhY2ggDQogICAgb3RoZXIgYW5kIGluY2x1ZGVzIGJvdGggYXNzb2NpYXRpb24gZXN0 YWJsaXNobWVudCBhbmQgc3RlYWR5LXN0YXRlIA0KICAgIGNvbW11bmljYXRpb24uICBUaGUgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIENFIGFuZCBGRSBpcyBwZXJmb3JtZWQgDQogICAgYWNyb3NzIHRo ZSBGcCAoInAiIG1lYW5pbmcgcHJvdG9jb2wpIHJlZmVyZW5jZSBwb2ludC4gRm9yQ0VTIA0KICAg IHByb3RvY29sIGlzIGV4Y2x1c2l2ZWx5IHVzZWQgZm9yIGFsbCBjb21tdW5pY2F0aW9uIGFjcm9z cyB0aGUgRnAgDQogICAgcmVmZXJlbmNlIHBvaW50LiAgDQogICAgIA0KIDQuMi4xLiBQcm94aW1p dHkgYW5kIEludGVyY29ubmVjdCBiZXR3ZWVuIENFcyBhbmQgRkVzIA0KICAgICANCiAgICBUaGUg Rm9yQ0VTIFdvcmtpbmcgR3JvdXAgaGFzIG1hZGUgYSBjb25zY2lvdXMgZGVjaXNpb24gdGhhdCB0 aGUgDQogICAgZmlyc3QgdmVyc2lvbiBvZiBGb3JDRVMgd2lsbCBiZSBmb2N1c2VkIG9uICJ2ZXJ5 IGNsb3NlIiBDRS9GRSANCiAgICBsb2NhbGl0aWVzIGluIElQIG5ldHdvcmtzLiBWZXJ5IENsb3Nl IGxvY2FsaXRpZXMgY29uc2lzdCBvZiBjb250cm9sIA0KICAgIGFuZCBmb3J3YXJkaW5nIGVsZW1l bnRzIHRoYXQgZWl0aGVyIGFyZSBjb21wb25lbnRzIGluIHRoZSBzYW1lIA0KICAgIHBoeXNpY2Fs IGJveCwgb3IgYXJlIHNlcGFyYXRlZCBhdCBtb3N0IGJ5IG9uZSBsb2NhbCBuZXR3b3JrIGhvcCAN CiAgICAoWzddKS4gIENFcyBhbmQgRkVzIGNhbiBiZSBjb25uZWN0ZWQgYnkgYSB2YXJpZXR5IG9m IGludGVyY29ubmVjdCANCiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgTWFyY2gg ICAgMjAwNCAgICAgICAgICAgICAgICAgICBbUGFnZSAxN10gICANCiBJbnRlcm5ldCBEcmFmdCAg ICAgICAgIEZvckNFUyBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAyMDAzIA0K ICANCiAgDQogICAgdGVjaG5vbG9naWVzLCBpbmNsdWRpbmcgRXRoZXJuZXQgY29ubmVjdGlvbnMs IGJhY2twbGFuZXMsIEFUTSANCiAgICAoY2VsbCkgZmFicmljcywgZXRjLiAgRm9yQ0VTIHNob3Vs ZCBiZSBhYmxlIHRvIHN1cHBvcnQgZWFjaCBvZiANCiAgICB0aGVzZSBpbnRlcmNvbm5lY3RzIChz ZWUgWzNdIFNlY3Rpb24gNSwgcmVxdWlyZW1lbnQgIzEpLiAgV2hlbiB0aGUgDQogICAgQ0VzIGFu ZCBGRXMgYXJlIHNlcGFyYXRlZCBiZXlvbmQgYSBzaW5nbGUgTDMgcm91dGluZyBob3AsIHRoZSAN CiAgICBGb3JDRVMgcHJvdG9jb2wgd2lsbCBtYWtlIHVzZSBvZiBhbiBleGlzdGluZyBSRkMyOTE0 IGNvbXBsaWFudCBMNCANCiAgICBwcm90b2NvbCB3aXRoIGFkZXF1YXRlIHJlbGlhYmlsaXR5LCBz ZWN1cml0eSBhbmQgY29uZ2VzdGlvbiBjb250cm9sIA0KICAgIChlLmcuIFRDUCwgU0NUUCkgZm9y IHRyYW5zcG9ydCBwdXJwb3Nlcy4gDQogICAgIA0KIDQuMi4yLiBBc3NvY2lhdGlvbiBFc3RhYmxp c2htZW50IA0KICAgICANCiAgICAgDQogICAgICAgICAgICAgICAgIEZFICAgICAgICAgICAgICAg ICAgICAgIENFIA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0K ICAgICAgICAgICAgICAgICB8KFNlY3VyaXR5IGV4Y2hhbmdlLikgICB8IA0KICAgICAgICAgICAg ICAgIDF8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLT58IA0KICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8KExldCBtZSBqb2luIHRoZSBO RSBwbGVhc2UuKSAgICANCiAgICAgICAgICAgICAgICAyfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+ fCANCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAg ICAgICAgICAgfChXaGF0IGtpbmQgb2YgRkUgYXJlIHlvdT8gLS0gY2FwYWJpbGl0eSBxdWVyeSkg DQogICAgICAgICAgICAgICAgM3w8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgDQogICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgIHwoSGVy ZSBpcyBteSBGRSBmdW5jdGlvbnMvc3RhdGU6IHVzZSBtb2RlbCB0byANCiAgICBkZXNjcmliZSkg DQogICAgICAgICAgICAgICAgNHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgDQogICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgIHwoSG93 IGFyZSB5b3UgY29ubmVjdGVkIHdpdGggb3RoZXIgRkVzPykgDQogICAgICAgICAgICAgICAgNXw8 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgDQogICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgIHwoSGVyZSBpcyB0aGUgRkUgdG9wb2xvZ3kg aW5mbykgDQogICAgICAgICAgICAgICAgNnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgDQogICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAg IHwoSW5pdGlhbCBjb25maWcgZm9yIEZFIC0tIG9wdGlvbmFsKSANCiAgICAgICAgICAgICAgICA3 fDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCANCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgfChJIGFtIHJlYWR5IHRvIGdvLiBTaGFs bCBJPykgICAgIA0KICAgICAgICAgICAgICAgIDh8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58IA0K ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAg ICAgICB8KEdvIGFoZWFkISkgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgIDl8PC0tLS0t LS0tLS0tLS0tLS0tLS0tLS18IA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICB8IA0KICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgRmlndXJlIDkuIEV4YW1wbGUg b2YgbWVzc2FnZSBleGNoYW5nZSBiZXR3ZWVuIENFIGFuZCBGRSANCiAgICAgICAgICAgICAgICAg ICAgb3ZlciBGcCB0byBlc3RhYmxpc2ggTkUgYXNzb2NpYXRpb24gDQogICAgIA0KICAgIEFzIGFu IGV4YW1wbGUsIGZpZ3VyZSA5IHNob3dzIHNvbWUgb2YgdGhlIG1lc3NhZ2UgZXhjaGFuZ2UgdGhh dCBtYXkgDQogICAgaGFwcGVuIGJlZm9yZSB0aGUgYXNzb2NpYXRpb24gYmV0d2VlbiB0aGUgQ0Ug YW5kIEZFIGlzIGZ1bGx5IA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJj aCAgICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDE4XSAgIA0KIEludGVybmV0IERyYWZ0 ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMg DQogIA0KICANCiAgICBlc3RhYmxpc2hlZC4gIEVpdGhlciB0aGUgQ0Ugb3IgRkUgY2FuIGluaXRp YXRlIHRoZSBjb25uZWN0aW9uLiANCiAgICBTZWN1cml0eSBoYW5kc2hha2UgaXMgbmVjZXNzYXJ5 IHRvIGF1dGhlbnRpY2F0ZSB0aGUgdHdvIA0KICAgIGNvbW11bmljYXRpb24gZW5kcG9pbnRzIHRv IGVhY2ggb3RoZXIgYmVmb3JlIGFueSBmdXJ0aGVyIG1lc3NhZ2UgDQogICAgZXhjaGFuZ2UgY2Fu IGhhcHBlbi4gVGhlIGV4YWN0IGRldGFpbHMgb2YgdGhlIHNlY3VyaXR5IGhhbmRzaGFrZSANCiAg ICBkZXBlbmQgb24gdGhlIHNlY3VyaXR5IHNvbHV0aW9uIGNob3NlbiBieSBGb3JDRVMgcHJvdG9j b2wuICBTZWN0aW9uIA0KICAgIDggcHJvdmlkZXMgbW9yZSBkZXRhaWxzIG9uIHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBmb3IgRm9yQ0VTLiAgDQogICAgQWZ0ZXIgdGhlIHN1Y2Nlc3NmdWwg c2VjdXJpdHkgaGFuZHNoYWtlLCB0aGUgRkUgbmVlZHMgdG8gaW5mb3JtIHRoZSANCiAgICBDRSBv ZiBpdHMgb3duIGNhcGFiaWxpdHkgYW5kIGl0cyB0b3BvbG9neSBpbiByZWxhdGlvbiB0byBvdGhl ciBGRXMuIA0KICAgIFRoZSBjYXBhYmlsaXR5IG9mIHRoZSBGRSBpcyByZXByZXNlbnRlZCBieSB0 aGUgRkUgbW9kZWwsIGRlc2NyaWJlZCANCiAgICBpbiBhIHNlcGFyYXRlIGRvY3VtZW50LiAgVGhl IG1vZGVsIHdvdWxkIGFsbG93IGFuIEZFIHRvIGRlc2NyaWJlIA0KICAgIHdoYXQga2luZCBvZiBw YWNrZXQgcHJvY2Vzc2luZyBmdW5jdGlvbnMgaXQgY29udGFpbnMsIGluIHdoYXQgb3JkZXIgDQog ICAgdGhlIHByb2Nlc3NpbmcgaGFwcGVucywgd2hhdCBraW5kcyBvZiBjb25maWd1cmFibGUgcGFy YW1ldGVycyBpdCANCiAgICBhbGxvd3MsIHdoYXQgc3RhdGlzdGljcyBpdCBjb2xsZWN0cyBhbmQg d2hhdCBldmVudHMgaXQgbWlnaHQgdGhyb3csIA0KICAgIGV0Yy4gIE9uY2Ugc3VjaCBpbmZvcm1h dGlvbiBpcyBhdmFpbGFibGUgdG8gdGhlIENFLCB0aGUgQ0UgbWF5IA0KICAgIGNob29zZSB0byBz ZW5kIHNvbWUgaW5pdGlhbCBvciBkZWZhdWx0IGNvbmZpZ3VyYXRpb24gdG8gdGhlIEZFIHNvIA0K ICAgIHRoYXQgdGhlIEZFIGNhbiBzdGFydCByZWNlaXZpbmcgYW5kIHByb2Nlc3NpbmcgcGFja2V0 cyBjb3JyZWN0bHkuICANCiAgICBTdWNoIGluaXRpYWxpemF0aW9uIG1heSBub3QgYmUgbmVjZXNz YXJ5IGlmIHRoZSBGRSBhbHJlYWR5IG9idGFpbnMgDQogICAgdGhlIGluZm9ybWF0aW9uIGZyb20g aXRzIG93biBib290c3RyYXAgcHJvY2Vzcy4gIE9uY2UgRkUgc3RhcnRzIA0KICAgIGFjY2VwdGlu ZyBwYWNrZXRzIGZvciBwcm9jZXNzaW5nLCB3ZSBzYXkgdGhlIGFzc29jaWF0aW9uIG9mIHRoaXMg RkUgDQogICAgd2l0aCBpdHMgQ0UgaXMgbm93IGVzdGFibGlzaGVkLiAgRnJvbSB0aGVuIG9uLCB0 aGUgQ0UgYW5kIEZFIGVudGVyIA0KICAgIHN0ZWFkeS1zdGF0ZSBjb21tdW5pY2F0aW9uLiANCiAg ICAgDQogICAgIA0KIDQuMi4zLiBTdGVhZHktc3RhdGUgQ29tbXVuaWNhdGlvbiANCiAgDQogICAg T25jZSBhbiBhc3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVuIHRoZSBDRSBhbmQgRkUs IHRoZSANCiAgICBGb3JDRVMgcHJvdG9jb2wgaXMgdXNlZCBieSB0aGUgQ0UgYW5kIEZFIG92ZXIg RnAgcmVmZXJlbmNlIHBvaW50IHRvIA0KICAgIGV4Y2hhbmdlIGluZm9ybWF0aW9uIHRvIGZhY2ls aXRhdGUgcGFja2V0IHByb2Nlc3NpbmcuICANCiAgICAgDQogICAgICAgICAgICAgICAgIEZFICAg ICAgICAgICAgICAgICAgICAgIENFIA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8KEFkZCB0aGVzZSBuZXcgcm91dGVzLil8IA0K ICAgICAgICAgICAgICAgIDF8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18IA0KICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8KFN1Y2Nl c3NmdWwuKSAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgIDJ8LS0tLS0tLS0tLS0tLS0tLS0t LS0tLT58IA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAg ICB8KFF1ZXJ5IHNvbWUgc3RhdHMuKSAgICB8IA0KICAgICAgICAgICAgICAgIDF8PC0tLS0tLS0t LS0tLS0tLS0tLS0tLS18IA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgICAgICAgICB8KFJlcGx5IHdpdGggc3RhdHMgY29sbGVjdGVkLikgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgIDJ8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58IA0KICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8KE15IHBvcnQg aXMgZG93biwgd2l0aCBwb3J0ICMuKSAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgIDF8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58IA0KICANCiAgDQogWWFuZywgZXQgYWwuICAg ICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDE5XSAgIA0K IEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAg U2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgfChIZXJlIGlzIGEgbmV3IGZvcndhcmRpbmcg dGFibGUpICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgIDJ8PC0tLS0tLS0tLS0tLS0t LS0tLS0tLS18ICAgICANCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg fCANCiAgICAgICAgIEZpZ3VyZSAxMC4gRXhhbXBsZXMgb2YgbWVzc2FnZSBleGNoYW5nZSBiZXR3 ZWVuIENFIGFuZCBGRSANCiAgICAgICAgICAgICAgICAgb3ZlciBGcCBkdXJpbmcgc3RlYWR5LXN0 YXRlIGNvbW11bmljYXRpb24gDQogICAgIA0KICAgIEJhc2VkIG9uIHRoZSBpbmZvcm1hdGlvbiBh Y3F1aXJlZCB0aHJvdWdoIENFcycgY29udHJvbCBwcm9jZXNzaW5nLCANCiAgICBDRXMgd2lsbCBm cmVxdWVudGx5IG5lZWQgdG8gbWFuaXB1bGF0ZSB0aGUgcGFja2V0LWZvcndhcmRpbmcgDQogICAg YmVoYXZpb3JzIG9mIHRoZWlyIEZFKHMpIGJ5IHNlbmRpbmcgaW5zdHJ1Y3Rpb25zIHRvIEZFcy4g IEZvciANCiAgICBleGFtcGxlLCBGaWd1cmUgMTAgc2hvd3MgbWVzc2FnZSBleGNoYW5nZSBleGFt cGxlcyBpbiB3aGljaCB0aGUgQ0UgDQogICAgc2VuZHMgbmV3IHJvdXRlcyB0byB0aGUgRkUgc28g dGhhdCB0aGUgRkUgY2FuIGFkZCB0aGVtIHRvIGl0cyANCiAgICBmb3J3YXJkaW5nIHRhYmxlLiAg VGhlIENFIG1heSBxdWVyeSB0aGUgRkUgZm9yIHN0YXRpc3RpY3MgY29sbGVjdGVkIA0KICAgIGJ5 IHRoZSBGRSBhbmQgdGhlIEZFIG1heSBub3RpZnkgdGhlIENFIG9mIGltcG9ydGFudCBldmVudHMg c3VjaCBhcyANCiAgICBwb3J0IGZhaWx1cmUuIA0KICAgICANCiA0LjIuNC4gRGF0YSBQYWNrZXRz IGFjcm9zcyBGcCByZWZlcmVuY2UgcG9pbnQgDQogICAgIA0KICAgICAgICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8IA0KICAg ICAgICAgfCAgICArLS0tLS0tLS0rICAgICB8ICAgICAgICAgICB8ICAgICArLS0tLS0tLS0rICAg ICB8IA0KICAgICAgICAgfCAgICB8Q0UoQkdQKSB8ICAgICB8ICAgICAgICAgICB8ICAgICB8Q0Uo QkdQKSB8ICAgICB8IA0KICAgICAgICAgfCAgICArLS0tLS0tLS0rICAgICB8ICAgICAgICAgICB8 ICAgICArLS0tLS0tLS0rICAgICB8IA0KICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICB8ICAg ICAgICAgICB8ICAgICAgICAgIF4gICAgICAgICB8IA0KICAgICAgICAgfCAgICAgICAgfEZwICAg ICAgICB8ICAgICAgICAgICB8ICAgICAgICAgIHxGcCAgICAgICB8IA0KICAgICAgICAgfCAgICAg ICAgdiAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICB8IA0KICAgICAg ICAgfCAgICArLS0tLS0tLS0rICAgICB8ICAgICAgICAgICB8ICAgICArLS0tLS0tLS0rICAgICB8 IA0KICAgICAgICAgfCAgICB8ICBGRSAgICB8ICAgICB8ICAgICAgICAgICB8ICAgICB8ICAgRkUg ICB8ICAgICB8IA0KICAgICAgICAgfCAgICArLS0tLS0tLS0rICAgICB8ICAgICAgICAgICB8ICAg ICArLS0tLS0tLS0rICAgICB8IA0KICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICB8ICAgICAg ICAgICB8ICAgICAgICAgIF4gICAgICAgICB8IA0KICAgICAgICAgfCBSb3V0ZXIgfCAgICAgICAg ICB8ICAgICAgICAgICB8IFJvdXRlciAgIHwgICAgICAgICB8IA0KICAgICAgICAgfCBBICAgICAg fCAgICAgICAgICB8ICAgICAgICAgICB8IEIgICAgICAgIHwgICAgICAgICB8IA0KICAgICAgICAg LS0tLS0tLS0tKy0tLS0tLS0tLS0tICAgICAgICAgICAtLS0tLS0tLS0tLSstLS0tLS0tLS0tIA0K ICAgICAgICAgICAgICAgICAgdiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4gDQog ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAg ICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLT4tLS0tLS0tLS0tLS0tLS0gICAgIA0K ICAgICANCiAgICAgICAgRmlndXJlIDExLiBFeGFtcGxlIHRvIHNob3cgZGF0YSBwYWNrZXQgZmxv dyBiZXR3ZWVuIHR3byBORXMuIA0KICAgICANCiAgICBDb250cm9sIHBsYW5lIHByb3RvY29sIHBh Y2tldHMgKHN1Y2ggYXMgUklQLCBPU1BGIG1lc3NhZ2VzKSANCiAgICBhZGRyZXNzZWQgdG8gYW55 IG9mIE5FJ3MgaW50ZXJmYWNlcyBhcmUgdHlwaWNhbGx5IHJlZGlyZWN0ZWQgYnkgdGhlIA0KICAg IHJlY2VpdmluZyBGRSB0byBpdHMgQ0UsIGFuZCBDRSBtYXkgb3JpZ2luYXRlIHBhY2tldHMgYW5k IGhhdmUgaXRzIA0KICAgIEZFIGRlbGl2ZXIgdGhlbSB0byBvdGhlciBORXMuICBUaGVyZWZvcmUs IEZvckNFUyBwcm90b2NvbCBvdmVyIEZwIA0KICAgIG5vdCBvbmx5IHRyYW5zcG9ydHMgdGhlIEZv ckNFUyBwcm90b2NvbCBtZXNzYWdlcyBiZXR3ZWVuIENFcyBhbmQgDQogICAgRkVzLCBidXQgYWxz byBlbmNhcHN1bGF0ZXMgdGhlIGRhdGEgcGFja2V0cyBmcm9tIGNvbnRyb2wgcGxhbmUgDQogICAg cHJvdG9jb2xzLiAgTW9yZW92ZXIsIG9uZSBGRSBtYXkgYmUgY29udHJvbGxlZCBieSBtdWx0aXBs ZSBDRXMgZm9yIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAy MDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDIwXSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAg ICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0K ICANCiAgICBkaXN0cmlidXRlZCBjb250cm9sLiAgSW4gdGhpcyBjb25maWd1cmF0aW9uLCB0aGUg Y29udHJvbCBwcm90b2NvbHMgDQogICAgc3VwcG9ydGVkIGJ5IHRoZSBGT1JDRVMgTkVzIG1heSBz cHJlYWQgYWNyb3NzIG11bHRpcGxlIENFcy4gIEZvciANCiAgICBleGFtcGxlLCBvbmUgQ0UgbWF5 IHN1cHBvcnQgcm91dGluZyBwcm90b2NvbHMgbGlrZSBPU1BGIGFuZCBCR1AsIA0KICAgIHdoaWxl IGEgc2lnbmFsaW5nIGFuZCBhZG1pc3Npb24gY29udHJvbCBwcm90b2NvbCBsaWtlIFJTVlAgaXMg DQogICAgc3VwcG9ydGVkIGluIGFub3RoZXIgQ0UuICBGRXMgYXJlIGNvbmZpZ3VyZWQgdG8gcmVj b2duaXplIGFuZCANCiAgICBmaWx0ZXIgdGhlc2UgcHJvdG9jb2wgcGFja2V0cyBhbmQgZm9yd2Fy ZCB0aGVtIHRvIHRoZSBjb3JyZXNwb25kaW5nIA0KICAgIENFLiAgDQogIA0KICAgIEZpZ3VyZSAx MSBzaG93cyBvbmUgZXhhbXBsZSBvZiBob3cgdGhlIEJHUCBwYWNrZXRzIG9yaWdpbmF0ZWQgYnkg DQogICAgcm91dGVyIEEgYXJlIHBhc3NlZCB0byByb3V0ZXIgQi4gIEluIHRoaXMgZXhhbXBsZSwg dGhlIEZvckNFUyANCiAgICBwcm90b2NvbCBpcyB1c2VkIHRvIHRyYW5zcG9ydCB0aGUgcGFja2V0 cyBmcm9tIHRoZSBDRSB0byB0aGUgRkUgDQogICAgaW5zaWRlIHJvdXRlciBBLCBhbmQgdGhlbiBm cm9tIHRoZSBGRSB0byB0aGUgQ0UgaW5zaWRlIHJvdXRlciBCLiAgDQogICAgSW4gbGlnaHQgb2Yg dGhlIGZhY3QgdGhhdCB0aGUgRm9yQ0VTIHByb3RvY29sIGlzIHJlc3BvbnNpYmxlIGZvciANCiAg ICB0cmFuc3BvcnRpbmcgYm90aCB0aGUgY29udHJvbCBtZXNzYWdlcyBhbmQgdGhlIGRhdGEgcGFj a2V0cyBiZXR3ZWVuIA0KICAgIHRoZSBDRSBhbmQgRkUgb3ZlciBGcCByZWZlcmVuY2UgcG9pbnQs IGl0IGlzIHBvc3NpYmxlIHRvIHVzZSBlaXRoZXIgDQogICAgYSBzaW5nbGUgcHJvdG9jb2wgb3Ig bXVsdGlwbGUgcHJvdG9jb2xzIHRvIGFjaGlldmUgdGhpcy4gDQogICAgIA0KIDQuMi41LiBQcm94 eSBGRSANCiAgICAgDQogICAgSW4gdGhlIGNhc2Ugd2hlcmUgYSBwaHlzaWNhbCBGRSBjYW5ub3Qg aW1wbGVtZW50IChlLmcuLCBkdWUgdG8gdGhlIA0KICAgIGxhY2sgb2YgYSBnZW5lcmFsIHB1cnBv c2UgQ1BVKSB0aGUgRm9yQ0VTIHByb3RvY29sIGRpcmVjdGx5LCBhIA0KICAgIHByb3h5IEZFIGNh biBiZSB1c2VkIGluIHRoZSBtaWRkbGUgb2YgRnAgcmVmZXJlbmNlIHBvaW50LiAgVGhpcyANCiAg ICBhbGxvd3MgdGhlIENFIGNvbW11bmljYXRlIHRvIHRoZSBwaHlzaWNhbCBGRSB2aWEgdGhlIHBy b3h5IGJ5IHVzaW5nIA0KICAgIEZvckNFUywgd2hpbGUgdGhlIHByb3h5IG1hbmlwdWxhdGVzIHRo ZSBwaHlzaWNhbCBGRSB1c2luZyBzb21lIA0KICAgIGludGVybWVkaWFyeSBmb3JtIG9mIGNvbW11 bmljYXRpb24gKGUuZy4sIGEgbm9uLUZvckNFUyBwcm90b2NvbCBvciANCiAgICBETUEpLiAgSW4g c3VjaCBhbiBpbXBsZW1lbnRhdGlvbiwgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBwcm94eSBhbmQg DQogICAgdGhlIHBoeXNpY2FsIEZFIGJlY29tZXMgb25lIGxvZ2ljYWwgRkUgZW50aXR5LiAgDQog ICAgIA0KIDQuMy4gQXNzb2NpYXRpb24gUmUtZXN0YWJsaXNobWVudCANCiAgICAgDQogICAgRkVz IGFuZCBDRXMgbWF5IGpvaW4gYW5kIGxlYXZlIE5FcyBkeW5hbWljYWxseSAoc2VlIFszXSBTZWN0 aW9uIDUsIA0KICAgIHJlcXVpcmVtZW50cyAjMTIpLiAgV2hlbiBhbiBGRSBvciBDRSBsZWF2ZXMg dGhlIE5FLCB0aGUgYXNzb2NpYXRpb24gDQogICAgd2l0aCB0aGUgTkUgaXMgYnJva2VuLiAgSWYg dGhlIGxlYXZpbmcgcGFydHkgcmVqb2lucyBhbiBORSBsYXRlciwgDQogICAgdG8gcmUtZXN0YWJs aXNoIHRoZSBhc3NvY2lhdGlvbiwgaXQgbWF5IG5lZWQgdG8gcmUtZW50ZXIgdGhlIHByZS0NCiAg ICBhc3NvY2lhdGlvbiBwaGFzZS4gIExvc3Mgb2YgYXNzb2NpYXRpb24gY2FuIGFsc28gaGFwcGVu IA0KICAgIHVuZXhwZWN0ZWRseSBkdWUgdG8gbG9zcyBvZiBjb25uZWN0aW9uIGJldHdlZW4gdGhl IENFIGFuZCB0aGUgRkUuICANCiAgICBUaGVyZWZvcmUsIHRoZSBmcmFtZXdvcmsgYWxsb3dzIHRo ZSBiaS1kaXJlY3Rpb25hbCB0cmFuc2l0aW9uIA0KICAgIGJldHdlZW4gdGhlc2UgdHdvIHBoYXNl cywgYnV0IHRoZSBGb3JDRVMgcHJvdG9jb2wgaXMgb25seSANCiAgICBhcHBsaWNhYmxlIGZvciB0 aGUgcG9zdC1hc3NvY2lhdGlvbiBwaGFzZS4gIEhvd2V2ZXIsIHRoZSBwcm90b2NvbCANCiAgICBz aG91bGQgcHJvdmlkZSBtZWNoYW5pc21zIHRvIHN1cHBvcnQgYXNzb2NpYXRpb24gcmUtZXN0YWJs aXNobWVudC4gDQogICAgVGhpcyBpbmNsdWRlcyB0aGUgYWJpbGl0eSBmb3IgQ0VzIGFuZCBGRXMg dG8gZGV0ZXJtaW5lIHdoZW4gdGhlcmUgDQogICAgaXMgYSBsb3NzIG9mIGFzc29jaWF0aW9uIGJl dHdlZW4gdGhlbSwgYWJpbGl0eSB0byByZXN0b3JlIA0KICAgIGFzc29jaWF0aW9uIGFuZCBlZmZp Y2llbnQgc3RhdGUgKHJlKXN5bmNocm9uaXphdGlvbiBtZWNoYW5pc21zIChzZWUgDQogICAgWzNd IFNlY3Rpb24gNSwgcmVxdWlyZW1lbnQgIzcpLiBOb3RlIHRoYXQgc2VjdXJpdHkgYXNzb2NpYXRp b24gYW5kIA0KICAgIHN0YXRlIG11c3QgYmUgYWxzbyByZS1lc3RhYmxpc2hlZCB0byBndWFyYW50 ZWUgdGhlIHNhbWUgbGV2ZWwgb2YgDQogICAgc2VjdXJpdHkgZXhpc3RzIGJlZm9yZSBhbmQgYWZ0 ZXIgdGhlIGFzc29jaWF0aW9uIHJlLWVzdGFibGlzaG1lbnQuIA0KICAgICANCiAgDQogIA0KIFlh bmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgTWFyY2ggICAgMjAwNCAgICAgICAgICAgICAgICAgICBb UGFnZSAyMV0gICANCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGcmFtZXdvcmsgICAg ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDAzIA0KICANCiAgDQogICAgV2hlbiBhbiBGRSBsZWF2 ZXMgb3Igam9pbnMgYW4gZXhpc3RpbmcgTkUgdGhhdCBpcyBhbHJlYWR5IGluIHBvc3QtDQogICAg YXNzb2NpYXRpb24gcGhhc2UsIHRoZSBDRSBuZWVkcyB0byBiZSBhd2FyZSBvZiB0aGUgaW1wYWN0 IG9uIEZFIA0KICAgIHRvcG9sb2d5IGFuZCBkZWFscyB3aXRoIHRoZSBjaGFuZ2UgYWNjb3JkaW5n bHkuIA0KICAgICANCiA0LjMuMS4gQ0UgZ3JhY2VmdWwgcmVzdGFydCANCiAgDQogICAgVGhlIGZh aWx1cmUgYW5kIHJlc3RhcnQgb2YgdGhlIENFIGluIGEgcm91dGVyIGNhbiBwb3RlbnRpYWxseSBj YXVzZSANCiAgICBtdWNoIHN0cmVzcyBhbmQgZGlzcnVwdGlvbiBvbiB0aGUgY29udHJvbCBwbGFu ZSB0aHJvdWdob3V0IGEgDQogICAgbmV0d29yay4gIEJlY2F1c2Ugd2hlbiBhIENFIGhhcyB0byBy ZXN0YXJ0IGZvciBhbnkgcmVhc29uLCB0aGUgDQogICAgcm91dGVyIGxvc2VzIHJvdXRpbmcgYWRq YWNlbmNpZXMgb3Igc2Vzc2lvbnMgd2l0aCBpdHMgcm91dGluZyANCiAgICBuZWlnaGJvcnMuICBO ZWlnaGJvcnMgd2hvIGRldGVjdCB0aGUgbG9zdCBhZGphY2VuY3kgbm9ybWFsbHkgcmUtDQogICAg Y29tcHV0ZSBuZXcgcm91dGVzIGFuZCB0aGVuIHNlbmQgcm91dGluZyB1cGRhdGVzIHRvIHRoZWly IG93biANCiAgICBuZWlnaGJvcnMgdG8gY29tbXVuaWNhdGUgdGhlIGxvc3QgYWRqYWNlbmN5LiAg VGhlaXIgbmVpZ2hib3JzIGRvIA0KICAgIHRoZSBzYW1lIHRoaW5nIHRvIHByb3BhZ2F0ZSB0aHJv dWdob3V0IHRoZSBuZXR3b3JrLiAgSW4gdGhlIA0KICAgIG1lYW50aW1lLCB0aGUgcmVzdGFydGlu ZyByb3V0ZXIgY2Fubm90IHJlY2VpdmUgdHJhZmZpYyBmcm9tIG90aGVyIA0KICAgIHJvdXRlcnMg YmVjYXVzZSB0aGUgbmVpZ2hib3JzIGhhdmUgc3RvcHBlZCB1c2luZyB0aGUgcm91dGVyJ3MgDQog ICAgcHJldmlvdXNseSBhZHZlcnRpc2VkIHJvdXRlcy4gV2hlbiB0aGUgcmVzdGFydGluZyByb3V0 ZXIgcmVzdG9yZXMgDQogICAgYWRqYWNlbmNpZXMsIG5laWdoYm9ycyBtdXN0IG9uY2UgYWdhaW4g cmUtY29tcHV0ZSBuZXcgcm91dGVzIGFuZCANCiAgICBzZW5kIG91dCBhZGRpdGlvbmFsIHJvdXRp bmcgdXBkYXRlcy4gVGhlIHJlc3RhcnRpbmcgcm91dGVyIGlzIA0KICAgIHVuYWJsZSB0byBmb3J3 YXJkIHBhY2tldHMgdW50aWwgaXQgaGFzIHJlLWVzdGFibGlzaGVkIHJvdXRpbmcgDQogICAgYWRq YWNlbmNpZXMgd2l0aCBuZWlnaGJvcnMsIHJlY2VpdmVkIHJvdXRlIHVwZGF0ZXMgdGhyb3VnaCB0 aGVzZSANCiAgICBhZGphY2VuY2llcywgYW5kIGNvbXB1dGVkIG5ldyByb3V0ZXMuICBVbnRpbCBj b252ZXJnZW5jZSB0YWtlcyANCiAgICBwbGFjZSB0aHJvdWdob3V0IHRoZSBuZXR3b3JrLCBwYWNr ZXRzIG1heSBiZSBsb3N0IGluIHRyYW5zaWVudCANCiAgICBibGFjayBob2xlcyBvciBmb3J3YXJk aW5nIGxvb3BzLiAgIA0KICANCiAgICBBIGhpZ2ggYXZhaWxhYmlsaXR5IG1lY2hhbmlzbSBrbm93 biBhcyB0aGUgImdyYWNlZnVsIHJlc3RhcnQiIGhhcyANCiAgICBiZWVuIHVzZWQgYnkgdGhlIElQ IHJvdXRpbmcgcHJvdG9jb2xzIChPU1BGIFsxMF0sIEJHUCBbMTFdLCBCR1AgDQogICAgWzExXSkg YW5kIE1QTFMgbGFiZWwgZGlzdHJpYnV0aW9uIHByb3RvY29sIChMRFAgWzldKSB0byBoZWxwIA0K ICAgIG1pbmltaXplIHRoZSBuZWdhdGl2ZSBlZmZlY3RzIG9uIHJvdXRpbmcgdGhyb3VnaG91dCBh biBlbnRpcmUgDQogICAgbmV0d29yayBjYXVzZWQgYnkgYSByZXN0YXJ0aW5nIHJvdXRlci4gIFJv dXRlIGZsYXAgb24gbmVpZ2hib3JpbmcgDQogICAgcm91dGVycyBpcyBhdm9pZGVkLCBhbmQgYSBy ZXN0YXJ0aW5nIHJvdXRlciBjYW4gY29udGludWUgdG8gZm9yd2FyZCANCiAgICBwYWNrZXRzIHRo YXQgd291bGQgb3RoZXJ3aXNlIGJlIGRyb3BwZWQuICAgDQogICAgIA0KICAgIFdoaWxlIHRoZSBk ZXRhaWxzIGRpZmZlciBmcm9tIHByb3RvY29sIHRvIHByb3RvY29sLCB0aGUgZ2VuZXJhbCANCiAg ICBpZGVhIGJlaGluZCB0aGUgZ3JhY2VmdWwgcmVzdGFydCBtZWNoYW5pc20gcmVtYWlucyB0aGUg c2FtZS4gIFdpdGggDQogICAgdGhlIGdyYWNlZnVsIHJlc3RhcnQsIGEgcmVzdGFydGluZyByb3V0 ZXIgY2FuIGluZm9ybSBpdHMgbmVpZ2hib3JzIA0KICAgIHdoZW4gaXQgcmVzdGFydHMuICBUaGUg bmVpZ2hib3JzIG1heSBkZXRlY3QgdGhlIGxvc3QgYWRqYWNlbmN5IGJ1dCANCiAgICBkbyBub3Qg cmVjb21wdXRlIG5ldyByb3V0ZXMgb3Igc2VuZCByb3V0aW5nIHVwZGF0ZXMgdG8gdGhlaXIgDQog ICAgbmVpZ2hib3JzLiAgVGhlIG5laWdoYm9ycyBhbHNvIGhvbGQgb24gdG8gdGhlIHJvdXRlcyBy ZWNlaXZlZCBmcm9tIA0KICAgIHRoZSByZXN0YXJ0aW5nIHJvdXRlciBiZWZvcmUgcmVzdGFydCBh bmQgYXNzdW1lIHRoZXkgYXJlIHN0aWxsIA0KICAgIHZhbGlkIGZvciBhIGxpbWl0ZWQgdGltZS4g IEJ5IGRvaW5nIHNvLCB0aGUgcmVzdGFydGluZyByb3V0ZXIncyBGRXMgDQogICAgY2FuIGFsc28g Y29udGludWUgdG8gcmVjZWl2ZSBhbmQgZm9yd2FyZCB0cmFmZmljIGZyb20gb3RoZXIgDQogICAg bmVpZ2hib3JzIGZvciBhIGxpbWl0ZWQgdGltZSBieSB1c2luZyB0aGUgcm91dGVzIHRoZXkgYWxy ZWFkeSBoYXZlLiANCiAgICBUaGUgcmVzdGFydGluZyByb3V0ZXIgdGhlbiByZS1lc3RhYmxpc2hl cyByb3V0aW5nIGFkamFjZW5jaWVzLCANCiAgICBkb3dubG9hZHMgdXBkYXRlZCByb3V0ZXMgZnJv bSBhbGwgaXRzIG5laWdoYm9ycywgcmVjb21wdXRlcyBuZXcgDQogICAgcm91dGVzIGFuZCB1c2Vz IHRoZW0gdG8gcmVwbGFjZSB0aGUgb2xkZXIgcm91dGVzIGl0IHdhcyB1c2luZy4gSXQgDQogIA0K ICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIE1hcmNoICAgIDIwMDQgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMjJdICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3 b3JrICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0KICAgIHRoZW4gc2Vu ZHMgdGhlc2UgdXBkYXRlZCByb3V0ZXMgdG8gaXRzIG5laWdoYm9ycyBhbmQgc2lnbmFscyB0aGUg DQogICAgY29tcGxldGlvbiBvZiB0aGUgZ3JhY2VmdWwgcmVzdGFydCBwcm9jZXNzLiANCiAgICAg DQogICAgTm9uLXN0b3AgZm9yd2FyZGluZyBpcyBhIHJlcXVpcmVtZW50IGZvciBncmFjZWZ1bCBy ZXN0YXJ0LiAgSXQgaXMgDQogICAgbmVjZXNzYXJ5IHNvIGEgcm91dGVyIGNhbiBjb250aW51ZSB0 byBmb3J3YXJkIHBhY2tldHMgd2hpbGUgaXQgaXMgDQogICAgZG93bmxvYWRpbmcgcm91dGluZyBp bmZvcm1hdGlvbiBhbmQgcmVjb21wdXRpbmcgbmV3IHJvdXRlcy4gIFRoaXMgDQogICAgZW5zdXJl cyB0aGF0IHBhY2tldHMgd2lsbCBub3QgYmUgZHJvcHBlZC4gIEFzIG9uZSBjYW4gc2VlLCBvbmUg b2YgDQogICAgdGhlIGJlbmVmaXRzIGFmZm9yZGVkIGJ5IHRoZSBzZXBhcmF0aW9uIG9mIENFIGFu ZCBGRSBpcyBleGFjdGx5IHRoZSANCiAgICBhYmlsaXR5IG9mIG5vbi1zdG9wIGZvcndhcmRpbmcg aW4gdGhlIGZhY2Ugb2YgdGhlIENFIGZhaWx1cmUgYW5kIA0KICAgIHJlc3RhcnQuICBUaGUgc3Vw cG9ydCBvZiBkeW5hbWljIGNoYW5nZXMgdG8gQ0UvRkUgYXNzb2NpYXRpb24gaW4gDQogICAgRm9y Q0VTIGFsc28gbWFrZXMgaXQgY29tcGF0aWJsZSB3aXRoIGhpZ2ggYXZhaWxhYmlsaXR5IG1lY2hh bmlzbXMgDQogICAgc3VjaCBhcyBncmFjZWZ1bCByZXN0YXJ0LiANCiAgICAgDQogICAgRm9yQ0VT IHNob3VsZCBiZSBhYmxlIHRvIHN1cHBvcnQgQ0UgZ3JhY2VmdWwgcmVzdGFydCBlYXNpbHkuICBX aGVuIA0KICAgIHRoZSBhc3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hlZCB0aGUgZmlyc3QgdGltZSwg dGhlIENFIG11c3QgaW5mb3JtIA0KICAgIHRoZSBGRXMgd2hhdCB0byBkbyBpbiB0aGUgY2FzZSBv ZiBDRSBmYWlsdXJlLiAgSWYgZ3JhY2VmdWwgcmVzdGFydCANCiAgICBpcyBub3Qgc3VwcG9ydGVk LCB0aGUgRkVzIG1heSBiZSB0b2xkIHRvIHN0b3AgcGFja2V0IHByb2Nlc3NpbmcgYWxsIA0KICAg IHRvZ2V0aGVyIGlmIGl0cyBDRSBmYWlscy4gIElmIGdyYWNlZnVsIHJlc3RhcnQgaXMgc3VwcG9y dGVkLCB0aGUgDQogICAgRkVzIHNob3VsZCBiZSB0b2xkIHRvIGNhY2hlIGFuZCBob2xkIG9uIHRv IGl0cyBGRSBzdGF0ZSBpbmNsdWRpbmcgDQogICAgdGhlIGZvcndhcmRpbmcgdGFibGVzIGFjcm9z cyB0aGUgcmVzdGFydHMuICBBIHRpbWVyIG11c3QgYmUgDQogICAgaW5jbHVkZWQgc28gdGhhdCB0 aGUgdGltZW91dCBjYXVzZXMgc3VjaCBjYWNoZWQgc3RhdGUgdG8gZXhwaXJlIA0KICAgIGV2ZW50 dWFsbHkuICBUaG9zZSB0aW1lcnMgc2hvdWxkIGJlIHNldHRhYmxlIGJ5IHRoZSBDRS4gIA0KICAN CiA0LjMuMi4gRkUgcmVzdGFydCANCiAgDQogICAgSW4gdGhlIHNhbWUgZXhhbXBsZSBpbiBGaWd1 cmUgNSwgYXNzdW1pbmcgQ0UxIGlzIHRoZSB3b3JraW5nIENFIGZvciANCiAgICB0aGUgbW9tZW50 LCB3aGF0IHdvdWxkIGhhcHBlbiBpZiBvbmUgb2YgdGhlIEZFcywgc2F5IEZFMSwgbGVhdmVzIA0K ICAgIHRoZSBORSB0ZW1wb3JhcmlseT8gIEZFMSBtYXkgdm9sdW50YXJpbHkgZGVjaWRlIHRvIGxl YXZlIHRoZSANCiAgICBhc3NvY2lhdGlvbi4gIEFsdGVybmF0aXZlbHksIEZFMSBtYXkgc3RvcCBm dW5jdGlvbmluZyBzaW1wbHkgZHVlIHRvIA0KICAgIHVuZXhwZWN0ZWQgZmFpbHVyZS4gIEluIGZv cm1lciBjYXNlLCBDRTEgcmVjZWl2ZXMgYSAibGVhdmUtDQogICAgYXNzb2NpYXRpb24gcmVxdWVz dCIgZnJvbSBGRTEuICBJbiB0aGUgbGF0dGVyLCBDRTEgZGV0ZWN0cyB0aGUgDQogICAgZmFpbHVy ZSBvZiBGRTEgYnkgc29tZSBvdGhlciBtZWFucy4gIEluIGJvdGggY2FzZXMsIENFMSBtdXN0IGlu Zm9ybSANCiAgICB0aGUgcm91dGluZyBwcm90b2NvbHMgb2Ygc3VjaCBhbiBldmVudCwgbW9zdCBs aWtlbHkgcHJvbXB0aW5nIGEgDQogICAgcmVhY2hhYmlsaXR5IGFuZCBTUEYgKFNob3J0ZXN0IFBh dGggRmlyc3QpIHJlY2FsY3VsYXRpb24gYW5kIA0KICAgIGFzc29jaWF0ZWQgZG93bmxvYWRpbmcg b2YgbmV3IEZJQnMgZnJvbSBDRTEgdG8gdGhlIG90aGVyIHJlbWFpbmluZyANCiAgICBGRXMgKG9u bHkgRkUyIGluIHRoaXMgZXhhbXBsZSkuICBTdWNoIHJlY2FsY3VsYXRpb24gYW5kIEZJQiB1cGRh dGUgDQogICAgd2lsbCBhbHNvIGJlIHByb3BhZ2F0ZWQgZnJvbSB0aGUgQ0UxIHRvIGl0cyBuZWln aGJvcnMgdGhhdCBhcmUgDQogICAgYWZmZWN0ZWQgYnkgdGhlIGNvbm5lY3Rpdml0eSBvZiBGRTEu ICAgDQogICAgIA0KICAgIFdoZW4gRkUxIGRlY2lkZXMgdG8gcmVqb2luIGFnYWluLCBvciB3aGVu IGl0IHJlc3RhcnRzIGFnYWluIGZyb20gDQogICAgdGhlIGZhaWx1cmUsIEZFMSBuZWVkcyB0byBy ZS1kaXNjb3ZlciBpdHMgbWFzdGVyIChDRSkuICBUaGlzIGNhbiBiZSANCiAgICBhY2hpZXZlZCBi eSBzZXZlcmFsIG1lYW5zLiAgSXQgbWF5IHJlLWVudGVyIHRoZSBwcmUtYXNzb2NpYXRpb24gDQog ICAgcGhhc2UgYW5kIGdldCB0aGF0IGluZm9ybWF0aW9uIGZyb20gaXRzIEZFIG1hbmFnZXIuICBJ dCBtYXkgDQogICAgcmV0cmlldmUgdGhlIHByZXZpb3VzIENFIGluZm9ybWF0aW9uIGZyb20gaXRz IGNhY2hlLCBpZiBpdCBjYW4gDQogICAgdmFsaWRhdGUgdGhlIGluZm9ybWF0aW9uIGZyZXNobmVz cy4gIE9uY2UgaXQgZGlzY292ZXJzIGl0cyBDRSwgaXQgDQogICAgc3RhcnRzIG1lc3NhZ2UgZXhj aGFuZ2Ugd2l0aCBDRSB0byByZS1lc3RhYmxpc2ggdGhlIGFzc29jaWF0aW9uIA0KICAgIGp1c3Qg YXMgb3V0bGluZWQgaW4gRmlndXJlIDksIHdpdGggdGhlIHBvc3NpYmxlIGV4Y2VwdGlvbiB0aGF0 IGl0IA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAg ICAgICAgICAgICAgICAgIFtQYWdlIDIzXSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9y Q0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAg ICBtaWdodCBiZSBhYmxlIHRvIGJ5cGFzcyB0aGUgdHJhbnNwb3J0IG9mIHRoZSBjb21wbGV0ZSBp bml0aWFsIA0KICAgIGNvbmZpZ3VyYXRpb24uICBTdXBwb3NlIHRoYXQgRkUxIHN0aWxsIGhhcyBp dHMgcm91dGluZyB0YWJsZSBhbmQgDQogICAgb3RoZXIgc3RhdGUgaW5mb3JtYXRpb24gZnJvbSB0 aGUgbGFzdCBhc3NvY2lhdGlvbiwgaW5zdGVhZCBvZiANCiAgICBzZW5kaW5nIGFsbCB0aGUgaW5m b3JtYXRpb24gYWdhaW4gZnJvbSBzY3JhdGNoLCBpdCBtYXkgYmUgYWJsZSB0byANCiAgICB1c2Ug bW9yZSBlZmZpY2llbnQgbWVjaGFuaXNtIHRvIHJlLXN5bmMgdXAgdGhlIHN0YXRlIHdpdGggaXRz IENFIGlmIA0KICAgIHN1Y2ggbWVjaGFuaXNtIGlzIHN1cHBvcnRlZCBieSB0aGUgRm9yQ0VTIHBy b3RvY29sLiAgRm9yIGV4YW1wbGUsIA0KICAgIENSQy0zMiBvZiB0aGUgc3RhdGUgbWlnaHQgZ2l2 ZSBhIHF1aWNrIGluZGljYXRpb24gb2Ygd2hldGhlciBvciBub3QgDQogICAgdGhlIHN0YXRlIGlz IGluLXN5bmMgd2l0aCBpdHMgQ0UuICBCeSBjb21wYXJpbmcgaXRzIHN0YXRlIHdpdGggQ0UgDQog ICAgZmlyc3QsIGl0IHNlbmRzIGluZm9ybWF0aW9uIHVwZGF0ZSBvbmx5IGlmIGl0IGlzIG5lZWRl ZC4gIEZvckNFUyANCiAgICBwcm90b2NvbCBtYXkgY2hvb3NlIHRvIGltcGxlbWVudCBzaW1pbGFy IG9wdGltaXphdGlvbiBtZWNoYW5pc21zLCANCiAgICBidXQgaXQgbWF5IGFsc28gY2hvb3NlIG5v dCB0bywgYXMgdGhpcyBpcyBub3QgYSByZXF1aXJlbWVudC4gDQogICAgIA0KICAgICANCiA1LiBB cHBsaWNhYmlsaXR5IHRvIFJGQzE4MTIgIA0KICANCiAgICBbM10gU2VjdGlvbiA1LCByZXF1aXJl bWVudCAjOSBkaWN0YXRlcyAiQW55IHByb3Bvc2VkIEZvckNFUyANCiAgICBhcmNoaXRlY3R1cmUg bXVzdCBleHBsYWluIGhvdyB0aGF0IGFyY2hpdGVjdHVyZSBzdXBwb3J0cyBhbGwgb2YgdGhlIA0K ICAgIHJvdXRlciBmdW5jdGlvbnMgYXMgZGVmaW5lZCBpbiBSRkMxODEyLiIgIFJGQzE4MTIgZGlz Y3Vzc2VzIG1hbnkgDQogICAgaW1wb3J0YW50IHJlcXVpcmVtZW50cyBmb3IgSVB2NCByb3V0ZXJz IGZyb20gdGhlIGxpbmsgbGF5ZXIgdG8gdGhlIA0KICAgIGFwcGxpY2F0aW9uIGxheWVyLiAgVGhp cyBzZWN0aW9uIGFkZHJlc3NlcyB0aGUgcmVsZXZhbnQgDQogICAgcmVxdWlyZW1lbnRzIGluIFJG QzE4MTIgZm9yIGltcGxlbWVudGluZyBJUHY0IHJvdXRlcnMgYmFzZWQgb24gDQogICAgRm9yQ0VT IGFyY2hpdGVjdHVyZSBhbmQgZXhwbGFpbnMgaG93IEZvckNFUyBzYXRpc2ZpZXMgdGhlc2UgDQog ICAgcmVxdWlyZW1lbnRzIGJ5IHByb3ZpZGluZyBndWlkZWxpbmVzIG9uIGhvdyB0byBzZXBhcmF0 ZSB0aGUgDQogICAgZnVuY3Rpb25hbGl0aWVzIHJlcXVpcmVkIGludG8gZm9yd2FyZGluZyBwbGFu ZSBhbmQgY29udHJvbCBwbGFuZS4gICANCiAgICAgDQogICAgSW4gZ2VuZXJhbCwgdGhlIGZvcndh cmRpbmcgcGxhbmUgY2FycmllcyBvdXQgdGhlIGJ1bGsgb2YgdGhlIHBlci0NCiAgICBwYWNrZXQg cHJvY2Vzc2luZyB0aGF0IGlzIHJlcXVpcmVkIGF0IGxpbmUgc3BlZWQsIHdoaWxlIHRoZSBjb250 cm9sIA0KICAgIHBsYW5lIGNhcnJpZXMgbW9zdCBvZiB0aGUgY29tcHV0YXRpb25hbGx5IGNvbXBs ZXggb3BlcmF0aW9ucyB0aGF0IA0KICAgIGFyZSB0eXBpY2FsIG9mIHRoZSBjb250cm9sIGFuZCBz aWduYWxpbmcgcHJvdG9jb2xzLiAgSG93ZXZlciwgaXQgaXMgDQogICAgaW1wb3NzaWJsZSB0byBk cmF3IGEgcmlnaWQgbGluZSB0byBkaXZpZGUgdGhlIHByb2Nlc3NpbmcgaW50byBDRXMgDQogICAg YW5kIEZFcyBjbGVhbmx5LiAgTm9yIHNob3VsZCB0aGUgRm9yQ0VTIGFyY2hpdGVjdHVyZSBsaW1p dCB0aGUgDQogICAgaW5ub3ZhdGl2ZSBhcHByb2FjaGVzIGluIGNvbnRyb2wgYW5kIGZvcndhcmRp bmcgcGxhbmUgc2VwYXJhdGlvbi4gIA0KICAgIEFzIG1vcmUgYW5kIG1vcmUgcHJvY2Vzc2luZyBw b3dlciBpcyBhdmFpbGFibGUgaW4gdGhlIEZFcywgc29tZSBvZiANCiAgICB0aGUgY29udHJvbCBm dW5jdGlvbnMgdGhhdCB0cmFkaXRpb25hbGx5IGFyZSBwZXJmb3JtZWQgYnkgQ0VzIG1heSANCiAg ICBub3cgYmUgbW92ZWQgdG8gRkVzIGZvciBiZXR0ZXIgcGVyZm9ybWFuY2UgYW5kIHNjYWxhYmls aXR5LiAgU3VjaCANCiAgICBvZmZsb2FkZWQgZnVuY3Rpb25zIG1heSBpbmNsdWRlIHBhcnQgb2Yg SUNNUCBvciBUQ1AgcHJvY2Vzc2luZywgb3IgDQogICAgcGFydCBvZiByb3V0aW5nIHByb3RvY29s cy4gIE9uY2Ugb2ZmLWxvYWRlZCBvbnRvIHRoZSBmb3J3YXJkaW5nIA0KICAgIHBsYW5lLCBzdWNo IENFIGZ1bmN0aW9ucywgZXZlbiB0aG91Z2ggbG9naWNhbGx5IGJlbG9uZ2luZyB0byB0aGUgDQog ICAgY29udHJvbCBwbGFuZSwgbm93IGJlY29tZSBwYXJ0IG9mIHRoZSBGRSBmdW5jdGlvbnMuICBK dXN0IGxpa2UgdGhlIA0KICAgIG90aGVyIGxvZ2ljYWwgZnVuY3Rpb25zIHBlcmZvcm1lZCBieSBG RXMsIHN1Y2ggb2ZmLWxvYWRlZCBmdW5jdGlvbnMgDQogICAgbXVzdCBiZSBleHByZXNzZWQgYXMg cGFydCBvZiB0aGUgRkUgbW9kZWwgc28gdGhhdCB0aGUgQ0VzIGNhbiANCiAgICBkZWNpZGUgaG93 IHRvIGJlc3QgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlc2Ugb2ZmLWxvYWRlZCBmdW5jdGlvbnMgDQog ICAgd2hlbiBwcmVzZW50IG9uIHRoZSBGRXMuIA0KICAgICANCiA1LjEuIEdlbmVyYWwgUm91dGVy IFJlcXVpcmVtZW50cyANCiAgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIE1h cmNoICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjRdICAgDQogSW50ZXJuZXQgRHJh ZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAw MyANCiAgDQogIA0KICAgIFJvdXRlcnMgaGF2ZSBhdCBsZWFzdCB0d28gb3IgbW9yZSBsb2dpY2Fs IGludGVyZmFjZXMuICBXaGVuIENFcyBhbmQgDQogICAgRkVzIGFyZSBzZXBhcmF0ZWQgYnkgRm9y Q0VTIHdpdGhpbiBhIHNpbmdsZSBORSwgc29tZSBhZGRpdGlvbmFsIA0KICAgIGludGVyZmFjZXMg YXJlIG5lZWRlZCBmb3IgaW50cmEtTkUgY29tbXVuaWNhdGlvbnMuICBGaWd1cmUgMTIgc2hvd3Mg DQogICAgYW4gZXhhbXBsZSB0byBpbGx1c3RyYXRlIHRoYXQuICBUaGlzIE5FIGNvbnRhaW5zIG9u ZSBDRSBhbmQgdHdvIA0KICAgIEZFcy4gIEVhY2ggRkUgaGFzIGZvdXIgaW50ZXJmYWNlczsgdHdv IG9mIHRoZW0gYXJlIHVzZWQgZm9yIA0KICAgIHJlY2VpdmluZyBhbmQgdHJhbnNtaXR0aW5nIHBh Y2tldHMgdG8gdGhlIGV4dGVybmFsIHdvcmxkLCB3aGlsZSB0aGUgDQogICAgb3RoZXIgdHdvIGFy ZSBmb3IgaW50cmEtTkUgY29ubmVjdGlvbnMuICBDRSBoYXMgdHdvIGxvZ2ljYWwgDQogICAgaW50 ZXJmYWNlcyAjOSBhbmQgIzEwLCBjb25uZWN0ZWQgdG8gaW50ZXJmYWNlcyAjMyBhbmQgIzYgZnJv bSBGRTEgDQogICAgYW5kIEZFMiwgcmVzcGVjdGl2ZWx5LiAgSW50ZXJmYWNlICM0IGFuZCAjNSBh cmUgY29ubmVjdGVkIGZvciBGRTEtDQogICAgRkUyIGNvbW11bmljYXRpb24uICBUaGVyZWZvcmUs IHRoaXMgcm91dGVyIE5FIHByb3ZpZGVzIGZvdXIgDQogICAgZXh0ZXJuYWwgaW50ZXJmYWNlcyAo IzEsIDIsIDcgYW5kIDgpLiAgDQogIA0KICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0gDQogICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICByb3V0 ZXIgTkUgICAgICAgfCANCiAgICAgICAgICAgICAgICAgfCAgIC0tLS0tLS0tLS0tICAgLS0tLS0t LS0tLS0gICB8IA0KICAgICAgICAgICAgICAgICB8ICAgfCAgIEZFMSAgIHwgICB8ICAgRkUyICAg fCAgIHwgDQogICAgICAgICAgICAgICAgIHwgICAtLS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0tICAg fCANCiAgICAgICAgICAgICAgICAgfCAgIDF8IDJ8IDN8IDR8ICAgNXwgNnwgN3wgOHwgICB8IA0K ICAgICAgICAgICAgICAgICB8ICAgIHwgIHwgIHwgIHwgICAgfCAgfCAgfCAgfCAgIHwgDQogICAg ICAgICAgICAgICAgIHwgICAgfCAgfCAgfCAgKy0tLS0rICB8ICB8ICB8ICAgfCANCiAgICAgICAg ICAgICAgICAgfCAgICB8ICB8ICB8ICAgICAgICAgIHwgIHwgIHwgICB8IA0KICAgICAgICAgICAg ICAgICB8ICAgIHwgIHwgOXwgICAgICAgIDEwfCAgfCAgfCAgIHwgDQogICAgICAgICAgICAgICAg IHwgICAgfCAgfCAtLS0tLS0tLS0tLS0tLSB8ICB8ICAgfCANCiAgICAgICAgICAgICAgICAgfCAg ICB8ICB8IHwgICAgQ0UgICAgICB8IHwgIHwgICB8IA0KICAgICAgICAgICAgICAgICB8ICAgIHwg IHwgLS0tLS0tLS0tLS0tLS0gfCAgfCAgIHwgDQogICAgICAgICAgICAgICAgIHwgICAgfCAgfCAg ICAgICAgICAgICAgICB8ICB8ICAgfCANCiAgICAgICAgICAgICAgICAgLS0tLS0rLS0rLS0tLS0t LS0tLS0tLS0tLSstLSstLS0tIA0KICAgICAgICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICAg ICAgICAgfCAgfCAgDQogICAgICAgICAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgICAgICB8 ICB8ICANCiAgICAgDQogICAgICAgICAgICAgICAgIEZpZ3VyZSAxMi4gQSByb3V0ZXIgTkUgZXhh bXBsZSB3aXRoIGZvdXIgaW50ZXJmYWNlcy4gDQogIA0KICAgIElQdjQgcm91dGVycyBtdXN0IGlt cGxlbWVudCBJUCB0byBzdXBwb3J0IGl0cyBwYWNrZXQgZm9yd2FyZGluZyANCiAgICBmdW5jdGlv biwgd2hpY2ggaXMgZHJpdmVuIGJ5IGl0cyBGSUIgKEZvcndhcmRpbmcgSW5mb3JtYXRpb24gQmFz ZSkuIA0KICAgIFRoaXMgSW50ZXJuZXQgbGF5ZXIgZm9yd2FyZGluZyAoc2VlIFJGQzE4MTIgWzFd IFNlY3Rpb24gNSkgDQogICAgZnVuY3Rpb25hbGl0eSBuYXR1cmFsbHkgYmVsb25ncyB0byBGRXMg aW4gdGhlIEZvckNFUyBhcmNoaXRlY3R1cmUuICANCiAgICAgDQogICAgQSByb3V0ZXIgbWF5IGlt cGxlbWVudCB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2xzIChsaWtlIFRDUCBhbmQgVURQKSANCiAg ICB0aGF0IGFyZSByZXF1aXJlZCB0byBzdXBwb3J0IGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29s cyAoc2VlIA0KICAgIFJGQzE4MTIgWzFdIFNlY3Rpb24gNikuICBPbmUgaW1wb3J0YW50IGNsYXNz IG9mIGFwcGxpY2F0aW9uIA0KICAgIHByb3RvY29scyBpcyByb3V0aW5nIHByb3RvY29scyAoc2Vl IFJGQzE4MTIgWzFdIFNlY3Rpb24gNykuICBJbiANCiAgICBGb3JDRVMgYXJjaGl0ZWN0dXJlLCBy b3V0aW5nIHByb3RvY29scyBhcmUgbmF0dXJhbGx5IGltcGxlbWVudGVkIGJ5IA0KICAgIENFcy4g IFJvdXRpbmcgcHJvdG9jb2xzIHJlcXVpcmUgcm91dGVycyBjb21tdW5pY2F0ZSB3aXRoIGVhY2gg DQogICAgb3RoZXIuICBUaGlzIGNvbW11bmljYXRpb24gYmV0d2VlbiBDRXMgaW4gZGlmZmVyZW50 IHJvdXRlcnMgaXMgDQogICAgc3VwcG9ydGVkIGluIEZvckNFUyBieSBGRXMnIGFiaWxpdHkgdG8g cmVkaXJlY3QgZGF0YSBwYWNrZXRzIA0KICAgIGFkZHJlc3NlZCB0byByb3V0ZXJzIChpLmUuLCBO RXMpIGFuZCBDRXMnIGFiaWxpdHkgdG8gb3JpZ2luYXRlIA0KICAgIHBhY2tldHMgYW5kIGhhdmUg dGhlbSBkZWxpdmVyZWQgYnkgdGhlaXIgRkVzLiAgVGhpcyBjb21tdW5pY2F0aW9uIA0KICANCiAg DQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAgICAgICAgICAgICAg ICAgIFtQYWdlIDI1XSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29y ayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAgICBvY2N1cnMgYWNy b3NzIEZwIHJlZmVyZW5jZSBwb2ludCBpbnNpZGUgZWFjaCByb3V0ZXIgYW5kIGJldHdlZW4gDQog ICAgbmVpZ2hib3Jpbmcgcm91dGVycycgZXh0ZXJuYWwgaW50ZXJmYWNlcywgYXMgaWxsdXN0cmF0 ZWQgaW4gRmlndXJlIA0KICAgIDExLiAgDQogICAgIA0KIDUuMi5MaW5rIExheWVyIA0KICAgICAN CiAgICBTaW5jZSBGRXMgb3duIGFsbCB0aGUgZXh0ZXJuYWwgaW50ZXJmYWNlcyBmb3IgdGhlIHJv dXRlciwgRkVzIG5lZWQgDQogICAgdG8gY29uZm9ybSB0byB0aGUgbGluayBsYXllciByZXF1aXJl bWVudHMgaW4gUkZDMTgxMi4gIEFyZ3VhYmx5LCANCiAgICBBUlAgc3VwcG9ydCBtYXkgYmUgaW1w bGVtZW50ZWQgaW4gZWl0aGVyIENFcyBvciBGRXMuICBBcyB3ZSB3aWxsIA0KICAgIHNlZSBsYXRl ciwgYSBudW1iZXIgb2YgYmVoYXZpb3JzIHRoYXQgUkZDMTgxMiBtYW5kYXRlcyBmYWxsIGludG8g DQogICAgdGhpcyBjYXRlZ29yeSAtLSB0aGV5IG1heSBiZSBwZXJmb3JtZWQgYnkgdGhlIEZFIGFu ZCBtYXkgYmUgDQogICAgcGVyZm9ybWVkIGJ5IHRoZSBDRS4gIEEgZ2VuZXJhbCBndWlkZWxpbmUg aXMgbmVlZGVkIHRvIGVuc3VyZSANCiAgICBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gc2VwYXJh dGVkIGNvbnRyb2wgYW5kIGZvcndhcmRpbmcgcGxhbmVzLiAgDQogICAgVGhlIGd1aWRlbGluZSB3 ZSBvZmZlciBoZXJlIGlzIHRoYXQgQ0VzIE1VU1QgYmUgY2FwYWJsZSBvZiB0aGVzZSANCiAgICBr aW5kIG9mIG9wZXJhdGlvbnMgd2hpbGUgRkVzIE1BWSBjaG9vc2UgdG8gaW1wbGVtZW50IHRoZW0u ICBGRSANCiAgICBtb2RlbCBzaG91bGQgaW5kaWNhdGUgaXRzIGNhcGFiaWxpdGllcyBpbiB0aGlz IHJlZ2FyZCBzbyB0aGF0IENFcyANCiAgICBjYW4gZGVjaWRlIHdoZXJlIHRoZXNlIGZ1bmN0aW9u cyBhcmUgaW1wbGVtZW50ZWQuIA0KICAgICANCiAgICBJbnRlcmZhY2UgcGFyYW1ldGVycywgaW5j bHVkaW5nIE1UVSwgSVAgYWRkcmVzcywgZXRjLiwgbXVzdCBiZSANCiAgICBjb25maWd1cmFibGUg YnkgQ0VzIHZpYSBGb3JDRVMuICBDRXMgbXVzdCBiZSBhYmxlIHRvIGRldGVybWluZSANCiAgICB3 aGV0aGVyIGEgcGh5c2ljYWwgaW50ZXJmYWNlIGluIGFuIEZFIGlzIGF2YWlsYWJsZSB0byBzZW5k IHBhY2tldHMgDQogICAgb3Igbm90LiAgRkVzIG11c3QgYWxzbyBpbmZvcm0gQ0VzIHRoZSBzdGF0 dXMgY2hhbmdlIG9mIHRoZSANCiAgICBpbnRlcmZhY2VzIChsaWtlIGxpbmsgdXAvZG93bikgdmlh IEZvckNFUy4gDQogICAgIA0KIDUuMy5JbnRlcm5ldCBMYXllciBQcm90b2NvbHMgDQogICAgIA0K ICAgIEJvdGggRkVzIGFuZCBDRXMgbXVzdCBpbXBsZW1lbnQgSVAgcHJvdG9jb2wgYW5kIGFsbCBt YW5kYXRvcnkgDQogICAgZXh0ZW5zaW9ucyBhcyBSRkMxODEyIHNwZWNpZmllZC4gIENFcyBzaG91 bGQgaW1wbGVtZW50IElQIG9wdGlvbnMgDQogICAgbGlrZSBzb3VyY2Ugcm91dGUgYW5kIHJlY29y ZCByb3V0ZSB3aGlsZSBGRXMgbWF5IGNob29zZSB0byANCiAgICBpbXBsZW1lbnQgdGhvc2UgYXMg d2VsbC4gIFRoZSB0aW1lc3RhbXAgb3B0aW9uIHNob3VsZCBiZSANCiAgICBpbXBsZW1lbnRlZCBi eSBGRXMgdG8gaW5zZXJ0IHRoZSB0aW1lc3RhbXAgbW9zdCBhY2N1cmF0ZWx5LiAgVGhlIEZFIA0K ICAgIG11c3QgaW50ZXJwcmV0IHRoZSBJUCBvcHRpb25zIHRoYXQgaXQgdW5kZXJzdGFuZHMgYW5k IHByZXNlcnZlIHRoZSANCiAgICByZXN0IHVuY2hhbmdlZCBmb3IgdXNlIGJ5IENFcy4gIEJvdGgg RkVzIGFuZCBDRXMgbWlnaHQgY2hvb3NlIHRvIA0KICAgIHNpbGVudGx5IGRpc2NhcmQgcGFja2V0 cyB3aXRob3V0IHNlbmRpbmcgSUNNUCBlcnJvcnMsIGJ1dCBzdWNoIA0KICAgIGV2ZW50cyBzaG91 bGQgYmUgbG9nZ2VkIGFuZCBjb3VudGVkLiAgRkVzIG1heSByZXBvcnQgc3RhdGlzdGljcyBmb3Ig DQogICAgc3VjaCBldmVudHMgdG8gQ0VzIHZpYSBGb3JDRVMuICANCiAgDQogICAgV2hlbiBtdWx0 aXBsZSBGRXMgYXJlIGludm9sdmVkIHRvIHByb2Nlc3MgcGFja2V0cywgdGhlIGFwcGVhcmFuY2Ug DQogICAgb2Ygc2luZ2xlIE5FIG11c3QgYmUgc3RyaWN0bHkgbWFpbnRhaW5lZC4gIEZvciBleGFt cGxlLCBUaW1lLVRvLQ0KICAgIExpdmUgKFRUTCkgbXVzdCBiZSBkZWNyZW1lbnRlZCBvbmx5IG9u Y2Ugd2l0aGluIGEgc2luZ2xlIE5FLiAgRm9yIA0KICAgIGV4YW1wbGUsIGl0IGNhbiBiZSBhbHdh eXMgZGVjcmVtZW50ZWQgYnkgdGhlIGxhc3QgRkUgd2l0aCBlZ3Jlc3MgDQogICAgZnVuY3Rpb24u ICANCiAgICAgDQogICAgRkVzIG11c3QgcmVjZWl2ZSBhbmQgcHJvY2VzcyBub3JtYWxseSBhbnkg cGFja2V0cyB3aXRoIGEgYnJvYWRjYXN0IA0KICAgIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3IgYSBt dWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyB0aGF0IHRoZSANCiAgICByb3V0ZXIgaGFzIGFz a2VkIHRvIHJlY2VpdmUuICBXaGVuIElQIG11bHRpY2FzdCBpcyBzdXBwb3J0ZWQgaW4gDQogICAg cm91dGVycywgSUdNUCBpcyBpbXBsZW1lbnRlZCBpbiBDRXMuICBDRXMgYXJlIGFsc28gcmVxdWly ZWQgb2YgSUNNUCANCiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgTWFyY2ggICAg MjAwNCAgICAgICAgICAgICAgICAgICBbUGFnZSAyNl0gICANCiBJbnRlcm5ldCBEcmFmdCAgICAg ICAgIEZvckNFUyBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAyMDAzIA0KICAN CiAgDQogICAgc3VwcG9ydCwgd2hpbGUgaXQgaXMgb3B0aW9uYWwgZm9yIEZFcyB0byBzdXBwb3J0 IElDTVAuICBTdWNoIGFuIA0KICAgIG9wdGlvbiBjYW4gYmUgY29tbXVuaWNhdGVkIHRvIENFcyBh cyBwYXJ0IG9mIHRoZSBGRSBtb2RlbC4gIA0KICAgIFRoZXJlZm9yZSwgRkVzIGNhbiBhbHdheXMg cmVseSB1cG9uIENFcyB0byBzZW5kIG91dCBJQ01QIGVycm9yIA0KICAgIG1lc3NhZ2VzLCBidXQg RkVzIGFsc28gaGF2ZSB0aGUgb3B0aW9uIHRvIGdlbmVyYXRlIElDTVAgZXJyb3IgDQogICAgbWVz c2FnZXMgdGhlbXNlbHZlcy4gIA0KICAgICANCiA1LjQuSW50ZXJuZXQgTGF5ZXIgRm9yd2FyZGlu ZyANCiAgICAgDQogICAgSVAgZm9yd2FyZGluZyBpcyBpbXBsZW1lbnRlZCBieSBGRXMuICBXaGVu IHRoZSByb3V0aW5nIHRhYmxlIGlzIA0KICAgIHVwZGF0ZWQgYXQgQ0VzLCBGb3JDRVMgaXMgdXNl ZCB0byBzZW5kIHRoZSBuZXcgcm91dGUgZW50cmllcyBmcm9tIA0KICAgIENFcyB0byBGRXMuICBF YWNoIEZFIGhhcyBpdHMgb3duIGZvcndhcmRpbmcgdGFibGUgYW5kIHVzZXMgdGhpcyANCiAgICB0 YWJsZSB0byBkaXJlY3QgcGFja2V0cyB0byB0aGUgbmV4dCBob3AgaW50ZXJmYWNlLiAgDQogICAg IA0KICAgIFVwb24gcmVjZWl2aW5nIElQIHBhY2tldHMsIHRoZSBGRSB2ZXJpZmllcyB0aGUgSVAg aGVhZGVyIGFuZCANCiAgICBwcm9jZXNzZXMgbW9zdCBvZiB0aGUgSVAgb3B0aW9ucy4gIFNvbWUg b3B0aW9ucyBjYW5ub3QgYmUgcHJvY2Vzc2VkIA0KICAgIHVudGlsIHRoZSByb3V0aW5nIGRlY2lz aW9uIGhhcyBiZWVuIG1hZGUuICBUaGUgcm91dGluZyBkZWNpc2lvbiBpcyANCiAgICBtYWRlIGFm dGVyIGV4YW1pbmluZyB0aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzcy4gIElmIHRoZSANCiAgICBk ZXN0aW5hdGlvbiBhZGRyZXNzIGJlbG9uZ3MgdG8gdGhlIHJvdXRlciBpdHNlbGYsIHRoZSBwYWNr ZXRzIGFyZSANCiAgICBmaWx0ZXJlZCBhbmQgZWl0aGVyIHByb2Nlc3NlZCBsb2NhbGx5IG9yIGZv cndhcmRlZCB0byBDRSwgZGVwZW5kaW5nIA0KICAgIHVwb24gdGhlIGluc3RydWN0aW9ucyBzZXQt dXAgYnkgQ0UuICBPdGhlcndpc2UsIHRoZSBGRSBkZXRlcm1pbmVzIA0KICAgIHRoZSBuZXh0IGhv cCBJUCBhZGRyZXNzIGJ5IGxvb2tpbmcgdXAgaW4gaXRzIGZvcndhcmRpbmcgdGFibGUuICBUaGUg DQogICAgRkUgYWxzbyBkZXRlcm1pbmVzIHRoZSBuZXR3b3JrIGludGVyZmFjZSBpdCB1c2VzIHRv IHNlbmQgdGhlIA0KICAgIHBhY2tldHMuICBTb21ldGltZXMgYW4gRkUgbWF5IG5lZWQgdG8gZm9y d2FyZCB0aGUgcGFja2V0cyB0byANCiAgICBhbm90aGVyIEZFIGJlZm9yZSBwYWNrZXRzIGNhbiBi ZSBmb3J3YXJkZWQgb3V0IHRvIHRoZSBuZXh0IGhvcC4gIA0KICAgIFJpZ2h0IGJlZm9yZSBwYWNr ZXRzIGFyZSBmb3J3YXJkZWQgb3V0IHRvIHRoZSBuZXh0IGhvcCwgdGhlIEZFIA0KICAgIGRlY3Jl bWVudHMgVFRMIGJ5IDEgYW5kIHByb2Nlc3NlcyBhbnkgSVAgb3B0aW9ucyB0aGF0IGNhbm5vdCBi ZSANCiAgICBwcm9jZXNzZWQgYmVmb3JlLiAgVGhlIEZFIHBlcmZvcm1zIGFueSBJUCBmcmFnbWVu dGF0aW9uIGlmIA0KICAgIG5lY2Vzc2FyeSwgZGV0ZXJtaW5lcyBsaW5rIGxheWVyIGFkZHJlc3Mg KGUuZy4sIGJ5IEFSUCksIGFuZCANCiAgICBlbmNhcHN1bGF0ZXMgdGhlIElQIGRhdGFncmFtIChv ciBlYWNoIG9mIHRoZSBmcmFnbWVudHMgdGhlcmVvZikgaW4gDQogICAgYW4gYXBwcm9wcmlhdGUg bGluayBsYXllciBmcmFtZSBhbmQgcXVldWVzIGl0IGZvciBvdXRwdXQgb24gdGhlIA0KICAgIGlu dGVyZmFjZSBzZWxlY3RlZC4gDQogICAgIA0KICAgIE90aGVyIG9wdGlvbnMgbWVudGlvbmVkIGlu IFJGQzE4MTIgZm9yIElQIGZvcndhcmRpbmcgbWF5IGFsc28gYmUgDQogICAgaW1wbGVtZW50ZWQg YXQgRkVzLCBmb3IgZXhhbXBsZSwgcGFja2V0IGZpbHRlcmluZy4gDQogICAgIA0KICAgIEZFcyB0 eXBpY2FsbHkgZm9yd2FyZCBwYWNrZXRzIGRlc3RpbmVkIGxvY2FsbHkgdG8gQ0VzLiAgRkVzIG1h eSANCiAgICBhbHNvIGZvcndhcmQgZXhjZXB0aW9uYWwgcGFja2V0cyAocGFja2V0cyB0aGF0IEZF cyBkbyBub3Qga25vdyBob3cgDQogICAgdG8gaGFuZGxlKSB0byBDRXMuICBDRXMgYXJlIHJlcXVp cmVkIHRvIGhhbmRsZSBwYWNrZXRzIGZvcndhcmRlZCBieSANCiAgICBGRXMgZm9yIHdoYXRldmVy IGRpZmZlcmVudCByZWFzb25zLiAgSXQgbWlnaHQgYmUgbmVjZXNzYXJ5IGZvciANCiAgICBGb3JD RVMgdG8gYXR0YWNoIHNvbWUgbWV0YS1kYXRhIHdpdGggdGhlIHBhY2tldHMgdG8gaW5kaWNhdGUg dGhlIA0KICAgIHJlYXNvbnMgb2YgZm9yd2FyZGluZyBmcm9tIEZFcyB0byBDRXMuICBVcG9uIHJl Y2VpdmluZyBwYWNrZXRzIHdpdGggDQogICAgbWV0YS1kYXRhIGZyb20gRkVzLCBDRXMgY2FuIGRl Y2lkZSB0byBlaXRoZXIgcHJvY2VzcyB0aGUgcGFja2V0cyANCiAgICB0aGVtc2VsdmVzLCBvciBw YXNzIHRoZSBwYWNrZXRzIHRvIHRoZSB1cHBlciBsYXllciBwcm90b2NvbHMgDQogICAgaW5jbHVk aW5nIHJvdXRpbmcgYW5kIG1hbmFnZW1lbnQgcHJvdG9jb2xzLiAgSWYgQ0VzIGFyZSB0byBwcm9j ZXNzIA0KICAgIHRoZSBwYWNrZXRzIGJ5IHRoZW1zZWx2ZXMsIENFcyBtYXkgY2hvb3NlIHRvIGRp c2NhcmQgdGhlIHBhY2tldHMsIA0KICAgIG9yIG1vZGlmeSBhbmQgcmUtc2VuZCB0aGUgcGFja2V0 cy4gIENFcyBtYXkgYWxzbyBvcmlnaW5hdGUgbmV3IA0KICAgIHBhY2tldHMgYW5kIGRlbGl2ZXIg dGhlbSB0byBGRXMgZm9yIGZ1cnRoZXIgZm9yd2FyZGluZy4gIA0KICANCiAgDQogWWFuZywgZXQg YWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDI3 XSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAg ICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAgICAgDQogICAgQW55IHN0YXRlIGNoYW5n ZSBkdXJpbmcgcm91dGVyIG9wZXJhdGlvbiBtdXN0IGFsc28gYmUgaGFuZGxlZCANCiAgICBjb3Jy ZWN0bHkgYWNjb3JkaW5nIHRvIFJGQzE4MTIuICBGb3IgZXhhbXBsZSwgd2hlbiBhbiBGRSBjZWFz ZXMgDQogICAgZm9yd2FyZGluZywgdGhlIGVudGlyZSBORSBtYXkgY29udGludWUgZm9yd2FyZGlu ZyBwYWNrZXRzLCBidXQgaXQgDQogICAgbmVlZHMgdG8gc3RvcCBhZHZlcnRpc2luZyByb3V0ZXMg dGhhdCBhcmUgYWZmZWN0ZWQgYnkgdGhlIGZhaWxlZCANCiAgICBGRS4gIA0KICAgICAgDQogNS41 LiBUcmFuc3BvcnQgTGF5ZXIgIA0KICAgICANCiAgICBUcmFuc3BvcnQgbGF5ZXIgaXMgdHlwaWNh bGx5IGltcGxlbWVudGVkIGF0IENFcyB0byBzdXBwb3J0IGhpZ2hlciANCiAgICBsYXllciBhcHBs aWNhdGlvbiBwcm90b2NvbHMgbGlrZSByb3V0aW5nIHByb3RvY29scy4gIEluIHByYWN0aWNlLCAN CiAgICB0aGlzIG1lYW5zIHRoYXQgbW9zdCBDRXMgaW1wbGVtZW50IGJvdGggdGhlIFRyYW5zbWlz c2lvbiBDb250cm9sIA0KICAgIFByb3RvY29sIChUQ1ApIGFuZCB0aGUgVXNlciBEYXRhZ3JhbSBQ cm90b2NvbCAoVURQKS4gDQogICAgIA0KICAgIEJvdGggQ0VzIGFuZCBGRXMgbmVlZCB0byBpbXBs ZW1lbnQgRm9yQ0VTIHByb3RvY29sLiAgSWYgc29tZSBsYXllci0NCiAgICA0IHRyYW5zcG9ydCBp cyB1c2VkIHRvIHN1cHBvcnQgRm9yQ0VTLCB0aGVuIGJvdGggQ0VzIGFuZCBGRXMgbmVlZCANCiAg ICB0byBpbXBsZW1lbnQgdGhlIEw0IHRyYW5zcG9ydCBhbmQgRm9yQ0VTIHByb3RvY29scy4gICAN CiAgDQogNS42LiBBcHBsaWNhdGlvbiBMYXllciAtLSBSb3V0aW5nIFByb3RvY29scyANCiAgICAg DQogICAgSW50ZXJpb3IgYW5kIGV4dGVyaW9yIHJvdXRpbmcgcHJvdG9jb2xzIGFyZSBpbXBsZW1l bnRlZCBvbiBDRXMuICANCiAgICBUaGUgcm91dGluZyBwYWNrZXRzIG9yaWdpbmF0ZWQgYnkgQ0Vz IGFyZSBmb3J3YXJkZWQgdG8gRkVzIGZvciANCiAgICBkZWxpdmVyeS4gIFRoZSByZXN1bHRzIG9m IHN1Y2ggcHJvdG9jb2xzIChsaWtlIGZvcndhcmRpbmcgdGFibGUgDQogICAgdXBkYXRlcykgYXJl IGNvbW11bmljYXRlZCB0byBGRXMgdmlhIEZvckNFUy4gDQogICAgIA0KICAgIEZvciBwZXJmb3Jt YW5jZSBvciBzY2FsYWJpbGl0eSByZWFzb25zLCBwb3J0aW9ucyBvZiB0aGUgY29udHJvbCANCiAg ICBwbGFuZSBmdW5jdGlvbnMgdGhhdCBuZWVkIGZhc3RlciByZXNwb25zZSBtYXkgYmUgbW92ZWQg ZnJvbSB0aGUgQ0VzIA0KICAgIGFuZCBvZmYtbG9hZGVkIG9udG8gdGhlIEZFcy4gIEZvciBleGFt cGxlIGluIE9TUEYsIHRoZSBIZWxsbyANCiAgICBwcm90b2NvbCBwYWNrZXRzIGFyZSBnZW5lcmF0 ZWQgYW5kIHByb2Nlc3NlZCBwZXJpb2RpY2FsbHkuICBXaGVuIA0KICAgIGRvbmUgYXQgQ0VzLCB0 aGUgaW5ib3VuZCBIZWxsbyBwYWNrZXRzIGhhdmUgdG8gdHJhdmVyc2UgZnJvbSB0aGUgDQogICAg ZXh0ZXJuYWwgaW50ZXJmYWNlcyBhdCB0aGUgRkVzIHRvIHRoZSBDRXMgdmlhIHRoZSBpbnRlcm5h bCBDRS1GRSANCiAgICBjaGFubmVsLiAgU2ltaWxhcmx5LCB0aGUgb3V0Ym91bmQgSGVsbG8gcGFj a2V0cyBoYXZlIHRvIGdvIGZyb20gdGhlIA0KICAgIENFcyB0byB0aGUgRkVzIGFuZCB0byB0aGUg ZXh0ZXJuYWwgaW50ZXJmYWNlcy4gIEZyZXF1ZW50IEhlbGxvIA0KICAgIHVwZGF0ZXMgcGxhY2Ug aGVhdnkgcHJvY2Vzc2luZyBvdmVyaGVhZCBvbiB0aGUgQ0VzIGFuZCBjYW4gDQogICAgb3Zlcndo ZWxtIHRoZSBDRS1GRSBjaGFubmVsIGFzIHdlbGwuICBTaW5jZSB0eXBpY2FsbHkgdGhlcmUgYXJl IGZhciANCiAgICBtb3JlIEZFcyB0aGFuIENFcyBpbiBhIHJvdXRlciwgdGhlIG9mZi1sb2FkZWQg SGVsbG8gcGFja2V0cyBhcmUgDQogICAgcHJvY2Vzc2VkIGluIGEgbXVjaCBtb3JlIGRpc3RyaWJ1 dGVkIGFuZCBzY2FsYWJsZSBmYXNoaW9uLiAgQnkgDQogICAgZXhwcmVzc2luZyBzdWNoIG9mZi1s b2FkZWQgZnVuY3Rpb25zIGluIHRoZSBGRSBtb2RlbCwgd2UgY2FuIGVuc3VyZSANCiAgICBpbnRl cm9wZXJhYmlsaXR5LiBIb3dldmVyLCB0aGUgZXhhY3QgZGVzY3JpcHRpb24gb2YgdGhlIG9mZi1s b2FkZWQgDQogICAgZnVuY3Rpb25hbGl0eSBjb3JyZXNwb25kaW5nIHRvIHRoZSBvZmYtbG9hZGVk IGZ1bmN0aW9ucyBleHByZXNzZWQgDQogICAgaW4gdGhlIEZFIG1vZGVsIGFyZSBub3QgcGFydCBv ZiB0aGUgbW9kZWwgaXRzZWxmIGFuZCB3aWxsIG5lZWQgdG8gDQogICAgYmUgd29ya2VkIG91dCBh cyBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24uIA0KICANCiA1LjcuIEFwcGxpY2F0aW9uIExheWVy IC0tIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbCANCiAgICAgDQogICAgUkZDMTgxMiBhbHNv IGRpY3RhdGVzICJSb3V0ZXJzIE1VU1QgYmUgbWFuYWdlYWJsZSBieSBTTk1QLiIgIChzZWUgDQog ICAgWzRdIFNlY3Rpb24gOCkgSW4gZ2VuZXJhbCwgZm9yIHBvc3QtYXNzb2NpYXRpb24gcGhhc2Us IG1vc3QgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIE1hcmNoICAgIDIwMDQg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMjhdICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBG b3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0K ICAgIGV4dGVybmFsIG1hbmFnZW1lbnQgdGFza3MgKGluY2x1ZGluZyBTTk1QKSBzaG91bGQgYmUg ZG9uZSB0aHJvdWdoIA0KICAgIGludGVyYWN0aW9uIHdpdGggdGhlIENFIGluIG9yZGVyIHRvIHN1 cHBvcnQgdGhlIGFwcGVhcmFuY2Ugb2YgYSANCiAgICBzaW5nbGUgZnVuY3Rpb25hbCBkZXZpY2Uu ICBUaGVyZWZvcmUsIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgU05NUCANCiAgICBtYW5hZ2VtZW50 IGFnZW50IGJlIGltcGxlbWVudGVkIGJ5IENFcyBhbmQgdGhlIFNOTVAgbWVzc2FnZXMgDQogICAg cmVjZWl2ZWQgYnkgRkVzIGJlIHJlZGlyZWN0ZWQgdG8gdGhlaXIgQ0VzLiAgQWdlbnRYIGZyYW1l d29yayANCiAgICBkZWZpbmVkIGluIFJGQzI3NDEgKFs1XSkgbWF5IGJlIGFwcGxpZWQgaGVyZSBz dWNoIHRoYXQgQ0VzIGFjdCBpbiANCiAgICB0aGUgcm9sZSBvZiBtYXN0ZXIgYWdlbnQgdG8gcHJv Y2VzcyBTTk1QIHByb3RvY29sIG1lc3NhZ2VzIHdoaWxlIA0KICAgIEZFcyBhY3QgaW4gdGhlIHJv bGUgb2Ygc3ViYWdlbnQgdG8gcHJvdmlkZSBhY2Nlc3MgdG8gdGhlIE1JQiANCiAgICBvYmplY3Rz IHJlc2lkaW5nIG9uIEZFcy4gIEFnZW50WCBwcm90b2NvbCBtZXNzYWdlcyBiZXR3ZWVuIHRoZSAN CiAgICBtYXN0ZXIgYWdlbnQgKENFKSBhbmQgdGhlIHN1YmFnZW50IChGRSkgYXJlIGVuY2Fwc3Vs YXRlZCBhbmQgDQogICAgdHJhbnNwb3J0ZWQgdmlhIEZvckNFUywganVzdCBsaWtlIGRhdGEgcGFj a2V0cyBmcm9tIGFueSBvdGhlciANCiAgICBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbHMuICAN CiAgDQogNi4gU3VtbWFyeSANCiAgICAgDQogICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGFy Y2hpdGVjdHVyYWwgZnJhbWV3b3JrIGZvciBGb3JDRVMuICBJdCANCiAgICBpZGVudGlmaWVzIHRo ZSByZWxldmFudCBjb21wb25lbnRzIGZvciBhIEZvckNFUyBuZXR3b3JrIGVsZW1lbnQsIA0KICAg IGluY2x1ZGluZyAob25lIG9yIG1vcmUpIEZFcywgKG9uZSBvciBtb3JlKSBDRXMsIG9uZSBvcHRp b25hbCBGRSANCiAgICBtYW5hZ2VyLCBhbmQgb25lIG9wdGlvbmFsIENFIG1hbmFnZXIuICBJdCBh bHNvIGlkZW50aWZpZXMgdGhlIA0KICAgIGludGVyYWN0aW9uIGFtb25nIHRoZXNlIGNvbXBvbmVu dHMgYW5kIGRpc2N1c3NlcyBhbGwgdGhlIG1ham9yIA0KICAgIHJlZmVyZW5jZSBwb2ludHMuICBJ dCBpcyBpbXBvcnRhbnQgdG8gcG9pbnQgb3V0IHRoYXQsIGFtb25nIGFsbCB0aGUgDQogICAgcmVm ZXJlbmNlIHBvaW50cywgb25seSB0aGUgRnAgaW50ZXJmYWNlIGJldHdlZW4gQ0VzIGFuZCBGRXMg aXMgDQogICAgd2l0aGluIHRoZSBzY29wZSBvZiBGb3JDRVMuICBGb3JDRVMgYWxvbmUgbWF5IG5v dCBiZSBlbm91Z2ggdG8gDQogICAgc3VwcG9ydCBhbGwgZGVzaXJhYmxlIE5FIGNvbmZpZ3VyYXRp b25zLiAgSG93ZXZlciwgd2UgYmVsaWV2ZSB0aGF0IA0KICAgIEZvckNFUyBvdmVyIEZwIGludGVy ZmFjZSBpcyB0aGUgbW9zdCBpbXBvcnRhbnQgZWxlbWVudCBpbiByZWFsaXppbmcgDQogICAgcGh5 c2ljYWwgc2VwYXJhdGlvbiBhbmQgaW50ZXJvcGVyYWJpbGl0eSBvZiBDRXMgYW5kIEZFcywgYW5k IGhlbmNlIA0KICAgIHRoZSBmaXJzdCBpbnRlcmZhY2UgdGhhdCBvdWdodCB0byBiZSBzdGFuZGFy ZGl6ZWQuICBTaW1wbGUgYW5kIA0KICAgIHVzZWZ1bCBjb25maWd1cmF0aW9ucyBjYW4gc3RpbGwg YmUgaW1wbGVtZW50ZWQgd2l0aCBvbmx5IENFLUZFIA0KICAgIGludGVyZmFjZSBiZWluZyBzdGFu ZGFyZGl6ZWQsIGUuZy4sIHNpbmdsZSBDRSB3aXRoIGZ1bGwtbWVzaGVkIEZFcy4gDQogICAgIA0K IDcuIEFja25vd2xlZGdlbWVudHMgDQogICAgIA0KICAgIEpvZWwgTS4gSGFscGVybiBnYXZlIHVz IG1hbnkgaW5zaWdodGZ1bCBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgDQogICAgYW5kIHBvaW50 ZWQgb3V0IHNldmVyYWwgbWFqb3IgaXNzdWVzLiAgVC4gU3JpZGhhciBzdWdnZXN0ZWQgdGhhdCAN CiAgICB0aGUgQWdlbnRYIHByb3RvY29sIGNvdWxkIGJlIHVzZWQgd2l0aCBTTk1QIHRvIG1hbmFn ZSB0aGUgRm9yQ0VTIA0KICAgIG5ldHdvcmsgZWxlbWVudHMuICBNYW55IG9mIG91ciBjb2xsZWFn dWVzIGFuZCBwZW9wbGUgaW4gdGhlIEZvckNFUyANCiAgICBtYWlsaW5nIGxpc3QgYWxzbyBwcm92 aWRlZCB2YWx1YWJsZSBmZWVkYmFjay4gDQogICAgIA0KIDguIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIA0KICAgICANCiAgICBJbiBnZW5lcmFsLCB0aGUgcGh5c2ljYWwgc2VwYXJhdGlvbiBvZiB0 d28gZW50aXRpZXMgdXN1YWxseSByZXN1bHRzIA0KICAgIGluIGEgcG90ZW50aWFsbHkgaW5zZWN1 cmUgbGluayBiZXR3ZWVuIHRoZSB0d28gZW50aXRpZXMgYW5kIGhlbmNlIA0KICAgIG11Y2ggc3Ry aWN0ZXIgc2VjdXJpdHkgbWVhc3VyZW1lbnRzIGFyZSByZXF1aXJlZC4gIEZvciBleGFtcGxlLCB3 ZSANCiAgICBwb2ludGVkIG91dCBpbiBTZWN0aW9uIDQuMSB0aGF0IGF1dGhlbnRpY2F0aW9uIGJl Y29tZXMgbmVjZXNzYXJ5IA0KICAgIGJldHdlZW4gQ0UgbWFuYWdlciBhbmQgRkUgbWFuYWdlciwg YmV0d2VlbiBDRSBhbmQgQ0UgbWFuYWdlciwgDQogICAgYmV0d2VlbiBGRSBhbmQgRkUgbWFuYWdl ciBpbiBzb21lIGNvbmZpZ3VyYXRpb25zLiAgVGhlIHBoeXNpY2FsIA0KICAgIHNlcGFyYXRpb24g b2YgQ0UgYW5kIEZFIGFsc28gaW1wb3NlcyBzZXJpb3VzIHNlY3VyaXR5IHJlcXVpcmVtZW50IA0K ICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAgICAgICAg ICAgICAgICAgIFtQYWdlIDI5XSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZy YW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAgICBmb3Ig Rm9yQ0VTIHByb3RvY29sIG92ZXIgRnAgaW50ZXJmYWNlLiAgVGhpcyBzZWN0aW9uIGZpcnN0IGF0 dGVtcHRzIA0KICAgIHRvIGRlc2NyaWJlIHRoZSBzZWN1cml0eSB0aHJlYXRzIHRoYXQgbWF5IGJl IGludHJvZHVjZWQgYnkgdGhlIA0KICAgIHBoeXNpY2FsIHNlcGFyYXRpb24gb2YgdGhlIEZFcyBh bmQgdGhlIENFcywgYW5kIHRoZW4gaXQgcHJvdmlkZXMgDQogICAgcmVjb21tZW5kYXRpb24gYW5k IGd1aWRlbGluZXMgZm9yIHNlY3VyZSBvcGVyYXRpb24gYW5kIG1hbmFnZW1lbnQgDQogICAgb2Yg Rm9yQ0VTIHByb3RvY29sIG92ZXIgRnAgaW50ZXJmYWNlIGJhc2VkIG9uIGV4aXN0aW5nIHN0YW5k YXJkIA0KICAgIHNlY3VyaXR5IHNvbHV0aW9ucy4gDQogICAgIA0KIDguMS4gQW5hbHlzaXMgb2Yg UG90ZW50aWFsIFRocmVhdHMgSW50cm9kdWNlZCBieSBGb3JDRVMgDQogICAgIA0KICAgIFRoaXMg c2VjdGlvbiBwcm92aWRlcyB0aGUgdGhyZWF0IGFuYWx5c2lzIGZvciBGb3JDRVMsIHdpdGggYSBm b2N1cyANCiAgICBvbiBGcCBpbnRlcmZhY2UuICBFYWNoIHRocmVhdCBpcyBkZXNjcmliZWQgaW4g ZGV0YWlscyB3aXRoIHRoZSANCiAgICBlZmZlY3RzIG9uIHRoZSBGb3JDRVMgcHJvdG9jb2wgZW50 aXRpZXMgb3IvYW5kIHRoZSBORSBhcyBhIHdob2xlLCANCiAgICBhbmQgdGhlIHJlcXVpcmVkIGZ1 bmN0aW9uYWxpdGllcyB0aGF0IG5lZWQgdG8gYmUgaW4gcGxhY2UgdG8gZGVmZW5kIA0KICAgIHRo ZSB0aHJlYXQuICANCiAgDQogOC4xLjEuICJKb2luIiBvciAiUmVtb3ZlIiBNZXNzYWdlIEZsb29k aW5nIG9uIENFcyANCiAgICAgDQogICAgVGhyZWF0czogIEEgbWFsaWNpb3VzIG5vZGUgY291bGQg c2VuZCBhIHN0cmVhbSBvZiBmYWxzZSAiam9pbiBORSIgDQogICAgb3IgInJlbW92ZSBmcm9tIE5F IiByZXF1ZXN0cyBvbiBiZWhhbGYgb2Ygbm9uLWV4aXN0ZW50IG9yIA0KICAgIHVuYXV0aG9yaXpl ZCBGRSB0byBsZWdpdGltYXRlIENFcyBhdCBhIHZlcnkgcmFwaWQgcmF0ZSBhbmQgdGhlcmVieSAN CiAgICBjcmVhdGUgdW5uZWNlc3Nhcnkgc3RhdGUgaW4gdGhlIENFcy4gDQogICAgIA0KICAgIEVm ZmVjdHM6IElmIGJ5IG1haW50YWluaW5nIHN0YXRlIGZvciBub24tZXhpc3RlbnQgb3IgdW5hdXRo b3JpemVkIA0KICAgIEZFcywgYSBDRSBtYXkgYmVjb21lIHVuYXZhaWxhYmxlIGZvciBvdGhlciBw cm9jZXNzaW5nIGFuZCBoZW5jZSANCiAgICBzdWZmZXIgZnJvbSBkZW5pYWwgb2Ygc2VydmljZSAo RG9TKSBhdHRhY2sgc2ltaWxhciB0byB0aGUgVENQIFNZTiANCiAgICBEb1MuICBJZiBtdWx0aXBs ZSBDRXMgYXJlIHVzZWQsIHRoZSB1bm5lY2Vzc2FyeSBzdGF0ZSBpbmZvcm1hdGlvbiANCiAgICBt YXkgYWxzbyBiZSBjb252ZXllZCB0byBtdWx0aXBsZSBDRXMgdmlhIEZyIGludGVyZmFjZSAoZS5n LiwgZnJvbSANCiAgICB0aGUgYWN0aXZlIENFIHRvIHRoZSBzdGFuZC1ieSBDRSkgYW5kIGhlbmNl IHN1YmplY3QgbXVsdGlwbGUgQ0VzIHRvIA0KICAgIERvUyBhdHRhY2suICANCiAgICAgICAgDQog ICAgUmVxdWlyZW1lbnQ6ICBBIENFIHRoYXQgcmVjZWl2ZXMgYSAiam9pbiIgb3IgInJlbW92ZSIg cmVxdWVzdCANCiAgICBzaG91bGQgbm90IGNyZWF0ZSBhbnkgc3RhdGUgaW5mb3JtYXRpb24gdW50 aWwgaXQgaGFzIGF1dGhlbnRpY2F0ZWQgDQogICAgdGhlIEZFIGVuZHBvaW50LiANCiAgICAgDQog ICAgIA0KIDguMS4yLiBJbXBlcnNvbmF0aW9uIEF0dGFjayAgDQogICAgIA0KICAgIFRocmVhdHM6 IEEgbWFsaWNpb3VzIG5vZGUgY2FuIGltcGVyc29uYXRlIGEgQ0Ugb3IgRkUgYW5kIHNlbmQgb3V0 IA0KICAgIGZhbHNlIG1lc3NhZ2VzLiANCiAgICAgDQogICAgRWZmZWN0czogVGhlIHdob2xlIE5F IGNvdWxkIGJlIGNvbXByb21pc2VkLiANCiAgDQogICAgUmVxdWlyZW1lbnQ6ICBUaGUgQ0Ugb3Ig RkUgbXVzdCBhdXRoZW50aWNhdGUgdGhlIG1lc3NhZ2UgYmVmb3JlIA0KICAgIGFjY2VwdGluZyBh bmQgcHJvY2Vzc2luZyBpdC4gICANCiAgICAgDQogICAgIA0KIDguMS4zLiBSZXBsYXkgQXR0YWNr IA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAgICAg ICAgICAgICAgICAgIFtQYWdlIDMwXSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VT IEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAgICAg DQogICAgVGhyZWF0OiBBIG1hbGljaW91cyBub2RlIGNvdWxkIHJlcGxheSB0aGUgZW50aXJlIG1l c3NhZ2UgcHJldmlvdXNseSANCiAgICBzZW50IGJ5IGFuIEZFIG9yIENFIGVudGl0eSB0byBnZXQg YXJvdW5kIGF1dGhlbnRpY2F0aW9uLiAgDQogICAgIA0KICAgIEVmZmVjdDogVGhlIE5FIGNvdWxk IGJlIGNvbXByb21pc2VkLiANCiAgICAgDQogICAgUmVxdWlyZW1lbnQ6ICBSZXBsYXkgcHJvdGVj dGlvbiBtZWNoYW5pc20gbmVlZHMgdG8gYmUgcGFydCBvZiB0aGUgDQogICAgc2VjdXJpdHkgc29s dXRpb24gdG8gZGVmZW5kIGFnYWluc3QgdGhpcyBhdHRhY2suIA0KICAgICAgDQogOC4xLjQuIEF0 dGFjayBkdXJpbmcgRmFpbCBPdmVyIA0KICAgICAgDQogICAgVGhyZWF0OiBBIG1hbGljaW91cyBu b2RlIG1heSBleHBsb2l0IHRoZSBDRSBmYWlsLW92ZXIgbWVjaGFuaXNtIHRvIA0KICAgIHRha2Ug b3ZlciB0aGUgY29udHJvbCBvZiBORS4gRm9yIGV4YW1wbGUsIHN1cHBvc2UgdHdvIENFcywgc2F5 IENFLUEgDQogICAgYW5kIENFLUIsIGFyZSBjb250cm9sbGluZyBzZXZlcmFsIEZFcy4gQ0UtQSBp cyBhY3RpdmUgYW5kIENFLUIgaXMgDQogICAgc3RhbmQtYnkuICBXaGVuIENFLUEgZmFpbHMsIENF LUIgaXMgdGFraW5nIG92ZXIgdGhlIGFjdGl2ZSBDRSANCiAgICBwb3NpdGlvbi4gIFRoZSBGRXMg YWxyZWFkeSBoYWQgYSB0cnVzdGVkIHJlbGF0aW9uc2hpcCB3aXRoIENFLUEsIA0KICAgIGJ1dCB0 aGUgRkVzIG1heSBub3QgaGF2ZSB0aGUgc2FtZSB0cnVzdGVkIHJlbGF0aW9uc2hpcCBlc3RhYmxp c2hlZCANCiAgICB3aXRoIENFLUIgcHJpb3IgdG8gdGhlIGZhaWwtb3Zlci4gIEEgbWFsaWNpb3Vz IG5vZGUgY2FuIHRha2Ugb3ZlciANCiAgICBhcyBDRS1CIGlmIHN1Y2ggdHJ1c3RlZCByZWxhdGlv bnNoaXAgaXMgbm90IGVzdGFibGlzaGVkIGR1cmluZyB0aGUgDQogICAgZmFpbC1vdmVyLiAgDQog ICAgIA0KICAgIEVmZmVjdDogVGhlIE5FIG1heSBiZSBjb21wcm9taXNlZCBhZnRlciBzdWNoIGlu c2VjdXJlIGZhaWwtb3Zlci4gDQogICAgIA0KICAgIFJlcXVpcmVtZW50OiAgVGhlIGxldmVsIG9m IHRydXN0IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBzdGFuZC1ieSANCiAgICBDRSBhbmQgdGhl IEZFcyBtdXN0IGJlIGFzIHN0cm9uZyBhcyB0aGUgb25lIGJldHdlZW4gdGhlIGFjdGl2ZSBDRSAN CiAgICBhbmQgdGhlIEZFcy4gIFRoZSBzZWN1cml0eSBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBG RXMgYW5kIHRoZSANCiAgICBzdGFuZC1ieSBDRSBtYXkgYmUgZXN0YWJsaXNoZWQgcHJpb3IgdG8g ZmFpbC1vdmVyLiAgSWYgbm90IGFscmVhZHkgDQogICAgaW4gcGxhY2UsIHN1Y2ggc2VjdXJpdHkg YXNzb2NpYXRpb24gbXVzdCBiZSByZS1lc3RhYmxpc2hlZCBiZWZvcmUgDQogICAgdGhlIHN0YW5k LWJ5IENFIHRha2VzIG92ZXIuIA0KICAgICAgDQogOC4xLjUuICBEYXRhIEludGVncml0eSAgDQog ICAgIA0KICAgIFRocmVhdHM6IEEgbWFsaWNpb3VzIG5vZGUgbWF5IGluamVjdCBmYWxzZSBtZXNz YWdlcyB0byBsZWdpdGltYXRlIA0KICAgIENFIG9yIEZFLiAgICAgDQogICAgIA0KICAgIEVmZmVj dDogQW4gRkUgb3IgQ0UgcmVjZWl2ZXMgdGhlIGZhYnJpY2F0ZWQgcGFja2V0IGFuZCBwZXJmb3Jt cyANCiAgICBpbmNvcnJlY3Qgb3IgY2F0YXN0cm9waGljIG9wZXJhdGlvbi4gDQogICAgIA0KICAg IFJlcXVpcmVtZW50OiBQcm90b2NvbCBtZXNzYWdlcyByZXF1aXJlIGludGVncml0eSBwcm90ZWN0 aW9uLiANCiAgICAgDQogOC4xLjYuICBEYXRhIENvbmZpZGVudGlhbGl0eSANCiAgICAgDQogICAg VGhyZWF0OiBXaGVuIEZFIGFuZCBDRSBhcmUgcGh5c2ljYWxseSBzZXBhcmF0ZWQsIGEgbWFsaWNp b3VzIG5vZGUgDQogICAgbWF5IGVhdmVzZHJvcCB0aGUgbWVzc2FnZXMgaW4gdHJhbnNpdC4gIFNv bWUgb2YgdGhlIG1lc3NhZ2VzIGFyZSANCiAgICBjcml0aWNhbCB0byB0aGUgZnVuY3Rpb25pbmcg b2YgdGhlIHdob2xlIG5ldHdvcmssIHdoaWxlIG90aGVycyBtYXkgDQogICAgY29udGFpbiBjb25m aWRlbnRpYWwgYnVzaW5lc3MgZGF0YS4gIExlYWtpbmcgb2Ygc3VjaCBpbmZvcm1hdGlvbiANCiAg ICBtYXkgcmVzdWx0IGluIGNvbXByb21pc2UgZXZlbiBiZXlvbmQgdGhlIGltbWVkaWF0ZSBDRSBv ciBGRS4gIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0 ICAgICAgICAgICAgICAgICAgIFtQYWdlIDMxXSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAg Rm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICAN CiAgICAgIA0KICAgIEVmZmVjdDogU2Vuc2l0aXZlIGluZm9ybWF0aW9uIG1pZ2h0IGJlIGV4cG9z ZWQgYmV0d2VlbiBDRSBhbmQgRkUuIA0KICAgICANCiAgICBSZXF1aXJlbWVudDogRGF0YSBjb25m aWRlbnRpYWxpdHkgYmV0d2VlbiBGRSBhbmQgQ0UgbXVzdCBiZSANCiAgICBhdmFpbGFibGUgZm9y IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gDQogIA0KIDguMS43LiBTaGFyaW5nIHNlY3VyaXR5IHBh cmFtZXRlcnMgDQogICAgIA0KICAgIFRocmVhdDogQ29uc2lkZXIgYSBzY2VuYXJpbyB3aGVyZSBz ZXZlcmFsIEZFcyBjb21tdW5pY2F0aW5nIHRvIHRoZSANCiAgICBzYW1lIENFIHNoYXJlIHRoZSBz YW1lIGF1dGhlbnRpY2F0aW9uIGtleXMgZm9yIHRoZSBGcCBpbnRlcmZhY2UuICANCiAgICBJZiBh bnkgRkUgb3IgdGhlIENFIGlzIGNvbXByb21pc2VkLCBhbGwgb3RoZXIgZW50aXRpZXMgYXJlIA0K ICAgIGNvbXByb21pc2VkLiANCiAgICAgDQogICAgRWZmZWN0OiBUaGUgd2hvbGUgTkUgaXMgY29t cHJvbWlzZWQuIA0KICAgICAgDQogICAgUmVjb21tZW5kYXRpb246IFRvIGF2b2lkIHRoaXMgc2lk ZSBlZmZlY3QsIGl0J3MgYmV0dGVyIHRvIGNvbmZpZ3VyZSANCiAgICBkaWZmZXJlbnQgc2VjdXJp dHkgcGFyYW1ldGVycyBmb3IgZWFjaCBGRS1DRSBjb21tdW5pY2F0aW9uIG92ZXIgRnAgDQogICAg aW50ZXJmYWNlLiANCiAgICAgDQogOC4xLjguIERlbmlhbCBvZiBTZXJ2aWNlIEF0dGFjayB2aWEg RXh0ZXJuYWwgSW50ZXJmYWNlIA0KICAgICANCiAgICBUaHJlYXQ6IFdoZW4gYW4gRkUgcmVjZWl2 ZXMgYSBwYWNrZXQgdGhhdCBpcyBkZXN0aW5lZCBmb3IgaXRzIENFLCANCiAgICB0aGUgRkUgZm9y d2FyZHMgdGhlIHBhY2tldCBvdmVyIHRoZSBGcCBpbnRlcmZhY2UuICBNYWxpY2lvdXMgbm9kZSAN CiAgICBjYW4gZ2VuZXJhdGUgaHVnZSBtZXNzYWdlIHN0b3JtIGxpa2Ugcm91dGluZyBwcm90b2Nv bCBwYWNrZXRzIGV0Yy4gDQogICAgdGhyb3VnaCB0aGUgZXh0ZXJuYWwgRmkvZiBpbnRlcmZhY2Ug c28gdGhhdCB0aGUgRkUgaGFzIHRvIHByb2Nlc3MgDQogICAgYW5kIGZvcndhcmQgYWxsIHBhY2tl dHMgdG8gQ0UgdGhyb3VnaCBGcCBpbnRlcmZhY2UuIA0KICAgICANCiAgICBFZmZlY3Q6IENFIGVu Y291bnRlcnMgcmVzb3VyY2UgZXhoYXVzdGlvbiBhbmQgYmFuZHdpZHRoIHN0YXJ2YXRpb24gDQog ICAgb24gRnAgaW50ZXJmYWNlIGR1ZSB0byBhbiBvdmVyd2hlbG1pbmcgbnVtYmVyIG9mIHBhY2tl dHMgZnJvbSBGRXMuIA0KICAgICANCiAgICBSZXF1aXJlbWVudDogU29tZSBzb3J0IG9mIHJhdGUg bGltaXRpbmcgbWVjaGFuaXNtIE1VU1QgdG8gYmUgaW4gDQogICAgcGxhY2UgYXQgYm90aCBGRSBh bmQgQ0UuICBFeGFtcGxlcyBvZiBzdWNoIG1lY2hhbmlzbXMgaW5jbHVkZSANCiAgICBleHBsaWNp dCByYXRlIGxpbWl0ZXJzIG9yIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG1zLiAgUmF0ZSAN CiAgICBMaW1pdGVyIFNIT1VMRCBiZSBjb25maWd1cmVkIGF0IEZFIGZvciBlYWNoIG1lc3NhZ2Ug dHlwZSB0aGF0IGFyZSANCiAgICBiZWluZyByZWNlaXZlZCB0aHJvdWdoIEZpL0YgaW50ZXJmYWNl LiANCiAgICAgICAgICANCiA4LjIuIFNlY3VyaXR5IFJlY29tbWVuZGF0aW9ucyBmb3IgRm9yQ0VT IA0KICANCiAgICBUaGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IFszXSBzdWdnZXN0ZWQgdGhhdCBG b3JDRVMgcHJvdG9jb2wgc2hvdWxkIA0KICAgIHN1cHBvcnQgcmVsaWFiaWxpdHkgb3ZlciBGcCBp bnRlcmZhY2UsIGJ1dCBubyBwYXJ0aWN1bGFyIHRyYW5zcG9ydCANCiAgICBwcm90b2NvbCBpcyB5 ZXQgc3BlY2lmaWVkIGZvciBGb3JDRVMuICBUaGlzIGZyYW1ld29yayBkb2N1bWVudCBkb2VzIA0K ICAgIG5vdCBpbnRlbmQgdG8gc3BlY2lmeSB0aGUgcGFydGljdWxhciB0cmFuc3BvcnQgZWl0aGVy LCBhbmQgc28gd2UgDQogICAgb25seSBwcm92aWRlIHJlY29tbWVuZGF0aW9ucyBhbmQgZ3VpZGVs aW5lcyBiYXNlZCBvbiB0aGUgZXhpc3RpbmcgDQogICAgc3RhbmRhcmQgc2VjdXJpdHkgcHJvdG9j b2xzIHRoYXQgY2FuIHdvcmsgd2l0aCB0aGUgY29tbW9uIHRyYW5zcG9ydCANCiAgICBjYW5kaWRh dGVzIHN1aXRhYmxlIGZvciBGb3JDRVMuIA0KICAgICAgDQogIA0KICANCiBZYW5nLCBldCBhbC4g ICAgICBFeHBpcmVzIE1hcmNoICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMzJdICAg DQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAg ICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0KICAgIFdlIHJldmlldyB0d28gZXhpc3Rpbmcgc2Vj dXJpdHkgcHJvdG9jb2wgc29sdXRpb25zLCBuYW1lbHkgSVBzZWMgDQogICAgKElQIFNlY3VyaXR5 KSBbMTRdIG9yIFRMUyAoVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5KSBbMTNdLiAgVExTIA0KICAg IHdvcmtzIHdpdGggcmVsaWFibGUgdHJhbnNwb3J0cyBzdWNoIGFzIFRDUCBvciBTQ1RQIGZvciB1 bmljYXN0LCANCiAgICB3aGlsZSBJUHNlYyBjYW4gYmUgdXNlZCB3aXRoIGFueSB0cmFuc3BvcnQg KFVEUCwgVENQLCBTQ1RQKSBhbmQgDQogICAgc3VwcG9ydHMgYm90aCB1bmljYXN0IGFuZCBtdWx0 aWNhc3QuICBCb3RoIFRMUyBhbmQgSVBzZWMgY2FuIGJlIA0KICAgIHVzZWQgcG90ZW50aWFsbHkg dG8gc2F0aXNmeSBhbGwgb2YgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBmb3IgDQogICAgRm9y Q0VTIHByb3RvY29sLiAgT3RoZXIgYXBwcm9hY2hlcyBtYXkgYmUgdXNlZCBhcyB3ZWxsIGJ1dCBh cmUgbm90IA0KICAgIGRvY3VtZW50ZWQgaGVyZS4gDQogICAgICAgICAgDQogICAgV2hlbiBGb3JD RVMgaXMgZGVwbG95ZWQgYmV0d2VlbiBDRXMgYW5kIEZFcyBpbnNpZGUgYSBib3gsIA0KICAgIGF1 dGhlbnRpY2F0aW9uLCBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSBtYXkgYmUgcHJvdmlk ZWQgYnkgDQogICAgdGhlIHBoeXNpY2FsIHNlY3VyaXR5IG9mIHRoZSBib3ggYW5kIHNvIHRoZSBz ZWN1cml0eSBtZWNoYW5pc21zIG1heSANCiAgICBiZSB0dXJuZWQgb2ZmLCBkZXBlbmRpbmcgb24g dGhlIG5ldHdvcmtpbmcgdG9wb2xvZ3kgYW5kIGl0cyANCiAgICBhZG1pbmlzdHJhdGlvbiBwb2xp Y3kuICBIb3dldmVyLCBpdCBpcyBpbXBvcnRhbnQgdG8gcmVhbGl6ZSB0aGF0IA0KICAgIGV2ZW4g aWYgdGhlIE5FIGlzIGluIGEgc2luZ2xlLWJveCwgdGhlIERvUyBhdHRhY2tzIGFzIGRlc2NyaWJl ZCBpbiANCiAgICBTZWN0aW9uIDguMS44IGNhbiBzdGlsbCBiZSBsYXVuY2hlZCB0aHJvdWdoIEZp L2YgaW50ZXJmYWNlcy4gIA0KICAgIFRoZXJlZm9yZSwgaXQgaXMgaW1wb3J0YW50IHRvIGhhdmUg dGhlIGNvcnJlc3BvbmRpbmcgY291bnRlci0NCiAgICBtZWFzdXJlbWVudCBpbiBwbGFjZSBldmVu IGZvciBzaW5nbGUtYm94IGRlcGxveW1lbnQuIA0KICAgICAgICANCiA4LjIuMS4gU2VjdXJpdHkg Q29uZmlndXJhdGlvbiAgDQogICAgIA0KICAgIFRoZSBORSBhZG1pbmlzdHJhdG9yIGhhcyB0aGUg ZnJlZWRvbSB0byBkZXRlcm1pbmUgdGhlIGV4YWN0IA0KICAgIHNlY3VyaXR5IGNvbmZpZ3VyYXRp b24gdGhhdCBpcyBuZWVkZWQgZm9yIHRoZSBzcGVjaWZpYyBkZXBsb3ltZW50LiANCiAgICBGb3Ig ZXhhbXBsZSwgRm9yQ0VTIG1heSBiZSBkZXBsb3llZCBiZXR3ZWVuIENFcyBhbmQgRkVzIGNvbm5l Y3RlZCANCiAgICB0byBlYWNoIG90aGVyIGluc2lkZSBhIGJveCBvdmVyIGEgYmFja3BsYW5lLiAg SW4gc3VjaCBzY2VuYXJpbywgDQogICAgcGh5c2ljYWwgc2VjdXJpdHkgb2YgdGhlIGJveCBlbnN1 cmVzIHRoYXQgbW9zdCBvZiB0aGUgYXR0YWNrcyBzdWNoIA0KICAgIGFzIG1hbi1pbi10aGUtbWlk ZGxlLCBzbm9vcGluZywgYW5kIGltcGVyc29uYXRpb24gYXJlIG5vdCBwb3NzaWJsZSwgDQogICAg YW5kIGhlbmNlIEZvckNFUyBhcmNoaXRlY3R1cmUgbWF5IHJlbHkgb24gdGhlIHBoeXNpY2FsIHNl Y3VyaXR5IG9mIA0KICAgIHRoZSBib3ggdG8gZGVmZW5kIGFnYWluc3QgdGhlc2UgYXR0YWNrcyBh bmQgcHJvdG9jb2wgbWVjaGFuaXNtcyBtYXkgDQogICAgYmUgdHVybmVkIG9mZi4gIEhvd2V2ZXIs IGl0IGlzIGFsc28gc2hvd24gdGhhdCBkZW5pYWwgb2Ygc2VydmljZSANCiAgICBhdHRhY2sgdmlh IGV4dGVybmFsIGludGVyZmFjZSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA4LjEuOCBpcyANCiAg ICBzdGlsbCBhIHBvdGVudGlhbCB0aHJlYXQgZXZlbiBmb3Igc3VjaCAiYWxsLWluLW9uZS1ib3gi IGRlcGxveW1lbnQgDQogICAgc2NlbmFyaW8gYW5kIGhlbmNlIHRoZSByYXRlIGxpbWl0aW5nIG1l Y2hhbmlzbSBpcyBzdGlsbCBuZWNlc3NhcnkuICANCiAgICBUaGlzIGlzIGp1c3Qgb25lIGV4YW1w bGUgdG8gc2hvdyB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBhc3Nlc3MgdGhlIA0KICAgIHNlY3Vy aXR5IG5lZWRzIG9mIHRoZSBGb3JDRVMtZW5hYmxlZCBuZXR3b3JrIGVsZW1lbnRzIHVuZGVyIA0K ICAgIGRpZmZlcmVudCBkZXBsb3ltZW50IHNjZW5hcmlvcy4gIEl0IHNob3VsZCBiZSBwb3NzaWJs ZSBmb3IgdGhlIA0KICAgIGFkbWluaXN0cmF0b3IgdG8gY29uZmlndXJlIHRoZSBsZXZlbCBvZiBz ZWN1cml0eSBuZWVkZWQgZm9yIHRoZSANCiAgICBGb3JDRVMgcHJvdG9jb2wuIA0KICAgICANCiA4 LjIuMi4gVXNpbmcgVExTIHdpdGggRm9yQ0VTIA0KICAgICANCiAgICBUTFMgWzEzXSBjYW4gYmUg dXNlZCBpZiBhIHJlbGlhYmxlIHVuaWNhc3QgdHJhbnNwb3J0IHN1Y2ggYXMgVENQIG9yIA0KICAg IFNDVFAgaXMgdXNlZCBmb3IgRm9yQ0VTIG92ZXIgdGhlIEZwIGludGVyZmFjZS4gIFRoZSBUTFMg aGFuZHNoYWtlIA0KICAgIHByb3RvY29sIGlzIHVzZWQgZHVyaW5nIGFzc29jaWF0aW9uIGVzdGFi bGlzaG1lbnQgb3IgcmUtDQogICAgZXN0YWJsaXNobWVudCBwaGFzZSB0byBuZWdvdGlhdGUgYSBU TFMgc2Vzc2lvbiBiZXR3ZWVuIHRoZSBDRSBhbmQgDQogICAgRkUuICBPbmNlIHRoZSBzZXNzaW9u IGlzIGluIHBsYWNlLCB0aGUgVExTIHJlY29yZCBwcm90b2NvbCBpcyB1c2VkIA0KICAgIHRvIHNl Y3VyZSBGb3JDRVMgY29tbXVuaWNhdGlvbiBtZXNzYWdlcyBiZXR3ZWVuIHRoZSBDRSBhbmQgRkUu IA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBNYXJjaCAgICAyMDA0ICAgICAg ICAgICAgICAgICAgIFtQYWdlIDMzXSAgIA0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VT IEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMgDQogIA0KICANCiAgICAg DQogICAgQSBiYXNpYyBvdXRsaW5lIG9mIGhvdyBUTFMgY2FuIGJlIHVzZWQgd2l0aCBGb3JDRVMg aXMgZGVzY3JpYmVkIA0KICAgIGJlbG93LiAgU3RlcHMgMSkgdGlsbCA3KSBjb21wbGV0ZSB0aGUg c2VjdXJpdHkgaGFuZHNoYWtlIGFzIA0KICAgIGlsbHVzdHJhdGVkIGluIEZpZ3VyZSA5IHdoaWxl IHN0ZXAgOCkgaXMgZm9yIGFsbCB0aGUgZnVydGhlciANCiAgICBjb21tdW5pY2F0aW9uIGJldHdl ZW4gdGhlIENFIGFuZCBGRSwgaW5jbHVkaW5nIHRoZSByZXN0IG9mIG1lc3NhZ2VzIA0KICAgIGFm dGVyIHRoZSBzZWN1cml0eSBoYW5kc2hha2Ugc2hvd24gaW4gRmlndXJlIDkgYW5kIHRoZSBzdGVh ZHktc3RhdGUgDQogICAgY29tbXVuaWNhdGlvbiBzaG93biBpbiBGaWd1cmUgMTAuIA0KICAgICAN CiAgICAgICAgIDEpIER1cmluZyBQcmUtYXNzb2NpYXRpb24gcGhhc2UgYWxsIEZFcyBhcmUgY29u ZmlndXJlZCB3aXRoIA0KICAgICAgICAgdGhlIENFcyAoaW5jbHVkaW5nIGJvdGggdGhlIGFjdGl2 ZSBDRSBhbmQgdGhlIHN0YW5kYnkgQ0UpLiAgDQogICAgICAgICAyKSBUaGUgRkUgZXN0YWJsaXNo ZXMgYSBUTFMgY29ubmVjdGlvbiB3aXRoIHRoZSBDRSAobWFzdGVyKSANCiAgICAgICAgIGFuZCBu ZWdvdGlhdGVzIGEgY2lwaGVyIHN1aXRlLiANCiAgICAgICAgIDMpIFRoZSBGRSAoc2xhdmUpIGdl dHMgdGhlIENFIGNlcnRpZmljYXRlLCB2YWxpZGF0ZXMgdGhlIA0KICAgICAgICAgc2lnbmF0dXJl LCBjaGVja3MgdGhlIGV4cGlyYXRpb24gZGF0ZSwgY2hlY2tzIGlmIHRoZSANCiAgICAgICAgIGNl cnRpZmljYXRlIGhhcyBiZWVuIHJldm9rZWQuIA0KICAgICAgICAgNCkgVGhlIENFIChtYXN0ZXIp IGdldHMgdGhlIEZFIGNlcnRpZmljYXRlIGFuZCBwZXJmb3JtcyB0aGUgDQogICAgICAgICBzYW1l IHZhbGlkYXRpb24gYXMgdGhlIEZFIGluIHN0ZXAgMykuICANCiAgICAgICAgIDUpIElmIGFueSBv ZiB0aGUgY2hlY2sgZmFpbHMgaW4gc3RlcCAzKSBvciBzdGVwIDQpLCBlbmRwb2ludCANCiAgICAg ICAgIG11c3QgZ2VuZXJhdGUgYW4gZXJyb3IgbWVzc2FnZSBhbmQgYWJvcnQuIA0KICAgICAgICAg NikgQWZ0ZXIgc3VjY2Vzc2Z1bCBtdXR1YWwgYXV0aGVudGljYXRpb24sIGEgVExTIHNlc3Npb24g aXMgDQogICAgICAgICBlc3RhYmxpc2hlZCBiZXR3ZWVuIENFIGFuZCBGRS4gDQogICAgICAgICA3 KSBUaGUgRkUgc2VuZHMgYSAiam9pbiBORSIgbWVzc2FnZSB0byB0aGUgQ0UuICAgDQogICAgICAg ICA4KSBUaGUgRkUgYW5kIENFIHVzZSBUTFMgc2Vzc2lvbiBmb3IgZnVydGhlciBjb21tdW5pY2F0 aW9uLiANCiAgICAgDQogICAgTm90ZSB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyBmb3Ig dGhlIENFIGFuZCBGRSB0byB2YWxpZGF0ZSBhIA0KICAgIHJlY2VpdmVkIGNlcnRpZmljYXRlLiAg T25lIHdheSBpcyB0byBjb25maWd1cmUgdGhlIEZFIE1hbmFnZXIgb3IgQ0UgDQogICAgTWFuYWdl ciBvciBvdGhlciBjZW50cmFsIGNvbXBvbmVudCBhcyBDQSwgc28gdGhhdCB0aGUgQ0Ugb3IgRkUg Y2FuIA0KICAgIHF1ZXJ5IHRoaXMgcHJlLWNvbmZpZ3VyZWQgQ0EgdG8gdmFsaWRhdGUgdGhhdCB0 aGUgY2VydGlmaWNhdGUgaGFzIA0KICAgIG5vdCBiZWVuIHJldm9rZWQuICBBbm90aGVyIHdheSBp cyB0byBoYXZlIHRoZSBDRSBhbmQgdGhlIEZFIA0KICAgIGNvbmZpZ3VyZWQgZGlyZWN0bHkgYSBs aXN0IG9mIHZhbGlkIGNlcnRpZmljYXRlcyBpbiB0aGUgcHJlLQ0KICAgIGFzc29jaWF0aW9uIHBo YXNlLiAgDQogICAgIA0KICAgIEluIHRoZSBjYXNlIG9mIGZhaWwtb3ZlciwgaXQgaXMgdGhlIHJl c3BvbnNpYmlsaXR5IG9mIHRoZSBhY3RpdmUgQ0UgDQogICAgYW5kIHRoZSBzdGFuZGJ5IENFIHRv IHN5bmNocm9uaXplIEZvckNFUyBzdGF0ZXMgaW5jbHVkaW5nIHRoZSBUTFMgDQogICAgc3RhdGVz IHRvIG1pbmltaXplIHRoZSBzdGF0ZSByZWVzdGFibGlzaG1lbnQgZHVyaW5nIGZhaWwtb3Zlci4g IA0KICAgIENhcmUgbXVzdCBiZSB0YWtlbiB0byBlbnN1cmUgdGhhdCB0aGUgc3RhbmRieSBDRSBp cyBhbHNvIA0KICAgIGF1dGhlbnRpY2F0ZWQgaW4gdGhlIHNhbWUgd2F5IGFzIHRoZSBhY3RpdmUg Q0UsIGVpdGhlciBiZWZvcmUgb3IgDQogICAgZHVyaW5nIHRoZSBmYWlsLW92ZXIuIA0KICANCiA4 LjIuMy4gVXNpbmcgSVBzZWMgd2l0aCBGb3JDRVMgDQogICAgIA0KICAgIElQc2VjIFsxNF0gY2Fu IGJlIHVzZWQgd2l0aCBhbnkgdHJhbnNwb3J0IHByb3RvY29sLCBzdWNoIGFzIFVEUCwgDQogICAg U0NUUCBhbmQgVENQIG92ZXIgRnAgaW50ZXJmYWNlIGZvciBGb3JDRVMuICBXaGVuIHVzaW5nIElQ c2VjLCB3ZSANCiAgICByZWNvbW1lbmQgdXNpbmcgRVNQIGluIHRyYW5zcG9ydCBtb2RlIGZvciBG b3JDRVMgYmVjYXVzZSBtZXNzYWdlIA0KICAgIGNvbmZpZGVudGlhbGl0eSBpcyByZXF1aXJlZCBm b3IgRm9yQ0VTLiAgDQogICAgIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBN YXJjaCAgICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDM0XSAgIA0KIEludGVybmV0IERy YWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIw MDMgDQogIA0KICANCiAgICBJUHNlYyBjYW4gYmUgdXNlZCB3aXRoIGJvdGggbWFudWFsIGFuZCBh dXRvbWF0ZWQgU0EgYW5kIA0KICAgIGNyeXB0b2dyYXBoaWMga2V5IG1hbmFnZW1lbnQuICBCdXQg SXBzZWMncyByZXBsYXkgcHJvdGVjdGlvbiANCiAgICBtZWNoYW5pc21zIGFyZSBub3QgYXZhaWxh YmxlIGlmIG1hbnVhbCBrZXkgbWFuYWdlbWVudCBpcyB1c2VkLiAgDQogICAgSGVuY2UsIGF1dG9t YXRpYyBrZXkgbWFuYWdlbWVudCBpcyByZWNvbW1lbmRlZCBpZiByZXBsYXkgcHJvdGVjdGlvbiAN CiAgICBpcyBkZWVtZWQgaW1wb3J0YW50LiAgT3RoZXJ3aXNlLCBtYW51YWwga2V5IG1hbmFnZW1l bnQgbWlnaHQgYmUgDQogICAgc3VmZmljaWVudCBmb3Igc29tZSBkZXBsb3ltZW50IHNjZW5hcmlv cywgZXNwLiB3aGVuIHRoZSBudW1iZXIgb2YgDQogICAgQ0VzIGFuZCBGRXMgaXMgcmVsYXRpdmVs eSBzbWFsbC4gIEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIGtleXMgDQogICAgYmUgY2hhbmdl ZCBwZXJpb2RpY2FsbHkgZXZlbiBmb3IgbWFudWFsIGtleSBtYW5hZ2VtZW50LiANCiAgICAgDQog ICAgSVBzZWMgY2FuIHN1cHBvcnQgYm90aCB1bmljYXN0IGFuZCBtdWx0aWNhc3QgdHJhbnNwb3J0 LiBBdCB0aGUgdGltZSANCiAgICB0aGlzIGRvY3VtZW50IHdhcyBwdWJsaXNoZWQsIE1TRUMgd29y a2luZyBncm91cCBpcyBhY3RpdmVseSB3b3JraW5nIA0KICAgIG9uIHN0YW5kYXJkaXppbmcgcHJv dG9jb2xzIHRvIHByb3ZpZGUgbXVsdGljYXN0IHNlY3VyaXR5IFsxN10uIA0KICAgIE11bHRpY2Fz dC1iYXNlZCBzb2x1dGlvbnMgcmVseWluZyBvbiBJUHNlYyBzaG91bGQgc3BlY2lmeSBob3cgdG8g DQogICAgbWVldCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGluIFszXS4gIA0KICAgICANCiAg ICBVbmxpa2UgVExTLCBJUHNlYyBwcm92aWRlcyBzZWN1cml0eSBzZXJ2aWNlcyBiZXR3ZWVuIHRo ZSBDRSBhbmQgRkUgDQogICAgYXQgSVAgbGV2ZWwsIGFuZCBzbyB0aGUgc2VjdXJpdHkgaGFuZHNo YWtlIGFzIGlsbHVzdHJhdGVkIGluIEZpZ3VyZSANCiAgICA5IGFtb3VudHMgdG8gYSAibm8tb3Ai IHdoZW4gbWFudWFsIGtleSBtYW5hZ2VtZW50IGlzIHVzZWQuICBUaGUgDQogICAgZm9sbG93aW5n IG91dGxpbmUgdGhlIHN0ZXBzIHRha2VuIGZvciBGb3JDRVMgaW4gc3VjaCBhIGNhc2UuIA0KICAg ICANCiAgICAgICAgIDEpIER1cmluZyBQcmUtYXNzb2NpYXRpb24gcGhhc2UgYWxsIEZFcyBhcmUg Y29uZmlndXJlZCB3aXRoIA0KICAgICAgICAgdGhlIENFcyAoaW5jbHVkaW5nIGFjdGl2ZSBDRSBh bmQgc3RhbmRieSBDRSkgYW5kIFNBIHBhcmFtZXRlcnMgDQogICAgICAgICBtYW51YWxseS4gDQog ICAgICAgICAyKSBUaGUgRkUgc2VuZHMgYSAiam9pbiBORSIgbWVzc2FnZSB0byB0aGUgQ0UuICBU aGlzIG1lc3NhZ2UgDQogICAgICAgICBhbmQgYWxsIG90aGVycyB0aGF0IGZvbGxvdyBhcmUgYWZm b3JkZWQgc2VjdXJpdHkgc2VydmljZSANCiAgICAgICAgIGFjY29yZGluZyB0byB0aGUgbWFudWFs bHkgY29uZmlndXJlZCBJUHNlYyBTQSBwYXJhbWV0ZXJzLCBidXQgDQogICAgICAgICByZXBsYXkg cHJvdGVjdGlvbiBpcyBub3QgYXZhaWxhYmxlLiAgDQogICAgIA0KICAgIEl0IGlzIHVwIHRvIHRo ZSBhZG1pbmlzdHJhdG9yIHRvIGRlY2lkZSB3aGV0aGVyIHRvIHNoYXJlIHRoZSBzYW1lIA0KICAg IGtleSBhY3Jvc3MgbXVsdGlwbGUgRkUtQ0UgY29tbXVuaWNhdGlvbiwgYnV0IGl0IGlzIHJlY29t bWVuZGVkIHRoYXQgDQogICAgZGlmZmVyZW50IGtleXMgYmUgdXNlZC4gIFNpbWlsYXJseSwgaXQg aXMgcmVjb21tZW5kZWQgdGhhdCANCiAgICBkaWZmZXJlbnQga2V5cyBiZSB1c2VkIGZvciBpbmJv dW5kIGFuZCBvdXRib3VuZCB0cmFmZmljLiANCiAgDQogICAgSWYgYXV0b21hdGljIGtleSBtYW5h Z2VtZW50IGlzIG5lZWRlZCwgSUtFIFsxNV0gY2FuIGJlIHVzZWQgZm9yIA0KICAgIHRoYXQgcHVy cG9zZS4gT3RoZXIgYXV0b21hdGljIGtleSBkaXN0cmlidXRpb24gdGVjaG5pcXVlcyBzdWNoIGFz IA0KICAgIEtlcmJlcm9zIG1heSBiZSB1c2VkIGFzIHdlbGwuICAgVGhlIGtleSBleGNoYW5nZSBw cm9jZXNzIA0KICAgIGNvbnN0aXR1dGVzIHRoZSBzZWN1cml0eSBoYW5kc2hha2UgYXMgaWxsdXN0 cmF0ZWQgaW4gRmlndXJlIDkuICBUaGUgDQogICAgZm9sbG93aW5nIHNob3dzIHRoZSBzdGVwcyBp bnZvbHZlZCBpbiB1c2luZyBJS0Ugd2l0aCBJUHNlYyBmb3IgDQogICAgRm9yQ0VTLiAgU3RlcHMg MSkgdG8gNikgY29uc3RpdHV0ZSB0aGUgc2VjdXJpdHkgaGFuZHNoYWtlIGluIEZpZ3VyZSANCiAg ICA5LiANCiAgICAgDQogICAgICAgICAxKSBEdXJpbmcgUHJlLWFzc29jaWF0aW9uIHBoYXNlIGFs bCBGRXMgYXJlIGNvbmZpZ3VyZWQgd2l0aCANCiAgICAgICAgIHRoZSBDRXMgKGluY2x1ZGluZyBh Y3RpdmUgQ0UgYW5kIHN0YW5kYnkgQ0UpLCBJUHNlYyBwb2xpY3kgDQogICAgICAgICBldGMuIA0K ICAgICAgICAgMikgVGhlIEZFIGtpY2tzIG9mZiBJS0UgcHJvY2VzcyBhbmQgdHJpZXMgdG8gZXN0 YWJsaXNoIGFuIA0KICAgICAgICAgSVBzZWMgU0Egd2l0aCB0aGUgQ0UgKG1hc3RlcikuICBUaGUg RkUgKFNsYXZlKSBnZXRzIHRoZSBDRSANCiAgICAgICAgIGNlcnRpZmljYXRlIGFzIHBhcnQgb2Yg dGhlIElLRSBuZWdvdGlhdGlvbi4gIFRoZSBGRSB2YWxpZGF0ZXMgDQogIA0KICANCiBZYW5nLCBl dCBhbC4gICAgICBFeHBpcmVzIE1hcmNoICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MzVdICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAg ICAgICAgICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0KICAgICAgICAgc2lnbmF0dXJlLCBjaGVj a3MgdGhlIGV4cGlyYXRpb24gZGF0ZSwgY2hlY2tzIGlmIHRoZSANCiAgICAgICAgIGNlcnRpZmlj YXRlIGhhcyBiZWVuIHJldm9rZWQuIA0KICAgICAgICAgMykgVGhlIENFIChtYXN0ZXIpIGdldHMg dGhlIEZFIGNlcnRpZmljYXRlIGFuZCBwZXJmb3JtcyB0aGUgDQogICAgICAgICBzYW1lIGNoZWNr IGFzIHRoZSBGRSBpbiBzdGVwIDIpLiANCiAgICAgICAgIDQpIElmIGFueSBvZiB0aGUgY2hlY2sg ZmFpbHMgaW4gc3RlcCAyKSBvciBzdGVwIDMpLCB0aGUgDQogICAgICAgICBlbmRwb2ludCBtdXN0 IGdlbmVyYXRlIGFuIGVycm9yIG1lc3NhZ2UgYW5kIGFib3J0LiANCiAgICAgICAgIDUpIEFmdGVy IHN1Y2Nlc3NmdWwgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBJUHNlYyBzZXNzaW9uIGlzIA0KICAg ICAgICAgZXN0YWJsaXNoZWQgYmV0d2VlbiB0aGUgQ0UgYW5kIEZFLiANCiAgICAgICAgIDYpIFRo ZSBGRSBzZW5kcyBhICJqb2luIE5FIiBtZXNzYWdlIHRvIENFLiAgTm8gU0FEQiBlbnRyeSBpcyAN CiAgICAgICAgIGNyZWF0ZWQgaW4gRkUgeWV0LiANCiAgICAgICAgIDcpIFRoZSBGRSBhbmQgQ0Ug dXNlIHRoZSBJUHNlYyBzZXNzaW9uIGZvciBmdXJ0aGVyIA0KICAgICAgICAgY29tbXVuaWNhdGlv bi4gDQogICAgICANCiAgICBGRSBNYW5hZ2VyIG9yIENFIE1hbmFnZXIgb3Igb3RoZXIgY2VudHJh bCBjb21wb25lbnQgY2FuIGJlIHVzZWQgYXMgDQogICAgQ0EgZm9yIHZhbGlkYXRpbmcgQ0UgYW5k IEZFIGNlcnRpZmljYXRlcyBkdXJpbmcgdGhlIElLRSBwcm9jZXNzLiAgIA0KICAgIEFsdGVybmF0 aXZlbHksIGR1cmluZyB0aGUgcHJlLWFzc29jaWF0aW9uIHBoYXNlLCB0aGUgQ0UgYW5kIEZFIGNh biANCiAgICBiZSBjb25maWd1cmVkIGRpcmVjdGx5IHdpdGggdGhlIHJlcXVpcmVkIGluZm9ybWF0 aW9uIHN1Y2ggYXMgDQogICAgY2VydGlmaWNhdGVzIG9yIHBhc3N3b3JkcyBldGMgZGVwZW5kaW5n IHVwb24gdGhlIHR5cGUgb2YgDQogICAgYXV0aGVudGljYXRpb24gdGhhdCBhZG1pbmlzdHJhdG9y IHdhbnRzIHRvIGNvbmZpZ3VyZS4gIA0KICAgICAgICAgIA0KICAgIEluIHRoZSBjYXNlIG9mIGZh aWwtb3ZlciwgaXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGFjdGl2ZSBDRSBhbmQgDQogICAg c3RhbmRieSBDRSB0byBzeW5jaHJvbml6ZSBGb3JDRVMgc3RhdGVzIGFuZCBJUHNlYyBzdGF0ZXMg dG8gDQogICAgbWluaW1pemUgdGhlIHN0YXRlIHJlZXN0YWJsaXNobWVudCBkdXJpbmcgZmFpbC1v dmVyLiAgDQogICAgQWx0ZXJuYXRpdmVseSwgdGhlIEZFIG5lZWRzIHRvIGVzdGFibGlzaCBkaWZm ZXJlbnQgSVBzZWMgU0EgZHVyaW5nIA0KICAgIHRoZSBzdGFydHVwIG9wZXJhdGlvbiBpdHNlbGYg d2l0aCBlYWNoIENFLiAgVGhpcyB3aWxsIG1pbmltaXplIHRoZSANCiAgICBwZXJpb2RpYyBzdGF0 ZSB0cmFuc2ZlciBhY3Jvc3MgSVBzZWMgbGF5ZXIgdGhvdWdoIEZyIChDRS1DRSkgDQogICAgSW50 ZXJmYWNlLiAgDQogICAgIA0KIDkuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICANCiAgICBbMV0g QmFrZXIsIEYuLCAiUmVxdWlyZW1lbnRzIGZvciBJUCBWZXJzaW9uIDQgUm91dGVycyIsIFJGQyAx ODEyLCANCiAgICBKdW5lIDE5OTUuIA0KICAgICANCiAgICBbMl0gRmxveWQsIFMuLCAiQ29uZ2Vz dGlvbiBDb250cm9sIFByaW5jaXBsZXMiLCBSRkMgMjkxNCwgU2VwdGVtYmVyIA0KICAgIDIwMDAu IA0KICAgICANCiAgICBbM10gS2hvc3JhdmksIEguIGV0IGFsLiwgIlJlcXVpcmVtZW50cyBmb3Ig U2VwYXJhdGlvbiBvZiBJUCBDb250cm9sIA0KICAgIGFuZCBGb3J3YXJkaW5nIiwgd29yayBpbiBw cm9ncmVzcywgTWF5IDIwMDMsIDxkcmFmdC1pZXRmLWZvcmNlcy0NCiAgICByZXF1aXJlbWVudHMt MDkudHh0Pi4gDQogICAgIA0KIDEwLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgICANCiAg ICBbNF0gQ2FzZSwgSi4sIGV0IGFsLiwgIkEgU2ltcGxlIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90 b2NvbCANCiAgICAoU05NUCkiLCBSRkMgMTE1NywgTWF5IDE5OTAuIA0KICAgICANCiAgICBbNV0g RGFuaWVsZSwgTS4gZXQgYWwuLCAiQWdlbnQgRXh0ZW5zaWJpbGl0eSAoQWdlbnRYKSBQcm90b2Nv bCANCiAgICBWZXJzaW9uIDEiLCBSRkMgMjc0MSwgSmFudWFyeSAyMDAwLiANCiAgDQogIA0KIFlh bmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgTWFyY2ggICAgMjAwNCAgICAgICAgICAgICAgICAgICBb UGFnZSAzNl0gICANCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGcmFtZXdvcmsgICAg ICAgICAgICAgICAgIFNlcHRlbWJlciAyMDAzIA0KICANCiAgDQogICAgIA0KICAgIFs2XSBDaGFu LCBLLiBldCBhbC4sICJDT1BTIFVzYWdlIGZvciBQb2xpY3kgUHJvdmlzaW9uaW5nIChDT1BTLQ0K ICAgIFBSKSIsIFJGQyAzMDg0LCBNYXJjaCAyMDAxLiANCiAgICAgDQogICAgWzddIENyb3VjaCwg QS4gZXQgYWwuLCAiRm9yQ0VTIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50Iiwgd29yayBpbiANCiAg ICBwcm9ncmVzcywgSnVuZSAyMDAyLCA8ZHJhZnQtaWV0Zi1mb3JjZXMtYXBwbGljYWJpbGl0eS0w MC50eHQ+LiANCiAgICAgDQogICAgWzhdIEFuZGVyc29uLCBULiBhbmQgSi4gQnVlcmtsZSwgIlJl cXVpcmVtZW50cyBmb3IgdGhlIER5bmFtaWMgDQogICAgUGFydGl0aW9uaW5nIG9mIFN3aXRjaGlu ZyBFbGVtZW50cyIsIFJGQyAzNTMyLCBNYXkgMjAwMy4gDQogICAgIA0KICAgIFs5XSBMZWVsYW5p dmFzLCBNLiBldCBhbC4sICJHcmFjZWZ1bCBSZXN0YXJ0IE1lY2hhbmlzbSBmb3IgTGFiZWwgDQog ICAgRGlzdHJpYnV0aW9uIFByb3RvY29sIiwgUkZDIDM0NzgsIEZlYnJ1YXJ5IDIwMDMuIA0KICAg ICANCiAgICBbMTBdIE1veSwgSi4gZXQgYWwuLCAiR3JhY2VmdWwgT1NQRiBSZXN0YXJ0Iiwgd29y ayBpbiBwcm9ncmVzcywgDQogICAgTWFyY2ggMjAwMywgPGRyYWZ0LWlldGYtb3NwZi1oaXRsZXNz LXJlc3RhcnQtMDcudHh0Pi4gDQogICAgIA0KICAgIFsxMV0gU2FuZ2xpLCBTLiBldCBhbC4sICJH cmFjZWZ1bCBSZXN0YXJ0IE1lY2hhbmlzbSBmb3IgQkdQIiwgd29yayANCiAgICBpbiBwcm9ncmVz cywgSmFudWFyeSAyMDAzLCA8IGRyYWZ0LWlldGYtaWRyLXJlc3RhcnQtMDYudHh0Pi4gDQogICAg IA0KICAgIFsxMl0gU2hhbmQsIE0uIGFuZCBMLiBHaW5zYmVyZywgIlJlc3RhcnQgU2lnbmFsaW5n IGZvciBJUy1JUyIsIHdvcmsgDQogICAgaW4gcHJvZ3Jlc3MsIE1hcmNoIDIwMDMsIDxkcmFmdC1p ZXRmLWlzaXMtcmVzdGFydC0wMy50eHQ+LiANCiAgICAgDQogICAgWzEzXSBEaWVya3MsIFQuIGFu ZCBDLiBBbGxlbiwgIlRoZSBUTFMgUHJvdG9jb2wsIHZlcnNpb24gMS4wIiwgUkZDIA0KICAgIDIy NDYsIEphbnVhcnkgMTk5OS4gDQogICAgIA0KICAgIFsxNF0gS2VudCwgUy4gYW5kIFIuIEF0a2lu c29uLCAiU2VjdXJpdHkgQXJjaGl0ZWN0dXJlIGZvciB0aGUgDQogICAgSW50ZXJuZXQgUHJvdG9j b2wiLCBSRkMgMjQwMSwgTm92ZW1iZXIgMTk5OC4gDQogICAgIA0KICAgIFsxNV0gSGFya2lucywg RC4gYW5kIEQuIENhcnJlbCwgIlRoZSBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgKElLRSkgIiwgDQog ICAgUkZDIDI0MDksIE5vdmVtYmVyIDE5OTguIA0KICAgICANCiAgICBbMTZdIEJlbGxvdmluLCBT LiwgIkd1aWRlbGluZXMgZm9yIE1hbmRhdGluZyB0aGUgVXNlIG9mIElwc2VjIiwgDQogICAgd29y ayBpbiBwcm9ncmVzcywgT2N0b2JlciAyMDAyLCA8ZHJhZnQtYmVsbG92aW4tdXNlaXBzZWMtMDAu dHh0Pi4gDQogICAgIA0KICAgIFsxN10gSGFyZGpvbm8sIFQuIGFuZCBXZWlzLCBCLiAiVGhlIE11 bHRpY2FzdCBTZWN1cml0eSANCiAgICBBcmNoaXRlY3R1cmUiLCB3b3JrIGluIHByb2dyZXNzLCBB dWd1c3QgMjAwMywgPGRyYWZ0LWlldGYtbXNlYy0NCiAgICBhcmNoLTAzLnR4dD4uIA0KICAgICAN CiAxMS4gQXV0aG9ycycgQWRkcmVzc2VzIA0KICANCiAgICBMLiBMaWx5IFlhbmcgDQogICAgSW50 ZWwgQ29ycC4sIE1TIEpGMy0yMDYsIA0KICAgIDIxMTEgTkUgMjV0aCBBdmVudWUgDQogICAgSGls bHNib3JvLCBPUiA5NzEyNCwgVVNBIA0KICAgIFBob25lOiArMSA1MDMgMjY0IDg4MTMgDQogICAg RW1haWw6IGxpbHkubC55YW5nQGludGVsLmNvbSANCiAgICAgDQogIA0KICANCiBZYW5nLCBldCBh bC4gICAgICBFeHBpcmVzIE1hcmNoICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMzdd ICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAg ICAgICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0KICAgIFJhbSBEYW50dSANCiAgICBEZXBhcnRt ZW50IG9mIENvbXB1dGVyIFNjaWVuY2UsIA0KICAgIFVuaXZlcnNpdHkgb2YgTm9ydGggVGV4YXMs IA0KICAgIERlbnRvbiwgVFggNzYyMDMsIFVTQSANCiAgICBQaG9uZTogKzEgOTQwIDU2NSAyODIy IA0KICAgIEVtYWlsOiByZGFudHVAdW50LmVkdSANCiAgDQogICAgVG9kZCBBLiBBbmRlcnNvbiAN CiAgICBJbnRlbCBDb3JwLiANCiAgICAyMTExIE5FIDI1dGggQXZlbnVlIA0KICAgIEhpbGxzYm9y bywgT1IgOTcxMjQsIFVTQSANCiAgICBQaG9uZTogKzEgNTAzIDcxMiAxNzYwIA0KICAgIEVtYWls OiB0b2RkLmEuYW5kZXJzb25AaW50ZWwuY29tIA0KICAgICANCiAgICBSYW0gR29wYWwgDQogICAg Tm9raWEgUmVzZWFyY2ggQ2VudGVyIA0KICAgIDUsIFdheXNpZGUgUm9hZCwgDQogICAgQnVybGlu Z3RvbiwgTUEgMDE4MDMsIFVTQSANCiAgICBQaG9uZTogKzEgNzgxIDk5MyAzNjg1IA0KICAgIEVt YWlsOiByYW0uZ29wYWxAbm9raWEuY29tIA0KICAgICANCiAgDSAxMi4gSW50ZWxsZWN0dWFsIFBy b3BlcnR5IFJpZ2h0IA0KICAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0 aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55IA0KICAgIGludGVsbGVjdHVhbCBwcm9wZXJ0eSBv ciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvIA0KICAgIHBlcnRhaW4gdG8g dGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4g DQogICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVu ZGVyIHN1Y2ggcmlnaHRzIA0KICAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5l aXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCANCiAgICBoYXMgbWFkZSBhbnkgZWZmb3J0 IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uIG9uIA0KICAgIHRoZSBJ RVRGJ3MgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIHN0YW5kYXJkcy10cmFj ayBhbmQgDQogICAgc3RhbmRhcmRzLXJlbGF0ZWQgZG9jdW1lbnRhdGlvbiBjYW4gYmUgZm91bmQg aW4gUkZDIDIwMjYuICBDb3BpZXMgDQogICAgb2YgY2xhaW1zIG9mIHJpZ2h0cyBtYWRlIGF2YWls YWJsZSBmb3IgcHVibGljYXRpb24gYW5kIGFueSANCiAgICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2Vz IHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuIA0KICAgIGF0dGVtcHQg bWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVz ZSANCiAgICBvZiBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRvcnMgb3IgdXNl cnMgb2YgdGhpcyANCiAgICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJ RVRGIFNlY3JldGFyaWF0LiANCiAgICAgDQogICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJl c3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueSANCiAgICBjb3B5cmlnaHRz LCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5IA0K ICAgIHJpZ2h0cyB3aGljaCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJl ZCB0byBwcmFjdGljZSANCiAgICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGlu Zm9ybWF0aW9uIHRvIHRoZSBJRVRGIA0KICAgIEV4ZWN1dGl2ZSBEaXJlY3Rvci4gDQogICAgIA0K IDEzLiBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQgDQogICAgICAgIA0KICAgIENvcHlyaWdodCAo QykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDMpLiBBbGwgUmlnaHRzIFJlc2VydmVkLiANCiAg ICAgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIE1hcmNoICAgIDIwMDQgICAg ICAgICAgICAgICAgICAgW1BhZ2UgMzhdICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JD RVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMyANCiAgDQogIA0KICAg IFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBm dXJuaXNoZWQgdG8gDQogICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1l bnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gDQogICAgaXQgb3IgYXNzaXN0IGluIGl0cyBpbXBs ZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgDQogICAgcHVibGlzaGVkIGFuZCBk aXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiANCiAg ICBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBh bmQgdGhpcyANCiAgICBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBh bmQgZGVyaXZhdGl2ZSB3b3Jrcy4gIA0KICAgIEhvd2V2ZXIsIHRoaXMgZG9jdW1lbnQgaXRzZWxm IG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwgc3VjaCANCiAgICBhcyBieSByZW1vdmlu ZyB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCANCiAg ICBTb2NpZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVk ZWQgZm9yIHRoZSANCiAgICBwdXJwb3NlIG9mIGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRz IGluIHdoaWNoIGNhc2UgdGhlIA0KICAgIHByb2NlZHVyZXMgZm9yIGNvcHlyaWdodHMgZGVmaW5l ZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgDQogICAgbXVzdCBiZSBmb2xsb3dl ZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2VzIA0KICAgIG90 aGVyIHRoYW4gRW5nbGlzaC4gDQogICAgIA0KICAgIFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdy YW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3QgYmUgDQogICAgcmV2b2tlZCBi eSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBvciBhc3NpZ25zLiANCiAg ICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBw cm92aWRlZCBvbiANCiAgICBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVU WSBBTkQgVEhFIElOVEVSTkVUIA0KICAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU1T IEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIA0KICAgIElNUExJRUQsIElOQ0xVRElORyBCVVQg Tk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiANCiAgICBUSEUgSU5G T1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJ RUQgDQogICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQ QVJUSUNVTEFSIFBVUlBPU0UuIiANCiAgICAgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBF eHBpcmVzIE1hcmNoICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMzldICAg ------_=_NextPart_001_01C382D8.BC11903A-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 25 12:18:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03216 for ; Thu, 25 Sep 2003 12:18:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Yp6-0000lm-00 for forces-archive@IETF.ORG; Thu, 25 Sep 2003 12:18:32 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2Yp5-0000li-00 for forces-archive@IETF.ORG; Thu, 25 Sep 2003 12:18:31 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00BE5F41@cherry.ease.lsoft.com>; Thu, 25 Sep 2003 12:18:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56032936 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 25 Sep 2003 12:18:18 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Sep 2003 12:08:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02614; Thu, 25 Sep 2003 12:08:07 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200309251608.MAA02614@ietf.org> Date: Thu, 25 Sep 2003 12:08:06 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-framework-09.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : Forwarding and Control Element Separation (ForCES) Framework Author(s) : L. Yang et al. Filename : draft-ietf-forces-framework-09.txt Pages : 39 Date : 2003-9-25 This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and the interaction among them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-forces-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-forces-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: <2003-9-25104814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-framework-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-framework-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-25104814.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Sep 25 23:39:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05798 for ; Thu, 25 Sep 2003 23:39:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2jSB-0002od-00 for forces-archive@IETF.ORG; Thu, 25 Sep 2003 23:39:35 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2jSB-0002oa-00 for forces-archive@IETF.ORG; Thu, 25 Sep 2003 23:39:35 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00BE75A6@cherry.ease.lsoft.com>; Thu, 25 Sep 2003 23:39:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56092169 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 25 Sep 2003 23:39:34 -0400 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Sep 2003 23:39:34 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8Q3Yda29809 for ; Fri, 26 Sep 2003 03:34:40 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.py.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8Q3d6h20150 for ; Fri, 26 Sep 2003 03:39:07 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092520393307093 for ; Thu, 25 Sep 2003 20:39:33 -0700 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 25 Sep 2003 20:39:33 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Issue Summary: Inter-FE Topology requirements Thread-Index: AcOBxXmpYziFwQwxQWKNuwdpFMPpMgAC4t5Q X-OriginalArrivalTime: 26 Sep 2003 03:39:33.0841 (UTC) FILETIME=[CD18DC10:01C383DF] Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F4F2@orsmsx409.jf.intel.com> Date: Thu, 25 Sep 2003 20:39:33 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Issue Summary: Inter-FE Topology requirements To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable All, Thanks for the discussion on the topic of inter-FE topology. There are two sections of the requirements document that have=20 caused discussion here - Section 5 #10, which is an=20 architectural requirement, and Section 7 #10, which is a=20 protocol requirement. =20 Patrick & I have followed the list discussion and conferred=20 with the ADs. We suggest resolving this issue as follows: Issue #1: The architecture requirement (S5#10) says that FE's=20 must be able to provide to CEs the topology by which the FEs=20 in the NE are connected. We suggest rolling this back to=20 what the requirement was in requirements-01: 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by which the FEs in the NE are connected. This is suggested because it is possible for CEs to learn=20 topology information without the FEs having to provide it, and there are real systems that operate in such a fashion. Issue #2: The protocol requirement (S7#10) says that the ForCES=20 protocol must provide a mechanism to carry inter-FE topology=20 info to the CE. Given the resolution to issue#1, it is clear that a mechanism to deliver topology information is not always used in the Fp reference point (because the element providing topology information might not be a FE). As such, we recommend changing S7#10 from a MUST to a MAY. If a protocol author=20 believes that topology information is sufficiently important,=20 then they may include it in their protocol. However, if a protocol author believes it is not necessary then they may omit it. It will be up to the WG as a whole to determine during protocol selection the incremental value from including such mechanisms (for those protocols that choose to do so). Finally, there is also a procedural issue, in that this document is in the RFC editor's queue and as such it is a strange time to be changing the contents. Patrick & I believe the necessary changes can be made during the author's 48 hour=20 period, which has not started yet. We believe that the above recommendations are consistent with the statements and general consensus of the list.=20 If anyone has an objection to this resolution, or would like to suggest different replacement text, please make this known. Thanks, David and Patrick From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 26 00:16:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07016 for ; Fri, 26 Sep 2003 00:16:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2k20-0003G4-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 00:16:36 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2k1z-0003G1-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 00:16:35 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00BE75CE@cherry.ease.lsoft.com>; Fri, 26 Sep 2003 0:16:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56102711 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 00:16:35 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 26 Sep 2003 00:16:35 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 1A2k1y-000N4m-LR for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 04:16:34 +0000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Approved-By: Avri Doria Message-ID: <059BE7D0-EFD8-11D7-81AB-000393CC2112@acm.org> Date: Fri, 26 Sep 2003 13:15:11 +0900 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: Issue Summary: Inter-FE Topology requirements To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F4F2@orsmsx409.jf.intel.com> Precedence: list Content-Transfer-Encoding: 7bit I am fine with the first change (architecture) but uncomfortable with the second (protocol). I believe the protocol, as designed, should be able to carry. That would the protocol requirement. I believe it may or may not be called on to do so. That is an implementation detail. a. On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote: > All, > > Thanks for the discussion on the topic of inter-FE topology. > There are two sections of the requirements document that have > caused discussion here - Section 5 #10, which is an > architectural requirement, and Section 7 #10, which is a > protocol requirement. > > Patrick & I have followed the list discussion and conferred > with the ADs. We suggest resolving this issue as follows: > > Issue #1: The architecture requirement (S5#10) says that FE's > must be able to provide to CEs the topology by which the FEs > in the NE are connected. We suggest rolling this back to > what the requirement was in requirements-01: > > 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by > which the FEs in the NE are connected. > > This is suggested because it is possible for CEs to learn > topology information without the FEs having to provide > it, and there are real systems that operate in such a fashion. > > > Issue #2: The protocol requirement (S7#10) says that the ForCES > protocol must provide a mechanism to carry inter-FE topology > info to the CE. Given the resolution to issue#1, it is clear > that a mechanism to deliver topology information is not always > used in the Fp reference point (because the element providing > topology information might not be a FE). As such, we recommend > changing S7#10 from a MUST to a MAY. If a protocol author > believes that topology information is sufficiently important, > then they may include it in their protocol. However, > if a protocol author believes it is not necessary then they may > omit it. It will be up to the WG as a whole to determine during > protocol selection the incremental value from including such > mechanisms (for those protocols that choose to do so). > > Finally, there is also a procedural issue, in that this document > is in the RFC editor's queue and as such it is a strange > time to be changing the contents. Patrick & I believe the > necessary changes can be made during the author's 48 hour > period, which has not started yet. > > We believe that the above recommendations are consistent > with the statements and general consensus of the list. > If anyone has an objection to this resolution, or would like > to suggest different replacement text, please make this known. > > Thanks, > David and Patrick > From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 26 13:37:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14991 for ; Fri, 26 Sep 2003 13:37:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2wXI-0003bU-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 13:37:44 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2wXH-0003bG-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 13:37:44 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00BE8518@cherry.ease.lsoft.com>; Fri, 26 Sep 2003 13:37:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56169898 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 13:37:34 -0400 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 26 Sep 2003 13:37:33 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8QHWcl28831 for ; Fri, 26 Sep 2003 17:32:38 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.py.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8QHb5j28520 for ; Fri, 26 Sep 2003 17:37:05 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092610373220837 for ; Fri, 26 Sep 2003 10:37:32 -0700 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 26 Sep 2003 10:37:32 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) Thread-Index: AcOD5PyOjn8ywXOJTlG51O5ZaL6tcAAZz3mw X-OriginalArrivalTime: 26 Sep 2003 17:37:32.0062 (UTC) FILETIME=[DD408BE0:01C38454] Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD881F506@orsmsx409.jf.intel.com> Date: Fri, 26 Sep 2003 10:37:31 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable All, It appears that there is some concern around the second of the two recommendations made, specifically to change the MUST to a MAY in the protocol requirement to provide=20 a method to deliver inter-FE topology information from=20 FEs to CEs. Patrick & I would like to do an explicit consensus call on this matter to settle the question. Please=20 send a note to the list stating one of the following: * Retain original text The ForCES protocol MUST allow the FEs to provide their topology=20 information (topology by which the FEs in the NE are connected) to=20 the CE(s). (refer to section 5, requirement# 10) * Replace MUST with MAY in original text The ForCES protocol MAY allow the FEs to provide their topology=20 information (topology by which the FEs in the NE are connected) to=20 the CE(s). (refer to section 5, requirement# 10) * Some other alternative (please provide text). Thanks, David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria Sent: Thursday, September 25, 2003 9:15 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Issue Summary: Inter-FE Topology requirements I am fine with the first change (architecture) but uncomfortable with the second (protocol). I believe the protocol, as designed, should be able to carry. That would the protocol requirement. I believe it may or may not be called on to do so. That is an implementation detail. a. On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote: > All, > > Thanks for the discussion on the topic of inter-FE topology. > There are two sections of the requirements document that have > caused discussion here - Section 5 #10, which is an > architectural requirement, and Section 7 #10, which is a > protocol requirement. > > Patrick & I have followed the list discussion and conferred > with the ADs. We suggest resolving this issue as follows: > > Issue #1: The architecture requirement (S5#10) says that FE's > must be able to provide to CEs the topology by which the FEs > in the NE are connected. We suggest rolling this back to > what the requirement was in requirements-01: > > 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by > which the FEs in the NE are connected. > > This is suggested because it is possible for CEs to learn > topology information without the FEs having to provide > it, and there are real systems that operate in such a fashion. > > > Issue #2: The protocol requirement (S7#10) says that the ForCES > protocol must provide a mechanism to carry inter-FE topology > info to the CE. Given the resolution to issue#1, it is clear > that a mechanism to deliver topology information is not always > used in the Fp reference point (because the element providing > topology information might not be a FE). As such, we recommend > changing S7#10 from a MUST to a MAY. If a protocol author > believes that topology information is sufficiently important, > then they may include it in their protocol. However, > if a protocol author believes it is not necessary then they may > omit it. It will be up to the WG as a whole to determine during > protocol selection the incremental value from including such > mechanisms (for those protocols that choose to do so). > > Finally, there is also a procedural issue, in that this document > is in the RFC editor's queue and as such it is a strange > time to be changing the contents. Patrick & I believe the > necessary changes can be made during the author's 48 hour > period, which has not started yet. > > We believe that the above recommendations are consistent > with the statements and general consensus of the list. > If anyone has an objection to this resolution, or would like > to suggest different replacement text, please make this known. > > Thanks, > David and Patrick > From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 26 13:46:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15273 for ; Fri, 26 Sep 2003 13:46:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2wfm-0003gE-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 13:46:30 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2wfl-0003gB-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 13:46:29 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00BE85D7@cherry.ease.lsoft.com>; Fri, 26 Sep 2003 13:46:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56170578 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 13:46:28 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 26 Sep 2003 13:46:28 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5531057 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 13:46:27 -0400 X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20030926134218.02207800@mail.stevecrocker.com> Date: Fri, 26 Sep 2003 13:46:17 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD881F506@orsmsx409.jf.intel. com> Precedence: list I would prefer the replacement text. I can live with the original text, given the change in the architectural text. What actually would address the problem better would be some way of saying that the solution has to allow for carrying this information. I realize that some folks have read the current text to mean that. Other folks have read it more strictly. How about: The ForCES protocol or information carried in the ForCES protocol MUST allow those FEs which have inter-FE topology information to provide that information to the CE(s). (refer to section 5, requirement 10) Yours, Joel M. Halpern At 10:37 AM 9/26/2003 -0700, you wrote: >All, > >It appears that there is some concern around the second >of the two recommendations made, specifically to change >the MUST to a MAY in the protocol requirement to provide >a method to deliver inter-FE topology information from >FEs to CEs. > >Patrick & I would like to do an explicit consensus >call on this matter to settle the question. Please >send a note to the list stating one of the following: > >* Retain original text > The ForCES protocol MUST allow the FEs to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). (refer to section 5, requirement# 10) > >* Replace MUST with MAY in original text > The ForCES protocol MAY allow the FEs to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). (refer to section 5, requirement# 10) > >* Some other alternative (please provide text). > >Thanks, >David > > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria >Sent: Thursday, September 25, 2003 9:15 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] Issue Summary: Inter-FE Topology requirements > > >I am fine with the first change (architecture) but uncomfortable with >the second (protocol). > >I believe the protocol, as designed, should be able to carry. That >would the protocol requirement. > >I believe it may or may not be called on to do so. That is an >implementation detail. > >a. > >On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote: > > > All, > > > > Thanks for the discussion on the topic of inter-FE topology. > > There are two sections of the requirements document that have > > caused discussion here - Section 5 #10, which is an > > architectural requirement, and Section 7 #10, which is a > > protocol requirement. > > > > Patrick & I have followed the list discussion and conferred > > with the ADs. We suggest resolving this issue as follows: > > > > Issue #1: The architecture requirement (S5#10) says that FE's > > must be able to provide to CEs the topology by which the FEs > > in the NE are connected. We suggest rolling this back to > > what the requirement was in requirements-01: > > > > 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by > > which the FEs in the NE are connected. > > > > This is suggested because it is possible for CEs to learn > > topology information without the FEs having to provide > > it, and there are real systems that operate in such a fashion. > > > > > > Issue #2: The protocol requirement (S7#10) says that the ForCES > > protocol must provide a mechanism to carry inter-FE topology > > info to the CE. Given the resolution to issue#1, it is clear > > that a mechanism to deliver topology information is not always > > used in the Fp reference point (because the element providing > > topology information might not be a FE). As such, we recommend > > changing S7#10 from a MUST to a MAY. If a protocol author > > believes that topology information is sufficiently important, > > then they may include it in their protocol. However, > > if a protocol author believes it is not necessary then they may > > omit it. It will be up to the WG as a whole to determine during > > protocol selection the incremental value from including such > > mechanisms (for those protocols that choose to do so). > > > > Finally, there is also a procedural issue, in that this document > > is in the RFC editor's queue and as such it is a strange > > time to be changing the contents. Patrick & I believe the > > necessary changes can be made during the author's 48 hour > > period, which has not started yet. > > > > We believe that the above recommendations are consistent > > with the statements and general consensus of the list. > > If anyone has an objection to this resolution, or would like > > to suggest different replacement text, please make this known. > > > > Thanks, > > David and Patrick > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 26 14:16:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16553 for ; Fri, 26 Sep 2003 14:16:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2x9B-000401-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 14:16:53 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2x9A-0003zy-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 14:16:52 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00BE858F@cherry.ease.lsoft.com>; Fri, 26 Sep 2003 14:16:52 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56172657 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 14:16:51 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 26 Sep 2003 14:16:51 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2003092611224761:685 ; Fri, 26 Sep 2003 11:22:47 -0700 References: <5.1.0.14.0.20030926134218.02207800@mail.stevecrocker.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/26/2003 11:22:48 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/26/2003 11:22:53 AM, Serialize complete at 09/26/2003 11:22:53 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1064600205.1026.12.camel@jzny.localdomain> Date: Fri, 26 Sep 2003 14:16:45 -0400 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030926134218.02207800@mail.stevecrocker.com> Precedence: list Content-Transfer-Encoding: 7bit I think that the toning down to may (lowercase) would deliver the same semantics in the message as your text below. I would have prefered total removal since we do actually allow for _any_ FE attributes to be retrieved (including proprietary ones). cheers, jamal On Fri, 2003-09-26 at 13:46, Joel M. Halpern wrote: > I would prefer the replacement text. > > I can live with the original text, given the change in the architectural text. > > What actually would address the problem better would be some way of saying > that the solution has to allow for carrying this information. I realize > that some folks have read the current text to mean that. Other folks have > read it more strictly. How about: > The ForCES protocol or information carried in the ForCES protocol MUST > allow > those FEs which have inter-FE topology information to provide that > information > to the CE(s). (refer to section 5, requirement 10) > > Yours, > Joel M. Halpern > > At 10:37 AM 9/26/2003 -0700, you wrote: > >All, > > > >It appears that there is some concern around the second > >of the two recommendations made, specifically to change > >the MUST to a MAY in the protocol requirement to provide > >a method to deliver inter-FE topology information from > >FEs to CEs. > > > >Patrick & I would like to do an explicit consensus > >call on this matter to settle the question. Please > >send a note to the list stating one of the following: > > > >* Retain original text > > The ForCES protocol MUST allow the FEs to provide their topology > > information (topology by which the FEs in the NE are connected) to > > the CE(s). (refer to section 5, requirement# 10) > > > >* Replace MUST with MAY in original text > > The ForCES protocol MAY allow the FEs to provide their topology > > information (topology by which the FEs in the NE are connected) to > > the CE(s). (refer to section 5, requirement# 10) > > > >* Some other alternative (please provide text). > > > >Thanks, > >David > > > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria > >Sent: Thursday, September 25, 2003 9:15 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] Issue Summary: Inter-FE Topology requirements > > > > > >I am fine with the first change (architecture) but uncomfortable with > >the second (protocol). > > > >I believe the protocol, as designed, should be able to carry. That > >would the protocol requirement. > > > >I believe it may or may not be called on to do so. That is an > >implementation detail. > > > >a. > > > >On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote: > > > > > All, > > > > > > Thanks for the discussion on the topic of inter-FE topology. > > > There are two sections of the requirements document that have > > > caused discussion here - Section 5 #10, which is an > > > architectural requirement, and Section 7 #10, which is a > > > protocol requirement. > > > > > > Patrick & I have followed the list discussion and conferred > > > with the ADs. We suggest resolving this issue as follows: > > > > > > Issue #1: The architecture requirement (S5#10) says that FE's > > > must be able to provide to CEs the topology by which the FEs > > > in the NE are connected. We suggest rolling this back to > > > what the requirement was in requirements-01: > > > > > > 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by > > > which the FEs in the NE are connected. > > > > > > This is suggested because it is possible for CEs to learn > > > topology information without the FEs having to provide > > > it, and there are real systems that operate in such a fashion. > > > > > > > > > Issue #2: The protocol requirement (S7#10) says that the ForCES > > > protocol must provide a mechanism to carry inter-FE topology > > > info to the CE. Given the resolution to issue#1, it is clear > > > that a mechanism to deliver topology information is not always > > > used in the Fp reference point (because the element providing > > > topology information might not be a FE). As such, we recommend > > > changing S7#10 from a MUST to a MAY. If a protocol author > > > believes that topology information is sufficiently important, > > > then they may include it in their protocol. However, > > > if a protocol author believes it is not necessary then they may > > > omit it. It will be up to the WG as a whole to determine during > > > protocol selection the incremental value from including such > > > mechanisms (for those protocols that choose to do so). > > > > > > Finally, there is also a procedural issue, in that this document > > > is in the RFC editor's queue and as such it is a strange > > > time to be changing the contents. Patrick & I believe the > > > necessary changes can be made during the author's 48 hour > > > period, which has not started yet. > > > > > > We believe that the above recommendations are consistent > > > with the statements and general consensus of the list. > > > If anyone has an objection to this resolution, or would like > > > to suggest different replacement text, please make this known. > > > > > > Thanks, > > > David and Patrick > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 26 14:17:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16574 for ; Fri, 26 Sep 2003 14:17:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2x9v-00040E-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 14:17:39 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2x9u-00040B-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 14:17:39 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00BE86EB@cherry.ease.lsoft.com>; Fri, 26 Sep 2003 14:17:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56172715 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 14:17:38 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 26 Sep 2003 14:17:38 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8QIFG610805 for ; Fri, 26 Sep 2003 18:15:16 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8QICEe26470 for ; Fri, 26 Sep 2003 18:12:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092611173606928 for ; Fri, 26 Sep 2003 11:17:36 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 26 Sep 2003 11:17:36 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) Thread-Index: AcOEV6YcP69r6g0mSB+a13IEIsOpxgAAnh5g X-OriginalArrivalTime: 26 Sep 2003 18:17:36.0858 (UTC) FILETIME=[769F4BA0:01C3845A] Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D2714FF26@orsmsx410.jf.intel.com> Date: Fri, 26 Sep 2003 11:17:36 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I read the original text just as Joel's interpretation, but Joel's = suggested text is more explicit. So I would suggest we use his text = instead to avoid any future confusion. > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Joel M. Halpern > Sent: Friday, September 26, 2003 10:46 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Proto Requirement - Weigh in Please (was:=20 > re:[FORCES] Issue > Summary: Inter-FE Topology requirements) >=20 >=20 > I would prefer the replacement text. >=20 > I can live with the original text, given the change in the=20 > architectural text. >=20 > What actually would address the problem better would be some=20 > way of saying > that the solution has to allow for carrying this information.=20 > I realize > that some folks have read the current text to mean that. =20 > Other folks have > read it more strictly. How about: > The ForCES protocol or information carried in the ForCES=20 > protocol MUST > allow > those FEs which have inter-FE topology information to provide that > information > to the CE(s). (refer to section 5, requirement 10) >=20 > Yours, > Joel M. Halpern >=20 > At 10:37 AM 9/26/2003 -0700, you wrote: > >All, > > > >It appears that there is some concern around the second > >of the two recommendations made, specifically to change > >the MUST to a MAY in the protocol requirement to provide > >a method to deliver inter-FE topology information from > >FEs to CEs. > > > >Patrick & I would like to do an explicit consensus > >call on this matter to settle the question. Please > >send a note to the list stating one of the following: > > > >* Retain original text > > The ForCES protocol MUST allow the FEs to provide their topology > > information (topology by which the FEs in the NE are=20 > connected) to > > the CE(s). (refer to section 5, requirement# 10) > > > >* Replace MUST with MAY in original text > > The ForCES protocol MAY allow the FEs to provide their topology > > information (topology by which the FEs in the NE are=20 > connected) to > > the CE(s). (refer to section 5, requirement# 10) > > > >* Some other alternative (please provide text). > > > >Thanks, > >David > > > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria > >Sent: Thursday, September 25, 2003 9:15 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] Issue Summary: Inter-FE Topology requirements > > > > > >I am fine with the first change (architecture) but uncomfortable with > >the second (protocol). > > > >I believe the protocol, as designed, should be able to carry. That > >would the protocol requirement. > > > >I believe it may or may not be called on to do so. That is an > >implementation detail. > > > >a. > > > >On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote: > > > > > All, > > > > > > Thanks for the discussion on the topic of inter-FE topology. > > > There are two sections of the requirements document that have > > > caused discussion here - Section 5 #10, which is an > > > architectural requirement, and Section 7 #10, which is a > > > protocol requirement. > > > > > > Patrick & I have followed the list discussion and conferred > > > with the ADs. We suggest resolving this issue as follows: > > > > > > Issue #1: The architecture requirement (S5#10) says that FE's > > > must be able to provide to CEs the topology by which the FEs > > > in the NE are connected. We suggest rolling this back to > > > what the requirement was in requirements-01: > > > > > > 10) In a ForCES NE, the CE(s) MUST be able to learn=20 > the topology by > > > which the FEs in the NE are connected. > > > > > > This is suggested because it is possible for CEs to learn > > > topology information without the FEs having to provide > > > it, and there are real systems that operate in such a fashion. > > > > > > > > > Issue #2: The protocol requirement (S7#10) says that the ForCES > > > protocol must provide a mechanism to carry inter-FE topology > > > info to the CE. Given the resolution to issue#1, it is clear > > > that a mechanism to deliver topology information is not always > > > used in the Fp reference point (because the element providing > > > topology information might not be a FE). As such, we recommend > > > changing S7#10 from a MUST to a MAY. If a protocol author > > > believes that topology information is sufficiently important, > > > then they may include it in their protocol. However, > > > if a protocol author believes it is not necessary then they may > > > omit it. It will be up to the WG as a whole to determine during > > > protocol selection the incremental value from including such > > > mechanisms (for those protocols that choose to do so). > > > > > > Finally, there is also a procedural issue, in that this document > > > is in the RFC editor's queue and as such it is a strange > > > time to be changing the contents. Patrick & I believe the > > > necessary changes can be made during the author's 48 hour > > > period, which has not started yet. > > > > > > We believe that the above recommendations are consistent > > > with the statements and general consensus of the list. > > > If anyone has an objection to this resolution, or would like > > > to suggest different replacement text, please make this known. > > > > > > Thanks, > > > David and Patrick > > > >=20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 26 15:18:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20211 for ; Fri, 26 Sep 2003 15:18:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2y6V-0004lY-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 15:18:11 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A2y6V-0004lV-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 15:18:11 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00BE87A5@cherry.ease.lsoft.com>; Fri, 26 Sep 2003 15:18:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56083907 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 15:17:58 -0400 Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 26 Sep 2003 15:17:53 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id h8QJHq6E002902 for ; Fri, 26 Sep 2003 14:17:52 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <52D13A805349A249960B9943E5590BD881F506@orsmsx409.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <3F7490DF.F10922F4@alcatel.com> Date: Fri, 26 Sep 2003 14:17:52 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I guess my concern with a "MAY" strength here is it might impact interoperability. If FE box vendor A uses protocol stack X that doesn't provide a mechanism to query inter-FE connectivity, how would a CE box from vendor B using protocl stack Y that provides/expects this quey mechanism inter-operate fully with it? Regards, Alex. "Putzolu, David" wrote: > All, > > It appears that there is some concern around the second > of the two recommendations made, specifically to change > the MUST to a MAY in the protocol requirement to provide > a method to deliver inter-FE topology information from > FEs to CEs. > > Patrick & I would like to do an explicit consensus > call on this matter to settle the question. Please > send a note to the list stating one of the following: > > * Retain original text > The ForCES protocol MUST allow the FEs to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). (refer to section 5, requirement# 10) > > * Replace MUST with MAY in original text > The ForCES protocol MAY allow the FEs to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). (refer to section 5, requirement# 10) > > * Some other alternative (please provide text). > > Thanks, > David > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria > Sent: Thursday, September 25, 2003 9:15 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Issue Summary: Inter-FE Topology requirements > > I am fine with the first change (architecture) but uncomfortable with > the second (protocol). > > I believe the protocol, as designed, should be able to carry. That > would the protocol requirement. > > I believe it may or may not be called on to do so. That is an > implementation detail. > > a. > > On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote: > > > All, > > > > Thanks for the discussion on the topic of inter-FE topology. > > There are two sections of the requirements document that have > > caused discussion here - Section 5 #10, which is an > > architectural requirement, and Section 7 #10, which is a > > protocol requirement. > > > > Patrick & I have followed the list discussion and conferred > > with the ADs. We suggest resolving this issue as follows: > > > > Issue #1: The architecture requirement (S5#10) says that FE's > > must be able to provide to CEs the topology by which the FEs > > in the NE are connected. We suggest rolling this back to > > what the requirement was in requirements-01: > > > > 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by > > which the FEs in the NE are connected. > > > > This is suggested because it is possible for CEs to learn > > topology information without the FEs having to provide > > it, and there are real systems that operate in such a fashion. > > > > > > Issue #2: The protocol requirement (S7#10) says that the ForCES > > protocol must provide a mechanism to carry inter-FE topology > > info to the CE. Given the resolution to issue#1, it is clear > > that a mechanism to deliver topology information is not always > > used in the Fp reference point (because the element providing > > topology information might not be a FE). As such, we recommend > > changing S7#10 from a MUST to a MAY. If a protocol author > > believes that topology information is sufficiently important, > > then they may include it in their protocol. However, > > if a protocol author believes it is not necessary then they may > > omit it. It will be up to the WG as a whole to determine during > > protocol selection the incremental value from including such > > mechanisms (for those protocols that choose to do so). > > > > Finally, there is also a procedural issue, in that this document > > is in the RFC editor's queue and as such it is a strange > > time to be changing the contents. Patrick & I believe the > > necessary changes can be made during the author's 48 hour > > period, which has not started yet. > > > > We believe that the above recommendations are consistent > > with the statements and general consensus of the list. > > If anyone has an objection to this resolution, or would like > > to suggest different replacement text, please make this known. > > > > Thanks, > > David and Patrick > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 26 19:35:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29302 for ; Fri, 26 Sep 2003 19:35:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A327e-0007Ce-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 19:35:38 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A327e-0007Cb-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 19:35:38 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00BE91C8@cherry.ease.lsoft.com>; Fri, 26 Sep 2003 19:35:38 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56103737 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 19:35:37 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 26 Sep 2003 19:35:37 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 1A327c-000K7c-Ix for forces@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 23:35:37 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Approved-By: Avri Doria Message-ID: Date: Sat, 27 Sep 2003 08:34:20 +0900 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Avri Doria Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20030926134218.02207800@mail.stevecrocker.com> Precedence: list Content-Transfer-Encoding: quoted-printable I am fine with Joel's rewrite. a. On l=F6rdag, sep 27, 2003, at 02:46 Asia/Seoul, Joel M. Halpern wrote: > I would prefer the replacement text. > > I can live with the original text, given the change in the=20 > architectural text. > > What actually would address the problem better would be some way of=20 > saying > that the solution has to allow for carrying this information. I=20 > realize > that some folks have read the current text to mean that. Other folks=20= > have > read it more strictly. How about: > The ForCES protocol or information carried in the ForCES protocol=20= > MUST > allow > those FEs which have inter-FE topology information to provide that > information > to the CE(s). (refer to section 5, requirement 10) > > Yours, > Joel M. Halpern > > At 10:37 AM 9/26/2003 -0700, you wrote: >> All, >> >> It appears that there is some concern around the second >> of the two recommendations made, specifically to change >> the MUST to a MAY in the protocol requirement to provide >> a method to deliver inter-FE topology information from >> FEs to CEs. >> >> Patrick & I would like to do an explicit consensus >> call on this matter to settle the question. Please >> send a note to the list stating one of the following: >> >> * Retain original text >> The ForCES protocol MUST allow the FEs to provide their topology >> information (topology by which the FEs in the NE are connected) to >> the CE(s). (refer to section 5, requirement# 10) >> >> * Replace MUST with MAY in original text >> The ForCES protocol MAY allow the FEs to provide their topology >> information (topology by which the FEs in the NE are connected) to >> the CE(s). (refer to section 5, requirement# 10) >> >> * Some other alternative (please provide text). >> >> Thanks, >> David >> >> >> -----Original Message----- >> From: Forwarding and Control Element Separation >> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria >> Sent: Thursday, September 25, 2003 9:15 PM >> To: FORCES@PEACH.EASE.LSOFT.COM >> Subject: Re: [FORCES] Issue Summary: Inter-FE Topology requirements >> >> >> I am fine with the first change (architecture) but uncomfortable with >> the second (protocol). >> >> I believe the protocol, as designed, should be able to carry. That >> would the protocol requirement. >> >> I believe it may or may not be called on to do so. That is an >> implementation detail. >> >> a. >> >> On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote: >> >> > All, >> > >> > Thanks for the discussion on the topic of inter-FE topology. >> > There are two sections of the requirements document that have >> > caused discussion here - Section 5 #10, which is an >> > architectural requirement, and Section 7 #10, which is a >> > protocol requirement. >> > >> > Patrick & I have followed the list discussion and conferred >> > with the ADs. We suggest resolving this issue as follows: >> > >> > Issue #1: The architecture requirement (S5#10) says that FE's >> > must be able to provide to CEs the topology by which the FEs >> > in the NE are connected. We suggest rolling this back to >> > what the requirement was in requirements-01: >> > >> > 10) In a ForCES NE, the CE(s) MUST be able to learn the topology=20= >> by >> > which the FEs in the NE are connected. >> > >> > This is suggested because it is possible for CEs to learn >> > topology information without the FEs having to provide >> > it, and there are real systems that operate in such a fashion. >> > >> > >> > Issue #2: The protocol requirement (S7#10) says that the ForCES >> > protocol must provide a mechanism to carry inter-FE topology >> > info to the CE. Given the resolution to issue#1, it is clear >> > that a mechanism to deliver topology information is not always >> > used in the Fp reference point (because the element providing >> > topology information might not be a FE). As such, we recommend >> > changing S7#10 from a MUST to a MAY. If a protocol author >> > believes that topology information is sufficiently important, >> > then they may include it in their protocol. However, >> > if a protocol author believes it is not necessary then they may >> > omit it. It will be up to the WG as a whole to determine during >> > protocol selection the incremental value from including such >> > mechanisms (for those protocols that choose to do so). >> > >> > Finally, there is also a procedural issue, in that this document >> > is in the RFC editor's queue and as such it is a strange >> > time to be changing the contents. Patrick & I believe the >> > necessary changes can be made during the author's 48 hour >> > period, which has not started yet. >> > >> > We believe that the above recommendations are consistent >> > with the statements and general consensus of the list. >> > If anyone has an objection to this resolution, or would like >> > to suggest different replacement text, please make this known. >> > >> > Thanks, >> > David and Patrick >> > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Sep 26 21:21:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01643 for ; Fri, 26 Sep 2003 21:21:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A33mO-0000AZ-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 21:21:48 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A33mO-0000AW-00 for forces-archive@IETF.ORG; Fri, 26 Sep 2003 21:21:48 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00BE9333@cherry.ease.lsoft.com>; Fri, 26 Sep 2003 21:21:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56109990 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Sep 2003 21:21:36 -0400 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 26 Sep 2003 21:21:35 -0400 Received: from wwm1([218.108.150.51]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm5b3f752139; Sat, 27 Sep 2003 09:20:27 +0800 References: <5.1.0.14.0.20030926134218.02207800@mail.stevecrocker.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Approved-By: Weiming Wang Message-ID: <007601c38495$968ad3e0$3d19fea9@wwm1> Date: Sat, 27 Sep 2003 09:20:49 +0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SSdtIGFmcmFpZCBpbiBzb21lIGNhc2VzIENFIGlzIGFsc28gaW50ZXJlc3RlZCBpbiBrbm93aW5n IGlmIEZFIGNhbiBvciBjYW4gbm90IHByb3ZpZGUgaXRzIEZFIHRvcG9sb2d5IGluZm9ybWF0aW9u LiANClRoaXMgbWVhbnMgdGhlIEZwIHByb3RvY29sIE1VU1QgYWxsb3cgRkVzIHRvIHByb3ZpZGUg dG9wb2xvZ3kgaW5mb3JtYXRpb24gZXZlbiB0aGUgRkVzIGRvIG5vdCBhY3R1YWxseSANCmhhdmUg dG9wb2xvZ3kgaW4gaGFuZC4gDQpUaGVyZWZvcmUsIEkgcHJlZmVyIHRoZSBvcmlnaW5hbCBvbmUu ICBXaXRoIHRoZSBjaGFuZ2UgaW4gdGhlIHNlYzUgcmVxdWlyZW1lbnQgMTAsICB0aGUgcmVxdWly ZW1lbnQgZGlzY3Vzc2VkIGlzIG9rLg0KDQp3ZWltaW5nDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tIA0KRnJvbTogIkpvZWwgTS4gSGFscGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4N ClRvOiA8Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NPg0KU2VudDogU2F0dXJkYXksIFNlcHRl bWJlciAyNywgMjAwMyAxOjQ2IEFNDQpTdWJqZWN0OiBSZTogUHJvdG8gUmVxdWlyZW1lbnQgLSBX ZWlnaCBpbiBQbGVhc2UgKHdhczogcmU6W0ZPUkNFU10gSXNzdWUgU3VtbWFyeTogSW50ZXItRkUg VG9wb2xvZ3kgcmVxdWlyZW1lbnRzKQ0KDQoNCj4gSSB3b3VsZCBwcmVmZXIgdGhlIHJlcGxhY2Vt ZW50IHRleHQuDQo+IA0KPiBJIGNhbiBsaXZlIHdpdGggdGhlIG9yaWdpbmFsIHRleHQsIGdpdmVu IHRoZSBjaGFuZ2UgaW4gdGhlIGFyY2hpdGVjdHVyYWwgdGV4dC4NCj4gDQo+IFdoYXQgYWN0dWFs bHkgd291bGQgYWRkcmVzcyB0aGUgcHJvYmxlbSBiZXR0ZXIgd291bGQgYmUgc29tZSB3YXkgb2Yg c2F5aW5nDQo+IHRoYXQgdGhlIHNvbHV0aW9uIGhhcyB0byBhbGxvdyBmb3IgY2FycnlpbmcgdGhp cyBpbmZvcm1hdGlvbi4gIEkgcmVhbGl6ZQ0KPiB0aGF0IHNvbWUgZm9sa3MgaGF2ZSByZWFkIHRo ZSBjdXJyZW50IHRleHQgdG8gbWVhbiB0aGF0LiAgT3RoZXIgZm9sa3MgaGF2ZQ0KPiByZWFkIGl0 IG1vcmUgc3RyaWN0bHkuICBIb3cgYWJvdXQ6DQo+ICAgICBUaGUgRm9yQ0VTIHByb3RvY29sIG9y IGluZm9ybWF0aW9uIGNhcnJpZWQgaW4gdGhlIEZvckNFUyBwcm90b2NvbCBNVVNUDQo+IGFsbG93 DQo+ICAgICB0aG9zZSBGRXMgd2hpY2ggaGF2ZSBpbnRlci1GRSB0b3BvbG9neSBpbmZvcm1hdGlv biB0byBwcm92aWRlIHRoYXQNCj4gaW5mb3JtYXRpb24NCj4gICAgIHRvIHRoZSBDRShzKS4gIChy ZWZlciB0byBzZWN0aW9uIDUsIHJlcXVpcmVtZW50IDEwKQ0KPiANCj4gWW91cnMsDQo+IEpvZWwg TS4gSGFscGVybg0KPiANCj4gQXQgMTA6MzcgQU0gOS8yNi8yMDAzIC0wNzAwLCB5b3Ugd3JvdGU6 DQo+ID5BbGwsDQo+ID4NCj4gPkl0IGFwcGVhcnMgdGhhdCB0aGVyZSBpcyBzb21lIGNvbmNlcm4g YXJvdW5kIHRoZSBzZWNvbmQNCj4gPm9mIHRoZSB0d28gcmVjb21tZW5kYXRpb25zIG1hZGUsIHNw ZWNpZmljYWxseSB0byBjaGFuZ2UNCj4gPnRoZSBNVVNUIHRvIGEgTUFZIGluIHRoZSBwcm90b2Nv bCByZXF1aXJlbWVudCB0byBwcm92aWRlDQo+ID5hIG1ldGhvZCB0byBkZWxpdmVyIGludGVyLUZF IHRvcG9sb2d5IGluZm9ybWF0aW9uIGZyb20NCj4gPkZFcyB0byBDRXMuDQo+ID4NCj4gPlBhdHJp Y2sgJiBJIHdvdWxkIGxpa2UgdG8gZG8gYW4gZXhwbGljaXQgY29uc2Vuc3VzDQo+ID5jYWxsIG9u IHRoaXMgbWF0dGVyIHRvIHNldHRsZSB0aGUgcXVlc3Rpb24uIFBsZWFzZQ0KPiA+c2VuZCBhIG5v dGUgdG8gdGhlIGxpc3Qgc3RhdGluZyBvbmUgb2YgdGhlIGZvbGxvd2luZzoNCj4gPg0KPiA+KiBS ZXRhaW4gb3JpZ2luYWwgdGV4dA0KPiA+ICAgIFRoZSBGb3JDRVMgcHJvdG9jb2wgTVVTVCBhbGxv dyB0aGUgRkVzIHRvIHByb3ZpZGUgdGhlaXIgdG9wb2xvZ3kNCj4gPiAgICBpbmZvcm1hdGlvbiAo dG9wb2xvZ3kgYnkgd2hpY2ggdGhlIEZFcyBpbiB0aGUgTkUgYXJlIGNvbm5lY3RlZCkgdG8NCj4g PiAgICB0aGUgQ0UocykuIChyZWZlciB0byBzZWN0aW9uIDUsIHJlcXVpcmVtZW50IyAxMCkNCj4g Pg0KPiA+KiBSZXBsYWNlIE1VU1Qgd2l0aCBNQVkgaW4gb3JpZ2luYWwgdGV4dA0KPiA+ICAgIFRo ZSBGb3JDRVMgcHJvdG9jb2wgTUFZIGFsbG93IHRoZSBGRXMgdG8gcHJvdmlkZSB0aGVpciB0b3Bv bG9neQ0KPiA+ICAgIGluZm9ybWF0aW9uICh0b3BvbG9neSBieSB3aGljaCB0aGUgRkVzIGluIHRo ZSBORSBhcmUgY29ubmVjdGVkKSB0bw0KPiA+ICAgIHRoZSBDRShzKS4gKHJlZmVyIHRvIHNlY3Rp b24gNSwgcmVxdWlyZW1lbnQjIDEwKQ0KPiA+DQo+ID4qIFNvbWUgb3RoZXIgYWx0ZXJuYXRpdmUg KHBsZWFzZSBwcm92aWRlIHRleHQpLg0KPiA+DQo+ID5UaGFua3MsDQo+ID5EYXZpZA0KPiA+DQo+ ID4NCj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID5Gcm9tOiBGb3J3YXJkaW5nIGFu ZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbg0KPiA+W21haWx0bzpGT1JDRVNAUEVBQ0guRUFT RS5MU09GVC5DT01dIE9uIEJlaGFsZiBPZiBBdnJpIERvcmlhDQo+ID5TZW50OiBUaHVyc2RheSwg U2VwdGVtYmVyIDI1LCAyMDAzIDk6MTUgUE0NCj4gPlRvOiBGT1JDRVNAUEVBQ0guRUFTRS5MU09G VC5DT00NCj4gPlN1YmplY3Q6IFJlOiBbRk9SQ0VTXSBJc3N1ZSBTdW1tYXJ5OiBJbnRlci1GRSBU b3BvbG9neSByZXF1aXJlbWVudHMNCj4gPg0KPiA+DQo+ID5JIGFtIGZpbmUgd2l0aCB0aGUgZmly c3QgY2hhbmdlIChhcmNoaXRlY3R1cmUpIGJ1dCB1bmNvbWZvcnRhYmxlIHdpdGgNCj4gPnRoZSBz ZWNvbmQgKHByb3RvY29sKS4NCj4gPg0KPiA+SSBiZWxpZXZlIHRoZSBwcm90b2NvbCwgYXMgZGVz aWduZWQsIHNob3VsZCBiZSBhYmxlIHRvIGNhcnJ5LiAgVGhhdA0KPiA+d291bGQgdGhlIHByb3Rv Y29sIHJlcXVpcmVtZW50Lg0KPiA+DQo+ID5JIGJlbGlldmUgaXQgbWF5IG9yIG1heSBub3QgYmUg Y2FsbGVkIG9uIHRvIGRvIHNvLiBUaGF0IGlzIGFuDQo+ID5pbXBsZW1lbnRhdGlvbiBkZXRhaWwu DQo+ID4NCj4gPmEuDQo+ID4NCj4gPk9uIGZyZWRhZywgc2VwIDI2LCAyMDAzLCBhdCAxMjozOSBB c2lhL1Nlb3VsLCBQdXR6b2x1LCBEYXZpZCB3cm90ZToNCj4gPg0KPiA+ID4gQWxsLA0KPiA+ID4N Cj4gPiA+IFRoYW5rcyBmb3IgdGhlIGRpc2N1c3Npb24gb24gdGhlIHRvcGljIG9mIGludGVyLUZF IHRvcG9sb2d5Lg0KPiA+ID4gVGhlcmUgYXJlIHR3byBzZWN0aW9ucyBvZiB0aGUgcmVxdWlyZW1l bnRzIGRvY3VtZW50IHRoYXQgaGF2ZQ0KPiA+ID4gY2F1c2VkIGRpc2N1c3Npb24gaGVyZSAtIFNl Y3Rpb24gNSAjMTAsIHdoaWNoIGlzIGFuDQo+ID4gPiBhcmNoaXRlY3R1cmFsIHJlcXVpcmVtZW50 LCBhbmQgU2VjdGlvbiA3ICMxMCwgd2hpY2ggaXMgYQ0KPiA+ID4gcHJvdG9jb2wgcmVxdWlyZW1l bnQuDQo+ID4gPg0KPiA+ID4gUGF0cmljayAmIEkgaGF2ZSBmb2xsb3dlZCB0aGUgbGlzdCBkaXNj dXNzaW9uIGFuZCBjb25mZXJyZWQNCj4gPiA+IHdpdGggdGhlIEFEcy4gIFdlIHN1Z2dlc3QgcmVz b2x2aW5nIHRoaXMgaXNzdWUgYXMgZm9sbG93czoNCj4gPiA+DQo+ID4gPiBJc3N1ZSAjMTogVGhl IGFyY2hpdGVjdHVyZSByZXF1aXJlbWVudCAoUzUjMTApIHNheXMgdGhhdCBGRSdzDQo+ID4gPiBt dXN0IGJlIGFibGUgdG8gcHJvdmlkZSB0byBDRXMgdGhlIHRvcG9sb2d5IGJ5IHdoaWNoIHRoZSBG RXMNCj4gPiA+IGluIHRoZSBORSBhcmUgY29ubmVjdGVkLiAgV2Ugc3VnZ2VzdCByb2xsaW5nIHRo aXMgYmFjayB0bw0KPiA+ID4gd2hhdCB0aGUgcmVxdWlyZW1lbnQgd2FzIGluIHJlcXVpcmVtZW50 cy0wMToNCj4gPiA+DQo+ID4gPiAgICAxMCkgSW4gYSBGb3JDRVMgTkUsIHRoZSBDRShzKSBNVVNU IGJlIGFibGUgdG8gbGVhcm4gdGhlIHRvcG9sb2d5IGJ5DQo+ID4gPiAgICB3aGljaCB0aGUgRkVz IGluIHRoZSBORSBhcmUgY29ubmVjdGVkLg0KPiA+ID4NCj4gPiA+IFRoaXMgaXMgc3VnZ2VzdGVk IGJlY2F1c2UgaXQgaXMgcG9zc2libGUgZm9yIENFcyB0byBsZWFybg0KPiA+ID4gdG9wb2xvZ3kg aW5mb3JtYXRpb24gd2l0aG91dCB0aGUgRkVzIGhhdmluZyB0byBwcm92aWRlDQo+ID4gPiBpdCwg YW5kIHRoZXJlIGFyZSByZWFsIHN5c3RlbXMgdGhhdCBvcGVyYXRlIGluIHN1Y2ggYSBmYXNoaW9u Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBJc3N1ZSAjMjogVGhlIHByb3RvY29sIHJlcXVpcmVtZW50 IChTNyMxMCkgc2F5cyB0aGF0IHRoZSBGb3JDRVMNCj4gPiA+IHByb3RvY29sIG11c3QgcHJvdmlk ZSBhIG1lY2hhbmlzbSB0byBjYXJyeSBpbnRlci1GRSB0b3BvbG9neQ0KPiA+ID4gaW5mbyB0byB0 aGUgQ0UuICBHaXZlbiB0aGUgcmVzb2x1dGlvbiB0byBpc3N1ZSMxLCBpdCBpcyBjbGVhcg0KPiA+ ID4gdGhhdCBhIG1lY2hhbmlzbSB0byBkZWxpdmVyIHRvcG9sb2d5IGluZm9ybWF0aW9uIGlzIG5v dCBhbHdheXMNCj4gPiA+IHVzZWQgaW4gdGhlIEZwIHJlZmVyZW5jZSBwb2ludCAoYmVjYXVzZSB0 aGUgZWxlbWVudCBwcm92aWRpbmcNCj4gPiA+IHRvcG9sb2d5IGluZm9ybWF0aW9uIG1pZ2h0IG5v dCBiZSBhIEZFKS4gIEFzIHN1Y2gsIHdlIHJlY29tbWVuZA0KPiA+ID4gY2hhbmdpbmcgUzcjMTAg ZnJvbSBhIE1VU1QgdG8gYSBNQVkuICBJZiBhIHByb3RvY29sIGF1dGhvcg0KPiA+ID4gYmVsaWV2 ZXMgdGhhdCB0b3BvbG9neSBpbmZvcm1hdGlvbiBpcyBzdWZmaWNpZW50bHkgaW1wb3J0YW50LA0K PiA+ID4gdGhlbiB0aGV5IG1heSBpbmNsdWRlIGl0IGluIHRoZWlyIHByb3RvY29sLiAgSG93ZXZl ciwNCj4gPiA+IGlmIGEgcHJvdG9jb2wgYXV0aG9yIGJlbGlldmVzIGl0IGlzIG5vdCBuZWNlc3Nh cnkgdGhlbiB0aGV5IG1heQ0KPiA+ID4gb21pdCBpdC4gICBJdCB3aWxsIGJlIHVwIHRvIHRoZSBX RyBhcyBhIHdob2xlIHRvIGRldGVybWluZSBkdXJpbmcNCj4gPiA+IHByb3RvY29sIHNlbGVjdGlv biB0aGUgaW5jcmVtZW50YWwgdmFsdWUgZnJvbSBpbmNsdWRpbmcgc3VjaA0KPiA+ID4gbWVjaGFu aXNtcyAoZm9yIHRob3NlIHByb3RvY29scyB0aGF0IGNob29zZSB0byBkbyBzbykuDQo+ID4gPg0K PiA+ID4gRmluYWxseSwgdGhlcmUgaXMgYWxzbyBhIHByb2NlZHVyYWwgaXNzdWUsIGluIHRoYXQg dGhpcyBkb2N1bWVudA0KPiA+ID4gaXMgaW4gdGhlIFJGQyBlZGl0b3IncyBxdWV1ZSBhbmQgYXMg c3VjaCBpdCBpcyBhIHN0cmFuZ2UNCj4gPiA+IHRpbWUgdG8gYmUgY2hhbmdpbmcgdGhlIGNvbnRl bnRzLiAgUGF0cmljayAmIEkgYmVsaWV2ZSB0aGUNCj4gPiA+IG5lY2Vzc2FyeSBjaGFuZ2VzIGNh biBiZSBtYWRlIGR1cmluZyB0aGUgYXV0aG9yJ3MgNDggaG91cg0KPiA+ID4gcGVyaW9kLCB3aGlj aCBoYXMgbm90IHN0YXJ0ZWQgeWV0Lg0KPiA+ID4NCj4gPiA+IFdlIGJlbGlldmUgdGhhdCB0aGUg YWJvdmUgcmVjb21tZW5kYXRpb25zIGFyZSBjb25zaXN0ZW50DQo+ID4gPiB3aXRoIHRoZSBzdGF0 ZW1lbnRzIGFuZCBnZW5lcmFsIGNvbnNlbnN1cyBvZiB0aGUgbGlzdC4NCj4gPiA+IElmIGFueW9u ZSBoYXMgYW4gb2JqZWN0aW9uIHRvIHRoaXMgcmVzb2x1dGlvbiwgb3Igd291bGQgbGlrZQ0KPiA+ ID4gdG8gc3VnZ2VzdCBkaWZmZXJlbnQgcmVwbGFjZW1lbnQgdGV4dCwgcGxlYXNlIG1ha2UgdGhp cyBrbm93bi4NCj4gPiA+DQo+ID4gPiBUaGFua3MsDQo+ID4gPiBEYXZpZCBhbmQgUGF0cmljaw0K PiA+ID4NCj4g From owner-forces@PEACH.EASE.LSOFT.COM Sun Sep 28 14:04:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25450 for ; Sun, 28 Sep 2003 14:04:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3fuA-0003Xc-00 for forces-archive@IETF.ORG; Sun, 28 Sep 2003 14:04:22 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A3fu9-0003XX-00 for forces-archive@IETF.ORG; Sun, 28 Sep 2003 14:04:21 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00BEB476@cherry.ease.lsoft.com>; 28 Sep 2003 14:04:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56246639 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Sep 2003 14:04:20 -0400 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 28 Sep 2003 14:04:20 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8SI1w415363 for ; Sun, 28 Sep 2003 18:01:58 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8SHwt609432 for ; Sun, 28 Sep 2003 17:58:55 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092811041903886 for ; Sun, 28 Sep 2003 11:04:19 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 28 Sep 2003 11:04:19 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [FORCES] Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) Thread-Index: AcOEV3gRTGEeSghGRfaemYzlJD68BABktt4g X-OriginalArrivalTime: 28 Sep 2003 18:04:19.0318 (UTC) FILETIME=[F013D960:01C385EA] Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00A0875@orsmsx410.jf.intel.com> Date: Sun, 28 Sep 2003 11:04:18 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I am fine with Joel's text below. I do not like using MAY for the original text. Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, September 26, 2003 10:46 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) I would prefer the replacement text. I can live with the original text, given the change in the architectural text. What actually would address the problem better would be some way of saying that the solution has to allow for carrying this information. I realize that some folks have read the current text to mean that. Other folks have read it more strictly. How about: The ForCES protocol or information carried in the ForCES protocol MUST allow those FEs which have inter-FE topology information to provide that information to the CE(s). (refer to section 5, requirement 10) Yours, Joel M. Halpern At 10:37 AM 9/26/2003 -0700, you wrote: >All, > >It appears that there is some concern around the second >of the two recommendations made, specifically to change >the MUST to a MAY in the protocol requirement to provide >a method to deliver inter-FE topology information from >FEs to CEs. > >Patrick & I would like to do an explicit consensus >call on this matter to settle the question. Please >send a note to the list stating one of the following: > >* Retain original text > The ForCES protocol MUST allow the FEs to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). (refer to section 5, requirement# 10) > >* Replace MUST with MAY in original text > The ForCES protocol MAY allow the FEs to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). (refer to section 5, requirement# 10) > >* Some other alternative (please provide text). > >Thanks, >David > > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria >Sent: Thursday, September 25, 2003 9:15 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] Issue Summary: Inter-FE Topology requirements > > >I am fine with the first change (architecture) but uncomfortable with >the second (protocol). > >I believe the protocol, as designed, should be able to carry. That >would the protocol requirement. > >I believe it may or may not be called on to do so. That is an >implementation detail. > >a. > >On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote: > > > All, > > > > Thanks for the discussion on the topic of inter-FE topology. > > There are two sections of the requirements document that have > > caused discussion here - Section 5 #10, which is an > > architectural requirement, and Section 7 #10, which is a > > protocol requirement. > > > > Patrick & I have followed the list discussion and conferred > > with the ADs. We suggest resolving this issue as follows: > > > > Issue #1: The architecture requirement (S5#10) says that FE's > > must be able to provide to CEs the topology by which the FEs > > in the NE are connected. We suggest rolling this back to > > what the requirement was in requirements-01: > > > > 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by > > which the FEs in the NE are connected. > > > > This is suggested because it is possible for CEs to learn > > topology information without the FEs having to provide > > it, and there are real systems that operate in such a fashion. > > > > > > Issue #2: The protocol requirement (S7#10) says that the ForCES > > protocol must provide a mechanism to carry inter-FE topology > > info to the CE. Given the resolution to issue#1, it is clear > > that a mechanism to deliver topology information is not always > > used in the Fp reference point (because the element providing > > topology information might not be a FE). As such, we recommend > > changing S7#10 from a MUST to a MAY. If a protocol author > > believes that topology information is sufficiently important, > > then they may include it in their protocol. However, > > if a protocol author believes it is not necessary then they may > > omit it. It will be up to the WG as a whole to determine during > > protocol selection the incremental value from including such > > mechanisms (for those protocols that choose to do so). > > > > Finally, there is also a procedural issue, in that this document > > is in the RFC editor's queue and as such it is a strange > > time to be changing the contents. Patrick & I believe the > > necessary changes can be made during the author's 48 hour > > period, which has not started yet. > > > > We believe that the above recommendations are consistent > > with the statements and general consensus of the list. > > If anyone has an objection to this resolution, or would like > > to suggest different replacement text, please make this known. > > > > Thanks, > > David and Patrick > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 30 11:50:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27753 for ; Tue, 30 Sep 2003 11:50:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Mm7-0000Vg-00 for forces-archive@IETF.ORG; Tue, 30 Sep 2003 11:50:55 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1A4Mm6-0000Vc-00 for forces-archive@IETF.ORG; Tue, 30 Sep 2003 11:50:54 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00BEF2FF@cherry.ease.lsoft.com>; Tue, 30 Sep 2003 11:50:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 56461450 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 30 Sep 2003 11:50:52 -0400 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 30 Sep 2003 11:50:52 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8UFjr113821 for ; Tue, 30 Sep 2003 15:45:54 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.py.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8UFoLT07778 for ; Tue, 30 Sep 2003 15:50:21 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003093008505011400 for ; Tue, 30 Sep 2003 08:50:50 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 30 Sep 2003 08:50:51 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) Thread-Index: AcOEV6Dj5xW1yzOfTnCKDLUfW4GnygDEOnEA X-OriginalArrivalTime: 30 Sep 2003 15:50:51.0329 (UTC) FILETIME=[9FC53310:01C3876A] Approved-By: "Deleganes, Ellen M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0190AD9@orsmsx410.jf.intel.com> Date: Tue, 30 Sep 2003 08:50:50 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I prefer Joel's text to the original. Although many interpreted the original statement to mean the same thing (or something similar) as the rewritten text, I think the clarifications spelled out in the rewritten text are useful.=20 I like the addition of the clause "or information carried in the ForCES protocol". That seems to allow more flexibility in the protocol specification on how this would be done, and potentially allow other information about the FE to be transmitted to the CE, if so desired. Regards, Ellen Deleganes -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, September 26, 2003 10:46 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements) I would prefer the replacement text. I can live with the original text, given the change in the architectural text. What actually would address the problem better would be some way of saying that the solution has to allow for carrying this information. I realize that some folks have read the current text to mean that. Other folks have read it more strictly. How about: The ForCES protocol or information carried in the ForCES protocol MUST allow those FEs which have inter-FE topology information to provide that information to the CE(s). (refer to section 5, requirement 10) Yours, Joel M. Halpern At 10:37 AM 9/26/2003 -0700, you wrote: >All, > >It appears that there is some concern around the second >of the two recommendations made, specifically to change >the MUST to a MAY in the protocol requirement to provide >a method to deliver inter-FE topology information from >FEs to CEs. > >Patrick & I would like to do an explicit consensus >call on this matter to settle the question. Please >send a note to the list stating one of the following: > >* Retain original text > The ForCES protocol MUST allow the FEs to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). (refer to section 5, requirement# 10) > >* Replace MUST with MAY in original text > The ForCES protocol MAY allow the FEs to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). (refer to section 5, requirement# 10) > >* Some other alternative (please provide text). > >Thanks, >David > > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Avri Doria >Sent: Thursday, September 25, 2003 9:15 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] Issue Summary: Inter-FE Topology requirements > > >I am fine with the first change (architecture) but uncomfortable with >the second (protocol). > >I believe the protocol, as designed, should be able to carry. That >would the protocol requirement. > >I believe it may or may not be called on to do so. That is an >implementation detail. > >a. > >On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote: > > > All, > > > > Thanks for the discussion on the topic of inter-FE topology. > > There are two sections of the requirements document that have > > caused discussion here - Section 5 #10, which is an > > architectural requirement, and Section 7 #10, which is a > > protocol requirement. > > > > Patrick & I have followed the list discussion and conferred > > with the ADs. We suggest resolving this issue as follows: > > > > Issue #1: The architecture requirement (S5#10) says that FE's > > must be able to provide to CEs the topology by which the FEs > > in the NE are connected. We suggest rolling this back to > > what the requirement was in requirements-01: > > > > 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by > > which the FEs in the NE are connected. > > > > This is suggested because it is possible for CEs to learn > > topology information without the FEs having to provide > > it, and there are real systems that operate in such a fashion. > > > > > > Issue #2: The protocol requirement (S7#10) says that the ForCES > > protocol must provide a mechanism to carry inter-FE topology > > info to the CE. Given the resolution to issue#1, it is clear > > that a mechanism to deliver topology information is not always > > used in the Fp reference point (because the element providing > > topology information might not be a FE). As such, we recommend > > changing S7#10 from a MUST to a MAY. If a protocol author > > believes that topology information is sufficiently important, > > then they may include it in their protocol. However, > > if a protocol author believes it is not necessary then they may > > omit it. It will be up to the WG as a whole to determine during > > protocol selection the incremental value from including such > > mechanisms (for those protocols that choose to do so). > > > > Finally, there is also a procedural issue, in that this document > > is in the RFC editor's queue and as such it is a strange > > time to be changing the contents. Patrick & I believe the > > necessary changes can be made during the author's 48 hour > > period, which has not started yet. > > > > We believe that the above recommendations are consistent > > with the statements and general consensus of the list. > > If anyone has an objection to this resolution, or would like > > to suggest different replacement text, please make this known. > > > > Thanks, > > David and Patrick > >