From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 9 19:57:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02403 for ; Fri, 9 Jan 2004 19:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af7Rq-0001Qu-00 for forces-archive@ietf.org; Fri, 09 Jan 2004 19:57:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af7Q0-0001Mn-00 for forces-archive@ietf.org; Fri, 09 Jan 2004 19:56:02 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Af7Oi-0001J9-00 for forces-archive@IETF.ORG; Fri, 09 Jan 2004 19:54:40 -0500 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.00C9C923@cherry.ease.lsoft.com>; Fri, 9 Jan 2004 19:54:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67402990 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 9 Jan 2004 19:54:39 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jan 2004 19:54:38 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0A0udYd010233 for ; Sat, 10 Jan 2004 00:56:39 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0A0q6cI025810 for ; Sat, 10 Jan 2004 00:52:20 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010916543329683 for ; Fri, 09 Jan 2004 16:54:33 -0800 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, 9 Jan 2004 16:54:33 -0800 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: Comments on framework-12 Thread-Index: AcPVxaU0tKikpcLkQHaPL7RLyEJRSwBToEJA X-OriginalArrivalTime: 10 Jan 2004 00:54:33.0698 (UTC) FILETIME=[4FF06C20:01C3D714] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0BE@orsmsx410.jf.intel.com> Date: Fri, 9 Jan 2004 16:54:33 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: FW: Comments on framework-12 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I received these comments from Avri on the framework... -----Original Message----- From: avri [mailto:avri@psg.com] Sent: Thursday, January 08, 2004 12:59 AM To: Yang, Lily L Subject: Comments on framework-12 Hi, I know this is very late, but decided to reread the whole document as=20 opposed to just the changes. Apologies. I am just getting deeply=20 involved in a ForCES project so I am rereading everything with fresh=20 eyes. - Definitions Pre-association Phase - The period of time during which an FE Manager (see below) and a CE Manager (see below) are determining which FE and CE should be part of the same network element. As I have mentioned in other posting, this phase is likely to last long=20 into the post-association phase. I think it might be better to cast=20 the definition in terms of a single CE-FE association. Suggestion: Pre-association Phase - The period of time during which an FE Manager (see below) and a CE Manager (see below) are determining whether an FE and a CE should be part of the same network element. It is possible for some elements of the NE to be in pre-association = phase while other elements are in the post-association phase. - section 3 There is no defined role for FE Manager and CE Manager in post-association phase, thus these logical components are not considered part of the ForCES NE. I think this is misleading for the same reason given above. The idea=20 of pre and post association belongs to the 2 elements and not to the NE=20 at large. A dynamic system may have elements in pre-association as it=20 has elements in post-association. I recommend dropping the sentence. - section 3.2 Instead, FEs accept commands from any CE authorized to control them, and it is up to the CEs to coordinate among themselves to achieve redundancy, load sharing or distributed control. I am assuming that the FE accepts commands on a first come first served=20 basis. If so, this should probably be said. If not, then the possible=20 existence of a prioritization scheme should be mentioned. -section 4.1 Pre-association phase Pre-association phase is the period of time during which an FE Manager and a CE Manager are determining which FE and CE should be part of the same network element. Same comments as made above for the definition of the pre-association=20 phase. - section 4.1.1 this section reflects the same notion that the pre-association phase=20 occurs at a singular moment of time in the system. the CE and FE managers communicate to determine which CEs and FEs should communicate with each other. suggest: the CE and FE managers communicate to determine whether an individual CE and FE, or a set of CEs and FEs, should be=20 associated. - section 4.2.2 - message exchange diagram I think that since the delivery of inter-FE toplogy is optional, the=20 diagram should indicate this. - section 4.2.2. Once FE starts accepting packets for processing, we say the association of this FE with its CE is now established. This may be a pedantic point, but I would think that the the=20 association needs to be established before the process of accepting=20 packets for forwarding occurs. Suggest: Once the necessary exchange of initial information is exchanged, the process of association can be completed. Processing packets for forwarding cannot begin until association is established. - section 4.2.4 I think the language in: In light of the fact that the ForCES protocol is responsible for transporting both the control messages and the data packets between the CE and FE over Fp reference point, it is possible to use either a single protocol or multiple protocols to achieve this. can be confusing. Several times in the document 'protocol' is used to=20 refer both to the ForCES Protocol and to the possible protocols that=20 might comprise the ForCES protocol. I know what is meant here, but=20 everytime I read it, I need to stop and think. Perhaps some convention=20 of either capitalizing the 'protocol' in ForCES Protocol or using some=20 difficult phrase like component protocol will help with the=20 differentiation. - section 4.2.5 In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES protocol directly, a proxy FE can be used in the middle of Fp reference point. This allows the CE communicate to the physical FE via the proxy by using ForCES, while the proxy manipulates the physical FE using some intermediary form of communication (e.g., a non-ForCES protocol or DMA). In such an implementation, the combination of the proxy and the physical FE becomes one logical FE entity. I think that the Fp terminates at the proxy as opposed to the proxy=20 being at a midpoint. This is reinforced by the following sentence that=20 declares that proxy + non forCES FE comprises the FE. Question: is ther a one to one mapping between FE and proxies. Could=20 a Proxy serve several non ForCES FEs and would they be seen as a single=20 FE by the CE. I think so, but I am not sure. - section 4.3.1 This only pertains when the entire CE set falls. If an individual CE=20 falls then the circumstance may be different. From eigpress@bol.com.br Fri Jan 9 20:10:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03218 for ; Fri, 9 Jan 2004 20:10:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af7eJ-0002BG-00 for forces-archive@ietf.org; Fri, 09 Jan 2004 20:10:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af7ck-00020M-00 for forces-archive@ietf.org; Fri, 09 Jan 2004 20:09:12 -0500 Received: from [202.101.145.196] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1Af7ap-0001nl-00; Fri, 09 Jan 2004 20:07:15 -0500 From: "Temas Patrulhados" To: enum@ietf.org Subject: Lindenberg e o Clero "sem-microfone" ref.: txj X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 09 Jan 2004 20:07:15 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.3 required=5.0 tests=FORGED_MUA_EUDORA,HTML_40_50, HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora

Ref.: riy FreeAutomaticTranslator / TraductorGratuito / Retirar / SubscreverGratuitamente

Série Temas "Patrulhados" (2)

Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone

"Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na sua agenda o fim do boicote contra os sacerdotes sem-microfone?"

Adolpho Lindenberg

O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), incitando as invasões de terras promovidas pelo MST, criticando indiscriminadamente a Área de Livre Comércio das Américas (ALCA), as privatizações, as multinacionais (as norte-americanas, em especial), e o plantio dos transgênicos, apresenta um inconveniente sério: tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados.

Movimentos contestatários

É contristador perceber que na vasta rede de movimentos contestatários que está sendo articulada por todo o país, a ala progressista religiosa - fruto das Comunidades de Base e da Comissão Pastoral da Terra (CPT) - se sobressai como o núcleo mais ativo e radical em suas convicções. Para esses movimentos de contestação é de fundamental importância dar a impressão de que expressam a opinião majoritária, ou pelo menos muito expressiva, do Episcopado e no Clero.

Não é verdade, necessariamente.

Uma minoria do Clero fala, a maioria está calada

A realidade profunda é bem outra. A maioria do Episcopado e do Clero, na realidade, não tem voz nem vez na grande mídia. Suas pastorais, sermões e opiniões não chegam ao grande público. Quase ninguém os conhece, só alguns paroquianos e amigos próximos, com quem compartilham confidências. Eles são os prelados e sacerdotes sem-microfone; pertencem à imensa maioria dos excluídos dos grandes meios de difusão. E muitos deles inteligentes, cultos, de expressão fácil, com reflexões que ajudariam muito à autêntica formação da opinião nacional. Até por exigência de equilíbrio na ponderação das opiniões e de equidade em relação a este setor social, eles também precisariam ser ouvidos.

Padres sem-microfone são discriminados

O grande número dos padres sem-microfone, muitas vezes, talvez na maioria esmagadora dos casos, teria reservas sérias com as invasões e depredações das propriedades agrícolas. Mas são discriminados, não são ouvidos pelo público. De nada adiantam suas advertências. Não repercutem. Estão excluídos. Para eles, não funciona a encenação publicitária aparatosa, suas opiniões são ignoradas pela grande imprensa, o que acontece por exemplo no caso de "O Grito dos Excluídos". É que, para azar deles, nem estão entre os promotores da revolução social, nem pertencem aos pequenos grupos dos privilegiados pela mídia.

Excluir a exclusão

É preciso que se inclua entre os formadores de opinião, com acesso à mídia, também os prelados e sacerdotes que hoje estão sem microfone. Por que deixá-los de fora? Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na agenda já tão abrangente do "Grito dos Excluídos" também o fim do boicote contra os sacerdotes sem-microfone? Afinal de contas, não se proclamam os seus participantes em batalha contra as exclusões, pelo fim das discriminações? Ou é que umas exclusões podem existir, e são bem-vindas, e outras não? Se for assim afastam-se do que deseja o povo, pois milhões de brasileiros querem saber o que pensa o Clero sem-microfone.

Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado".

LINKS:

Lindenberg:Concordo (envie seu voto virtual, e, melhor ainda, acrescente seu comentário, caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores / GratuitamenteProximosArtigos / GratuitamenteTodosOsArtigos

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirLivroEmPortugal (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora em Portugal; preço: E 19,45)

Lindenberg:DesejoAdquirirLivroNoBrasil (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora no Brasil, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais Correio)

LINK DE REMOÇÃO

ConstruNews:Remover

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 9 20:20:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03988 for ; Fri, 9 Jan 2004 20:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af7nP-0002u7-00 for forces-archive@ietf.org; Fri, 09 Jan 2004 20:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af7lr-0002n8-00 for forces-archive@ietf.org; Fri, 09 Jan 2004 20:18:36 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Af7kO-0002dq-00 for forces-archive@IETF.ORG; Fri, 09 Jan 2004 20:17:04 -0500 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.00C9C80B@cherry.ease.lsoft.com>; Fri, 9 Jan 2004 20:17:05 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67404449 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 9 Jan 2004 20:17:03 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 9 Jan 2004 20:17:03 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0A1IBgW003943; Sat, 10 Jan 2004 01:18:11 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0A1EXcK004940; Sat, 10 Jan 2004 01:14:46 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010917144613531 ; Fri, 09 Jan 2004 17:14:47 -0800 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, 9 Jan 2004 17:14:06 -0800 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: Comments on framework-12 Thread-Index: AcPVxaU0tKikpcLkQHaPL7RLyEJRSwBToEJAAABRSeA= X-OriginalArrivalTime: 10 Jan 2004 01:14:06.0432 (UTC) FILETIME=[0AF16E00:01C3D717] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0BF@orsmsx410.jf.intel.com> Date: Fri, 9 Jan 2004 17:14:05 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Comments on framework-12 Comments: To: avri@psg.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable my reponse in line ...=20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Yang, Lily L > Sent: Friday, January 09, 2004 4:55 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: FW: Comments on framework-12 >=20 >=20 > I received these comments from Avri on the framework... >=20 > -----Original Message----- > From: avri [mailto:avri@psg.com] > Sent: Thursday, January 08, 2004 12:59 AM > To: Yang, Lily L > Subject: Comments on framework-12 >=20 >=20 > Hi, >=20 > I know this is very late, but decided to reread the whole document as=20 > opposed to just the changes. Apologies. I am just getting deeply=20 > involved in a ForCES project so I am rereading everything with fresh=20 > eyes. >=20 > - Definitions >=20 > Pre-association Phase - The period of time during which an FE > Manager (see below) and a CE Manager (see below) are determining > which FE and CE should be part of the same network element. >=20 > As I have mentioned in other posting, this phase is likely to=20 > last long=20 > into the post-association phase. I think it might be better to cast=20 > the definition in terms of a single CE-FE association. >=20 > Suggestion: >=20 > Pre-association Phase - The period of time during which an FE > Manager (see below) and a CE Manager (see below) are determining > whether an FE and a CE should be part of the same=20 > network element. > It is possible for some elements of the NE to be in=20 > pre-association=20 > phase > while other elements are in the post-association phase. >=20 > - section 3 >=20 > There is no > defined role for FE Manager and CE Manager in post-association > phase, thus these logical components are not considered=20 > part of the > ForCES NE. >=20 > I think this is misleading for the same reason given above. The idea=20 > of pre and post association belongs to the 2 elements and not=20 > to the NE=20 > at large. A dynamic system may have elements in=20 > pre-association as it=20 > has elements in post-association. I recommend dropping the sentence. >=20 Good point. I like the idea of tieing pre- and post- association phase = with individual CE/FE but not NE. It is conceptually more accurate. >=20 > - section 3.2 >=20 > Instead, FEs > accept commands from any CE authorized to control them, and it is > up to the CEs to coordinate among themselves to achieve=20 > redundancy, > load sharing or distributed control. >=20 > I am assuming that the FE accepts commands on a first come=20 > first served=20 > basis. If so, this should probably be said. If not, then=20 > the possible=20 > existence of a prioritization scheme should be mentioned. I would argue that such semantic details belong to the protocol, not = framework.=20 >=20 > -section 4.1 Pre-association phase >=20 > Pre-association phase is the period of time during which an FE > Manager and a CE Manager are determining which FE and CE=20 > should be > part of the same network element. >=20 > Same comments as made above for the definition of the pre-association=20 > phase. >=20 > - section 4.1.1 >=20 > this section reflects the same notion that the pre-association phase=20 > occurs at a singular moment of time in the system. >=20 > the CE > and FE managers communicate to determine which CEs and FEs should > communicate with each other. >=20 > suggest: >=20 > the CE and FE managers communicate to determine whether > an individual CE and FE, or a set of CEs and FEs, should be=20 > associated. >=20 > - section 4.2.2 - message exchange diagram >=20 > I think that since the delivery of inter-FE toplogy is optional, the=20 > diagram should indicate this. I would just delete the inter-FE topology messages here, since what we = show is just a conceptual example.=20 >=20 > - section 4.2.2. >=20 > Once FE starts > accepting packets for processing, we say the association=20 > of this FE > with its CE is now established. >=20 > This may be a pedantic point, but I would think that the the=20 > association needs to be established before the process of accepting=20 > packets for forwarding occurs. >=20 > Suggest: >=20 > Once the necessary exchange of initial information is exchanged, > the process of association can be completed. Processing packets > for forwarding cannot begin until association is established. >=20 >=20 > - section 4.2.4 >=20 > I think the language in: >=20 > In light of the fact that the ForCES protocol is responsible for > transporting both the control messages and the data=20 > packets between > the CE and FE over Fp reference point, it is possible to=20 > use either > a single protocol or multiple protocols to achieve this. >=20 > can be confusing. Several times in the document 'protocol'=20 > is used to=20 > refer both to the ForCES Protocol and to the possible protocols that=20 > might comprise the ForCES protocol. I know what is meant here, but=20 > everytime I read it, I need to stop and think. Perhaps some=20 > convention=20 > of either capitalizing the 'protocol' in ForCES Protocol or=20 > using some=20 > difficult phrase like component protocol will help with the=20 > differentiation. Yeah, I will clean up the language. >=20 > - section 4.2.5 >=20 > In the case where a physical FE cannot implement (e.g.,=20 > due to the > lack of a general purpose CPU) the ForCES protocol directly, a > proxy FE can be used in the middle of Fp reference point. This > allows the CE communicate to the physical FE via the=20 > proxy by using > ForCES, while the proxy manipulates the physical FE using some > intermediary form of communication (e.g., a non-ForCES=20 > protocol or > DMA). In such an implementation, the combination of the=20 > proxy and > the physical FE becomes one logical FE entity. >=20 > I think that the Fp terminates at the proxy as opposed to the proxy=20 > being at a midpoint. This is reinforced by the following=20 > sentence that=20 > declares that proxy + non forCES FE comprises the FE. Yes. I will fix that. >=20 > Question: is ther a one to one mapping between FE and=20 > proxies. Could=20 > a Proxy serve several non ForCES FEs and would they be seen=20 > as a single=20 > FE by the CE. I think so, but I am not sure. Yes. I will add a sentence to that effect. >=20 > - section 4.3.1 >=20 > This only pertains when the entire CE set falls. If an individual CE=20 > falls then the circumstance may be different. You are right. Will mention this. >=20 From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 11 20:00:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24768 for ; Sun, 11 Jan 2004 20:00:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfqRc-0006bS-00 for forces-archive@ietf.org; Sun, 11 Jan 2004 20:00:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfqPh-0006VC-00 for forces-archive@ietf.org; Sun, 11 Jan 2004 19:58:41 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AfqNk-0006Om-00 for forces-archive@IETF.ORG; Sun, 11 Jan 2004 19:56:40 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C9EDCF@cherry.ease.lsoft.com>; 11 Jan 2004 19:56:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67613737 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 11 Jan 2004 19:56:39 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jan 2004 19:56:39 -0500 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfqNd-000Nt6-Ln for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 00:56:37 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.553) Approved-By: avri@ACM.ORG Message-ID: <233626BC-449A-11D8-8C3B-000393CC2112@acm.org> Date: Mon, 12 Jan 2004 09:56:21 +0900 Reply-To: avri@acm.org Sender: Forwarding and Control Element Separation From: avri@acm.org Subject: Re: Comments on framework-12 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CB0BF@orsmsx410.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable On l=F6rdag, jan 10, 2004, at 10:14 Asia/Seoul, Yang, Lily L wrote: >> >> - section 3.2 >> >> Instead, FEs >> accept commands from any CE authorized to control them, and it = is >> up to the CEs to coordinate among themselves to achieve >> redundancy, >> load sharing or distributed control. >> >> I am assuming that the FE accepts commands on a first come >> first served >> basis. If so, this should probably be said. If not, then >> the possible >> existence of a prioritization scheme should be mentioned. > > I would argue that such semantic details belong to the protocol, not=20= > framework. Well while the specific behavior and they way it is negotiated if there=20= is an option would be a protocol issue, I think it might be appropriate=20= for the framework to assume a default behavior. And if more behaviors=20= are possible then a negotiation of behavior pattern is probably in=20 order. I think this is a more a negotiated (if there are option - and I think=20= there will be) behavioral pattern then a semantic issue. a. From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 11 21:35:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26641 for ; Sun, 11 Jan 2004 21:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afrvb-0001aC-00 for forces-archive@ietf.org; Sun, 11 Jan 2004 21:35:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afrql-0001Su-00 for forces-archive@ietf.org; Sun, 11 Jan 2004 21:30:43 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AfrnF-0001MO-00 for forces-archive@IETF.ORG; Sun, 11 Jan 2004 21:27:05 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00C9EE91@cherry.ease.lsoft.com>; 11 Jan 2004 21:26:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67618509 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 11 Jan 2004 21:26:34 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jan 2004 21:26:34 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0C2RgLU000679; Mon, 12 Jan 2004 02:27:42 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0C2O6vn009129; Mon, 12 Jan 2004 02:24:10 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011118263106114 ; Sun, 11 Jan 2004 18:26:31 -0800 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, 11 Jan 2004 18:26:31 -0800 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: Comments on framework-12 Thread-Index: AcPYpvU9uSx6BK9+Sn+G4zEQ/luxsQAC7daw X-OriginalArrivalTime: 12 Jan 2004 02:26:31.0247 (UTC) FILETIME=[7D7B15F0:01C3D8B3] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0C9@orsmsx410.jf.intel.com> Date: Sun, 11 Jan 2004 18:26:30 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Comments on framework-12 Comments: To: avri@acm.org To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I suppose at the minimum we can mention the default behavior=20 (first come first served) in the framework.=20 One exception is command bundling, meaning all or nothing.=20 By prioritization, did you mean prioritization between the control msg = and data packets, or prioritization among the control msgs? The former = is most likely needed, but I am not so sure about the latter. Maybe the = protocol people can comment on this what is the current thinking on = this? -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of avri@acm.org Sent: Sunday, January 11, 2004 4:56 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Comments on framework-12 On l=F6rdag, jan 10, 2004, at 10:14 Asia/Seoul, Yang, Lily L wrote: >> >> - section 3.2 >> >> Instead, FEs >> accept commands from any CE authorized to control them, and it = is >> up to the CEs to coordinate among themselves to achieve >> redundancy, >> load sharing or distributed control. >> >> I am assuming that the FE accepts commands on a first come >> first served >> basis. If so, this should probably be said. If not, then >> the possible >> existence of a prioritization scheme should be mentioned. > > I would argue that such semantic details belong to the protocol, not=20 > framework. Well while the specific behavior and they way it is negotiated if there=20 is an option would be a protocol issue, I think it might be appropriate=20 for the framework to assume a default behavior. And if more behaviors=20 are possible then a negotiation of behavior pattern is probably in=20 order. I think this is a more a negotiated (if there are option - and I think=20 there will be) behavioral pattern then a semantic issue. a. From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 11 22:35:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28040 for ; Sun, 11 Jan 2004 22:35:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfsrI-0003bb-00 for forces-archive@ietf.org; Sun, 11 Jan 2004 22:35:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afso7-0003WO-00 for forces-archive@ietf.org; Sun, 11 Jan 2004 22:32:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Afsl6-0003Ri-00 for forces-archive@IETF.ORG; Sun, 11 Jan 2004 22:28:56 -0500 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.00C9EE45@cherry.ease.lsoft.com>; 11 Jan 2004 22:28:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67620671 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 11 Jan 2004 22:28:31 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jan 2004 22:28:31 -0500 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004011119270586:44147 ; Sun, 11 Jan 2004 19:27:05 -0800 References: <26BDFAFFB541B047B24179002EBE6D278CB0C9@orsmsx410.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 01/11/2004 07:27:06 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2004 07:27:08 PM, Serialize complete at 01/11/2004 07:27:08 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1073878107.1119.325.camel@jzny.localdomain> Date: Sun, 11 Jan 2004 22:28:27 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Comments on framework-12 Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CB0C9@orsmsx410.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Sun, 2004-01-11 at 21:26, Yang, Lily L wrote: > I suppose at the minimum we can mention the default behavior > (first come first served) in the framework. Unfortunatly that would be defining one way to do it. Another scheme is to make it totaly tranparent for the FE. In other words if the FE got the illusion it was receiving commands from a single CE, then the goal is also achieved. So i would have to go with your former assertion that this is a protocol semantic issue. > One exception is command bundling, meaning all or nothing. > > By prioritization, did you mean prioritization between the > control msg and data packets, or prioritization among the control msgs? > The former is most likely needed, but I am not so sure about the latter. > Maybe the protocol people can comment on this what is the current thinking > on this? > I believe she meant that in a scheme where the FE is aware of the multiple CEs controlling say the same LFB, then something would have to be built into the protocol to prioritize which of the multiple CEs (controling an LFB) should take precedence when they issue conflicting commands. Given that this is not the only mechanism possible, i would suggest we leave the details out or talk about both known possibilities of operation. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 11 23:33:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29660 for ; Sun, 11 Jan 2004 23:33:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AftlA-0005tw-00 for forces-archive@ietf.org; Sun, 11 Jan 2004 23:33:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afth0-0005nx-00 for forces-archive@ietf.org; Sun, 11 Jan 2004 23:28:47 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AftdW-0005jb-00 for forces-archive@IETF.ORG; Sun, 11 Jan 2004 23:25:10 -0500 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.00C9F28A@cherry.ease.lsoft.com>; 11 Jan 2004 23:24:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67624428 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 11 Jan 2004 23:24:57 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jan 2004 23:24:57 -0500 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AftdF-0002DG-Pj for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 04:24:55 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.553) Approved-By: avri@ACM.ORG Message-ID: <3E8F648B-44B7-11D8-8C3B-000393CC2112@acm.org> Date: Mon, 12 Jan 2004 13:24:42 +0900 Reply-To: avri@acm.org Sender: Forwarding and Control Element Separation From: avri@acm.org Subject: Re: Comments on framework-12 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1073878107.1119.325.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable On m=E5ndag, jan 12, 2004, at 12:28 Asia/Seoul, Jamal Hadi Salim wrote: > On Sun, 2004-01-11 at 21:26, Yang, Lily L wrote: >> I suppose at the minimum we can mention the default behavior >> (first come first served) in the framework. > > Unfortunatly that would be defining one way to do it. > Another scheme is to make it totaly tranparent for the FE. > In other words if the FE got the illusion it was receiving > commands from a single CE, then the goal is also achieved. > So i would have to go with your former assertion that this is > a protocol semantic issue. I am not looking to define what the relation should be, though i did=20 assume a default behavior. What I am looking for is that we acknowledge that if there is more then=20= one behavior then the framework should indicate that there needs to be=20= exchange between the CE and FE about the behavior to be applied. I also think it reasonable that there be a default behavior established=20= in the Framework, and that then the semantics of the protocol can=20 include a method for negotiation of a different behavior. As for how a 'first come first served' was done, i don't think it makes=20= a great deal of difference. =46rom the FE. perspective. Whether there=20= is a Unified CE or many cooperating CEs sending the FE still processes=20= first come first served. > >> One exception is command bundling, meaning all or nothing. >> >> By prioritization, did you mean prioritization between the >> control msg and data packets, or prioritization among the control=20 >> msgs? >> The former is most likely needed, but I am not so sure about the=20 >> latter. >> Maybe the protocol people can comment on this what is the current=20 >> thinking >> on this? >> > > I believe she meant that in a scheme where the FE is aware of the > multiple CEs controlling say the same LFB, then something would > have to be built into the protocol to prioritize which of the > multiple CEs (controling an LFB) should take precedence when they = issue > conflicting commands. > Given that this is not the only mechanism possible, i would suggest we > leave the details out or talk about both known possibilities of > operation. Or just talk about the fact that this needs to be established soon=20 after an association is established. I also think we have to determine if this is a system wide behavior,=20 i.e. all FEs in the NE behave in the same manner for each instance of=20 an established NE (being an NE with at least one established CE-FE=20 association) or whether it is specific to each CE-FE association or,=20 something I had not thought of, specific to a single LFB. a.= From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 10:17:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01731 for ; Mon, 12 Jan 2004 10:17:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3oM-0006z1-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 10:17:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag3mX-0006wE-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 10:15:10 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ag3l8-0006tM-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 10:13:43 -0500 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.00C9FBA2@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 10:13:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67707853 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 10:13:35 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 10:13:35 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004011207120970:44460 ; Mon, 12 Jan 2004 07:12:09 -0800 References: <3E8F648B-44B7-11D8-8C3B-000393CC2112@acm.org> 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 01/12/2004 07:12:09 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/12/2004 07:12:12 AM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Approved-By: Jamal Hadi Salim Message-ID: <1073920411.1029.28.camel@jzny.localdomain> Date: Mon, 12 Jan 2004 10:13:31 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Comments on framework-12 Comments: To: avri@acm.org To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <3E8F648B-44B7-11D8-8C3B-000393CC2112@acm.org> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 T24gU3VuLCAyMDA0LTAxLTExIGF0IDIzOjI0LCBhdnJpQGFjbS5vcmcgd3JvdGU6DQo+IE9uIG3l bmRhZywgamFuIDEyLCAyMDA0LCBhdCAxMjoyOCBBc2lhL1Nlb3VsLCBKYW1hbCBIYWRpIFNhbGlt IHdyb3RlOg0KPg0KPiANCj4gV2hhdCBJIGFtIGxvb2tpbmcgZm9yIGlzIHRoYXQgd2UgYWNrbm93 bGVkZ2UgdGhhdCBpZiB0aGVyZSBpcyBtb3JlIHRoZW4gDQo+IG9uZSBiZWhhdmlvciB0aGVuIHRo ZSBmcmFtZXdvcmsgc2hvdWxkIGluZGljYXRlIHRoYXQgIHRoZXJlIG5lZWRzIHRvIGJlIA0KPiBl eGNoYW5nZSBiZXR3ZWVuIHRoZSBDRSBhbmQgRkUgYWJvdXQgdGhlIGJlaGF2aW9yIHRvIGJlIGFw cGxpZWQuDQo+IA0KDQpJIGFncmVlIGl0IGlzIGEgZ29vZCBpZGVhIHRvIGRlc2NyaWJlIHRoZSBw b3NzaWJsZSB3YXlzIHRvIGFjaGlldmUgdGhlDQplbmQgZ29hbCBzaW5jZSB0aGUgcHJvdG9jb2wg dGFsa3Mgb25seSBhYm91dCByZXF1aXJpbmcgbWVjaGFuaXNtcyB0byBiZQ0KcHJvdmlkZWQuIA0K V2hhdCB5b3UgcmVmZXIgdG8gYWJvdmUgd2lsbCBiZSBuZWVkZWQgaWYgdGhlIHNjaGVtZSBpcyBu b3QgdHJhbnNwYXJlbnQNCnRvIHRoZSBGRSAod2hpY2ggaXMgYWNoaWV2YWJsZSBpZiB5b3UgdXNl IGEgbXVsdGljYXN0IG9yIGJyb2FkY2FzdCB3aXJlKS4NCkluIHRoZSBjb3VwbGUgb2Ygbm9uLXRy YW5zcGFyZW50IHNjaGVtZXMgaSBjb3VsZCB0aGluayBvZiwNCnRoZSBGRSB3aWxsIGhhdmUgdG8g YmUgaW52b2x2ZWQgaW4gbWlncmF0aW9ucyBhbmQgbWF5IG5lZWQgdG8gYmUNCmV4cGxpY2l0bHkg dG9sZCB0byBkbyBzby4gDQoNCj4gSSBhbHNvIHRoaW5rIGl0IHJlYXNvbmFibGUgdGhhdCB0aGVy ZSBiZSBhIGRlZmF1bHQgYmVoYXZpb3IgZXN0YWJsaXNoZWQgDQo+IGluIHRoZSBGcmFtZXdvcmss IGFuZCB0aGF0IHRoZW4gdGhlIHNlbWFudGljcyBvZiB0aGUgcHJvdG9jb2wgY2FuIA0KPiBpbmNs dWRlIGEgbWV0aG9kIGZvciBuZWdvdGlhdGlvbiBvZiBhIGRpZmZlcmVudCBiZWhhdmlvci4NCj4g DQoNCklmIHlvdSBhc3N1bWVkIHRoZSBub24tdHJhbnNwYXJlbnQgc2NoZW1lIHRoZW4gaXQgd2ls bCBiZSBmYWlyIHRvIG1ha2UNCnN1Y2ggYSBkZWZhdWx0IHNwZWNpZmljYXRpb24uDQoNCkNvdWxk IHdlIGluc3RlYWQgb2YgaGF2aW5nIGl0IGFzIHBhcnQgb2YgdGhlIHByb3RvY29sIGhhdmUgdGhp cyBiZSBsZWZ0IA0KdG8geEVNICh4PSBGIG9yIEMpaW50ZXJmYWNlPyBJIGFtIGp1c3Qgd29ycmll ZCBhYm91dCBjaHJpc3RtYXMgdHJlZWluZy4NClRoYXQgZG9lc250IG1lYW4gaXQgc2hvdWxkbnQg YmUgaW4gdGhlIGRyYWZ0Lg0KDQoNCmNoZWVycywNCmphbWFsDQoNCg== From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 10:43:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02747 for ; Mon, 12 Jan 2004 10:43:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4E1-0000H0-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 10:43:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4DI-00008w-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 10:42:51 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ag47C-0007hP-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 10:36:30 -0500 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.00C9FC77@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 10:36:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67709382 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 10:36:18 -0500 Received: from 218.108.250.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 10:36:17 -0500 Received: from wwm1([218.108.154.51]) by hzcnc.com(AIMC 2.9.5.3) with SMTP id jm44002f1b5; Mon, 12 Jan 2004 23:34:36 +0800 References: <3E8F648B-44B7-11D8-8C3B-000393CC2112@acm.org> 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: <00fa01c3d921$845188f0$010aa8c0@wwm1> Date: Mon, 12 Jan 2004 23:34:06 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Comments on framework-12 Comments: cc: Wang Weiming To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 SGksDQoNClRhbGtpbmcgYWJvdXQgcHJveHkgRkUsIEkgdGhpbmsgb2YgYSBwb3NzaWJpbGl0eSB0 byBhbGxvdyBhIENFIHByb3h5IHRvIHN1cHBvcnQgY29udHJvbCBmb3IgbXVsdGlob3AgY2FzZS4N CkEgQ0UgcHJveHkgaXMgcHV0IGxvY2FsbHkgd2l0aCBhIGJ1bmNoIG9mIEZFcyAoZXZlbiBpbiBv bmUgY2hhc2lzKSwgd2hpbGUgYW4gYWN0dWFsIENFIGlzIG11bHRpaG9wcyBhd2F5Lg0KVGhpcyBz ZWVtcyBtYWtlIG11bHRpaG9wIGNhc2UgbW9yZSBsaWtlIGEgbG9jYWwgY2FzZS4gIFRoZSBwb3Nz aWJsZSBiZW5pZml0cyBtYXkgYmUgdGhhdCBsaWtlIG1ha2luZyBzZWN1cml5DQpjb25zaWRlcmF0 aW9uIGZvciBtdWx0aWhvcHMgc2ltcGxlciBhbmQgbWFraW5nIHNlY3VyZSBicm9hZGNhc3QvbXVs dGljYXN0ICBmb3IgRm9yQ0VTIHByb3RvY29sIHBvc3NpYmxlLiANCg0KUmVnYXJkcywNCg0KV2Vp bWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPGF2cmlAYWNtLm9y Zz4NClRvOiA8Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NPg0KU2VudDogTW9uZGF5LCBKYW51 YXJ5IDEyLCAyMDA0IDEyOjI0IFBNDQpTdWJqZWN0OiBSZTogQ29tbWVudHMgb24gZnJhbWV3b3Jr LTEyDQoNCg0KT24gbeVuZGFnLCBqYW4gMTIsIDIwMDQsIGF0IDEyOjI4IEFzaWEvU2VvdWwsIEph bWFsIEhhZGkgU2FsaW0gd3JvdGU6DQoNCj4gT24gU3VuLCAyMDA0LTAxLTExIGF0IDIxOjI2LCBZ YW5nLCBMaWx5IEwgd3JvdGU6DQo+PiBJIHN1cHBvc2UgYXQgdGhlIG1pbmltdW0gd2UgY2FuIG1l bnRpb24gdGhlIGRlZmF1bHQgYmVoYXZpb3INCj4+IChmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCkg aW4gdGhlIGZyYW1ld29yay4NCj4NCj4gVW5mb3J0dW5hdGx5IHRoYXQgd291bGQgYmUgZGVmaW5p bmcgb25lIHdheSB0byBkbyBpdC4NCj4gQW5vdGhlciBzY2hlbWUgaXMgdG8gbWFrZSBpdCB0b3Rh bHkgdHJhbnBhcmVudCBmb3IgdGhlIEZFLg0KPiBJbiBvdGhlciB3b3JkcyBpZiB0aGUgRkUgZ290 IHRoZSBpbGx1c2lvbiBpdCB3YXMgcmVjZWl2aW5nDQo+IGNvbW1hbmRzIGZyb20gYSBzaW5nbGUg Q0UsIHRoZW4gdGhlIGdvYWwgaXMgYWxzbyBhY2hpZXZlZC4NCj4gU28gaSB3b3VsZCBoYXZlIHRv IGdvIHdpdGggeW91ciBmb3JtZXIgYXNzZXJ0aW9uIHRoYXQgdGhpcyBpcw0KPiBhIHByb3RvY29s IHNlbWFudGljIGlzc3VlLg0KDQpJIGFtIG5vdCBsb29raW5nIHRvIGRlZmluZSB3aGF0IHRoZSBy ZWxhdGlvbiBzaG91bGQgYmUsIHRob3VnaCBpIGRpZCANCmFzc3VtZSBhIGRlZmF1bHQgYmVoYXZp b3IuDQoNCldoYXQgSSBhbSBsb29raW5nIGZvciBpcyB0aGF0IHdlIGFja25vd2xlZGdlIHRoYXQg aWYgdGhlcmUgaXMgbW9yZSB0aGVuIA0Kb25lIGJlaGF2aW9yIHRoZW4gdGhlIGZyYW1ld29yayBz aG91bGQgaW5kaWNhdGUgdGhhdCAgdGhlcmUgbmVlZHMgdG8gYmUgDQpleGNoYW5nZSBiZXR3ZWVu IHRoZSBDRSBhbmQgRkUgYWJvdXQgdGhlIGJlaGF2aW9yIHRvIGJlIGFwcGxpZWQuDQoNCkkgYWxz byB0aGluayBpdCByZWFzb25hYmxlIHRoYXQgdGhlcmUgYmUgYSBkZWZhdWx0IGJlaGF2aW9yIGVz dGFibGlzaGVkIA0KaW4gdGhlIEZyYW1ld29yaywgYW5kIHRoYXQgdGhlbiB0aGUgc2VtYW50aWNz IG9mIHRoZSBwcm90b2NvbCBjYW4gDQppbmNsdWRlIGEgbWV0aG9kIGZvciBuZWdvdGlhdGlvbiBv ZiBhIGRpZmZlcmVudCBiZWhhdmlvci4NCg0KQXMgZm9yIGhvdyBhICdmaXJzdCBjb21lIGZpcnN0 IHNlcnZlZCcgd2FzIGRvbmUsIGkgZG9uJ3QgdGhpbmsgaXQgbWFrZXMgDQphIGdyZWF0IGRlYWwg b2YgZGlmZmVyZW5jZS4gIEZyb20gdGhlIEZFLiAgcGVyc3BlY3RpdmUuICBXaGV0aGVyIHRoZXJl IA0KaXMgYSBVbmlmaWVkIENFIG9yIG1hbnkgY29vcGVyYXRpbmcgQ0VzIHNlbmRpbmcgdGhlIEZF IHN0aWxsIHByb2Nlc3NlcyANCmZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkLg0KDQo+DQo+PiBPbmUg ZXhjZXB0aW9uIGlzIGNvbW1hbmQgYnVuZGxpbmcsIG1lYW5pbmcgYWxsIG9yIG5vdGhpbmcuDQo+ Pg0KPj4gQnkgcHJpb3JpdGl6YXRpb24sIGRpZCB5b3UgbWVhbiBwcmlvcml0aXphdGlvbiBiZXR3 ZWVuIHRoZQ0KPj4gY29udHJvbCBtc2cgYW5kIGRhdGEgcGFja2V0cywgb3IgcHJpb3JpdGl6YXRp b24gYW1vbmcgdGhlIGNvbnRyb2wgDQo+PiBtc2dzPw0KPj4gVGhlIGZvcm1lciBpcyBtb3N0IGxp a2VseSBuZWVkZWQsIGJ1dCBJIGFtIG5vdCBzbyBzdXJlIGFib3V0IHRoZSANCj4+IGxhdHRlci4N Cj4+ICBNYXliZSB0aGUgcHJvdG9jb2wgcGVvcGxlIGNhbiBjb21tZW50IG9uIHRoaXMgd2hhdCBp cyB0aGUgY3VycmVudCANCj4+IHRoaW5raW5nDQo+PiAgb24gdGhpcz8NCj4+DQo+DQo+IEkgYmVs aWV2ZSBzaGUgbWVhbnQgdGhhdCBpbiBhIHNjaGVtZSB3aGVyZSB0aGUgRkUgaXMgYXdhcmUgb2Yg dGhlDQo+IG11bHRpcGxlIENFcyBjb250cm9sbGluZyBzYXkgdGhlIHNhbWUgTEZCLCB0aGVuIHNv bWV0aGluZyB3b3VsZA0KPiBoYXZlIHRvIGJlIGJ1aWx0IGludG8gdGhlIHByb3RvY29sIHRvIHBy aW9yaXRpemUgd2hpY2ggb2YgdGhlDQo+IG11bHRpcGxlIENFcyAoY29udHJvbGluZyBhbiBMRkIp IHNob3VsZCB0YWtlIHByZWNlZGVuY2Ugd2hlbiB0aGV5IGlzc3VlDQo+IGNvbmZsaWN0aW5nIGNv bW1hbmRzLg0KPiBHaXZlbiB0aGF0IHRoaXMgaXMgbm90IHRoZSBvbmx5IG1lY2hhbmlzbSBwb3Nz aWJsZSwgaSB3b3VsZCBzdWdnZXN0IHdlDQo+IGxlYXZlIHRoZSBkZXRhaWxzIG91dCBvciB0YWxr IGFib3V0IGJvdGgga25vd24gcG9zc2liaWxpdGllcyBvZg0KPiBvcGVyYXRpb24uDQoNCk9yIGp1 c3QgdGFsayBhYm91dCB0aGUgZmFjdCB0aGF0IHRoaXMgbmVlZHMgdG8gYmUgZXN0YWJsaXNoZWQg c29vbiANCmFmdGVyIGFuIGFzc29jaWF0aW9uIGlzIGVzdGFibGlzaGVkLg0KDQpJIGFsc28gdGhp bmsgd2UgaGF2ZSB0byBkZXRlcm1pbmUgaWYgdGhpcyBpcyBhIHN5c3RlbSB3aWRlIGJlaGF2aW9y LCANCmkuZS4gYWxsIEZFcyBpbiB0aGUgTkUgYmVoYXZlIGluIHRoZSBzYW1lIG1hbm5lciBmb3Ig ZWFjaCBpbnN0YW5jZSBvZiANCmFuIGVzdGFibGlzaGVkIE5FIChiZWluZyBhbiBORSB3aXRoIGF0 IGxlYXN0IG9uZSBlc3RhYmxpc2hlZCBDRS1GRSANCmFzc29jaWF0aW9uKSBvciB3aGV0aGVyIGl0 IGlzIHNwZWNpZmljIHRvIGVhY2ggQ0UtRkUgYXNzb2NpYXRpb24gb3IsIA0Kc29tZXRoaW5nIEkg aGFkIG5vdCB0aG91Z2h0IG9mLCBzcGVjaWZpYyB0byBhIHNpbmdsZSBMRkIuDQoNCmEu From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 12:25:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06697 for ; Mon, 12 Jan 2004 12:25:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag5oN-0004ef-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 12:25:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag5mV-0004ck-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 12:23:16 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ag5mB-0004Zm-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 12:22:55 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00C9FD78@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 12:22:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67719362 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 12:22:53 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 12:22:53 -0500 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0CHP0BX008978; Mon, 12 Jan 2004 17:25:00 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0CHM3fR022182; Mon, 12 Jan 2004 17:23:31 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011209224912351 ; Mon, 12 Jan 2004 09:22:49 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jan 2004 09:22:49 -0800 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 Framework Last Call for Comments (was: ForCES framework: summary of comments from Russ Housley and authors' respond) Thread-Index: AcPHM/e6HW7Y0aKkQMOXqFt7mFoSEAQEIFQQ X-OriginalArrivalTime: 12 Jan 2004 17:22:49.0701 (UTC) FILETIME=[B3EFF150:01C3D930] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0CC@orsmsx410.jf.intel.com> Date: Mon, 12 Jan 2004 09:22:48 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: ForCES Framework Last Call for Comments (was: ForCES framework: summary of comments from Russ Housley and authors' respond) Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Jamal -- See my comments below in line starting with [lily]. I also have further questions for the last two comments. I would appreciate it if you can elaborate. Thanks for taking the time to review the document in full. Lily -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Saturday, December 20, 2003 12:01 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: ForCES Framework Last Call for Comments (was: ForCES framework: summary of comments from Russ Housley and authors' respond) Lily et al, I think this draft is ready. The only issue i have is on section 8. Could you move section 8.2.1 and make it section 8.1 ? I think that it makes more sense to talk about NE security admin/config right at the beggining of section 8 so you can set context for the rest of the text. You can still point to the DoS concerns at that section as you do now if you want. [Lily]: I still prefer the current order because it flows better. 8.1 is about threats, and 8.2 is about the solution at high level. So moving 8.2.1 in front of threats do not flow naturally.=20 Other comments: - Section 2: I think the term "vendor" (which leaves a marketing after taste) should really be replaced with "implementor". [Lily] Ok. I personally have no problem with either, generally speaking. So I tried replacing all the "vendors" with "implementers" but it reads kind of weird in the context. So I changed back.=20 - General section 3: and the Fx references; it may be a good idea to introduce the meaning of each "x". I noticed that the "p" is introduced later on in section 4.2 [Lily] Good idea. I will do that. - section 3.2 and the Fi ref point: I dont understand why a virtualized FE should be treated any different from a non-virtualized one. You seem to imply there may be some need for tricks to be played during pre-association phase. Additionaly that section seems to be focussed more on the Fp than Fi reference. [Lily] First of all, if one PFE is partitioned into several logical FEs, it should happen before post-association (so pre-association). Now it may even impact post-association phase if the resource changes dynamically. There has been some discussion and comments on this from both IESG and the list (most notably Avri). I think the current draft addressed the issue better now thanks to these comments. - section 4.3, last paragraph: An NE can not in post-association phase; the relation between a CE and FE may be. You may wanna find another term to describe what you are implying - example "operational" may be a good fit. [Lily] You are absolutely right here. Avri made the similar comment. I will fix this particular paragraph. - section 4.3.1 and 4.3.2: Both seem to be really focussed on routing restarts and OSPF in particular. I think those should be good examples; however, forces would be dealing with more than just forwarding tables; almost every LFB will have state tables syncronized between CE-FE which in my opinion could use graceful restarts. [Lily] I think that is a reasonable point. I did try to include all the notable references that are using graceful restart (OSPF, BGP and MPLS) but these are all routing-focused. My problem is that I am not aware of any other non-forwarding services using graceful restart. So if you have references I would love to hear about them. I like what you propose, but I do want to use examples that are in current practice today.=20 - section 5.1: Nitpick: Is it true that you need at least two interfaces to do routing? What would stop you from doing routing (changing NH paths) with a single interface? [Lily] We meant two logical interfaces. It could be just one physical interface. This is consistent with RFC1814. - section 5.7: I think it should also be noted that the FE may not run SNMP. The assumption with agentX is that both FE and CE run SNMP. [Lily] That is not what I understand. According to RFC2741: "Within the SNMP framework, a managed node contains a processing entity, called an agent, which has access to management information. Within the AgentX framework, an agent is further defined to consist of: - a single processing entity called the master agent, which sends and receives SNMP protocol messages in an agent role (as specified by the SNMP framework documents) but typically has little or no direct access to management information. - zero or more processing entities called subagents, which are "shielded" from the SNMP protocol messages processed by the master agent, but which have access to management information." Therefore, the FE does NOT run SNMP. That is the whole point. AgentX is run between CE and FE so that CE can run SNMP to collect MIB info from FE.=20 - section 8.1.4: " A malicious node can take over as CE-B if such trusted relationship is not established during the fail-over." should really read: " A malicious node can take over as CE-B if such trusted relationship has not been established prior or during the fail-over. " [Lily] agree. Will take your suggestion.=20 - section 8.1.8: I have never heard of congestion control algorithms as a solution to a DoS. I would suggest a backing of this via citing of some work or removing it as an example. [Lily]It should be removed. - section 8.2 in general Would it be useful to cite RFC 3631 in general? [Lily]That is a good reference for this section. - Section 8.2.2: Steps 1-6; those could happen between a FEM and CEM as well. The FE could then be informed by the FEM. If no, why not? If yes, could we add text to that effect? [Lily] I don't quite follow here. Since ForCES does not control what happens between FEM and CEM, it does not even care whether there is any relationship between FEM and CEM at all, we don't want to depend on the trust relationship between FEM and CEM for ForCES security, do we? - section 8.2.3 I think i am missing something, but why would replay protection be impossible if you have CEM-FEM communication and say FEM-FE communication being trusted? [lily] same comment as above. Overall, i think section 8 is highly improved and very good. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 12:39:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07399 for ; Mon, 12 Jan 2004 12:39:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag62W-0005UR-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 12:39:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag60Z-0005Q5-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 12:37:48 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ag5ya-0005Lz-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 12:35:44 -0500 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.00C9FD67@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 12:35:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67719800 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 12:35:40 -0500 Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 12:35:40 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i0CHZTIc023629; Mon, 12 Jan 2004 11:35:30 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <26BDFAFFB541B047B24179002EBE6D278CB0BE@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <4002DAE0.7CFAB1A5@alcatel.com> Date: Mon, 12 Jan 2004 11:35:28 -0600 Reply-To: alex.audu@alcatel.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: FW: Comments on framework-12 Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I think the mechanism or algorithm of how CEs distribute messages to the FEs is better left to the implemented policy in effect in the NE. Definitely it could be first-come-first-serve, but if you are running in load shared mode, some algorithm should be in place to spread the traffic amongst the FEs. Is it 50-50 loading, 20-80,.. it just depends on the policy active on the NE. Regards, Alex. "Yang, Lily L" wrote: > I received these comments from Avri on the framework... > > -----Original Message----- > From: avri [mailto:avri@psg.com] > Sent: Thursday, January 08, 2004 12:59 AM > To: Yang, Lily L > Subject: Comments on framework-12 > > Hi, > > I know this is very late, but decided to reread the whole document as > opposed to just the changes. Apologies. I am just getting deeply > involved in a ForCES project so I am rereading everything with fresh > eyes. > > - Definitions > > Pre-association Phase - The period of time during which an FE > Manager (see below) and a CE Manager (see below) are determining > which FE and CE should be part of the same network element. > > As I have mentioned in other posting, this phase is likely to last long > into the post-association phase. I think it might be better to cast > the definition in terms of a single CE-FE association. > > Suggestion: > > Pre-association Phase - The period of time during which an FE > Manager (see below) and a CE Manager (see below) are determining > whether an FE and a CE should be part of the same network element. > It is possible for some elements of the NE to be in pre-association > phase > while other elements are in the post-association phase. > > - section 3 > > There is no > defined role for FE Manager and CE Manager in post-association > phase, thus these logical components are not considered part of the > ForCES NE. > > I think this is misleading for the same reason given above. The idea > of pre and post association belongs to the 2 elements and not to the NE > at large. A dynamic system may have elements in pre-association as it > has elements in post-association. I recommend dropping the sentence. > > - section 3.2 > > Instead, FEs > accept commands from any CE authorized to control them, and it is > up to the CEs to coordinate among themselves to achieve redundancy, > load sharing or distributed control. > > I am assuming that the FE accepts commands on a first come first served > basis. If so, this should probably be said. If not, then the possible > existence of a prioritization scheme should be mentioned. > > -section 4.1 Pre-association phase > > Pre-association phase is the period of time during which an FE > Manager and a CE Manager are determining which FE and CE should be > part of the same network element. > > Same comments as made above for the definition of the pre-association > phase. > > - section 4.1.1 > > this section reflects the same notion that the pre-association phase > occurs at a singular moment of time in the system. > > the CE > and FE managers communicate to determine which CEs and FEs should > communicate with each other. > > suggest: > > the CE and FE managers communicate to determine whether > an individual CE and FE, or a set of CEs and FEs, should be > associated. > > - section 4.2.2 - message exchange diagram > > I think that since the delivery of inter-FE toplogy is optional, the > diagram should indicate this. > > - section 4.2.2. > > Once FE starts > accepting packets for processing, we say the association of this FE > with its CE is now established. > > This may be a pedantic point, but I would think that the the > association needs to be established before the process of accepting > packets for forwarding occurs. > > Suggest: > > Once the necessary exchange of initial information is exchanged, > the process of association can be completed. Processing packets > for forwarding cannot begin until association is established. > > - section 4.2.4 > > I think the language in: > > In light of the fact that the ForCES protocol is responsible for > transporting both the control messages and the data packets between > the CE and FE over Fp reference point, it is possible to use either > a single protocol or multiple protocols to achieve this. > > can be confusing. Several times in the document 'protocol' is used to > refer both to the ForCES Protocol and to the possible protocols that > might comprise the ForCES protocol. I know what is meant here, but > everytime I read it, I need to stop and think. Perhaps some convention > of either capitalizing the 'protocol' in ForCES Protocol or using some > difficult phrase like component protocol will help with the > differentiation. > > - section 4.2.5 > > In the case where a physical FE cannot implement (e.g., due to the > lack of a general purpose CPU) the ForCES protocol directly, a > proxy FE can be used in the middle of Fp reference point. This > allows the CE communicate to the physical FE via the proxy by using > ForCES, while the proxy manipulates the physical FE using some > intermediary form of communication (e.g., a non-ForCES protocol or > DMA). In such an implementation, the combination of the proxy and > the physical FE becomes one logical FE entity. > > I think that the Fp terminates at the proxy as opposed to the proxy > being at a midpoint. This is reinforced by the following sentence that > declares that proxy + non forCES FE comprises the FE. > > Question: is ther a one to one mapping between FE and proxies. Could > a Proxy serve several non ForCES FEs and would they be seen as a single > FE by the CE. I think so, but I am not sure. > > - section 4.3.1 > > This only pertains when the entire CE set falls. If an individual CE > falls then the circumstance may be different. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 14:23:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12219 for ; Mon, 12 Jan 2004 14:23:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag7fF-0002EW-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 14:23:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag7dM-00027s-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 14:21:57 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ag7bV-00021g-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 14:20:01 -0500 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.00CA008B@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 14:20:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67728662 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 14:20:00 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 14:20:00 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0CJL9sq019348; Mon, 12 Jan 2004 19:21:09 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0CJGS1L020339; Mon, 12 Jan 2004 19:17:28 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011211195131876 ; Mon, 12 Jan 2004 11:19:51 -0800 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, 12 Jan 2004 11:19:50 -0800 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: Comments on framework-12 Thread-Index: AcPZHqxmiju++FSnQMWmdwF/LVlV5AAIQnAA X-OriginalArrivalTime: 12 Jan 2004 19:19:50.0865 (UTC) FILETIME=[0CE08C10:01C3D941] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0D0@orsmsx410.jf.intel.com> Date: Mon, 12 Jan 2004 11:19:49 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Comments on framework-12 Comments: To: hadi@znyx.com, avri@acm.org To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I am hesitant to start enumerating different possible ways to do load = sharing or whatever the multiple CEs set out to do in this document. = Because it is a complex issue with many possible ways to do it (by = FEM/CEM, or CE-CE protocol negotiation, or CE-FE negotiation) and from = the discussion here I don't think we've thought through them yet. I = would propose that we stay at the high level by stating simply that some = kind of mechanisms should be provided to maintain coherent command of = FEs (For example, first come first serve could be the default behavior = while other behaviors might be negotiated through the protocol). Do people feel that is sufficient? You are welcome to propose the text = for this. > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim > Sent: Monday, January 12, 2004 7:14 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Comments on framework-12 >=20 >=20 > On Sun, 2004-01-11 at 23:24, avri@acm.org wrote: > > On m=E5ndag, jan 12, 2004, at 12:28 Asia/Seoul, Jamal Hadi=20 > Salim wrote: > > > >=20 > > What I am looking for is that we acknowledge that if there=20 > is more then=20 > > one behavior then the framework should indicate that there=20 > needs to be=20 > > exchange between the CE and FE about the behavior to be applied. > >=20 >=20 > I agree it is a good idea to describe the possible ways to achieve the > end goal since the protocol talks only about requiring=20 > mechanisms to be > provided.=20 > What you refer to above will be needed if the scheme is not=20 > transparent > to the FE (which is achievable if you use a multicast or=20 > broadcast wire). > In the couple of non-transparent schemes i could think of, > the FE will have to be involved in migrations and may need to be > explicitly told to do so.=20 >=20 > > I also think it reasonable that there be a default behavior=20 > established=20 > > in the Framework, and that then the semantics of the protocol can=20 > > include a method for negotiation of a different behavior. > >=20 >=20 > If you assumed the non-transparent scheme then it will be fair to make > such a default specification. >=20 > Could we instead of having it as part of the protocol have=20 > this be left=20 > to xEM (x=3D F or C)interface? I am just worried about=20 > christmas treeing. > That doesnt mean it shouldnt be in the draft. >=20 >=20 > cheers, > jamal >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 17:23:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25746 for ; Mon, 12 Jan 2004 17:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgATX-0005x1-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 17:23:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgARi-0005sy-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 17:22:07 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AgAQ4-0005n3-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 17:20:24 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00CA0444@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 17:20:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67746528 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 17:20:20 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 17:20:20 -0500 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0CMMRBX008563 for ; Mon, 12 Jan 2004 22:22:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0CMKoeh006118 for ; Mon, 12 Jan 2004 22:20:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011214201630535 for ; Mon, 12 Jan 2004 14:20:16 -0800 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, 12 Jan 2004 14:20:16 -0800 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: Comments on framework-12 Thread-Index: AcPZHqxmiju++FSnQMWmdwF/LVlV5AAIQnAAAAaZb4A= X-OriginalArrivalTime: 12 Jan 2004 22:20:16.0019 (UTC) FILETIME=[412BF630:01C3D95A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0D4@orsmsx410.jf.intel.com> Date: Mon, 12 Jan 2004 14:20:15 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Comments on framework-12 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I am working on the next revision for framework to incorporate all the = comments. So please let me know if you have further comments by = tomorrow. > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Yang, Lily L > Sent: Monday, January 12, 2004 11:20 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Comments on framework-12 >=20 >=20 > I am hesitant to start enumerating different possible ways to=20 > do load sharing or whatever the multiple CEs set out to do in=20 > this document. Because it is a complex issue with many=20 > possible ways to do it (by FEM/CEM, or CE-CE protocol=20 > negotiation, or CE-FE negotiation) and from the discussion=20 > here I don't think we've thought through them yet. I would=20 > propose that we stay at the high level by stating simply that=20 > some kind of mechanisms should be provided to maintain=20 > coherent command of FEs (For example, first come first serve=20 > could be the default behavior while other behaviors might be=20 > negotiated through the protocol). >=20 > Do people feel that is sufficient? You are welcome to propose=20 > the text for this. >=20 > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim > > Sent: Monday, January 12, 2004 7:14 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: Comments on framework-12 > >=20 > >=20 > > On Sun, 2004-01-11 at 23:24, avri@acm.org wrote: > > > On m=E5ndag, jan 12, 2004, at 12:28 Asia/Seoul, Jamal Hadi=20 > > Salim wrote: > > > > > >=20 > > > What I am looking for is that we acknowledge that if there=20 > > is more then=20 > > > one behavior then the framework should indicate that there=20 > > needs to be=20 > > > exchange between the CE and FE about the behavior to be applied. > > >=20 > >=20 > > I agree it is a good idea to describe the possible ways to=20 > achieve the > > end goal since the protocol talks only about requiring=20 > > mechanisms to be > > provided.=20 > > What you refer to above will be needed if the scheme is not=20 > > transparent > > to the FE (which is achievable if you use a multicast or=20 > > broadcast wire). > > In the couple of non-transparent schemes i could think of, > > the FE will have to be involved in migrations and may need to be > > explicitly told to do so.=20 > >=20 > > > I also think it reasonable that there be a default behavior=20 > > established=20 > > > in the Framework, and that then the semantics of the protocol can=20 > > > include a method for negotiation of a different behavior. > > >=20 > >=20 > > If you assumed the non-transparent scheme then it will be=20 > fair to make > > such a default specification. > >=20 > > Could we instead of having it as part of the protocol have=20 > > this be left=20 > > to xEM (x=3D F or C)interface? I am just worried about=20 > > christmas treeing. > > That doesnt mean it shouldnt be in the draft. > >=20 > >=20 > > cheers, > > jamal > >=20 > >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 19:48:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02497 for ; Mon, 12 Jan 2004 19:48:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgCj0-0005H1-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 19:48:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgCh8-0005Co-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 19:46:11 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AgCgB-00059V-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 19:45:11 -0500 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.00CA06EC@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 19:45:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67756965 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 19:45:11 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 19:45:10 -0500 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgCg8-000M9w-Vl for FORCES@PEACH.EASE.LSOFT.COM; Tue, 13 Jan 2004 00:45:09 +0000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Approved-By: avri@ACM.ORG Message-ID: Date: Tue, 13 Jan 2004 09:44:55 +0900 Reply-To: avri@acm.org Sender: Forwarding and Control Element Separation From: avri@acm.org Subject: Re: Comments on framework-12 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CB0D4@orsmsx410.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On tisdag, jan 13, 2004, at 07:20 Asia/Seoul, Yang, Lily L wrote: >> I am hesitant to start enumerating different possible ways to >> do load sharing or whatever the multiple CEs set out to do in >> this document. Because it is a complex issue with many >> possible ways to do it (by FEM/CEM, or CE-CE protocol >> negotiation, or CE-FE negotiation) and from the discussion >> here I don't think we've thought through them yet. I would >> propose that we stay at the high level by stating simply that >> some kind of mechanisms should be provided to maintain >> coherent command of FEs (For example, first come first serve >> could be the default behavior while other behaviors might be >> negotiated through the protocol). >> >> Do people feel that is sufficient? You are welcome to propose >> the text for this. >> I think it is important that the way in which the FE will process commands be determinate. I agree that there are many schemes for setting up such a determination and that there is no reason to go down that rat hole (or is it up that christmas tree) at this point in this document, but there I believe there should be a presumption of a known state in case a protocol, either by design, by implementation or by use, does not specify any particular prioritization scheme. I also think this task is better handled by the ForCES protocol then by the manager protocols as it is the CE that must be able to predict the behavior, and thus the state, of the FE and it is also possible that the CE might change the rules midstream, e.g. if load sharing were to start up at some time, long after the initial association was formed, when a new CE comes on line. That is not to say that the xEM can't have configured something in advance, but then I would think it would still be responsibility of the ForCES protocol to determine the method being used (i.e. how can the CE be assured that the FEM has effected the same state in the FE that the CEM has told the CE about as there is no presumption of xEM coordination?). I suggest the following wording: - to section 3.2 Instead, FEs accept commands from any CE authorized to control them, and it is up to the CEs to coordinate among themselves to achieve redundancy, load sharing or distributed control. - add Unless otherwise configured or determined by a ForCEs protocol exchange, each FE will process authorized incoming commands directed at it as it receives them on a first come first serve basis. a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 21:40:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08244 for ; Mon, 12 Jan 2004 21:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgETT-0004ks-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 21:40:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgERa-0004iK-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 21:38:15 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AgEQr-0004fa-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 21:37:29 -0500 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.00CA0872@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 21:37:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67765617 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 21:37:29 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 21:37:28 -0500 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004011218360282:45290 ; Mon, 12 Jan 2004 18:36:02 -0800 References: <26BDFAFFB541B047B24179002EBE6D278CB0CC@orsmsx410.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 01/12/2004 06:36:03 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/12/2004 06:36:05 PM, Serialize complete at 01/12/2004 06:36:05 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1073961444.1039.180.camel@jzny.localdomain> Date: Mon, 12 Jan 2004 21:37:25 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: ForCES Framework Last Call for Comments (was: ForCES framework: summary of comments from Russ Housley and authors' respond) Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CB0CC@orsmsx410.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Lilly, On Mon, 2004-01-12 at 12:22, Yang, Lily L wrote: > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Saturday, December 20, 2003 12:01 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: ForCES Framework Last Call for Comments (was: ForCES > framework: summary of comments from Russ Housley and authors' respond) > > Lily et al, > > I think this draft is ready. The only issue i have is on section 8. > Could you move section 8.2.1 and make it section 8.1 ? > I think that it makes more sense to talk about NE security admin/config > right at the beggining of section 8 so you can set context for the rest > of the text. You can still point to the DoS concerns at that section as > you do now if you want. > > [Lily]: I still prefer the current order because it flows better. 8.1 is > about threats, and 8.2 is about the solution at high level. So moving > 8.2.1 in front of threats do not flow naturally. > I read 8.2.1 as being more about a desired end goal of the admin; example it talks about need to "assess the security needs of the ForCES-enabled network elements under different deployment scenarios" etc. It talks more about threats than solutions actually; the text does seem fit for introductory material IMO. BTW, you mention that TLS requires reliable protocols; i thought the requirement was for a connection oriented protocol which doesnt necessarily equate to a reliable one. > Other comments: > - Section 2: > I think the term "vendor" (which leaves a marketing after taste) should > really be replaced with "implementor". > > [Lily] Ok. I personally have no problem with either, generally speaking. > So I tried replacing all the "vendors" with "implementers" but it reads > kind of weird in the context. So I changed back. > Rereading: implementors is not a good replacement for vendor when you talk about hardware eg when you mention blades. The other spots are a good substitute word. I am indifferent - your call. > - section 3.2 and the Fi ref point: > I dont understand why a virtualized FE should be treated any different > from a non-virtualized one. You seem to imply there may be some need for > tricks to be played during pre-association phase. > Additionaly that section seems to be focussed more on the Fp than Fi > reference. > > [Lily] First of all, if one PFE is partitioned into several logical FEs, > it should happen before post-association (so pre-association). Now it > may even impact post-association phase if the resource changes > dynamically. There has been some discussion and comments on this from > both IESG and the list (most notably Avri). I think the current draft > addressed the issue better now thanks to these comments. > Ok, the first pass didnt make sense; so maybe a little word smithing: " If FE virtualization occurs 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-association 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 asynchronous messages (see [3], Section 5, requirement #6). " to: " If the FE partitioning occurs in the pre-association phase, it has no impact on ForCES and each virtual FE will be treated as a standard PFE would be. However, if new FE virtualization results in resource changes taken from an existing FE (already participating in ForCES post-association phase) and then the the ForCES protocol needs to be able to inform the CE of such change via asynchronous messages (see [3], Section 5, requirement #6). " > > - section 4.3.1 and 4.3.2: > Both seem to be really focussed on routing restarts and OSPF in > particular. I think those should be good examples; however, forces would > be dealing with more than just forwarding tables; almost every LFB > will have state tables syncronized between CE-FE which in my opinion > could use graceful restarts. > > [Lily] I think that is a reasonable point. I did try to include all the > notable references that are using graceful restart (OSPF, BGP and MPLS) > but these are all routing-focused. My problem is that I am not aware of > any other non-forwarding services using graceful restart. So if you have > references I would love to hear about them. I like what you propose, but > I do want to use examples that are in current practice today. > I dont think you need to provide references for other (currently non-existent) stuff - what you need to do is emphasize that the desire for such mechanisms is to make sure a graceful restart happens. Graceful restarts typically includes some protocol state stored in a table. That doesnt limit it to just OSPF or BGP or MPLS. > - section 5.7: > I think it should also be noted that the FE may not run SNMP. > The assumption with agentX is that both FE and CE run SNMP. > > [Lily] That is not what I understand. According to RFC2741: > "Within the SNMP framework, a managed node contains a processing > entity, called an agent, which has access to management information. > Within the AgentX framework, an agent is further defined to consist > of: > - a single processing entity called the master agent, which sends > and receives SNMP protocol messages in an agent role (as > specified by the SNMP framework documents) but typically has > little or no direct access to management information. > - zero or more processing entities called subagents, which are > "shielded" from the SNMP protocol messages processed by the > master agent, but which have access to management information." > Therefore, the FE does NOT run SNMP. That is the whole point. AgentX is > run between CE and FE so that CE can run SNMP to collect MIB info from > FE. > Ok, I stand corrected. > - Section 8.2.2: > Steps 1-6; those could happen between a FEM and CEM as well. > The FE could then be informed by the FEM. If no, why not? If yes, could > we add text to that effect? > > [Lily] I don't quite follow here. Since ForCES does not control what > happens between FEM and CEM, it does not even care whether there is any > relationship between FEM and CEM at all, we don't want to depend on the > trust relationship between FEM and CEM for ForCES security, do we? > FEM-CEM is a configuration plane if such a thing exists. i.e it could be a simple config file or a daemon that is continously running. I would say you have to trust your (initial bootstraping) config. Since 1-6 could be looked at as config, i was wondering if this could be between CEM-FEM. > - section 8.2.3 > I think i am missing something, but why would replay protection be > impossible if you have CEM-FEM communication and say FEM-FE > communication being trusted? > > [lily] same comment as above. > I wasnt sure why replay protection would be an issue in this case. I am not knowledgeable in this area so i may be missing something. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 21:42:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08333 for ; Mon, 12 Jan 2004 21:42:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgEVL-0004o2-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 21:42:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgETZ-0004ly-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 21:40:18 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AgETE-0004iq-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 21:39:56 -0500 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.00CA0942@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 21:39:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67765752 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 21:39:46 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 21:39:46 -0500 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0D2essq032218; Tue, 13 Jan 2004 02:40:55 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0D2eOed014237; Tue, 13 Jan 2004 02:40:24 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011218393814522 ; Mon, 12 Jan 2004 18:39:38 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jan 2004 18:39:38 -0800 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: Comments on framework-12 Thread-Index: AcPZbob3bRTz4FsvTGqdtgR/eBNA2AAD7E/w X-OriginalArrivalTime: 13 Jan 2004 02:39:38.0576 (UTC) FILETIME=[7D2DB500:01C3D97E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0DB@orsmsx410.jf.intel.com> Date: Mon, 12 Jan 2004 18:39:37 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Comments on framework-12 Comments: To: avri@acm.org To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This sounds reasonable. Thanks, Avri. Anybody has any other comments on framework? I would like to wrap up = this revision soon and send back to IESG.=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of avri@acm.org Sent: Monday, January 12, 2004 4:45 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Comments on framework-12 On tisdag, jan 13, 2004, at 07:20 Asia/Seoul, Yang, Lily L wrote: >> I am hesitant to start enumerating different possible ways to >> do load sharing or whatever the multiple CEs set out to do in >> this document. Because it is a complex issue with many >> possible ways to do it (by FEM/CEM, or CE-CE protocol >> negotiation, or CE-FE negotiation) and from the discussion >> here I don't think we've thought through them yet. I would >> propose that we stay at the high level by stating simply that >> some kind of mechanisms should be provided to maintain >> coherent command of FEs (For example, first come first serve >> could be the default behavior while other behaviors might be >> negotiated through the protocol). >> >> Do people feel that is sufficient? You are welcome to propose >> the text for this. >> I think it is important that the way in which the FE will process commands be determinate. I agree that there are many schemes for setting up such a determination and that there is no reason to go down that rat hole (or is it up that christmas tree) at this point in this document, but there I believe there should be a presumption of a known state in case a protocol, either by design, by implementation or by use, does not specify any particular prioritization scheme. I also think this task is better handled by the ForCES protocol then by the manager protocols as it is the CE that must be able to predict the behavior, and thus the state, of the FE and it is also possible that the CE might change the rules midstream, e.g. if load sharing were to start up at some time, long after the initial association was formed, when a new CE comes on line. That is not to say that the xEM can't have configured something in advance, but then I would think it would still be responsibility of the ForCES protocol to determine the method being used (i.e. how can the CE be assured that the FEM has effected the same state in the FE that the CEM has told the CE about as there is no presumption of xEM coordination?). I suggest the following wording: - to section 3.2 Instead, FEs accept commands from any CE authorized to control them, and it is up to the CEs to coordinate among themselves to achieve = redundancy, load sharing or distributed control. - add Unless otherwise configured or determined by a ForCEs protocol exchange, each FE will process authorized incoming commands directed at it as it receives them on a first come first serve basis. a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 12 23:18:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12208 for ; Mon, 12 Jan 2004 23:18:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgG0A-0001oA-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 23:18:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgFyM-0001m7-00 for forces-archive@ietf.org; Mon, 12 Jan 2004 23:16:11 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AgFx3-0001kH-00 for forces-archive@IETF.ORG; Mon, 12 Jan 2004 23:14:50 -0500 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.00CA0DB4@cherry.ease.lsoft.com>; Mon, 12 Jan 2004 23:14:49 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67773943 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 12 Jan 2004 23:14:44 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 12 Jan 2004 23:14:44 -0500 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0D4FttO013071; Tue, 13 Jan 2004 04:15:55 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0D4F9xX020263; Tue, 13 Jan 2004 04:15:24 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011220144225573 ; Mon, 12 Jan 2004 20:14:42 -0800 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, 12 Jan 2004 20:14:42 -0800 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: ForCES Framework Last Call for Comments (was: ForCESframework: summary of comments from Russ Housley and authors' respond) Thread-Index: AcPZfjCC0hzYjNJHSlaqsIvRManBpgABJ7Bw X-OriginalArrivalTime: 13 Jan 2004 04:14:42.0494 (UTC) FILETIME=[C4FA85E0:01C3D98B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0DE@orsmsx410.jf.intel.com> Date: Mon, 12 Jan 2004 20:14:41 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: ForCES Framework Last Call for Comments (was: ForCESframework: summary of comments from Russ Housley and authors' respond) Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Monday, January 12, 2004 6:37 PM > To: Yang, Lily L > Cc: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: ForCES Framework Last Call for Comments (was: > ForCESframework: summary of comments from Russ Housley and authors' > respond) >=20 >=20 >=20 > I read 8.2.1 as being more about a desired end goal of the admin; > example it talks about need to "assess the security needs of the > ForCES-enabled network elements under different deployment scenarios" > etc. > It talks more about threats than solutions actually; the text=20 > does seem > fit for introductory material IMO. I pulled that paragraph in now to the very beginning of Section 8. Well, = I actually like it now after reading it several times :-) > BTW, you mention that TLS requires reliable protocols; i thought the > requirement was for a connection oriented protocol which doesnt > necessarily equate to a reliable one. > Quote from RFC 2246:=20 "The (TLS) protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some *reliable* transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol." =20 >=20 > " If the FE partitioning occurs in the pre-association phase, it has=20 > no impact on ForCES and each virtual FE will be treated as=20 > a standard=20 > PFE would be. However, if new FE virtualization results in=20 > resource changes taken from an existing FE (already=20 > participating in=20 > ForCES post-association phase) and then the the ForCES=20 > protocol needs to be able to inform the CE of such change via=20 > asynchronous messages (see [3], Section 5, requirement #6).=20 > " >=20 Ok. I will take that. =20 > I dont think you need to provide references for other (currently > non-existent) stuff - what you need to do is emphasize that the desire > for such mechanisms is to make sure a graceful restart happens. > Graceful restarts typically includes some protocol state stored in a > table. > That doesnt limit it to just OSPF or BGP or MPLS. Point taken. But I believe the general concept is already conveyed in = the text. If you can make specific suggestion (as what text to put = where in the section), I can consider. Otherwise, I incline to leave it = as it is. >=20 > FEM-CEM is a configuration plane if such a thing exists. > i.e it could be a simple config file or a daemon that is continously > running. I would say you have to trust your (initial bootstraping) > config. Since 1-6 could be looked at as config, i was wondering if > this could be between CEM-FEM. >=20 > > - section 8.2.3 > > I think i am missing something, but why would replay protection be > > impossible if you have CEM-FEM communication and say FEM-FE > > communication being trusted? > >=20 > > [lily] same comment as above. > >=20 >=20 > I wasnt sure why replay protection would be an issue in this=20 > case. I am > not knowledgeable in this area so i may be missing something. What we asserted there is that manual key management is susceptible to = replay attack, and hence automatic key mgmt is important. The ultimate = trust we want is CE-FE. Yes, you have to trust your initial boostraping = manager (and hence CE-CEM or FE-FEM trust relationship) but I am not = sure about CEM-FEM that you keep mentioning. As far as I can tell, there = might not be any communication between CEM and FEM at all. So I am still = not sure what you are trying to say here. =20 >=20 > cheers, > jamal >=20 >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 14 01:18:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04219 for ; Wed, 14 Jan 2004 01:18:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgeM6-000483-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 01:18:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgeHu-00042i-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 01:13:59 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AgeD9-0003vO-00 for forces-archive@IETF.ORG; Wed, 14 Jan 2004 01:09:03 -0500 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.00CA2B91@cherry.ease.lsoft.com>; Wed, 14 Jan 2004 1:08:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67936844 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Jan 2004 01:08:57 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 Jan 2004 01:08:56 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0E6A43f018032; Wed, 14 Jan 2004 06:10:04 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0E66Esc007525; Wed, 14 Jan 2004 06:06:21 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011322085024985 ; Tue, 13 Jan 2004 22:08:50 -0800 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, 13 Jan 2004 22:08:50 -0800 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 Framework Last Call for Comments (was: ForCES framework: summary of comments from Russ Housley and authors' respond) Thread-Index: AcPZ+1zeIj/hXruORiKq6gd2QJqNZAAaXm9A X-OriginalArrivalTime: 14 Jan 2004 06:08:50.0524 (UTC) FILETIME=[E122B9C0:01C3DA64] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0EA@orsmsx410.jf.intel.com> Date: Tue, 13 Jan 2004 22:08:48 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: ForCES Framework Last Call for Comments (was: ForCES framework: summary of comments from Russ Housley and authors' respond) Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable That seems reasonable. Thanks. -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Weiming Wang Sent: Tuesday, January 13, 2004 9:31 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: ForCES Framework Last Call for Comments (was: ForCES framework: summary of comments from Russ Housley and authors' respond) Hi Lily, =20 > - section 5.7: > I think it should also be noted that the FE may not run SNMP. > The assumption with agentX is that both FE and CE run SNMP. > > [Lily] That is not what I understand. According to RFC2741: > "Within the SNMP framework, a managed node contains a processing > entity, called an agent, which has access to management information. > Within the AgentX framework, an agent is further defined to consist > of: > - a single processing entity called the master agent, which sends > and receives SNMP protocol messages in an agent role (as > specified by the SNMP framework documents) but typically has > little or no direct access to management information. > - zero or more processing entities called subagents, which are > "shielded" from the SNMP protocol messages processed by the > master agent, but which have access to management information." > Therefore, the FE does NOT run SNMP. That is the whole point. AgentX is > run between CE and FE so that CE can run SNMP to collect MIB info from > FE. Though ActiveX for FE SNMP supporting can be used,it does not mean FEs without ActiveX supporting is precluded. And RFC3654=20 architectural requirements 14) also states that: 14)......In certain conditions (e.g., CE/FE disconnection), it may be useful to allow management tools (e.g., SNMP) to be used to diagnose and repair problems. The following guidelines MUST be observed: 1. The ability for a management tool (e.g., SNMP) to be used to read (but not change) the state of FE SHOULD NOT be precluded. ...... My understanding of the requirement is that FEs SHOULD support SNMP at the level of fetch somthing. Therefore, I suggest to change the use of ActiveX from "recommend" to "may use". Sincerely, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 14 06:17:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11739 for ; Wed, 14 Jan 2004 06:17:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agj1v-0003Uy-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 06:17:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgiyT-0003KO-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 06:14:14 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AgiuI-0003DL-00 for forces-archive@IETF.ORG; Wed, 14 Jan 2004 06:09:54 -0500 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.00CA306F@cherry.ease.lsoft.com>; Wed, 14 Jan 2004 6:09:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 67961433 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Jan 2004 06:09:28 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 Jan 2004 06:09:26 -0500 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004011403080040:46601 ; Wed, 14 Jan 2004 03:08:00 -0800 References: <26BDFAFFB541B047B24179002EBE6D278CB0DE@orsmsx410.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 01/14/2004 03:08:00 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/14/2004 03:08:02 AM, Serialize complete at 01/14/2004 03:08:02 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1074078563.1084.8.camel@jzny.localdomain> Date: Wed, 14 Jan 2004 06:09:23 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: ForCES Framework Last Call for Comments (was: ForCESframework: summary of comments from Russ Housley and authors' respond) Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CB0DE@orsmsx410.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Mon, 2004-01-12 at 23:14, Yang, Lily L wrote: > > > - section 8.2.3 > > > I think i am missing something, but why would replay protection be > > > impossible if you have CEM-FEM communication and say FEM-FE > > > communication being trusted? > > > > > > [lily] same comment as above. > > > > > > > I wasnt sure why replay protection would be an issue in this > > case. I am > > not knowledgeable in this area so i may be missing something. > > What we asserted there is that manual key management is susceptible > to replay attack, and hence automatic key mgmt is important. The > ultimate trust we want is CE-FE. Yes, you have to trust your initial > boostraping manager (and hence CE-CEM or FE-FEM trust relationship) > but I am not sure about CEM-FEM that you keep mentioning. As far as > I can tell, there might not be any communication between CEM and FEM > at all. So I am still not sure what you are trying to say here. Maybe an example would be useful: Assume you have a secure channel between the CEM and FEM. Doesnt matter whether the CE owns a key server; but that the CE is able to do key updates to the FE via the XEM channel. Could you not simulate automatic key management? Dont wanna slow you down in submitting that draft - so my comments end here. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 14 13:03:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00652 for ; Wed, 14 Jan 2004 13:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgpMq-00008P-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 13:03:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgpLu-00006n-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 13:02:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AgpL0-00005T-00 for forces-archive@IETF.ORG; Wed, 14 Jan 2004 13:01:54 -0500 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.00CA37C1@cherry.ease.lsoft.com>; Wed, 14 Jan 2004 13:01:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68001554 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Jan 2004 13:01:28 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 Jan 2004 13:01:28 -0500 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0EI2f3f029860; Wed, 14 Jan 2004 18:02:41 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0EI2AEh003309; Wed, 14 Jan 2004 18:02:10 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011410012622469 ; Wed, 14 Jan 2004 10:01:26 -0800 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, 14 Jan 2004 10:01:26 -0800 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: ForCES Framework Last Call for Comments (was: ForCESframework:summary of comments from Russ Housley and authors' respond) Thread-Index: AcPajt/0nFBP7JvSSNqURPkv9qeAuwAN0Dvg X-OriginalArrivalTime: 14 Jan 2004 18:01:26.0474 (UTC) FILETIME=[6DAAF2A0:01C3DAC8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0EF@orsmsx410.jf.intel.com> Date: Wed, 14 Jan 2004 10:01:25 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: ForCES Framework Last Call for Comments (was: ForCESframework:summary of comments from Russ Housley and authors' respond) Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] Sent: Wednesday, January 14, 2004 3:09 AM To: Yang, Lily L Cc: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: ForCES Framework Last Call for Comments (was: ForCESframework:summary of comments from Russ Housley and authors' respond) On Mon, 2004-01-12 at 23:14, Yang, Lily L wrote: =20 > > > - section 8.2.3 > > > I think i am missing something, but why would replay protection be > > > impossible if you have CEM-FEM communication and say FEM-FE > > > communication being trusted? > > >=20 > > > [lily] same comment as above. > > >=20 > >=20 > > I wasnt sure why replay protection would be an issue in this=20 > > case. I am > > not knowledgeable in this area so i may be missing something. >=20 > What we asserted there is that manual key management is susceptible=20 > to replay attack, and hence automatic key mgmt is important. The=20 > ultimate trust we want is CE-FE. Yes, you have to trust your initial > boostraping manager (and hence CE-CEM or FE-FEM trust relationship) > but I am not sure about CEM-FEM that you keep mentioning. As far as > I can tell, there might not be any communication between CEM and FEM > at all. So I am still not sure what you are trying to say here. Maybe an example would be useful: Assume you have a secure channel between the CEM and FEM. Doesnt matter whether the CE owns a key server; but that the CE is able to do key updates to the FE via the XEM channel. Could you not simulate automatic key management? [Lily] Oh, now I get what you meant. I don't think we have any = disagreement there. Your example is similar to what you describe in = 8.2.3 using Kerboros.=20 Dont wanna slow you down in submitting that draft - so my comments end here. [Lily] No, you are not slowing us down. It is important to get it right. = But I do feel like we are ready to submit this as final version now.=20 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 14 13:42:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02428 for ; Wed, 14 Jan 2004 13:42:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agpyd-0001vx-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 13:42:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agpxq-0001v7-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 13:42:05 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Agpx4-0001tF-00 for forces-archive@IETF.ORG; Wed, 14 Jan 2004 13:41:14 -0500 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.00CA3857@cherry.ease.lsoft.com>; Wed, 14 Jan 2004 13:41:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68005082 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Jan 2004 13:41:09 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 Jan 2004 13:41:08 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0EIh2Hl006304 for ; Wed, 14 Jan 2004 18:43:02 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0EIaPtg025694 for ; Wed, 14 Jan 2004 18:38:17 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011410404715813 for ; Wed, 14 Jan 2004 10:40:47 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 14 Jan 2004 10:40:47 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3DACD.ECAB4057" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: yes Thread-Index: AcPazM/YGyjKsgXZSuORuRDOUMq5YgAAAa1Q X-OriginalArrivalTime: 14 Jan 2004 18:40:47.0834 (UTC) FILETIME=[ED25E3A0:01C3DACD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB0F1@orsmsx410.jf.intel.com> Date: Wed, 14 Jan 2004 10:40:47 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: framework v13 uploaded to IETF To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DACD.ECAB4057 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, all -- This new version of framework incorporated the most recent comments from = Avri, Jamal and others in the list. Below is a detailed log of the = changes. There are numerous clarification and corrections, but no = substantial change in the technical content. This revision is uploaded to IETF and we feel ready to go RFC.=20 Lily <>=20 -------------------------- summary of changes in v13 = -------------------------------------------- #1) Section 1 Dfinition: [Comment/Reason for change] To clarify that association is a per CE-FE = concept. [old] Pre-association Phase - The period of time during which an FE Manager = (see below) and a CE Manager (see below) are determining which FE and CE = should be part of the same network element. =20 [new] Pre-association Phase - The period of time during which an FE Manager = (see below) and a CE Manager (see below) are determining whether an FE = and a CE should be part of the same network element. It is possible = for some elements of the NE to be in pre-association=20 phase while other elements are in the post-association phase. #2) Section 3. Achitecture [Comment/Reason for change] To avoid the misconception that association = is a NE system wide concept. [deleted]=20 There is no defined role for FE Manager and CE Manager in = post-association phase, thus these logical components are not considered = part of the ForCES NE.=20 3.2 at the end of 1st paragraph: [Comment/Reason for change] clarify the impact of FE virtualization. [old] However, if FE virtualization results in dynamic resource change on FE = during post-association phase, the FE model needs to be able to report = such capability and the Protocol needs to be able to inform the CE of = such change via asynchronous messages (see [3], Section 5, requirement = #6). [new] However, if FE virtualization results in resource change taken from an = existing FE (already participating in ForCES post-association phase), = the ForCES Protocol needs to be able to inform the CE of such change via = asynchronous messages (see [3], Section 5, requirement #6). #3) 3.2 at the end of the 2nd paragraph [Comment/Reason for change] To point out the behavior issue of FE = accepting commands from multiple CEs. [add] Unless otherwise configured or determined by a ForCEs Protocol = exchange, each FE will process authorized incoming commands directed at = it as it receives them on a first come first serve basis. =20 #4) 4.1 Pre_association Phase [Comment/Reason for change] same as #1) [old] Pre-association phase is the period of time during which an FE Manager = and a CE Manager are determining which FE and CE should be part of the = same network element. =20 [new] Pre-association phase is the period of time during which an FE Manager = and a CE Manager are determining whether an FE and a CE should be part = of the same network element. =20 #5) 4.1.1 Fl Reference Point [Comment/Reason for change] same as #1) [old] CE managers and FE managers may communicate across the Fl reference = point in the pre-association phase in order to determine which CEs and = FEs should communicate with each other. =20 [new] CE managers and FE managers may communicate across the Fl reference = point in the pre-association phase in order to determine whether an = individual CE and FE, or a set of CEs and FEs should be associated. =20 #6) 4.2.2 Figure 9 [Comment/Reason for change] inter-FE topology exchange is optional in = the protocol. deleted the inter-FE topology msg exchange. at the beginning of last paragraph: [old] After the successful security handshake, the FE needs to inform the CE = of its own capability and its topology in relation to other FEs.=20 [new] After the successful security handshake, the FE needs to inform the CE = of its own capability and optionally its topology in relation to other = FEs.=20 #7) 4.2.2: end of last paragraph: [Comment/Reason for change] more accurate wording. [old] Once FE starts accepting packets for processing, we say the association = of this FE with its CE is now established. From then on, the CE and FE = enter steady-state communication. [new] Once the necessary initial information is exchanged, the process of = association is completed. Packet processing and forwarding at the FE = cannot begin until association is established. =20 #8) 4.2.5 FE Proxy [Comment/Reason for change] Clarify that FE Proxy terminates ForCES = itself. [old] In the case where a physical FE cannot implement (e.g., due to the lack = of a general purpose CPU) the ForCES protocol directly, a proxy FE can = be used to terminate the Fp reference point instead of the physical FE. = ... It is also possible that one proxy act on behalf of multiple = physical FEs. [new]=20 In the case where a physical FE cannot implement (e.g., due to the lack = of a general purpose CPU) the ForCES protocol directly, a proxy FE can = be used to terminate the Fp reference point instead of the physical FE. = ... It is also possible that one proxy act on behalf of multiple = physical FEs. #9) 4.3 Association Re-establishment [Comment/Reason for change] same as #1). [old] When an FE leaves or joins 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. [new] When an FE leaves or joins an existing NE that is already in operation, = the CE needs to be aware of the impact on FE topology and deals with the = change accordingly. #9.1) Section 7 Acknowledgement (updated) #9.5) Merged the paragraph in old section 8.2.1 to the beginning of = section 8 as part of the introduction. Following sections readjusted = accordingly. #10) 8.1.4 Attack during Fail Over [Comment/Reason for change] Better wording. [old] Threat: ... A malicious node can take over as CE-B if such trusted = relationship is not established during the fail-over.=20 [new] A malicious node can take over as CE-B if such trusted relationship has = not been established prior or during the fail-over.=20 #11) 8.1.8 [Comment/Reason for change] Remove congestion control. [old] Requirement: Some sort of rate limiting mechanism MUST to be in place = at both the FE and CE. Examples of such mechanisms include explicit = rate limiters or congestion control algorithms. Rate Limiter SHOULD be = configured at the FE for each message type that are being received = through Fi/F interface. [new] Requirement: Some sort of rate limiting mechanism MUST to be in place = at both the FE and CE. Rate Limiter SHOULD be configured at the FE for = each message type that are being received through Fi/F interface. #12) Section 9/10: references Adding one more reference for security: [18] S. Bellovin, J. Schiller, and C. Kaufman, "Security Mechanisms for = the Internet", RFC 3631, December, 2003. Updated most references to reflect the current status (RFC, or new = revision/date) ------_=_NextPart_001_01C3DACD.ECAB4057 Content-Type: text/plain; name="draft-ietf-forces-framework-13.txt" Content-Description: draft-ietf-forces-framework-13.txt Content-Disposition: attachment; filename="draft-ietf-forces-framework-13.txt" Content-Transfer-Encoding: base64 DQogICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTC4gWWFuZyANCiAgICBFeHBpcmF0aW9uOiBKdWx5IDIwMDQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEludGVsIENvcnAuIA0KICAgIEZpbGU6IGRyYWZ0LWlldGYt Zm9yY2VzLWZyYW1ld29yay0xMy50eHQgICAgICAgICAgICAgICAgICAgUi4gRGFudHUgDQogICAg V29ya2luZyBHcm91cDogRm9yQ0VTICAgICAgICAgICAgICAgICAgICAgICAgICBVbml2LiBvZiBO b3J0aCBUZXhhcyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFQuIEFuZGVyc29uIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW50ZWwgQ29ycC4gDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBH b3BhbCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE5va2lhIA0KICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNCANCiAgDQogICAgICAg IEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uIChGb3JDRVMpIEZyYW1l d29yayANCiAgICAgDQogICAgIA0KICAgICANCiAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi1mb3JjZXMtZnJhbWV3b3JrLTEzLnR4dCANCiAgICAgDQogICAgIA0KICAgICANCiAgICAgDQog U3RhdHVzIG9mIHRoaXMgTWVtbyANCiAgICAgDQogICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRl cm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIA0KICAgIGFsbCBwcm92 aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gIEludGVybmV0LURyYWZ0cyBhcmUgDQog ICAgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9y Y2UgKElFVEYpLCANCiAgICBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl IHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIA0KICAgIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiANCiAgICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggDQogICAgbW9udGhz IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciANCiAg ICBkb2N1bWVudHMgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMgDQogICAgYXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBv dGhlciB0aGFuIGFzIGBgd29yayBpbiANCiAgICBwcm9ncmVzcy4nJyANCiAgICAgDQogICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4gDQogICAgIA0KICAg IFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNj ZXNzZWQgYXQgIA0KICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KICAgICAN CiBDb3B5cmlnaHQgTm90aWNlICANCiAgICAgDQogICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMjAwMykuICBBbGwgUmlnaHRzIFJlc2VydmVkLiANCiAgICAgDQogQWJzdHJh Y3QgDQogIA0KICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgYXJjaGl0ZWN0dXJhbCBmcmFt ZXdvcmsgZm9yIHRoZSBGb3JDRVMgDQogICAgKEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVu dCBTZXBhcmF0aW9uKSBuZXR3b3JrIGVsZW1lbnRzLCBhbmQgDQogICAgaWRlbnRpZmllcyB0aGUg YXNzb2NpYXRlZCBlbnRpdGllcyBhbmQgdGhlIGludGVyYWN0aW9ucyBhbW9uZyB0aGVtLiANCiAg ICAgDQogVGFibGUgb2YgQ29udGVudHMgDQogIA0KICANCg0KIEludGVybmV0IERyYWZ0ICAgICAg ICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAg DQogICAgIA0KICAgIDEuIERlZmluaXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgICAgICAxLjEuIENvbnZlbnRpb25zIHVzZWQgaW4g dGhpcyBkb2N1bWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMgDQogICAgICAgMS4yLiBUZXJt aW5vbG9naWVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zIA0K ICAgIDIuIEludHJvZHVjdGlvbiB0byBGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2Vw YXJhdGlvbiANCiAgICAoRm9yQ0VTKS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICAgMy4gQXJjaGl0ZWN0dXJlLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgICAgIDMuMS4gQ29u dHJvbCBFbGVtZW50cyBhbmQgRnIgUmVmZXJlbmNlIFBvaW50Li4uLi4uLi4uLi4uLi4uLi4xMCAN CiAgICAgICAzLjIuIEZvcndhcmRpbmcgRWxlbWVudHMgYW5kIEZpIHJlZmVyZW5jZSBwb2ludC4u Li4uLi4uLi4uLi4uMTEgDQogICAgICAgMy4zLiBDRSBNYW5hZ2Vycy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE1IA0KICAgICAgIDMuNC4gRkUgTWFuYWdlcnMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNSANCiAgICA0LiBP cGVyYXRpb25hbCBQaGFzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTUgDQogICAgICAgNC4xLiBQcmUtYXNzb2NpYXRpb24gUGhhc2UuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjE1IA0KICAgICAgICAgIDQuMS4xLiBGbCBSZWZlcmVuY2UgUG9p bnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNSANCiAgICAgICAgICA0LjEuMi4g RmYgUmVmZXJlbmNlIFBvaW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYgDQog ICAgICAgICAgNC4xLjMuIEZjIFJlZmVyZW5jZSBQb2ludC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjE3IA0KICAgICAgIDQuMi4gUG9zdC1hc3NvY2lhdGlvbiBQaGFzZSBhbmQgRnAg cmVmZXJlbmNlIHBvaW50Li4uLi4uLi4uLi4xNyANCiAgICAgICAgICA0LjIuMS4gUHJveGltaXR5 IGFuZCBJbnRlcmNvbm5lY3QgYmV0d2VlbiBDRXMgYW5kIEZFcy4uLi4uMTggDQogICAgICAgICAg NC4yLjIuIEFzc29jaWF0aW9uIEVzdGFibGlzaG1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjE4IA0KICAgICAgICAgIDQuMi4zLiBTdGVhZHktc3RhdGUgQ29tbXVuaWNhdGlvbi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4yMCANCiAgICAgICAgICA0LjIuNC4gRGF0YSBQYWNrZXRzIGFjcm9z cyBGcCByZWZlcmVuY2UgcG9pbnQuLi4uLi4uLi4uLi4uMjAgDQogICAgICAgICAgNC4yLjUuIFBy b3h5IEZFLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIyIA0KICAg ICAgIDQuMy4gQXNzb2NpYXRpb24gUmUtZXN0YWJsaXNobWVudC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4yMiANCiAgICAgICAgICA0LjMuMS4gQ0UgZ3JhY2VmdWwgcmVzdGFydC4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjIgDQogICAgICAgICAgNC4zLjIuIEZFIHJlc3RhcnQu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI0IA0KICAgIDUuIEFwcGxp Y2FiaWxpdHkgdG8gUkZDMTgxMi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4y NSANCiAgICAgICA1LjEuIEdlbmVyYWwgUm91dGVyIFJlcXVpcmVtZW50cy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMjUgDQogICAgICAgNS4yLiBMaW5rIExheWVyLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI2IA0KICAgICAgIDUuMy4gSW50ZXJuZXQg TGF5ZXIgUHJvdG9jb2xzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yNyANCiAgICAg ICA1LjQuIEludGVybmV0IExheWVyIEZvcndhcmRpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMjggDQogICAgICAgNS41LiBUcmFuc3BvcnQgTGF5ZXIuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjI5IA0KICAgICAgIDUuNi4gQXBwbGljYXRpb24gTGF5ZXIg LS0gUm91dGluZyBQcm90b2NvbHMuLi4uLi4uLi4uLi4uLi4uLi4yOSANCiAgICAgICA1LjcuIEFw cGxpY2F0aW9uIExheWVyIC0tIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbC4uLi4uLi4uMjkg DQogICAgNi4gU3VtbWFyeS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjMwIA0KICAgIDcuIEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zMCANCiAgICA4LiBTZWN1cml0eSBDb25zaWRl cmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzAgDQogICAgICAg OC4xLiBBbmFseXNpcyBvZiBQb3RlbnRpYWwgVGhyZWF0cyBJbnRyb2R1Y2VkIGJ5IEZvckNFUy4u Li4uLjMxIA0KICAgICAgICAgIDguMS4xLiAiSm9pbiIgb3IgIlJlbW92ZSIgTWVzc2FnZSBGbG9v ZGluZyBvbiBDRXMuLi4uLi4uLi4zMSANCiAgICAgICAgICA4LjEuMi4gSW1wZXJzb25hdGlvbiBB dHRhY2suLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzIgDQogICAgICAgICAgOC4xLjMu IFJlcGxheSBBdHRhY2suLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMyIA0K ICAgICAgICAgIDguMS40LiBBdHRhY2sgZHVyaW5nIEZhaWwgT3Zlci4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4zMiANCiAgICAgICAgICA4LjEuNS4gRGF0YSBJbnRlZ3JpdHkuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzIgDQogICAgICAgICAgOC4xLjYuIERhdGEgQ29u ZmlkZW50aWFsaXR5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMzIA0KICAgICAgICAg IDguMS43LiBTaGFyaW5nIHNlY3VyaXR5IHBhcmFtZXRlcnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4zMyANCiAgICAgICAgICA4LjEuOC4gRGVuaWFsIG9mIFNlcnZpY2UgQXR0YWNrIHZpYSBFeHRl cm5hbCBJbnRlcmZhY2UuLi4uMzMgDQogICAgICAgOC4yLiBTZWN1cml0eSBSZWNvbW1lbmRhdGlv bnMgZm9yIEZvckNFUy4uLi4uLi4uLi4uLi4uLi4uLi4uLjM0IA0KICAgICAgICAgIDguMi4xLiBV c2luZyBUTFMgd2l0aCBGb3JDRVMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zNCANCiAg DQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgSnVseSAgICAyMDA0ICAgICAgICAgICAg ICAgICAgIFtQYWdlIDJdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1l d29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgICAgICAgOC4y LjIuIFVzaW5nIElQc2VjIHdpdGggRm9yQ0VTLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjM1 IA0KICAgIDkuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4zNyANCiAgICAxMC4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzcgDQogICAgMTEuIEF1dGhvcnMnIEFkZHJl c3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjM4IA0KICAgIDEy LiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4zOSANCiAgICAxMy4gRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMzkgDQogICAgIA0KICAgICANCiAxLiBEZWZpbml0aW9ucyAN CiAgIA0KIDEuMS4gQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50ICANCiAgICAgICAg IA0KICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hB TEwiLCAiU0hBTEwgTk9UIiwgDQogICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVO REVEIiwgICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiANCiAgICB0aGlzIGRvY3VtZW50IGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkuIA0KICANCiAxLjIuIFRl cm1pbm9sb2dpZXMgDQogICAgIA0KICAgIEEgc2V0IG9mIHRlcm1pbm9sb2d5IGFzc29jaWF0ZWQg d2l0aCB0aGUgRm9yQ0VTIHJlcXVpcmVtZW50cyBpcyANCiAgICBkZWZpbmVkIGluIFszXSBhbmQg d2Ugb25seSBpbmNsdWRlIHRoZSBkZWZpbml0aW9ucyB0aGF0IGFyZSBtb3N0IA0KICAgIHJlbGV2 YW50IHRvIHRoaXMgZG9jdW1lbnQgaGVyZS4gIA0KICAgICANCiAgICBBZGRyZXNzYWJsZSBFbnRp dHkgKEFFKSAtIEFuIGVudGl0eSB0aGF0IGlzIGRpcmVjdGx5IGFkZHJlc3NhYmxlIA0KICAgIGdp dmVuIHNvbWUgaW50ZXJjb25uZWN0IHRlY2hub2xvZ3kuICBGb3IgZXhhbXBsZSwgb24gSVAgbmV0 d29ya3MsIA0KICAgIGl0IGlzIGEgZGV2aWNlIHRvIHdoaWNoIHdlIGNhbiBjb21tdW5pY2F0ZSB1 c2luZyBhbiBJUCBhZGRyZXNzOyBvbiANCiAgICBhIHN3aXRjaCBmYWJyaWMsIGl0IGlzIGEgZGV2 aWNlIHRvIHdoaWNoIHdlIGNhbiBjb21tdW5pY2F0ZSB1c2luZyBhIA0KICAgIHN3aXRjaCBmYWJy aWMgcG9ydCBudW1iZXIuICANCiAgICAgDQogICAgUGh5c2ljYWwgRm9yd2FyZGluZyBFbGVtZW50 IChQRkUpIC0gQW4gQUUgdGhhdCBpbmNsdWRlcyBoYXJkd2FyZSANCiAgICB1c2VkIHRvIHByb3Zp ZGUgcGVyLXBhY2tldCBwcm9jZXNzaW5nIGFuZCBoYW5kbGluZy4gIFRoaXMgaGFyZHdhcmUgDQog ICAgbWF5IGNvbnNpc3Qgb2YgKGJ1dCBpcyBub3QgbGltaXRlZCB0bykgbmV0d29yayBwcm9jZXNz b3JzLCBBU0lDcyANCiAgICAoQXBwbGljYXRpb24tU3BlY2lmaWMgSW50ZWdyYXRlZCBDaXJjdWl0 cyksIG9yIGdlbmVyYWwgcHVycG9zZSANCiAgICBwcm9jZXNzb3JzLCBpbnN0YWxsZWQgb24gbGlu ZSBjYXJkcywgZGF1Z2h0ZXIgYm9hcmRzLCBtZXp6YW5pbmUgDQogICAgY2FyZHMsIG9yIGluIHN0 YW5kLWFsb25lIGJveGVzLiANCiAgICAgICAgIA0KICAgIFBGRSBQYXJ0aXRpb24gLSBBIGxvZ2lj YWwgcGFydGl0aW9uIG9mIGEgUEZFIGNvbnNpc3Rpbmcgb2Ygc29tZSANCiAgICBzdWJzZXQgb2Yg ZWFjaCBvZiB0aGUgcmVzb3VyY2VzIChlLmcuLCBwb3J0cywgbWVtb3J5LCBmb3J3YXJkaW5nIA0K ICAgIHRhYmxlIGVudHJpZXMpIGF2YWlsYWJsZSBvbiB0aGUgUEZFLiAgVGhpcyBjb25jZXB0IGlz IGFuYWxvZ291cyB0byANCiAgICB0aGF0IG9mIHRoZSByZXNvdXJjZXMgYXNzaWduZWQgdG8gYSB2 aXJ0dWFsIHN3aXRjaGluZyBlbGVtZW50IGFzIA0KICAgIGRlc2NyaWJlZCBpbiBbOF0uICANCiAg ICAgICAgIA0KICAgIFBoeXNpY2FsIENvbnRyb2wgRWxlbWVudCAoUENFKSAtIEFuIEFFIHRoYXQg aW5jbHVkZXMgaGFyZHdhcmUgdXNlZCANCiAgICB0byBwcm92aWRlIGNvbnRyb2wgZnVuY3Rpb25h bGl0eS4gIFRoaXMgaGFyZHdhcmUgdHlwaWNhbGx5IGluY2x1ZGVzIA0KICAgIGEgZ2VuZXJhbCBw dXJwb3NlIHByb2Nlc3Nvci4gIA0KICAgICAgICAgDQogICAgUENFIFBhcnRpdGlvbiAtIEEgbG9n aWNhbCBwYXJ0aXRpb24gb2YgYSBQQ0UgY29uc2lzdGluZyBvZiBzb21lIA0KICAgIHN1YnNldCBv ZiBlYWNoIG9mIHRoZSByZXNvdXJjZXMgYXZhaWxhYmxlIG9uIHRoZSBQQ0UuICANCiAgDQogIA0K IFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgSnVseSAgICAyMDA0ICAgICAgICAgICAgICAgICAg IFtQYWdlIDNdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAg ICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgICAgICANCiAgICBGb3J3 YXJkaW5nIEVsZW1lbnQgKEZFKSAtIEEgbG9naWNhbCBlbnRpdHkgdGhhdCBpbXBsZW1lbnRzIHRo ZSANCiAgICBGb3JDRVMgUHJvdG9jb2wuICBGRXMgdXNlIHRoZSB1bmRlcmx5aW5nIGhhcmR3YXJl IHRvIHByb3ZpZGUgcGVyLQ0KICAgIHBhY2tldCBwcm9jZXNzaW5nIGFuZCBoYW5kbGluZyBhcyBk aXJlY3RlZCBieSBhIENFIHZpYSB0aGUgRm9yQ0VTIA0KICAgIFByb3RvY29sLiAgRkVzIG1heSBo YXBwZW4gdG8gYmUgYSBzaW5nbGUgYmxhZGUgKG9yIFBGRSksIGEgDQogICAgcGFydGl0aW9uIG9m IGEgUEZFIG9yIG11bHRpcGxlIFBGRXMuIA0KICAgICANCiAgICBDb250cm9sIEVsZW1lbnQgKENF KSAtIEEgbG9naWNhbCBlbnRpdHkgdGhhdCBpbXBsZW1lbnRzIHRoZSBGb3JDRVMgDQogICAgUHJv dG9jb2wgYW5kIHVzZXMgaXQgdG8gaW5zdHJ1Y3Qgb25lIG9yIG1vcmUgRkVzIGhvdyB0byBwcm9j ZXNzIA0KICAgIHBhY2tldHMuICBDRXMgaGFuZGxlIGZ1bmN0aW9uYWxpdHkgc3VjaCBhcyB0aGUg ZXhlY3V0aW9uIG9mIGNvbnRyb2wgDQogICAgYW5kIHNpZ25hbGluZyBwcm90b2NvbHMuICBDRXMg bWF5IGNvbnNpc3Qgb2YgUENFIHBhcnRpdGlvbnMgb3IgDQogICAgd2hvbGUgUENFcy4gDQogICAg ICAgICANCiAgICBGb3JDRVMgTmV0d29yayBFbGVtZW50IChORSkgLSBBbiBlbnRpdHkgY29tcG9z ZWQgb2Ygb25lIG9yIG1vcmUgQ0VzIA0KICAgIGFuZCBvbmUgb3IgbW9yZSBGRXMuICBUbyBlbnRp dGllcyBvdXRzaWRlIGFuIE5FLCB0aGUgTkUgcmVwcmVzZW50cyANCiAgICBhIHNpbmdsZSBwb2lu dCBvZiBtYW5hZ2VtZW50LiAgU2ltaWxhcmx5LCBhbiBORSB1c3VhbGx5IGhpZGVzIGl0cyANCiAg ICBpbnRlcm5hbCBvcmdhbml6YXRpb24gZnJvbSBleHRlcm5hbCBlbnRpdGllcy4gIA0KICAgICAg ICAgDQogICAgUHJlLWFzc29jaWF0aW9uIFBoYXNlIC0gVGhlIHBlcmlvZCBvZiB0aW1lIGR1cmlu ZyB3aGljaCBhbiBGRSANCiAgICBNYW5hZ2VyIChzZWUgYmVsb3cpIGFuZCBhIENFIE1hbmFnZXIg KHNlZSBiZWxvdykgYXJlIGRldGVybWluaW5nIA0KICAgIHdoZXRoZXIgYW4gRkUgYW5kIGEgQ0Ug c2hvdWxkIGJlIHBhcnQgb2YgdGhlIHNhbWUgbmV0d29yayBlbGVtZW50LiAgDQogICAgSXQgaXMg cG9zc2libGUgZm9yIHNvbWUgZWxlbWVudHMgb2YgdGhlIE5FIHRvIGJlIGluIHByZS1hc3NvY2lh dGlvbiANCiAgICBwaGFzZSB3aGlsZSBvdGhlciBlbGVtZW50cyBhcmUgaW4gdGhlIHBvc3QtYXNz b2NpYXRpb24gcGhhc2UuIA0KICAgICANCiAgICBQb3N0LWFzc29jaWF0aW9uIFBoYXNlIC0gVGhl IHBlcmlvZCBvZiB0aW1lIGR1cmluZyB3aGljaCBhbiBGRSBkb2VzIA0KICAgIGtub3cgd2hpY2gg Q0UgaXMgdG8gY29udHJvbCBpdCBhbmQgdmljZSB2ZXJzYSwgaW5jbHVkaW5nIHRoZSB0aW1lIA0K ICAgIGR1cmluZyB3aGljaCB0aGUgQ0UgYW5kIEZFIGFyZSBlc3RhYmxpc2hpbmcgY29tbXVuaWNh dGlvbiB3aXRoIG9uZSANCiAgICBhbm90aGVyLiAgDQogICAgICAgICANCiAgICBGb3JDRVMgUHJv dG9jb2wgLSBXaGlsZSB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgcHJvdG9jb2xzIHVzZWQgd2l0aGlu IA0KICAgIHRoZSBvdmVyYWxsIEZvckNFUyBhcmNoaXRlY3R1cmUsIHRoZSB0ZXJtICJGb3JDRVMg UHJvdG9jb2wiIHJlZmVycyANCiAgICBvbmx5IHRvIHRoZSBGb3JDRVMgcG9zdC1hc3NvY2lhdGlv biBwaGFzZSBwcm90b2NvbCAoc2VlIGJlbG93KS4gIA0KICAgICAgICAgDQogICAgRm9yQ0VTIFBv c3QtQXNzb2NpYXRpb24gUGhhc2UgUHJvdG9jb2wgLSBUaGUgcHJvdG9jb2wgdXNlZCBmb3IgDQog ICAgcG9zdC1hc3NvY2lhdGlvbiBwaGFzZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gQ0VzIGFuZCBG RXMuICBUaGlzIA0KICAgIHByb3RvY29sIGRvZXMgbm90IGFwcGx5IHRvIENFLXRvLUNFIGNvbW11 bmljYXRpb24sIEZFLXRvLUZFIA0KICAgIGNvbW11bmljYXRpb24sIG5vciB0byBjb21tdW5pY2F0 aW9uIGJldHdlZW4gRkUgYW5kIENFIG1hbmFnZXJzLiAgDQogICAgVGhlIEZvckNFUyBQcm90b2Nv bCBpcyBhIG1hc3Rlci1zbGF2ZSBwcm90b2NvbCBpbiB3aGljaCBGRXMgYXJlIA0KICAgIHNsYXZl cyBhbmQgQ0VzIGFyZSBtYXN0ZXJzLiAgIFRoaXMgcHJvdG9jb2wgaW5jbHVkZXMgYm90aCB0aGUg DQogICAgbWFuYWdlbWVudCBvZiB0aGUgY29tbXVuaWNhdGlvbiBjaGFubmVsIChlLmcuLCBjb25u ZWN0aW9uIA0KICAgIGVzdGFibGlzaG1lbnQsIGhlYXJ0YmVhdHMpIGFuZCB0aGUgY29udHJvbCBt ZXNzYWdlcyB0aGVtc2VsdmVzLiAgDQogICAgVGhpcyBwcm90b2NvbCBjb3VsZCBiZSBhIHNpbmds ZSBwcm90b2NvbCBvciBjb3VsZCBjb25zaXN0IG9mIA0KICAgIG11bHRpcGxlIHByb3RvY29scyB3 b3JraW5nIHRvZ2V0aGVyLCBhbmQgbWF5IGJlIHVuaWNhc3QgYmFzZWQgb3IgDQogICAgbXVsdGlj YXN0IGJhc2VkLiBBIHNlcGFyYXRlIHByb3RvY29sIGRvY3VtZW50IHdpbGwgc3BlY2lmeSB0aGlz IA0KICAgIGluZm9ybWF0aW9uLiANCiAgICAgICAgIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAg ICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gIA0KDQog SW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBK YW51YXJ5IDIwMDQgDQogIA0KICANCiAgICBGRSBNYW5hZ2VyIC0gQSBsb2dpY2FsIGVudGl0eSB0 aGF0IG9wZXJhdGVzIGluIHRoZSBwcmUtYXNzb2NpYXRpb24gDQogICAgcGhhc2UgYW5kIGlzIHJl c3BvbnNpYmxlIGZvciBkZXRlcm1pbmluZyB0byB3aGljaCBDRShzKSBhbiBGRSANCiAgICBzaG91 bGQgY29tbXVuaWNhdGUuICBUaGlzIHByb2Nlc3MgaXMgY2FsbGVkIENFIGRpc2NvdmVyeSBhbmQg bWF5IA0KICAgIGludm9sdmUgdGhlIEZFIG1hbmFnZXIgbGVhcm5pbmcgdGhlIGNhcGFiaWxpdGll cyBvZiBhdmFpbGFibGUgQ0VzLiAgDQogICAgQW4gRkUgbWFuYWdlciBtYXkgdXNlIGFueXRoaW5n IGZyb20gYSBzdGF0aWMgY29uZmlndXJhdGlvbiB0byBhIA0KICAgIHByZS1hc3NvY2lhdGlvbiBw aGFzZSBwcm90b2NvbCAoc2VlIGJlbG93KSB0byBkZXRlcm1pbmUgd2hpY2ggQ0UocykgDQogICAg dG8gdXNlOyBob3dldmVyLCB0aGlzIGlzIGN1cnJlbnRseSBvdXQgb2Ygc2NvcGUuICBCZWluZyBh IGxvZ2ljYWwgDQogICAgZW50aXR5LCBhbiBGRSBtYW5hZ2VyIG1pZ2h0IGJlIHBoeXNpY2FsbHkg Y29tYmluZWQgd2l0aCBhbnkgb2YgdGhlIA0KICAgIG90aGVyIGxvZ2ljYWwgZW50aXRpZXMgbWVu dGlvbmVkIGluIHRoaXMgc2VjdGlvbi4gIA0KICAgICAgICAgDQogICAgQ0UgTWFuYWdlciAtIEEg bG9naWNhbCBlbnRpdHkgdGhhdCBvcGVyYXRlcyBpbiB0aGUgcHJlLWFzc29jaWF0aW9uICANCiAg ICBwaGFzZSBhbmQgaXMgcmVzcG9uc2libGUgZm9yIGRldGVybWluaW5nIHRvIHdoaWNoIEZFKHMp IGEgQ0Ugc2hvdWxkIA0KICAgIGNvbW11bmljYXRlLiAgVGhpcyBwcm9jZXNzIGlzIGNhbGxlZCBG RSBkaXNjb3ZlcnkgYW5kIG1heSBpbnZvbHZlIA0KICAgIHRoZSBDRSBtYW5hZ2VyIGxlYXJuaW5n IHRoZSBjYXBhYmlsaXRpZXMgb2YgYXZhaWxhYmxlIEZFcy4gIEEgQ0UgDQogICAgbWFuYWdlciBt YXkgdXNlIGFueXRoaW5nIGZyb20gYSBzdGF0aWMgY29uZmlndXJhdGlvbiB0byBhIHByZS0NCiAg ICBhc3NvY2lhdGlvbiBwaGFzZSBwcm90b2NvbCAoc2VlIGJlbG93KSB0byBkZXRlcm1pbmUgd2hp Y2ggRkUgdG8gDQogICAgdXNlLCBob3dldmVyIHRoaXMgaXMgY3VycmVudGx5IG91dCBvZiBzY29w ZS4gICBCZWluZyBhIGxvZ2ljYWwgDQogICAgZW50aXR5LCBhIENFIG1hbmFnZXIgbWlnaHQgYmUg cGh5c2ljYWxseSBjb21iaW5lZCB3aXRoIGFueSBvZiB0aGUgDQogICAgb3RoZXIgbG9naWNhbCBl bnRpdGllcyBtZW50aW9uZWQgaW4gdGhpcyBzZWN0aW9uLiAgDQogICAgICAgICANCiAgICBQcmUt YXNzb2NpYXRpb24gUGhhc2UgUHJvdG9jb2wgLSBBIHByb3RvY29sIGJldHdlZW4gRkUgbWFuYWdl cnMgYW5kIA0KICAgIENFIG1hbmFnZXJzIHRoYXQgaXMgdXNlZCB0byBkZXRlcm1pbmUgd2hpY2gg Q0VzIG9yIEZFcyB0byB1c2UuICBBIA0KICAgIHByZS1hc3NvY2lhdGlvbiBwaGFzZSBwcm90b2Nv bCBtYXkgaW5jbHVkZSBhIENFIGFuZC9vciBGRSANCiAgICBjYXBhYmlsaXR5IGRpc2NvdmVyeSBt ZWNoYW5pc20uICBOb3RlIHRoYXQgdGhpcyBjYXBhYmlsaXR5IA0KICAgIGRpc2NvdmVyeSBwcm9j ZXNzIGlzIHdob2xseSBzZXBhcmF0ZSBmcm9tIChhbmQgZG9lcyBub3QgcmVwbGFjZSkgDQogICAg dGhhdCB1c2VkIHdpdGhpbiB0aGUgRm9yQ0VTIFByb3RvY29sLiAgSG93ZXZlciwgdGhlIHR3byBj YXBhYmlsaXR5IA0KICAgIGRpc2NvdmVyeSBtZWNoYW5pc21zIG1heSB1dGlsaXplIHRoZSBzYW1l IEZFIG1vZGVsLiAgIA0KICAgICAgICAgDQogICAgRkUgTW9kZWwgLSBBIG1vZGVsIHRoYXQgZGVz Y3JpYmVzIHRoZSBsb2dpY2FsIHByb2Nlc3NpbmcgZnVuY3Rpb25zIA0KICAgIG9mIGFuIEZFLiAg DQogICAgICAgICANCiAgICBGb3JDRVMgUHJvdG9jb2wgRWxlbWVudCAtIEFuIEZFIG9yIENFLiAg DQogICAgIA0KICAgIEludHJhLUZFIHRvcG9sb2d5IC0gUmVwcmVzZW50YXRpb24gb2YgaG93IGEg c2luZ2xlIEZFIGlzIHJlYWxpemVkIA0KICAgIGJ5IGNvbWJpbmluZyBwb3NzaWJseSBtdWx0aXBs ZSBsb2dpY2FsIGZ1bmN0aW9uYWwgYmxvY2tzIGFsb25nIA0KICAgIG11bHRpcGxlIGRhdGEgcGF0 aC4gVGhpcyBpcyBkZWZpbmVkIGJ5IHRoZSBGRSBtb2RlbC4gIA0KICANCiAgICBGRSBUb3BvbG9n eSAtIFJlcHJlc2VudGF0aW9uIG9mIGhvdyB0aGUgbXVsdGlwbGUgRkVzIGluIGEgc2luZ2xlIE5F IA0KICAgIGFyZSBpbnRlcmNvbm5lY3RlZC4gIFNvbWV0aW1lcyBpdCBpcyBjYWxsZWQgaW50ZXIt RkUgdG9wb2xvZ3ksIHRvIA0KICAgIGJlIGRpc3Rpbmd1aXNoZWQgZnJvbSBpbnRyYS1GRSB0b3Bv bG9neSB1c2VkIGJ5IHRoZSBGRSBtb2RlbC4gDQogICAgIA0KICAgIEludGVyLUZFIHRvcG9sb2d5 IC0gc2VlIEZFIFRvcG9sb2d5LiANCiAgICAgDQogMi4gSW50cm9kdWN0aW9uIHRvIEZvcndhcmRp bmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uIChGb3JDRVMpICANCiAgDQogICAgQW4g SVAgbmV0d29yayBlbGVtZW50IChORSkgYXBwZWFycyB0byBleHRlcm5hbCBlbnRpdGllcyBhcyBh IA0KICAgIG1vbm9saXRoaWMgcGllY2Ugb2YgbmV0d29yayBlcXVpcG1lbnQsIGUuZy4sIGEgcm91 dGVyLCBOQVQsIA0KICAgIGZpcmV3YWxsLCBvciBsb2FkIGJhbGFuY2VyLiAgSW50ZXJuYWxseSwg aG93ZXZlciwgYW4gSVAgbmV0d29yayANCiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGly ZXMgSnVseSAgICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdICANCg0KIEludGVybmV0 IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAy MDA0IA0KICANCiAgDQogICAgZWxlbWVudCAoTkUpIChzdWNoIGFzIGEgcm91dGVyKSBpcyBjb21w b3NlZCBvZiBudW1lcm91cyBsb2dpY2FsbHkgDQogICAgc2VwYXJhdGVkIGVudGl0aWVzIHRoYXQg Y29vcGVyYXRlIHRvIHByb3ZpZGUgYSBnaXZlbiBmdW5jdGlvbmFsaXR5IA0KICAgIChzdWNoIGFz IHJvdXRpbmcpLiAgVHdvIHR5cGVzIG9mIG5ldHdvcmsgZWxlbWVudCBjb21wb25lbnRzIGV4aXN0 OiANCiAgICBjb250cm9sIGVsZW1lbnQgKENFKSBpbiBjb250cm9sIHBsYW5lIGFuZCBmb3J3YXJk aW5nIGVsZW1lbnQgKEZFKSANCiAgICBpbiBmb3J3YXJkaW5nIHBsYW5lIChvciBkYXRhIHBsYW5l KS4gIEZvcndhcmRpbmcgZWxlbWVudHMgdHlwaWNhbGx5IA0KICAgIGFyZSBBU0lDLCBuZXR3b3Jr LXByb2Nlc3Nvciwgb3IgZ2VuZXJhbC1wdXJwb3NlIHByb2Nlc3Nvci1iYXNlZCANCiAgICBkZXZp Y2VzIHRoYXQgaGFuZGxlIGRhdGEgcGF0aCBvcGVyYXRpb25zIGZvciBlYWNoIHBhY2tldC4gIENv bnRyb2wgDQogICAgZWxlbWVudHMgYXJlIHR5cGljYWxseSBiYXNlZCBvbiBnZW5lcmFsLXB1cnBv c2UgcHJvY2Vzc29ycyB0aGF0IA0KICAgIHByb3ZpZGUgY29udHJvbCBmdW5jdGlvbmFsaXR5IGxp a2Ugcm91dGluZyBhbmQgc2lnbmFsaW5nIHByb3RvY29scy4gDQogICAgIA0KICAgIEZvckNFUyBh aW1zIHRvIGRlZmluZSBhIGZyYW1ld29yayBhbmQgYXNzb2NpYXRlZCBwcm90b2NvbChzKSB0byAN CiAgICBzdGFuZGFyZGl6ZSBpbmZvcm1hdGlvbiBleGNoYW5nZSBiZXR3ZWVuIHRoZSBjb250cm9s IGFuZCBmb3J3YXJkaW5nIA0KICAgIHBsYW5lLiAgSGF2aW5nIHN0YW5kYXJkIG1lY2hhbmlzbXMg YWxsb3dzIENFcyBhbmQgRkVzIHRvIGJlY29tZSANCiAgICBwaHlzaWNhbGx5IHNlcGFyYXRlZCBz dGFuZGFyZCBjb21wb25lbnRzLiAgVGhpcyBwaHlzaWNhbCBzZXBhcmF0aW9uIA0KICAgIGFjY3J1 ZXMgc2V2ZXJhbCBiZW5lZml0cyB0byB0aGUgRm9yQ0VTIGFyY2hpdGVjdHVyZS4gIFNlcGFyYXRl IA0KICAgIGNvbXBvbmVudHMgd291bGQgYWxsb3cgY29tcG9uZW50IHZlbmRvcnMgdG8gc3BlY2lh bGl6ZSBpbiBvbmUgDQogICAgY29tcG9uZW50IHdpdGhvdXQgaGF2aW5nIHRvIGJlY29tZSBleHBl cnRzIGluIGFsbCBjb21wb25lbnRzLiANCiAgICBTdGFuZGFyZCBwcm90b2NvbCBhbHNvIGFsbG93 cyB0aGUgQ0VzIGFuZCBGRXMgZnJvbSBkaWZmZXJlbnQgDQogICAgY29tcG9uZW50IHZlbmRvcnMg dG8gaW50ZXJvcGVyYXRlIHdpdGggZWFjaCBvdGhlciBhbmQgaGVuY2UgaXQgDQogICAgYmVjb21l cyBwb3NzaWJsZSBmb3Igc3lzdGVtIHZlbmRvcnMgdG8gaW50ZWdyYXRlIHRvZ2V0aGVyIHRoZSBD RXMgDQogICAgYW5kIEZFcyBmcm9tIGRpZmZlcmVudCBjb21wb25lbnQgc3VwcGxpZXJzLiAgVGhp cyBpbnRlcm9wZXJhYmlsaXR5IA0KICAgIHRyYW5zbGF0ZXMgaW50byBtb3JlIGRlc2lnbiBjaG9p Y2VzIGFuZCBmbGV4aWJpbGl0eSBmb3IgdGhlIHN5c3RlbSANCiAgICB2ZW5kb3JzLiAgT3ZlcmFs bCwgRm9yQ0VTIHdpbGwgZW5hYmxlIHJhcGlkIGlubm92YXRpb24gaW4gYm90aCB0aGUgDQogICAg Y29udHJvbCBhbmQgZm9yd2FyZGluZyBwbGFuZXMgd2hpbGUgbWFpbnRhaW5pbmcgaW50ZXJvcGVy YWJpbGl0eS4gIA0KICAgIFNjYWxhYmlsaXR5IGlzIGFsc28gZWFzaWx5IHByb3ZpZGVkIGJ5IHRo aXMgYXJjaGl0ZWN0dXJlIGluIHRoYXQgDQogICAgYWRkaXRpb25hbCBmb3J3YXJkaW5nIG9yIGNv bnRyb2wgY2FwYWNpdHkgY2FuIGJlIGFkZGVkIHRvIGV4aXN0aW5nIA0KICAgIG5ldHdvcmsgZWxl bWVudHMgd2l0aG91dCB0aGUgbmVlZCBmb3IgZm9ya2xpZnQgdXBncmFkZXMuIA0KICAgICANCiAg ICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSANCiAgICAgICAgIHwgIENvbnRyb2wgQmxhZGUgQSAgICAgIHwgICAgICAgfCAgQ29u dHJvbCBCbGFkZSBCICAgICAgfCANCiAgICAgICAgIHwgICAgICAgKENFKSAgICAgICAgICAgIHwg ICAgICAgfCAgICAgICAgICAoQ0UpICAgICAgICAgfCANCiAgICAgICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgICAg ICAgICAgXiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgIHwgDQogICAgICAgICAg ICAgICAgIHwgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB8IA0KICAgICAgICAg ICAgICAgICB8ICAgViAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgViANCiAgICAgICAg IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSANCiAgICAgICAgIHwgICAgICAgICAgICAgICBTd2l0Y2ggRmFicmljIEJhY2twbGFuZSAgICAg ICAgICAgICAgICAgfCANCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgICAgICAgICBeICB8ICAgICAgICAg ICAgXiAgfCAgICAgICAgICAgICAgICAgICBeICB8ICAgICAgICAgDQogICAgICAgICAgICAgICAg fCAgfCAgICAgICAgICAgIHwgIHwgICAgIC4gLiAuICAgICAgICAgfCAgfCAgICAgICAgIA0KICAg ICAgICAgICAgICAgIHwgIFYgICAgICAgICAgICB8ICBWICAgICAgICAgICAgICAgICAgIHwgIFYg ICAgICAgICANCiAgICAgICAgICAgIC0tLS0tLS0tLS0tLSAgICAtLS0tLS0tLS0tLS0gICAgICAg ICAgIC0tLS0tLS0tLS0tLSAgICAgDQogICAgICAgICAgICB8Um91dGVyICAgIHwgICAgfFJvdXRl ciAgICB8ICAgICAgICAgICB8Um91dGVyICAgIHwgDQogICAgICAgICAgICB8QmxhZGUgIzEgIHwg ICAgfEJsYWRlICMyICB8ICAgICAgICAgICB8QmxhZGUgI04gIHwgDQogICAgICAgICAgICB8ICAg KEZFKSAgIHwgICAgfCAgIChGRSkgICB8ICAgICAgICAgICB8ICAgKEZFKSAgIHwgDQogICAgICAg ICAgICAtLS0tLS0tLS0tLS0gICAgLS0tLS0tLS0tLS0tICAgICAgICAgICAtLS0tLS0tLS0tLS0g ICAgIA0KICAgICAgICAgICAgICAgIF4gIHwgICAgICAgICAgICBeICB8ICAgICAgICAgICAgICAg ICAgIF4gIHwgICAgICAgICANCiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgSnVs eSAgICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdICANCg0KIEludGVybmV0IERyYWZ0 ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0K ICANCiAgDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgIHwgIHwgICAgIC4gLiAuICAg ICAgICAgfCAgfCAgICAgICAgIA0KICAgICAgICAgICAgICAgIHwgIFYgICAgICAgICAgICB8ICBW ICAgICAgICAgICAgICAgICAgIHwgIFYgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgIEZp Z3VyZSAxLiBBIHJvdXRlciBjb25maWd1cmF0aW9uIGV4YW1wbGUgd2l0aCBzZXBhcmF0ZSBibGFk ZXMuIA0KICANCiAgICBPbmUgZXhhbXBsZSBvZiBzdWNoIHBoeXNpY2FsIHNlcGFyYXRpb24gaXMg YXQgdGhlIGJsYWRlIGxldmVsLiANCiAgICBGaWd1cmUgMSBzaG93cyBzdWNoIGFuIGV4YW1wbGUg Y29uZmlndXJhdGlvbiBvZiBhIHJvdXRlciwgd2l0aCB0d28gDQogICAgY29udHJvbCBibGFkZXMg YW5kIG11bHRpcGxlIGZvcndhcmRpbmcgYmxhZGVzLCBhbGwgaW50ZXJjb25uZWN0ZWQgDQogICAg aW50byBhIHN3aXRjaCBmYWJyaWMgYmFja3BsYW5lLiAgSW4gc3VjaCBhIGNoYXNzaXMgY29uZmln dXJhdGlvbiwgDQogICAgdGhlIGNvbnRyb2wgYmxhZGVzIGFyZSB0aGUgQ0VzIHdoaWxlIHRoZSBy b3V0ZXIgYmxhZGVzIGFyZSBGRXMsIGFuZCANCiAgICB0aGUgc3dpdGNoIGZhYnJpYyBiYWNrcGxh bmUgcHJvdmlkZXMgdGhlIHBoeXNpY2FsIGludGVyY29ubmVjdCBmb3IgDQogICAgYWxsIHRoZSBi bGFkZXMuICBDb250cm9sIGJsYWRlIEEgbWF5IGJlIHRoZSBwcmltYXJ5IENFIHdoaWxlIA0KICAg IGNvbnRyb2wgYmxhZGUgQiBtYXkgYmUgdGhlIGJhY2t1cCBDRSBwcm92aWRpbmcgcmVkdW5kYW5j eS4gIEl0IGlzIA0KICAgIGFsc28gcG9zc2libGUgdG8gaGF2ZSBhIHJlZHVuZGFudCBzd2l0Y2gg ZmFicmljIGZvciBoaWdoIA0KICAgIGF2YWlsYWJpbGl0eSBzdXBwb3J0LiAgUm91dGVycyB0b2Rh eSB3aXRoIHRoaXMga2luZCBvZiANCiAgICBjb25maWd1cmF0aW9uIHVzZSBwcm9wcmlldGFyeSBp bnRlcmZhY2VzIGZvciBtZXNzYWdpbmcgYmV0d2VlbiBDRXMgDQogICAgYW5kIEZFcy4gIFRoZSBn b2FsIG9mIEZvckNFUyBpcyB0byByZXBsYWNlIHN1Y2ggcHJvcHJpZXRhcnkgDQogICAgaW50ZXJm YWNlcyB3aXRoIGEgc3RhbmRhcmQgcHJvdG9jb2wuICBXaXRoIGEgc3RhbmRhcmQgcHJvdG9jb2wg bGlrZSANCiAgICBGb3JDRVMgaW1wbGVtZW50ZWQgb24gYWxsIGJsYWRlcywgaXQgYmVjb21lcyBw b3NzaWJsZSBmb3IgY29udHJvbCANCiAgICBibGFkZXMgZnJvbSB2ZW5kb3IgWCBhbmQgZm9yd2Fy ZGluZyBibGFkZXMgZnJvbSB2ZW5kb3IgWSB0byB3b3JrIA0KICAgIHNlYW1sZXNzbHkgdG9nZXRo ZXIgaW4gb25lIGNoYXNzaXMuICANCiAgDQogIA0KICAgICAgICAgLS0tLS0tLSAgICAgICAgIC0t LS0tLS0gDQogICAgICAgICB8IENFMSB8ICAgICAgICAgfCBDRTIgfCANCiAgICAgICAgIC0tLS0t LS0gICAgICAgICAtLS0tLS0tIA0KICAgICAgICAgICAgXiAgICAgICAgICAgICAgIF4gDQogICAg ICAgICAgICB8ICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgIFYgICAgICAgICAgICAgICBW IA0KICAgICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSBFdGhl cm5ldCANCiAgICAgICAgIF4gICAgICAgXiAgICAgICAuIC4gLiAgIF4gDQogICAgICAgICB8ICAg ICAgIHwgICAgICAgICAgICAgICB8IA0KICAgICAgICAgViAgICAgICBWICAgICAgICAgICAgICAg ViANCiAgICAgIC0tLS0tLS0gIC0tLS0tLS0gICAgICAgICAtLS0tLS0tLSANCiAgICAgIHwgRkUj MXwgIHwgRkUjMnwgICAgICAgICB8IEZFI24gfCANCiAgICAgIC0tLS0tLS0gIC0tLS0tLS0gICAg ICAgICAtLS0tLS0tLSANCiAgICAgICAgXiAgfCAgICAgXiAgfCAgICAgICAgICAgIF4gIHwgICAg ICAgICANCiAgICAgICAgfCAgfCAgICAgfCAgfCAgICAgICAgICAgIHwgIHwgICAgICAgICANCiAg ICAgICAgfCAgViAgICAgfCAgViAgICAgICAgICAgIHwgIFYgICAgICAgICANCiAgICAgICAgICAN CiAgICAgICAgIEZpZ3VyZSAyLiBBIHJvdXRlciBjb25maWd1cmF0aW9uIGV4YW1wbGUgd2l0aCBz ZXBhcmF0ZSBib3hlcy4gDQogICAgIA0KICAgIEFub3RoZXIgbGV2ZWwgb2YgcGh5c2ljYWwgc2Vw YXJhdGlvbiBiZXR3ZWVuIHRoZSBDRXMgYW5kIEZFcyBjYW4gYmUgDQogICAgYXQgdGhlIGJveCBs ZXZlbC4gIEluIHN1Y2ggY29uZmlndXJhdGlvbiwgYWxsIHRoZSBDRXMgYW5kIEZFcyBhcmUgDQog ICAgcGh5c2ljYWxseSBzZXBhcmF0ZWQgYm94ZXMsIGludGVyY29ubmVjdGVkIHdpdGggc29tZSBr aW5kIG9mIGhpZ2ggDQogICAgc3BlZWQgTEFOIGNvbm5lY3Rpb24gKGxpa2UgR2lnYWJpdCBFdGhl cm5ldCkuICBUaGVzZSBzZXBhcmF0ZWQgQ0VzIA0KICAgIGFuZCBGRXMgYXJlIG9ubHkgb25lIGhv cCBhd2F5IGZyb20gZWFjaCBvdGhlciB3aXRoaW4gYSBsb2NhbCBhcmVhIA0KICANCiAgDQogWWFu ZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1Bh Z2UgN10gIA0KDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAg ICAgICAgICAgICBKYW51YXJ5IDIwMDQgDQogIA0KICANCiAgICBuZXR3b3JrLiAgVGhlIENFcyBh bmQgRkVzIGNvbW11bmljYXRlIHRvIGVhY2ggb3RoZXIgYnkgcnVubmluZyANCiAgICBGb3JDRVMs IGFuZCB0aGUgY29sbGVjdGlvbiBvZiB0aGVzZSBDRXMgYW5kIEZFcyB0b2dldGhlciBiZWNvbWUg b25lIA0KICAgIHJvdXRpbmcgdW5pdCB0byB0aGUgZXh0ZXJuYWwgd29ybGQuIEZpZ3VyZSAyIHNo b3dzIHN1Y2ggYW4gZXhhbXBsZS4gDQogICAgIA0KICAgIEluIGJvdGggZXhhbXBsZXMgc2hvd24g aGVyZSwgdGhlIHNhbWUgcGh5c2ljYWwgaW50ZXJjb25uZWN0IGlzIHVzZWQgDQogICAgZm9yIGJv dGggQ0UtdG8tRkUgYW5kIEZFLXRvLUZFIGNvbW11bmljYXRpb24uICBIb3dldmVyLCB0aGF0IGRv ZXMgDQogICAgbm90IGhhdmUgdG8gYmUgdGhlIGNhc2UuICBPbmUgcmVhc29uIHRvIHVzZSBkaWZm ZXJlbnQgaW50ZXJjb25uZWN0cyANCiAgICBpcyB0aGF0IENFLXRvLUZFIGludGVyY29ubmVjdCBk b2VzIG5vdCBoYXZlIHRvIGJlIGFzIGZhc3QgYXMgdGhlIA0KICAgIEZFLXRvLUZFIGludGVyY29u bmVjdCwgc28gdGhlIG1vcmUgZXhwZW5zaXZlIGZhc3QgY29ubmVjdGlvbnMgY2FuIA0KICAgIGJl IHNhdmVkIGZvciBGRS10by1GRS4gIFRoZSBzZXBhcmF0ZSBpbnRlcmNvbm5lY3RzIG1heSBhbHNv IHByb3ZpZGUgDQogICAgcmVsaWFiaWxpdHkgYW5kIHJlZHVuZGFuY3kgYmVuZWZpdHMgZm9yIHRo ZSBORS4gDQogIA0KICAgIFNvbWUgZXhhbXBsZXMgb2YgY29udHJvbCBmdW5jdGlvbnMgdGhhdCBj YW4gYmUgaW1wbGVtZW50ZWQgaW4gdGhlIA0KICAgIENFIGluY2x1ZGUgcm91dGluZyBwcm90b2Nv bHMgbGlrZSBSSVAsIE9TUEYgYW5kIEJHUCwgY29udHJvbCBhbmQgDQogICAgc2lnbmFsaW5nIHBy b3RvY29scyBsaWtlIFJTVlAgKFJlc291cmNlIFJlc2VydmF0aW9uIFByb3RvY29sKSwgTERQIA0K ICAgIChMYWJlbCBEaXN0cmlidXRpb24gUHJvdG9jb2wpIGZvciBNUExTLCBldGMuICBFeGFtcGxl cyBvZiANCiAgICBmb3J3YXJkaW5nIGZ1bmN0aW9ucyBpbiB0aGUgRkUgaW5jbHVkZSBMUE0gKGxv bmdlc3QgcHJlZml4IG1hdGNoKSANCiAgICBmb3J3YXJkZXIsIGNsYXNzaWZpZXJzLCB0cmFmZmlj IHNoYXBlciwgbWV0ZXIsIE5BVCAoTmV0d29yayBBZGRyZXNzIA0KICAgIFRyYW5zbGF0b3JzKSwg ZXRjLiAgRmlndXJlIDMgcHJvdmlkZXMgZXhhbXBsZSBmdW5jdGlvbnMgaW4gYm90aCBDRSANCiAg ICBhbmQgRkUuICBBbnkgZ2l2ZW4gTkUgbWF5IGNvbnRhaW4gb25lIG9yIG1hbnkgb2YgdGhlc2Ug Q0UgYW5kIEZFIA0KICAgIGZ1bmN0aW9ucyBpbiBpdC4gIFRoZSBkaWFncmFtIGFsc28gc2hvd3Mg dGhhdCBGb3JDRVMgUHJvdG9jb2wgaXMgDQogICAgdXNlZCB0byB0cmFuc3BvcnQgYm90aCB0aGUg Y29udHJvbCBtZXNzYWdlcyBmb3IgRm9yQ0VTIGl0c2VsZiBhbmQgDQogICAgdGhlIGRhdGEgcGFj a2V0cyB0aGF0IGFyZSBvcmlnaW5hdGVkL2Rlc3RpbmVkIGZyb20vdG8gdGhlIGNvbnRyb2wgDQog ICAgZnVuY3Rpb25zIGluIENFIChlLmcuLCByb3V0aW5nIHBhY2tldHMpLiAgU2VjdGlvbiA0LjIu NCBwcm92aWRlcyANCiAgICBtb3JlIGRldGFpbCBvbiB0aGlzLiAgDQogICAgIA0KICAgICAgICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgICAg ICAgIHwgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgICAgIHwgDQog ICAgICAgICB8T1NQRiAgIHxSSVAgICAgfEJHUCAgICB8UlNWUCAgIHxMRFAgICAgfC4gLiAuICB8 IA0KICAgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAg ICAgfCANCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gDQogICAgICAgICB8ICAgICAgICAgICAgICAgRm9yQ0VTIEludGVyZmFjZSAgICAg ICAgICAgICAgICB8IA0KICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4gICBe ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICBGb3JDRVMgIHwg ICB8ZGF0YSAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgY29udHJvbCB8ICAgfHBh Y2tldHMgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgIG1lc3NhZ2VzfCAgIHwoZS5nLiwg cm91dGluZyBwYWNrZXRzKSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHYgICB2 IA0KICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSANCiAgICAgICAgIHwgICAgICAgICAgICAgICBGb3JDRVMgSW50ZXJmYWNlICAgICAgICAg ICAgICAgIHwgDQogICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tIA0KICAgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICB8 ICAgICAgIHwgICAgICAgfCANCiAgICAgICAgIHxMUE0gRndkfE1ldGVyICB8U2hhcGVyIHxOQVQg ICAgfENsYXNzaS18LiAuIC4gIHwgDQogICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICB8 ICAgICAgIHxmaWVyICAgfCAgICAgICB8IA0KICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgIHwgICAgICAgICAgICAgICBG RSByZXNvdXJjZXMgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICANCiAgDQogWWFuZywgZXQg YWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0g IA0KDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAg ICAgICBKYW51YXJ5IDIwMDQgDQogIA0KICANCiAgICAgDQogICAgICAgICAgICAgICAgIEZpZ3Vy ZSAzLiBFeGFtcGxlcyBvZiBDRSBhbmQgRkUgZnVuY3Rpb25zIA0KICAgICANCiAgICAgDQogICAg QSBzZXQgb2YgcmVxdWlyZW1lbnRzIGZvciBjb250cm9sIGFuZCBmb3J3YXJkaW5nIHNlcGFyYXRp b24gaXMgDQogICAgaWRlbnRpZmllZCBpbiBbM10uICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IEZvckNFUyBhcmNoaXRlY3R1cmUgDQogICAgdGhhdCBzYXRpc2ZpZXMgdGhlIGFyY2hpdGVjdHVy YWwgcmVxdWlyZW1lbnRzIG9mIHRoYXQgZG9jdW1lbnQgYW5kIA0KICAgIGRlZmluZXMgYSBmcmFt ZXdvcmsgZm9yIEZvckNFUyBuZXR3b3JrIGVsZW1lbnRzIGFuZCB0aGUgYXNzb2NpYXRlZCANCiAg ICBlbnRpdGllcyB0byBmYWNpbGl0YXRlIHByb3RvY29sIGRlZmluaXRpb24uICBXaGVuZXZlciBu ZWNlc3NhcnksIA0KICAgIHRoaXMgZG9jdW1lbnQgdXNlcyBtYW55IGV4YW1wbGVzIHRvIGlsbHVz dHJhdGUgdGhlIGlzc3VlcyBhbmQvb3IgDQogICAgcG9zc2libGUgc29sdXRpb25zIGluIEZvckNF Uy4gIFRoZXNlIGV4YW1wbGVzIGFyZSBpbnRlbmRlZCB0byBiZSANCiAgICBqdXN0IGV4YW1wbGVz LCBhbmQgc2hvdWxkIG5vdCBiZSB0YWtlbiBhcyB0aGUgb25seSBvciBkZWZpbml0ZSB3YXlzIA0K ICAgIG9mIGRvaW5nIGNlcnRhaW4gdGhpbmdzLiAgSXQgaXMgZXhwZWN0ZWQgdGhhdCBzZXBhcmF0 ZSBkb2N1bWVudCANCiAgICB3aWxsIGJlIHByb2R1Y2VkIGJ5IHRoZSBGb3JDRVMgd29ya2luZyBn cm91cCB0byBzcGVjaWZ5IHRoZSBGb3JDRVMgDQogICAgUHJvdG9jb2wuIA0KICAgICANCiAzLiBB cmNoaXRlY3R1cmUgDQogIA0KICAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBGb3JDRVMgYXJj aGl0ZWN0dXJhbCBmcmFtZXdvcmsgYW5kIHRoZSANCiAgICBhc3NvY2lhdGVkIGxvZ2ljYWwgY29t cG9uZW50cy4gIFRoaXMgRm9yQ0VTIGZyYW1ld29yayBkZWZpbmVzIA0KICAgIGNvbXBvbmVudHMg b2YgRm9yQ0VTIE5FcyBpbmNsdWRpbmcgc2V2ZXJhbCBhbmNpbGxhcnkgY29tcG9uZW50cy4gIA0K ICAgIFRoZXNlIGNvbXBvbmVudHMgbWF5IGJlIGNvbm5lY3RlZCBpbiBkaWZmZXJlbnQga2luZHMg b2YgdG9wb2xvZ2llcyANCiAgICBmb3IgZmxleGlibGUgcGFja2V0IHByb2Nlc3NpbmcuICANCiAg ICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgRm9yQ0VTIE5l dHdvcmsgRWxlbWVudCAgICAgICAgICAgICAgfCANCiAgICAgLS0tLS0tLS0tLS0tLS0gICBGYyAg ICB8IC0tLS0tLS0tLS0tLS0tICAgICAgLS0tLS0tLS0tLS0tLS0gIHwgDQogICAgIHwgQ0UgTWFu YWdlciB8LS0tLS0tLS0tKy18ICAgICBDRSAxICAgfC0tLS0tLXwgICAgQ0UgMiAgICB8ICB8IA0K ICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAgIHwgfCAgICAgICAgICAgIHwgIEZyICB8ICAgICAg ICAgICAgfCAgfCANCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8IC0tLS0tLS0tLS0tLS0t ICAgICAgLS0tLS0tLS0tLS0tLS0gIHwgDQogICAgICAgICAgIHwgRmwgICAgICAgICAgICAgfCAg ICAgICAgIHwgIHwgICAgRnAgICAgICAgLyAgICAgICAgICB8IA0KICAgICAgICAgICB8ICAgICAg ICAgICAgICAgIHwgICAgICAgRnB8ICB8LS0tLS0tLS0tLXwgLyAgICAgICAgICAgfCANCiAgICAg ICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICB8LyAgICAgICAg ICAgIHwgDQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAg ICAgfCAgICAgICAgICAgICB8IA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAg ICB8ICAgICBGcCAgICAgL3wtLS0tfCAgICAgICAgfCANCiAgICAgICAgICAgfCAgICAgICAgICAg ICAgICB8ICAgICAgICAgfCAgLy0tLS0tLS0tLyAgICAgIHwgICAgICAgIHwgDQogICAgIC0tLS0t LS0tLS0tLS0tICAgICBGZiAgfCAtLS0tLS0tLS0tLS0tLSAgICAgIC0tLS0tLS0tLS0tLS0tICB8 IA0KICAgICB8IEZFIE1hbmFnZXIgfC0tLS0tLS0tLSstfCAgICAgRkUgMSAgIHwgIEZpICB8ICAg ICBGRSAyICAgfCAgfCANCiAgICAgLS0tLS0tLS0tLS0tLS0gICAgICAgICB8IHwgICAgICAgICAg ICB8LS0tLS0tfCAgICAgICAgICAgIHwgIHwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAtLS0tLS0tLS0tLS0tLSAgICAgIC0tLS0tLS0tLS0tLS0tICB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgIHwgIHwgIHwgIHwgICAgICAgICAgfCAgfCAgfCAgfCAgICB8IA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0rLS0rLS0rLS0rLS0tLS0tLS0tLSstLSstLSst LSstLS0tLSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgfCAgfCAgfCAgICAg ICAgICB8ICB8ICB8ICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICB8ICB8 ICB8ICAgICAgICAgIHwgIHwgIHwgIHwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmkvZiAgICAgICAgICAgICAgICAgICBGaS9mIA0KICAgICANCiAgICAgICAgIEZwOiBDRS1G RSBpbnRlcmZhY2UgIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAg IDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0gIA0KDQogSW50ZXJuZXQgRHJhZnQgICAg ICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDQgDQogIA0K ICANCiAgICAgICAgIEZpOiBGRS1GRSBpbnRlcmZhY2UgDQogICAgICAgICBGcjogQ0UtQ0UgaW50 ZXJmYWNlIA0KICAgICAgICAgRmM6IEludGVyZmFjZSBiZXR3ZWVuIHRoZSBDRSBNYW5hZ2VyIGFu ZCBhIENFIA0KICAgICAgICAgRmY6IEludGVyZmFjZSBiZXR3ZWVuIHRoZSBGRSBNYW5hZ2VyIGFu ZCBhbiBGRSANCiAgICAgICAgIEZsOiBJbnRlcmZhY2UgYmV0d2VlbiB0aGUgQ0UgTWFuYWdlciBh bmQgdGhlIEZFIE1hbmFnZXIgDQogICAgICAgICBGaS9mOiBGRSBleHRlcm5hbCBpbnRlcmZhY2Ug IA0KICAgICANCiAgICAgICAgICAgICAgICAgRmlndXJlIDQuIEZvckNFUyBBcmNoaXRlY3R1cmFs IERpYWdyYW0gDQogICAgIA0KICAgIFRoZSBkaWFncmFtIGluIEZpZ3VyZSA0IHNob3dzIHRoZSBs b2dpY2FsIGNvbXBvbmVudHMgb2YgdGhlIEZvckNFUyANCiAgICBhcmNoaXRlY3R1cmUgYW5kIHRo ZWlyIHJlbGF0aW9uc2hpcHMuICBUaGVyZSBhcmUgdHdvIGtpbmRzIG9mIA0KICAgIGNvbXBvbmVu dHMgaW5zaWRlIGEgRm9yQ0VTIG5ldHdvcmsgZWxlbWVudDogY29udHJvbCBlbGVtZW50IChDRSkg DQogICAgYW5kIGZvcndhcmRpbmcgZWxlbWVudCAoRkUpLiAgVGhlIGZyYW1ld29yayBhbGxvd3Mg bXVsdGlwbGUgDQogICAgaW5zdGFuY2VzIG9mIENFIGFuZCBGRSBpbnNpZGUgb25lIE5FLiAgRWFj aCBGRSBjb250YWlucyBvbmUgb3IgbW9yZSANCiAgICBwaHlzaWNhbCBtZWRpYSBpbnRlcmZhY2Vz IGZvciByZWNlaXZpbmcgYW5kIHRyYW5zbWl0dGluZyBwYWNrZXRzIA0KICAgIGZyb20vdG8gdGhl IGV4dGVybmFsIHdvcmxkLiAgVGhlIGFnZ3JlZ2F0aW9uIG9mIHRoZXNlIEZFIGludGVyZmFjZXMg DQogICAgYmVjb21lcyB0aGUgTkUncyBleHRlcm5hbCBpbnRlcmZhY2VzLiAgSW4gYWRkaXRpb24g dG8gdGhlIGV4dGVybmFsIA0KICAgIGludGVyZmFjZXMsIHRoZXJlIG11c3QgYWxzbyBleGlzdCBz b21lIGtpbmQgb2YgaW50ZXJjb25uZWN0IHdpdGhpbiANCiAgICB0aGUgTkUgc28gdGhhdCB0aGUg Q0UgYW5kIEZFIGNhbiBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIsIGFuZCANCiAgICBvbmUg RkUgY2FuIGZvcndhcmQgcGFja2V0cyB0byBhbm90aGVyIEZFLiAgVGhlIGRpYWdyYW0gYWxzbyBz aG93cyANCiAgICB0d28gZW50aXRpZXMgb3V0c2lkZSBvZiB0aGUgRm9yQ0VTIE5FOiBDRSBNYW5h Z2VyIGFuZCBGRSBNYW5hZ2VyLiAgDQogICAgVGhlc2UgdHdvIGFuY2lsbGFyeSBlbnRpdGllcyBw cm92aWRlIGNvbmZpZ3VyYXRpb24gdG8gdGhlIA0KICAgIGNvcnJlc3BvbmRpbmcgQ0Ugb3IgRkUg aW4gdGhlIHByZS1hc3NvY2lhdGlvbiBwaGFzZSAoc2VlIFNlY3Rpb24gDQogICAgNC4xKS4gICAN CiAgICAgDQogICAgRm9yIGNvbnZlbmllbmNlLCB0aGUgbG9naWNhbCBpbnRlcmFjdGlvbnMgYmV0 d2VlbiB0aGVzZSBjb21wb25lbnRzIA0KICAgIGFyZSBsYWJlbGVkIGJ5IHJlZmVyZW5jZSBwb2lu dHMgRnAsIEZjLCBGZiwgRnIsIEZsLCBhbmQgRmksIGFzIA0KICAgIHNob3duIGluIEZpZ3VyZSA0 LiAgVGhlIEZFIGV4dGVybmFsIGludGVyZmFjZXMgYXJlIGxhYmVsZWQgYXMgRmkvZi4gDQogICAg TW9yZSBkZXRhaWwgaXMgcHJvdmlkZWQgaW4gU2VjdGlvbiAzIGFuZCA0IGZvciBlYWNoIG9mIHRo ZXNlIA0KICAgIHJlZmVyZW5jZSBwb2ludHMuICBBbGwgdGhlc2UgcmVmZXJlbmNlIHBvaW50cyBh cmUgaW1wb3J0YW50IGluIA0KICAgIHVuZGVyc3RhbmRpbmcgdGhlIEZvckNFUyBhcmNoaXRlY3R1 cmUsIGhvd2V2ZXIsIHRoZSBGb3JDRVMgUHJvdG9jb2wgDQogICAgaXMgb25seSBkZWZpbmVkIG92 ZXIgb25lIHJlZmVyZW5jZSBwb2ludCAtLSBGcC4gIA0KICAgICANCiAgICBUaGUgaW50ZXJmYWNl IGJldHdlZW4gdHdvIEZvckNFUyBORXMgaXMgaWRlbnRpY2FsIHRvIHRoZSBpbnRlcmZhY2UgDQog ICAgYmV0d2VlbiB0d28gY29udmVudGlvbmFsIHJvdXRlcnMgYW5kIHRoZXNlIHR3byBORXMgZXhj aGFuZ2UgdGhlIA0KICAgIHByb3RvY29sIHBhY2tldHMgdGhyb3VnaCB0aGUgZXh0ZXJuYWwgaW50 ZXJmYWNlcyBhdCBGaS9mLiAgRm9yQ0VTIA0KICAgIE5FcyBjb25uZWN0IHRvIGV4aXN0aW5nIHJv dXRlcnMgdHJhbnNwYXJlbnRseS4gDQogIA0KIDMuMS4gQ29udHJvbCBFbGVtZW50cyBhbmQgRnIg UmVmZXJlbmNlIFBvaW50IA0KICAgICANCiAgICBJdCBpcyBub3QgbmVjZXNzYXJ5IHRvIGRlZmlu ZSBhbnkgcHJvdG9jb2xzIGFjcm9zcyB0aGUgRnIgcmVmZXJlbmNlIA0KICAgIHBvaW50IHRvIGVu YWJsZSBjb250cm9sIGFuZCBmb3J3YXJkaW5nIHNlcGFyYXRpb24gZm9yIHNpbXBsZSANCiAgICBj b25maWd1cmF0aW9ucyBsaWtlIHNpbmdsZSBDRSBhbmQgbXVsdGlwbGUgRkVzLiAgSG93ZXZlciwg dGhpcyANCiAgICBhcmNoaXRlY3R1cmUgcGVybWl0cyBtdWx0aXBsZSBDRXMgdG8gYmUgcHJlc2Vu dCBpbiBhIG5ldHdvcmsgDQogICAgZWxlbWVudC4gIEluIGNhc2VzIHdoZXJlIGFuIGltcGxlbWVu dGF0aW9uIHVzZXMgbXVsdGlwbGUgQ0VzLCB0aGUgDQogICAgaW52YXJpYW50IHRoYXQgdGhlIENF cyBhbmQgRkVzIHRvZ2V0aGVyIGFwcGVhciBhcyBhIHNpbmdsZSBORSBtdXN0IA0KICAgIGJlIG1h aW50YWluZWQuIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIw MDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAg ICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAg DQogICAgIA0KICAgIE11bHRpcGxlIENFcyBtYXkgYmUgdXNlZCBmb3IgcmVkdW5kYW5jeSwgbG9h ZCBzaGFyaW5nLCBkaXN0cmlidXRlZCANCiAgICBjb250cm9sLCBvciBvdGhlciBwdXJwb3Nlcy4g IFJlZHVuZGFuY3kgaXMgdGhlIGNhc2Ugd2hlcmUgb25lIG9yIA0KICAgIG1vcmUgQ0VzIGFyZSBw cmVwYXJlZCB0byB0YWtlIG92ZXIgc2hvdWxkIGFuIGFjdGl2ZSBDRSBmYWlsLiAgTG9hZCANCiAg ICBzaGFyaW5nIGlzIHRoZSBjYXNlIHdoZXJlIHR3byBvciBtb3JlIENFcyBhcmUgY29uY3VycmVu dGx5IGFjdGl2ZSANCiAgICBhbmQgYW55IHJlcXVlc3QgdGhhdCBjYW4gYmUgc2VydmljZWQgYnkg b25lIG9mIHRoZSBDRXMgY2FuIGFsc28gYmUgDQogICAgc2VydmljZWQgYnkgYW55IG9mIHRoZSBv dGhlciBDRXMuICBGb3IgYm90aCByZWR1bmRhbmN5IGFuZCBsb2FkIA0KICAgIHNoYXJpbmcsIHRo ZSBDRXMgaW52b2x2ZWQgYXJlIGVxdWl2YWxlbnRseSBjYXBhYmxlLiAgVGhlIG9ubHkgDQogICAg ZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZXNlIHR3byBjYXNlcyBpcyBpbiB0ZXJtcyBvZiBob3cgbWFu eSBhY3RpdmUgDQogICAgQ0VzIHRoZXJlIGFyZS4gIERpc3RyaWJ1dGVkIGNvbnRyb2wgaXMgdGhl IGNhc2Ugd2hlcmUgdHdvIG9yIG1vcmUgDQogICAgQ0VzIGFyZSBjb25jdXJyZW50bHkgYWN0aXZl IGJ1dCBjZXJ0YWluIHJlcXVlc3RzIGNhbiBvbmx5IGJlIA0KICAgIHNlcnZpY2VkIGJ5IGNlcnRh aW4gQ0VzLiANCiAgDQogICAgV2hlbiBtdWx0aXBsZSBDRXMgYXJlIGVtcGxveWVkIGluIGEgRm9y Q0VTIE5FLCB0aGVpciBpbnRlcm5hbCANCiAgICBvcmdhbml6YXRpb24gaXMgY29uc2lkZXJlZCBh biBpbXBsZW1lbnRhdGlvbiBpc3N1ZSB0aGF0IGlzIGJleW9uZCANCiAgICB0aGUgc2NvcGUgb2Yg Rm9yQ0VTLiAgQ0VzIGFyZSB3aG9sbHkgcmVzcG9uc2libGUgZm9yIGNvb3JkaW5hdGluZyANCiAg ICBhbW9uZ3N0IHRoZW1zZWx2ZXMgdmlhIHRoZSBGciByZWZlcmVuY2UgcG9pbnQgdG8gcHJvdmlk ZSANCiAgICBjb25zaXN0ZW5jeSBhbmQgc3luY2hyb25pemF0aW9uLiAgSG93ZXZlciwgRm9yQ0VT IGRvZXMgbm90IGRlZmluZSANCiAgICB0aGUgaW1wbGVtZW50YXRpb24gb3IgcHJvdG9jb2xzIHVz ZWQgYmV0d2VlbiBDRXMsIG5vciBkb2VzIGl0IA0KICAgIGRlZmluZSBob3cgdG8gZGlzdHJpYnV0 ZSBmdW5jdGlvbmFsaXR5IGFtb25nIENFcy4gIE5ldmVydGhlbGVzcywgDQogICAgRm9yQ0VTIHdp bGwgc3VwcG9ydCBtZWNoYW5pc21zIGZvciBDRSByZWR1bmRhbmN5IG9yIGZhaWwgb3ZlciwgYW5k IA0KICAgIGl0IGlzIGV4cGVjdGVkIHRoYXQgdmVuZG9ycyB3aWxsIHByb3ZpZGUgcmVkdW5kYW5j eSBvciBmYWlsIG92ZXIgDQogICAgc29sdXRpb25zIHdpdGhpbiB0aGlzIGZyYW1ld29yay4gDQog IA0KICANCiAzLjIuIEZvcndhcmRpbmcgRWxlbWVudHMgYW5kIEZpIHJlZmVyZW5jZSBwb2ludCAN CiAgICAgDQogICAgQW4gRkUgaXMgYSBsb2dpY2FsIGVudGl0eSB0aGF0IGltcGxlbWVudHMgdGhl IEZvckNFUyBQcm90b2NvbCBhbmQgDQogICAgdXNlcyB0aGUgdW5kZXJseWluZyBoYXJkd2FyZSB0 byBwcm92aWRlIHBlci1wYWNrZXQgcHJvY2Vzc2luZyBhbmQgDQogICAgaGFuZGxpbmcgYXMgZGly ZWN0ZWQgYnkgYSBDRS4gIEl0IGlzIHBvc3NpYmxlIHRvIHBhcnRpdGlvbiBvbmUgDQogICAgcGh5 c2ljYWwgRkUgaW50byBtdWx0aXBsZSBsb2dpY2FsIEZFcy4gIEl0IGlzIGFsc28gcG9zc2libGUg Zm9yIG9uZSANCiAgICBGRSB0byB1c2UgbXVsdGlwbGUgcGh5c2ljYWwgRkVzLiAgVGhlIG1hcHBp bmcgYmV0d2VlbiBwaHlzaWNhbCANCiAgICBGRShzKSBhbmQgdGhlIGxvZ2ljYWwgRkUocykgaXMg YmV5b25kIHRoZSBzY29wZSBvZiBGb3JDRVMuICBGb3IgDQogICAgZXhhbXBsZSwgYSBsb2dpY2Fs IHBhcnRpdGlvbiBvZiBhIHBoeXNpY2FsIEZFIGNhbiBiZSBjcmVhdGVkIGJ5IA0KICAgIGFzc2ln bmluZyBzb21lIHBvcnRpb24gb2YgZWFjaCBvZiB0aGUgcmVzb3VyY2VzIChlLmcuLCBwb3J0cywg DQogICAgbWVtb3J5LCBmb3J3YXJkaW5nIHRhYmxlIGVudHJpZXMpIGF2YWlsYWJsZSBvbiB0aGUg Rm9yQ0VTIHBoeXNpY2FsIA0KICAgIEZFIHRvIGVhY2ggb2YgdGhlIGxvZ2ljYWwgRkVzLiAgU3Vj aCBjb25jZXB0IG9mIEZFIHZpcnR1YWxpemF0aW9uIA0KICAgIGlzIGFuYWxvZ291cyB0byBhIHZp cnR1YWwgc3dpdGNoaW5nIGVsZW1lbnQgYXMgZGVzY3JpYmVkIGluIFs4XS4gIA0KICAgIElmIEZF IHZpcnR1YWxpemF0aW9uIG9jY3VycyBvbmx5IGluIHRoZSBwcmUtYXNzb2NpYXRpb24gcGhhc2Us IGl0IA0KICAgIGhhcyBubyBpbXBhY3Qgb24gRm9yQ0VTLiBIb3dldmVyLCBpZiBGRSB2aXJ0dWFs aXphdGlvbiByZXN1bHRzIGluIA0KICAgIHJlc291cmNlIGNoYW5nZSB0YWtlbiBmcm9tIGFuIGV4 aXN0aW5nIEZFIChhbHJlYWR5IHBhcnRpY2lwYXRpbmcgaW4gDQogICAgRm9yQ0VTIHBvc3QtYXNz b2NpYXRpb24gcGhhc2UpLCB0aGUgRm9yQ0VTIFByb3RvY29sIG5lZWRzIHRvIGJlIA0KICAgIGFi bGUgdG8gaW5mb3JtIHRoZSBDRSBvZiBzdWNoIGNoYW5nZSB2aWEgYXN5bmNocm9ub3VzIG1lc3Nh Z2VzIChzZWUgDQogICAgWzNdLCBTZWN0aW9uIDUsIHJlcXVpcmVtZW50ICM2KS4gDQogICAgIA0K ICAgIEZFcyBwZXJmb3JtIGFsbCBwYWNrZXQgcHJvY2Vzc2luZyBmdW5jdGlvbnMgYXMgZGlyZWN0 ZWQgYnkgQ0VzLiAgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEp1bHkgICAg MjAwNCAgICAgICAgICAgICAgICAgICBbUGFnZSAxMV0gIA0KDQogSW50ZXJuZXQgRHJhZnQgICAg ICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDQgDQogIA0K ICANCiAgICBGRXMgaGF2ZSBubyBpbml0aWF0aXZlIG9mIHRoZWlyIG93bi4gIEluc3RlYWQsIEZF cyBhcmUgc2xhdmVzIGFuZCANCiAgICBvbmx5IGRvIGFzIHRoZXkgYXJlIHRvbGQuICBGRXMgbWF5 IGNvbW11bmljYXRlIHdpdGggb25lIG9yIG1vcmUgQ0VzIA0KICAgIGNvbmN1cnJlbnRseSBhY3Jv c3MgcmVmZXJlbmNlIHBvaW50IEZwLiAgRkVzIGhhdmUgbm8gbm90aW9uIG9mIENFIA0KICAgIHJl ZHVuZGFuY3ksIGxvYWQgc2hhcmluZywgb3IgZGlzdHJpYnV0ZWQgY29udHJvbC4gIEluc3RlYWQs IEZFcyANCiAgICBhY2NlcHQgY29tbWFuZHMgZnJvbSBhbnkgQ0UgYXV0aG9yaXplZCB0byBjb250 cm9sIHRoZW0sIGFuZCBpdCBpcyANCiAgICB1cCB0byB0aGUgQ0VzIHRvIGNvb3JkaW5hdGUgYW1v bmcgdGhlbXNlbHZlcyB0byBhY2hpZXZlIHJlZHVuZGFuY3ksIA0KICAgIGxvYWQgc2hhcmluZyBv ciBkaXN0cmlidXRlZCBjb250cm9sLiAgVGhlIGlkZWEgaXMgdG8ga2VlcCBGRXMgYXMgDQogICAg c2ltcGxlIGFuZCBkdW1iIGFzIHBvc3NpYmxlIHNvIHRoYXQgRkVzIGNhbiBmb2N1cyB0aGVpciBy ZXNvdXJjZSBvbiANCiAgICB0aGUgcGFja2V0IHByb2Nlc3NpbmcgZnVuY3Rpb25zLiAgVW5sZXNz IG90aGVyd2lzZSBjb25maWd1cmVkIG9yIA0KICAgIGRldGVybWluZWQgYnkgYSBGb3JDRXMgUHJv dG9jb2wgZXhjaGFuZ2UsIGVhY2ggRkUgd2lsbCBwcm9jZXNzIA0KICAgIGF1dGhvcml6ZWQgaW5j b21pbmcgY29tbWFuZHMgZGlyZWN0ZWQgYXQgaXQgYXMgaXQgcmVjZWl2ZXMgdGhlbSBvbiANCiAg ICBhIGZpcnN0IGNvbWUgZmlyc3Qgc2VydmUgYmFzaXMuICAgDQogICAgIA0KICAgIEZvciBleGFt cGxlLCBpbiBGaWd1cmUgNSwgRkUxIGFuZCBGRTIgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gYWNjZXB0 IA0KICAgIGNvbW1hbmRzIGZyb20gYm90aCB0aGUgcHJpbWFyeSBDRSAoQ0UxKSBhbmQgdGhlIGJh Y2t1cCBDRSAoQ0UyKS4gIA0KICAgIFVwb24gZGV0ZWN0aW9uIG9mIENFMSBmYWlsdXJlLCBwZXJo YXBzIGFjcm9zcyB0aGUgRnIgb3IgRnAgDQogICAgcmVmZXJlbmNlIHBvaW50LCBDRTIgaXMgY29u ZmlndXJlZCB0byB0YWtlIG92ZXIgYWN0aXZpdGllcyBvZiBDRTEuICANCiAgICBUaGlzIGlzIGJl eW9uZCB0aGUgc2NvcGUgb2YgRm9yQ0VTIGFuZCBpcyBub3QgZGlzY3Vzc2VkIGZ1cnRoZXIuIA0K ICAgICANCiAgICBEaXN0cmlidXRlZCBjb250cm9sIGNhbiBiZSBhY2hpZXZlZCBpbiBhIHNpbWls YXIgZmFzaGlvbiwgd2l0aG91dCANCiAgICBtdWNoIGludGVsbGlnZW5jZSBvbiB0aGUgcGFydCBv ZiBGRXMuICBGb3IgZXhhbXBsZSwgRkVzIGNhbiBiZSANCiAgICBjb25maWd1cmVkIHRvIGRldGVj dCBSU1ZQIGFuZCBCR1AgcHJvdG9jb2wgcGFja2V0cywgYW5kIGZvcndhcmQgDQogICAgUlNWUCBw YWNrZXRzIHRvIG9uZSBDRSBhbmQgQkdQIHBhY2tldHMgdG8gYW5vdGhlciBDRS4gIEhlbmNlLCBG RXMgDQogICAgbWF5IG5lZWQgdG8gZG8gcGFja2V0IGZpbHRlcmluZyBmb3IgZm9yd2FyZGluZyBw YWNrZXRzIHRvIHNwZWNpZmljIA0KICAgIENFcy4gDQogICAgIA0KICAgICAgICAgICAgICAgICAt LS0tLS0tICAgRnIgIC0tLS0tLS0gDQogICAgICAgICAgICAgICAgIHwgQ0UxIHwgLS0tLS0tfCBD RTIgfCANCiAgICAgICAgICAgICAgICAgLS0tLS0tLSAgICAgICAtLS0tLS0tIA0KICAgICAgICAg ICAgICAgICAgIHwgICBcICAgICAgLyAgIHwgDQogICAgICAgICAgICAgICAgICAgfCAgICBcICAg IC8gICAgfCANCiAgICAgICAgICAgICAgICAgICB8ICAgICBcICAvICAgICB8IA0KICAgICAgICAg ICAgICAgICAgIHwgICAgICBcL0ZwICAgIHwgDQogICAgICAgICAgICAgICAgICAgfCAgICAgIC9c ICAgICAgfCANCiAgICAgICAgICAgICAgICAgICB8ICAgICAvICBcICAgICB8IA0KICAgICAgICAg ICAgICAgICAgIHwgICAgLyAgICBcICAgIHwgDQogICAgICAgICAgICAgICAgIC0tLS0tLS0gIEZp ICAgLS0tLS0tLSANCiAgICAgICAgICAgICAgICAgfCBGRTEgfDwtLS0tLT58IEZFMiB8IA0KICAg ICAgICAgICAgICAgICAtLS0tLS0tICAgICAgIC0tLS0tLS0gDQogIA0KICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgNS4gQ0UgcmVkdW5kYW5jeSBleGFtcGxlLiANCiAgICAgDQogICAgVGhpcyBh cmNoaXRlY3R1cmUgcGVybWl0cyBtdWx0aXBsZSBGRXMgdG8gYmUgcHJlc2VudCBpbiBhbiBORS4g WzNdIA0KICAgIGRpY3RhdGVzIHRoYXQgdGhlIEZvckNFUyBQcm90b2NvbCBtdXN0IGJlIGFibGUg dG8gc2NhbGUgdG8gYXQgbGVhc3QgDQogICAgaHVuZHJlZHMgb2YgRkVzIChzZWUgWzNdIFNlY3Rp b24gNSwgcmVxdWlyZW1lbnQgIzExKS4gIEVhY2ggb2YgDQogICAgdGhlc2UgRkVzIG1heSBwb3Rl bnRpYWxseSBoYXZlIGEgZGlmZmVyZW50IHNldCBvZiBwYWNrZXQgcHJvY2Vzc2luZyANCiAgICBm dW5jdGlvbnMsIHdpdGggZGlmZmVyZW50IG1lZGlhIGludGVyZmFjZXMuICBGRXMgYXJlIHJlc3Bv bnNpYmxlIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAg Rm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQog ICAgZm9yIGJhc2ljIG1haW50ZW5hbmNlIG9mIGxheWVyLTIgY29ubmVjdGl2aXR5IHdpdGggb3Ro ZXIgRkVzIGFuZCANCiAgICB3aXRoIGV4dGVybmFsIGVudGl0aWVzLiAgTWFueSBsYXllci0yIG1l ZGlhIGluY2x1ZGUgc29waGlzdGljYXRlZCANCiAgICBjb250cm9sIHByb3RvY29scy4gIFRoZSBG T1JDRVMgUHJvdG9jb2wgKG92ZXIgdGhlIEZwIHJlZmVyZW5jZSANCiAgICBwb2ludCkgd2lsbCBi ZSBhYmxlIHRvIGNhcnJ5IG1lc3NhZ2VzIGZvciBzdWNoIHByb3RvY29scyBzbyB0aGF0LCANCiAg ICBpbiBrZWVwaW5nIHdpdGggdGhlIGR1bWIgRkUgbW9kZWwsIHRoZSBDRSBjYW4gcHJvdmlkZSBh cHByb3ByaWF0ZSANCiAgICBpbnRlbGxpZ2VuY2UgYW5kIGNvbnRyb2wgb3ZlciB0aGVzZSBtZWRp YS4gDQogICAgIA0KICAgIFdoZW4gbXVsdGlwbGUgRkVzIGFyZSBwcmVzZW50LCBGb3JDRVMgcmVx dWlyZXMgdGhhdCBwYWNrZXRzIG11c3QgYmUgDQogICAgYWJsZSB0byBhcnJpdmUgYXQgdGhlIE5F IGJ5IG9uZSBGRSBhbmQgbGVhdmUgdGhlIE5FIHZpYSBhIGRpZmZlcmVudCANCiAgICBGRSAoU2Vl IFszXSwgU2VjdGlvbiA1LCBSZXF1aXJlbWVudCAjMykuICBQYWNrZXRzIHRoYXQgZW50ZXIgdGhl IE5FIA0KICAgIHZpYSBvbmUgRkUgYW5kIGxlYXZlIHRoZSBORSB2aWEgYSBkaWZmZXJlbnQgRkUg YXJlIHRyYW5zZmVycmVkIA0KICAgIGJldHdlZW4gRkVzIGFjcm9zcyB0aGUgRmkgcmVmZXJlbmNl IHBvaW50LiAgRmkgcmVmZXJlbmNlIHBvaW50IA0KICAgIGNvdWxkIGJlIHVzZWQgYnkgRkVzIHRv IGRpc2NvdmVyeSB0aGVpciAoaW50ZXItRkUpIHRvcG9sb2d5LCANCiAgICBwZXJoYXBzIGR1cmlu ZyBwcmUtYXNzb2NpYXRpb24gcGhhc2UuICBUaGUgRmkgcmVmZXJlbmNlIHBvaW50IGlzIGEgDQog ICAgc2VwYXJhdGUgcHJvdG9jb2wgZnJvbSB0aGUgRnAgcmVmZXJlbmNlIHBvaW50IGFuZCBpcyBu b3QgY3VycmVudGx5IA0KICAgIGRlZmluZWQgYnkgdGhlIEZvckNFUyBhcmNoaXRlY3R1cmUuIA0K ICAgICANCiAgICBGRXMgY291bGQgYmUgY29ubmVjdGVkIGluIGRpZmZlcmVudCBraW5kcyBvZiB0 b3BvbG9naWVzIGFuZCBwYWNrZXQgDQogICAgcHJvY2Vzc2luZyBtYXkgc3ByZWFkIGFjcm9zcyBz ZXZlcmFsIEZFcyBpbiB0aGUgdG9wb2xvZ3kuICBIZW5jZSwgDQogICAgbG9naWNhbCBwYWNrZXQg ZmxvdyBtYXkgYmUgZGlmZmVyZW50IGZyb20gcGh5c2ljYWwgRkUgdG9wb2xvZ3kuIA0KICAgIEZp Z3VyZSA2IHByb3ZpZGVzIHNvbWUgdG9wb2xvZ3kgZXhhbXBsZXMuICBXaGVuIGl0IGlzIG5lY2Vz c2FyeSB0byANCiAgICBmb3J3YXJkIHBhY2tldHMgYmV0d2VlbiBGRXMsIHRoZSBDRSBuZWVkcyB0 byB1bmRlcnN0YW5kIHRoZSBGRSANCiAgICB0b3BvbG9neS4gIFRoZSBGRSB0b3BvbG9neSBtYXkg YmUgcXVlcmllZCBmcm9tIHRoZSBGRXMgYnkgdGhlIENFcyANCiAgICB2aWEgRm9yQ0VTIFByb3Rv Y29sLCBidXQgdGhlIEZFcyBhcmUgbm90IHJlcXVpcmVkIHRvIHByb3ZpZGUgdGhhdCANCiAgICBp bmZvcm1hdGlvbiB0byB0aGUgQ0VzLiBTbywgdGhlIEZFIHRvcG9sb2d5IGluZm9ybWF0aW9uIG1h eSBhbHNvIGJlIA0KICAgIGdhdGhlcmVkIGJ5IG90aGVyIG1lYW5zIG91dHNpZGUgb2YgdGhlIEZv ckNFUyBQcm90b2NvbCAobGlrZSBpbnRlci0NCiAgICBGRSB0b3BvbG9neSBkaXNjb3ZlcnkgcHJv dG9jb2wpLiAgDQogICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAt LS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICBDRSAgICAgICB8ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgLS0t LS0tLS0tLS0tLS0tLS0gICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgXiAgICAg IF4gICAgICBeIA0KICAgICAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgfCAgICAgICBcIA0K ICAgICAgICAgICAgICAgICAgICAgICAgLyAgICAgICAgdiAgICAgICAgXCANCiAgICAgICAgICAg ICAgICAgICAgICAgLyAgICAgIC0tLS0tLS0gICAgICBcIA0KICAgICAgICAgICAgICAgICAgICAg IC8gICAgKy0+fCBGRTMgfDwtKyAgICBcIA0KICAgICAgICAgICAgICAgICAgICAgLyAgICAgfCAg fCAgICAgfCAgfCAgICAgXCANCiAgICAgICAgICAgICAgICAgICAgdiAgICAgIHwgIC0tLS0tLS0g IHwgICAgICB2IA0KICAgICAgICAgICAgICAgICAgLS0tLS0tLSAgfCAgICAgICAgICAgfCAgLS0t LS0tLSANCiAgICAgICAgICAgICAgICAgIHwgRkUxIHw8LSsgICAgICAgICAgICstPnwgRkUyIHwg DQogICAgICAgICAgICAgICAgICB8ICAgICB8PC0tLS0tLS0tLS0tLS0tLT58ICAgICB8IA0KICAg ICAgICAgICAgICAgICAgLS0tLS0tLSAgICAgICAgICAgICAgICAgLS0tLS0tLSANCiAgICAgICAg ICAgICAgICAgICAgIF4gIHwgICAgICAgICAgICAgICAgICAgXiAgfCANCiAgICAgICAgICAgICAg ICAgICAgIHwgIHwgICAgICAgICAgICAgICAgICAgfCAgfCANCiAgICAgICAgICAgICAgICAgICAg IHwgIHYgICAgICAgICAgICAgICAgICAgfCAgdiANCiAgICAgDQogICAgICAgICAgICAgICAgIChh KSBGdWxsIG1lc2ggYW1vbmcgRkUxLCBGRTIgYW5kIEZFMy4gDQogIA0KICANCiBZYW5nLCBldCBh bC4gICAgICBFeHBpcmVzIEp1bHkgICAgMjAwNCAgICAgICAgICAgICAgICAgICBbUGFnZSAxM10g IA0KDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAg ICAgICBKYW51YXJ5IDIwMDQgDQogIA0KICANCiAgDQogICAgIA0KICAgICAgICAgICAgICAgICAg ICAgICAgIC0tLS0tLS0tLS0tICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg IHwgICBDRSAgICB8ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0t ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICBeIF4gICAgICAgXiBeIA0KICAgICAg ICAgICAgICAgICAgICAgICAvICB8ICAgICAgIHwgIFwgDQogICAgICAgICAgICAgICAgLy0tLS0t LSAgIHwgICAgICAgfCAgIC0tLS0tLVwgDQogICAgICAgICAgICAgICAgdiAgICAgICAgIHYgICAg ICAgdiAgICAgICAgICB2IA0KICAgICAgICAgICAgLS0tLS0tLSAgIC0tLS0tLS0gICAtLS0tLS0t ICAgLS0tLS0tLSANCiAgICAgICAgICAgIHwgRkUxIHw8LT58IEZFMiB8PC0+fCBGRTMgfDwtPnwg RkU0IHwgDQogICAgICAgICAgICAtLS0tLS0tICAgLS0tLS0tLSAgIC0tLS0tLS0gICAtLS0tLS0t IA0KICAgICAgICAgICAgICBeICB8ICAgICBeICB8ICAgICAgIF4gIHwgICAgIF4gIHwgDQogICAg ICAgICAgICAgIHwgIHwgICAgIHwgIHwgICAgICAgfCAgfCAgICAgfCAgfCANCiAgICAgICAgICAg ICAgfCAgdiAgICAgfCAgdiAgICAgICB8ICB2ICAgICB8ICB2IA0KICAgICANCiAgICAgICAgICAg ICAgICAgKGIpIE11bHRpcGxlIEZFcyBpbiBhIGRhaXN5IGNoYWluIA0KICANCiAgDQogIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIF4gfCANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IHYgDQogICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0gICAgICAgICAgICAg DQogICAgICAgICAgICAgICAgICAgICAgICAgfCAgIEZFMSAgIHw8LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS18ICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0gICAgICAg ICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgXiAgICBeICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgLyAg ICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIA0KICAgICAgICAgICAgICAgICAgIHwg XiAgIC8gICAgICAgIFwgICBeIHwgICAgICAgICAgICAgICAgICAgViANCiAgICAgICAgICAgICAg ICAgICB2IHwgIHYgICAgICAgICAgdiAgfCB2ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0gDQog ICAgICAgICAgICAgICAgIC0tLS0tLS0tLSAgICAgICAgLS0tLS0tLS0tICAgICAgICAgICAgICB8 ICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8IEZFMiAgIHwgICAgICAgIHwgIEZFMyAgfDwt LS0tLS0tLS0tLS0+fCAgIENFICAgfCANCiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tICAgICAg ICAtLS0tLS0tLS0gICAgICAgICAgICAgIHwgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAg ICBeICBeICAgICAgICAgIF4gICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tIA0KICAgICAg ICAgICAgICAgICAgICAgfCAgIFwgICAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICBeICBe IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICBcICAgICAgLyAgICAgICAgICAgICAgICAgICAg ICAgICB8ICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICB2ICAgICB2ICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgIC0tLS0tLS0tLS0t ICAgICAgICAgICAgICAgICAgICAgICB8ICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgIHwg ICBGRTQgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18ICB8ICAgIA0KICAgICAgICAgICAgICAg ICAgICAgfCAgIC0tLS0tLS0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAg ICAgICAgICAgICAgICAgfCAgICAgIHwgIF4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHYgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18IA0KICAgICANCiAgICAgICAgICAgICAgICAgKGMp IE11bHRpcGxlIEZFcyBjb25uZWN0ZWQgYnkgYSByaW5nIA0KICAgICANCiAgICAgICAgICAgICAg ICAgRmlndXJlIDYuIFNvbWUgZXhhbXBsZXMgb2YgRkUgdG9wb2xvZ3kuIA0KICANCiAgDQogWWFu ZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1Bh Z2UgMTRdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAg ICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgIA0KIDMuMy5DRSBNYW5hZ2Vy cyANCiAgICAgDQogICAgQ0UgbWFuYWdlcnMgYXJlIHJlc3BvbnNpYmxlIGZvciBkZXRlcm1pbmlu ZyB3aGljaCBGRXMgYSBDRSBzaG91bGQgDQogICAgY29udHJvbC4gIEl0IGlzIGxlZ2l0aW1hdGUg Zm9yIENFIG1hbmFnZXJzIHRvIGJlIGhhcmQtY29kZWQgd2l0aCANCiAgICB0aGUga25vd2xlZGdl IG9mIHdpdGggd2hpY2ggRkVzIGl0cyBDRXMgc2hvdWxkIGNvbW11bmljYXRlIHdpdGguICBBIA0K ICAgIENFIG1hbmFnZXIgbWF5IGFsc28gYmUgcGh5c2ljYWxseSBlbWJlZGRlZCBpbnRvIGEgQ0Ug YW5kIGJlIA0KICAgIGltcGxlbWVudGVkIGFzIGEgc2ltcGxlIGtleXBhZCBvciBvdGhlciBkaXJl Y3QgY29uZmlndXJhdGlvbiANCiAgICBtZWNoYW5pc20gb24gdGhlIENFLiAgRmluYWxseSwgQ0Ug bWFuYWdlcnMgbWF5IGJlIHBoeXNpY2FsbHkgYW5kIA0KICAgIGxvZ2ljYWxseSBzZXBhcmF0ZSBl bnRpdGllcyB0aGF0IGNvbmZpZ3VyZSB0aGUgQ0Ugd2l0aCBGRSANCiAgICBpbmZvcm1hdGlvbiB2 aWEgc3VjaCBtZWNoYW5pc21zIGFzIENPUFMtUFIgWzZdIG9yIFNOTVAgWzRdLiANCiAgICAgDQog My40LiBGRSBNYW5hZ2VycyANCiAgICAgDQogICAgRkUgbWFuYWdlcnMgYXJlIHJlc3BvbnNpYmxl IGZvciBkZXRlcm1pbmluZyB3aXRoIHdoaWNoIENFIGFueSANCiAgICBwYXJ0aWN1bGFyIEZFIHNo b3VsZCBpbml0aWFsbHkgY29tbXVuaWNhdGUuICBMaWtlIENFIG1hbmFnZXJzLCBubyANCiAgICBy ZXN0cmljdGlvbnMgYXJlIHBsYWNlZCBvbiBob3cgYW4gRkUgbWFuYWdlciBkZWNpZGVzIHdpdGgg d2hpY2ggQ0UgDQogICAgaXRzIEZFcyBzaG91bGQgY29tbXVuaWNhdGUsIG5vciBhcmUgcmVzdHJp Y3Rpb25zIHBsYWNlZCBvbiBob3cgRkUgDQogICAgbWFuYWdlcnMgYXJlIGltcGxlbWVudGVkLiAg RWFjaCBGRSBzaG91bGQgaGF2ZSBvbmUgYW5kIG9ubHkgb25lIEZFIA0KICAgIG1hbmFnZXIsIHdo aWxlIGRpZmZlcmVudCBGRXMgbWF5IGhhdmUgdGhlIHNhbWUgb3IgZGlmZmVyZW50IEZFIA0KICAg IG1hbmFnZXIocykuICBFYWNoIG1hbmFnZXIgY2FuIGNob29zZSB0byBleGlzdCBhbmQgb3BlcmF0 ZSANCiAgICBpbmRlcGVuZGVudGx5IG9mIG90aGVyIG1hbmFnZXIuIA0KICANCiA0LiBPcGVyYXRp b25hbCBQaGFzZXMgDQogICAgIA0KICAgIEJvdGggRkVzIGFuZCBDRXMgcmVxdWlyZSBzb21lIGNv bmZpZ3VyYXRpb24gaW4gcGxhY2UgYmVmb3JlIHRoZXkgDQogICAgY2FuIHN0YXJ0IGluZm9ybWF0 aW9uIGV4Y2hhbmdlIGFuZCBmdW5jdGlvbiBhcyBhIGNvaGVyZW50IG5ldHdvcmsgDQogICAgZWxl bWVudC4gIFR3byBvcGVyYXRpb25hbCBwaGFzZXMgYXJlIGlkZW50aWZpZWQgaW4gdGhpcyBmcmFt ZXdvcms6IA0KICAgIHByZS1hc3NvY2lhdGlvbiBhbmQgcG9zdC1hc3NvY2lhdGlvbi4gIA0KICAg ICANCiA0LjEuUHJlLWFzc29jaWF0aW9uIFBoYXNlIA0KICANCiAgICBQcmUtYXNzb2NpYXRpb24g cGhhc2UgaXMgdGhlIHBlcmlvZCBvZiB0aW1lIGR1cmluZyB3aGljaCBhbiBGRSANCiAgICBNYW5h Z2VyIGFuZCBhIENFIE1hbmFnZXIgYXJlIGRldGVybWluaW5nIHdoZXRoZXIgYW4gRkUgYW5kIGEg Q0UgDQogICAgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIHNhbWUgbmV0d29yayBlbGVtZW50LiAgVGhl IHByb3RvY29scyB1c2VkIA0KICAgIGR1cmluZyB0aGlzIHBoYXNlIG1heSBpbmNsdWRlIGFsbCBv ciBzb21lIG9mIHRoZSBtZXNzYWdlIGV4Y2hhbmdlIA0KICAgIG92ZXIgRmwsIEZmIGFuZCBGYyBy ZWZlcmVuY2UgcG9pbnRzLiAgSG93ZXZlciwgYWxsIHRoZXNlIG1heSBiZSANCiAgICBvcHRpb25h bCBhbmQgbm9uZSBvZiB0aGlzIGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgRm9yQ0VTIFByb3RvY29s LiANCiAgICAgDQogNC4xLjEuIEZsIFJlZmVyZW5jZSBQb2ludCANCiAgDQogICAgQ0UgbWFuYWdl cnMgYW5kIEZFIG1hbmFnZXJzIG1heSBjb21tdW5pY2F0ZSBhY3Jvc3MgdGhlIEZsIHJlZmVyZW5j ZSANCiAgICBwb2ludCBpbiB0aGUgcHJlLWFzc29jaWF0aW9uIHBoYXNlIGluIG9yZGVyIHRvIGRl dGVybWluZSB3aGV0aGVyIGFuIA0KICAgIGluZGl2aWR1YWwgQ0UgYW5kIEZFLCBvciBhIHNldCBv ZiBDRXMgYW5kIEZFcyBzaG91bGQgYmUgYXNzb2NpYXRlZC4gDQogICAgQ29tbXVuaWNhdGlvbiBh Y3Jvc3MgdGhlIEZsIHJlZmVyZW5jZSBwb2ludCBpcyBvcHRpb25hbCBpbiB0aGlzIA0KICAgIGFy Y2hpdGVjdHVyZS4gIE5vIHJlcXVpcmVtZW50cyBhcmUgcGxhY2VkIG9uIHRoaXMgcmVmZXJlbmNl IHBvaW50LiANCiAgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEp1bHkgICAg MjAwNCAgICAgICAgICAgICAgICAgICBbUGFnZSAxNV0gIA0KDQogSW50ZXJuZXQgRHJhZnQgICAg ICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDQgDQogIA0K ICANCiAgICBDRSBtYW5hZ2VycyBhbmQgRkUgbWFuYWdlcnMgbWF5IGJlIG9wZXJhdGVkIGJ5IGRp ZmZlcmVudCBlbnRpdGllcy4gIA0KICAgIFRoZSBvcGVyYXRvciBvZiB0aGUgQ0UgbWFuYWdlciBt YXkgbm90IHdhbnQgdG8gZGl2dWxnZSwgZXhjZXB0IHRvIA0KICAgIHNwZWNpZmllZCBGRSBtYW5h Z2VycywgYW55IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgQ0VzIGl0IG1hbmFnZXMuICAgDQogICAg U2ltaWxhcmx5LCB0aGUgb3BlcmF0b3Igb2YgdGhlIEZFIG1hbmFnZXIgbWF5IG5vdCB3YW50IHRv IGRpdnVsZ2UgDQogICAgRkUgY2hhcmFjdGVyaXN0aWNzLCBleGNlcHQgdG8gYXV0aG9yaXplZCBl bnRpdGllcy4gIEFzIHN1Y2gsIENFIA0KICAgIG1hbmFnZXJzIGFuZCBGRSBtYW5hZ2VycyBtYXkg bmVlZCB0byBhdXRoZW50aWNhdGUgb25lIGFub3RoZXIuICAgDQogICAgU3Vic2VxdWVudCBjb21t dW5pY2F0aW9uIGJldHdlZW4gQ0UgbWFuYWdlcnMgYW5kIEZFIG1hbmFnZXJzIG1heSANCiAgICBy ZXF1aXJlIG90aGVyIHNlY3VyaXR5IGZ1bmN0aW9ucyBzdWNoIGFzIHByaXZhY3ksIG5vbi1yZXB1 ZGlhdGlvbiwgDQogICAgZnJlc2huZXNzLCBhbmQgaW50ZWdyaXR5LiANCiAgICAgDQogICAgICAg ICBGRSBNYW5hZ2VyICAgICAgRkUgICAgICAgICAgICAgICBDRSBNYW5hZ2VyICAgICBDRSANCiAg ICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwg DQogICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8IA0KICAgICAgICAgIHwoc2VjdXJpdHkgZXhjaGFuZ2UpICAgICAgICAgICAgIHwgICAgICAg ICAgICAgfCANCiAgICAgICAgIDF8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAg ICAgICAgICAgIHwgDQogICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICB8IA0KICAgICAgICAgIHwoYSBsaXN0IG9mIENFcyBhbmQgdGhlaXIgYXR0 cmlidXRlcykgICAgICAgICAgfCANCiAgICAgICAgIDJ8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS18ICAgICAgICAgICAgIHwgDQogICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgICAgICAgIHwoYSBsaXN0IG9mIEZFcyBh bmQgdGhlaXIgYXR0cmlidXRlcykgICAgICAgICAgfCANCiAgICAgICAgIDN8LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgIHwgDQogICAgICAgICAgfCAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgICAgICAgIHwgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCANCiAgICAgICAgICB8 PC0tLS0tLS0tLS0tLS0tLS1GbC0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgIHwgDQogICAgIA0K ICAgICAgRmlndXJlIDcuIEFuIGV4YW1wbGUgb2YgbWVzc2FnZSBleGNoYW5nZSBvdmVyIEZsIHJl ZmVyZW5jZSBwb2ludCANCiAgICAgDQogICAgT25jZSB0aGUgbmVjZXNzYXJ5IHNlY3VyaXR5IGZ1 bmN0aW9ucyBoYXZlIGJlZW4gcGVyZm9ybWVkLCB0aGUgQ0UgDQogICAgYW5kIEZFIG1hbmFnZXJz IGNvbW11bmljYXRlIHRvIGRldGVybWluZSB3aGljaCBDRXMgYW5kIEZFcyBzaG91bGQgDQogICAg Y29tbXVuaWNhdGUgd2l0aCBlYWNoIG90aGVyLiAgQXQgdGhlIHZlcnkgbWluaW11bSwgdGhlIENF IGFuZCBGRSANCiAgICBtYW5hZ2VycyBuZWVkIHRvIGxlYXJuIG9mIHRoZSBleGlzdGVuY2Ugb2Yg YXZhaWxhYmxlIEZFcyBhbmQgQ0VzIA0KICAgIHJlc3BlY3RpdmVseS4gIFRoaXMgZGlzY292ZXJ5 IHByb2Nlc3MgbWF5IGVudGFpbCBvbmUgb3IgYm90aCANCiAgICBtYW5hZ2VycyBsZWFybmluZyB0 aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBkaXNjb3ZlcmVkIEZvckNFUyANCiAgICBwcm90b2NvbCBl bGVtZW50cy4gIEZpZ3VyZSA3IHNob3dzIGFuIGV4YW1wbGUgb2YgcG9zc2libGUgbWVzc2FnZSAN CiAgICBleGNoYW5nZSBiZXR3ZWVuIENFIG1hbmFnZXIgYW5kIEZFIG1hbmFnZXIgb3ZlciBGbCBy ZWZlcmVuY2UgcG9pbnQuIA0KICAgICANCiA0LjEuMi4gRmYgUmVmZXJlbmNlIFBvaW50IA0KICAg ICANCiAgICBUaGUgRmYgcmVmZXJlbmNlIHBvaW50IGlzIHVzZWQgdG8gaW5mb3JtIGZvcndhcmRp bmcgZWxlbWVudHMgb2YgdGhlIA0KICAgIGFzc29jaWF0aW9uIGRlY2lzaW9ucyBtYWRlIGJ5IHRo ZSBGRSBtYW5hZ2VyIGluIHByZS1hc3NvY2lhdGlvbiANCiAgICBwaGFzZS4gIE9ubHkgYXV0aG9y aXplZCBlbnRpdGllcyBtYXkgaW5zdHJ1Y3QgYW4gRkUgd2l0aCByZXNwZWN0IHRvIA0KICAgIHdo aWNoIENFIHNob3VsZCBjb250cm9sIGl0LiAgVGhlcmVmb3JlLCBwcml2YWN5LCBpbnRlZ3JpdHks IA0KICAgIGZyZXNobmVzcywgYW5kIGF1dGhlbnRpY2F0aW9uIGFyZSBuZWNlc3NhcnkgYmV0d2Vl biB0aGUgRkUgbWFuYWdlciANCiAgICBhbmQgRkVzIHdoZW4gdGhlIEZFIG1hbmFnZXIgaXMgcmVt b3RlIHRvIHRoZSBGRS4gIE9uY2UgdGhlIA0KICAgIGFwcHJvcHJpYXRlIHNlY3VyaXR5IGhhcyBi ZWVuIGVzdGFibGlzaGVkLCB0aGUgRkUgbWFuYWdlciBpbnN0cnVjdHMgDQogICAgdGhlIEZFcyBh Y3Jvc3MgdGhpcyByZWZlcmVuY2UgcG9pbnQgdG8gam9pbiBhIG5ldyBORSBvciB0byANCiAgDQog IA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgSnVseSAgICAyMDA0ICAgICAgICAgICAgICAg ICAgIFtQYWdlIDE2XSAgDQoNCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGcmFtZXdv cmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNCANCiAgDQogIA0KICAgIGRpc2Nvbm5lY3Qg ZnJvbSBhbiBleGlzdGluZyBORS4gVGhlIEZFIE1hbmFnZXIgY291bGQgYWxzbyBhc3NpZ24gDQog ICAgdW5pcXVlIEZFIGlkZW50aWZpZXJzIHRvIHRoZSBGRXMgdXNpbmcgdGhpcyByZWZlcmVuY2Ug cG9pbnQuICBUaGUgDQogICAgRkUgaWRlbnRpZmllcnMgYXJlIHVzZWZ1bCBpbiBwb3N0IGFzc29j aWF0aW9uIHBoYXNlIHRvIGV4cHJlc3MgRkUgDQogICAgdG9wb2xvZ3kuICBGaWd1cmUgOCBzaG93 cyBleGFtcGxlIG9mIG1lc3NhZ2UgZXhjaGFuZ2Ugb3ZlciBGZiANCiAgICByZWZlcmVuY2UgcG9p bnQuIA0KICANCiAgICAgICAgIEZFIE1hbmFnZXIgICAgICBGRSAgICAgICAgICAgICAgIENFIE1h bmFnZXIgICAgIENFIA0KICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICB8IA0KICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICB8IA0KICAgICAgICAgIHwoc2VjdXJpdHkgZXhjaGFuZ2UpICAgICAg ICAgICAgfChzZWN1cml0eSBleGNoYW5nZSkgDQogICAgICAgICAxfDwtLS0tLS0tLS0tLS0+fGF1 dGhlbnRpY2F0aW9uIDF8PC0tLS0tLS0tLS0tPnxhdXRoZW50aWNhdGlvbg0KICAgICAgICAgIHwg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgICAgICAg IHwoRkUgSUQsIGF0dHJpYnV0ZXMpICAgICAgICAgICAgfChDRSBJRCwgYXR0cmlidXRlcykgDQog ICAgICAgICAyfDwtLS0tLS0tLS0tLS0tfHJlcXVlc3QgICAgICAgIDJ8PC0tLS0tLS0tLS0tPnxy ZXF1ZXN0IA0KICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8IA0KICAgICAgICAgM3wtLS0tLS0tLS0tLS0tPnxyZXNwb25zZSAgICAgICAzfC0t LS0tLS0tLS0tLT58cmVzcG9uc2UgDQogICAgICAgICAgfChjb3JyZXNwb25kaW5nIENFIElEKSAg ICAgICAgICB8KGNvcnJlc3BvbmRpbmcgRkUgSUQpIA0KICAgICAgICAgIHwgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgICAgICAgIHwgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgICAgICAgIHw8LS0tLS1G Zi0tLS0tPnwgICAgICAgICAgICAgICAgfDwtLS0tLUZjLS0tLT58IA0KICAgICANCiAgICAgICAg ICAgICAgICAgICAgIEZpZ3VyZSA4LiBFeGFtcGxlcyBvZiBtZXNzYWdlIGV4Y2hhbmdlIA0KICAg ICAgICAgICAgICAgICAgICAgICAgb3ZlciBGZiBhbmQgRmMgcmVmZXJlbmNlIHBvaW50cy4gDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgIE5vdGUgdGhhdCB0 aGUgRkUgbWFuYWdlciBmdW5jdGlvbiBtYXkgYmUgY28tbG9jYXRlZCB3aXRoIHRoZSBGRSANCiAg ICAoc3VjaCBhcyBieSBtYW51YWwga2V5cGFkIGVudHJ5IG9mIHRoZSBDRSBJUCBhZGRyZXNzKSwg aW4gd2hpY2ggDQogICAgY2FzZSB0aGlzIHJlZmVyZW5jZSBwb2ludCBpcyByZWR1Y2VkIHRvIGEg YnVpbHQtaW4gZnVuY3Rpb24uIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgDQogNC4xLjMuIEZjIFJlZmVyZW5jZSBQb2ludCANCiAgICAgDQogICAgVGhl IEZjIHJlZmVyZW5jZSBwb2ludCBpcyB1c2VkIHRvIGluZm9ybSBjb250cm9sIGVsZW1lbnRzIG9m IHRoZSANCiAgICBhc3NvY2lhdGlvbiBkZWNpc2lvbnMgbWFkZSBieSBDRSBtYW5hZ2VycyBpbiBw cmUtYXNzb2NpYXRpb24gcGhhc2UuIA0KICAgIFdoZW4gdGhlIENFIG1hbmFnZXIgaXMgcmVtb3Rl LCBvbmx5IGF1dGhvcml6ZWQgZW50aXRpZXMgbWF5IA0KICAgIGluc3RydWN0IGEgQ0UgdG8gY29u dHJvbCBjZXJ0YWluIEZFcy4gIFByaXZhY3ksIGludGVncml0eSwgDQogICAgZnJlc2huZXNzIGFu ZCBhdXRoZW50aWNhdGlvbiBhcmUgYWxzbyByZXF1aXJlZCBhY3Jvc3MgdGhpcyANCiAgICByZWZl cmVuY2UgcG9pbnQgaW4gc3VjaCBhIGNvbmZpZ3VyYXRpb24uICBPbmNlIGFwcHJvcHJpYXRlIHNl Y3VyaXR5IA0KICAgIGhhcyBiZWVuIGVzdGFibGlzaGVkLCB0aGUgQ0UgbWFuYWdlciBpbnN0cnVj dHMgQ0VzIGFzIHRvIHdoaWNoIEZFcyANCiAgICB0aGV5IHNob3VsZCBjb250cm9sIGFuZCBob3cg dGhleSBzaG91bGQgY29udHJvbCB0aGVtLiAgRmlndXJlIDggDQogICAgc2hvd3MgZXhhbXBsZSBv ZiBtZXNzYWdlIGV4Y2hhbmdlIG92ZXIgRmMgcmVmZXJlbmNlIHBvaW50LiANCiAgDQogICAgQXMg d2l0aCB0aGUgRkUgbWFuYWdlciBhbmQgRkVzLCBjb25maWd1cmF0aW9ucyBhcmUgcG9zc2libGUg d2hlcmUgDQogICAgdGhlIENFIG1hbmFnZXIgYW5kIENFIGFyZSBjby1sb2NhdGVkIGFuZCBubyBw cm90b2NvbCBpcyB1c2VkIGZvciANCiAgICB0aGlzIGZ1bmN0aW9uLiANCiAgICAgDQogNC4yLiBQ b3N0LWFzc29jaWF0aW9uIFBoYXNlIGFuZCBGcCByZWZlcmVuY2UgcG9pbnQgDQogICAgIA0KICAN CiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMTddICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1l d29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgUG9zdC1hc3Nv Y2lhdGlvbiBwaGFzZSBpcyB0aGUgcGVyaW9kIG9mIHRpbWUgZHVyaW5nIHdoaWNoIGFuIEZFIGFu ZCANCiAgICBDRSBoYXZlIGJlZW4gY29uZmlndXJlZCB3aXRoIGluZm9ybWF0aW9uIG5lY2Vzc2Fy eSB0byBjb250YWN0IGVhY2ggDQogICAgb3RoZXIgYW5kIGluY2x1ZGVzIGJvdGggYXNzb2NpYXRp b24gZXN0YWJsaXNobWVudCBhbmQgc3RlYWR5LXN0YXRlIA0KICAgIGNvbW11bmljYXRpb24uICBU aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIENFIGFuZCBGRSBpcyBwZXJmb3JtZWQgDQogICAgYWNy b3NzIHRoZSBGcCAoInAiIG1lYW5pbmcgcHJvdG9jb2wpIHJlZmVyZW5jZSBwb2ludC4gRm9yQ0VT IA0KICAgIFByb3RvY29sIGlzIGV4Y2x1c2l2ZWx5IHVzZWQgZm9yIGFsbCBjb21tdW5pY2F0aW9u IGFjcm9zcyB0aGUgRnAgDQogICAgcmVmZXJlbmNlIHBvaW50LiAgDQogICAgIA0KIDQuMi4xLiBQ cm94aW1pdHkgYW5kIEludGVyY29ubmVjdCBiZXR3ZWVuIENFcyBhbmQgRkVzIA0KICAgICANCiAg ICBUaGUgRm9yQ0VTIFdvcmtpbmcgR3JvdXAgaGFzIG1hZGUgYSBjb25zY2lvdXMgZGVjaXNpb24g dGhhdCB0aGUgDQogICAgZmlyc3QgdmVyc2lvbiBvZiBGb3JDRVMgd2lsbCBiZSBmb2N1c2VkIG9u ICJ2ZXJ5IGNsb3NlIiBDRS9GRSANCiAgICBsb2NhbGl0aWVzIGluIElQIG5ldHdvcmtzLiAgVmVy eSBDbG9zZSBsb2NhbGl0aWVzIGNvbnNpc3Qgb2YgDQogICAgY29udHJvbCBhbmQgZm9yd2FyZGlu ZyBlbGVtZW50cyB0aGF0IGVpdGhlciBhcmUgY29tcG9uZW50cyBpbiB0aGUgDQogICAgc2FtZSBw aHlzaWNhbCBib3gsIG9yIGFyZSBzZXBhcmF0ZWQgYXQgbW9zdCBieSBvbmUgbG9jYWwgbmV0d29y ayANCiAgICBob3AgKFs3XSkuICBDRXMgYW5kIEZFcyBjYW4gYmUgY29ubmVjdGVkIGJ5IGEgdmFy aWV0eSBvZiANCiAgICBpbnRlcmNvbm5lY3QgdGVjaG5vbG9naWVzLCBpbmNsdWRpbmcgRXRoZXJu ZXQgY29ubmVjdGlvbnMsIA0KICAgIGJhY2twbGFuZXMsIEFUTSAoY2VsbCkgZmFicmljcywgZXRj LiAgRm9yQ0VTIHNob3VsZCBiZSBhYmxlIHRvIA0KICAgIHN1cHBvcnQgZWFjaCBvZiB0aGVzZSBp bnRlcmNvbm5lY3RzIChzZWUgWzNdIFNlY3Rpb24gNSwgcmVxdWlyZW1lbnQgDQogICAgIzEpLiAg V2hlbiB0aGUgQ0VzIGFuZCBGRXMgYXJlIHNlcGFyYXRlZCBiZXlvbmQgYSBzaW5nbGUgTDMgcm91 dGluZyANCiAgICBob3AsIHRoZSBGb3JDRVMgUHJvdG9jb2wgd2lsbCBtYWtlIHVzZSBvZiBhbiBl eGlzdGluZyBSRkMyOTE0IA0KICAgIGNvbXBsaWFudCBMNCBwcm90b2NvbCB3aXRoIGFkZXF1YXRl IHJlbGlhYmlsaXR5LCBzZWN1cml0eSBhbmQgDQogICAgY29uZ2VzdGlvbiBjb250cm9sIChlLmcu IFRDUCwgU0NUUCkgZm9yIHRyYW5zcG9ydCBwdXJwb3Nlcy4gDQogICAgIA0KIDQuMi4yLiBBc3Nv Y2lhdGlvbiBFc3RhYmxpc2htZW50IA0KICAgICANCiAgICAgDQogICAgICAgICAgICAgICAgIEZF ICAgICAgICAgICAgICAgICAgICAgIENFIA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8KFNlY3VyaXR5IGV4Y2hhbmdlLikgICB8 IA0KICAgICAgICAgICAgICAgIDF8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLT58IA0KICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8KExl dCBtZSBqb2luIHRoZSBORSBwbGVhc2UuKSAgICANCiAgICAgICAgICAgICAgICAyfC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0+fCANCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgfCANCiAgICAgICAgICAgICAgICAgfChXaGF0IGtpbmQgb2YgRkUgYXJlIHlvdT8gLS0gY2Fw YWJpbGl0eSBxdWVyeSkgDQogICAgICAgICAgICAgICAgM3w8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LXwgDQogICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAg ICAgICAgICAgIHwoSGVyZSBpcyBteSBGRSBmdW5jdGlvbnMvc3RhdGU6IHVzZSBtb2RlbCB0byAN CiAgICBkZXNjcmliZSkgDQogICAgICAgICAgICAgICAgNHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t PnwgDQogICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAg ICAgICAgICAgIHwoSW5pdGlhbCBjb25maWcgZm9yIEZFIC0tIG9wdGlvbmFsKSANCiAgICAgICAg ICAgICAgICA1fDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCANCiAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgfChJIGFtIHJlYWR5IHRv IGdvLiBTaGFsbCBJPykgICAgIA0KICAgICAgICAgICAgICAgIDZ8LS0tLS0tLS0tLS0tLS0tLS0t LS0tLT58IA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMThdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAg Rm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQog ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAg ICAgIHwoR28gYWhlYWQhKSAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgN3w8LS0tLS0t LS0tLS0tLS0tLS0tLS0tLXwgDQogICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgIHwgDQogICAgICAgICAgICAgICAgICANCiAgICAgICAgICBGaWd1cmUgOS4gRXhhbXBsZSBv ZiBtZXNzYWdlIGV4Y2hhbmdlIGJldHdlZW4gQ0UgYW5kIEZFIA0KICAgICAgICAgICAgICAgICAg ICBvdmVyIEZwIHRvIGVzdGFibGlzaCBORSBhc3NvY2lhdGlvbiANCiAgICAgDQogICAgQXMgYW4g ZXhhbXBsZSwgZmlndXJlIDkgc2hvd3Mgc29tZSBvZiB0aGUgbWVzc2FnZSBleGNoYW5nZSB0aGF0 IG1heSANCiAgICBoYXBwZW4gYmVmb3JlIHRoZSBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBDRSBh bmQgRkUgaXMgZnVsbHkgDQogICAgZXN0YWJsaXNoZWQuICBFaXRoZXIgdGhlIENFIG9yIEZFIGNh biBpbml0aWF0ZSB0aGUgY29ubmVjdGlvbi4gIA0KICAgICANCiAgICBTZWN1cml0eSBoYW5kc2hh a2UgaXMgbmVjZXNzYXJ5IHRvIGF1dGhlbnRpY2F0ZSB0aGUgdHdvIA0KICAgIGNvbW11bmljYXRp b24gZW5kcG9pbnRzIHRvIGVhY2ggb3RoZXIgYmVmb3JlIGFueSBmdXJ0aGVyIG1lc3NhZ2UgDQog ICAgZXhjaGFuZ2UgY2FuIGhhcHBlbi4gIFRoZSBzZWN1cml0eSBoYW5kc2hha2Ugc2hvdWxkIGlu Y2x1ZGUgbXV0dWFsIA0KICAgIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGJldHdl ZW4gdGhlIENFIGFuZCBGRSwgYnV0IHRoZSANCiAgICBleGFjdCBkZXRhaWxzIGRlcGVuZCBvbiB0 aGUgc2VjdXJpdHkgc29sdXRpb24gY2hvc2VuIGJ5IEZvckNFUyANCiAgICBQcm90b2NvbC4gIEF1 dGhvcml6YXRpb24gY2FuIGJlIGFzIHNpbXBsZSBhcyBjaGVja2luZyBhZ2FpbnN0IHRoZSANCiAg ICBsaXN0IG9mIGF1dGhvcml6ZWQgZW5kIHBvaW50cyBwcm92aWRlZCBieSB0aGUgRkUgb3IgQ0Ug bWFuYWdlciANCiAgICBkdXJpbmcgdGhlIHByZS1hc3NvY2lhdGlvbiBwaGFzZS4gIEJvdGggYXV0 aGVudGljYXRpb24gYW5kIA0KICAgIGF1dGhvcml6YXRpb24gbXVzdCBiZSBzdWNjZXNzZnVsIGJl Zm9yZSB0aGUgYXNzb2NpYXRpb24gY2FuIGJlIA0KICAgIGVzdGFibGlzaGVkLiAgSWYgZWl0aGVy IGF1dGhlbnRpY2F0aW9uIG9yIGF1dGhvcml6YXRpb24gZmFpbHMsIHRoZSANCiAgICBlbmQgcG9p bnQgbXVzdCBub3QgYmUgYWxsb3dlZCB0byBqb2luIHRoZSBORS4gIEFmdGVyIHRoZSBzdWNjZXNz ZnVsIA0KICAgIHNlY3VyaXR5IGhhbmRzaGFrZSwgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBhbmQg Y29uZmlkZW50aWFsaXR5IGFyZSANCiAgICBzdGlsbCBuZWNlc3NhcnkgZm9yIHRoZSBvbi1nb2lu ZyBpbmZvcm1hdGlvbiBleGNoYW5nZSBiZXR3ZWVuIHRoZSANCiAgICBDRSBhbmQgRkUsIHVubGVz cyBzb21lIGZvcm0gb2YgcGh5c2ljYWwgc2VjdXJpdHkgZXhpc3RzLiAgV2hlbmV2ZXIgDQogICAg YSBwYWNrZXQgZmFpbHMgYXV0aGVudGljYXRpb24sIGl0IG11c3QgYmUgZHJvcHBlZCBhbmQgYSAN CiAgICBub3RpZmljYXRpb24gbWF5IGJlIHNlbnQgdG8gYWxlcnQgdGhlIHNlbmRlciBvZiB0aGUg cG90ZW50aWFsIA0KICAgIGF0dGFjay4gIFNlY3Rpb24gOCBwcm92aWRlcyBtb3JlIGRldGFpbHMg b24gdGhlIHNlY3VyaXR5IA0KICAgIGNvbnNpZGVyYXRpb25zIGZvciBGb3JDRVMuICAgDQogICAg IA0KICAgIEFmdGVyIHRoZSBzdWNjZXNzZnVsIHNlY3VyaXR5IGhhbmRzaGFrZSwgdGhlIEZFIG5l ZWRzIHRvIGluZm9ybSB0aGUgDQogICAgQ0Ugb2YgaXRzIG93biBjYXBhYmlsaXR5IGFuZCBvcHRp b25hbGx5IGl0cyB0b3BvbG9neSBpbiByZWxhdGlvbiB0byANCiAgICBvdGhlciBGRXMuIFRoZSBj YXBhYmlsaXR5IG9mIHRoZSBGRSBpcyByZXByZXNlbnRlZCBieSB0aGUgRkUgbW9kZWwsIA0KICAg IGRlc2NyaWJlZCBpbiBhIHNlcGFyYXRlIGRvY3VtZW50LiAgVGhlIG1vZGVsIHdvdWxkIGFsbG93 IGFuIEZFIHRvIA0KICAgIGRlc2NyaWJlIHdoYXQga2luZCBvZiBwYWNrZXQgcHJvY2Vzc2luZyBm dW5jdGlvbnMgaXQgY29udGFpbnMsIGluIA0KICAgIHdoYXQgb3JkZXIgdGhlIHByb2Nlc3Npbmcg aGFwcGVucywgd2hhdCBraW5kcyBvZiBjb25maWd1cmFibGUgDQogICAgcGFyYW1ldGVycyBpdCBh bGxvd3MsIHdoYXQgc3RhdGlzdGljcyBpdCBjb2xsZWN0cyBhbmQgd2hhdCBldmVudHMgDQogICAg aXQgbWlnaHQgdGhyb3csIGV0Yy4gIE9uY2Ugc3VjaCBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUg dG8gdGhlIENFLCANCiAgICB0aGUgQ0UgbWF5IGNob29zZSB0byBzZW5kIHNvbWUgaW5pdGlhbCBv ciBkZWZhdWx0IGNvbmZpZ3VyYXRpb24gdG8gDQogICAgdGhlIEZFIHNvIHRoYXQgdGhlIEZFIGNh biBzdGFydCByZWNlaXZpbmcgYW5kIHByb2Nlc3NpbmcgcGFja2V0cyANCiAgICBjb3JyZWN0bHku ICBTdWNoIGluaXRpYWxpemF0aW9uIG1heSBub3QgYmUgbmVjZXNzYXJ5IGlmIHRoZSBGRSANCiAg ICBhbHJlYWR5IG9idGFpbnMgdGhlIGluZm9ybWF0aW9uIGZyb20gaXRzIG93biBib290c3RyYXAg cHJvY2Vzcy4gIA0KICAgIE9uY2UgdGhlIG5lY2Vzc2FyeSBpbml0aWFsIGluZm9ybWF0aW9uIGlz IGV4Y2hhbmdlZCwgdGhlIHByb2Nlc3Mgb2YgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBF eHBpcmVzIEp1bHkgICAgMjAwNCAgICAgICAgICAgICAgICAgICBbUGFnZSAxOV0gIA0KDQogSW50 ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51 YXJ5IDIwMDQgDQogIA0KICANCiAgICBhc3NvY2lhdGlvbiBpcyBjb21wbGV0ZWQuICBQYWNrZXQg cHJvY2Vzc2luZyBhbmQgZm9yd2FyZGluZyBhdCB0aGUgDQogICAgRkUgY2Fubm90IGJlZ2luIHVu dGlsIGFzc29jaWF0aW9uIGlzIGVzdGFibGlzaGVkLiAgQWZ0ZXIgdGhlIA0KICAgIGFzc29jaWF0 aW9uIGlzIGVzdGFibGlzaGVkLCB0aGUgQ0UgYW5kIEZFIGVudGVyIHN0ZWFkeS1zdGF0ZSANCiAg ICBjb21tdW5pY2F0aW9uLiANCiAgICAgDQogICAgIA0KIDQuMi4zLiBTdGVhZHktc3RhdGUgQ29t bXVuaWNhdGlvbiANCiAgDQogICAgT25jZSBhbiBhc3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hlZCBi ZXR3ZWVuIHRoZSBDRSBhbmQgRkUsIHRoZSANCiAgICBGb3JDRVMgUHJvdG9jb2wgaXMgdXNlZCBi eSB0aGUgQ0UgYW5kIEZFIG92ZXIgRnAgcmVmZXJlbmNlIHBvaW50IHRvIA0KICAgIGV4Y2hhbmdl IGluZm9ybWF0aW9uIHRvIGZhY2lsaXRhdGUgcGFja2V0IHByb2Nlc3NpbmcuICANCiAgICAgDQog ICAgICAgICAgICAgICAgIEZFICAgICAgICAgICAgICAgICAgICAgIENFIA0KICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8KEFkZCB0 aGVzZSBuZXcgcm91dGVzLil8IA0KICAgICAgICAgICAgICAgIDF8PC0tLS0tLS0tLS0tLS0tLS0t LS0tLS18IA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAg ICAgICAgICAgICAgICB8KFN1Y2Nlc3NmdWwuKSAgICAgICAgICB8IA0KICAgICAgICAgICAgICAg IDJ8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58IA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgICAgICAgICB8KFF1ZXJ5IHNvbWUgc3RhdHMuKSAgICB8IA0KICAgICAg ICAgICAgICAgIDF8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18IA0KICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8KFJlcGx5IHdpdGgg c3RhdHMgY29sbGVjdGVkLikgICAgICAgICAgIA0KICAgICAgICAgICAgICAgIDJ8LS0tLS0tLS0t LS0tLS0tLS0tLS0tLT58IA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAg ICAgICAgICAgICB8KE15IHBvcnQgaXMgZG93biwgd2l0aCBwb3J0ICMuKSAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgIDF8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58IA0KICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAg ICB8KEhlcmUgaXMgYSBuZXcgZm9yd2FyZGluZyB0YWJsZSkgICAgICAgICAgICAgICAgDQogICAg ICAgICAgICAgICAgMnw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgICAgIA0KICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgRmlndXJlIDEwLiBFeGFt cGxlcyBvZiBtZXNzYWdlIGV4Y2hhbmdlIGJldHdlZW4gQ0UgYW5kIEZFIA0KICAgICAgICAgICAg ICAgICBvdmVyIEZwIGR1cmluZyBzdGVhZHktc3RhdGUgY29tbXVuaWNhdGlvbiANCiAgICAgDQog ICAgQmFzZWQgb24gdGhlIGluZm9ybWF0aW9uIGFjcXVpcmVkIHRocm91Z2ggQ0VzJyBjb250cm9s IHByb2Nlc3NpbmcsIA0KICAgIENFcyB3aWxsIGZyZXF1ZW50bHkgbmVlZCB0byBtYW5pcHVsYXRl IHRoZSBwYWNrZXQtZm9yd2FyZGluZyANCiAgICBiZWhhdmlvcnMgb2YgdGhlaXIgRkUocykgYnkg c2VuZGluZyBpbnN0cnVjdGlvbnMgdG8gRkVzLiAgRm9yIA0KICAgIGV4YW1wbGUsIEZpZ3VyZSAx MCBzaG93cyBtZXNzYWdlIGV4Y2hhbmdlIGV4YW1wbGVzIGluIHdoaWNoIHRoZSBDRSANCiAgICBz ZW5kcyBuZXcgcm91dGVzIHRvIHRoZSBGRSBzbyB0aGF0IHRoZSBGRSBjYW4gYWRkIHRoZW0gdG8g aXRzIA0KICAgIGZvcndhcmRpbmcgdGFibGUuICBUaGUgQ0UgbWF5IHF1ZXJ5IHRoZSBGRSBmb3Ig c3RhdGlzdGljcyBjb2xsZWN0ZWQgDQogICAgYnkgdGhlIEZFIGFuZCB0aGUgRkUgbWF5IG5vdGlm eSB0aGUgQ0Ugb2YgaW1wb3J0YW50IGV2ZW50cyBzdWNoIGFzIA0KICAgIHBvcnQgZmFpbHVyZS4g DQogICAgIA0KIDQuMi40LiBEYXRhIFBhY2tldHMgYWNyb3NzIEZwIHJlZmVyZW5jZSBwb2ludCAN CiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgSnVseSAgICAyMDA0ICAgICAgICAg ICAgICAgICAgIFtQYWdlIDIwXSAgDQoNCiBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBG cmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNCANCiAgDQogIA0KICAgICANCiAg ICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSANCiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgfCANCiAgICAgICAgIHwgICAgKy0tLS0tLS0tKyAgICAgfCAgICAgICAgICAg fCAgICAgKy0tLS0tLS0tKyAgICAgfCANCiAgICAgICAgIHwgICAgfENFKEJHUCkgfCAgICAgfCAg ICAgICAgICAgfCAgICAgfENFKEJHUCkgfCAgICAgfCANCiAgICAgICAgIHwgICAgKy0tLS0tLS0t KyAgICAgfCAgICAgICAgICAgfCAgICAgKy0tLS0tLS0tKyAgICAgfCANCiAgICAgICAgIHwgICAg ICAgIHwgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICBeICAgICAgICAgfCANCiAgICAg ICAgIHwgICAgICAgIHxGcCAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8RnAgICAgICAg fCANCiAgICAgICAgIHwgICAgICAgIHYgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgfCANCiAgICAgICAgIHwgICAgKy0tLS0tLS0tKyAgICAgfCAgICAgICAgICAgfCAg ICAgKy0tLS0tLS0tKyAgICAgfCANCiAgICAgICAgIHwgICAgfCAgRkUgICAgfCAgICAgfCAgICAg ICAgICAgfCAgICAgfCAgIEZFICAgfCAgICAgfCANCiAgICAgICAgIHwgICAgKy0tLS0tLS0tKyAg ICAgfCAgICAgICAgICAgfCAgICAgKy0tLS0tLS0tKyAgICAgfCANCiAgICAgICAgIHwgICAgICAg IHwgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICBeICAgICAgICAgfCANCiAgICAgICAg IHwgUm91dGVyIHwgICAgICAgICAgfCAgICAgICAgICAgfCBSb3V0ZXIgICB8ICAgICAgICAgfCAN CiAgICAgICAgIHwgQSAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgfCBCICAgICAgICB8ICAg ICAgICAgfCANCiAgICAgICAgIC0tLS0tLS0tLSstLS0tLS0tLS0tLSAgICAgICAgICAgLS0tLS0t LS0tLS0rLS0tLS0tLS0tLSANCiAgICAgICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBeIA0KICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0+LS0t LS0tLS0tLS0tLS0tICAgICANCiAgICAgDQogICAgICAgIEZpZ3VyZSAxMS4gRXhhbXBsZSB0byBz aG93IGRhdGEgcGFja2V0IGZsb3cgYmV0d2VlbiB0d28gTkVzLiANCiAgICAgDQogICAgQ29udHJv bCBwbGFuZSBwcm90b2NvbCBwYWNrZXRzIChzdWNoIGFzIFJJUCwgT1NQRiBtZXNzYWdlcykgDQog ICAgYWRkcmVzc2VkIHRvIGFueSBvZiBORSdzIGludGVyZmFjZXMgYXJlIHR5cGljYWxseSByZWRp cmVjdGVkIGJ5IHRoZSANCiAgICByZWNlaXZpbmcgRkUgdG8gaXRzIENFLCBhbmQgQ0UgbWF5IG9y aWdpbmF0ZSBwYWNrZXRzIGFuZCBoYXZlIGl0cyANCiAgICBGRSBkZWxpdmVyIHRoZW0gdG8gb3Ro ZXIgTkVzLiAgVGhlcmVmb3JlLCBGb3JDRVMgUHJvdG9jb2wgb3ZlciBGcCANCiAgICBub3Qgb25s eSB0cmFuc3BvcnRzIHRoZSBGb3JDRVMgUHJvdG9jb2wgbWVzc2FnZXMgYmV0d2VlbiBDRXMgYW5k IA0KICAgIEZFcywgYnV0IGFsc28gZW5jYXBzdWxhdGVzIHRoZSBkYXRhIHBhY2tldHMgZnJvbSBj b250cm9sIHBsYW5lIA0KICAgIHByb3RvY29scy4gIE1vcmVvdmVyLCBvbmUgRkUgbWF5IGJlIGNv bnRyb2xsZWQgYnkgbXVsdGlwbGUgQ0VzIGZvciANCiAgICBkaXN0cmlidXRlZCBjb250cm9sLiAg SW4gdGhpcyBjb25maWd1cmF0aW9uLCB0aGUgY29udHJvbCBwcm90b2NvbHMgDQogICAgc3VwcG9y dGVkIGJ5IHRoZSBGT1JDRVMgTkVzIG1heSBzcHJlYWQgYWNyb3NzIG11bHRpcGxlIENFcy4gIEZv ciANCiAgICBleGFtcGxlLCBvbmUgQ0UgbWF5IHN1cHBvcnQgcm91dGluZyBwcm90b2NvbHMgbGlr ZSBPU1BGIGFuZCBCR1AsIA0KICAgIHdoaWxlIGEgc2lnbmFsaW5nIGFuZCBhZG1pc3Npb24gY29u dHJvbCBwcm90b2NvbCBsaWtlIFJTVlAgaXMgDQogICAgc3VwcG9ydGVkIGluIGFub3RoZXIgQ0Uu ICBGRXMgYXJlIGNvbmZpZ3VyZWQgdG8gcmVjb2duaXplIGFuZCANCiAgICBmaWx0ZXIgdGhlc2Ug cHJvdG9jb2wgcGFja2V0cyBhbmQgZm9yd2FyZCB0aGVtIHRvIHRoZSBjb3JyZXNwb25kaW5nIA0K ICAgIENFLiAgDQogIA0KICAgIEZpZ3VyZSAxMSBzaG93cyBvbmUgZXhhbXBsZSBvZiBob3cgdGhl IEJHUCBwYWNrZXRzIG9yaWdpbmF0ZWQgYnkgDQogICAgcm91dGVyIEEgYXJlIHBhc3NlZCB0byBy b3V0ZXIgQi4gIEluIHRoaXMgZXhhbXBsZSwgdGhlIEZvckNFUyANCiAgICBQcm90b2NvbCBpcyB1 c2VkIHRvIHRyYW5zcG9ydCB0aGUgcGFja2V0cyBmcm9tIHRoZSBDRSB0byB0aGUgRkUgDQogICAg aW5zaWRlIHJvdXRlciBBLCBhbmQgdGhlbiBmcm9tIHRoZSBGRSB0byB0aGUgQ0UgaW5zaWRlIHJv dXRlciBCLiAgDQogICAgSW4gbGlnaHQgb2YgdGhlIGZhY3QgdGhhdCB0aGUgRm9yQ0VTIFByb3Rv Y29sIGlzIHJlc3BvbnNpYmxlIGZvciANCiAgICB0cmFuc3BvcnRpbmcgYm90aCB0aGUgY29udHJv bCBtZXNzYWdlcyBhbmQgdGhlIGRhdGEgcGFja2V0cyBiZXR3ZWVuIA0KICAgIHRoZSBDRSBhbmQg RkUgb3ZlciBGcCByZWZlcmVuY2UgcG9pbnQsIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSBlaXRoZXIg DQogICAgYSBzaW5nbGUgcHJvdG9jb2wgb3IgbXVsdGlwbGUgcHJvdG9jb2xzIHRvIGFjaGlldmUg dGhpcy4gDQogICAgIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAg IDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjFdICANCg0KIEludGVybmV0IERyYWZ0ICAg ICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICAN CiAgDQogNC4yLjUuIFByb3h5IEZFIA0KICAgICANCiAgICBJbiB0aGUgY2FzZSB3aGVyZSBhIHBo eXNpY2FsIEZFIGNhbm5vdCBpbXBsZW1lbnQgKGUuZy4sIGR1ZSB0byB0aGUgDQogICAgbGFjayBv ZiBhIGdlbmVyYWwgcHVycG9zZSBDUFUpIHRoZSBGb3JDRVMgUHJvdG9jb2wgZGlyZWN0bHksIGEg DQogICAgcHJveHkgRkUgY2FuIGJlIHVzZWQgdG8gdGVybWluYXRlIHRoZSBGcCByZWZlcmVuY2Ug cG9pbnQgaW5zdGVhZCBvZiANCiAgICB0aGUgcGh5c2ljYWwgRkUuICBUaGlzIGFsbG93cyB0aGUg Q0UgY29tbXVuaWNhdGUgdG8gdGhlIHBoeXNpY2FsIEZFIA0KICAgIHZpYSB0aGUgcHJveHkgYnkg dXNpbmcgRm9yQ0VTLCB3aGlsZSB0aGUgcHJveHkgbWFuaXB1bGF0ZXMgdGhlIA0KICAgIHBoeXNp Y2FsIEZFIHVzaW5nIHNvbWUgaW50ZXJtZWRpYXJ5IGZvcm0gb2YgY29tbXVuaWNhdGlvbiAoZS5n LiwgYSANCiAgICBub24tRm9yQ0VTIHByb3RvY29sIG9yIERNQSkuICBJbiBzdWNoIGFuIGltcGxl bWVudGF0aW9uLCB0aGUgDQogICAgY29tYmluYXRpb24gb2YgdGhlIHByb3h5IGFuZCB0aGUgcGh5 c2ljYWwgRkUgYmVjb21lcyBvbmUgbG9naWNhbCBGRSANCiAgICBlbnRpdHkuICBJdCBpcyBhbHNv IHBvc3NpYmxlIHRoYXQgb25lIHByb3h5IGFjdCBvbiBiZWhhbGYgb2YgDQogICAgbXVsdGlwbGUg cGh5c2ljYWwgRkVzLiANCiAgICAgDQogICAgT25lIG5lZWRzIHRvIGJlIGF3YXJlIG9mIHRoZSBz ZWN1cml0eSBpbXBsaWNhdGlvbiBpbnRyb2R1Y2VkIGJ5IHRoZSANCiAgICBwcm94eSBGRS4gIFNp bmNlIHRoZSBwaHlzaWNhbCBGRSBpcyBub3QgY2FwYWJsZSBvZiBpbXBsZW1lbnRpbmcgDQogICAg Rm9yQ0VTIGl0c2VsZiwgdGhlIHNlY3VyaXR5IG1lY2hhbmlzbSBvZiBGb3JDRVMgY2FuIG9ubHkg c2VjdXJlIHRoZSANCiAgICBjb21tdW5pY2F0aW9uIGNoYW5uZWwgYmV0d2VlbiB0aGUgQ0UgYW5k IHRoZSBwcm94eSBGRSwgYnV0IG5vdCBhbGwgDQogICAgdGhlIHdheSB0byB0aGUgcGh5c2ljYWwg RkUuICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IG90aGVyIHNlY3VyaXR5IA0KICAgIG1lY2hhbmlz bXMgKGluY2x1ZGluZyBwaHlzaWNhbCBzZWN1cml0eSBwcm9wZXJ0eSkgYmUgZW1wbG95ZWQgdG8g DQogICAgZW5zdXJlIHRoZSBzZWN1cml0eSBiZXR3ZWVuIHRoZSBDRSBhbmQgdGhlIHBoeXNpY2Fs IEZFLiAgDQogICAgIA0KIDQuMy4gQXNzb2NpYXRpb24gUmUtZXN0YWJsaXNobWVudCANCiAgICAg DQogICAgRkVzIGFuZCBDRXMgbWF5IGpvaW4gYW5kIGxlYXZlIE5FcyBkeW5hbWljYWxseSAoc2Vl IFszXSBTZWN0aW9uIDUsIA0KICAgIHJlcXVpcmVtZW50cyAjMTIpLiAgV2hlbiBhbiBGRSBvciBD RSBsZWF2ZXMgdGhlIE5FLCB0aGUgYXNzb2NpYXRpb24gDQogICAgd2l0aCB0aGUgTkUgaXMgYnJv a2VuLiAgSWYgdGhlIGxlYXZpbmcgcGFydHkgcmVqb2lucyBhbiBORSBsYXRlciwgDQogICAgdG8g cmUtZXN0YWJsaXNoIHRoZSBhc3NvY2lhdGlvbiwgaXQgbWF5IG5lZWQgdG8gcmUtZW50ZXIgdGhl IHByZS0NCiAgICBhc3NvY2lhdGlvbiBwaGFzZS4gIExvc3Mgb2YgYXNzb2NpYXRpb24gY2FuIGFs c28gaGFwcGVuIA0KICAgIHVuZXhwZWN0ZWRseSBkdWUgdG8gbG9zcyBvZiBjb25uZWN0aW9uIGJl dHdlZW4gdGhlIENFIGFuZCB0aGUgRkUuICANCiAgICBUaGVyZWZvcmUsIHRoZSBmcmFtZXdvcmsg YWxsb3dzIHRoZSBiaS1kaXJlY3Rpb25hbCB0cmFuc2l0aW9uIA0KICAgIGJldHdlZW4gdGhlc2Ug dHdvIHBoYXNlcywgYnV0IHRoZSBGb3JDRVMgUHJvdG9jb2wgaXMgb25seSANCiAgICBhcHBsaWNh YmxlIGZvciB0aGUgcG9zdC1hc3NvY2lhdGlvbiBwaGFzZS4gIEhvd2V2ZXIsIHRoZSBwcm90b2Nv bCANCiAgICBzaG91bGQgcHJvdmlkZSBtZWNoYW5pc21zIHRvIHN1cHBvcnQgYXNzb2NpYXRpb24g cmUtZXN0YWJsaXNobWVudC4gDQogICAgVGhpcyBpbmNsdWRlcyB0aGUgYWJpbGl0eSBmb3IgQ0Vz IGFuZCBGRXMgdG8gZGV0ZXJtaW5lIHdoZW4gdGhlcmUgDQogICAgaXMgYSBsb3NzIG9mIGFzc29j aWF0aW9uIGJldHdlZW4gdGhlbSwgYWJpbGl0eSB0byByZXN0b3JlIA0KICAgIGFzc29jaWF0aW9u IGFuZCBlZmZpY2llbnQgc3RhdGUgKHJlKXN5bmNocm9uaXphdGlvbiBtZWNoYW5pc21zIChzZWUg DQogICAgWzNdIFNlY3Rpb24gNSwgcmVxdWlyZW1lbnQgIzcpLiBOb3RlIHRoYXQgc2VjdXJpdHkg YXNzb2NpYXRpb24gYW5kIA0KICAgIHN0YXRlIG11c3QgYmUgYWxzbyByZS1lc3RhYmxpc2hlZCB0 byBndWFyYW50ZWUgdGhlIHNhbWUgbGV2ZWwgb2YgDQogICAgc2VjdXJpdHkgKGluY2x1ZGluZyBi b3RoIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uKSBleGlzdHMgDQogICAgYmVmb3Jl IGFuZCBhZnRlciB0aGUgYXNzb2NpYXRpb24gcmUtZXN0YWJsaXNobWVudC4gDQogICAgIA0KICAg IFdoZW4gYW4gRkUgbGVhdmVzIG9yIGpvaW5zIGFuIGV4aXN0aW5nIE5FIHRoYXQgaXMgYWxyZWFk eSBpbiANCiAgICBvcGVyYXRpb24sIHRoZSBDRSBuZWVkcyB0byBiZSBhd2FyZSBvZiB0aGUgaW1w YWN0IG9uIEZFIHRvcG9sb2d5IA0KICAgIGFuZCBkZWFscyB3aXRoIHRoZSBjaGFuZ2UgYWNjb3Jk aW5nbHkuIA0KICAgICANCiA0LjMuMS4gQ0UgZ3JhY2VmdWwgcmVzdGFydCANCiAgDQogIA0KICAN CiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEp1bHkgICAgMjAwNCAgICAgICAgICAgICAgICAg ICBbUGFnZSAyMl0gIA0KDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3Jr ICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDQgDQogIA0KICANCiAgICBUaGUgZmFpbHVyZSBh bmQgcmVzdGFydCBvZiB0aGUgQ0UgaW4gYSByb3V0ZXIgY2FuIHBvdGVudGlhbGx5IGNhdXNlIA0K ICAgIG11Y2ggc3RyZXNzIGFuZCBkaXNydXB0aW9uIG9uIHRoZSBjb250cm9sIHBsYW5lIHRocm91 Z2hvdXQgYSANCiAgICBuZXR3b3JrLiAgQmVjYXVzZSB3aGVuIGEgQ0UgaGFzIHRvIHJlc3RhcnQg Zm9yIGFueSByZWFzb24sIHRoZSANCiAgICByb3V0ZXIgbG9zZXMgcm91dGluZyBhZGphY2VuY2ll cyBvciBzZXNzaW9ucyB3aXRoIGl0cyByb3V0aW5nIA0KICAgIG5laWdoYm9ycy4gIE5laWdoYm9y cyB3aG8gZGV0ZWN0IHRoZSBsb3N0IGFkamFjZW5jeSBub3JtYWxseSByZS0NCiAgICBjb21wdXRl IG5ldyByb3V0ZXMgYW5kIHRoZW4gc2VuZCByb3V0aW5nIHVwZGF0ZXMgdG8gdGhlaXIgb3duIA0K ICAgIG5laWdoYm9ycyB0byBjb21tdW5pY2F0ZSB0aGUgbG9zdCBhZGphY2VuY3kuICBUaGVpciBu ZWlnaGJvcnMgZG8gDQogICAgdGhlIHNhbWUgdGhpbmcgdG8gcHJvcGFnYXRlIHRocm91Z2hvdXQg dGhlIG5ldHdvcmsuICBJbiB0aGUgDQogICAgbWVhbnRpbWUsIHRoZSByZXN0YXJ0aW5nIHJvdXRl ciBjYW5ub3QgcmVjZWl2ZSB0cmFmZmljIGZyb20gb3RoZXIgDQogICAgcm91dGVycyBiZWNhdXNl IHRoZSBuZWlnaGJvcnMgaGF2ZSBzdG9wcGVkIHVzaW5nIHRoZSByb3V0ZXIncyANCiAgICBwcmV2 aW91c2x5IGFkdmVydGlzZWQgcm91dGVzLiBXaGVuIHRoZSByZXN0YXJ0aW5nIHJvdXRlciByZXN0 b3JlcyANCiAgICBhZGphY2VuY2llcywgbmVpZ2hib3JzIG11c3Qgb25jZSBhZ2FpbiByZS1jb21w dXRlIG5ldyByb3V0ZXMgYW5kIA0KICAgIHNlbmQgb3V0IGFkZGl0aW9uYWwgcm91dGluZyB1cGRh dGVzLiBUaGUgcmVzdGFydGluZyByb3V0ZXIgaXMgDQogICAgdW5hYmxlIHRvIGZvcndhcmQgcGFj a2V0cyB1bnRpbCBpdCBoYXMgcmUtZXN0YWJsaXNoZWQgcm91dGluZyANCiAgICBhZGphY2VuY2ll cyB3aXRoIG5laWdoYm9ycywgcmVjZWl2ZWQgcm91dGUgdXBkYXRlcyB0aHJvdWdoIHRoZXNlIA0K ICAgIGFkamFjZW5jaWVzLCBhbmQgY29tcHV0ZWQgbmV3IHJvdXRlcy4gIFVudGlsIGNvbnZlcmdl bmNlIHRha2VzIA0KICAgIHBsYWNlIHRocm91Z2hvdXQgdGhlIG5ldHdvcmssIHBhY2tldHMgbWF5 IGJlIGxvc3QgaW4gdHJhbnNpZW50IA0KICAgIGJsYWNrIGhvbGVzIG9yIGZvcndhcmRpbmcgbG9v cHMuICAgDQogIA0KICAgIEEgaGlnaCBhdmFpbGFiaWxpdHkgbWVjaGFuaXNtIGtub3duIGFzIHRo ZSAiZ3JhY2VmdWwgcmVzdGFydCIgaGFzIA0KICAgIGJlZW4gdXNlZCBieSB0aGUgSVAgcm91dGlu ZyBwcm90b2NvbHMgKE9TUEYgWzEwXSwgQkdQIFsxMV0pIGFuZCANCiAgICBNUExTIGxhYmVsIGRp c3RyaWJ1dGlvbiBwcm90b2NvbCAoTERQIFs5XSkgdG8gaGVscCBtaW5pbWl6ZSB0aGUgDQogICAg bmVnYXRpdmUgZWZmZWN0cyBvbiByb3V0aW5nIHRocm91Z2hvdXQgYW4gZW50aXJlIG5ldHdvcmsg Y2F1c2VkIGJ5IA0KICAgIGEgcmVzdGFydGluZyByb3V0ZXIuICBSb3V0ZSBmbGFwIG9uIG5laWdo Ym9yaW5nIHJvdXRlcnMgaXMgYXZvaWRlZCwgDQogICAgYW5kIGEgcmVzdGFydGluZyByb3V0ZXIg Y2FuIGNvbnRpbnVlIHRvIGZvcndhcmQgcGFja2V0cyB0aGF0IHdvdWxkIA0KICAgIG90aGVyd2lz ZSBiZSBkcm9wcGVkLiAgIA0KICAgICANCiAgICBXaGlsZSB0aGUgZGV0YWlscyBkaWZmZXIgZnJv bSBwcm90b2NvbCB0byBwcm90b2NvbCwgdGhlIGdlbmVyYWwgDQogICAgaWRlYSBiZWhpbmQgdGhl IGdyYWNlZnVsIHJlc3RhcnQgbWVjaGFuaXNtIHJlbWFpbnMgdGhlIHNhbWUuICBXaXRoIA0KICAg IHRoZSBncmFjZWZ1bCByZXN0YXJ0LCBhIHJlc3RhcnRpbmcgcm91dGVyIGNhbiBpbmZvcm0gaXRz IG5laWdoYm9ycyANCiAgICB3aGVuIGl0IHJlc3RhcnRzLiAgVGhlIG5laWdoYm9ycyBtYXkgZGV0 ZWN0IHRoZSBsb3N0IGFkamFjZW5jeSBidXQgDQogICAgZG8gbm90IHJlY29tcHV0ZSBuZXcgcm91 dGVzIG9yIHNlbmQgcm91dGluZyB1cGRhdGVzIHRvIHRoZWlyIA0KICAgIG5laWdoYm9ycy4gIFRo ZSBuZWlnaGJvcnMgYWxzbyBob2xkIG9uIHRvIHRoZSByb3V0ZXMgcmVjZWl2ZWQgZnJvbSANCiAg ICB0aGUgcmVzdGFydGluZyByb3V0ZXIgYmVmb3JlIHJlc3RhcnQgYW5kIGFzc3VtZSB0aGV5IGFy ZSBzdGlsbCANCiAgICB2YWxpZCBmb3IgYSBsaW1pdGVkIHRpbWUuICBCeSBkb2luZyBzbywgdGhl IHJlc3RhcnRpbmcgcm91dGVyJ3MgRkVzIA0KICAgIGNhbiBhbHNvIGNvbnRpbnVlIHRvIHJlY2Vp dmUgYW5kIGZvcndhcmQgdHJhZmZpYyBmcm9tIG90aGVyIA0KICAgIG5laWdoYm9ycyBmb3IgYSBs aW1pdGVkIHRpbWUgYnkgdXNpbmcgdGhlIHJvdXRlcyB0aGV5IGFscmVhZHkgaGF2ZS4gDQogICAg VGhlIHJlc3RhcnRpbmcgcm91dGVyIHRoZW4gcmUtZXN0YWJsaXNoZXMgcm91dGluZyBhZGphY2Vu Y2llcywgDQogICAgZG93bmxvYWRzIHVwZGF0ZWQgcm91dGVzIGZyb20gYWxsIGl0cyBuZWlnaGJv cnMsIHJlY29tcHV0ZXMgbmV3IA0KICAgIHJvdXRlcyBhbmQgdXNlcyB0aGVtIHRvIHJlcGxhY2Ug dGhlIG9sZGVyIHJvdXRlcyBpdCB3YXMgdXNpbmcuIEl0IA0KICAgIHRoZW4gc2VuZHMgdGhlc2Ug dXBkYXRlZCByb3V0ZXMgdG8gaXRzIG5laWdoYm9ycyBhbmQgc2lnbmFscyB0aGUgDQogICAgY29t cGxldGlvbiBvZiB0aGUgZ3JhY2VmdWwgcmVzdGFydCBwcm9jZXNzLiANCiAgICAgDQogICAgTm9u LXN0b3AgZm9yd2FyZGluZyBpcyBhIHJlcXVpcmVtZW50IGZvciBncmFjZWZ1bCByZXN0YXJ0LiAg SXQgaXMgDQogICAgbmVjZXNzYXJ5IHNvIGEgcm91dGVyIGNhbiBjb250aW51ZSB0byBmb3J3YXJk IHBhY2tldHMgd2hpbGUgaXQgaXMgDQogICAgZG93bmxvYWRpbmcgcm91dGluZyBpbmZvcm1hdGlv biBhbmQgcmVjb21wdXRpbmcgbmV3IHJvdXRlcy4gIFRoaXMgDQogICAgZW5zdXJlcyB0aGF0IHBh Y2tldHMgd2lsbCBub3QgYmUgZHJvcHBlZC4gIEFzIG9uZSBjYW4gc2VlLCBvbmUgb2YgDQogIA0K ICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEp1bHkgICAgMjAwNCAgICAgICAgICAgICAg ICAgICBbUGFnZSAyM10gIA0KDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3 b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDQgDQogIA0KICANCiAgICB0aGUgYmVuZWZp dHMgYWZmb3JkZWQgYnkgdGhlIHNlcGFyYXRpb24gb2YgQ0UgYW5kIEZFIGlzIGV4YWN0bHkgdGhl IA0KICAgIGFiaWxpdHkgb2Ygbm9uLXN0b3AgZm9yd2FyZGluZyBpbiB0aGUgZmFjZSBvZiB0aGUg Q0UgZmFpbHVyZSBhbmQgDQogICAgcmVzdGFydC4gIFRoZSBzdXBwb3J0IG9mIGR5bmFtaWMgY2hh bmdlcyB0byBDRS9GRSBhc3NvY2lhdGlvbiBpbiANCiAgICBGb3JDRVMgYWxzbyBtYWtlcyBpdCBj b21wYXRpYmxlIHdpdGggaGlnaCBhdmFpbGFiaWxpdHkgbWVjaGFuaXNtcyANCiAgICBzdWNoIGFz IGdyYWNlZnVsIHJlc3RhcnQuIA0KICAgICANCiAgICBGb3JDRVMgc2hvdWxkIGJlIGFibGUgdG8g c3VwcG9ydCBDRSBncmFjZWZ1bCByZXN0YXJ0IGVhc2lseS4gIFdoZW4gDQogICAgdGhlIGFzc29j aWF0aW9uIGlzIGVzdGFibGlzaGVkIHRoZSBmaXJzdCB0aW1lLCB0aGUgQ0UgbXVzdCBpbmZvcm0g DQogICAgdGhlIEZFcyB3aGF0IHRvIGRvIGluIHRoZSBjYXNlIG9mIENFIGZhaWx1cmUuICBJZiBn cmFjZWZ1bCByZXN0YXJ0IA0KICAgIGlzIG5vdCBzdXBwb3J0ZWQsIHRoZSBGRXMgbWF5IGJlIHRv bGQgdG8gc3RvcCBwYWNrZXQgcHJvY2Vzc2luZyBhbGwgDQogICAgdG9nZXRoZXIgaWYgaXRzIENF IGZhaWxzLiAgSWYgZ3JhY2VmdWwgcmVzdGFydCBpcyBzdXBwb3J0ZWQsIHRoZSANCiAgICBGRXMg c2hvdWxkIGJlIHRvbGQgdG8gY2FjaGUgYW5kIGhvbGQgb24gdG8gaXRzIEZFIHN0YXRlIGluY2x1 ZGluZyANCiAgICB0aGUgZm9yd2FyZGluZyB0YWJsZXMgYWNyb3NzIHRoZSByZXN0YXJ0cy4gIEEg dGltZXIgbXVzdCBiZSANCiAgICBpbmNsdWRlZCBzbyB0aGF0IHRoZSB0aW1lb3V0IGNhdXNlcyBz dWNoIGNhY2hlZCBzdGF0ZSB0byBleHBpcmUgDQogICAgZXZlbnR1YWxseS4gIFRob3NlIHRpbWVy cyBzaG91bGQgYmUgc2V0dGFibGUgYnkgdGhlIENFLiAgDQogIA0KIDQuMy4yLiBGRSByZXN0YXJ0 IA0KICANCiAgICBJbiB0aGUgc2FtZSBleGFtcGxlIGluIEZpZ3VyZSA1LCBhc3N1bWluZyBDRTEg aXMgdGhlIHdvcmtpbmcgQ0UgZm9yIA0KICAgIHRoZSBtb21lbnQsIHdoYXQgd291bGQgaGFwcGVu IGlmIG9uZSBvZiB0aGUgRkVzLCBzYXkgRkUxLCBsZWF2ZXMgDQogICAgdGhlIE5FIHRlbXBvcmFy aWx5PyAgRkUxIG1heSB2b2x1bnRhcmlseSBkZWNpZGUgdG8gbGVhdmUgdGhlIA0KICAgIGFzc29j aWF0aW9uLiAgQWx0ZXJuYXRpdmVseSwgRkUxIG1heSBzdG9wIGZ1bmN0aW9uaW5nIHNpbXBseSBk dWUgdG8gDQogICAgdW5leHBlY3RlZCBmYWlsdXJlLiAgSW4gdGhlIGZvcm1lciBjYXNlLCBDRTEg cmVjZWl2ZXMgYSAibGVhdmUtDQogICAgYXNzb2NpYXRpb24gcmVxdWVzdCIgZnJvbSBGRTEuICBJ biB0aGUgbGF0dGVyLCBDRTEgZGV0ZWN0cyB0aGUgDQogICAgZmFpbHVyZSBvZiBGRTEgYnkgc29t ZSBvdGhlciBtZWFucy4gIEluIGJvdGggY2FzZXMsIENFMSBtdXN0IGluZm9ybSANCiAgICB0aGUg cm91dGluZyBwcm90b2NvbHMgb2Ygc3VjaCBhbiBldmVudCwgbW9zdCBsaWtlbHkgcHJvbXB0aW5n IGEgDQogICAgcmVhY2hhYmlsaXR5IGFuZCBTUEYgKFNob3J0ZXN0IFBhdGggRmlyc3QpIHJlY2Fs Y3VsYXRpb24gYW5kIA0KICAgIGFzc29jaWF0ZWQgZG93bmxvYWRpbmcgb2YgbmV3IEZJQnMgZnJv bSBDRTEgdG8gdGhlIG90aGVyIHJlbWFpbmluZyANCiAgICBGRXMgKG9ubHkgRkUyIGluIHRoaXMg ZXhhbXBsZSkuICBTdWNoIHJlY2FsY3VsYXRpb24gYW5kIEZJQiB1cGRhdGUgDQogICAgd2lsbCBh bHNvIGJlIHByb3BhZ2F0ZWQgZnJvbSBDRTEgdG8gdGhlIE5FJ3MgbmVpZ2hib3JzIHRoYXQgYXJl IA0KICAgIGFmZmVjdGVkIGJ5IHRoZSBjb25uZWN0aXZpdHkgb2YgRkUxLiAgIA0KICAgICANCiAg ICBXaGVuIEZFMSBkZWNpZGVzIHRvIHJlam9pbiBhZ2Fpbiwgb3Igd2hlbiBpdCByZXN0YXJ0cyBh Z2FpbiBmcm9tIA0KICAgIHRoZSBmYWlsdXJlLCBGRTEgbmVlZHMgdG8gcmUtZGlzY292ZXIgaXRz IG1hc3RlciAoQ0UpLiAgVGhpcyBjYW4gYmUgDQogICAgYWNoaWV2ZWQgYnkgc2V2ZXJhbCBtZWFu cy4gIEl0IG1heSByZS1lbnRlciB0aGUgcHJlLWFzc29jaWF0aW9uIA0KICAgIHBoYXNlIGFuZCBn ZXQgdGhhdCBpbmZvcm1hdGlvbiBmcm9tIGl0cyBGRSBtYW5hZ2VyLiAgSXQgbWF5IA0KICAgIHJl dHJpZXZlIHRoZSBwcmV2aW91cyBDRSBpbmZvcm1hdGlvbiBmcm9tIGl0cyBjYWNoZSwgaWYgaXQg Y2FuIA0KICAgIHZhbGlkYXRlIHRoZSBpbmZvcm1hdGlvbiBmcmVzaG5lc3MuICBPbmNlIGl0IGRp c2NvdmVycyBpdHMgQ0UsIGl0IA0KICAgIHN0YXJ0cyBtZXNzYWdlIGV4Y2hhbmdlIHdpdGggdGhl IENFIHRvIHJlLWVzdGFibGlzaCB0aGUgYXNzb2NpYXRpb24gDQogICAganVzdCBhcyBvdXRsaW5l ZCBpbiBGaWd1cmUgOSwgd2l0aCB0aGUgcG9zc2libGUgZXhjZXB0aW9uIHRoYXQgaXQgDQogICAg bWlnaHQgYmUgYWJsZSB0byBieXBhc3MgdGhlIHRyYW5zcG9ydCBvZiB0aGUgY29tcGxldGUgaW5p dGlhbCANCiAgICBjb25maWd1cmF0aW9uLiAgU3VwcG9zZSB0aGF0IEZFMSBzdGlsbCBoYXMgaXRz IHJvdXRpbmcgdGFibGUgYW5kIA0KICAgIG90aGVyIHN0YXRlIGluZm9ybWF0aW9uIGZyb20gdGhl IGxhc3QgYXNzb2NpYXRpb24uIEluc3RlYWQgb2YgDQogICAgc2VuZGluZyBhbGwgdGhlIGluZm9y bWF0aW9uIGFnYWluIGZyb20gc2NyYXRjaCwgaXQgbWF5IGJlIGFibGUgdG8gDQogICAgdXNlIG1v cmUgZWZmaWNpZW50IG1lY2hhbmlzbSB0byByZS1zeW5jIHVwIHRoZSBzdGF0ZSB3aXRoIGl0cyBD RSBpZiANCiAgICBzdWNoIG1lY2hhbmlzbSBpcyBzdXBwb3J0ZWQgYnkgdGhlIEZvckNFUyBQcm90 b2NvbC4gIEZvciBleGFtcGxlLCANCiAgICBDUkMtMzIgb2YgdGhlIHN0YXRlIG1pZ2h0IGdpdmUg YSBxdWljayBpbmRpY2F0aW9uIG9mIHdoZXRoZXIgb3Igbm90IA0KICANCiAgDQogWWFuZywgZXQg YWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjRd ICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAg ICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgdGhlIHN0YXRlIGlzIGluLXN5bmMgd2l0 aCBpdHMgQ0UuICBCeSBjb21wYXJpbmcgaXRzIHN0YXRlIHdpdGggdGhlIA0KICAgIENFIGZpcnN0 LCBpdCBzZW5kcyBhbiBpbmZvcm1hdGlvbiB1cGRhdGUgb25seSBpZiBpdCBpcyBuZWVkZWQuICAN CiAgICBGb3JDRVMgUHJvdG9jb2wgbWF5IGNob29zZSB0byBpbXBsZW1lbnQgc2ltaWxhciBvcHRp bWl6YXRpb24gDQogICAgbWVjaGFuaXNtcywgYnV0IGl0IG1heSBhbHNvIGNob29zZSBub3QgdG8s IGFzIHRoaXMgaXMgbm90IGEgDQogICAgcmVxdWlyZW1lbnQuIA0KICAgICANCiAgICAgDQogNS4g QXBwbGljYWJpbGl0eSB0byBSRkMxODEyICANCiAgDQogICAgWzNdIFNlY3Rpb24gNSwgcmVxdWly ZW1lbnQgIzkgZGljdGF0ZXMgIkFueSBwcm9wb3NlZCBGb3JDRVMgDQogICAgYXJjaGl0ZWN0dXJl IG11c3QgZXhwbGFpbiBob3cgdGhhdCBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgYWxsIG9mIHRoZSAN CiAgICByb3V0ZXIgZnVuY3Rpb25zIGFzIGRlZmluZWQgaW4gUkZDMTgxMi4iICBSRkMxODEyIGRp c2N1c3NlcyBtYW55IA0KICAgIGltcG9ydGFudCByZXF1aXJlbWVudHMgZm9yIElQdjQgcm91dGVy cyBmcm9tIHRoZSBsaW5rIGxheWVyIHRvIHRoZSANCiAgICBhcHBsaWNhdGlvbiBsYXllci4gIFRo aXMgc2VjdGlvbiBhZGRyZXNzZXMgdGhlIHJlbGV2YW50IA0KICAgIHJlcXVpcmVtZW50cyBpbiBS RkMxODEyIGZvciBpbXBsZW1lbnRpbmcgSVB2NCByb3V0ZXJzIGJhc2VkIG9uIA0KICAgIEZvckNF UyBhcmNoaXRlY3R1cmUgYW5kIGV4cGxhaW5zIGhvdyBGb3JDRVMgc2F0aXNmaWVzIHRoZXNlIA0K ICAgIHJlcXVpcmVtZW50cyBieSBwcm92aWRpbmcgZ3VpZGVsaW5lcyBvbiBob3cgdG8gc2VwYXJh dGUgdGhlIA0KICAgIGZ1bmN0aW9uYWxpdGllcyByZXF1aXJlZCBpbnRvIGZvcndhcmRpbmcgcGxh bmUgYW5kIGNvbnRyb2wgcGxhbmUuICAgDQogICAgIA0KICAgIEluIGdlbmVyYWwsIHRoZSBmb3J3 YXJkaW5nIHBsYW5lIGNhcnJpZXMgb3V0IHRoZSBidWxrIG9mIHRoZSBwZXItDQogICAgcGFja2V0 IHByb2Nlc3NpbmcgdGhhdCBpcyByZXF1aXJlZCBhdCBsaW5lIHNwZWVkLCB3aGlsZSB0aGUgY29u dHJvbCANCiAgICBwbGFuZSBjYXJyaWVzIG1vc3Qgb2YgdGhlIGNvbXB1dGF0aW9uYWxseSBjb21w bGV4IG9wZXJhdGlvbnMgdGhhdCANCiAgICBhcmUgdHlwaWNhbCBvZiB0aGUgY29udHJvbCBhbmQg c2lnbmFsaW5nIHByb3RvY29scy4gIEhvd2V2ZXIsIGl0IGlzIA0KICAgIGltcG9zc2libGUgdG8g ZHJhdyBhIHJpZ2lkIGxpbmUgdG8gZGl2aWRlIHRoZSBwcm9jZXNzaW5nIGludG8gQ0VzIA0KICAg IGFuZCBGRXMgY2xlYW5seS4gIE5vciBzaG91bGQgdGhlIEZvckNFUyBhcmNoaXRlY3R1cmUgbGlt aXQgdGhlIA0KICAgIGlubm92YXRpdmUgYXBwcm9hY2hlcyBpbiBjb250cm9sIGFuZCBmb3J3YXJk aW5nIHBsYW5lIHNlcGFyYXRpb24uICANCiAgICBBcyBtb3JlIGFuZCBtb3JlIHByb2Nlc3Npbmcg cG93ZXIgaXMgYXZhaWxhYmxlIGluIHRoZSBGRXMsIHNvbWUgb2YgDQogICAgdGhlIGNvbnRyb2wg ZnVuY3Rpb25zIHRoYXQgdHJhZGl0aW9uYWxseSBhcmUgcGVyZm9ybWVkIGJ5IENFcyBtYXkgDQog ICAgbm93IGJlIG1vdmVkIHRvIEZFcyBmb3IgYmV0dGVyIHBlcmZvcm1hbmNlIGFuZCBzY2FsYWJp bGl0eS4gIFN1Y2ggDQogICAgb2ZmbG9hZGVkIGZ1bmN0aW9ucyBtYXkgaW5jbHVkZSBwYXJ0IG9m IElDTVAgb3IgVENQIHByb2Nlc3NpbmcsIG9yIA0KICAgIHBhcnQgb2Ygcm91dGluZyBwcm90b2Nv bHMuICBPbmNlIG9mZi1sb2FkZWQgb250byB0aGUgZm9yd2FyZGluZyANCiAgICBwbGFuZSwgc3Vj aCBDRSBmdW5jdGlvbnMsIGV2ZW4gdGhvdWdoIGxvZ2ljYWxseSBiZWxvbmdpbmcgdG8gdGhlIA0K ICAgIGNvbnRyb2wgcGxhbmUsIG5vdyBiZWNvbWUgcGFydCBvZiB0aGUgRkUgZnVuY3Rpb25zLiAg SnVzdCBsaWtlIHRoZSANCiAgICBvdGhlciBsb2dpY2FsIGZ1bmN0aW9ucyBwZXJmb3JtZWQgYnkg RkVzLCBzdWNoIG9mZi1sb2FkZWQgZnVuY3Rpb25zIA0KICAgIG11c3QgYmUgZXhwcmVzc2VkIGFz IHBhcnQgb2YgdGhlIEZFIG1vZGVsIHNvIHRoYXQgdGhlIENFcyBjYW4gDQogICAgZGVjaWRlIGhv dyB0byBiZXN0IHRha2UgYWR2YW50YWdlIG9mIHRoZXNlIG9mZi1sb2FkZWQgZnVuY3Rpb25zIA0K ICAgIHdoZW4gcHJlc2VudCBvbiB0aGUgRkVzLiANCiAgICAgDQogNS4xLiBHZW5lcmFsIFJvdXRl ciBSZXF1aXJlbWVudHMgDQogIA0KICAgIFJvdXRlcnMgaGF2ZSBhdCBsZWFzdCB0d28gb3IgbW9y ZSBsb2dpY2FsIGludGVyZmFjZXMuICBXaGVuIENFcyBhbmQgDQogICAgRkVzIGFyZSBzZXBhcmF0 ZWQgYnkgRm9yQ0VTIHdpdGhpbiBhIHNpbmdsZSBORSwgc29tZSBhZGRpdGlvbmFsIA0KICAgIGlu dGVyZmFjZXMgYXJlIG5lZWRlZCBmb3IgaW50cmEtTkUgY29tbXVuaWNhdGlvbnMuICBGaWd1cmUg MTIgc2hvd3MgDQogICAgYW4gZXhhbXBsZSB0byBpbGx1c3RyYXRlIHRoYXQuICBUaGlzIE5FIGNv bnRhaW5zIG9uZSBDRSBhbmQgdHdvIA0KICAgIEZFcy4gIEVhY2ggRkUgaGFzIGZvdXIgaW50ZXJm YWNlczsgdHdvIG9mIHRoZW0gYXJlIHVzZWQgZm9yIA0KICAgIHJlY2VpdmluZyBhbmQgdHJhbnNt aXR0aW5nIHBhY2tldHMgdG8gdGhlIGV4dGVybmFsIHdvcmxkLCB3aGlsZSB0aGUgDQogICAgb3Ro ZXIgdHdvIGFyZSBmb3IgaW50cmEtTkUgY29ubmVjdGlvbnMuICBDRSBoYXMgdHdvIGxvZ2ljYWwg DQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEp1bHkgICAgMjAwNCAgICAgICAg ICAgICAgICAgICBbUGFnZSAyNV0gIA0KDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMg RnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDQgDQogIA0KICANCiAgICBpbnRl cmZhY2VzICM5IGFuZCAjMTAsIGNvbm5lY3RlZCB0byBpbnRlcmZhY2VzICMzIGFuZCAjNiBmcm9t IEZFMSANCiAgICBhbmQgRkUyLCByZXNwZWN0aXZlbHkuICBJbnRlcmZhY2UgIzQgYW5kICM1IGFy ZSBjb25uZWN0ZWQgZm9yIEZFMS0NCiAgICBGRTIgY29tbXVuaWNhdGlvbi4gIFRoZXJlZm9yZSwg dGhpcyByb3V0ZXIgTkUgcHJvdmlkZXMgZm91ciANCiAgICBleHRlcm5hbCBpbnRlcmZhY2VzICgj MSwgMiwgNyBhbmQgOCkuICANCiAgDQogICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSANCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHJvdXRl ciBORSAgICAgICB8IA0KICAgICAgICAgICAgICAgICB8ICAgLS0tLS0tLS0tLS0gICAtLS0tLS0t LS0tLSAgIHwgDQogICAgICAgICAgICAgICAgIHwgICB8ICAgRkUxICAgfCAgIHwgICBGRTIgICB8 ICAgfCANCiAgICAgICAgICAgICAgICAgfCAgIC0tLS0tLS0tLS0tICAgLS0tLS0tLS0tLS0gICB8 IA0KICAgICAgICAgICAgICAgICB8ICAgMXwgMnwgM3wgNHwgICA1fCA2fCA3fCA4fCAgIHwgDQog ICAgICAgICAgICAgICAgIHwgICAgfCAgfCAgfCAgfCAgICB8ICB8ICB8ICB8ICAgfCANCiAgICAg ICAgICAgICAgICAgfCAgICB8ICB8ICB8ICArLS0tLSsgIHwgIHwgIHwgICB8IA0KICAgICAgICAg ICAgICAgICB8ICAgIHwgIHwgIHwgICAgICAgICAgfCAgfCAgfCAgIHwgDQogICAgICAgICAgICAg ICAgIHwgICAgfCAgfCA5fCAgICAgICAgMTB8ICB8ICB8ICAgfCANCiAgICAgICAgICAgICAgICAg fCAgICB8ICB8IC0tLS0tLS0tLS0tLS0tIHwgIHwgICB8IA0KICAgICAgICAgICAgICAgICB8ICAg IHwgIHwgfCAgICBDRSAgICAgIHwgfCAgfCAgIHwgDQogICAgICAgICAgICAgICAgIHwgICAgfCAg fCAtLS0tLS0tLS0tLS0tLSB8ICB8ICAgfCANCiAgICAgICAgICAgICAgICAgfCAgICB8ICB8ICAg ICAgICAgICAgICAgIHwgIHwgICB8IA0KICAgICAgICAgICAgICAgICAtLS0tLSstLSstLS0tLS0t LS0tLS0tLS0tKy0tKy0tLS0gDQogICAgICAgICAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAg ICAgICB8ICB8ICANCiAgICAgICAgICAgICAgICAgICAgICB8ICB8ICAgICAgICAgICAgICAgIHwg IHwgIA0KICAgICANCiAgICAgICAgICAgICAgICAgRmlndXJlIDEyLiBBIHJvdXRlciBORSBleGFt cGxlIHdpdGggZm91ciBpbnRlcmZhY2VzLiANCiAgDQogICAgSVB2NCByb3V0ZXJzIG11c3QgaW1w bGVtZW50IElQIHRvIHN1cHBvcnQgaXRzIHBhY2tldCBmb3J3YXJkaW5nIA0KICAgIGZ1bmN0aW9u LCB3aGljaCBpcyBkcml2ZW4gYnkgaXRzIEZJQiAoRm9yd2FyZGluZyBJbmZvcm1hdGlvbiBCYXNl KS4gDQogICAgVGhpcyBJbnRlcm5ldCBsYXllciBmb3J3YXJkaW5nIChzZWUgUkZDMTgxMiBbMV0g U2VjdGlvbiA1KSANCiAgICBmdW5jdGlvbmFsaXR5IG5hdHVyYWxseSBiZWxvbmdzIHRvIEZFcyBp biB0aGUgRm9yQ0VTIGFyY2hpdGVjdHVyZS4gIA0KICAgICANCiAgICBBIHJvdXRlciBtYXkgaW1w bGVtZW50IHRyYW5zcG9ydCBsYXllciBwcm90b2NvbHMgKGxpa2UgVENQIGFuZCBVRFApIA0KICAg IHRoYXQgYXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2xz IChzZWUgDQogICAgUkZDMTgxMiBbMV0gU2VjdGlvbiA2KS4gIE9uZSBpbXBvcnRhbnQgY2xhc3Mg b2YgYXBwbGljYXRpb24gDQogICAgcHJvdG9jb2xzIGlzIHJvdXRpbmcgcHJvdG9jb2xzIChzZWUg UkZDMTgxMiBbMV0gU2VjdGlvbiA3KS4gIEluIA0KICAgIEZvckNFUyBhcmNoaXRlY3R1cmUsIHJv dXRpbmcgcHJvdG9jb2xzIGFyZSBuYXR1cmFsbHkgaW1wbGVtZW50ZWQgYnkgDQogICAgQ0VzLiAg Um91dGluZyBwcm90b2NvbHMgcmVxdWlyZSByb3V0ZXJzIGNvbW11bmljYXRlIHdpdGggZWFjaCAN CiAgICBvdGhlci4gIFRoaXMgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIENFcyBpbiBkaWZmZXJlbnQg cm91dGVycyBpcyANCiAgICBzdXBwb3J0ZWQgaW4gRm9yQ0VTIGJ5IEZFcycgYWJpbGl0eSB0byBy ZWRpcmVjdCBkYXRhIHBhY2tldHMgDQogICAgYWRkcmVzc2VkIHRvIHJvdXRlcnMgKGkuZS4sIE5F cykgYW5kIENFcycgYWJpbGl0eSB0byBvcmlnaW5hdGUgDQogICAgcGFja2V0cyBhbmQgaGF2ZSB0 aGVtIGRlbGl2ZXJlZCBieSB0aGVpciBGRXMuICBUaGlzIGNvbW11bmljYXRpb24gDQogICAgb2Nj dXJzIGFjcm9zcyBGcCByZWZlcmVuY2UgcG9pbnQgaW5zaWRlIGVhY2ggcm91dGVyIGFuZCBiZXR3 ZWVuIA0KICAgIG5laWdoYm9yaW5nIHJvdXRlcnMnIGV4dGVybmFsIGludGVyZmFjZXMsIGFzIGls bHVzdHJhdGVkIGluIEZpZ3VyZSANCiAgICAxMS4gIA0KICAgICANCiA1LjIuTGluayBMYXllciAN CiAgICAgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEp1bHkgICAgMjAwNCAg ICAgICAgICAgICAgICAgICBbUGFnZSAyNl0gIA0KDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICBG b3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDQgDQogIA0KICANCiAg ICBTaW5jZSBGRXMgb3duIGFsbCB0aGUgZXh0ZXJuYWwgaW50ZXJmYWNlcyBmb3IgdGhlIHJvdXRl ciwgRkVzIG5lZWQgDQogICAgdG8gY29uZm9ybSB0byB0aGUgbGluayBsYXllciByZXF1aXJlbWVu dHMgaW4gUkZDMTgxMi4gIEFyZ3VhYmx5LCANCiAgICBBUlAgc3VwcG9ydCBtYXkgYmUgaW1wbGVt ZW50ZWQgaW4gZWl0aGVyIENFcyBvciBGRXMuICBBcyB3ZSB3aWxsIA0KICAgIHNlZSBsYXRlciwg YSBudW1iZXIgb2YgYmVoYXZpb3JzIHRoYXQgUkZDMTgxMiBtYW5kYXRlcyBmYWxsIGludG8gDQog ICAgdGhpcyBjYXRlZ29yeSAtLSB0aGV5IG1heSBiZSBwZXJmb3JtZWQgYnkgdGhlIEZFIGFuZCBt YXkgYmUgDQogICAgcGVyZm9ybWVkIGJ5IHRoZSBDRS4gIEEgZ2VuZXJhbCBndWlkZWxpbmUgaXMg bmVlZGVkIHRvIGVuc3VyZSANCiAgICBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gc2VwYXJhdGVk IGNvbnRyb2wgYW5kIGZvcndhcmRpbmcgcGxhbmVzLiAgDQogICAgVGhlIGd1aWRlbGluZSB3ZSBv ZmZlciBoZXJlIGlzIHRoYXQgQ0VzIE1VU1QgYmUgY2FwYWJsZSBvZiB0aGVzZSANCiAgICBraW5k IG9mIG9wZXJhdGlvbnMgd2hpbGUgRkVzIE1BWSBjaG9vc2UgdG8gaW1wbGVtZW50IHRoZW0uICBG RSANCiAgICBtb2RlbCBzaG91bGQgaW5kaWNhdGUgaXRzIGNhcGFiaWxpdGllcyBpbiB0aGlzIHJl Z2FyZCBzbyB0aGF0IENFcyANCiAgICBjYW4gZGVjaWRlIHdoZXJlIHRoZXNlIGZ1bmN0aW9ucyBh cmUgaW1wbGVtZW50ZWQuIA0KICAgICANCiAgICBJbnRlcmZhY2UgcGFyYW1ldGVycywgaW5jbHVk aW5nIE1UVSwgSVAgYWRkcmVzcywgZXRjLiwgbXVzdCBiZSANCiAgICBjb25maWd1cmFibGUgYnkg Q0VzIHZpYSBGb3JDRVMuICBDRXMgbXVzdCBiZSBhYmxlIHRvIGRldGVybWluZSANCiAgICB3aGV0 aGVyIGEgcGh5c2ljYWwgaW50ZXJmYWNlIGluIGFuIEZFIGlzIGF2YWlsYWJsZSB0byBzZW5kIHBh Y2tldHMgDQogICAgb3Igbm90LiAgRkVzIG11c3QgYWxzbyBpbmZvcm0gQ0VzIHRoZSBzdGF0dXMg Y2hhbmdlIG9mIHRoZSANCiAgICBpbnRlcmZhY2VzIChsaWtlIGxpbmsgdXAvZG93bikgdmlhIEZv ckNFUy4gDQogICAgIA0KIDUuMy5JbnRlcm5ldCBMYXllciBQcm90b2NvbHMgDQogICAgIA0KICAg IEJvdGggRkVzIGFuZCBDRXMgbXVzdCBpbXBsZW1lbnQgSVAgcHJvdG9jb2wgYW5kIGFsbCBtYW5k YXRvcnkgDQogICAgZXh0ZW5zaW9ucyBhcyBSRkMxODEyIHNwZWNpZmllZC4gIENFcyBzaG91bGQg aW1wbGVtZW50IElQIG9wdGlvbnMgDQogICAgbGlrZSBzb3VyY2Ugcm91dGUgYW5kIHJlY29yZCBy b3V0ZSB3aGlsZSBGRXMgbWF5IGNob29zZSB0byANCiAgICBpbXBsZW1lbnQgdGhvc2UgYXMgd2Vs bC4gIFRoZSB0aW1lc3RhbXAgb3B0aW9uIHNob3VsZCBiZSANCiAgICBpbXBsZW1lbnRlZCBieSBG RXMgdG8gaW5zZXJ0IHRoZSB0aW1lc3RhbXAgbW9zdCBhY2N1cmF0ZWx5LiAgVGhlIEZFIA0KICAg IG11c3QgaW50ZXJwcmV0IHRoZSBJUCBvcHRpb25zIHRoYXQgaXQgdW5kZXJzdGFuZHMgYW5kIHBy ZXNlcnZlIHRoZSANCiAgICByZXN0IHVuY2hhbmdlZCBmb3IgdXNlIGJ5IENFcy4gIEJvdGggRkVz IGFuZCBDRXMgbWlnaHQgY2hvb3NlIHRvIA0KICAgIHNpbGVudGx5IGRpc2NhcmQgcGFja2V0cyB3 aXRob3V0IHNlbmRpbmcgSUNNUCBlcnJvcnMsIGJ1dCBzdWNoIA0KICAgIGV2ZW50cyBzaG91bGQg YmUgbG9nZ2VkIGFuZCBjb3VudGVkLiAgRkVzIG1heSByZXBvcnQgc3RhdGlzdGljcyBmb3IgDQog ICAgc3VjaCBldmVudHMgdG8gQ0VzIHZpYSBGb3JDRVMuICANCiAgDQogICAgV2hlbiBtdWx0aXBs ZSBGRXMgYXJlIGludm9sdmVkIHRvIHByb2Nlc3MgcGFja2V0cywgdGhlIGFwcGVhcmFuY2UgDQog ICAgb2Ygc2luZ2xlIE5FIG11c3QgYmUgc3RyaWN0bHkgbWFpbnRhaW5lZC4gIEZvciBleGFtcGxl LCBUaW1lLVRvLQ0KICAgIExpdmUgKFRUTCkgbXVzdCBiZSBkZWNyZW1lbnRlZCBvbmx5IG9uY2Ug d2l0aGluIGEgc2luZ2xlIE5FLiAgRm9yIA0KICAgIGV4YW1wbGUsIGl0IGNhbiBiZSBhbHdheXMg ZGVjcmVtZW50ZWQgYnkgdGhlIGxhc3QgRkUgd2l0aCBlZ3Jlc3MgDQogICAgZnVuY3Rpb24uICAN CiAgICAgDQogICAgRkVzIG11c3QgcmVjZWl2ZSBhbmQgcHJvY2VzcyBub3JtYWxseSBhbnkgcGFj a2V0cyB3aXRoIGEgYnJvYWRjYXN0IA0KICAgIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3IgYSBtdWx0 aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyB0aGF0IHRoZSANCiAgICByb3V0ZXIgaGFzIGFza2Vk IHRvIHJlY2VpdmUuICBXaGVuIElQIG11bHRpY2FzdCBpcyBzdXBwb3J0ZWQgaW4gDQogICAgcm91 dGVycywgSUdNUCBpcyBpbXBsZW1lbnRlZCBpbiBDRXMuICBDRXMgYXJlIGFsc28gcmVxdWlyZWQg b2YgSUNNUCANCiAgICBzdXBwb3J0LCB3aGlsZSBpdCBpcyBvcHRpb25hbCBmb3IgRkVzIHRvIHN1 cHBvcnQgSUNNUC4gIFN1Y2ggYW4gDQogICAgb3B0aW9uIGNhbiBiZSBjb21tdW5pY2F0ZWQgdG8g Q0VzIGFzIHBhcnQgb2YgdGhlIEZFIG1vZGVsLiAgDQogICAgVGhlcmVmb3JlLCBGRXMgY2FuIGFs d2F5cyByZWx5IHVwb24gQ0VzIHRvIHNlbmQgb3V0IElDTVAgZXJyb3IgDQogICAgbWVzc2FnZXMs IGJ1dCBGRXMgYWxzbyBoYXZlIHRoZSBvcHRpb24gdG8gZ2VuZXJhdGUgSUNNUCBlcnJvciANCiAg ICBtZXNzYWdlcyB0aGVtc2VsdmVzLiAgDQogICAgIA0KICANCiAgDQogWWFuZywgZXQgYWwuICAg ICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjddICANCg0K IEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAg SmFudWFyeSAyMDA0IA0KICANCiAgDQogNS40LkludGVybmV0IExheWVyIEZvcndhcmRpbmcgDQog ICAgIA0KICAgIElQIGZvcndhcmRpbmcgaXMgaW1wbGVtZW50ZWQgYnkgRkVzLiAgV2hlbiB0aGUg cm91dGluZyB0YWJsZSBpcyANCiAgICB1cGRhdGVkIGF0IENFcywgRm9yQ0VTIGlzIHVzZWQgdG8g c2VuZCB0aGUgbmV3IHJvdXRlIGVudHJpZXMgZnJvbSANCiAgICBDRXMgdG8gRkVzLiAgRWFjaCBG RSBoYXMgaXRzIG93biBmb3J3YXJkaW5nIHRhYmxlIGFuZCB1c2VzIHRoaXMgDQogICAgdGFibGUg dG8gZGlyZWN0IHBhY2tldHMgdG8gdGhlIG5leHQgaG9wIGludGVyZmFjZS4gIA0KICAgICANCiAg ICBVcG9uIHJlY2VpdmluZyBJUCBwYWNrZXRzLCB0aGUgRkUgdmVyaWZpZXMgdGhlIElQIGhlYWRl ciBhbmQgDQogICAgcHJvY2Vzc2VzIG1vc3Qgb2YgdGhlIElQIG9wdGlvbnMuICBTb21lIG9wdGlv bnMgY2Fubm90IGJlIHByb2Nlc3NlZCANCiAgICB1bnRpbCB0aGUgcm91dGluZyBkZWNpc2lvbiBo YXMgYmVlbiBtYWRlLiAgVGhlIHJvdXRpbmcgZGVjaXNpb24gaXMgDQogICAgbWFkZSBhZnRlciBl eGFtaW5pbmcgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MuICBJZiB0aGUgDQogICAgZGVzdGlu YXRpb24gYWRkcmVzcyBiZWxvbmdzIHRvIHRoZSByb3V0ZXIgaXRzZWxmLCB0aGUgcGFja2V0cyBh cmUgDQogICAgZmlsdGVyZWQgYW5kIGVpdGhlciBwcm9jZXNzZWQgbG9jYWxseSBvciBmb3J3YXJk ZWQgdG8gQ0UsIGRlcGVuZGluZyANCiAgICB1cG9uIHRoZSBpbnN0cnVjdGlvbnMgc2V0LXVwIGJ5 IENFLiAgT3RoZXJ3aXNlLCB0aGUgRkUgZGV0ZXJtaW5lcyANCiAgICB0aGUgbmV4dCBob3AgSVAg YWRkcmVzcyBieSBsb29raW5nIHVwIGluIGl0cyBmb3J3YXJkaW5nIHRhYmxlLiAgVGhlIA0KICAg IEZFIGFsc28gZGV0ZXJtaW5lcyB0aGUgbmV0d29yayBpbnRlcmZhY2UgaXQgdXNlcyB0byBzZW5k IHRoZSANCiAgICBwYWNrZXRzLiAgU29tZXRpbWVzIGFuIEZFIG1heSBuZWVkIHRvIGZvcndhcmQg dGhlIHBhY2tldHMgdG8gDQogICAgYW5vdGhlciBGRSBiZWZvcmUgcGFja2V0cyBjYW4gYmUgZm9y d2FyZGVkIG91dCB0byB0aGUgbmV4dCBob3AuICANCiAgICBSaWdodCBiZWZvcmUgcGFja2V0cyBh cmUgZm9yd2FyZGVkIG91dCB0byB0aGUgbmV4dCBob3AsIHRoZSBGRSANCiAgICBkZWNyZW1lbnRz IFRUTCBieSAxIGFuZCBwcm9jZXNzZXMgYW55IElQIG9wdGlvbnMgdGhhdCBjYW5ub3QgYmUgDQog ICAgcHJvY2Vzc2VkIGJlZm9yZS4gIFRoZSBGRSBwZXJmb3JtcyBhbnkgSVAgZnJhZ21lbnRhdGlv biBpZiANCiAgICBuZWNlc3NhcnksIGRldGVybWluZXMgbGluayBsYXllciBhZGRyZXNzIChlLmcu LCBieSBBUlApLCBhbmQgDQogICAgZW5jYXBzdWxhdGVzIHRoZSBJUCBkYXRhZ3JhbSAob3IgZWFj aCBvZiB0aGUgZnJhZ21lbnRzIHRoZXJlb2YpIGluIA0KICAgIGFuIGFwcHJvcHJpYXRlIGxpbmsg bGF5ZXIgZnJhbWUgYW5kIHF1ZXVlcyBpdCBmb3Igb3V0cHV0IG9uIHRoZSANCiAgICBpbnRlcmZh Y2Ugc2VsZWN0ZWQuIA0KICAgICANCiAgICBPdGhlciBvcHRpb25zIG1lbnRpb25lZCBpbiBSRkMx ODEyIGZvciBJUCBmb3J3YXJkaW5nIG1heSBhbHNvIGJlIA0KICAgIGltcGxlbWVudGVkIGF0IEZF cywgZm9yIGV4YW1wbGUsIHBhY2tldCBmaWx0ZXJpbmcuIA0KICAgICANCiAgICBGRXMgdHlwaWNh bGx5IGZvcndhcmQgcGFja2V0cyBkZXN0aW5lZCBsb2NhbGx5IHRvIENFcy4gIEZFcyBtYXkgDQog ICAgYWxzbyBmb3J3YXJkIGV4Y2VwdGlvbmFsIHBhY2tldHMgKHBhY2tldHMgdGhhdCBGRXMgZG8g bm90IGtub3cgaG93IA0KICAgIHRvIGhhbmRsZSkgdG8gQ0VzLiAgQ0VzIGFyZSByZXF1aXJlZCB0 byBoYW5kbGUgcGFja2V0cyBmb3J3YXJkZWQgYnkgDQogICAgRkVzIGZvciB3aGF0ZXZlciBkaWZm ZXJlbnQgcmVhc29ucy4gIEl0IG1pZ2h0IGJlIG5lY2Vzc2FyeSBmb3IgDQogICAgRm9yQ0VTIHRv IGF0dGFjaCBzb21lIG1ldGEtZGF0YSB3aXRoIHRoZSBwYWNrZXRzIHRvIGluZGljYXRlIHRoZSAN CiAgICByZWFzb25zIG9mIGZvcndhcmRpbmcgZnJvbSBGRXMgdG8gQ0VzLiAgVXBvbiByZWNlaXZp bmcgcGFja2V0cyB3aXRoIA0KICAgIG1ldGEtZGF0YSBmcm9tIEZFcywgQ0VzIGNhbiBkZWNpZGUg dG8gZWl0aGVyIHByb2Nlc3MgdGhlIHBhY2tldHMgDQogICAgdGhlbXNlbHZlcywgb3IgcGFzcyB0 aGUgcGFja2V0cyB0byB0aGUgdXBwZXIgbGF5ZXIgcHJvdG9jb2xzIA0KICAgIGluY2x1ZGluZyBy b3V0aW5nIGFuZCBtYW5hZ2VtZW50IHByb3RvY29scy4gIElmIENFcyBhcmUgdG8gcHJvY2VzcyAN CiAgICB0aGUgcGFja2V0cyBieSB0aGVtc2VsdmVzLCBDRXMgbWF5IGNob29zZSB0byBkaXNjYXJk IHRoZSBwYWNrZXRzLCANCiAgICBvciBtb2RpZnkgYW5kIHJlLXNlbmQgdGhlIHBhY2tldHMuICBD RXMgbWF5IGFsc28gb3JpZ2luYXRlIG5ldyANCiAgICBwYWNrZXRzIGFuZCBkZWxpdmVyIHRoZW0g dG8gRkVzIGZvciBmdXJ0aGVyIGZvcndhcmRpbmcuICANCiAgICAgDQogICAgQW55IHN0YXRlIGNo YW5nZSBkdXJpbmcgcm91dGVyIG9wZXJhdGlvbiBtdXN0IGFsc28gYmUgaGFuZGxlZCANCiAgICBj b3JyZWN0bHkgYWNjb3JkaW5nIHRvIFJGQzE4MTIuICBGb3IgZXhhbXBsZSwgd2hlbiBhbiBGRSBj ZWFzZXMgDQogICAgZm9yd2FyZGluZywgdGhlIGVudGlyZSBORSBtYXkgY29udGludWUgZm9yd2Fy ZGluZyBwYWNrZXRzLCBidXQgaXQgDQogICAgbmVlZHMgdG8gc3RvcCBhZHZlcnRpc2luZyByb3V0 ZXMgdGhhdCBhcmUgYWZmZWN0ZWQgYnkgdGhlIGZhaWxlZCANCiAgICBGRS4gIA0KICANCiAgDQog WWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAg W1BhZ2UgMjhdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAg ICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgICANCiA1LjUuIFRyYW5z cG9ydCBMYXllciAgDQogICAgIA0KICAgIFRyYW5zcG9ydCBsYXllciBpcyB0eXBpY2FsbHkgaW1w bGVtZW50ZWQgYXQgQ0VzIHRvIHN1cHBvcnQgaGlnaGVyIA0KICAgIGxheWVyIGFwcGxpY2F0aW9u IHByb3RvY29scyBsaWtlIHJvdXRpbmcgcHJvdG9jb2xzLiAgSW4gcHJhY3RpY2UsIA0KICAgIHRo aXMgbWVhbnMgdGhhdCBtb3N0IENFcyBpbXBsZW1lbnQgYm90aCB0aGUgVHJhbnNtaXNzaW9uIENv bnRyb2wgDQogICAgUHJvdG9jb2wgKFRDUCkgYW5kIHRoZSBVc2VyIERhdGFncmFtIFByb3RvY29s IChVRFApLiANCiAgICAgDQogICAgQm90aCBDRXMgYW5kIEZFcyBuZWVkIHRvIGltcGxlbWVudCBG b3JDRVMgUHJvdG9jb2wuICBJZiBzb21lIGxheWVyLQ0KICAgIDQgdHJhbnNwb3J0IGlzIHVzZWQg dG8gc3VwcG9ydCBGb3JDRVMsIHRoZW4gYm90aCBDRXMgYW5kIEZFcyBuZWVkIA0KICAgIHRvIGlt cGxlbWVudCB0aGUgTDQgdHJhbnNwb3J0IGFuZCBGb3JDRVMgUHJvdG9jb2xzLiAgIA0KICANCiA1 LjYuIEFwcGxpY2F0aW9uIExheWVyIC0tIFJvdXRpbmcgUHJvdG9jb2xzIA0KICAgICANCiAgICBJ bnRlcmlvciBhbmQgZXh0ZXJpb3Igcm91dGluZyBwcm90b2NvbHMgYXJlIGltcGxlbWVudGVkIG9u IENFcy4gIA0KICAgIFRoZSByb3V0aW5nIHBhY2tldHMgb3JpZ2luYXRlZCBieSBDRXMgYXJlIGZv cndhcmRlZCB0byBGRXMgZm9yIA0KICAgIGRlbGl2ZXJ5LiAgVGhlIHJlc3VsdHMgb2Ygc3VjaCBw cm90b2NvbHMgKGxpa2UgZm9yd2FyZGluZyB0YWJsZSANCiAgICB1cGRhdGVzKSBhcmUgY29tbXVu aWNhdGVkIHRvIEZFcyB2aWEgRm9yQ0VTLiANCiAgICAgDQogICAgRm9yIHBlcmZvcm1hbmNlIG9y IHNjYWxhYmlsaXR5IHJlYXNvbnMsIHBvcnRpb25zIG9mIHRoZSBjb250cm9sIA0KICAgIHBsYW5l IGZ1bmN0aW9ucyB0aGF0IG5lZWQgZmFzdGVyIHJlc3BvbnNlIG1heSBiZSBtb3ZlZCBmcm9tIHRo ZSBDRXMgDQogICAgYW5kIG9mZi1sb2FkZWQgb250byB0aGUgRkVzLiAgRm9yIGV4YW1wbGUgaW4g T1NQRiwgdGhlIEhlbGxvIA0KICAgIHByb3RvY29sIHBhY2tldHMgYXJlIGdlbmVyYXRlZCBhbmQg cHJvY2Vzc2VkIHBlcmlvZGljYWxseS4gIFdoZW4gDQogICAgZG9uZSBhdCBDRXMsIHRoZSBpbmJv dW5kIEhlbGxvIHBhY2tldHMgaGF2ZSB0byB0cmF2ZXJzZSBmcm9tIHRoZSANCiAgICBleHRlcm5h bCBpbnRlcmZhY2VzIGF0IHRoZSBGRXMgdG8gdGhlIENFcyB2aWEgdGhlIGludGVybmFsIENFLUZF IA0KICAgIGNoYW5uZWwuICBTaW1pbGFybHksIHRoZSBvdXRib3VuZCBIZWxsbyBwYWNrZXRzIGhh dmUgdG8gZ28gZnJvbSB0aGUgDQogICAgQ0VzIHRvIHRoZSBGRXMgYW5kIHRvIHRoZSBleHRlcm5h bCBpbnRlcmZhY2VzLiAgRnJlcXVlbnQgSGVsbG8gDQogICAgdXBkYXRlcyBwbGFjZSBoZWF2eSBw cm9jZXNzaW5nIG92ZXJoZWFkIG9uIHRoZSBDRXMgYW5kIGNhbiANCiAgICBvdmVyd2hlbG0gdGhl IENFLUZFIGNoYW5uZWwgYXMgd2VsbC4gIFNpbmNlIHR5cGljYWxseSB0aGVyZSBhcmUgZmFyIA0K ICAgIG1vcmUgRkVzIHRoYW4gQ0VzIGluIGEgcm91dGVyLCB0aGUgb2ZmLWxvYWRlZCBIZWxsbyBw YWNrZXRzIGFyZSANCiAgICBwcm9jZXNzZWQgaW4gYSBtdWNoIG1vcmUgZGlzdHJpYnV0ZWQgYW5k IHNjYWxhYmxlIGZhc2hpb24uICBCeSANCiAgICBleHByZXNzaW5nIHN1Y2ggb2ZmLWxvYWRlZCBm dW5jdGlvbnMgaW4gdGhlIEZFIG1vZGVsLCB3ZSBjYW4gZW5zdXJlIA0KICAgIGludGVyb3BlcmFi aWxpdHkuIEhvd2V2ZXIsIHRoZSBleGFjdCBkZXNjcmlwdGlvbiBvZiB0aGUgb2ZmLWxvYWRlZCAN CiAgICBmdW5jdGlvbmFsaXR5IGNvcnJlc3BvbmRpbmcgdG8gdGhlIG9mZi1sb2FkZWQgZnVuY3Rp b25zIGV4cHJlc3NlZCANCiAgICBpbiB0aGUgRkUgbW9kZWwgYXJlIG5vdCBwYXJ0IG9mIHRoZSBt b2RlbCBpdHNlbGYgYW5kIHdpbGwgbmVlZCB0byANCiAgICBiZSB3b3JrZWQgb3V0IGFzIGEgc2Vw YXJhdGUgc3BlY2lmaWNhdGlvbi4gDQogIA0KIDUuNy4gQXBwbGljYXRpb24gTGF5ZXIgLS0gTmV0 d29yayBNYW5hZ2VtZW50IFByb3RvY29sIA0KICAgICANCiAgICBSRkMxODEyIGFsc28gZGljdGF0 ZXMgIlJvdXRlcnMgTVVTVCBiZSBtYW5hZ2VhYmxlIGJ5IFNOTVAuIiAgSW4gDQogICAgZ2VuZXJh bCwgZm9yIHBvc3QtYXNzb2NpYXRpb24gcGhhc2UsIG1vc3QgZXh0ZXJuYWwgbWFuYWdlbWVudCB0 YXNrcyANCiAgICAoaW5jbHVkaW5nIFNOTVApIHNob3VsZCBiZSBkb25lIHRocm91Z2ggaW50ZXJh Y3Rpb24gd2l0aCB0aGUgQ0UgaW4gDQogICAgb3JkZXIgdG8gc3VwcG9ydCB0aGUgYXBwZWFyYW5j ZSBvZiBhIHNpbmdsZSBmdW5jdGlvbmFsIGRldmljZS4gIA0KICAgIFRoZXJlZm9yZSwgaXQgaXMg cmVjb21tZW5kZWQgdGhhdCBTTk1QIGFnZW50IGJlIGltcGxlbWVudGVkIGJ5IENFcyANCiAgICBh bmQgdGhlIFNOTVAgbWVzc2FnZXMgcmVjZWl2ZWQgYnkgRkVzIGJlIHJlZGlyZWN0ZWQgdG8gdGhl aXIgQ0VzLiAgDQogICAgQWdlbnRYIGZyYW1ld29yayBkZWZpbmVkIGluIFJGQzI3NDEgKFs1XSkg bWF5IGJlIGFwcGxpZWQgaGVyZSBzdWNoIA0KICAgIHRoYXQgQ0VzIGFjdCBpbiB0aGUgcm9sZSBv ZiBtYXN0ZXIgYWdlbnQgdG8gcHJvY2VzcyBTTk1QIHByb3RvY29sIA0KICANCiAgDQogWWFuZywg ZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MjldICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAg ICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgbWVzc2FnZXMgd2hpbGUgRkVzIGFj dCBpbiB0aGUgcm9sZSBvZiBzdWJhZ2VudCB0byBwcm92aWRlIGFjY2VzcyB0byANCiAgICB0aGUg TUlCIG9iamVjdHMgcmVzaWRpbmcgb24gRkVzLiAgQWdlbnRYIHByb3RvY29sIG1lc3NhZ2VzIGJl dHdlZW4gDQogICAgdGhlIG1hc3RlciBhZ2VudCAoQ0UpIGFuZCB0aGUgc3ViYWdlbnQgKEZFKSBh cmUgZW5jYXBzdWxhdGVkIGFuZCANCiAgICB0cmFuc3BvcnRlZCB2aWEgRm9yQ0VTLCBqdXN0IGxp a2UgZGF0YSBwYWNrZXRzIGZyb20gYW55IG90aGVyIA0KICAgIGFwcGxpY2F0aW9uIGxheWVyIHBy b3RvY29scy4gIA0KICANCiA2LiBTdW1tYXJ5IA0KICAgICANCiAgICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYW4gYXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmsgZm9yIEZvckNFUy4gIEl0IA0KICAgIGlk ZW50aWZpZXMgdGhlIHJlbGV2YW50IGNvbXBvbmVudHMgZm9yIGEgRm9yQ0VTIG5ldHdvcmsgZWxl bWVudCwgDQogICAgaW5jbHVkaW5nIChvbmUgb3IgbW9yZSkgRkVzLCAob25lIG9yIG1vcmUpIENF cywgb25lIG9wdGlvbmFsIEZFIA0KICAgIG1hbmFnZXIsIGFuZCBvbmUgb3B0aW9uYWwgQ0UgbWFu YWdlci4gIEl0IGFsc28gaWRlbnRpZmllcyB0aGUgDQogICAgaW50ZXJhY3Rpb24gYW1vbmcgdGhl c2UgY29tcG9uZW50cyBhbmQgZGlzY3Vzc2VzIGFsbCB0aGUgbWFqb3IgDQogICAgcmVmZXJlbmNl IHBvaW50cy4gIEl0IGlzIGltcG9ydGFudCB0byBwb2ludCBvdXQgdGhhdCwgYW1vbmcgYWxsIHRo ZSANCiAgICByZWZlcmVuY2UgcG9pbnRzLCBvbmx5IHRoZSBGcCBpbnRlcmZhY2UgYmV0d2VlbiBD RXMgYW5kIEZFcyBpcyANCiAgICB3aXRoaW4gdGhlIHNjb3BlIG9mIEZvckNFUy4gIEZvckNFUyBh bG9uZSBtYXkgbm90IGJlIGVub3VnaCB0byANCiAgICBzdXBwb3J0IGFsbCBkZXNpcmFibGUgTkUg Y29uZmlndXJhdGlvbnMuICBIb3dldmVyLCB3ZSBiZWxpZXZlIHRoYXQgDQogICAgRm9yQ0VTIG92 ZXIgRnAgaW50ZXJmYWNlIGlzIHRoZSBtb3N0IGltcG9ydGFudCBlbGVtZW50IGluIHJlYWxpemlu ZyANCiAgICBwaHlzaWNhbCBzZXBhcmF0aW9uIGFuZCBpbnRlcm9wZXJhYmlsaXR5IG9mIENFcyBh bmQgRkVzLCBhbmQgaGVuY2UgDQogICAgdGhlIGZpcnN0IGludGVyZmFjZSB0aGF0IG91Z2h0IHRv IGJlIHN0YW5kYXJkaXplZC4gIFNpbXBsZSBhbmQgDQogICAgdXNlZnVsIGNvbmZpZ3VyYXRpb25z IGNhbiBzdGlsbCBiZSBpbXBsZW1lbnRlZCB3aXRoIG9ubHkgQ0UtRkUgDQogICAgaW50ZXJmYWNl IGJlaW5nIHN0YW5kYXJkaXplZCwgZS5nLiwgc2luZ2xlIENFIHdpdGggZnVsbC1tZXNoZWQgRkVz LiANCiAgICAgDQogNy4gQWNrbm93bGVkZ2VtZW50cyANCiAgICAgDQogICAgSm9lbCBNLiBIYWxw ZXJuIGdhdmUgdXMgbWFueSBpbnNpZ2h0ZnVsIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyANCiAg ICBhbmQgcG9pbnRlZCBvdXQgc2V2ZXJhbCBtYWpvciBpc3N1ZXMuICBULiBTcmlkaGFyIHN1Z2dl c3RlZCB0aGF0IA0KICAgIHRoZSBBZ2VudFggcHJvdG9jb2wgY291bGQgYmUgdXNlZCB3aXRoIFNO TVAgdG8gbWFuYWdlIHRoZSBGb3JDRVMgDQogICAgbmV0d29yayBlbGVtZW50cy4gIFN1c2FuIEhh cmVzIHBvaW50ZWQgb3V0IHRoZSBpc3N1ZSBvZiBncmFjZWZ1bCANCiAgICByZXN0YXJ0IHdpdGgg Rm9yQ0VTLiAgUnVzcyBIb3VzbGV5LCBBdnJpIERvcmlhLCBKYW1hbCBIYWRpIFNhbGltIA0KICAg IGFuZCBtYW55IG90aGVycyBpbiB0aGUgRm9yQ0VTIG1haWxpbmcgbGlzdCBhbHNvIHByb3ZpZGVk IHZhbHVhYmxlIA0KICAgIGZlZWRiYWNrLiANCiAgICAgDQogOC4gU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgDQogICAgIA0KICAgIFRoZSBORSBhZG1pbmlzdHJhdG9yIGhhcyB0aGUgZnJlZWRvbSB0 byBkZXRlcm1pbmUgdGhlIGV4YWN0IA0KICAgIHNlY3VyaXR5IGNvbmZpZ3VyYXRpb24gdGhhdCBp cyBuZWVkZWQgZm9yIHRoZSBzcGVjaWZpYyBkZXBsb3ltZW50LiANCiAgICBGb3IgZXhhbXBsZSwg Rm9yQ0VTIG1heSBiZSBkZXBsb3llZCBiZXR3ZWVuIENFcyBhbmQgRkVzIGNvbm5lY3RlZCANCiAg ICB0byBlYWNoIG90aGVyIGluc2lkZSBhIGJveCBvdmVyIGEgYmFja3BsYW5lLiAgSW4gc3VjaCBz Y2VuYXJpbywgDQogICAgcGh5c2ljYWwgc2VjdXJpdHkgb2YgdGhlIGJveCBlbnN1cmVzIHRoYXQg bW9zdCBvZiB0aGUgYXR0YWNrcyBzdWNoIA0KICAgIGFzIG1hbi1pbi10aGUtbWlkZGxlLCBzbm9v cGluZywgYW5kIGltcGVyc29uYXRpb24gYXJlIG5vdCBwb3NzaWJsZSwgDQogICAgYW5kIGhlbmNl IEZvckNFUyBhcmNoaXRlY3R1cmUgbWF5IHJlbHkgb24gdGhlIHBoeXNpY2FsIHNlY3VyaXR5IG9m IA0KICAgIHRoZSBib3ggdG8gZGVmZW5kIGFnYWluc3QgdGhlc2UgYXR0YWNrcyBhbmQgcHJvdG9j b2wgbWVjaGFuaXNtcyBtYXkgDQogICAgYmUgdHVybmVkIG9mZi4gIEhvd2V2ZXIsIGl0IGlzIGFs c28gc2hvd24gdGhhdCBkZW5pYWwgb2Ygc2VydmljZSANCiAgICBhdHRhY2sgdmlhIGV4dGVybmFs IGludGVyZmFjZSBhcyBkZXNjcmliZWQgYmVsb3cgaW4gU2VjdGlvbiA4LjEuOCANCiAgICBpcyBz dGlsbCBhIHBvdGVudGlhbCB0aHJlYXQgZXZlbiBmb3Igc3VjaCAiYWxsLWluLW9uZS1ib3giIA0K ICAgIGRlcGxveW1lbnQgc2NlbmFyaW8gYW5kIGhlbmNlIHRoZSByYXRlIGxpbWl0aW5nIG1lY2hh bmlzbSBpcyBzdGlsbCANCiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgSnVseSAg ICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDMwXSAgDQoNCiBJbnRlcm5ldCBEcmFmdCAg ICAgICAgIEZvckNFUyBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNCANCiAg DQogIA0KICAgIG5lY2Vzc2FyeS4gIFRoaXMgaXMganVzdCBvbmUgZXhhbXBsZSB0byBzaG93IHRo YXQgaXQgaXMgaW1wb3J0YW50IA0KICAgIHRvIGFzc2VzcyB0aGUgc2VjdXJpdHkgbmVlZHMgb2Yg dGhlIEZvckNFUy1lbmFibGVkIG5ldHdvcmsgZWxlbWVudHMgDQogICAgdW5kZXIgZGlmZmVyZW50 IGRlcGxveW1lbnQgc2NlbmFyaW9zLiAgSXQgc2hvdWxkIGJlIHBvc3NpYmxlIGZvciANCiAgICB0 aGUgYWRtaW5pc3RyYXRvciB0byBjb25maWd1cmUgdGhlIGxldmVsIG9mIHNlY3VyaXR5IG5lZWRl ZCBmb3IgdGhlIA0KICAgIEZvckNFUyBQcm90b2NvbC4gDQogICAgIA0KICAgIEluIGdlbmVyYWws IHRoZSBwaHlzaWNhbCBzZXBhcmF0aW9uIG9mIHR3byBlbnRpdGllcyB1c3VhbGx5IHJlc3VsdHMg DQogICAgaW4gYSBwb3RlbnRpYWxseSBpbnNlY3VyZSBsaW5rIGJldHdlZW4gdGhlIHR3byBlbnRp dGllcyBhbmQgaGVuY2UgDQogICAgbXVjaCBzdHJpY3RlciBzZWN1cml0eSBtZWFzdXJlbWVudHMg YXJlIHJlcXVpcmVkLiAgRm9yIGV4YW1wbGUsIHdlIA0KICAgIHBvaW50ZWQgb3V0IGluIFNlY3Rp b24gNC4xIHRoYXQgYXV0aGVudGljYXRpb24gYmVjb21lcyBuZWNlc3NhcnkgDQogICAgYmV0d2Vl biBDRSBtYW5hZ2VyIGFuZCBGRSBtYW5hZ2VyLCBiZXR3ZWVuIENFIGFuZCBDRSBtYW5hZ2VyLCAN CiAgICBiZXR3ZWVuIEZFIGFuZCBGRSBtYW5hZ2VyIGluIHNvbWUgY29uZmlndXJhdGlvbnMuICBU aGUgcGh5c2ljYWwgDQogICAgc2VwYXJhdGlvbiBvZiBDRSBhbmQgRkUgYWxzbyBpbXBvc2VzIHNl cmlvdXMgc2VjdXJpdHkgcmVxdWlyZW1lbnQgDQogICAgZm9yIEZvckNFUyBQcm90b2NvbCBvdmVy IEZwIGludGVyZmFjZS4gIFRoaXMgc2VjdGlvbiBmaXJzdCBhdHRlbXB0cyANCiAgICB0byBkZXNj cmliZSB0aGUgc2VjdXJpdHkgdGhyZWF0cyB0aGF0IG1heSBiZSBpbnRyb2R1Y2VkIGJ5IHRoZSAN CiAgICBwaHlzaWNhbCBzZXBhcmF0aW9uIG9mIHRoZSBGRXMgYW5kIHRoZSBDRXMsIGFuZCB0aGVu IGl0IHByb3ZpZGVzIA0KICAgIHJlY29tbWVuZGF0aW9uIGFuZCBndWlkZWxpbmVzIGZvciBzZWN1 cmUgb3BlcmF0aW9uIGFuZCBtYW5hZ2VtZW50IA0KICAgIG9mIEZvckNFUyBQcm90b2NvbCBvdmVy IEZwIGludGVyZmFjZSBiYXNlZCBvbiBleGlzdGluZyBzdGFuZGFyZCANCiAgICBzZWN1cml0eSBz b2x1dGlvbnMuIA0KICAgICANCiA4LjEuIEFuYWx5c2lzIG9mIFBvdGVudGlhbCBUaHJlYXRzIElu dHJvZHVjZWQgYnkgRm9yQ0VTIA0KICAgICANCiAgICBUaGlzIHNlY3Rpb24gcHJvdmlkZXMgdGhl IHRocmVhdCBhbmFseXNpcyBmb3IgRm9yQ0VTLCB3aXRoIGEgZm9jdXMgDQogICAgb24gRnAgaW50 ZXJmYWNlLiAgRWFjaCB0aHJlYXQgaXMgZGVzY3JpYmVkIGluIGRldGFpbHMgd2l0aCB0aGUgDQog ICAgZWZmZWN0cyBvbiB0aGUgRm9yQ0VTIFByb3RvY29sIGVudGl0aWVzIG9yL2FuZCB0aGUgTkUg YXMgYSB3aG9sZSwgDQogICAgYW5kIHRoZSByZXF1aXJlZCBmdW5jdGlvbmFsaXRpZXMgdGhhdCBu ZWVkIHRvIGJlIGluIHBsYWNlIHRvIGRlZmVuZCANCiAgICB0aGUgdGhyZWF0LiAgDQogIA0KIDgu MS4xLiAiSm9pbiIgb3IgIlJlbW92ZSIgTWVzc2FnZSBGbG9vZGluZyBvbiBDRXMgDQogICAgIA0K ICAgIFRocmVhdHM6ICBBIG1hbGljaW91cyBub2RlIGNvdWxkIHNlbmQgYSBzdHJlYW0gb2YgZmFs c2UgImpvaW4gTkUiIA0KICAgIG9yICJyZW1vdmUgZnJvbSBORSIgcmVxdWVzdHMgb24gYmVoYWxm IG9mIG5vbi1leGlzdGVudCBvciANCiAgICB1bmF1dGhvcml6ZWQgRkUgdG8gbGVnaXRpbWF0ZSBD RXMgYXQgYSB2ZXJ5IHJhcGlkIHJhdGUgYW5kIHRoZXJlYnkgDQogICAgY3JlYXRlIHVubmVjZXNz YXJ5IHN0YXRlIGluIHRoZSBDRXMuIA0KICAgICANCiAgICBFZmZlY3RzOiBJZiBieSBtYWludGFp bmluZyBzdGF0ZSBmb3Igbm9uLWV4aXN0ZW50IG9yIHVuYXV0aG9yaXplZCANCiAgICBGRXMsIGEg Q0UgbWF5IGJlY29tZSB1bmF2YWlsYWJsZSBmb3Igb3RoZXIgcHJvY2Vzc2luZyBhbmQgaGVuY2Ug DQogICAgc3VmZmVyIGZyb20gZGVuaWFsIG9mIHNlcnZpY2UgKERvUykgYXR0YWNrIHNpbWlsYXIg dG8gdGhlIFRDUCBTWU4gDQogICAgRG9TLiAgSWYgbXVsdGlwbGUgQ0VzIGFyZSB1c2VkLCB0aGUg dW5uZWNlc3Nhcnkgc3RhdGUgaW5mb3JtYXRpb24gDQogICAgbWF5IGFsc28gYmUgY29udmV5ZWQg dG8gbXVsdGlwbGUgQ0VzIHZpYSBGciBpbnRlcmZhY2UgKGUuZy4sIGZyb20gDQogICAgdGhlIGFj dGl2ZSBDRSB0byB0aGUgc3RhbmQtYnkgQ0UpIGFuZCBoZW5jZSBzdWJqZWN0IG11bHRpcGxlIENF cyB0byANCiAgICBEb1MgYXR0YWNrLiAgDQogICAgICAgIA0KICAgIFJlcXVpcmVtZW50OiAgQSBD RSB0aGF0IHJlY2VpdmVzIGEgImpvaW4iIG9yICJyZW1vdmUiIHJlcXVlc3QgDQogICAgc2hvdWxk IG5vdCBjcmVhdGUgYW55IHN0YXRlIGluZm9ybWF0aW9uIHVudGlsIGl0IGhhcyBhdXRoZW50aWNh dGVkIA0KICAgIHRoZSBGRSBlbmRwb2ludC4gDQogICAgIA0KICANCiAgDQogWWFuZywgZXQgYWwu ICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMzFdICAN Cg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAgICAg ICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgIA0KIDguMS4yLiBJbXBlcnNvbmF0aW9uIEF0 dGFjayAgDQogICAgIA0KICAgIFRocmVhdHM6IEEgbWFsaWNpb3VzIG5vZGUgY2FuIGltcGVyc29u YXRlIGEgQ0Ugb3IgRkUgYW5kIHNlbmQgb3V0IA0KICAgIGZhbHNlIG1lc3NhZ2VzLiANCiAgICAg DQogICAgRWZmZWN0czogVGhlIHdob2xlIE5FIGNvdWxkIGJlIGNvbXByb21pc2VkLiANCiAgDQog ICAgUmVxdWlyZW1lbnQ6ICBUaGUgQ0Ugb3IgRkUgbXVzdCBhdXRoZW50aWNhdGUgdGhlIG1lc3Nh Z2UgYXMgaGF2aW5nIA0KICAgIGNvbWUgZnJvbSBhbiBGRSBvciBDRSBvbiB0aGUgbGlzdCBvZiB0 aGUgYXV0aG9yaXplZCBGb3JDRVMgZWxlbWVudHMgDQogICAgKHByb3ZpZGVkIGJ5IHRoZSBDRSBv ciBGRSBNYW5hZ2VyIGluIHRoZSBwcmUtYXNzb2NpYXRpb24gcGhhc2UpIA0KICAgIGJlZm9yZSBh Y2NlcHRpbmcgYW5kIHByb2Nlc3NpbmcgaXQuICAgDQogICAgIA0KICAgICANCiA4LjEuMy4gUmVw bGF5IEF0dGFjayANCiAgICAgDQogICAgVGhyZWF0OiBBIG1hbGljaW91cyBub2RlIGNvdWxkIHJl cGxheSB0aGUgZW50aXJlIG1lc3NhZ2UgcHJldmlvdXNseSANCiAgICBzZW50IGJ5IGFuIEZFIG9y IENFIGVudGl0eSB0byBnZXQgYXJvdW5kIGF1dGhlbnRpY2F0aW9uLiAgDQogICAgIA0KICAgIEVm ZmVjdDogVGhlIE5FIGNvdWxkIGJlIGNvbXByb21pc2VkLiANCiAgICAgDQogICAgUmVxdWlyZW1l bnQ6ICBSZXBsYXkgcHJvdGVjdGlvbiBtZWNoYW5pc20gbmVlZHMgdG8gYmUgcGFydCBvZiB0aGUg DQogICAgc2VjdXJpdHkgc29sdXRpb24gdG8gZGVmZW5kIGFnYWluc3QgdGhpcyBhdHRhY2suIA0K ICAgICAgDQogOC4xLjQuIEF0dGFjayBkdXJpbmcgRmFpbCBPdmVyIA0KICAgICAgDQogICAgVGhy ZWF0OiBBIG1hbGljaW91cyBub2RlIG1heSBleHBsb2l0IHRoZSBDRSBmYWlsLW92ZXIgbWVjaGFu aXNtIHRvIA0KICAgIHRha2Ugb3ZlciB0aGUgY29udHJvbCBvZiBORS4gRm9yIGV4YW1wbGUsIHN1 cHBvc2UgdHdvIENFcywgc2F5IENFLUEgDQogICAgYW5kIENFLUIsIGFyZSBjb250cm9sbGluZyBz ZXZlcmFsIEZFcy4gQ0UtQSBpcyBhY3RpdmUgYW5kIENFLUIgaXMgDQogICAgc3RhbmQtYnkuICBX aGVuIENFLUEgZmFpbHMsIENFLUIgaXMgdGFraW5nIG92ZXIgdGhlIGFjdGl2ZSBDRSANCiAgICBw b3NpdGlvbi4gIFRoZSBGRXMgYWxyZWFkeSBoYWQgYSB0cnVzdGVkIHJlbGF0aW9uc2hpcCB3aXRo IENFLUEsIA0KICAgIGJ1dCB0aGUgRkVzIG1heSBub3QgaGF2ZSB0aGUgc2FtZSB0cnVzdGVkIHJl bGF0aW9uc2hpcCBlc3RhYmxpc2hlZCANCiAgICB3aXRoIENFLUIgcHJpb3IgdG8gdGhlIGZhaWwt b3Zlci4gIEEgbWFsaWNpb3VzIG5vZGUgY2FuIHRha2Ugb3ZlciANCiAgICBhcyBDRS1CIGlmIHN1 Y2ggdHJ1c3RlZCByZWxhdGlvbnNoaXAgaGFzIG5vdCBiZWVuIGVzdGFibGlzaGVkIHByaW9yIA0K ICAgIG9yIGR1cmluZyB0aGUgZmFpbC1vdmVyLiAgDQogICAgIA0KICAgIEVmZmVjdDogVGhlIE5F IG1heSBiZSBjb21wcm9taXNlZCBhZnRlciBzdWNoIGluc2VjdXJlIGZhaWwtb3Zlci4gDQogICAg IA0KICAgIFJlcXVpcmVtZW50OiAgVGhlIGxldmVsIG9mIHRydXN0IHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIHRoZSBzdGFuZC1ieSANCiAgICBDRSBhbmQgdGhlIEZFcyBtdXN0IGJlIGFzIHN0cm9uZyBh cyB0aGUgb25lIGJldHdlZW4gdGhlIGFjdGl2ZSBDRSANCiAgICBhbmQgdGhlIEZFcy4gIFRoZSBz ZWN1cml0eSBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBGRXMgYW5kIHRoZSANCiAgICBzdGFuZC1i eSBDRSBtYXkgYmUgZXN0YWJsaXNoZWQgcHJpb3IgdG8gZmFpbC1vdmVyLiAgSWYgbm90IGFscmVh ZHkgDQogICAgaW4gcGxhY2UsIHN1Y2ggc2VjdXJpdHkgYXNzb2NpYXRpb24gbXVzdCBiZSByZS1l c3RhYmxpc2hlZCBiZWZvcmUgDQogICAgdGhlIHN0YW5kLWJ5IENFIHRha2VzIG92ZXIuIA0KICAg ICAgDQogOC4xLjUuICBEYXRhIEludGVncml0eSAgDQogICAgIA0KICANCiAgDQogWWFuZywgZXQg YWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAgICAgW1BhZ2UgMzJd ICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29yayAgICAgICAgICAg ICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgVGhyZWF0czogQSBtYWxpY2lvdXMgbm9k ZSBtYXkgaW5qZWN0IGZhbHNlIG1lc3NhZ2VzIHRvIGxlZ2l0aW1hdGUgDQogICAgQ0Ugb3IgRkUu ICAgICANCiAgICAgDQogICAgRWZmZWN0OiBBbiBGRSBvciBDRSByZWNlaXZlcyB0aGUgZmFicmlj YXRlZCBwYWNrZXQgYW5kIHBlcmZvcm1zIA0KICAgIGluY29ycmVjdCBvciBjYXRhc3Ryb3BoaWMg b3BlcmF0aW9uLiANCiAgICAgDQogICAgUmVxdWlyZW1lbnQ6IFByb3RvY29sIG1lc3NhZ2VzIHJl cXVpcmUgaW50ZWdyaXR5IHByb3RlY3Rpb24uIA0KICAgICANCiA4LjEuNi4gIERhdGEgQ29uZmlk ZW50aWFsaXR5IA0KICAgICANCiAgICBUaHJlYXQ6IFdoZW4gRkUgYW5kIENFIGFyZSBwaHlzaWNh bGx5IHNlcGFyYXRlZCwgYSBtYWxpY2lvdXMgbm9kZSANCiAgICBtYXkgZWF2ZXNkcm9wIHRoZSBt ZXNzYWdlcyBpbiB0cmFuc2l0LiAgU29tZSBvZiB0aGUgbWVzc2FnZXMgYXJlIA0KICAgIGNyaXRp Y2FsIHRvIHRoZSBmdW5jdGlvbmluZyBvZiB0aGUgd2hvbGUgbmV0d29yaywgd2hpbGUgb3RoZXJz IG1heSANCiAgICBjb250YWluIGNvbmZpZGVudGlhbCBidXNpbmVzcyBkYXRhLiAgTGVha2luZyBv ZiBzdWNoIGluZm9ybWF0aW9uIA0KICAgIG1heSByZXN1bHQgaW4gY29tcHJvbWlzZSBldmVuIGJl eW9uZCB0aGUgaW1tZWRpYXRlIENFIG9yIEZFLiAgDQogICAgICANCiAgICBFZmZlY3Q6IFNlbnNp dGl2ZSBpbmZvcm1hdGlvbiBtaWdodCBiZSBleHBvc2VkIGJldHdlZW4gQ0UgYW5kIEZFLiANCiAg ICAgDQogICAgUmVxdWlyZW1lbnQ6IERhdGEgY29uZmlkZW50aWFsaXR5IGJldHdlZW4gRkUgYW5k IENFIG11c3QgYmUgDQogICAgYXZhaWxhYmxlIGZvciBzZW5zaXRpdmUgaW5mb3JtYXRpb24uIA0K ICANCiA4LjEuNy4gU2hhcmluZyBzZWN1cml0eSBwYXJhbWV0ZXJzIA0KICAgICANCiAgICBUaHJl YXQ6IENvbnNpZGVyIGEgc2NlbmFyaW8gd2hlcmUgc2V2ZXJhbCBGRXMgY29tbXVuaWNhdGluZyB0 byB0aGUgDQogICAgc2FtZSBDRSBzaGFyZSB0aGUgc2FtZSBhdXRoZW50aWNhdGlvbiBrZXlzIGZv ciB0aGUgRnAgaW50ZXJmYWNlLiAgDQogICAgSWYgYW55IEZFIG9yIHRoZSBDRSBpcyBjb21wcm9t aXNlZCwgYWxsIG90aGVyIGVudGl0aWVzIGFyZSANCiAgICBjb21wcm9taXNlZC4gDQogICAgIA0K ICAgIEVmZmVjdDogVGhlIHdob2xlIE5FIGlzIGNvbXByb21pc2VkLiANCiAgICAgIA0KICAgIFJl Y29tbWVuZGF0aW9uOiBUbyBhdm9pZCB0aGlzIHNpZGUgZWZmZWN0LCBpdCdzIGJldHRlciB0byBj b25maWd1cmUgDQogICAgZGlmZmVyZW50IHNlY3VyaXR5IHBhcmFtZXRlcnMgZm9yIGVhY2ggRkUt Q0UgY29tbXVuaWNhdGlvbiBvdmVyIEZwIA0KICAgIGludGVyZmFjZS4gDQogICAgIA0KIDguMS44 LiBEZW5pYWwgb2YgU2VydmljZSBBdHRhY2sgdmlhIEV4dGVybmFsIEludGVyZmFjZSANCiAgICAg DQogICAgVGhyZWF0OiBXaGVuIGFuIEZFIHJlY2VpdmVzIGEgcGFja2V0IHRoYXQgaXMgZGVzdGlu ZWQgZm9yIGl0cyBDRSwgDQogICAgdGhlIEZFIGZvcndhcmRzIHRoZSBwYWNrZXQgb3ZlciB0aGUg RnAgaW50ZXJmYWNlLiAgTWFsaWNpb3VzIG5vZGUgDQogICAgY2FuIGdlbmVyYXRlIGh1Z2UgbWVz c2FnZSBzdG9ybSBsaWtlIHJvdXRpbmcgcHJvdG9jb2wgcGFja2V0cyBldGMuIA0KICAgIHRocm91 Z2ggdGhlIGV4dGVybmFsIEZpL2YgaW50ZXJmYWNlIHNvIHRoYXQgdGhlIEZFIGhhcyB0byBwcm9j ZXNzIA0KICAgIGFuZCBmb3J3YXJkIGFsbCBwYWNrZXRzIHRvIENFIHRocm91Z2ggRnAgaW50ZXJm YWNlLiANCiAgICAgDQogICAgRWZmZWN0OiBDRSBlbmNvdW50ZXJzIHJlc291cmNlIGV4aGF1c3Rp b24gYW5kIGJhbmR3aWR0aCBzdGFydmF0aW9uIA0KICAgIG9uIEZwIGludGVyZmFjZSBkdWUgdG8g YW4gb3ZlcndoZWxtaW5nIG51bWJlciBvZiBwYWNrZXRzIGZyb20gRkVzLiANCiAgICAgDQogICAg UmVxdWlyZW1lbnQ6IFNvbWUgc29ydCBvZiByYXRlIGxpbWl0aW5nIG1lY2hhbmlzbSBNVVNUIHRv IGJlIGluIA0KICAgIHBsYWNlIGF0IGJvdGggdGhlIEZFIGFuZCBDRS4gIFJhdGUgTGltaXRlciBT SE9VTEQgYmUgY29uZmlndXJlZCBhdCANCiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGly ZXMgSnVseSAgICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDMzXSAgDQoNCiBJbnRlcm5l dCBEcmFmdCAgICAgICAgIEZvckNFUyBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkg MjAwNCANCiAgDQogIA0KICAgIHRoZSBGRSBmb3IgZWFjaCBtZXNzYWdlIHR5cGUgdGhhdCBhcmUg YmVpbmcgcmVjZWl2ZWQgdGhyb3VnaCBGaS9GIA0KICAgIGludGVyZmFjZS4gDQogICAgICAgICAg DQogOC4yLiBTZWN1cml0eSBSZWNvbW1lbmRhdGlvbnMgZm9yIEZvckNFUyANCiAgDQogICAgVGhl IHJlcXVpcmVtZW50cyBkb2N1bWVudCBbM10gc3VnZ2VzdGVkIHRoYXQgRm9yQ0VTIFByb3RvY29s IHNob3VsZCANCiAgICBzdXBwb3J0IHJlbGlhYmlsaXR5IG92ZXIgRnAgaW50ZXJmYWNlLCBidXQg bm8gcGFydGljdWxhciB0cmFuc3BvcnQgDQogICAgcHJvdG9jb2wgaXMgeWV0IHNwZWNpZmllZCBm b3IgRm9yQ0VTLiAgVGhpcyBmcmFtZXdvcmsgZG9jdW1lbnQgZG9lcyANCiAgICBub3QgaW50ZW5k IHRvIHNwZWNpZnkgdGhlIHBhcnRpY3VsYXIgdHJhbnNwb3J0IGVpdGhlciwgYW5kIHNvIHdlIA0K ICAgIG9ubHkgcHJvdmlkZSByZWNvbW1lbmRhdGlvbnMgYW5kIGd1aWRlbGluZXMgYmFzZWQgb24g dGhlIGV4aXN0aW5nIA0KICAgIHN0YW5kYXJkIHNlY3VyaXR5IHByb3RvY29scyBbMThdIHRoYXQg Y2FuIHdvcmsgd2l0aCB0aGUgY29tbW9uIA0KICAgIHRyYW5zcG9ydCBjYW5kaWRhdGVzIHN1aXRh YmxlIGZvciBGb3JDRVMuIA0KICAgICAgDQogICAgV2UgcmV2aWV3IHR3byBleGlzdGluZyBzZWN1 cml0eSBwcm90b2NvbCBzb2x1dGlvbnMsIG5hbWVseSBJUHNlYyANCiAgICAoSVAgU2VjdXJpdHkp IFsxNF0gb3IgVExTIChUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkpIFsxM10uICBUTFMgDQogICAg d29ya3Mgd2l0aCByZWxpYWJsZSB0cmFuc3BvcnRzIHN1Y2ggYXMgVENQIG9yIFNDVFAgZm9yIHVu aWNhc3QsIA0KICAgIHdoaWxlIElQc2VjIGNhbiBiZSB1c2VkIHdpdGggYW55IHRyYW5zcG9ydCAo VURQLCBUQ1AsIFNDVFApIGFuZCANCiAgICBzdXBwb3J0cyBib3RoIHVuaWNhc3QgYW5kIG11bHRp Y2FzdC4gIEJvdGggVExTIGFuZCBJUHNlYyBjYW4gYmUgDQogICAgdXNlZCBwb3RlbnRpYWxseSB0 byBzYXRpc2Z5IGFsbCBvZiB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciANCiAgICBGb3JD RVMgUHJvdG9jb2wuICBJbiBhZGRpdGlvbiwgb3RoZXIgYXBwcm9hY2hlcyBtYXkgYmUgdXNlZCBh cyB3ZWxsIA0KICAgIGJ1dCBhcmUgbm90IGRvY3VtZW50ZWQgaGVyZSwgaW5jbHVkaW5nIHVzaW5n IEwyIHNlY3VyaXR5IG1lY2hhbmlzbXMgDQogICAgZm9yIGEgZ2l2ZW4gTDIgaW50ZXJjb25uZWN0 IHRlY2hub2xvZ3ksIGFzIGxvbmcgYXMgdGhlIHJlcXVpcmVtZW50cyANCiAgICBjYW4gYmUgc2F0 aXNmaWVkLiAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICBXaGVuIEZvckNFUyBpcyBkZXBsb3llZCBiZXR3ZWVuIENFcyBhbmQgRkVzIGluc2lk ZSBhIGJveCBvciBhIA0KICAgIHBoeXNpY2FsbHkgc2VjdXJlZCByb29tLCBhdXRoZW50aWNhdGlv biwgY29uZmlkZW50aWFsaXR5IGFuZCANCiAgICBpbnRlZ3JpdHkgbWF5IGJlIHByb3ZpZGVkIGJ5 IHRoZSBwaHlzaWNhbCBzZWN1cml0eSBvZiB0aGUgYm94IGFuZCANCiAgICBzbyB0aGUgc2VjdXJp dHkgbWVjaGFuaXNtcyBtYXkgYmUgdHVybmVkIG9mZiwgZGVwZW5kaW5nIG9uIHRoZSANCiAgICBu ZXR3b3JraW5nIHRvcG9sb2d5IGFuZCBpdHMgYWRtaW5pc3RyYXRpb24gcG9saWN5LiAgSG93ZXZl ciwgaXQgaXMgDQogICAgaW1wb3J0YW50IHRvIHJlYWxpemUgdGhhdCBldmVuIGlmIHRoZSBORSBp cyBpbiBhIHNpbmdsZS1ib3gsIHRoZSANCiAgICBEb1MgYXR0YWNrcyBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA4LjEuOCBjYW4gc3RpbGwgYmUgbGF1bmNoZWQgDQogICAgdGhyb3VnaCBGaS9mIGlu dGVyZmFjZXMuICBUaGVyZWZvcmUsIGl0IGlzIGltcG9ydGFudCB0byBoYXZlIHRoZSANCiAgICBj b3JyZXNwb25kaW5nIGNvdW50ZXItbWVhc3VyZW1lbnQgaW4gcGxhY2UgZXZlbiBmb3Igc2luZ2xl LWJveCANCiAgICBkZXBsb3ltZW50LiANCiAgDQogOC4yLjEuIFVzaW5nIFRMUyB3aXRoIEZvckNF UyANCiAgICAgDQogICAgVExTIFsxM10gY2FuIGJlIHVzZWQgaWYgYSByZWxpYWJsZSB1bmljYXN0 IHRyYW5zcG9ydCBzdWNoIGFzIFRDUCBvciANCiAgICBTQ1RQIGlzIHVzZWQgZm9yIEZvckNFUyBv dmVyIHRoZSBGcCBpbnRlcmZhY2UuICBUaGUgVExTIGhhbmRzaGFrZSANCiAgICBwcm90b2NvbCBp cyB1c2VkIGR1cmluZyBhc3NvY2lhdGlvbiBlc3RhYmxpc2htZW50IG9yIHJlLQ0KICAgIGVzdGFi bGlzaG1lbnQgcGhhc2UgdG8gbmVnb3RpYXRlIGEgVExTIHNlc3Npb24gYmV0d2VlbiB0aGUgQ0Ug YW5kIA0KICAgIEZFLiAgT25jZSB0aGUgc2Vzc2lvbiBpcyBpbiBwbGFjZSwgdGhlIFRMUyByZWNv cmQgcHJvdG9jb2wgaXMgdXNlZCANCiAgICB0byBzZWN1cmUgRm9yQ0VTIGNvbW11bmljYXRpb24g bWVzc2FnZXMgYmV0d2VlbiB0aGUgQ0UgYW5kIEZFLiANCiAgICAgDQogICAgQSBiYXNpYyBvdXRs aW5lIG9mIGhvdyBUTFMgY2FuIGJlIHVzZWQgd2l0aCBGb3JDRVMgaXMgZGVzY3JpYmVkIA0KICAg IGJlbG93LiAgU3RlcHMgMSkgdGlsbCA3KSBjb21wbGV0ZSB0aGUgc2VjdXJpdHkgaGFuZHNoYWtl IGFzIA0KICAgIGlsbHVzdHJhdGVkIGluIEZpZ3VyZSA5IHdoaWxlIHN0ZXAgOCkgaXMgZm9yIGFs bCB0aGUgZnVydGhlciANCiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgSnVseSAg ICAyMDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDM0XSAgDQoNCiBJbnRlcm5ldCBEcmFmdCAg ICAgICAgIEZvckNFUyBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNCANCiAg DQogIA0KICAgIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgQ0UgYW5kIEZFLCBpbmNsdWRpbmcg dGhlIHJlc3Qgb2YgbWVzc2FnZXMgDQogICAgYWZ0ZXIgdGhlIHNlY3VyaXR5IGhhbmRzaGFrZSBz aG93biBpbiBGaWd1cmUgOSBhbmQgdGhlIHN0ZWFkeS1zdGF0ZSANCiAgICBjb21tdW5pY2F0aW9u IHNob3duIGluIEZpZ3VyZSAxMC4gDQogICAgIA0KICAgICAgICAgMSkgRHVyaW5nIFByZS1hc3Nv Y2lhdGlvbiBwaGFzZSBhbGwgRkVzIGFyZSBjb25maWd1cmVkIHdpdGggDQogICAgICAgICB0aGUg Q0VzIChpbmNsdWRpbmcgYm90aCB0aGUgYWN0aXZlIENFIGFuZCB0aGUgc3RhbmRieSBDRSkuICAN CiAgICAgICAgIDIpIFRoZSBGRSBlc3RhYmxpc2hlcyBhIFRMUyBjb25uZWN0aW9uIHdpdGggdGhl IENFIChtYXN0ZXIpIA0KICAgICAgICAgYW5kIG5lZ290aWF0ZXMgYSBjaXBoZXIgc3VpdGUuIA0K ICAgICAgICAgMykgVGhlIEZFIChzbGF2ZSkgZ2V0cyB0aGUgQ0UgY2VydGlmaWNhdGUsIHZhbGlk YXRlcyB0aGUgDQogICAgICAgICBzaWduYXR1cmUsIGNoZWNrcyB0aGUgZXhwaXJhdGlvbiBkYXRl LCBjaGVja3MgaWYgdGhlIA0KICAgICAgICAgY2VydGlmaWNhdGUgaGFzIGJlZW4gcmV2b2tlZC4g DQogICAgICAgICA0KSBUaGUgQ0UgKG1hc3RlcikgZ2V0cyB0aGUgRkUgY2VydGlmaWNhdGUgYW5k IHBlcmZvcm1zIHRoZSANCiAgICAgICAgIHNhbWUgdmFsaWRhdGlvbiBhcyB0aGUgRkUgaW4gc3Rl cCAzKS4gIA0KICAgICAgICAgNSkgSWYgYW55IG9mIHRoZSBjaGVjayBmYWlscyBpbiBzdGVwIDMp IG9yIHN0ZXAgNCksIGVuZHBvaW50IA0KICAgICAgICAgbXVzdCBnZW5lcmF0ZSBhbiBlcnJvciBt ZXNzYWdlIGFuZCBhYm9ydC4gDQogICAgICAgICA2KSBBZnRlciBzdWNjZXNzZnVsIG11dHVhbCBh dXRoZW50aWNhdGlvbiwgYSBUTFMgc2Vzc2lvbiBpcyANCiAgICAgICAgIGVzdGFibGlzaGVkIGJl dHdlZW4gQ0UgYW5kIEZFLiANCiAgICAgICAgIDcpIFRoZSBGRSBzZW5kcyBhICJqb2luIE5FIiBt ZXNzYWdlIHRvIHRoZSBDRS4gICANCiAgICAgICAgIDgpIFRoZSBGRSBhbmQgQ0UgdXNlIFRMUyBz ZXNzaW9uIGZvciBmdXJ0aGVyIGNvbW11bmljYXRpb24uIA0KICAgICANCiAgICBOb3RlIHRoYXQg dGhlcmUgYXJlIGRpZmZlcmVudCB3YXlzIGZvciB0aGUgQ0UgYW5kIEZFIHRvIHZhbGlkYXRlIGEg DQogICAgcmVjZWl2ZWQgY2VydGlmaWNhdGUuICBPbmUgd2F5IGlzIHRvIGNvbmZpZ3VyZSB0aGUg RkUgTWFuYWdlciBvciBDRSANCiAgICBNYW5hZ2VyIG9yIG90aGVyIGNlbnRyYWwgY29tcG9uZW50 IGFzIENBLCBzbyB0aGF0IHRoZSBDRSBvciBGRSBjYW4gDQogICAgcXVlcnkgdGhpcyBwcmUtY29u ZmlndXJlZCBDQSB0byB2YWxpZGF0ZSB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSBoYXMgDQogICAgbm90 IGJlZW4gcmV2b2tlZC4gIEFub3RoZXIgd2F5IGlzIHRvIGhhdmUgdGhlIENFIGFuZCB0aGUgRkUg DQogICAgY29uZmlndXJlZCBkaXJlY3RseSBhIGxpc3Qgb2YgdmFsaWQgY2VydGlmaWNhdGVzIGlu IHRoZSBwcmUtDQogICAgYXNzb2NpYXRpb24gcGhhc2UuICANCiAgICAgDQogICAgSW4gdGhlIGNh c2Ugb2YgZmFpbC1vdmVyLCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIGFjdGl2ZSBD RSANCiAgICBhbmQgdGhlIHN0YW5kYnkgQ0UgdG8gc3luY2hyb25pemUgRm9yQ0VTIHN0YXRlcyBp bmNsdWRpbmcgdGhlIFRMUyANCiAgICBzdGF0ZXMgdG8gbWluaW1pemUgdGhlIHN0YXRlIHJlZXN0 YWJsaXNobWVudCBkdXJpbmcgZmFpbC1vdmVyLiAgDQogICAgQ2FyZSBtdXN0IGJlIHRha2VuIHRv IGVuc3VyZSB0aGF0IHRoZSBzdGFuZGJ5IENFIGlzIGFsc28gDQogICAgYXV0aGVudGljYXRlZCBp biB0aGUgc2FtZSB3YXkgYXMgdGhlIGFjdGl2ZSBDRSwgZWl0aGVyIGJlZm9yZSBvciANCiAgICBk dXJpbmcgdGhlIGZhaWwtb3Zlci4gDQogIA0KIDguMi4yLiBVc2luZyBJUHNlYyB3aXRoIEZvckNF UyANCiAgICAgDQogICAgSVBzZWMgWzE0XSBjYW4gYmUgdXNlZCB3aXRoIGFueSB0cmFuc3BvcnQg cHJvdG9jb2wsIHN1Y2ggYXMgVURQLCANCiAgICBTQ1RQIGFuZCBUQ1Agb3ZlciBGcCBpbnRlcmZh Y2UgZm9yIEZvckNFUy4gIFdoZW4gdXNpbmcgSVBzZWMsIHdlIA0KICAgIHJlY29tbWVuZCB1c2lu ZyBFU1AgaW4gdHJhbnNwb3J0IG1vZGUgZm9yIEZvckNFUyBiZWNhdXNlIG1lc3NhZ2UgDQogICAg Y29uZmlkZW50aWFsaXR5IGlzIHJlcXVpcmVkIGZvciBGb3JDRVMuICANCiAgICAgDQogICAgSVBz ZWMgY2FuIGJlIHVzZWQgd2l0aCBib3RoIG1hbnVhbCBhbmQgYXV0b21hdGVkIFNBIGFuZCANCiAg ICBjcnlwdG9ncmFwaGljIGtleSBtYW5hZ2VtZW50LiAgQnV0IElQc2VjJ3MgcmVwbGF5IHByb3Rl Y3Rpb24gDQogICAgbWVjaGFuaXNtcyBhcmUgbm90IGF2YWlsYWJsZSBpZiBtYW51YWwga2V5IG1h bmFnZW1lbnQgaXMgdXNlZC4gIA0KICAgIEhlbmNlLCBhdXRvbWF0aWMga2V5IG1hbmFnZW1lbnQg aXMgcmVjb21tZW5kZWQgaWYgcmVwbGF5IHByb3RlY3Rpb24gDQogICAgaXMgZGVlbWVkIGltcG9y dGFudC4gIE90aGVyd2lzZSwgbWFudWFsIGtleSBtYW5hZ2VtZW50IG1pZ2h0IGJlIA0KICANCiAg DQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAgICAgICAgICAg ICAgW1BhZ2UgMzVdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZyYW1ld29y ayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgc3VmZmljaWVudCBm b3Igc29tZSBkZXBsb3ltZW50IHNjZW5hcmlvcywgZXNwLiB3aGVuIHRoZSBudW1iZXIgb2YgDQog ICAgQ0VzIGFuZCBGRXMgaXMgcmVsYXRpdmVseSBzbWFsbC4gIEl0IGlzIHJlY29tbWVuZGVkIHRo YXQgdGhlIGtleXMgDQogICAgYmUgY2hhbmdlZCBwZXJpb2RpY2FsbHkgZXZlbiBmb3IgbWFudWFs IGtleSBtYW5hZ2VtZW50LiANCiAgICAgDQogICAgSVBzZWMgY2FuIHN1cHBvcnQgYm90aCB1bmlj YXN0IGFuZCBtdWx0aWNhc3QgdHJhbnNwb3J0LiBBdCB0aGUgdGltZSANCiAgICB0aGlzIGRvY3Vt ZW50IHdhcyBwdWJsaXNoZWQsIE1TRUMgd29ya2luZyBncm91cCBpcyBhY3RpdmVseSB3b3JraW5n IA0KICAgIG9uIHN0YW5kYXJkaXppbmcgcHJvdG9jb2xzIHRvIHByb3ZpZGUgbXVsdGljYXN0IHNl Y3VyaXR5IFsxN10uIA0KICAgIE11bHRpY2FzdC1iYXNlZCBzb2x1dGlvbnMgcmVseWluZyBvbiBJ UHNlYyBzaG91bGQgc3BlY2lmeSBob3cgdG8gDQogICAgbWVldCB0aGUgc2VjdXJpdHkgcmVxdWly ZW1lbnRzIGluIFszXS4gIA0KICAgICANCiAgICBVbmxpa2UgVExTLCBJUHNlYyBwcm92aWRlcyBz ZWN1cml0eSBzZXJ2aWNlcyBiZXR3ZWVuIHRoZSBDRSBhbmQgRkUgDQogICAgYXQgSVAgbGV2ZWws IGFuZCBzbyB0aGUgc2VjdXJpdHkgaGFuZHNoYWtlIGFzIGlsbHVzdHJhdGVkIGluIEZpZ3VyZSAN CiAgICA5IGFtb3VudHMgdG8gYSAibm8tb3AiIHdoZW4gbWFudWFsIGtleSBtYW5hZ2VtZW50IGlz IHVzZWQuICBUaGUgDQogICAgZm9sbG93aW5nIG91dGxpbmUgdGhlIHN0ZXBzIHRha2VuIGZvciBG b3JDRVMgaW4gc3VjaCBhIGNhc2UuIA0KICAgICANCiAgICAgICAgIDEpIER1cmluZyBQcmUtYXNz b2NpYXRpb24gcGhhc2UgYWxsIEZFcyBhcmUgY29uZmlndXJlZCB3aXRoIA0KICAgICAgICAgdGhl IENFcyAoaW5jbHVkaW5nIGFjdGl2ZSBDRSBhbmQgc3RhbmRieSBDRSkgYW5kIFNBIHBhcmFtZXRl cnMgDQogICAgICAgICBtYW51YWxseS4gDQogICAgICAgICAyKSBUaGUgRkUgc2VuZHMgYSAiam9p biBORSIgbWVzc2FnZSB0byB0aGUgQ0UuICBUaGlzIG1lc3NhZ2UgDQogICAgICAgICBhbmQgYWxs IG90aGVycyB0aGF0IGZvbGxvdyBhcmUgYWZmb3JkZWQgc2VjdXJpdHkgc2VydmljZSANCiAgICAg ICAgIGFjY29yZGluZyB0byB0aGUgbWFudWFsbHkgY29uZmlndXJlZCBJUHNlYyBTQSBwYXJhbWV0 ZXJzLCBidXQgDQogICAgICAgICByZXBsYXkgcHJvdGVjdGlvbiBpcyBub3QgYXZhaWxhYmxlLiAg DQogICAgIA0KICAgIEl0IGlzIHVwIHRvIHRoZSBhZG1pbmlzdHJhdG9yIHRvIGRlY2lkZSB3aGV0 aGVyIHRvIHNoYXJlIHRoZSBzYW1lIA0KICAgIGtleSBhY3Jvc3MgbXVsdGlwbGUgRkUtQ0UgY29t bXVuaWNhdGlvbiwgYnV0IGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgDQogICAgZGlmZmVyZW50IGtl eXMgYmUgdXNlZC4gIFNpbWlsYXJseSwgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCANCiAgICBkaWZm ZXJlbnQga2V5cyBiZSB1c2VkIGZvciBpbmJvdW5kIGFuZCBvdXRib3VuZCB0cmFmZmljLiANCiAg DQogICAgSWYgYXV0b21hdGljIGtleSBtYW5hZ2VtZW50IGlzIG5lZWRlZCwgSUtFIFsxNV0gY2Fu IGJlIHVzZWQgZm9yIA0KICAgIHRoYXQgcHVycG9zZS4gT3RoZXIgYXV0b21hdGljIGtleSBkaXN0 cmlidXRpb24gdGVjaG5pcXVlcyBzdWNoIGFzIA0KICAgIEtlcmJlcm9zIG1heSBiZSB1c2VkIGFz IHdlbGwuICAgVGhlIGtleSBleGNoYW5nZSBwcm9jZXNzIA0KICAgIGNvbnN0aXR1dGVzIHRoZSBz ZWN1cml0eSBoYW5kc2hha2UgYXMgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDkuICBUaGUgDQogICAg Zm9sbG93aW5nIHNob3dzIHRoZSBzdGVwcyBpbnZvbHZlZCBpbiB1c2luZyBJS0Ugd2l0aCBJUHNl YyBmb3IgDQogICAgRm9yQ0VTLiAgU3RlcHMgMSkgdG8gNikgY29uc3RpdHV0ZSB0aGUgc2VjdXJp dHkgaGFuZHNoYWtlIGluIEZpZ3VyZSANCiAgICA5LiANCiAgICAgDQogICAgICAgICAxKSBEdXJp bmcgUHJlLWFzc29jaWF0aW9uIHBoYXNlIGFsbCBGRXMgYXJlIGNvbmZpZ3VyZWQgd2l0aCANCiAg ICAgICAgIHRoZSBDRXMgKGluY2x1ZGluZyBhY3RpdmUgQ0UgYW5kIHN0YW5kYnkgQ0UpLCBJUHNl YyBwb2xpY3kgDQogICAgICAgICBldGMuIA0KICAgICAgICAgMikgVGhlIEZFIGtpY2tzIG9mZiBJ S0UgcHJvY2VzcyBhbmQgdHJpZXMgdG8gZXN0YWJsaXNoIGFuIA0KICAgICAgICAgSVBzZWMgU0Eg d2l0aCB0aGUgQ0UgKG1hc3RlcikuICBUaGUgRkUgKFNsYXZlKSBnZXRzIHRoZSBDRSANCiAgICAg ICAgIGNlcnRpZmljYXRlIGFzIHBhcnQgb2YgdGhlIElLRSBuZWdvdGlhdGlvbi4gIFRoZSBGRSB2 YWxpZGF0ZXMgDQogICAgICAgICBzaWduYXR1cmUsIGNoZWNrcyB0aGUgZXhwaXJhdGlvbiBkYXRl LCBjaGVja3MgaWYgdGhlIA0KICAgICAgICAgY2VydGlmaWNhdGUgaGFzIGJlZW4gcmV2b2tlZC4g DQogICAgICAgICAzKSBUaGUgQ0UgKG1hc3RlcikgZ2V0cyB0aGUgRkUgY2VydGlmaWNhdGUgYW5k IHBlcmZvcm1zIHRoZSANCiAgICAgICAgIHNhbWUgY2hlY2sgYXMgdGhlIEZFIGluIHN0ZXAgMiku IA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAgICAg ICAgICAgICAgICAgW1BhZ2UgMzZdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VT IEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAgICAg ICA0KSBJZiBhbnkgb2YgdGhlIGNoZWNrIGZhaWxzIGluIHN0ZXAgMikgb3Igc3RlcCAzKSwgdGhl IA0KICAgICAgICAgZW5kcG9pbnQgbXVzdCBnZW5lcmF0ZSBhbiBlcnJvciBtZXNzYWdlIGFuZCBh Ym9ydC4gDQogICAgICAgICA1KSBBZnRlciBzdWNjZXNzZnVsIG11dHVhbCBhdXRoZW50aWNhdGlv biwgSVBzZWMgc2Vzc2lvbiBpcyANCiAgICAgICAgIGVzdGFibGlzaGVkIGJldHdlZW4gdGhlIENF IGFuZCBGRS4gDQogICAgICAgICA2KSBUaGUgRkUgc2VuZHMgYSAiam9pbiBORSIgbWVzc2FnZSB0 byBDRS4gIE5vIFNBREIgZW50cnkgaXMgDQogICAgICAgICBjcmVhdGVkIGluIEZFIHlldC4gDQog ICAgICAgICA3KSBUaGUgRkUgYW5kIENFIHVzZSB0aGUgSVBzZWMgc2Vzc2lvbiBmb3IgZnVydGhl ciANCiAgICAgICAgIGNvbW11bmljYXRpb24uIA0KICAgICAgDQogICAgRkUgTWFuYWdlciBvciBD RSBNYW5hZ2VyIG9yIG90aGVyIGNlbnRyYWwgY29tcG9uZW50IGNhbiBiZSB1c2VkIGFzIA0KICAg IENBIGZvciB2YWxpZGF0aW5nIENFIGFuZCBGRSBjZXJ0aWZpY2F0ZXMgZHVyaW5nIHRoZSBJS0Ug cHJvY2Vzcy4gICANCiAgICBBbHRlcm5hdGl2ZWx5LCBkdXJpbmcgdGhlIHByZS1hc3NvY2lhdGlv biBwaGFzZSwgdGhlIENFIGFuZCBGRSBjYW4gDQogICAgYmUgY29uZmlndXJlZCBkaXJlY3RseSB3 aXRoIHRoZSByZXF1aXJlZCBpbmZvcm1hdGlvbiBzdWNoIGFzIA0KICAgIGNlcnRpZmljYXRlcyBv ciBwYXNzd29yZHMgZXRjIGRlcGVuZGluZyB1cG9uIHRoZSB0eXBlIG9mIA0KICAgIGF1dGhlbnRp Y2F0aW9uIHRoYXQgYWRtaW5pc3RyYXRvciB3YW50cyB0byBjb25maWd1cmUuICANCiAgICAgICAg ICANCiAgICBJbiB0aGUgY2FzZSBvZiBmYWlsLW92ZXIsIGl0IGlzIHRoZSByZXNwb25zaWJpbGl0 eSBvZiBhY3RpdmUgQ0UgYW5kIA0KICAgIHN0YW5kYnkgQ0UgdG8gc3luY2hyb25pemUgRm9yQ0VT IHN0YXRlcyBhbmQgSVBzZWMgc3RhdGVzIHRvIA0KICAgIG1pbmltaXplIHRoZSBzdGF0ZSByZWVz dGFibGlzaG1lbnQgZHVyaW5nIGZhaWwtb3Zlci4gIA0KICAgIEFsdGVybmF0aXZlbHksIHRoZSBG RSBuZWVkcyB0byBlc3RhYmxpc2ggZGlmZmVyZW50IElQc2VjIFNBIGR1cmluZyANCiAgICB0aGUg c3RhcnR1cCBvcGVyYXRpb24gaXRzZWxmIHdpdGggZWFjaCBDRS4gIFRoaXMgd2lsbCBtaW5pbWl6 ZSB0aGUgDQogICAgcGVyaW9kaWMgc3RhdGUgdHJhbnNmZXIgYWNyb3NzIElQc2VjIGxheWVyIHRo b3VnaCBGciAoQ0UtQ0UpIA0KICAgIEludGVyZmFjZS4gIA0KICAgICANCiA5LiBOb3JtYXRpdmUg UmVmZXJlbmNlcyANCiAgDQogICAgWzFdIEJha2VyLCBGLiwgIlJlcXVpcmVtZW50cyBmb3IgSVAg VmVyc2lvbiA0IFJvdXRlcnMiLCBSRkMgMTgxMiwgDQogICAgSnVuZSAxOTk1LiANCiAgICAgDQog ICAgWzJdIEZsb3lkLCBTLiwgIkNvbmdlc3Rpb24gQ29udHJvbCBQcmluY2lwbGVzIiwgUkZDIDI5 MTQsIFNlcHRlbWJlciANCiAgICAyMDAwLiANCiAgICAgDQogICAgWzNdIEtob3NyYXZpLCBILiBh bmQgQW5kZXJzb24sIFQuLCAiUmVxdWlyZW1lbnRzIGZvciBTZXBhcmF0aW9uIG9mIA0KICAgIElQ IENvbnRyb2wgYW5kIEZvcndhcmRpbmciLCBSRkMgMzY1NCwgTm92ZW1iZXIgMjAwMy4gDQogICAg IA0KIDEwLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgICANCiAgICBbNF0gQ2FzZSwgSi4s IGV0IGFsLiwgIkludHJvZHVjdGlvbiBhbmQgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIA0KICAg IGZvciBJbnRlcm5ldCBTdGFuZGFyZCBNYW5hZ2VtZW50IEZyYW1ld29yayIsIFJGQyAzNDEwLCBE ZWNlbWJlciANCiAgICAyMDAyLiANCiAgICAgDQogICAgWzVdIERhbmllbGUsIE0uIGV0IGFsLiwg IkFnZW50IEV4dGVuc2liaWxpdHkgKEFnZW50WCkgUHJvdG9jb2wgDQogICAgVmVyc2lvbiAxIiwg UkZDIDI3NDEsIEphbnVhcnkgMjAwMC4gDQogICAgIA0KICAgIFs2XSBDaGFuLCBLLiBldCBhbC4s ICJDT1BTIFVzYWdlIGZvciBQb2xpY3kgUHJvdmlzaW9uaW5nIChDT1BTLQ0KICAgIFBSKSIsIFJG QyAzMDg0LCBNYXJjaCAyMDAxLiANCiAgICAgDQogIA0KICANCiBZYW5nLCBldCBhbC4gICAgICBF eHBpcmVzIEp1bHkgICAgMjAwNCAgICAgICAgICAgICAgICAgICBbUGFnZSAzN10gIA0KDQogSW50 ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRnJhbWV3b3JrICAgICAgICAgICAgICAgICBKYW51 YXJ5IDIwMDQgDQogIA0KICANCiAgICBbN10gQ3JvdWNoLCBBLiBldCBhbC4sICJGb3JDRVMgQXBw bGljYWJpbGl0eSBTdGF0ZW1lbnQiLCB3b3JrIGluIA0KICAgIHByb2dyZXNzLCBKdW5lIDIwMDMs IDxkcmFmdC1pZXRmLWZvcmNlcy1hcHBsaWNhYmlsaXR5LTAyLnR4dD4uIA0KICAgICANCiAgICBb OF0gQW5kZXJzb24sIFQuIGFuZCBKLiBCdWVya2xlLCAiUmVxdWlyZW1lbnRzIGZvciB0aGUgRHlu YW1pYyANCiAgICBQYXJ0aXRpb25pbmcgb2YgU3dpdGNoaW5nIEVsZW1lbnRzIiwgUkZDIDM1MzIs IE1heSAyMDAzLiANCiAgICAgDQogICAgWzldIExlZWxhbml2YXMsIE0uIGV0IGFsLiwgIkdyYWNl ZnVsIFJlc3RhcnQgTWVjaGFuaXNtIGZvciBMYWJlbCANCiAgICBEaXN0cmlidXRpb24gUHJvdG9j b2wiLCBSRkMgMzQ3OCwgRmVicnVhcnkgMjAwMy4gDQogICAgIA0KICAgIFsxMF0gTW95LCBKLiBl dCBhbC4sICJHcmFjZWZ1bCBPU1BGIFJlc3RhcnQiLCBSRkMgMzYyMywgTm92ZW1iZXIgDQogICAg MjAwMy4gDQogICAgIA0KICAgIFsxMV0gU2FuZ2xpLCBTLiBldCBhbC4sICJHcmFjZWZ1bCBSZXN0 YXJ0IE1lY2hhbmlzbSBmb3IgQkdQIiwgd29yayANCiAgICBpbiBwcm9ncmVzcywgU2VwdGVtYmVy IDIwMDMsIDwgZHJhZnQtaWV0Zi1pZHItcmVzdGFydC0wOC50eHQ+LiANCiAgICAgDQogICAgWzEy XSBTaGFuZCwgTS4gYW5kIEwuIEdpbnNiZXJnLCAiUmVzdGFydCBTaWduYWxpbmcgZm9yIElTLUlT Iiwgd29yayANCiAgICBpbiBwcm9ncmVzcywgSnVseSAyMDAzLCA8ZHJhZnQtaWV0Zi1pc2lzLXJl c3RhcnQtMDQudHh0Pi4gDQogICAgIA0KICAgIFsxM10gRGllcmtzLCBULiBhbmQgQy4gQWxsZW4s ICJUaGUgVExTIFByb3RvY29sLCB2ZXJzaW9uIDEuMCIsIFJGQyANCiAgICAyMjQ2LCBKYW51YXJ5 IDE5OTkuIA0KICAgICANCiAgICBbMTRdIEtlbnQsIFMuIGFuZCBSLiBBdGtpbnNvbiwgIlNlY3Vy aXR5IEFyY2hpdGVjdHVyZSBmb3IgdGhlIA0KICAgIEludGVybmV0IFByb3RvY29sIiwgUkZDIDI0 MDEsIE5vdmVtYmVyIDE5OTguIA0KICAgICANCiAgICBbMTVdIEhhcmtpbnMsIEQuIGFuZCBELiBD YXJyZWwsICJUaGUgSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIChJS0UpICIsIA0KICAgIFJGQyAyNDA5 LCBOb3ZlbWJlciAxOTk4LiANCiAgICAgDQogICAgWzE2XSBCZWxsb3ZpbiwgUy4sICJHdWlkZWxp bmVzIGZvciBNYW5kYXRpbmcgdGhlIFVzZSBvZiBJcHNlYyIsIA0KICAgIHdvcmsgaW4gcHJvZ3Jl c3MsIE9jdG9iZXIgMjAwMywgPGRyYWZ0LWJlbGxvdmluLXVzZWlwc2VjLTAyLnR4dD4uIA0KICAg ICANCiAgICBbMTddIEhhcmRqb25vLCBULiBhbmQgV2VpcywgQi4gIlRoZSBNdWx0aWNhc3QgU2Vj dXJpdHkgDQogICAgQXJjaGl0ZWN0dXJlIiwgd29yayBpbiBwcm9ncmVzcywgTm92ZW1iZXIgMjAw MywgPGRyYWZ0LWlldGYtbXNlYy0NCiAgICBhcmNoLTA0LnR4dD4uIA0KICAgICANCiAgICBbMThd IFMuIEJlbGxvdmluLCBKLiBTY2hpbGxlciwgYW5kIEMuIEthdWZtYW4sICJTZWN1cml0eSBNZWNo YW5pc21zIA0KICAgIGZvciB0aGUgSW50ZXJuZXQiLCBSRkMgMzYzMSwgRGVjZW1iZXIsIDIwMDMu IA0KICAgICANCiAxMS4gQXV0aG9ycycgQWRkcmVzc2VzIA0KICANCiAgICBMLiBMaWx5IFlhbmcg DQogICAgSW50ZWwgQ29ycC4sIE1TIEpGMy0yMDYsIA0KICAgIDIxMTEgTkUgMjV0aCBBdmVudWUg DQogICAgSGlsbHNib3JvLCBPUiA5NzEyNCwgVVNBIA0KICAgIFBob25lOiArMSA1MDMgMjY0IDg4 MTMgDQogICAgRW1haWw6IGxpbHkubC55YW5nQGludGVsLmNvbSANCiAgICAgDQogICAgUmFtIERh bnR1IA0KICANCiAgDQogWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBKdWx5ICAgIDIwMDQgICAg ICAgICAgICAgICAgICAgW1BhZ2UgMzhdICANCg0KIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9y Q0VTIEZyYW1ld29yayAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA0IA0KICANCiAgDQogICAg RGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlLCANCiAgICBVbml2ZXJzaXR5IG9mIE5vcnRo IFRleGFzLCANCiAgICBEZW50b24sIFRYIDc2MjAzLCBVU0EgDQogICAgUGhvbmU6ICsxIDk0MCA1 NjUgMjgyMiANCiAgICBFbWFpbDogcmRhbnR1QHVudC5lZHUgDQogIA0KICAgIFRvZGQgQS4gQW5k ZXJzb24gDQogICAgSW50ZWwgQ29ycC4gDQogICAgMjExMSBORSAyNXRoIEF2ZW51ZSANCiAgICBI aWxsc2Jvcm8sIE9SIDk3MTI0LCBVU0EgDQogICAgUGhvbmU6ICsxIDUwMyA3MTIgMTc2MCANCiAg ICBFbWFpbDogdG9kZC5hLmFuZGVyc29uQGludGVsLmNvbSANCiAgICAgDQogICAgUmFtIEdvcGFs IA0KICAgIE5va2lhIFJlc2VhcmNoIENlbnRlciANCiAgICA1LCBXYXlzaWRlIFJvYWQsIA0KICAg IEJ1cmxpbmd0b24sIE1BIDAxODAzLCBVU0EgDQogICAgUGhvbmU6ICsxIDc4MSA5OTMgMzY4NSAN CiAgICBFbWFpbDogcmFtLmdvcGFsQG5va2lhLmNvbSANCiAgDQogMTIuIEludGVsbGVjdHVhbCBQ cm9wZXJ0eSBSaWdodCANCiAgICAgDQogICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVn YXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkgDQogICAgaW50ZWxsZWN0dWFsIHBy b3BlcnR5IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8gDQogICAgcGVy dGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2Ny aWJlZCBpbiANCiAgICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxp Y2Vuc2UgdW5kZXIgc3VjaCByaWdodHMgDQogICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWls YWJsZTsgbmVpdGhlciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IA0KICAgIGhhcyBtYWRlIGFu eSBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24gb24gDQog ICAgdGhlIElFVEYncyBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gc3RhbmRh cmRzLXRyYWNrIGFuZCANCiAgICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBi ZSBmb3VuZCBpbiBSRkMgMjAyNi4gIENvcGllcyANCiAgICBvZiBjbGFpbXMgb2YgcmlnaHRzIG1h ZGUgYXZhaWxhYmxlIGZvciBwdWJsaWNhdGlvbiBhbmQgYW55IA0KICAgIGFzc3VyYW5jZXMgb2Yg bGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4gDQogICAg YXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZv ciB0aGUgdXNlIA0KICAgIG9mIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudG9y cyBvciB1c2VycyBvZiB0aGlzIA0KICAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZy b20gdGhlIElFVEYgU2VjcmV0YXJpYXQuIA0KICAgICANCiAgICBUaGUgSUVURiBpbnZpdGVzIGFu eSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55IA0KICAgIGNv cHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJp ZXRhcnkgDQogICAgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJl IHJlcXVpcmVkIHRvIHByYWN0aWNlIA0KICAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVz cyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgDQogICAgRXhlY3V0aXZlIERpcmVjdG9yLiAN CiAgICAgDQogMTMuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudCANCiAgICAgICAgDQogICAgQ29w eXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMgUmVzZXJ2 ZWQuIA0KICAgICANCiAgDQogIA0KIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgSnVseSAgICAy MDA0ICAgICAgICAgICAgICAgICAgIFtQYWdlIDM5XSAgDQoNCiBJbnRlcm5ldCBEcmFmdCAgICAg ICAgIEZvckNFUyBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNCANCiAgDQog IA0KICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVk IGFuZCBmdXJuaXNoZWQgdG8gDQogICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0 IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gDQogICAgaXQgb3IgYXNzaXN0IGluIGl0 cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgDQogICAgcHVibGlzaGVk IGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlv biANCiAgICBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5v dGljZSBhbmQgdGhpcyANCiAgICBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNv cGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gIA0KICAgIEhvd2V2ZXIsIHRoaXMgZG9jdW1lbnQg aXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwgc3VjaCANCiAgICBhcyBieSBy ZW1vdmluZyB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5l dCANCiAgICBTb2NpZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBh cyBuZWVkZWQgZm9yIHRoZSANCiAgICBwdXJwb3NlIG9mIGRldmVsb3BpbmcgSW50ZXJuZXQgc3Rh bmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIA0KICAgIHByb2NlZHVyZXMgZm9yIGNvcHlyaWdodHMg ZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgDQogICAgbXVzdCBiZSBm b2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2VzIA0K ICAgIG90aGVyIHRoYW4gRW5nbGlzaC4gDQogICAgIA0KICAgIFRoZSBsaW1pdGVkIHBlcm1pc3Np b25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3QgYmUgDQogICAgcmV2 b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBvciBhc3NpZ25z LiANCiAgICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVp biBpcyBwcm92aWRlZCBvbiANCiAgICBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQg U09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIA0KICAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElT Q0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIA0KICAgIElNUExJRUQsIElOQ0xVRElO RyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiANCiAgICBU SEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5Z IElNUExJRUQgDQogICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBG T1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIiANCiAgICAgDQogIA0KICANCiBZYW5nLCBldCBhbC4g ICAgICBFeHBpcmVzIEp1bHkgICAgMjAwNCAgICAgICAgICAgICAgICAgICBbUGFnZSA0MF0gIA0K ------_=_NextPart_001_01C3DACD.ECAB4057-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 14 19:32:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23122 for ; Wed, 14 Jan 2004 19:32:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgvQd-0003lN-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 19:32:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgvPi-0003jw-00 for forces-archive@ietf.org; Wed, 14 Jan 2004 19:31:11 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AgvPT-0003hy-00 for forces-archive@IETF.ORG; Wed, 14 Jan 2004 19:30:55 -0500 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.00CA3FC7@cherry.ease.lsoft.com>; Wed, 14 Jan 2004 19:30:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68034612 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 14 Jan 2004 19:30:51 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 14 Jan 2004 19:30:50 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0F0W33f011805 for ; Thu, 15 Jan 2004 00:32:03 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0F0R5tc023094 for ; Thu, 15 Jan 2004 00:28:18 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011416304907886 for ; Wed, 14 Jan 2004 16:30:49 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 14 Jan 2004 16:30:49 -0800 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] framework v13 uploaded to IETF Thread-Index: AcPazM/YGyjKsgXZSuORuRDOUMq5YgAAAa1QAAo6DAA= X-OriginalArrivalTime: 15 Jan 2004 00:30:49.0164 (UTC) FILETIME=[D2EA88C0:01C3DAFE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8020B0618@orsmsx409.jf.intel.com> Date: Wed, 14 Jan 2004 16:30:48 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: framework v13 uploaded to IETF To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, This document has received good detailed review and=20 the changes made are clarifications and not major technical changes. =20 Please review the change list (included below) and comment before January 20 if there are any significant=20 issues with this document. Thanks, David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Yang, Lily L > Sent: Wednesday, January 14, 2004 10:41 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] framework v13 uploaded to IETF >=20 > Hi, all -- >=20 > This new version of framework incorporated the most recent=20 > comments from Avri, Jamal and others in the list. Below is a=20 > detailed log of the changes. There are numerous clarification=20 > and corrections, but no substantial change in the technical content. >=20 > This revision is uploaded to IETF and we feel ready to go RFC.=20 >=20 > Lily >=20 >=20 > <>=20 >=20 > -------------------------- summary of changes in v13=20 > -------------------------------------------- >=20 > #1) Section 1 Dfinition: > [Comment/Reason for change] To clarify that association is a=20 > per CE-FE concept. > [old] > Pre-association Phase - The period of time during=20 > which an FE Manager (see below) and a CE Manager (see below)=20 > are determining which FE and CE should be part of the same=20 > network element. > =20 > [new] > Pre-association Phase - The period of time during=20 > which an FE Manager (see below) and a CE Manager (see below)=20 > are determining whether an FE and a CE should be part of the=20 > same network element. It is possible for some elements of=20 > the NE to be in pre-association=20 > phase while other elements are in the post-association phase. >=20 > #2) Section 3. Achitecture > [Comment/Reason for change] To avoid the misconception that=20 > association is a NE system wide concept. > [deleted]=20 > There is no defined role for FE Manager and CE=20 > Manager in post-association phase, thus these logical=20 > components are not considered part of the ForCES NE.=20 >=20 > 3.2 at the end of 1st paragraph: > [Comment/Reason for change] clarify the impact of FE virtualization. > [old] > However, if FE virtualization results in dynamic=20 > resource change on FE during post-association phase, the FE=20 > model needs to be able to report such capability and the=20 > Protocol needs to be able to inform the CE of such change via=20 > asynchronous messages (see [3], Section 5, requirement #6). > [new] > However, if FE virtualization results in resource=20 > change taken from an existing FE (already participating in=20 > ForCES post-association phase), the ForCES Protocol needs to=20 > be able to inform the CE of such change via asynchronous=20 > messages (see [3], Section 5, requirement #6). >=20 >=20 > #3) 3.2 at the end of the 2nd paragraph > [Comment/Reason for change] To point out the behavior issue=20 > of FE accepting commands from multiple CEs. > [add] Unless otherwise configured or determined by a ForCEs=20 > Protocol exchange, each FE will process authorized=20 > incoming commands directed at it as it receives them=20 > on a first come first serve basis. =20 >=20 > #4) 4.1 Pre_association Phase > [Comment/Reason for change] same as #1) > [old] > Pre-association phase is the period of time during=20 > which an FE Manager and a CE Manager are determining which FE=20 > and CE should be part of the same network element. =20 >=20 > [new] > Pre-association phase is the period of time during=20 > which an FE Manager and a CE Manager are determining whether=20 > an FE and a CE should be part of the same network element. =20 >=20 > #5) 4.1.1 Fl Reference Point > [Comment/Reason for change] same as #1) > [old] > CE managers and FE managers may communicate across=20 > the Fl reference point in the pre-association phase in order=20 > to determine which CEs and FEs should communicate with each other. =20 > [new] > CE managers and FE managers may communicate across=20 > the Fl reference point in the pre-association phase in order=20 > to determine whether an individual CE and FE, or a set of CEs=20 > and FEs should be associated. =20 >=20 > #6) 4.2.2 Figure 9 > [Comment/Reason for change] inter-FE topology exchange is=20 > optional in the protocol. > deleted the inter-FE topology msg exchange. > at the beginning of last paragraph: > [old] > After the successful security handshake, the FE needs=20 > to inform the CE of its own capability and its topology in=20 > relation to other FEs.=20 > [new] > After the successful security handshake, the FE needs=20 > to inform the CE of its own capability and optionally its=20 > topology in relation to other FEs.=20 >=20 > #7) 4.2.2: end of last paragraph: > [Comment/Reason for change] more accurate wording. > [old] > Once FE starts accepting packets for processing, we=20 > say the association of this FE with its CE is now=20 > established. From then on, the CE and FE enter steady-state=20 > communication. > [new] > Once the necessary initial information is exchanged,=20 > the process of association is completed. Packet processing=20 > and forwarding at the FE cannot begin until association is=20 > established. =20 >=20 > #8) 4.2.5 FE Proxy > [Comment/Reason for change] Clarify that FE Proxy terminates=20 > ForCES itself. > [old] > In the case where a physical FE cannot implement=20 > (e.g., due to the lack of a general purpose CPU) the ForCES=20 > protocol directly, a proxy FE can be used to terminate the Fp=20 > reference point instead of the physical FE. ... It is also=20 > possible that one proxy act on behalf of multiple physical FEs. > [new]=20 > In the case where a physical FE cannot implement=20 > (e.g., due to the lack of a general purpose CPU) the ForCES=20 > protocol directly, a proxy FE can be used to terminate the Fp=20 > reference point instead of the physical FE. ... It is also=20 > possible that one proxy act on behalf of multiple physical FEs. >=20 > #9) 4.3 Association Re-establishment > [Comment/Reason for change] same as #1). > [old] > When an FE leaves or joins an existing NE that is=20 > already in post-association phase, the CE needs to be aware=20 > of the impact on FE topology and deals with the change accordingly. > [new] > When an FE leaves or joins an existing NE that is=20 > already in operation, the CE needs to be aware of the impact=20 > on FE topology and deals with the change accordingly. >=20 > #9.1) Section 7 Acknowledgement (updated) >=20 > #9.5) Merged the paragraph in old section 8.2.1 to the=20 > beginning of section 8 as part of the introduction. Following=20 > sections readjusted accordingly. >=20 > #10) 8.1.4 Attack during Fail Over > [Comment/Reason for change] Better wording. > [old] > Threat: ... A malicious node can take over as CE-B if=20 > such trusted relationship is not established during the fail-over.=20 > [new] > A malicious node can take over as CE-B if such=20 > trusted relationship has not been established prior or during=20 > the fail-over.=20 >=20 > #11) 8.1.8 > [Comment/Reason for change] Remove congestion control. > [old] > Requirement: Some sort of rate limiting mechanism=20 > MUST to be in place at both the FE and CE. Examples of such=20 > mechanisms include explicit rate limiters or congestion=20 > control algorithms. Rate Limiter SHOULD be configured at the=20 > FE for each message type that are being received through Fi/F=20 > interface. > [new] > Requirement: Some sort of rate limiting mechanism=20 > MUST to be in place at both the FE and CE. Rate Limiter=20 > SHOULD be configured at the FE for each message type that are=20 > being received through Fi/F interface. >=20 > #12) Section 9/10: references > Adding one more reference for security: > [18] S. Bellovin, J. Schiller, and C. Kaufman,=20 > "Security Mechanisms for the Internet", RFC 3631, December, 2003. > Updated most references to reflect the current status (RFC,=20 > or new revision/date) >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 15 16:21:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29189 for ; Thu, 15 Jan 2004 16:21:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhEvr-0002jN-00 for forces-archive@ietf.org; Thu, 15 Jan 2004 16:21:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhEut-0002h2-00 for forces-archive@ietf.org; Thu, 15 Jan 2004 16:20:39 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AhEtm-0002c4-00 for forces-archive@IETF.ORG; Thu, 15 Jan 2004 16:19:30 -0500 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.00CA5A17@cherry.ease.lsoft.com>; Thu, 15 Jan 2004 16:19:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68174160 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 15 Jan 2004 16:19:28 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 15 Jan 2004 16:09:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28392; Thu, 15 Jan 2004 16:09:25 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: dinaras@CNRI.RESTON.VA.US Message-ID: <200401152109.QAA28392@ietf.org> Date: Thu, 15 Jan 2004 16:09:24 -0500 Reply-To: Internet-Drafts@ietf.org 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-13.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 Filename : draft-ietf-forces-framework-13.txt Pages : 40 Date : 2004-1-15 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-13.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-13.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-13.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: <2004-1-15152316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-framework-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-framework-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-15152316.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 15 19:49:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11007 for ; Thu, 15 Jan 2004 19:49:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhIBJ-0000P0-00 for forces-archive@ietf.org; Thu, 15 Jan 2004 19:49:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhIAO-0000Nk-00 for forces-archive@ietf.org; Thu, 15 Jan 2004 19:48:53 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AhI9a-0000Lr-00 for forces-archive@IETF.ORG; Thu, 15 Jan 2004 19:48:02 -0500 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.00CA5FCA@cherry.ease.lsoft.com>; Thu, 15 Jan 2004 19:47:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68191869 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 15 Jan 2004 19:47:53 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 15 Jan 2004 19:47:52 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0G0n6Yg014401 for ; Fri, 16 Jan 2004 00:49:06 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0G0gMnm016283 for ; Fri, 16 Jan 2004 00:45:16 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011516475015264 for ; Thu, 15 Jan 2004 16:47:50 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Jan 2004 16:47:50 -0800 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] framework v13 uploaded to IETF Thread-Index: AcPazM/YGyjKsgXZSuORuRDOUMq5YgAAAa1QAD9cVtA= X-OriginalArrivalTime: 16 Jan 2004 00:47:50.0962 (UTC) FILETIME=[5E5E4920:01C3DBCA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Khosravi, Hormuzd M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B00191CEAA@orsmsx410.jf.intel.com> Date: Thu, 15 Jan 2004 16:47:50 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: framework v13 uploaded to IETF Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Lily et al. This looks pretty good to me for final submission. Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Yang, Lily L Sent: Wednesday, January 14, 2004 10:41 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] framework v13 uploaded to IETF Hi, all -- This new version of framework incorporated the most recent comments from Avri, Jamal and others in the list. Below is a detailed log of the changes. There are numerous clarification and corrections, but no substantial change in the technical content. This revision is uploaded to IETF and we feel ready to go RFC.=20 Lily <>=20 -------------------------- summary of changes in v13 -------------------------------------------- #1) Section 1 Dfinition: [Comment/Reason for change] To clarify that association is a per CE-FE concept. [old] Pre-association Phase - The period of time during which an FE Manager (see below) and a CE Manager (see below) are determining which FE and CE should be part of the same network element. =20 [new] Pre-association Phase - The period of time during which an FE Manager (see below) and a CE Manager (see below) are determining whether an FE and a CE should be part of the same network element. It is possible for some elements of the NE to be in pre-association=20 phase while other elements are in the post-association phase. #2) Section 3. Achitecture [Comment/Reason for change] To avoid the misconception that association is a NE system wide concept. [deleted]=20 There is no defined role for FE Manager and CE Manager in post-association phase, thus these logical components are not considered part of the ForCES NE.=20 3.2 at the end of 1st paragraph: [Comment/Reason for change] clarify the impact of FE virtualization. [old] However, if FE virtualization results in dynamic resource change on FE during post-association phase, the FE model needs to be able to report such capability and the Protocol needs to be able to inform the CE of such change via asynchronous messages (see [3], Section 5, requirement #6). [new] However, if FE virtualization results in resource change taken from an existing FE (already participating in ForCES post-association phase), the ForCES Protocol needs to be able to inform the CE of such change via asynchronous messages (see [3], Section 5, requirement #6). #3) 3.2 at the end of the 2nd paragraph [Comment/Reason for change] To point out the behavior issue of FE accepting commands from multiple CEs. [add] Unless otherwise configured or determined by a ForCEs Protocol exchange, each FE will process authorized incoming commands directed at it as it receives them on a first come first serve basis. =20 #4) 4.1 Pre_association Phase [Comment/Reason for change] same as #1) [old] Pre-association phase is the period of time during which an FE Manager and a CE Manager are determining which FE and CE should be part of the same network element. =20 [new] Pre-association phase is the period of time during which an FE Manager and a CE Manager are determining whether an FE and a CE should be part of the same network element. =20 #5) 4.1.1 Fl Reference Point [Comment/Reason for change] same as #1) [old] CE managers and FE managers may communicate across the Fl reference point in the pre-association phase in order to determine which CEs and FEs should communicate with each other. =20 [new] CE managers and FE managers may communicate across the Fl reference point in the pre-association phase in order to determine whether an individual CE and FE, or a set of CEs and FEs should be associated. =20 #6) 4.2.2 Figure 9 [Comment/Reason for change] inter-FE topology exchange is optional in the protocol. deleted the inter-FE topology msg exchange. at the beginning of last paragraph: [old] After the successful security handshake, the FE needs to inform the CE of its own capability and its topology in relation to other FEs.=20 [new] After the successful security handshake, the FE needs to inform the CE of its own capability and optionally its topology in relation to other FEs.=20 #7) 4.2.2: end of last paragraph: [Comment/Reason for change] more accurate wording. [old] Once FE starts accepting packets for processing, we say the association of this FE with its CE is now established. From then on, the CE and FE enter steady-state communication. [new] Once the necessary initial information is exchanged, the process of association is completed. Packet processing and forwarding at the FE cannot begin until association is established. =20 #8) 4.2.5 FE Proxy [Comment/Reason for change] Clarify that FE Proxy terminates ForCES itself. [old] In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES protocol directly, a proxy FE can be used to terminate the Fp reference point instead of the physical FE. ... It is also possible that one proxy act on behalf of multiple physical FEs. [new]=20 In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES protocol directly, a proxy FE can be used to terminate the Fp reference point instead of the physical FE. ... It is also possible that one proxy act on behalf of multiple physical FEs. #9) 4.3 Association Re-establishment [Comment/Reason for change] same as #1). [old] When an FE leaves or joins 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. [new] When an FE leaves or joins an existing NE that is already in operation, the CE needs to be aware of the impact on FE topology and deals with the change accordingly. #9.1) Section 7 Acknowledgement (updated) #9.5) Merged the paragraph in old section 8.2.1 to the beginning of section 8 as part of the introduction. Following sections readjusted accordingly. #10) 8.1.4 Attack during Fail Over [Comment/Reason for change] Better wording. [old] Threat: ... A malicious node can take over as CE-B if such trusted relationship is not established during the fail-over.=20 [new] A malicious node can take over as CE-B if such trusted relationship has not been established prior or during the fail-over.=20 #11) 8.1.8 [Comment/Reason for change] Remove congestion control. [old] Requirement: Some sort of rate limiting mechanism MUST to be in place at both the FE and CE. Examples of such mechanisms include explicit rate limiters or congestion control algorithms. Rate Limiter SHOULD be configured at the FE for each message type that are being received through Fi/F interface. [new] Requirement: Some sort of rate limiting mechanism MUST to be in place at both the FE and CE. Rate Limiter SHOULD be configured at the FE for each message type that are being received through Fi/F interface. #12) Section 9/10: references Adding one more reference for security: [18] S. Bellovin, J. Schiller, and C. Kaufman, "Security Mechanisms for the Internet", RFC 3631, December, 2003. Updated most references to reflect the current status (RFC, or new revision/date) From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 16 11:18:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19931 for ; Fri, 16 Jan 2004 11:18:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhWfp-0005jV-00 for forces-archive@ietf.org; Fri, 16 Jan 2004 11:18:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhWce-0005XT-00 for forces-archive@ietf.org; Fri, 16 Jan 2004 11:15:01 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AhWYv-0005IW-00 for forces-archive@IETF.ORG; Fri, 16 Jan 2004 11:11:09 -0500 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.00CA7608@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 11:10:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68293217 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 11:10:32 -0500 Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 11:10:32 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i0GGAVLS022449 for ; Fri, 16 Jan 2004 10:10:31 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <40080CF7.40259792@alcatel.com> Date: Fri, 16 Jan 2004 10:10:31 -0600 Reply-To: alex.audu@alcatel.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: framework v13 uploaded to IETF To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Lily, Is there supposed to be a change in the FE Proxy section? I can see the difference between the [old] and the [new] text. Sorry for the late notice. Regards, Alex. #8) 4.2.5 FE Proxy [Comment/Reason for change] Clarify that FE Proxy terminates ForCES itself. [old] In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES protocol directly, a proxy FE can be used to terminate the Fp reference point instead of the physical FE. ... It is also possible that one proxy act on behalf of multiple physical FEs. [new] In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES protocol directly, a proxy FE can be used to terminate the Fp reference point instead of the physical FE. ... It is also possible that one proxy act on behalf of multiple physical FEs. From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 16 12:25:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22151 for ; Fri, 16 Jan 2004 12:25:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXii-0001iZ-00 for forces-archive@ietf.org; Fri, 16 Jan 2004 12:25:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXhj-0001e1-00 for forces-archive@ietf.org; Fri, 16 Jan 2004 12:24:20 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AhXgj-0001Vz-00 for forces-archive@IETF.ORG; Fri, 16 Jan 2004 12:23:17 -0500 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.00CA7860@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 12:22:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68299426 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 12:22:41 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 12:22:41 -0500 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0GHOsXL009525; Fri, 16 Jan 2004 17:24:54 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0GHNMfw010732; Fri, 16 Jan 2004 17:23:23 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011609223724876 ; Fri, 16 Jan 2004 09:22:37 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jan 2004 09:22:37 -0800 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 v13 uploaded to IETF Thread-Index: AcPcS1LZTn1k5TFtTZW2mQS9r1dDzwACPE8A X-OriginalArrivalTime: 16 Jan 2004 17:22:37.0283 (UTC) FILETIME=[56301B30:01C3DC55] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB10F@orsmsx410.jf.intel.com> Date: Fri, 16 Jan 2004 09:22:36 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: framework v13 uploaded to IETF Comments: To: alex.audu@alcatel.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Oops! I knew that it would be a miracle if all those cut and paste would = always land them in the right spots ... I am also impressed that somebody actually read the list carefully! Good = catch! Here is what it is supposed to be: [old] In the case where a physical FE cannot implement (e.g., due to=20 the lack of a general purpose CPU) the ForCES protocol=20 directly, a proxy FE can be used in the middle of Fp reference point =20 ... In such an implementation, the combination of the proxy and the=20 physical FE becomes one logical FE entity.=20 =20 [new] In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES protocol=20 directly, a proxy FE can be used to terminate the Fp reference point = instead of the physical FE. ... In such an implementation, the combination of the = proxy=20 and the physical FE becomes one logical FE entity.=20 It is also possible that one proxy act on behalf of multiple physical FEs. =20 Lily > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Alex Audu > Sent: Friday, January 16, 2004 8:11 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: framework v13 uploaded to IETF >=20 >=20 > Hi Lily, >=20 > Is there supposed to be a change in the FE Proxy section? I=20 > can see the > difference > between the [old] and the [new] text. Sorry for the late notice. >=20 > Regards, > Alex. >=20 >=20 > #8) 4.2.5 FE Proxy > [Comment/Reason for change] Clarify that FE Proxy terminates ForCES > itself. > [old] > In the case where a physical FE cannot implement (e.g., due to > the lack of a general purpose CPU) the ForCES protocol=20 > directly, a proxy >=20 > FE can be used to terminate the Fp reference point instead of the > physical FE. ... It is also possible that one proxy act on behalf of > multiple physical FEs. > [new] > In the case where a physical FE cannot implement (e.g., due to > the lack of a general purpose CPU) the ForCES protocol=20 > directly, a proxy >=20 > FE can be used to terminate the Fp reference point instead of the > physical FE. ... It is also possible that one proxy act on behalf of > multiple physical FEs. >=20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 16 16:01:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28904 for ; Fri, 16 Jan 2004 16:01:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahb5p-0004cN-00 for forces-archive@ietf.org; Fri, 16 Jan 2004 16:01:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahb2v-0004Ts-00 for forces-archive@ietf.org; Fri, 16 Jan 2004 15:58:27 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ahb1d-0004OZ-00 for forces-archive@IETF.ORG; Fri, 16 Jan 2004 15:57:07 -0500 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.00CA7B8D@cherry.ease.lsoft.com>; Fri, 16 Jan 2004 15:56:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68316411 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 16 Jan 2004 15:56:32 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 16 Jan 2004 15:56:31 -0500 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0GKwiXL009612 for ; Fri, 16 Jan 2004 20:58:44 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0GKupg4002980 for ; Fri, 16 Jan 2004 20:57:12 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011612562621479 for ; Fri, 16 Jan 2004 12:56:26 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jan 2004 12:56:26 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3DC73.349377BB" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: yes Thread-Topic: FE Capabilities and attributes section of the model draft Thread-Index: AcPcczQI+nuZKQUMRdCHYugKHe3cKQ== X-OriginalArrivalTime: 16 Jan 2004 20:56:26.0273 (UTC) FILETIME=[34DCA110:01C3DC73] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Deleganes, Ellen M" Message-ID: <9CB758BBEE58754F8F33234D75B9F4B0012625CA@orsmsx410.jf.intel.com> Date: Fri, 16 Jan 2004 12:56:25 -0800 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: FE Capabilities and attributes section of the model draft To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=HTML_20_30,HTML_MESSAGE, HTML_TAG_BALANCE_BODY autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DC73.349377BB Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C3DC73.349377BB" ------_=_NextPart_002_01C3DC73.349377BB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This is the FE Capabilities and attributes section of the model draft for general working group review. This section was contributed by Joel Halpern and is posted as it was incorporated into section 6 of the FE model draft. Since the model draft is getting rather long and reviewing the entire document is a rather onerous task, sections will be posted for working group review by either the authors or by me prior to sending out the full updated draft for comments. =20 Regards, Ellen =20 Ellen Deleganes Intel Corporation MS JF3-206 5200 NE Elam Young Parkway Hillsboro, OR 97124 =20 Tel: (503) 712-4173 Fax: (503) 264-4230 =20 ------_=_NextPart_002_01C3DC73.349377BB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

This is the FE Capabilities and attributes section of = the model draft for general working group review. This section was = contributed by Joel Halpern and is posted as it was incorporated into section 6 of the = FE model draft. Since the model draft is getting rather long and reviewing = the entire document is a rather onerous task, sections will be posted for = working group review by either the authors or by me prior to sending out the = full updated draft for comments.

 

Regards,

Ellen

 

Ellen = Deleganes

Intel = Corporation MS JF3-206

5200 NE = Elam Young Parkway

Hillsboro, OR 97124

 

Tel:  (503) 712-4173

Fax: (503) = 264-4230

 

=00 ------_=_NextPart_002_01C3DC73.349377BB-- ------_=_NextPart_001_01C3DC73.349377BB Content-Type: text/plain; name="FEattributes.txt" Content-Transfer-Encoding: base64 Content-Description: FEattributes.txt Content-Disposition: attachment; filename="FEattributes.txt" Content-Transfer-Encoding: base64 MS4gRkUgQXR0cmlidXRlcyBhbmQgQ2FwYWJpbGl0aWVzDQoNCkEgRm9yQ0VTIGZvcndhcmRpbmcg ZWxlbWVudCBoYW5kbGVzIHRyYWZmaWMgb24gYmVoYWxmIG9mIA0KYSBGb3JDRVMgY29udHJvbCBl bGVtZW50LiAgV2hpbGUgdGhlIHN0YW5kYXJkcyB3aWxsIA0KZGVzY3JpYmUgdGhlIHByb3RvY29s IGFuZCBtZWNoYW5pc21zIGZvciB0aGlzIGNvbnRyb2wsIA0KZGlmZmVyZW50IGltcGxlbWVudGF0 aW9ucyBhbmQgZGlmZmVyZW50IGluc3RhbmNlcyB3aWxsIA0KaGF2ZSBkaWZmZXJlbnQgY2FwYWJp bGl0aWVzLiAgVGhlIENFIG5lZWRzIHRvIGJlIGFibGUgdG8gDQpkZXRlcm1pbmUgd2hhdCBlYWNo IGluc3RhbmNlIGl0IGlzIHJlc3BvbnNpYmxlIGZvciBpcyANCmFjdHVhbGx5IGNhcGFibGUgb2Yg ZG9pbmcuICBBcyBzdGF0ZWQgcHJldmlvdXNseSwgdGhpcyANCmlzIGFuIGFwcHJveGltYXRpb24u ICBUaGUgQ0UgaXMgZXhwZWN0ZWQgdG8gYmUgcHJlcGFyZWQgDQp0byBjb3BlIHdpdGggZXJyb3Jz IGluIHJlcXVlc3RzIGFuZCB2YXJpYXRpb25zIGluIGRldGFpbCANCm5vdCBjYXB0dXJlZCBieSB0 aGUgY2FwYWJpbGl0aWVzIGluZm9ybWF0aW9uIGFib3V0IGFuIA0KRkUuDQoNCkluIGFkZGl0aW9u IHRvIGl0cyBjYXBhYmlsaXRpZXMsIGFuIEZFIHdpbGwgaGF2ZSBzb21lIA0KaW5mb3JtYXRpb24g KGF0dHJpYnV0ZXMpIHRoYXQgY2FuIGJlIHVzZWQgaW4gDQp1bmRlcnN0YW5kaW5nIGFuZCBjb250 cm9sbGluZyB0aGUgZm9yd2FyZGluZyBvcGVyYXRpb25zLiAgDQpTb21lIG9mIHRoZSBhdHRyaWJ1 dGVzIHdpbGwgYmUgcmVhZCBvbmx5LCB3aGlsZSBvdGhlcnMgDQp3aWxsIGFsc28gYmUgd3JpdGVh YmxlLg0KDQpUaGUgRm9yQ0VTIHByb3RvY29sIHdpbGwgZGVmaW5lIHRoZSBhY3R1YWwgbWVjaGFu aXNtIGZvciANCmdldHRpbmcgYW5kIHNldHRpbmcgYXR0cmlidXRlIGluZm9ybWF0aW9uLiAgVGhp cyBtb2RlbCANCmRlZmluZXMgdGhlIHN0YXJ0aW5nIHNldCBvZiBpbmZvcm1hdGlvbiB0aGF0IHdp bGwgYmUgDQphdmFpbGFibGUuICBUaGlzIGRlZmluaXRpb24gaW5jbHVkZXMgdGhlIHNlbWFudGlj cyBhbmQgDQp0aGUgc3RydWN0dXJpbmcgb2YgdGhlIGluZm9ybWF0aW9uLiAgSXQgYWxzbyBwcm92 aWRlcyANCmZvciBleHRlbnNpb25zIHRvIHRoaXMgaW5mb3JtYXRpb24uDQoNCkluIG9yZGVyIHRv IGNyaXNwbHkgZGVmaW5lIHRoZSBhdHRyaWJ1dGUgaW5mb3JtYXRpb24gYW5kIA0Kc3RydWN0dXJl LCB0aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgYXR0cmlidXRlcyBhcyANCmluZm9ybWF0aW9u IGluIGFuIGFic3RyYWN0IFhNTCBkb2N1bWVudC4gIENvbmNlcHR1YWxseSwgDQplYWNoIEZFIGNv bnRhaW5zIHN1Y2ggYSBkb2N1bWVudC4gIFRoZSBkb2N1bWVudCANCnN0cnVjdHVyZSBpcyBkZWZp bmVkIGJ5IHRoZSBYTUwgU2NoZW1hIGNvbnRhaW5lZCBpbiB0aGlzIA0KbW9kZWwuICBPcGVyYXRp b25hbGx5LCB0aGUgRm9yQ0VTIHByb3RvY29sIHJlZmVycyB0byANCmluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGF0IGRvY3VtZW50IGluIG9yZGVyIHRvIHJlYWQgDQpvciB3cml0ZSBGRSBhdHRy aWJ1dGVzIGFuZCBjYXBhYmlsaXRpZXMuICBUaGlzIGRvY3VtZW50IA0KaXMgYW4gYWJzdHJhY3Qg cmVwcmVzZW50YXRpb24gb2YgdGhlIGluZm9ybWF0aW9uLiAgVGhlcmUgDQppcyBubyByZXF1aXJl bWVudCB0aGF0IHN1Y2ggYSBkb2N1bWVudCByZWFsbHkgZXhpc3QgaW4gDQptZW1vcnkuICBVbmxl c3MgdGhlIEZvckNFUyBwcm90b2NvbCBjYWxscyBmb3IgdHJhbnNmZXIgDQpvZiB0aGUgaW5mb3Jt YXRpb24gaW4gWE1MLCB0aGUgaW5mb3JtYXRpb24gaXMgbm90IA0KcmVxdWlyZWQgdG8gZXZlciBi ZSByZXByZXNlbnRlZCBpbiB0aGUgRkUgaW4gWE1MLiAgVGhlIA0KWE1MIHNjaGVtYSBzZXJ2ZXMg b25seSB0byBpZGVudGlmeSB0aGUgZWxlbWVudHMgYW5kIA0Kc3RydWN0dXJlIG9mIHRoZSBpbmZv cm1hdGlvbi4NCg0KVGhlIHN1YnNlY3Rpb25zIGluIHRoaXMgcGFydCBvZiB0aGUgZG9jdW1lbnQg cHJvdmlkZSB0aGUgDQpkZXRhaWxzIG9uIHRoaXMgYXNwZWN0IG9mIHRoZSBGRSBtb2RlbC4gIDYu MSBnaXZlcyB0aGUgDQpYTUwgc2NoZW1hIGZvciB0aGUgYWJzdHJhY3QgRkUgYXR0cmlidXRlIGRv Y3VtZW50LiAgNi4yIA0KZWxhYm9yYXRlcyBvbiBlYWNoIG9mIHRoZSBkZWZpbmVkIGF0dHJpYnV0 ZXMgb2YgdGhlIEZFLCANCmZvbGxvd2luZyB0aGUgaGllcmFyY2h5IG9mIHRoZSBzY2hlbWEuICA2 LjMgcHJvdmlkZXMgYW4gDQpleGFtcGxlIFhNTCBGRSBhdHRyaWJ1dGUgZG9jdW1lbnQgdG8gY2xh cmlmeSB0aGUgbWVhbmluZyANCm9mIDYuMSBhbmQgNi4yLiANCg0KMS4xLiBGRSBBdHRyaWJ1dGUg RkUgU2NoZW1hDQoxLjIuDQo8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0K PHhzZDpzY2hlbWEgDQp4bWxuczp4c2Q9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1h Ij4NCg0KIDx4c2Q6YW5ub3RhdGlvbj4NCiAgPHhzZDpkb2N1bWVudGF0aW9uIHhtbDpsYW5nPSJl biI+DQogICBTY2hlbWEgZm9yIHRoZSBBYnN0cmFjdCBGRSBBdHRyaWJ1dGVzIGFuZCANCkNhcGFi aWxpdGllcyBEb2N1bWVudA0KICA8L3hzZDpkb2N1bWVudGF0aW9uPg0KDQogPHhzZDplbGVtZW50 IG5hbWU9IkZFRG9jdW1lbnQiPg0KICA8eHNkOmNvbXBsZXhUeXBlPg0KICAgPHhzZDpzZXF1ZW5j ZT4NCiAgICA8eHNkOmVsZW1lbnQgbmFtZT0iRkVDYXBhYmlsaXRpZXMiIA0KdHlwZT0iRkVDYXBh YmlsaXRpZXNUeXBlIg0KICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAg ICA8eHNkOmVsZW1lbnQgbmFtZT0iRkVBdHRyaWJ1dGVzIiANCnR5cGU9IkZFQXR0cmlidXRlc1R5 cGUiDQogICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgPC94c2Q6c2Vx dWVuY2U+DQogIDwveHNkOmNvbXBsZXhUeXBlPg0KIDwveHNkOmVsZW1lbnQ+DQoNCiA8eHNkOmNv bXBsZXhUeXBlIG5hbWU9IkZFQ2FwYWJpbGl0aWVzVHlwZSI+DQogIDx4c2Q6c2VxdWVuY2U+DQog ICA8eHNkOmVsZW1lbnQgbmFtZT0iTW9kaWZpYWJsZUxGQlRvcG9sb2d5IiANCnR5cGU9InhzZDpi b29sZWFuIg0KICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0KICAgPHhzZDpl bGVtZW50IG5hbWU9IlN1cHBvcnRlZExGQnMiIG1pbk9jY3Vycz0iMCIgDQptYXhPY2N1cnM9IjEi Pg0KICAgIDx4c2Q6Y29tcGxleFR5cGU+DQogICAgIDx4c2Q6c2VxdWVuY2U+DQogICAgICA8eHNk OmVsZW1lbnQgbmFtZT0iU3VwcG9ydGVkTEZCIiANCnR5cGU9IlN1cHBvcnRlZExGQlR5cGUiDQog ICAgICAgICAgIG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgPC94 c2Q6c2VxdWVuY2U+DQogICAgPC94c2Q6Y29tcGxleFR5cGU+DQogICA8L3hzZDplbGVtZW50Pg0K ICAgPHhzZDplbGVtZW50IG5hbWU9IlN1cHBvcnRlZEF0dHJpYnV0ZXMiIA0KICAgICAgICB0eXBl PSJTdXBwb3J0ZWRBdHRyaWJ1dGVzVHlwZSIgDQogICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2Nj dXJzPSIxIi8+DQogIDwveHNkOnNlcXVlbmNlPg0KIDwveHNkOmNvbXBsZXhUeXBlPg0KDQogPHhz ZDpjb21wbGV4VHlwZSBuYW1lPSJTdXBwb3J0ZWRMRkJUeXBlIj4NCiAgPHhzZDpzZXF1ZW5jZT4N CiAgIDwhLS0gdGhlIG5hbWUgb2YgYSBzdXBwb3J0ZWQgTEZCIC0tPg0KICAgPHhzZDplbGVtZW50 IG5hbWU9IkxGQk5hbWUiIHR5cGU9InhzZDpOTVRPS0VOIi8+DQogICA8IS0tIGhvdyBtYW55IG9m IHRoaXMgTEZCIGNsYXNzIGNhbiBleGlzdCAtLT4NCiAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJMRkJP Y2N1cnJlbmNlTGltaXQiDQogICAgICAgIHR5cGU9InhzZDpub25OZWdhdGl2ZUludGVnZXIiIG1p bk9jY3Vycz0iMCIgDQptYXhPY2N1cnM9IjEiLz4NCiAgIDwhLS0gRm9yIGVhY2ggcG9ydCBncm91 cCwgaG93IG1hbnkgcG9ydHMgY2FuIGV4aXN0IC0tDQo+DQogICA8eHNkOmVsZW1lbnQgbmFtZT0i UG9ydEdyb3VwTGltaXRzIiBtaW5PY2N1cnM9IjAiIA0KbWF4T2NjdXJzPSIxIj4NCiAgICA8eHNk OmNvbXBsZXhUeXBlPg0KICAgICAgICA8eHNkOnNlcXVlbmNlPg0KICAgICAgPHhzZDplbGVtZW50 IG5hbWU9IlBvcnRHcm91cExpbWl0IiBtaW5PY2N1cnM9IjAiIA0KICAgICAgICAgICBtYXhPY2N1 cnM9InVuYm91bmRlZCI+DQogICAgICAgPHhzZDpjb21wbGV4VHlwZT4NCiAgICAgICAgPHhzZDpz ZXF1ZW5jZT4NCiAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJQb3J0R3JvdXBOYW1lIiANCnR5 cGU9InhzZDpOTVRPS0VOIi8+DQogICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iTWluUG9ydENv dW50IiAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICB0eXBlPSJ4c2Q6bm9uTmVn YXRpdmVJbnRlZ2VyIg0KICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIv Pg0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Ik1heFBvcnRDb3VudCIgDQogICAgICAgICAg ICAgIHR5cGU9InhzZDpub25OZWdhdGl2ZUludGVnZXIiDQogICAgICAgICAgICAgIG1pbk9jY3Vy cz0iMCIgbWF4T2NjdXJzPSIxIi8+DQogICAgICAgIDwveHNkOnNlcXVlbmNlPg0KICAgICAgIDwv eHNkOmNvbXBsZXhUeXBlPg0KICAgICAgPC94c2Q6ZWxlbWVudD4NCiAgICAgPC94c2Q6c2VxdWVu Y2U+DQogICAgPC94c2Q6Y29tcGxleFR5cGU+DQogICA8L3hzZDplbGVtZW50Pg0KICAgPCEtLSBm b3IgdGhlIG5hbWVkIExGQiBDbGFzcywgdGhlIExGQiBDbGFzc2VzIGl0IG1heSANCmZvbGxvdyAt LT4NCiAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJDYW5PY2N1ckFmdGVycyIgbWluT2NjdXJzPSIwIiAN Cm1heE9jY3Vycz0iMSI+DQogICAgPHhzZDpjb21wbGV4VHlwZT4NCiAgICAgPHhzZDpzZXF1ZW5j ZT4NCiAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJDYW5PY2N1ckFmdGVyIg0KICAgICAgICAgICB0 eXBlPSJMRkJBZGphY2VuY3lMaW1pdFR5cGUiDQogICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgPC94c2Q6c2VxdWVuY2U+DQogICAgPC94c2Q6Y29t cGxleFR5cGU+DQogICA8L3hzZDplbGVtZW50Pg0KIA0KICAgPCEtLSBmb3IgdGhlIG5hbWVkIExG QiBDbGFzcywgd2hpY2ggTEZCIENsYXNzZXMgbWF5IA0KZm9sbG93IC0tPg0KICAgPHhzZDplbGVt ZW50IG5hbWU9IkNhbk9jY3VyQmVmb3JlcyIgbWluT2NjdXJzPSIwIiANCm1heE9jY3Vycz0iMSI+ DQogICAgPHhzZDpjb21wbGV4VHlwZT4NCiAgICAgPHhzZDpzZXF1ZW5jZT4NCiAgICAgIDx4c2Q6 ZWxlbWVudCBuYW1lPSJDYW5PY2N1ckJlZm9yZSINCiAgICAgICAgICAgdHlwZT0iTEZCQWRqYWNl bmN5TGltaXRUeXBlIg0KICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3Vu ZGVkIi8+DQogICAgIDwveHNkOnNlcXVlbmNlPg0KICAgIDwveHNkOmNvbXBsZXhUeXBlPg0KICAg PC94c2Q6ZWxlbWVudD4NCiAgIDwhLS0gaW5mb3JtYXRpb24gZGVmaW5lZCBieSB0aGUgQ2xhc3Mg RGVmaW5pdGlvbiAtLT4NCiAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJMRkJDbGFzc0NhcGFiaWxpdGll cyIgDQp0eXBlPSJ4c2Q6YW55VHlwZSINCiAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9 IjEiLz4NCiAgPC94c2Q6c2VxdWVuY2U+DQogPC94c2Q6Y29tcGxleFR5cGU+DQoNCiA8eHNkOmNv bXBsZXhUeXBlIG5hbWU9IkxGQkFkamFjZW5jeUxpbWl0VHlwZSI+DQogIDx4c2Q6c2VxdWVuY2U+ DQogICA8eHNkOmVsZW1lbnQgbmFtZT0iTmVpZ2hib3JMRkIiIHR5cGU9InhzZDpOTVRPS0VOIi8+ DQogICA8eHNkOmVsZW1lbnQgbmFtZT0idmlhUG9ydCIgdHlwZT0ieHNkOk5NVE9LRU4iDQogICAg ICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgPC94c2Q6c2VxdWVu Y2U+DQogPC94c2Q6Y29tcGxleFR5cGU+DQoNCiA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9IlN1cHBv cnRlZEF0dHJpYnV0ZXNUeXBlIj4NCiAgPHhzZDpzZXF1ZW5jZT4NCiAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJTdXBwb3J0ZWRBdHRyaWJ1dGUiDQogICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz PSJ1bmJvdW5kZWQiPg0KICAgIDx4c2Q6Y29tcGxleFR5cGU+DQogICAgIDx4c2Q6c2VxdWVuY2U+ DQogICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iQXR0cmlidXRlTmFtZSIgDQp0eXBlPSJ4c2Q6Tk1U T0tFTiIvPg0KICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkFjY2Vzc01vZGVzIiANCnR5cGU9Inhz ZDpOTVRPS0VOIi8+DQogICAgIDwveHNkOnNlcXVlbmNlPg0KICAgIDwveHNkOmNvbXBsZXhUeXBl Pg0KICAgPC94c2Q6ZWxlbWVudD4NCiAgPC94c2Q6c2VxdWVuY2U+DQogPC94c2Q6Y29tcGxleFR5 cGU+DQoNCiA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9IkZFQXR0cmlidXRlc1R5cGUiPg0KICA8eHNk OnNlcXVlbmNlPg0KICAgPHhzZDplbGVtZW50IG5hbWU9IlZlbmRvciIgdHlwZT0ieHNkOnN0cmlu ZyIgDQptaW5PY2N1cnM9IjAiLz4NCiAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJNb2RlbCIgdHlwZT0i eHNkOnN0cmluZyIgDQptaW5PY2N1cnM9IjAiLz4NCiAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJGRVN0 YXR1cyIgdHlwZT0iRkVTdGF0ZVR5cGUiIA0KbWluT2NjdXJzPSIwIi8+DQogICA8eHNkOmVsZW1l bnQgbmFtZT0iTEZCSW5zdGFuY2VzIiBtaW5PY2N1cnM9IjAiIA0KbWF4T2NjdXJzPSIxIj4NCiAg ICA8eHNkOmNvbXBsZXhUeXBlPg0KICAgICA8eHNkOnNlcXVlbmNlPg0KICAgICAgPHhzZDplbGVt ZW50IG5hbWU9IkxGQkluc3RhbmNlIiBtaW5PY2N1cnM9IjAiDQogICAgICAgICAgIG1heE9jY3Vy cz0idW5ib3VuZGVkIj4NCiAgICAgICA8eHNkOmNvbXBsZXhUeXBlPg0KICAgICAgICA8eHNkOnNl cXVlbmNlPg0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkxGQkNsYXNzTmFtZSIgDQp0eXBl PSJ4c2Q6Tk1UT0tFTiIvPiI+DQogICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iTEZCSW5zdGFu Y2VJRCIgDQp0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiI+DQogICAgICAgIDwveHNkOnNlcXVlbmNlPg0K ICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPg0KICAgICAgPC94c2Q6ZWxlbWVudD4NCiAgICAgPC94 c2Q6c2VxdWVuY2U+DQogICAgPC94c2Q6Y29tcGxleFR5cGU+DQogICA8L3hzZDplbGVtZW50Pg0K ICAgPHhzZDplbGVtZW50IG5hbWU9IkxGQlRvcG9sb2d5IiANCnR5cGU9IkxGQlRvcG9sb2d5VHlw ZSINCiAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgIDx4c2Q6ZWxlbWVu dCBuYW1lPSJGRUNvbmZpZ3VyZWROZWlnaGJvcnMiIA0KbWluT2NjdXJzPSIwIg0KICAgICAgICBt YXhPY2N1cnM9IjEiPg0KICAgIDx4c2Q6Y29tcGxleFR5cGU+DQogICAgIDx4c2Q6c2VxdWVuY2U+ DQogICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iRkVDb25maWd1cmVkTmVpZ2hib3IiDQogICAgICAg ICAgIHR5cGU9IkZFQ29uZmlndXJlZE5laWdoYm9yVHlwZSIgDQogICAgICAgICAgIG1pbk9jY3Vy cz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgPC94c2Q6c2VxdWVuY2U+DQogICAg PC94c2Q6Y29tcGxleFR5cGU+DQogICA8L3hzZDplbGVtZW50Pg0KICA8L3hzZDpzZXF1ZW5jZT4N CiA8L3hzZDpjb21wbGV4VHlwZT4NCg0KIDx4c2Q6Y29tcGxleFR5cGUgbmFtZT0iTEZCVG9wb2xv Z3lUeXBlIj4NCiAgPHhzZDpzZXF1ZW5jZT4NCiAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJMRkJMaW5r IiBtaW5PY2N1cnM9IjAiIA0KbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPg0KICAgIDx4c2Q6Y29tcGxl eFR5cGU+DQogICAgIDx4c2Q6c2VxdWVuY2U+DQogICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iRnJv bUxGQklEIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPg0KICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkZy b21Qb3J0R3JvdXAiIA0KdHlwZT0ieHNkOk5NVE9LRU4iLz4NCiAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJGcm9tUG9ydEluZGV4IiAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgIHR5 cGU9InhzZDpub25OZWdhdGl2ZUludGVnZXIiLz4NCiAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJU b0xGQklEIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPg0KICAgICAgPHhzZDplbGVtZW50IG5hbWU9IlRv UG9ydEdyb3VwIiANCnR5cGU9InhzZDpOTVRPS0VOIi8+DQogICAgICA8eHNkOmVsZW1lbnQgbmFt ZT0iVG9Qb3J0SW5kZXgiIA0KICAgICAgICAgICB0eXBlPSJ4c2Q6bm9uTmVnYXRpdmVJbnRlZ2Vy Ii8+DQogICAgIDwveHNkOnNlcXVlbmNlPg0KICAgIDwveHNkOmNvbXBsZXhUeXBlPg0KICAgPC94 c2Q6ZWxlbWVudD4NCiAgPC94c2Q6c2VxdWVuY2U+DQogPC94c2Q6Y29tcGxleFR5cGU+DQoNCiA8 eHNkOmNvbXBsZXhUeXBlIG5hbWU9IkZFQ29uZmlndXJlZE5laWdoYm9yVHlwZSI+DQogIDx4c2Q6 c2VxdWVuY2U+DQogICA8eHNkOmVsZW1lbnQgbmFtZT0iTmVpZ2hib3JJRCIgdHlwZT0ieHNkOmFu eVR5cGUiLz4NCiAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJOZWlnaGJvckludGVyZmFjZSIgDQp0eXBl PSJ4c2Q6YW55VHlwZSIvPg0KICAgPHhzZDplbGVtZW50IG5hbWU9Ik5laWdoYm9yTmV0d29ya0Fk ZHJlc3MiIA0KdHlwZT0ieHNkOmFueVR5cGUiDQogICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2Nj dXJzPSIxIi8+DQogICA8eHNkOmVsZW1lbnQgbmFtZT0iTmVpZ2hib3JNQUNBZGRyZXNzIiANCnR5 cGU9InhzZDphbnlUeXBlIg0KICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPg0K ICA8L3hzZDpzZXF1ZW5jZT4NCiA8L3hzZDpjb21wbGV4VHlwZT4NCg0KIDwhLS0gVGhlIHZhbHVl cyBmb3IgdGhlIHNpbXBsZSBzdGF0ZSBhdHRyaWJ1dGUgLS0+DQogPCEtLSBUaGVzZSBzaG91bGQg cHJvYmFibHkgYmUgZGlyZWN0bHkgZW5jb2RhYmxlIGluIHRoZSANCi0tPg0KIDwhLS0gcHJvdG9j b2wgc28gdGhleSBtYXkgZW5kIHVwIG51bWVyaWMgaW5zdGVhZCBvZiANCnN0cmluZ3MgLS0+DQog PHhzZDpzaW1wbGVUeXBlIG5hbWU9IkZFU3RhdGVUeXBlIj4NCiAgPHhzZDpyZXN0cmljdGlvbiBi YXNlPSJ4c2Q6Tk1UT0tFTiI+DQogICA8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJBZG1pbkRpc2Fi bGUiLz4NCiAgIDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9Ik9wZXJEaXNhYmxlIi8+DQogICA8eHNk OmVudW1lcmF0aW9uIHZhbHVlPSJPcGVyRW5hYmxlIi8+DQogIDwveHNkOnJlc3RyaWN0aW9uPg0K IDwveHNkOnNpbXBsZVR5cGU+DQoNCjwveHNkOnNjaGVtYT4NCg0KMS4zLiBGRURvY3VtZW50DQox LjQuDQpBbiBpbnN0YW5jZSBvZiB0aGlzIGRvY3VtZW50IGNhcHR1cmVzIHRoZSBjYXBhYmlsaXRp ZXMgDQphbmQgRkUgbGV2ZWwgYXR0cmlidXRlIC8gc3RhdGUgaW5mb3JtYXRpb24gYWJvdXQgYSBn aXZlbiANCkZFLiAgQ3VycmVudGx5LCB0d28gZWxlbWVudHMgYXJlIGFsbG93ZWQgaW4gdGhlIA0K RkVEb2N1bWVudCwgRkVDYXBhYmlsaXRpZXMgYW5kIEZFQXR0cmlidXRlcy4gDQoNCkF0IHRoZSBt b21lbnQsIGFsbCBjYXBhYmlsaXR5IGFuZCBhdHRyaWJ1dGUgaW5mb3JtYXRpb24gDQppbiB0aGlz IGFic3RyYWN0IGRvY3VtZW50IGlzIGRlZmluZWQgYXMgb3B0aW9uYWwuICBXZSANCm1heSB3aXNo IHRvIG1hbmRhdGUgc3VwcG9ydCBmb3Igc29tZSBjYXBhYmlsaXR5IGFuZC9vciANCmF0dHJpYnV0 ZSBpbmZvcm1hdGlvbi4NCg0KSWYgYSBwcm90b2NvbCB1c2luZyBiaW5hcnkgZW5jb2Rpbmcgb2Yg dGhpcyBpbmZvcm1hdGlvbiANCmlzIGFkb3B0ZWQgYnkgdGhlIEZvckNFUyB3b3JraW5nIGdyb3Vw LCB0aGVuIGVhY2ggDQpyZWxldmFudCBlbGVtZW50IGRlZmluZWQgaW4gdGhlIHNjaGVtYSB3aWxs IGhhdmUgYSANCiJQcm90b2NvbEVuY29kaW5nIiBhdHRyaWJ1dGUgYWRkZWQsIHdpdGggYSAiRml4 ZWQiIHZhbHVlIA0KcHJvdmlkaW5nIHRoZSB2YWx1ZSB0aGF0IGlzIHVzZWQgaW4gdGhlIHByb3Rv Y29sIGZvciANCnRoYXQgZWxlbWVudCwgc28gdGhhdCB0aGUgWE1MIGFuZCB0aGUgb24gdGhlIHdp cmUgDQpwcm90b2NvbCBjYW4gYmUgY29ycmVsYXRlZC4gIA0KDQoxLjQuMS4gIEZFQ2FwYWJpbGl0 aWVzDQoxLjQuMi4gDQpUaGlzIGVsZW1lbnQsIHdoaWNoIGlmIGl0IG9jY3VycyBtdXN0IG9jY3Vy IG9ubHkgb25jZSwgDQpjb250YWlucyBhbGwgdGhlIGNhcGFiaWxpdHkgcmVsYXRlZCBpbmZvcm1h dGlvbiBhYm91dCANCnRoZSBGRS4gIENhcGFiaWxpdHkgaW5mb3JtYXRpb24gaXMgYWx3YXlzIGNv bnNpZGVyZWQgdG8gDQpiZSByZWFkLW9ubHkuDQoNClRoZSBjdXJyZW50bHkgZGVmaW5lZCBlbGVt ZW50cyBhbGxvd2VkIHdpdGhpbiB0aGUgDQpGRUNhcGFiaWxpdGllcyBlbGVtZW50IGFyZSBNb2Rp ZmlhYmxlTEZCVG9wb2xvZ3ksIA0KTEZCc1N1cHBvcnRlZCwgV3JpdGVhYmxlQXR0cmlidXRlcyBh bmQgDQpSZWFkYWJsZUF0dHJpYnV0ZXMuDQoNCjEuNC4yLjEuIE1vZGlmaWFibGVMRkJUb3BvbG9n eQ0KDQpUaGlzIGVsZW1lbnQgaGFzIGEgYm9vbGVhbiB2YWx1ZS4gIFRoaXMgZWxlbWVudCANCmlu ZGljYXRlcyB3aGV0aGVyIHRoZSBMRkIgdG9wb2xvZ3kgb2YgdGhlIEZFIG1heSBiZSANCmNoYW5n ZWQgYnkgdGhlIENFLiAgSWYgdGhlIGVsZW1lbnQgaXMgYWJzZW50LCB0aGUgDQpkZWZhdWx0IHZh bHVlIGlzIGFzc3VtZWQgdG8gYmUgdHJ1ZSwgYW5kIHRoZSBDRSBwcmVzdW1lcyANCnRoZSBMRkIg dG9wb2xvZ3kgbWF5IGJlIGNoYW5nZWQuIElmIHRoZSB2YWx1ZSBpcyBwcmVzZW50IA0KYW5kIHNl dCB0byBmYWxzZSwgdGhlIExGQiB0b3BvbG9neSBvZiB0aGUgRkUgaXMgZml4ZWQuICANCkluIHRo YXQgY2FzZSwgdGhlIExGQnMgc3VwcG9ydGVkIGNsYXVzZSBtYXkgYmUgb21pdHRlZCwgDQphbmQg dGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIExGQnMgaXMgaW5mZXJyZWQgYnkgdGhlIENFIA0KZnJvbSB0 aGUgTEZCIHRvcG9sb2d5IGluZm9ybWF0aW9uLiAgSWYgdGhlIGxpc3Qgb2YgDQpzdXBwb3J0ZWQg TEZCcyBpcyBwcm92aWRlZCB3aGVuIE1vZGlmaWFibGVMRkJUb3BvbG9neSBpcyANCmZhbHNlLCB0 aGUgQ2FuT2NjdXJCZWZvcmUgYW5kIENhbk9jY3VyQWZ0ZXIgaW5mb3JtYXRpb24gDQpzaG91bGQg YmUgb21pdHRlZC4NCg0KMS40LjIuMi4gU3VwcG9ydGVkTEZCcyBhbmQgU3VwcG9ydGVkTEZCDQoN Ck9uZSBjYXBhYmlsaXR5IHRoYXQgdGhlIEZFIHNob3VsZCBpbmNsdWRlIGlzIHRoZSBsaXN0IG9m IA0Kc3VwcG9ydGVkIExGQiBjbGFzc2VzLiBUaGUgU3VwcG9ydGVkTEZCcyBlbGVtZW50LCB3aGlj aCANCm9jY3VycyBhdCBtb3N0IG9uY2UsIHNlcnZlcyBhcyBhIHdyYXBwZXIgZm9yIHRoZSBsaXN0 IG9mIA0KTEZCIGNsYXNzZXMgc3VwcG9ydGVkLiBFYWNoIGNsYXNzIGlzIGRlc2NyaWJlZCBpbiBh IA0KU3VwcG9ydGVkTEZCIGVsZW1lbnQuDQoNCkVhY2ggb2NjdXJyZW5jZSBvZiB0aGUgU3VwcG9y dGVkTEZCIGVsZW1lbnQgZGVzY3JpYmVzIGFuIA0KTEZCIGNsYXNzIHRoYXQgdGhlIEZFIHN1cHBv cnRzLiAgSW4gYWRkaXRpb24gdG8gDQppbmRpY2F0aW5nIHRoYXQgdGhlIEZFIHN1cHBvcnRzIHRo ZSBjbGFzcywgRkVzIHdpdGggDQptb2RpZmlhYmxlIExGQiB0b3BvbG9neSBzaG91bGQgaW5jbHVk ZSBpbmZvcm1hdGlvbiBhYm91dCANCmhvdyBMRkJzIG9mIHRoZSBzcGVjaWZpZWQgY2xhc3MgbWF5 IGJlIGNvbm5lY3RlZCB0byANCm90aGVyIExGQnMuICBUaGlzIGluZm9ybWF0aW9uIHNob3VsZCBk ZXNjcmliZSB3aGljaCBMRkIgDQpjbGFzc2VzIHRoZSBzcGVjaWZpZWQgTEZCIGNsYXNzIG1heSBz dWNjZWVkIG9yIHByZWNlZGUgDQppbiB0aGUgTEZCIHRvcG9sb2d5LiAgVGhlIEZFIHNob3VsZCBp bmNsdWRlIGluZm9ybWF0aW9uIA0KYXMgdG8gd2hpY2ggcG9ydCBncm91cHMgbWF5IGJlIGNvbm5l Y3RlZCB0byB0aGUgZ2l2ZW4gDQphZGphY2VudCBMRkIgY2xhc3MuICBJZiBwb3J0IGdyb3VwIGlu Zm9ybWF0aW9uIGlzIA0Kb21pdHRlZCwgaXQgaXMgYXNzdW1lZCB0aGF0IGFsbCBwb3J0IGdyb3Vw cyBtYXkgYmUgdXNlZC4NCg0KMS40LjIuMi4xLiBMRkJOYW1lDQoNClRoaXMgZWxlbWVudCBoYXMg YXMgaXRzIHZhbHVlIHRoZSBuYW1lIG9mIHRoZSBMRkIgYmVpbmcgDQpkZXNjcmliZWQuDQoNCjEu NC4yLjIuMi4gTEZCT2NjdXJyZW5jZUxpbWl0DQoNClRoaXMgZWxlbWVudCwgaWYgcHJlc2VudCwg aW5kaWNhdGVzIHRoZSBsYXJnZXN0IG51bWJlciANCm9mIGluc3RhbmNlcyBvZiB0aGlzIExGQiBj bGFzcyB0aGUgRkUgY2FuIHN1cHBvcnQuICBGb3IgDQpGRXMgdGhhdCBkbyBub3QgaGF2ZSB0aGUg Y2FwYWJpbGl0eSB0byBjcmVhdGUgb3IgZGVzdHJveSANCkxGQiBpbnN0YW5jZXMsIHRoaXMgY2Fu IGVpdGhlciBiZSBvbWl0dGVkIG9yIGJlIHRoZSBzYW1lIA0KYXMgdGhlIG51bWJlciBvZiBMRkIg aW5zdGFuY2VzIG9mIHRoaXMgY2xhc3MgY29udGFpbmVkIA0KaW4gdGhlIExGQiBsaXN0IGF0dHJp YnV0ZS4NCg0KMS40LjIuMi4zLiBQb3J0R3JvdXBMaW1pdHMgYW5kIFBvcnRHcm91cExpbWl0DQoN ClRoZSBQb3J0R3JvdXBMaW1pdHMgZWxlbWVudCBpcyB0aGUgd3JhcHBlciB0byBob2xkIA0KaW5m b3JtYXRpb24gYWJvdXQgdGhlIHBvcnQgZ3JvdXBzIHN1cHBvcnRlZCBieSB0aGUgTEZCIA0KY2xh c3MuIEl0IGhvbGRzIG11bHRpcGxlIG9jY3VycmVuY2VzIG9mIHRoZSANClBvcnRHcm91cExpbWl0 IGVsZW1lbnQuDQoNCkVhY2ggb2NjdXJyZW5jZSBvZiB0aGUgUG9ydEdyb3VwTGltaXQgZWxlbWVu dCBjb250YWlucyANCnRoZSBwb3J0IG9jY3VycmVuY2UgaW5mb3JtYXRpb24gZm9yIGEgc2luZ2xl IHBvcnQgZ3JvdXAgDQpvZiB0aGUgTEZCIGNsYXNzLiAgRWFjaCBvY2N1cnJlbmNlIGhhcyB0aGUg bmFtZSBvZiB0aGUgDQpwb3J0IGdyb3VwIGluIHRoZSBQb3J0R3JvdXBOYW1lIGVsZW1lbnQsIHRo ZSBmZXdlc3QgDQpudW1iZXIgb2YgcG9ydHMgdGhhdCBjYW4gZXhpc3QgaW4gdGhlIGdyb3VwIGlu IHRoZSANCk1pblBvcnRDb3VudCBlbGVtZW50LCBhbmQgdGhlIGxhcmdlc3QgbnVtYmVyIG9mIHBv cnRzIA0KdGhhdCBjYW4gZXhpc3QgaW4gdGhlIGdyb3VwIGluIHRoZSBNYXhQb3J0Q291bnQgZWxl bWVudC4NCg0KMS40LjIuMi40LkNhbk9jY3VyQWZ0ZXJzIGFuZCBDYW5PY2N1ckFmdGVyDQoNClRo ZSBDYW5PY2N1ckFmdGVycyBlbGVtZW50IGlzIGEgd3JhcHBlciB0byBob2xkIHRoZSANCm11bHRp cGxlIG9jY3VycmVuY2VzIG9mIHRoZSBDYW5PY2N1ckFmdGVyIHBlcm1pc3NpYmxlIA0KcGxhY2Vt ZW50IGluZm9ybWF0aW9uLg0KDQpUaGUgQ2FuT2NjdXJBZnRlciBlbGVtZW50IGRlc2NyaWJlcyBh IHBlcm1pc3NpYmxlIA0KcG9zaXRpb25pbmcgb2YgdGhlIFN1cHBvcnRlZExGQi4gIFNwZWNpZmlj YWxseSwgaXQgbmFtZXMgDQphbiBMRkIgdGhhdCBjYW4gdG9wb2xvZ2ljYWxseSBwcmVjZWRlIHRo ZSBTdXBwb3J0ZWRMRkIuICANClRoYXQgaXMsIHRoZSBTdXBwb3J0ZWRMRkIgY2FuIGhhdmUgYW4g aW5wdXQgcG9ydCANCmNvbm5lY3RlZCB0byBhbiBvdXRwdXQgcG9ydCBvZiB0aGUgTEZCIHRoYXQg aXQgDQpDYW5PY2N1ckFmdGVyLiBUaGUgTEZCIGNsYXNzIHRoYXQgdGhlIFN1cHBvcnRlZExGQiBj YW4gDQpmb2xsb3cgaXMgaWRlbnRpZmllZCBieSB0aGUgTmVpZ2hib3JMRkIgZWxlbWVudCBvZiB0 aGUgDQpDYW5PY2N1ckFmdGVyIGVsZW1lbnQuICBJZiB0aGlzIG5laWdoYm9yIGNhbiBvbmx5IGJl IA0KY29ubmVjdGVkIHRvIGEgc3BlY2lmaWMgc2V0IG9mIGlucHV0IHBvcnQgZ3JvdXBzLCB0aGVu IA0KdGhlIHZpYVBvcnQgZWxlbWVudCBpcyBpbmNsdWRlZC4gIFRoaXMgZWxlbWVudCBvY2N1cnMg DQpvbmNlIGZvciBlYWNoIGlucHV0IHBvcnQgZ3JvdXAgb2YgdGhlIFN1cHBvcnRlZExGQiB0aGF0 IA0KY2FuIGJlIGNvbm5lY3RlZCB0byBhbiBvdXRwdXQgcG9ydCBvZiB0aGUgTmVpZ2hib3JMRkIu DQoNCltlLmcuLCBXaXRoaW4gYSBTdXBwb3J0ZWRMRkIgZWxlbWVudCwgZWFjaCBDYW5PY2N1ckFm dGVyIA0KZWxlbWVudCBtdXN0IGhhdmUgYSB1bmlxdWUgTmVpZ2hib3JMRkIsIGFuZCB3aXRoaW4g ZWFjaCANCkNhbk9jY3VyQWZ0ZXIgZWxlbWVudCBlYWNoIHZpYVBvcnQgbXVzdCByZXByZXNlbnQg YSANCnVuaXF1ZSBhbmQgdmFsaWQgaW5wdXQgcG9ydCBncm91cCBvZiB0aGUgU3VwcG9ydGVkTEZC LiAgDQpUaGUgInVuaXF1ZSIgY2xhdXNlcyBmb3IgdGhpcyBoYXZlIG5vdCB5ZXQgYmVlbiBhZGRl ZCB0byANCnRoZSBzY2hlbWEuXQ0KDQoxLjQuMi4yLjUuIENhbk9jY3VyQmVmb3JlcyBhbmQgQ2Fu T2NjdXJCZWZvcmUNCg0KVGhlIENhbk9jY3VyQmVmb3JlcyBlbGVtZW50IGlzIGEgd3JhcHBlciB0 byBob2xkIHRoZSANCm11bHRpcGxlIG9jY3VycmVuY2VzIG9mIHRoZSBDYW5PY2N1ckJlZm9yZSBw ZXJtaXNzaWJsZSANCnBsYWNlbWVudCBpbmZvcm1hdGlvbi4NCg0KVGhlIENhbk9jY3VyQmVmb3Jl IGVsZW1lbnQgc2ltaWxhcmx5IGxpc3RzIHRob3NlIExGQiANCmNsYXNzZXMgdGhhdCB0aGUgU3Vw cG9ydGVkTEZCIG1heSBwcmVjZWRlIGluIHRoZSANCnRvcG9sb2d5LiAgSW4gdGhpcyBlbGVtZW50 LCB0aGUNCnZpYVBvcnQgZWxlbWVudCByZXByZXNlbnRzIHRoZSBvdXRwdXQgcG9ydCBncm91cCBv ZiB0aGUgDQpTdXBwb3J0ZWRMRkIgdGhhdCBtYXkgYmUgY29ubmVjdGVkIHRvIHRoZSBOZWlnaGJv ckxGQi4gIA0KQXMgd2l0aCBDYW5PY2N1ckFmdGVyLCB2aWFQb3J0IG1heSBvY2N1ciBtdWx0aXBs ZSB0aW1lcyANCmlmIG11bHRpcGxlIG91dHB1dCBwb3J0cyBtYXkgbGVnaXRpbWF0ZWx5IGNvbm5l Y3QgdG8gdGhlIA0KZ2l2ZW4gTmVpZ2hib3JMRkIgY2xhc3MuDQoNCltBbmQgYSBzaW1pbGFyIHNl dCBvZiB1bmlxdWVuZXNzIGNvbnN0cmFpbnRzIGFwcGx5IHRvIA0KdGhlDQpDYW5PY2N1ckJlZm9y ZSBjbGF1c2VzLCBldmVuIHRob3VnaCBhbiBMRkIgbWF5IG9jY3VyIA0KYm90aCBpbg0KQ2FuT2Nj dXJBZnRlciBhbmQgQ2FuT2NjdXJCZWZvcmUuXQ0KDQoxLjQuMi4yLjYuIExGQkNsYXNzQ2FwYWJp bGl0aWVzDQoNClRoaXMgZWxlbWVudCBjb250YWlucyBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIGFi b3V0IHRoZSANCnN1YmplY3QgTEZCIGNsYXNzIHdob3NlIHN0cnVjdHVyZSBhbmQgc2VtYW50aWNz IGFyZSANCmRlZmluZWQgYnkgdGhlIExGQiBjbGFzcyBkZWZpbml0aW9uLiANCg0KMS40LjIuMy4g U3VwcG9ydGVkQXR0cmlidXRlcw0KDQpUaGlzIGVsZW1lbnQgc2VydmVzIGFzIGEgd3JhcHBlciB0 byBob2xkIHRoZSBpbmZvcm1hdGlvbiANCmFib3V0IGF0dHJpYnV0ZWQgcmVsYXRlZCBjYXBhYmls aXRpZXMuIFNwZWNpZmljYWxseSwgDQphdHRyaWJ1dGVzIHNob3VsZCBiZSBkZXNjcmliZWQgaW4g dGhpcyBlbGVtZW50IGlmOg0KYSkJdGhleSBhcmUgb3B0aW9uYWwgZWxlbWVudHMgaW4gdGhlIHN0 YW5kYXJkIGFuZCBhcmUgDQpzdXBwb3J0ZWQgYnkgdGhlIEZFLCBvcg0KYikJdGhlIHN0YW5kYXJk IGFsbG93cyBmb3IgYSByYW5nZSBvZiBhY2Nlc3MgDQpwZXJtaXNzaW9ucyAoZm9yIGV4YW1wbGUs IHJlYWQtb25seSBvciByZWFkLXdyaXRlKS4NCg0KRWFjaCBhdHRyaWJ1dGUgc28gZGVzY3JpYmVk IGlzIGNvbnRhaW5lZCBpbiB0aGUgDQpTdXBwb3J0ZWRBdHRyaWJ1dGVzIGVsZW1lbnQuIFRoYXQg ZWxlbWVudCBjb250YWlucyBhbiANCkF0dHJpYnV0ZU5hbWUgZWxlbWVudCB3aG9zZSB2YWx1ZSBp cyB0aGUgbmFtZSBvZiB0aGUgDQplbGVtZW50IGJlaW5nIGRlc2NyaWJlZCBhbmQgYW4gQWNjZXNz TW9kZXMgZWxlbWVudCwgDQp3aG9zZSB2YWx1ZSBpcyB0aGUgbGlzdCBvZiBwZXJtaXNzaW9ucy4N Cg0KMS40LjMuIEZFQXR0cmlidXRlcw0KDQpUaGUgRkVBdHRyaWJ1dGVzIGVsZW1lbnQgY29udGFp bnMgdGhlIGF0dHJpYnV0ZXMgb2YgdGhlIA0KRkUgdGhhdCBhcmUgbm90IGNvbnNpZGVyZWQgImNh cGFiaWxpdGllcyIuICBTb21lIG9mIA0KdGhlc2UgYXR0cmlidXRlcyBhcmUgd3JpdGVhYmxlLCBh bmQgc29tZSBhcmUgcmVhZC1vbmx5LCANCndoaWNoIHNob3VsZCBiZSBpbmRpY2F0ZWQgYnkgdGhl IGNhcGFiaWxpdHkgaW5mb3JtYXRpb24uICANCkF0IHRoZSBtb21lbnQsIHRoZSBzZXQgb2YgYXR0 cmlidXRlcyBpcyB3b2VmdWxseSANCmluY29tcGxldGUuICBFYWNoIGF0dHJpYnV0ZSBpcyBpZGVu dGlmaWVkIGJ5IGEgdW5pcXVlIA0KZWxlbWVudCB0YWcsIGFuZCB0aGUgdmFsdWUgb2YgdGhlIGVs ZW1lbnQgaXMgdGhlIHZhbHVlIA0Kb2YgdGhlIGF0dHJpYnV0ZS4NCg0KMS40LjMuMS4gRkVTdGF0 dXMNCg0KVGhpcyBhdHRyaWJ1dGUgY2FycmllcyB0aGUgb3ZlcmFsbCBzdGF0ZSBvZiB0aGUgRkUu ICBGb3IgDQpub3csIGl0IGlzIHJlc3RyaWN0ZWQgdG8gdGhlIHN0cmluZ3MgQWRtaW5EaXNhYmxl LCANCk9wZXJEaXNhYmxlIGFuZCBPcGVyRW5hYmxlLg0KDQoxLjQuMy4yLkxGQkluc3RhbmNlcyBh bmQgTEZCSW5zdGFuY2UNCg0KVGhlIExGQkluc3RhbmNlcyBlbGVtZW50IHNlcnZlcyBhcyBhIHdy YXBwZXIgdG8gaG9sZCB0aGUgDQptdWx0aXBsZSBvY2N1cnJlbmNlcyBvZiB0aGUgTEZCSW5zdGFu Y2UgaW5mb3JtYXRpb24gDQphYm91dCBpbmRpdmlkdWFsIExGQiBpbnN0YW5jZXMgb24gdGhlIEZF Lg0KDQpFYWNoIG9jY3VycmVuY2Ugb2YgdGhlIExGQkluc3RhbmNlIGVsZW1lbnQgZGVzY3JpYmVz IGEgDQpzaW5nbGUgTEZCIGluc3RhbmNlLiAgRWFjaCBlbGVtZW50IGNvbnRhaW5zIGFuIA0KTEZC Q2xhc3NOYW1lIGluZGljYXRpbmcgd2hhdCBjbGFzcyB0aGlzIGluc3RhbmNlIGhhcywgDQphbmQg YW4gTEZCSW5zdGFuY2VJRCBpbmRpY2F0aW5nIHRoZSBJRCB1c2VkIGZvciANCnJlZmVycmluZyB0 byB0aGlzIGluc3RhbmNlLiAgRm9yIG5vdywgdGhlIElEIHVzZXMgdGhlIA0KTk1UT0tFTiBjb25z dHJ1Y3Rpb24uICBGdXJ0aGVyIHByb3RvY29sIHdvcmsgaXMgbGlrZWx5IA0KdG8gcmVwbGFjZSB0 aGlzIHdpdGggYSByYW5nZSByZXN0cmljdGVkIGludGVnZXIuDQoNCjEuNC4zLjMuIExGQlRvcG9s b2d5IGFuZCBMRkJMaW5rDQoNClRoaXMgb3B0aW9uYWwgZWxlbWVudCBjb250YWlucyB0aGUgaW5m b3JtYXRpb24gYWJvdXQgDQplYWNoIGludGVyLUxGQiBsaW5rIGluc2lkZSB0aGUgRkUuICBFYWNo IGxpbmsgaXMgDQpkZXNjcmliZWQgaW4gYW4gTEZCTGluayBlbGVtZW50Lg0KVGhpcyBlbGVtZW50 IGNvbnRhaW5zIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gdG8gaWRlbnRpZnkgDQpwcmVjaXNlbHkg dGhlIGVuZCBwb2ludHMgb2YgYSBsaW5rLiBUaGUgRnJvbUxGQklEIGFuZCANClRvTEZCSUQgZmll bGRzIGluZGljYXRlIHRoZSBMRkIgaW5zdGFuY2VzIGF0IGVhY2ggZW5kIG9mIA0KdGhlIGxpbmss IGFuZCBtdXN0IHJlZmVyZW5jZSBMRkJzIGluIHRoZSBMRkIgaW5zdGFuY2UgDQp0YWJsZS4gIFRo ZSBGcm9tUG9ydEdyb3VwIGFuZCBUb1BvcnRHcm91cCBtdXN0IGlkZW50aWZ5IA0Kb3V0cHV0IGFu ZCBpbnB1dCBwb3J0IGdyb3VwcyBkZWZpbmVkIGluIHRoZSBMRkIgY2xhc3NlcyANCm9mIHRoZSBM RkIgaW5zdGFuY2VzIGlkZW50aWZpZWQgYnkgdGhlIEZyb21MRkJJRCBhbmQgDQpUb0xGQklELiAg VGhlIEZyb21Qb3J0SW5kZXggYW5kIFRvUG9ydEluZGV4IGZpZWxkcyANCnNlbGVjdCB0aGUgZWxl bWVudHMgZnJvbSB0aGUgcG9ydCBncm91cHMgdGhhdCB0aGlzIGxpbmsgDQpjb25uZWN0cy4gIEFs bCBsaW5rcyBhcmUgdW5pcXVlbHkgaWRlbnRpZmllZCBieSB0aGUgDQpGcm9tTEZCSUQsIEZyb21Q b3J0R3JvdXAsIGFuZCBGcm9tUG9ydEluZGV4IGZpZWxkcy4gIA0KTXVsdGlwbGUgbGlua3MgbWF5 IGhhdmUgdGhlIHNhbWUgVG9MRkJJRCwgVG9Qb3J0R3JvdXAsIA0KYW5kIFRvUG9ydEluZGV4IGFz IHRoaXMgbW9kZWwgc3VwcG9ydHMgZmFuIGluIG9mIGludGVyLQ0KTEZCIGxpbmtzIGJ1dCBub3Qg ZmFuIG91dC4NCg0KMS40LjMuNC4gRkVDb25maWd1cmVkTmVpZ2hib3JzIGFuIEZFQ29uZmlndXJl ZE5laWdoYm9yDQoNClRoZSBGRUNvbmZpZ3VyZWROZWlnaGJvcnMgZWxlbWVudCBpcyBhIHdyYXBw ZXIgdG8gaG9sZCANCnRoZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIHRoYXQgb25lIG9yIG1v cmUgDQpGRUNvbmZpZ3VyZWROZWlnaGJvciBlbGVtZW50cyBjb252ZXkgYWJvdXQgdGhlIA0KY29u ZmlndXJlZCBGRSB0b3BvbG9neS4NCg0KVGhlIEZFQ29uZmlndXJlZE5laWdoYm9yIGVsZW1lbnQg b2NjdXJzIG9uY2UgZm9yIGVhY2ggDQpjb25maWd1cmVkIEZFIG5laWdoYm9yIHRoZSBGRSBrbm93 cyBhYm91dC4gIEl0IHNob3VsZCANCm5vdCBiZSBmaWxsZWQgaW4gYmFzZWQgb24gRkUgbGV2ZWwg cHJvdG9jb2wgb3BlcmF0aW9ucy4gIA0KSW4gZ2VuZXJhbCwgbmVpZ2hib3IgZGlzY292ZXJ5IG9w ZXJhdGlvbiBvbiB0aGUgRkUgDQpzaG91bGQgYmUgcmVwcmVzZW50ZWQgYW5kIG1hbmlwdWxhdGVk IGFzIGFuIExGQi4gIA0KSG93ZXZlciwgZm9yIEZFcyB0aGF0IGluY2x1ZGUgbmVpZ2hib3IgZGlz Y292ZXJ5IGFuZCBkbyANCm5vdCBoYXZlIHN1Y2ggYW4gTEZCLCBpdCBpcyBwZXJtaXR0ZWQgdG8g ZmlsbCBpbiB0aGUgDQppbmZvcm1hdGlvbiBpbiB0aGlzIHRhYmxlIGJhc2VkIG9uIHN1Y2ggcHJv dG9jb2xzLiANCg0KU2ltaWxhcmx5LCB0aGUgTUFDIGFkZHJlc3MgaW5mb3JtYXRpb24gaW4gdGhl IHRhYmxlIGlzIA0KaW50ZW5kZWQgdG8gYmUgdXNlZCBpbiBzaXR1YXRpb25zIHdoZXJlIG5laWdo Ym9ycyBhcmUgDQpjb25maWd1cmVkIGJ5IE1BQyBhZGRyZXNzLiAgUmVzb2x1dGlvbiBvZiBuZXR3 b3JrIGxheWVyIA0KdG8gTUFDIGFkZHJlc3MgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGNhcHR1cmVk IGluIEFSUCANCkxGQnMsIG5vdCBkdXBsaWNhdGVkIGluIHRoaXMgdGFibGUuICBOb3RlIHRoYXQg dGhlIHNhbWUgDQpuZWlnaGJvciBtYXkgYmUgcmVhY2hlZCB0aHJvdWdoIG11bHRpcGxlIGludGVy ZmFjZXMgb3IgDQphdCBtdWx0aXBsZSBhZGRyZXNzZXMuICBUaGVyZSBpcyBubyB1bmlxdWVuZXNz IA0KcmVxdWlyZW1lbnQgb2YgYW55IHNvcnQgb24gb2NjdXJyZW5jZXMgb2YgdGhlIA0KRkVDb25m aWd1cmVkTmVpZ2hib3IgZWxlbWVudC4NCg0KSW5mb3JtYXRpb24gYWJvdXQgdGhlIGludGVuZGVk IGZvcm1zIG9mIGV4Y2hhbmdlIHdpdGggYSANCmdpdmVuIG5laWdoYm9yIGlzIG5vdCBjYXB0dXJl ZCBoZXJlLCBvbmx5IHRoZSBhZGphY2VuY3kgDQppbmZvcm1hdGlvbiBpcyBpbmNsdWRlZC4NCg0K MS40LjMuNC4xLk5laWdoYm9ySUQNCg0KVGhpcyBpcyB0aGUgSUQgaW4gc29tZSBzcGFjZSBtZWFu aW5nZnVsIHRvIHRoZSBDRSBmb3IgDQp0aGUgbmVpZ2hib3IuDQpJZiB0aGlzIHRhYmxlIHJlbWFp bnMsIHdlIHByb2JhYmx5IHNob3VsZCBhZGQgYW4gRkVJRCANCmZyb20gdGhlIHNhbWUgc3BhY2Ug YXMgYW4gYXR0cmlidXRlIG9mIHRoZSBGRS4NCg0KMS40LjMuNC4yLk5laWdoYm9ySW50ZXJmYWNl DQoNClRoaXMgaWRlbnRpZmllcyB0aGUgaW50ZXJmYWNlIHRocm91Z2ggd2hpY2ggdGhlIG5laWdo Ym9yIA0KaXMgcmVhY2hlZC4NCg0KW0VkaXRvcnMgbm90ZTogQXMgdGhlIHBvcnQgc3RydWN0dXJl cyBiZWNvbWUgYmV0dGVyIA0KZGVmaW5lZCwgdGhlIHR5cGUgZm9yIHRoaXMgc2hvdWxkIGJlIGZp bGxlZCBpbiB3aXRoIHRoZSANCnR5cGVzIG5lY2Vzc2FyeSB0byByZWZlcmVuY2UgdGhlIHZhcmlv dXMgcG9zc2libGUgDQpuZWlnaGJvciBpbnRlcmZhY2VzLCBpbmNsdWRlIHBoeXNpY2FsIGludGVy ZmFjZXMsIA0KbG9naWNhbCB0dW5uZWxzLCB2aXJ0dWFsIGNpcmN1aXRzLCBldGMuXQ0KDQoxLjQu My40LjMuIE5laWdoYm9yTmV0d29ya0FkZHJlc3MNCg0KTmVpZ2hib3IgY29uZmlndXJhdGlvbiBp cyBmcmVxdWVudGx5IGRvbmUgb24gdGhlIGJhc2lzIA0Kb2YgYSBuZXR3b3JrIGxheWVyIGFkZHJl c3MuICBGb3IgbmVpZ2hib3JzIGNvbmZpZ3VyZWQgaW4gDQp0aGF0IGZhc2hpb24sIHRoaXMgaXMg d2hlcmUgdGhhdCBhZGRyZXNzIGlzIHN0b3JlZC4NCg0KMS40LjMuNC40Lk5laWdoYm9yTWFjQWRk cmVzcw0KDQpOZWlnaGJvcnMgYXJlIHNvbWV0aW1lcyBjb25maWd1cmVkIHVzaW5nIE1BQyBsZXZl bCANCmFkZHJlc3NlcyAoRXRoZXJuZXQgTUFDIGFkZHJlc3MsIGNpcmN1aXQgaWRlbnRpZmllcnMs IA0KZXRjLikgIElmIHN1Y2ggYWRkcmVzc2VzIGFyZSB1c2VkIHRvIGNvbmZpZ3VyZSB0aGUgDQph ZGphY2VuY3ksIHRoZW4gdGhhdCBpbmZvcm1hdGlvbiBpcyBzdG9yZWQgaGVyZS4gIE5vdGUgDQp0 aGF0IG92ZXIgc29tZSBwb3J0cyBzdWNoIGFzIHBoeXNpY2FsIHBvaW50IHRvIHBvaW50IA0KbGlu a3Mgb3IgdmlydHVhbCBjaXJjdWl0cyBjb25zaWRlcmVkIGFzIGluZGl2aWR1YWwgDQppbnRlcmZh Y2VzLCB0aGVyZSBpcyBubyBuZWVkIGZvciBlaXRoZXIgZm9ybSBvZiBhZGRyZXNzLg0KDQoxLjUu IFNhbXBsZSBGRSBBdHRyaWJ1dGUgRG9jdW1lbnQNCg0KPD94bWwgdmVyc2lvbj0iMS4wIj4NCjxm bTpGRURvY3VtZW50IA0KeG1sbnM6Zm09Imh0dHA6Ly93d3cuaWV0Zi5vcmcvLi4udGhlc2NoZW1h Li4uIj4NCg0KIDxmbTpGRUNhcGFiaWxpdGllcz4NCg0KICA8Zm06TW9kaWZpYWJsZUxGQlRvcG9s b2d5PiB0cnVlIA0KPC9mbTpNb2RpZmlhYmxlTEZCVG9wb2xvZ3k+DQoNCiAgPGZtOlN1cHBvcnRl ZExGQnM+DQogICA8Zm06U3VwcG9ydGVkTEZCPg0KICAgIDwhLS0gQSBzaW1wbGUgc2luZ2xlLWlu cHV0IG11bHRpLW91dHB1dCBjbGFzc2lmaWVyIC0NCi0+DQogICAgPGZtOkxGQk5hbWU+IENsYXNz aWZpZXIgPC9mbTpMRkJOYW1lPg0KICAgIDxmbTpMRkJPY2N1cnJlbmNlTGltaXQ+IDMgPC9mbTpM RkJPY2N1cnJlbmNlTGltaXQ+DQoNCiAgICA8Zm06UG9ydEdyb3VwTGltaXRzPg0KICAgICA8Zm06 UG9ydEdyb3VwTGltaXQ+DQogICAgICA8IS0tIFRoZSBpbnB1dCBwb3J0IC0tPg0KICAgICAgPGZt OlBvcnRHcm91cE5hbWU+IElucHV0UG9ydEdyb3VwIA0KPC9mbTpQb3J0R3JvdXBOYW1lPg0KICAg ICAgPGZtOk1pblBvcnRDb3VudD4gMSA8L2ZtOk1pblBvcnRDb3VudD4NCiAgICAgIDxmbTpNYXhQ b3J0Q291bnQ+IDEgPC9mbTpNYXhQb3J0Q291bnQ+DQogICAgIDwvZm06UG9ydEdyb3VwTGltaXQ+ DQogICAgIDxmbTpQb3J0R3JvdXBMaW1pdD4NCiAgICAgPCEtLVRoZSBub3JtYWwgb3V0cHV0IHBv cnRzIC0tPg0KICAgICA8Zm06UG9ydEdyb3VwTmFtZT4gT3V0cHV0UG9ydEdyb3VwIA0KPC9mbTpQ b3J0R3JvdXBOYW1lPg0KICAgICAgPGZtOk1pblBvcnRDb3VudD4gMCA8L2ZtOk1pblBvcnRDb3Vu dD4NCiAgICAgIDxmbTpNYXhQb3J0Q291bnQ+IDMyIDwvZm06TWF4UG9ydENvdW50Pg0KICAgICA8 L2ZtOlBvcnRHcm91cExpbWl0Pg0KICAgICA8Zm06UG9ydEdyb3VwTGltaXQ+DQogICAgICA8IS0t IFRoZSBvcHRpb25hbCBlcnJvciBwb3J0IC0tPg0KICAgICAgPGZtOlBvcnRHcm91cE5hbWU+IEVy cm9yUG9ydEdyb3VwIA0KPC9mbTpQb3J0R3JvdXBOYW1lPg0KICAgICAgPGZtOk1pblBvcnRDb3Vu dD4gMCA8L2ZtOk1pblBvcnRDb3VudD4NCiAgICAgIDxmbTpNYXhQb3J0Q291bnQ+IDEgPC9mbTpN YXhQb3J0Q291bnQ+DQogICAgIDwvZm06UG9ydEdyb3VwTGltaXQ+DQogICAgPC9mbTpQb3J0R3Jv dXBMaW1pdHM+ICAgDQogICAgPGZtOkNhbk9jY3VyQWZ0ZXJzPg0KICAgICA8Zm06Q2FuT2NjdXJB ZnRlcj4NCiAgICAgIDxmbTpOZWlnaGJvckxGQj4gUG9ydCA8L2ZtOk5laWdoYm9yTEZCPg0KICAg ICAgPCEtLSBvbWl0dGVkIHZpYVBvcnQgLS0+DQogICAgIDwvZm06Q2FuT2NjdXJBZnRlcj4NCiAg ICAgPGZtOkNhbk9jY3VyQWZ0ZXINCiAgICAgIDxmbTpOZWlnaGJvckxGQj4gSW50ZXJuYWxTb3Vy Y2UgPC9mbTpOZWlnaGJvckxGQj4NCiAgICAgIDwhLS0gb21pdHRlZCB2aWFQb3J0IC0tPg0KICAg ICA8L2ZtOkNhbk9jY3VyQWZ0ZXI+DQogICAgPC9mbTpDYW5PY2N1ckFmdGVycz4NCiAgICA8Zm06 Q2FuT2NjdXJCZWZvcmVzPg0KICAgICA8Zm06Q2FuT2NjdXJCZWZvcmU+DQogICAgICA8Zm06TmVp Z2hib3JMRkI+IE1hcmtlciA8L2ZtOk5laWdoYm9yTEZCPg0KICAgICAgPCEtLSBvbWl0dGVkIHZp YVBvcnQgLS0+DQogICAgIDwvZm06Q2FuT2NjdXJCZWZvcmU+DQogICAgPC9mbTpDYW5PY2N1ckJl Zm9yZXM+DQogICA8L2ZtOlN1cHBvcnRlZExGQj4NCiAgIDwhLS0gdGhlbiBTdXBwb3J0ZWQgTEZC IGVsZW1lbnRzIGZvciBQb3J0LCANCkludGVybmFsU291cmNlIC0tPg0KICAgPCEtLSAgICAgIE1h cmtlciwgLi4uIC0tPg0KICA8L2ZtOlN1cHBvcnRlZExGQnM+DQoNCiAgPGZtOlN1cHBvcnRlZEF0 dHJpYnV0ZXM+DQogICA8Zm06U3VwcG9ydGVkQXR0cmlidXRlPg0KICAgIDxmbTpBdHRyaWJ1dGVO YW1lPiBGRVN0YXR1cyAgPC9mbTpBdHRyaWJ1dGVOYW1lPg0KICAgIDxmbTpBY2Nlc3NNb2Rlcz4g IHJlYWQgd3JpdGUgPC9mbTpBY2Nlc3NNb2Rlcz4NCiAgIDwvZm06U3VwcG9ydGVkQXR0cmlidXRl Pg0KICAgPGZtOlN1cHBvcnRlZEF0dHJpYnV0ZT4NCiAgICA8Zm06QXR0cmlidXRlTmFtZT4gIFZl bmRvciAgIDwvZm06QXR0cmlidXRlTmFtZT4NCiAgICA8Zm06QWNjZXNzTW9kZXM+ICAgIHJlYWQg ICAgIDwvZm06QWNjZXNzTW9kZXM+DQogICA8L2ZtOlN1cHBvcnRlZEF0dHJpYnV0ZQ0KICAgPGZt OlN1cHBvcnRlZEF0dHJpYnV0ZT4NCiAgICA8Zm06QXR0cmlidXRlTmFtZT4gIE1vZGVsICAgIDwv Zm06QXR0cmlidXRlTmFtZT4NCiAgICA8Zm06QWNjZXNzTW9kZXM+ICAgIHJlYWQgICAgIDwvZm06 QWNjZXNzTW9kZXM+DQogICA8L2ZtOlN1cHBvcnRlZEF0dHJpYnV0ZT4NCiAgPC9mbTpTdXBwb3J0 ZWRBdHRyaWJ1dGVzPg0KIDwvZm06RkVDYXBhYmlsaXRpZXM+DQoNCiA8Zm06RkVBdHRyaWJ1dGVz Pg0KICA8Zm06VmVuZG9yPiBXb3JsZCBXaWRlIFdpZGdldHMgPC9mbTpWZW5kb3I+DQogIDxmbTpN b2RlbD4gRm9vIEZvcndhcmQgTW9kZWwgNiA8L2ZtOk1vZGVsPg0KICA8Zm06RkVTdGF0dXM+ICAg ICAgIE9wZXJFbmFibGUgPC9mbTpGRVN0YXR1cz4NCiAgPGZtOkxGQkluc3RhbmNlcz4NCiAgIDxm bTpMRkJJbnN0YW5jZT4NCiAgICA8Zm06TEZCQ2xhc3NOYW1lPiBDbGFzc2lmaWVyIDwvZm06TEZC Q2xhc3NOYW1lPg0KICAgIDxmbTpMRkJJbnN0YW5jZUlEPiBJbnN0NSAgICAgPC9mbTpMRkJJbnN0 YW5jZUlEPg0KICAgPC9mbTpMRkJJbnN0YW5jZT4NCiAgIDxmbTpMRkJJbnN0YW5jZT4NCiAgICA8 Zm06TEZCQ2xhc3NOYW1lPiBJbnRlcmZhY2UgIDwvZm06TEZCQ2xhc3NOYW1lPg0KICAgIDxmbTpM RkJJbnN0YW5jZUlEPiBJbnN0MTEgICAgPC9mbTpMRkJJbnN0YW5jZUlEPg0KICAgPC9mbTpMRkJJ bnN0YW5jZT4NCiAgIDxmbTpMRkJJbnN0YW5jZT4NCiAgICA8Zm06TEZCQ2xhc3NOYW1lPiBNZXRl ciAgICAgIDwvZm06TEZCQ2xhc3NOYW1lPg0KICAgIDxmbTpMRkJJbnN0YW5jZUlEPiBJbnN0MTcg ICAgPC9mbTpMRkJJbnN0YW5jZUlEPg0KICAgPC9mbTpMRkJJbnN0YW5jZT4NCiAgPC9mbTpMRkJJ bnRhbmNlcz4NCiAgPGZtOkxGQlRvcG9sb2d5Pg0KICAgPGZtOkxGQkxpbms+DQogICAgPGZtOkZy b21MRkJJRD4gICBJbnN0MTEgICAgICA8L2ZtOmZyb21MRkJJRD4NCiAgICA8Zm06RnJvbVBvcnRH cm91cD4gSUZPbndhcmRHcm91cCA8L2ZtOkZyb21Qb3J0R3JvdXA+DQogICAgPGZtOkZyb21Qb3J0 SW5kZXg+IDEgICAgICAgICA8L2ZtOkZyb21Qb3J0SW5kZXg+DQogICAgPGZtOlRvTEZCSUQ+ICAg ICBJbnN0NSAgICAgICA8L2ZtOlRvTEZCSUQ+DQogICAgPGZtOlRvUG9ydEdyb3VwPiBJbnB1dFBv cnRHcm91cCA8L2ZtOlRvUG9ydEdyb3VwPg0KICAgIDxmbTpUb1BvcnRJbmRleD4gMSAgICAgICAg ICAgPC9mbTpUb1BvcnRJbmRleD4NCiAgIDwvZm06TEZCTGluaz4NCiAgIDxmbTpMRkJMaW5rPg0K ICAgIDxmbTpGcm9tTEZCSUQ+ICAgSW5zdDUgICAgICAgPC9mbTpmcm9tTEZCSUQ+DQogICAgPGZt OkZyb21Qb3J0R3JvdXA+IE91dHB1dEdyb3VwIDwvZm06RnJvbVBvcnRHcm91cD4NCiAgICA8Zm06 RnJvbVBvcnRJbmRleD4gMSAgICAgICAgIDwvZm06RnJvbVBvcnRJbmRleD4NCiAgICA8Zm06VG9M RkJJRD4gICAgIEluc3QxNyAgICAgICA8L2ZtOlRvTEZCSUQ+DQogICAgPGZtOlRvUG9ydEdyb3Vw PiBJbk1ldGVyR3JvdXAgPC9mbTpUb1BvcnRHcm91cD4NCiAgICA8Zm06VG9Qb3J0SW5kZXg+IDEg ICAgICAgICAgIDwvZm06VG9Qb3J0SW5kZXg+DQogICA8L2ZtOkxGQkxpbms+DQogIDwvZm06TEZC VG9wb2xvZ3k+DQogPC9mbTpGRUF0dHJpYnV0ZXM+DQo8L2ZtOkZFRG9jdW1lbnQ+DQoNCg0K ------_=_NextPart_001_01C3DC73.349377BB-- From uuqnews@mail.com Sat Jan 17 02:32:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29819 for ; Sat, 17 Jan 2004 02:32:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhkwM-0002k7-00 for forces-archive@ietf.org; Sat, 17 Jan 2004 02:32:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhkvO-0002fi-00 for forces-archive@ietf.org; Sat, 17 Jan 2004 02:31:19 -0500 Received: from [202.100.24.167] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1Ahkub-0002Yx-00; Sat, 17 Jan 2004 02:30:30 -0500 From: "Memorial Cubano:" To: enum@ietf.org Subject: Pedem Missas e orações pelas vítimas do comunismo ref.: byo 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 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 17 Jan 2004 02:30:30 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook

Ref.: (otv) InEnglish / InItaliano / EnCastellano

Memorial cubano: Pedido de Missas e orações pelas vítimas do comunismo

A ajuda urgente que solicitamos é de caráter estritamente espiritual, ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus

Queridos irmãos luso-brasileiros,

* Precisamos de vossa valiosa ajuda para resgatar do esquecimento a mais de 10 mil cubanos que morreram vítimas do regime comunista, sobre os quais se possui informação documentada. Esta ajuda que lhes solicitamos é de caráter estritamente espiritual, inteiramente ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus!

* Entre os dias 20 e 23 de fevereiro próximo, no Tamiami Park de Miami, Flórida, voluntários de diversos países organizarão o Memorial Cubano, consistente em mais de 10 mil cruzes brancas, cada uma delas tendo inscrito o nome de uma vítima do regime comunista de Cuba. Familiares desterrados que nunca puderam dar o adeus a seus seres queridos assassinados, por não ser-lhes permitido visitar suas tumbas em Cuba, poderão fazê-lo agora.

* No centro da área se localizará uma cruz de madeira gigante, também pintada de branco, denominada "Cruz da vítima desconhecida", que constituirá o reconhecimento a todos os que morreram por causa do regime comunista, porém a respeito dos quais até o momento não se possui informação suficiente.

* De que maneira vocês podem unir-se a esta cruzada de orações e a esta homenagem espiritual? Simplesmente encomendando uma Missa ou serviço religioso, organizando com sua família, comunidade ou colegas de trabalho um momento de oração conjunta, ou rezando privadamente. Solicitamos-lhes que as Missas sejam encomendadas, se for possível, para o domingo 22 de fevereiro. Assim, no mundo inteiro, nesse dia se elevarão preces a Deus pelo eterno descanso dessas almas. Poderão encomendá-las em benefício das "vítimas do genocídio cubano sob o regime comunista de Fidel Castro".

* Muitas destas vítimas foram jovens que enfrentaram o "paredón" de fuzilamento proclamando "Viva Cristo Rei!"

* Confirmem-nos o quanto antes vossa adesão, encomendando Missas, prometendo orações, etc., fazendo clic em:

ConfirmamosMissa/ServicoReligioso e/ou ConfirmamosOraçoesPreces incluindo local, data e, se o desejarem, outros detalhes.

* Irmãos ibero-americanos e homens e mulheres de boa vontade, de outras regiões do mundo, que leiam esta mensagem e a ela adiram: que a Providência os recompense com o cêntuplo já nesta terra!

Com a maior consideração e estima,

Renato Gómez - Coordenador Geral

Comitê Organizador do Memorial Cubano

Tel. (1-786) 621-7505 Miami (FL) www memorialcubano org

PS.:

Em vossas orações e preces incluam também os homens, mulheres e crianças que morreram afogados no estreito da Flórida, tentando alcançar a liberdade. Seus nomes são em sua maioria desconhecidos e fontes autorizadas estimam que o número deles seja de muitas dezenas de milhares de cubanos.

Por fim, rezem pelos presos políticos que agonizam nos cárceres, como o médico Oscar Elias Biscet, pela economista Martha Beatriz Roque e milhares de outros irmãos cubanos detidos DesejoInfoPresosPoliticos. A seis anos da viagem de S.S. João Paulo II a Cuba (21-25 de janeiro de 1998), se continua contrariando o sonho papal de que a ilha-cárcere abra-se ao mundo.

LINKS PRIORITÁRIOS:

ConfirmoMissa/ServiçoReligioso e/ou ConfirmoOraçoesPreces (incluindo nome, cidade e, se desejar, outros detalhes)

MinhaAjuda (narre de que maneira poderá ajudar-nos a difundir esta iniciativa espiritual e humanitária: reenviando esta notícia a seus amigos, levando-a a jornalistas conhecidos, colocando-a no quadro de avisos de seu local de trabalho, etc.; pode incluir também sugestões).

MinhaOpiniao

OUTROS LINKS:

DesejoRecibirLinkMemorialCubano (para receber o link do web site sobre o Memorial Cubano, com nomes de todas as vítimas)

DesejoReceberInfoPresosPoliticos

ProximosEnvios:SoloEnEspañol

NextMails:OnlyInEnglish

Remover

A difusão deste e-mail é de exclusiva responsabilidade da agência humanitária Derechos Sin Fronteras (DSF).

Tradução: Graça Salgueiro

 

 

From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 19 15:33:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07709 for ; Mon, 19 Jan 2004 15:33:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aig5l-0003Pz-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 15:33:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aig4u-0003NT-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 15:32:57 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Aig4M-0003K5-00 for forces-archive@IETF.ORG; Mon, 19 Jan 2004 15:32:22 -0500 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.00CABB83@cherry.ease.lsoft.com>; Mon, 19 Jan 2004 15:32:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68671762 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Jan 2004 15:32:21 -0500 Received: from 198.24.6.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 Jan 2004 15:32:20 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i0JKWHEq018369 for ; Mon, 19 Jan 2004 14:32:17 -0600 (CST) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 19 Jan 2004 14:32:05 -0600 Received: from ericsson.com (142.133.72.81 [142.133.72.81]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XHG6WDCQ; Mon, 19 Jan 2004 15:32:17 -0500 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Jon Maloy Message-ID: <400C3ECC.5050802@ericsson.com> Date: Mon, 19 Jan 2004 15:32:12 -0500 Reply-To: Jon Maloy Sender: Forwarding and Control Element Separation From: Jon Maloy Subject: Draft TIPC To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Here is the draft describing TIPC (now renamed to "Transparent Inter Process Communication"): http://www.ietf.org/internet-drafts/draft-maloy-tipc-00.txt We don't explicitly refer to it as a ForCES base protocol in the draft, but as stated earlier, it is the intention that this should be one of the options. I plan to go to Seoul and present this. /Jon From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 19 17:28:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11986 for ; Mon, 19 Jan 2004 17:28:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AihsO-0002t9-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 17:28:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aihmf-0002Rw-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 17:22:14 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Aihhl-0001ue-00 for forces-archive@IETF.ORG; Mon, 19 Jan 2004 17:17:09 -0500 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.00CABE2F@cherry.ease.lsoft.com>; Mon, 19 Jan 2004 17:16:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68680556 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Jan 2004 17:16:42 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 Jan 2004 17:16:42 -0500 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0JMHxuo001758 for ; Mon, 19 Jan 2004 22:17:59 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0JMGLiq032697 for ; Mon, 19 Jan 2004 22:17:27 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011914163723379 for ; Mon, 19 Jan 2004 14:16:37 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jan 2004 14:16:37 -0800 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] FE Capabilities and attributes section of the model draft Thread-Index: AcPcczQI+nuZKQUMRdCHYugKHe3cKQCXCqJA X-OriginalArrivalTime: 19 Jan 2004 22:16:37.0225 (UTC) FILETIME=[E7A6E590:01C3DED9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8020B0FD2@orsmsx409.jf.intel.com> Date: Mon, 19 Jan 2004 14:16:36 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: FE Capabilities and attributes section of the model draft Comments: To: "Deleganes, Ellen M" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I just reviewed the document and had the following comments. Cheers, David=20 General: Is there a good cross-platform tool for browsing and validating the schema that anyone can recommend? General: I noticed a few spots where comments where=20 included, that is, . Is there some sort of annotation tag that can be used to include comments on each attribute? It would be nice if the schema could be self-describing and browsable with some nice graphical tool. Line 5: The tag here appears to not be matched anywhere, causing the document to be invalid. =20 FEDocument attribute: Why is all capabilities and attributes optional? Seems like mandating that providing the information should be mandatory. 1.4.1 FECapabilities should all be mandatory. E.g. every FE should be able to indicate whether it can support modifiable topology or not. Actually, all=20 the attributes I looked at should be mandatory. =20 Having defaults is good, but requiring that the FE explicitly say what capabilities it has reduces the chance of hard-to-diagnose bugs due to an FE implementor assuming the default was A when in fact it was NotA, where the implementor didn't express the attribute due to assuming the (unexpressed) default matches their implementation. 1.4.2.2.4/5 The CanOccur approach says that LFBs have particular other LFBs they can follow/precede. Why not instead define LFB connectivity according to the type of traffic on a LFBLink? I.e. perhaps an IPv6 forwarder LFB would only be able to accept input from other LFBs that output IPv6 traffic. Perhaps consider allowing both types of constraints to be expressed. 1.4.3.4.1 What Neighbor does the NeighborID refer=20 to? Neighboring CE (within a NE), Neighboring NE (within a network), neighboring LFB (within an FE), or=20 neighboring FE (within an NE)? (end) From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 19 18:03:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13676 for ; Mon, 19 Jan 2004 18:03:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiiQj-0005FH-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 18:03:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiiOF-00056h-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 18:01:04 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AiiLe-0004zT-00 for forces-archive@IETF.ORG; Mon, 19 Jan 2004 17:58:23 -0500 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.00CABE41@cherry.ease.lsoft.com>; Mon, 19 Jan 2004 17:58:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68684226 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Jan 2004 17:58:07 -0500 Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 Jan 2004 17:58:07 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i0JMvsdt024998; Mon, 19 Jan 2004 16:57:55 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <52D13A805349A249960B9943E5590BD8020B0FD2@orsmsx409.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <400C60F1.CEBC0FBB@alcatel.com> Date: Mon, 19 Jan 2004 16:57:53 -0600 Reply-To: alex.audu@alcatel.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: FE Capabilities and attributes section of the model draft Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This the same question I have in mind. May be we can have a graphical representation of the FECapabilities and Attributes structure itself. This will give us something to correlate the XML structure with. Regards, Alex. "Putzolu, David" wrote: > I just reviewed the document and had the following comments. > > Cheers, > David > > General: Is there a good cross-platform tool for > browsing and validating the schema that anyone > can recommend? > > General: I noticed a few spots where comments where > included, that is, . Is > there some sort of annotation tag that can be used > to include comments on each attribute? It would > be nice if the schema could be self-describing and > browsable with some nice graphical tool. > > Line 5: The tag here appears to not > be matched anywhere, causing the document to be > invalid. > > FEDocument attribute: Why is all capabilities and > attributes optional? Seems like mandating that providing > the information should be mandatory. > > 1.4.1 FECapabilities should all be mandatory. E.g. > every FE should be able to indicate whether it can > support modifiable topology or not. Actually, all > the attributes I looked at should be mandatory. > Having defaults is good, but requiring that the FE > explicitly say what capabilities it has reduces the > chance of hard-to-diagnose bugs due to an FE implementor > assuming the default was A when in fact it was NotA, > where the implementor didn't express the attribute due > to assuming the (unexpressed) default matches their > implementation. > > 1.4.2.2.4/5 The CanOccur approach says that LFBs > have particular other LFBs they can follow/precede. > Why not instead define LFB connectivity according to > the type of traffic on a LFBLink? I.e. perhaps an IPv6 > forwarder LFB would only be able to accept input > from other LFBs that output IPv6 traffic. Perhaps > consider allowing both types of constraints to be > expressed. > > 1.4.3.4.1 What Neighbor does the NeighborID refer > to? Neighboring CE (within a NE), Neighboring NE (within > a network), neighboring LFB (within an FE), or > neighboring FE (within an NE)? > > (end) From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 19 19:06:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17914 for ; Mon, 19 Jan 2004 19:06:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AijPw-00022g-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 19:06:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AijMa-0001q1-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 19:03:24 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AijGO-0001Ot-00 for forces-archive@IETF.ORG; Mon, 19 Jan 2004 18:57:00 -0500 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.00CABF15@cherry.ease.lsoft.com>; Mon, 19 Jan 2004 18:56:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 68688775 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Jan 2004 18:56:32 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 19 Jan 2004 18:56:32 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6096613 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 19 Jan 2004 18:56:31 -0500 X-Sender: joel@stevecrocker.com@localhost 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.20040119184047.01acdcb0@localhost> Date: Mon, 19 Jan 2004 18:56:16 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: FE Capabilities and attributes section of the model draft To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD8020B0FD2@orsmsx409.jf.inte l.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,FREE_TRIAL autolearn=no version=2.60 Let me restate the questions, and try to provide the answers that motivated me when I wrote the text: I used Oxygen to validate the schema, and to validate the sample against the schema. Cut and paste errors may have crept in since. (Oxygen is commercial, with a 30 day free trial. There are other good tools, such as XMLspy.) The schema should have more documentation. Probably as annotations. I did not think that the full descriptive text went in the schema (at least every other example I have seen has less information in the schema than in the document.) Since I was not sure where to draw the line, I figured that schema internal documentation could wait. I made everything optional for now for two reasons: 1) I had to make a call. Since there was some resistance to a lot of these things, I thought that optionality with defaults was sensible. I have no objection if folks think that all the information should be mandatory. 2) By making it optional I could write a short example which would match the schema. (Not a very good reason, but it helped me out.) The reason for the "CanOccurs" approach is that we can not predefine the traffic types, nor the implementation types. Within the set of FEs with adjustable topology, some will be able to support placing any LFB in any place in the topology. Others will have restrictions on which elements can occur where. While not all restrictions can be expressed this way (in general, there are going to be non-expressable capability restrictions. The FE will give errors if the CE tries to order it to do something it can not) nonetheless, I wanted a flexible approach. And knowing whether the traffic is v4 or v6t only helps choose a few of the branches / placements. Getting into specifying the services the FE delivers, and the order of LFBs that the CE / FE use to deliver those services is clearly not the job of the FE Model (nor even the ForCES protocol specification, except as examples.) Section 1.4.3.4 is about inter-FE topology. NeighborID is some sort of ID for the neighboring FE. Whether that neighboring FE is in the same NE, in a different NE, or actually some router probably depends upon how you expect the FE to know about its neighbors. I expect that the ID will be an IP (v4 or v6) address. But I felt that it was a little premature to specify that. [I tried to give this information fair treatment. I apologize if my biases caused it to be under-specified.] Thanks very much for taking a look at this. More comments please. Joel PS: I saw Alex's request for a diagram. If the CanOccurs stuff is still confusing, I will have to find some tools and write a much longer explanation, with diagrams. My concern is that the next step up in explanation gets quite verbose. At 02:16 PM 1/19/2004 -0800, Putzolu, David wrote: >I just reviewed the document and had the following comments. > >Cheers, >David > >General: Is there a good cross-platform tool for >browsing and validating the schema that anyone >can recommend? > >General: I noticed a few spots where comments where >included, that is, . Is >there some sort of annotation tag that can be used >to include comments on each attribute? It would >be nice if the schema could be self-describing and >browsable with some nice graphical tool. > >Line 5: The tag here appears to not > be matched anywhere, causing the document to be > invalid. > >FEDocument attribute: Why is all capabilities and >attributes optional? Seems like mandating that providing >the information should be mandatory. > >1.4.1 FECapabilities should all be mandatory. E.g. >every FE should be able to indicate whether it can >support modifiable topology or not. Actually, all >the attributes I looked at should be mandatory. >Having defaults is good, but requiring that the FE >explicitly say what capabilities it has reduces the >chance of hard-to-diagnose bugs due to an FE implementor >assuming the default was A when in fact it was NotA, >where the implementor didn't express the attribute due >to assuming the (unexpressed) default matches their >implementation. > >1.4.2.2.4/5 The CanOccur approach says that LFBs >have particular other LFBs they can follow/precede. >Why not instead define LFB connectivity according to >the type of traffic on a LFBLink? I.e. perhaps an IPv6 >forwarder LFB would only be able to accept input >from other LFBs that output IPv6 traffic. Perhaps >consider allowing both types of constraints to be >expressed. > >1.4.3.4.1 What Neighbor does the NeighborID refer >to? Neighboring CE (within a NE), Neighboring NE (within >a network), neighboring LFB (within an FE), or >neighboring FE (within an NE)? > >(end) From bus4irwa@altavista.com Mon Jan 19 21:17:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23518 for ; Mon, 19 Jan 2004 21:17:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AilSo-0002zG-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 21:17:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AilRv-0002xR-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 21:17:03 -0500 Received: from 200-180-135-154.paemt200.dial.brasiltelecom.net.br ([200.180.135.154]) by ietf-mx with smtp (Exim 4.12) id 1AilRM-0002v5-00 for forces-archive@ietf.org; Mon, 19 Jan 2004 21:16:29 -0500 Received: from [69.188.135.197] by 200-180-135-154.paemt200.dial.brasiltelecom.net.br with ESMTP id 78CB11F32E9; Wed, 21 Jan 2004 06:10:19 +0600 Message-ID: <2$$nhrg-zd97-5vz-9@8zfe0s4zwlxsn> From: "Arthur Cartwright" Reply-To: "Arthur Cartwright" To: Subject: weight |oss (ID:3m4) Date: Wed, 21 Jan 04 06:10:19 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F_FE0_E_3_" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=18.3 required=5.0 tests=DATE_IN_FUTURE_06_12, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, FORGED_OUTLOOK_TAGS,HTML_40_50,HTML_IMAGE_ONLY_04,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,USERPASS autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --F_FE0_E_3_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Best quality weight |oss product - |ose your weight fast and guaranted!

http:= //www.procitravin.com/index27.html

Procitravin is designed to help you lose weight
and feel more energetic. Our patented formula
including Advantra Z bitter orange releases
energy from fats and carbohydrates will make
the pounds melt away!

Remove your add= ress from our database.

Thanks,
Doma Greg



w cwjxnfhgwjggtwclvxve e g wk pkzpd xtmujk pivfah --F_FE0_E_3_-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 21 18:38:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18014 for ; Wed, 21 Jan 2004 18:38:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjRvT-0002zM-00 for forces-archive@ietf.org; Wed, 21 Jan 2004 18:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjRua-0002yE-00 for forces-archive@ietf.org; Wed, 21 Jan 2004 18:37:29 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AjRuI-0002wH-00 for forces-archive@IETF.ORG; Wed, 21 Jan 2004 18:37:10 -0500 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.00CAFBBE@cherry.ease.lsoft.com>; Wed, 21 Jan 2004 18:37:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69003665 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 21 Jan 2004 18:36:57 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jan 2004 18:36:56 -0500 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: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0LNc4Wd019452 for ; Wed, 21 Jan 2004 23:38:05 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0LNbR9x004859 for ; Wed, 21 Jan 2004 23:37:30 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012115363806568 for ; Wed, 21 Jan 2004 15:36:38 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jan 2004 15:36:38 -0800 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] framework v13 uploaded to IETF Thread-Index: AcPazM/YGyjKsgXZSuORuRDOUMq5YgAAAa1QAAo6DAABYF/1cA== X-OriginalArrivalTime: 21 Jan 2004 23:36:38.0173 (UTC) FILETIME=[6A10ECD0:01C3E077] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8021CBDA8@orsmsx409.jf.intel.com> Date: Wed, 21 Jan 2004 15:36:34 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: framework v13 uploaded to IETF To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, The revised Framework has not received further comment and thus is now being forwarded back to the IESG for=20 final review. Cheers, David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David > Sent: Wednesday, January 14, 2004 4:31 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] framework v13 uploaded to IETF >=20 > All, >=20 > This document has received good detailed review and the=20 > changes made are clarifications and not major technical changes. =20 >=20 > Please review the change list (included below) and comment=20 > before January 20 if there are any significant issues with=20 > this document. >=20 > Thanks, > David >=20 >=20 > > -----Original Message----- > > From: Forwarding and Control Element Separation=20 > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Yang, Lily L > > Sent: Wednesday, January 14, 2004 10:41 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] framework v13 uploaded to IETF > >=20 > > Hi, all -- > >=20 > > This new version of framework incorporated the most recent comments=20 > > from Avri, Jamal and others in the list. Below is a detailed log of=20 > > the changes. There are numerous clarification and=20 > corrections, but no=20 > > substantial change in the technical content. > >=20 > > This revision is uploaded to IETF and we feel ready to go RFC.=20 > >=20 > > Lily > >=20 > >=20 > > <> > >=20 > > -------------------------- summary of changes in v13 > > -------------------------------------------- > >=20 > > #1) Section 1 Dfinition: > > [Comment/Reason for change] To clarify that association is=20 > a per CE-FE=20 > > concept. > > [old] > > Pre-association Phase - The period of time during=20 > which an FE=20 > > Manager (see below) and a CE Manager (see below) are=20 > determining which=20 > > FE and CE should be part of the same network element. > > =20 > > [new] > > Pre-association Phase - The period of time during=20 > which an FE=20 > > Manager (see below) and a CE Manager (see below) are determining=20 > > whether an FE and a CE should be part of the > > same network element. It is possible for some elements of=20 > > the NE to be in pre-association=20 > > phase while other elements are in the=20 > post-association phase. > >=20 > > #2) Section 3. Achitecture > > [Comment/Reason for change] To avoid the misconception that=20 > > association is a NE system wide concept. > > [deleted]=20 > > There is no defined role for FE Manager and CE Manager in=20 > > post-association phase, thus these logical components are not=20 > > considered part of the ForCES NE. > >=20 > > 3.2 at the end of 1st paragraph: > > [Comment/Reason for change] clarify the impact of FE virtualization. > > [old] > > However, if FE virtualization results in dynamic resource=20 > > change on FE during post-association phase, the FE model=20 > needs to be=20 > > able to report such capability and the Protocol needs to be able to=20 > > inform the CE of such change via asynchronous messages (see [3],=20 > > Section 5, requirement #6). > > [new] > > However, if FE virtualization results in resource=20 > change taken=20 > > from an existing FE (already participating in ForCES=20 > post-association=20 > > phase), the ForCES Protocol needs to be able to inform the=20 > CE of such=20 > > change via asynchronous messages (see [3], Section 5,=20 > requirement #6). > >=20 > >=20 > > #3) 3.2 at the end of the 2nd paragraph > > [Comment/Reason for change] To point out the behavior issue=20 > > of FE accepting commands from multiple CEs. > > [add] Unless otherwise configured or determined by a ForCEs=20 > > Protocol exchange, each FE will process authorized=20 > > incoming commands directed at it as it receives them=20 > > on a first come first serve basis. =20 > >=20 > > #4) 4.1 Pre_association Phase > > [Comment/Reason for change] same as #1) > > [old] > > Pre-association phase is the period of time during=20 > > which an FE Manager and a CE Manager are determining which FE=20 > > and CE should be part of the same network element. =20 > >=20 > > [new] > > Pre-association phase is the period of time during=20 > > which an FE Manager and a CE Manager are determining whether=20 > > an FE and a CE should be part of the same network element. =20 > >=20 > > #5) 4.1.1 Fl Reference Point > > [Comment/Reason for change] same as #1) > > [old] > > CE managers and FE managers may communicate across=20 > > the Fl reference point in the pre-association phase in order=20 > > to determine which CEs and FEs should communicate with each other. =20 > > [new] > > CE managers and FE managers may communicate across=20 > > the Fl reference point in the pre-association phase in order=20 > > to determine whether an individual CE and FE, or a set of CEs=20 > > and FEs should be associated. =20 > >=20 > > #6) 4.2.2 Figure 9 > > [Comment/Reason for change] inter-FE topology exchange is=20 > > optional in the protocol. > > deleted the inter-FE topology msg exchange. > > at the beginning of last paragraph: > > [old] > > After the successful security handshake, the FE needs=20 > > to inform the CE of its own capability and its topology in=20 > > relation to other FEs.=20 > > [new] > > After the successful security handshake, the FE needs=20 > > to inform the CE of its own capability and optionally its=20 > > topology in relation to other FEs.=20 > >=20 > > #7) 4.2.2: end of last paragraph: > > [Comment/Reason for change] more accurate wording. > > [old] > > Once FE starts accepting packets for processing, we=20 > > say the association of this FE with its CE is now=20 > > established. From then on, the CE and FE enter steady-state=20 > > communication. > > [new] > > Once the necessary initial information is exchanged,=20 > > the process of association is completed. Packet processing=20 > > and forwarding at the FE cannot begin until association is=20 > > established. =20 > >=20 > > #8) 4.2.5 FE Proxy > > [Comment/Reason for change] Clarify that FE Proxy terminates=20 > > ForCES itself. > > [old] > > In the case where a physical FE cannot implement=20 > > (e.g., due to the lack of a general purpose CPU) the ForCES=20 > > protocol directly, a proxy FE can be used to terminate the Fp=20 > > reference point instead of the physical FE. ... It is also=20 > > possible that one proxy act on behalf of multiple physical FEs. > > [new]=20 > > In the case where a physical FE cannot implement=20 > > (e.g., due to the lack of a general purpose CPU) the ForCES=20 > > protocol directly, a proxy FE can be used to terminate the Fp=20 > > reference point instead of the physical FE. ... It is also=20 > > possible that one proxy act on behalf of multiple physical FEs. > >=20 > > #9) 4.3 Association Re-establishment > > [Comment/Reason for change] same as #1). > > [old] > > When an FE leaves or joins an existing NE that is=20 > > already in post-association phase, the CE needs to be aware=20 > > of the impact on FE topology and deals with the change accordingly. > > [new] > > When an FE leaves or joins an existing NE that is=20 > > already in operation, the CE needs to be aware of the impact=20 > > on FE topology and deals with the change accordingly. > >=20 > > #9.1) Section 7 Acknowledgement (updated) > >=20 > > #9.5) Merged the paragraph in old section 8.2.1 to the=20 > > beginning of section 8 as part of the introduction. Following=20 > > sections readjusted accordingly. > >=20 > > #10) 8.1.4 Attack during Fail Over > > [Comment/Reason for change] Better wording. > > [old] > > Threat: ... A malicious node can take over as CE-B if=20 > > such trusted relationship is not established during the fail-over.=20 > > [new] > > A malicious node can take over as CE-B if such=20 > > trusted relationship has not been established prior or during=20 > > the fail-over.=20 > >=20 > > #11) 8.1.8 > > [Comment/Reason for change] Remove congestion control. > > [old] > > Requirement: Some sort of rate limiting mechanism=20 > > MUST to be in place at both the FE and CE. Examples of such=20 > > mechanisms include explicit rate limiters or congestion=20 > > control algorithms. Rate Limiter SHOULD be configured at the=20 > > FE for each message type that are being received through Fi/F=20 > > interface. > > [new] > > Requirement: Some sort of rate limiting mechanism=20 > > MUST to be in place at both the FE and CE. Rate Limiter=20 > > SHOULD be configured at the FE for each message type that are=20 > > being received through Fi/F interface. > >=20 > > #12) Section 9/10: references > > Adding one more reference for security: > > [18] S. Bellovin, J. Schiller, and C. Kaufman,=20 > > "Security Mechanisms for the Internet", RFC 3631, December, 2003. > > Updated most references to reflect the current status (RFC,=20 > > or new revision/date) > >=20 > >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 23 11:20:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09624 for ; Fri, 23 Jan 2004 11:20:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak42s-00003G-00 for forces-archive@ietf.org; Fri, 23 Jan 2004 11:20:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak41R-0007bz-00 for forces-archive@ietf.org; Fri, 23 Jan 2004 11:19:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak401-0007MD-00 for forces-archive@IETF.ORG; Fri, 23 Jan 2004 11:17:37 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak401-00088W-CC for forces-archive@IETF.ORG; Fri, 23 Jan 2004 11:17:37 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00CB3022@cherry.ease.lsoft.com>; Fri, 23 Jan 2004 11:17:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69260391 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 23 Jan 2004 11:17:31 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 Jan 2004 11:17:30 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i0NGHR986633; Fri, 23 Jan 2004 11:17:27 -0500 (EST) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i0NGHR776393; Fri, 23 Jan 2004 11:17:27 -0500 (EST) Received: from empress.torrentnet.com (empress.torrentnet.com [4.18.161.79]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id i0NGHK108878; Fri, 23 Jan 2004 11:17:20 -0500 (EST) Content-Type: multipart/mixed; boundary="=-UPpy7u1G58cs/pRaWxHI" Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Approved-By: Zsolt Haraszti Message-ID: <1074874628.2805.22.camel@empress.torrentnet.com> Date: Fri, 23 Jan 2004 11:17:09 -0500 Reply-To: Zsolt Haraszti Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Ericsson IPI Subject: Metadata model for the ForCES model To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-UPpy7u1G58cs/pRaWxHI Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, Attached is a writeup on the metadata model that the ForCES model team worked out for modeling state propagation between LFBs. The model team is working on incorporating this text (after some further clarification work) into the upcoming revision of the model draft, but we thought it may be beneficial to have this early dissemination to the wider ForCES audience (even though the text is a bit raw), with the hope of getting some early feedback. So, comments are welcome. -- Zsolt Haraszti, Ph.D. Tel: +1 919 472 9949 Ericsson IP Infrastructure Mobile: +1 240 505 2852 Raleigh NC USA Fax: +1 919 472 9999 Email: zsolt.haraszti@ericsson.com --=-UPpy7u1G58cs/pRaWxHI Content-Disposition: attachment; filename=forces-metadata-model_3.txt Content-Type: text/plain; name=forces-metadata-model_3.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Simple Metadata Model for the ForCES Model ========================================== 1 Per-packet state variables and their life-cycle In order to propose a metadata model for ForCES, first it is useful to understand the notion of per-packet state and the life-cycle of per-packet state variables in the forwarding plane. As the packet is processed in the forwarding plane (either in a physical implementation or in the logical model), various types of state information are created and kept in association with the packet to assist further processing of the packet. Although such state information is somewhat implementation dependent, it can always be regarded as a collection of independent or loosely coupled state variables. The (logical) interface at which the packet was received, the result of a classification operation, the color associated with the packet as a result of metering, etc., are all examples of such per-packet state variables. For most cases, each of these variables can be conveniently modeled as a pair, where the label identifies the type of information (for example, "color"), and its value holds the current value for the packet (e.g., "red"). The value is typically a simple integer (enumerator, table entry reference, actual protocol value), or in some cases it may be some structure protocol address, such as an IP or MAC address. In any given system, there is a finite number of state variables that can be associated with (created for) a packet. As the packet goes through its life-cycle (i.e., traverses through the forwarding plane), each of the state variables goes through its own life-cycle, some possibly more than once. For the discussion that follows, we define the life-cycle of the state variable using three types of events: "write", "read" and "consume". The first "write" event initializes the value of the variable (implicitly creating and/or initializing the variable), and hence starts the life-cycle. The explicit "consume" event terminates the life-cycle. Within the life-cycle, that is after a "write" event but before the next "consume" event, there can be an arbitrary number of "write" and "read" events. These can be mixed in an arbitrary order within the life-cycle. Outside of the life-cycle, that is before the fist "write" event, or between a "consume" event and the next "write" event, the state variable should be regarded non-existent or non-initialized. Reading a state variable outside of its life-cycle is considered an error. Although the length of the life-cycle of a state variable may coincide with the packet's own life-cycle, typically it is much shorter, and sometimes it is possible that a state variable goes through more than one life-cycle for the same packet. An example for the latter is when an IP packet is encapsulated (tunneled) in another IP packet (e.g., GRE or IP-IP). In such a case, IP LPM lookup needs to be done twice, once for the inner packet and then for the outer. Assuming that the LPM lookup results in a state variable that encodes the next hop information which is then used and consumed by a next hop stage, such state variable is initialized and then consumed twice, i.e., goes through two life-cycles. 2 Per-packet State Variables and the ForCES LFB Model According to the ForCES model, the operation of the forwarding plane is logically decomposed into a set of LFBs and thus the forwarding plane is modeled by a directed graph of such LFBs. To make the decomposition possible, the model needs to rely on per-packet state variables, just as any physical implementation. Note, however, that the LFB model may or may not closely resemble the physical implementation, hence the per-packet state variables of the model may differ from the actual per-packet state variables of the physical implementation. With respect to the life-cycle of per-packet state variables in the LFB model, we can distinguish between intra-LFB state variables and inter-LFB state variables. The former type of state variables are those which have life-cycles that are completely contained within an LFB. The existence and actual value of such variables do not need to be (and should not be) exposed to the ForCES model and protocol, except that it may be mentioned in the textual operational description of the LFB as a way of describing the logical operation of the LFB. In the remaining part of this discussion we will narrow our focus on those per-packet state variables of the model that have life-cycles spanning across more than one LFB, since these are the ones that will be carried as metadata. We can call these variables inter-LFB state variables. As we will see shortly, inter-LFB state variables must be exposed to the ForCES model and protocol to some extent, as they put certain requirements on both. These are further discussed in the remaining part of this document. 3 Modeling Choices for the Propagation of State Variables Between LFBs The ForCES model must capture how per-packet state information is propagated from one LFB to other(s) on the same FE, and also from one LFB on one FE to another LFB on another FE. Before discussing our possible modeling choices, we should point out that there is a wide range of ways how actual physical implementations keep and manage per-packet state variables. On the one end of the spectrum are the pure register-based approaches, where there is some sort of a globally accessible register array, each register representing a certain state variable. Ideally, the registers should be available for read and write from any part of the forwarding plane that need to read and/or write the variable. If all involved stages of the forwarding plane can look at the global registers, there is never a need to actually send any information along with the packet. Ideally, each state variable should be mapped to its own register, in which case the forwarding plane can be re-arranged without changing the register allocations. Due to various hardware constraints, in practical implementations registers are typically re-used/shared by more than one state variables, utilizing the limited temporal scope of the variables. Register sharing may require re-allocating the registers when the forwarding operations are re-arranged. On the other end of the spectrum are the pure frame-based solutions. Here all relevant packet state variables are pre-pended or appended to the packet in some lower-layer frame, and sent along with the packet from one processing operation stage to the next. Register-based approaches are considered more efficient inside processors or processor cores, but their applicability is limited to these, as all users of the variable must be able to access the same memory/registers. On the other hand, one can always use the frame-based approach, even though in cases where the register-based approach is available the latter is typically more efficient. In most physical implementations the two approaches are mixed: register based approaches may be preferred within network processors or processor cores, while frame-based approaches may be used across processor(-core) and FE boundaries. In fact, for inter-FE communication of per packet state information the frame-based approach is the only sensible alternative. When it comes to modeling per-packet state information and its propagation in the ForCES model, we can for a second consider both the register based and the frame-based alternatives as a starting point for the model. Since physical constraints are not applicable to the model, both approaches are feasible, and there is little incentive to use a mixture of the two. It is however an advantage (though not a requirement) if the selected model resembles how the state is actually propagated in physical implementations. Since the frame-based implementation is a more universal option for physical implementations, we argue that the ForCES model should also use a model where the state variables conceptually are sent with the packet. We call such model a metadata model, since the state variables are sent with the packet as metadata. The following sections introduce the metadata model in more details. 4 The Proposed Metadata Model Our proposed metadata model is defined as follows: The per-packet inter-LFB state information is propagated with the packet as metadata. Although this conceptually corresponds to the frame-based approach, the model does not specify how the metadata is actually passed (the framing), it simply assumes that the metadata is passed with the packet. The only exception is inter-FE links, where physical inter-operability (and testability) requires that the frame formats, metadata encoding, endiannes, etc., are properly specified. Such specifications are beyond the scope of this document. A metadata corresponds to one per-packet state variable, and thus has a label (or tag) part that identifies the type of information, and a value part that carries the actual information. Lets denote this as a pair, e.g., . The tag here is shown as a textual label, but it can be replaced or associated with a unique numeric value (identifier). The value part is assumed to be a 32-bit signed integer (negative values are typically used to encode special values). At any given edge of the LFB topology graph (any link between two LFBs), the packet is marked with a finite set of active metadata, where active means that all metadata is inside its life-cycle (i.e., have been properly initialized, and has not been consumed yet). Two corollaries of this model: 1 No uninitialized metadata exists in the model. 2 There can only be up to one occurrence of each metadata type (label) associated with the packet at any given time. When the packet is processed by an LFB, i.e., between it is received and forwarded by the LFB, the LFB may perform read, write and/or consume operation on any of the metadata. Considering the LFB as a back box, we can say that one of the following operations are performed on each metadata: - IGNORE: ignores and forwards it - READ: reads and forwards it - READ/RE-WRITE: reads, over-writes and forwards it - WRITE: writes and forwards it - READ-AND-CONSUME: reads and consumes it - CONSUME: consumes it (without reading) The last two terminate the life-cycle of the metadata, meaning that the metadata is not forwarded with the packet when the packet is sent to the next LFB. In our model a new metadata is generated by an LFB when the LFB applies a WRITE operation into a metadata type that was not present when the packet was received by the LFB. Such implicit creation may be unintentional by the LFB, that is, the LFB may apply the WRITE operation without knowing or caring if the given metadata existed or not. If it existed, it gets over-written; if it did not exist, it gets created. For source type LFBs (i.e., that insert packets into the model), WRITE is the only meaningful metadata operation. Sink type of LFBs (that remove the packet from the model) may either read (READ-AND-CONSUME) or ignore (CONSUME) each metadata. 5 Metadata Production and Consumption For a given metadata on a given packet path, there is at least one LFB that creates that metadata (producer), and there should be at least one LFB that needs that metadata (consumer). The producer and the consumer LFBs may not be adjacent. There may be multiple consumers for the same metadata. There may be multiple producers of the same metadata. If a packet path involves multiple producers of the same metadata, then the 2nd, 3rd, etc. producers overwrite the metadata value. What metadata is produced by an LFB is specified by the LFB class definition on a per output port group basis. A producer may always generate the metadata on the port group, or may generate it only upon certain conditions. We call the former a "unconditional" metadata, whereas the latter is a "conditional" metadata. In the case of conditional metadata, it should be possible to determine from the definition of the LFB when a "conditional" metadata is produced. The consumer behavior of an LFB, i.e., what metadata the LFB needs for its operation, is defined in the LFB class definition on a per input port group basis. An input port group may "require" a given metadata, or may treat it as an "optional" information. In the latter case it must be explicitly defined in the LFB class definition what happens if an optional metadata is not provided. This may be done in the form of providing a default value for each optional metadata, and assuming that the default value is substituted if the metadata is not provided for a packet. 6 Expressing Inter-LFB Metadata Dependencies When a consumer requires a given metadata, it has dependencies on its up-stream LFBs, that is, it can only function if there is at least one producer of that metadata and no intermediate LFB consumes the metadata. The model should expose the inter-dependency, and it should be possible that the inter-dependency can be taken into consideration when constructing LFB topologies, and also that dependency can be verified when validating topologies. For extensibility reasons it is preferred that an LFB specification defines what metadata the LFB requires, but without specifying from what other LFB it expect a certain metadata to come from. Similarly, LFBs should specify what metadata they produce, but without defining what other LFBs the metadata is meant for. When specifying the metadata tags (labels), some harmonization effort must be made so that the producer LFB(-class) uses the same tag as its intended consumer(s), or vice versa. 7 Fixed Tag, Variable Tag, and Configurable Tag Metadata Production When the produced metadata is defined for a given LFB class, most metadata will be specified with a fixed tag. For example, a Rate Meter LFB will always produce the "Color" metadata. A small subset of LFBs will need to have the capability to produce one or more of their metadata with tags that are not fixed in the LFB class definition, but instead can be selected per LFB instance. We call this variable tag metadata production. If an LFB produces metadata with variable tag, a corresponding LFB attribute--called the tag selector--specifies the tag for each such metadata. This mechanism is to improve the versatility of certain multi-purpose LFB classes, since it allows the same LFB class be used in different topologies, producing the right metadata tags according to the needs of the topology. An example for such LFB class is a Generic Classifier LFB. Depending on the capability of the FE, the tag selector can be a read-only or a read-write attribute. In the former case the tag cannot be modified by the CE. In the latter case the tag can be configured by the CE, hence we call this "configurable tag metadata production." (Note that in this definition configurable tag metadata production is a subset of variable tag metadata production.) As for any other LFB attribute, the ForCES protocol will provide access for the CE to examine (and for the configurable case to modify) the value of the tag selector. 8 Fixed Tag, Variable Tag, and Configurable Tag Metadata Needs Most LFB classes will specify their metadata needs using fixed metadata tags. For example, a Next Hop LFB may always require a "NextHopId" metadata. For a small subset of LFB classes, however, it is beneficial to leave the tag of some required or optional metadata unspecified in the LFB class definition, and instead refer to an LFB attribute that provides the required metadata tag at run-time. For example, the Redirector LFB may need to use a "ClassID" metadata in one instance, and a "ProtocolType" metadata in another instance as a basis for selecting the right output port. This mechanism allows for a certain level of adaptability for the LFB class. The metadata tag selector attribute may be read-only or read-write, depending on the capabilities of the LFB instance and the FE. In either case, the ForCES protocol will provide the means for accessing the attribute. 9 Metadata Usage Categories Depending on the role and usage of a metadata, various amount of encoding information must be provided when the metadata is defined, and some cases offer less flexibility in the value selection than others. As far as usage of a metadata is concerned, three types of metadata exist: - Relational (or binding) metadata - Enumerated metadata - Explicit/external value metadata The purpose of the relational metadata is to refer in one LFB instance (producer LFB) to a "thing" in another downstream LFB instance (consumer LFB), where the "thing" is typically an entry in a table attribute of the consumer LFB. For example, the Prefix Lookup LFB executes an LPM search using its prefix table and resolves to a next-hop reference. This reference needs to be passed as metadata by the Prefix Lookup LFB (producer) to the Next Hop LFB (consumer), and must refer to a specific entry in the next-hop table within the consumer. Expressing and propagating such binding relationship is probably the most common usage of metadata. One or more object in the producer LFB are related (bound) to a specific object in the consumer LFB. Such relation is established by the CE very explicitely, i.e., by properly configuring the attributes in both LFBs. Available methods include the following: The binding may be expressed by tagging the involved objects in both LFBs by the same unique (but otherwise arbitrary) identifier. The value of the tag is explicitly configured (written by the CE) into both LFBs, and this value also is the value what the metadata carries between the LFBs. Another way of setting up binding relations is when a naturally occurring unique identifier of the consumer's object (for example, the array index of a table entry) is used as a reference (and as a value of the metadata. In such case the index is obtained (read) or inferred by the CE by communicating with the consumer LFB. Once the CE obtained the index, it needs to plug (write) it into the producer LFB to establish the binding. Important characteristics of the binding usage of metadata are: - The value of the metadata shows up in the CE-FE communication for BOTH the consumer and the producer, that is, its value must be carried over the ForCES protocol. Using the tagging technique, the value is WRITTEN to both LFBs. Using the other technique, the value is WRITTEN to only the producer LFB and may be READ from the consumer LFB. - The actual value is irrelevant for the CE, the binding is simply expressed by using the SAME value at the consumer and producer LFBs. - Hence the definiton of the metadata does not have to include value assignments. The only exception is when some special value(s) of the metadata must be reserved to convey special events. Eventhough such special cases must be then defined with the metadata specification, their encoded values can be selected rather arbitrarily. For example, for the above Prefix Lookup LFB example, a special value may be reserved to signal the NO-MATCH case, and the value of zero may be assigned for this purpose. The second class of metadata is the enumerated type. An example is the Color metadata that is produced by a Meter LFB and consumed by some other LFBs. As the name suggests, such metadata has a relatively small number of possible values, each with a very specific meaning. All the possible cases must be enumerated when defining such a metadata. Although a value encoding must be included in the specification, the actual values can be selected rather arbitrarily (e.g., and would be both valid encodings, what is important is that an encoding is specified). The value of the enumerated metadata may or may not be conveyed via the ForCES protocol between the CE and FE. The third class of metadata is of the explicit type. This refers to cases where the value of the metadata is explicitly used by the consumer LFB to change some packet header fields. In other words, its value has a direct and explicit impact on some field and will be visible externally when the packet leaves the NE. Examples are TTL increment given to a Header Modifier LFB, DSCP value for a Remarker LFB. For such type of metadata not only that the value encoding must be explicitly provided in the metadata definition, the values cannot be selected arbitrarily, but rather they should conform to what is commonly expected. For example, a TTL increment metadata should encode with zero the no increment case, by one the single increment case, etc. A DSCP metadata should use 0 to endoce DSCP=0, 1 to encode DSCP=1, etc. --=-UPpy7u1G58cs/pRaWxHI-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 23 14:06:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16528 for ; Fri, 23 Jan 2004 14:06:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6dn-0007Bj-00 for forces-archive@ietf.org; Fri, 23 Jan 2004 14:06:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6cr-00079E-00 for forces-archive@ietf.org; Fri, 23 Jan 2004 14:05:54 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6cH-00077L-00 for forces-archive@IETF.ORG; Fri, 23 Jan 2004 14:05:17 -0500 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.00CB33F6@cherry.ease.lsoft.com>; Fri, 23 Jan 2004 14:05:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69279815 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 23 Jan 2004 14:05:16 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 23 Jan 2004 14:05:16 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0NJ6a06012325 for ; Fri, 23 Jan 2004 19:06:36 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0NJ24TB018518 for ; Fri, 23 Jan 2004 19:02:11 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012311051325446 for ; Fri, 23 Jan 2004 11:05:13 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jan 2004 11:05:12 -0800 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: Protocol Selection Process: Merger Suggestion Thread-Index: AcPh49OOZz+IiUb0R3yokYJaOPLBjw== X-Priority: 1 Priority: Urgent Importance: high X-OriginalArrivalTime: 23 Jan 2004 19:05:13.0064 (UTC) FILETIME=[D435FE80:01C3E1E3] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8021CC3BF@orsmsx409.jf.intel.com> Date: Fri, 23 Jan 2004 11:05:12 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Protocol Selection Process: Merger Suggestion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, After reviewing the protocol submissions it appears that each of the proposals has valuable features that merit inclusion in the ForCES protocol. Patrick and I would like to urge the various authors to evaluate whether a merger of the protocols, selecting the best features of each, would be possible.=20 In order to expedite this process we are considering holding and interim working group meeting two weeks prior to the=20 next IETF where interested parties could meet for a day to focus on producing a "best of all worlds" proposal. Please contact Patrick or I if you would be interested in attending such a meeting. Thanks, David & Patrick co-chairs, IETF ForCES Working Group From owner-forces@PEACH.EASE.LSOFT.COM Sat Jan 31 17:22:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07955 for ; Sat, 31 Jan 2004 17:22:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An3VM-0006ID-00 for forces-archive@ietf.org; Sat, 31 Jan 2004 17:22:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An3UU-0006C5-00 for forces-archive@ietf.org; Sat, 31 Jan 2004 17:21:27 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1An3To-00065f-00 for forces-archive@IETF.ORG; Sat, 31 Jan 2004 17:20:44 -0500 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.00CC6CAF@cherry.ease.lsoft.com>; Sat, 31 Jan 2004 17:20:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 91452 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 31 Jan 2004 17:20:41 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 31 Jan 2004 17:20:41 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004013114213918:20089 ; Sat, 31 Jan 2004 14:21:39 -0800 References: <5.1.0.14.0.20040119184047.01acdcb0@localhost> 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 01/31/2004 02:21:39 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/31/2004 02:21:45 PM, Serialize complete at 01/31/2004 02:21:45 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1075587632.1031.225.camel@jzny.localdomain> Date: Sat, 31 Jan 2004 17:20:32 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: FE Capabilities and attributes section of the model draft Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040119184047.01acdcb0@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,FREE_TRIAL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Mon, 2004-01-19 at 18:56, Joel M. Halpern wrote: > Let me restate the questions, and try to provide the answers that motivated > me when I wrote the text: > > I used Oxygen to validate the schema, and to validate the sample against > the schema. Cut and paste errors may have crept in since. (Oxygen is > commercial, with a 30 day free trial. There are other good tools, such as > XMLspy.) > Just downloaded Oxygen and it doesnt validate for me either. I think it would be nice to have a validated XML in the text. Also nice to see the breakdowns of sections approach instead of one big doc. Comments: - Something bothering me is the FEattribute piece however many times i stared at it. So i figured i would start from the ground up. Is it fair to say that "capabilities constitute attributes". That once you give these attributes values or parametrize them as the FEAttributes branch does, then now you are talking about state - which may be more closer to implementation details than to a model. I am not saying i have an answer on what would be a good way to resolve this. I think the FECapabilities piece is well done. I just dont know what to make of the FEattributes - they dont taste too good. For example the FEAttributesType seems to be a scatter of a few things. Vendor, Model (maybe serial number and you could go further to say slotid etc) are more like Product Data (as in PCI VPD) whereas FEstatus seems to be an instanteous state of the FE and LFB* seem to be related instantiated LFB policies (or topologies). Its almost like FEAttributes is meant to be FERunningState. - The FE should probably have a name and provisioned numeric ID. - FEConfiguredNeighborType is also one of those things that doesnt seem to really fit in that picture. Some of the pieces seem to fit into three different possible LFBs: Port, Neighbor and i dont know if you want to call IP address provisioning as an LFB. Which seems to me like we need at least some base LFBs to always be in the FE (i.e MUST) to satisfy the basic model. So maybe we should head that way with the model. Other comments: 1. FE Attributes and Capabilities "A ForCES forwarding element handles traffic on behalf of a ForCES control element. While the standards will describe the protocol and mechanisms for this control, different implementations and different instances will have different capabilities" What is the last "instances" refering to? 1.4.2 "LFBsSupported, WriteableAttributes and ReadableAttributes." dont exist in the schema. I think you meant SupportedLFBs and SupportedAttributes. 1.4.2.1 - "LFBs supported clause" probably intended to say SupportedLFBs - Also would it not be OK to use CanOccurBefore and CanOccurAfter even for static topolgies as a way to capture the static topology? 1.4.2.2. SupportedLFBs and SupportedLFB I think each LFB with a name will end up getting some numeric ID probably issued by IANA. so a LFBId would be a good fit here. 1.4.2.5 - CanOccurBefore and CanOccurAfter: I think it would be good to state the "any" or wildcard behavior as well - maybe when these attributes are left out. 1.4.2.2.6. LFBClassCapabilities - What is this for? Wouldnt each LFB have its own config which is outside the scope of the model? 1.5 Sample FE Attribute Document - s/LFBInstance/LFBInstance (see, i read the whole thing if i can catch the above typo ;->) cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Jan 31 18:13:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10098 for ; Sat, 31 Jan 2004 18:13:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An4If-0003kq-00 for forces-archive@ietf.org; Sat, 31 Jan 2004 18:13:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An4Hk-0003ey-00 for forces-archive@ietf.org; Sat, 31 Jan 2004 18:12:21 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1An4HN-0003ZK-00 for forces-archive@IETF.ORG; Sat, 31 Jan 2004 18:11:57 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00CC6CB7@cherry.ease.lsoft.com>; Sat, 31 Jan 2004 18:11:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 94310 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 31 Jan 2004 18:11:46 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 31 Jan 2004 18:11:46 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6130318; Sat, 31 Jan 2004 18:11:46 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20040119184047.01acdcb0@localhost> <5.1.0.14.0.20040119184047.01acdcb0@localhost> 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.20040131175652.01936c48@localhost> Date: Sat, 31 Jan 2004 18:11:25 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: FE Capabilities and attributes section of the model draft Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1075587632.1031.225.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Thanks for taking the time to read this throughly and provide some useful comments. On the validation issue, we will need to work out procedures so that we verify that the pieces in the document pass validation. I will try to respond to your comments in line. Joel >Comments: >- Something bothering me is the FEattribute piece however many times i >stared at it. So i figured i would start from the ground up. >Is it fair to say that "capabilities constitute attributes". >That once you give these attributes values or parametrize them as the >FEAttributes branch does, then now you are talking about state - which >may be more closer to implementation details than to a model. >I am not saying i have an answer on what would be a good way to resolve >this. I think the FECapabilities piece is well done. I just dont know >what to make of the FEattributes - they dont taste too good. For example >the FEAttributesType seems to be a scatter of a few things. Vendor, >Model (maybe serial number and you could go further to say slotid etc) >are more like Product Data (as in PCI VPD) whereas FEstatus seems to >be an instanteous state of the FE and LFB* seem to be related >instantiated LFB policies (or topologies). Its almost like FEAttributes >is meant to be FERunningState. The FE Attributes are certainly related to the FE state. They are intended to model the state aspects of the FE as a whole that the CE will need cognizance of. The examples I included are pretty weak, but we assume that there will be some useful attributes. >- The FE should probably have a name and provisioned numeric ID. The FE presumably has / needs an identity. However, whether it needs a name, a numeric ID within the protocol, or merely an IP address is yet to be determined. If it is internal to the protocol, then it should be reflected in the model. >- FEConfiguredNeighborType is also one of those things that doesnt >seem to really fit in that picture. Some of the pieces seem to fit into >three different possible LFBs: Port, Neighbor and i dont know if you >want to call IP address provisioning as an LFB. Which seems to me like >we need at least some base LFBs to always be in the FE (i.e MUST) to >satisfy the basic model. So maybe we should head that way with the >model. I would be happy to leave out FE Configured Neighbors entirely. However, the working group consensus is that it is FE level information that the protocol needs to carry. If the protocol will carry it, the model should describe it. >Other comments: > >1. FE Attributes and Capabilities >"A ForCES forwarding element handles traffic on behalf of >a ForCES control element. While the standards will >describe the protocol and mechanisms for this control, >different implementations and different instances will >have different capabilities" > >What is the last "instances" refering to? What I was trying to say is that not only will differing designs of ForCES boxes have different capabilities, but sometimes within a design different specific boxes may have different capabilities (different customers might plug in more or less memory, allowing more or fewer LFBs in some designs.) There are a couple of cases where the text did not catch up with some last minute name changes. Thanks for noticing them, and we will fix them. >1.4.2.1 >- Also would it not be OK to use CanOccurBefore and CanOccurAfter >even for static topolgies as a way to capture the static topology? You could use CanOccurBefore and CanOccurAfter to represent the topology for static cases. But since that does not represent the precise topology, it seems better to set the "static topology" flag, and then use the attributes which describe the current topology to accurately describe the actual topology. (After all, one could have a situation where there well flexible instance connections but fixed type sequences. That would still be a dynamic topology, even if limited in the changes that the CE can make to it.) >1.4.2.2. SupportedLFBs and SupportedLFB > >I think each LFB with a name will end up getting some numeric ID >probably issued by IANA. so a LFBId would be a good fit here. You are probably right. But I wanted to wait until we had made protocol progress. After all, if we were to switch to XML on the wire we would probably use names instead of numbers. >1.4.2.5 >- CanOccurBefore and CanOccurAfter: I think it would be good to state >the "any" or wildcard behavior as well - maybe when these attributes >are left out. I thought I had specified the wildcard behavior. I will make sure it is in, as it is an important case. >1.4.2.2.6. LFBClassCapabilities >- What is this for? Wouldnt each LFB have its own config which is >outside the scope of the model? There are capabilities limitations that apply to an LFB Class even before there are any instances of the class. For example, the LFB Class may define a port group. The maximum number of ports allowed in that port group is an implementation specific LFB Class level capability. To phrase this differently, there are capability questions about an LFB Class that the CE may want / need to ask before it chooses to instantiate / examine any instances of that class in the FE. So there needs to be a table with an entry per LFB Class holding those pieces of capability information. This is something that caused us some confusion, and probably needs better explanatory text. I hope it will be easier to see once we have some LFB Library elements to look at. >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Jan 31 21:04:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16610 for ; Sat, 31 Jan 2004 21:04:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An6yI-0000C5-00 for forces-archive@ietf.org; Sat, 31 Jan 2004 21:04:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An6xP-00005Q-00 for forces-archive@ietf.org; Sat, 31 Jan 2004 21:03:32 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1An6wT-0007l5-00 for forces-archive@IETF.ORG; Sat, 31 Jan 2004 21:02:33 -0500 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.00CC6E54@cherry.ease.lsoft.com>; 1 Feb 2004 21:02:27 +1900 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 110254 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 31 Jan 2004 21:02:23 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 31 Jan 2004 21:02:23 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004013118032651:20300 ; Sat, 31 Jan 2004 18:03:26 -0800 References: <5.1.0.14.0.20040119184047.01acdcb0@localhost> <5.1.0.14.0.20040119184047.01acdcb0@localhost> <5.1.0.14.0.20040131175652.01936c48@localhost> 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 01/31/2004 06:03:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/31/2004 06:03:28 PM, Serialize complete at 01/31/2004 06:03:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1075600936.1036.298.camel@jzny.localdomain> Date: Sat, 31 Jan 2004 21:02:16 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: FE Capabilities and attributes section of the model draft Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040131175652.01936c48@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Sat, 2004-01-31 at 18:11, Joel M. Halpern wrote: > The FE Attributes are certainly related to the FE state. They are intended > to model the state aspects of the FE as a whole that the CE will need > cognizance of. Fine - its one of those greyish things. FEAttributesType could be abstracted further into three categories: - FEProductData = { vendor, model} - LFBpolicyData = { LFBInstances, LFBTopology} - FERunningState = { FEStatus, FEConfiguredNeighbor } I dont think youll have to change SupportedAttributes if you rearranged things. > The examples I included are pretty weak, but we assume that > there will be some useful attributes. The example is OK i found. There could be more. > > >- The FE should probably have a name and provisioned numeric ID. > > The FE presumably has / needs an identity. However, whether it needs a > name, a numeric ID within the protocol, or merely an IP address is yet to > be determined. If it is internal to the protocol, then it should be > reflected in the model. The name or ID i am refering to are for more for management purposes; Maybe its an implementation specific, so i will wait. I am not sure the model should really reflect (or dictate) the protocol. > I would be happy to leave out FE Configured Neighbors entirely. However, > the working group consensus is that it is FE level information that the > protocol needs to carry. If the protocol will carry it, the model should > describe it. > I see the value in having the detail but not sure thats where it fits from an abstraction level. Perhaps the Port and Neighbor information should be assumed to be very basic that they need to be in the model. The problem is that detail is redundant or seems to assume existence of knowledge elsewhere (example NeighborInterface which assumes a Port LFB). Do you foresee an FE with no port and Neighbordiscovery LFB? > >1.4.2.1 > >- Also would it not be OK to use CanOccurBefore and CanOccurAfter > >even for static topolgies as a way to capture the static topology? > > You could use CanOccurBefore and CanOccurAfter to represent the topology > for static cases. But since that does not represent the precise topology, > it seems better to set the "static topology" flag, and then use the > attributes which describe the current topology to accurately describe the > actual topology. By "current topology" above, do you mean whats described in LFBInstances and LFBTopology i.e "currently configured" topology policy? > (After all, one could have a situation where there well > flexible instance connections but fixed type sequences. That would still > be a dynamic topology, even if limited in the changes that the CE can make > to it.) > Heres an example of hardware i am aware of: LFBA->LFBB->LFBC->LFBD being valid as well as ability to remove one or both of LFBB and LFBC from a topolgy instance with no other sequences being valid. This is semi static. Is this what you are refering to above? > > >1.4.2.2. SupportedLFBs and SupportedLFB > > > >I think each LFB with a name will end up getting some numeric ID > >probably issued by IANA. so a LFBId would be a good fit here. > > You are probably right. But I wanted to wait until we had made protocol > progress. After all, if we were to switch to XML on the wire we would > probably use names instead of numbers. > That sounds reasonable, but again note that danger of tying the model to the protocol - dont make any assumptions about what representation is useful. Binary encoding is useful to avoid latencies. I think it is OK to have both binary and XML but the model shouldnt assume one or the other - and if you end up predicting wrong, it wouldnt harm to waste another 32 bit (since you are gracious to waste more with XML;->). Whether its a name or ID or both someone is going to have to maintain them for sanity purposes. > > >1.4.2.2.6. LFBClassCapabilities > >- What is this for? Wouldnt each LFB have its own config which is > >outside the scope of the model? > > There are capabilities limitations that apply to an LFB Class even before > there are any instances of the class. For example, the LFB Class may > define a port group. The maximum number of ports allowed in that port > group is an implementation specific LFB Class level capability. To phrase > this differently, there are capability questions about an LFB Class that > the CE may want / need to ask before it chooses to instantiate / examine > any instances of that class in the FE. So there needs to be a table with > an entry per LFB Class holding those pieces of capability information. > This is something that caused us some confusion, and probably needs better > explanatory text. I hope it will be easier to see once we have some LFB > Library elements to look at. > I think i am still confused. Will wait for those library elements. cheers, jamal