From mailman-owner@ietf.org Sat Jun 1 06:23:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16032 for ; Sat, 1 Jun 2002 06:23:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21016 for ; Sat, 1 Jun 2002 06:23:43 -0400 (EDT) Date: Sat, 1 Jun 2002 06:23:43 -0400 (EDT) Message-Id: <200206011023.GAA21016@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: dhc-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhc-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive@lists.ietf.org From dhcwg-admin@ietf.org Tue Jun 4 17:54:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17306; Tue, 4 Jun 2002 17:54:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25428; Tue, 4 Jun 2002 17:53:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25237 for ; Tue, 4 Jun 2002 17:46:12 -0400 (EDT) Received: from mail.mysolutions.biz (e-203-110-biz.mts.net [216.55.203.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16957 for ; Tue, 4 Jun 2002 17:45:41 -0400 (EDT) Received: from tim by mysolutions.biz with SMTP (MDaemon.PRO.v5.0.1.R) for ; Tue, 04 Jun 2002 16:45:34 -0500 From: "Tim Friesen" To: Date: Tue, 4 Jun 2002 14:34:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Return-Path: tim.friesen@mysolutions.biz X-MDaemon-Deliver-To: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP server Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi there. I am trying to configure a specialized dhcp server for my network. The server is being used in conjunction with ip masquerading and a transparent web proxy for a school. It has one external network interface, and 2 internal network interfaces, each on different subnets. I want to create 2 completely separate networks, one for students, and one for teachers. The reason for this is because of content filtering for the students on one interface, and no filtering on the other interface, used for administration/teacher use. I am wondering how i can create a dhcp configuration on my redhat 7.3 server, that will assign the appropriate ip address to a connected host depending on what internal interface of the server they are connected to. for example: eth1 on my server lies on the subnet 192.168.5.0 with mask of 255.255.255.0. i want to assign ip address in the 192.168.5.100-254 range for that interface. the other interface (eth2) lies on 192.168.6.0 with mask 255.255.255.0. Is there a way to specify manually what interface can assign addresses to one subnet and the other assign addresses to the other interface? Thanks for you help. SOLUTIONS Tim Friesen Linux + Computer Service 325-7536 tim.friesen@mysolutions.biz _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 4 21:10:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21062; Tue, 4 Jun 2002 21:10:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04831; Tue, 4 Jun 2002 21:09:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04805 for ; Tue, 4 Jun 2002 21:09:22 -0400 (EDT) Received: from manta.infocus.com (moray.infocus.com [209.84.97.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21034 for ; Tue, 4 Jun 2002 21:08:52 -0400 (EDT) Received: by manta.infocus.com (Postfix, from userid 5) id EBAEF27848; Tue, 4 Jun 2002 18:09:20 -0700 (PDT) Received: from sonata.infocus.com(200.1.10.70), claiming to be "sonata.infocuscorp.com" via SMTP by manta.infocus.com, id smtpdAAA1LMdY_; Tue Jun 4 18:09:17 2002 Received: by sonata with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 18:05:46 -0700 Message-ID: From: Chris Pearson To: "'dhcwg@ietf.org'" Cc: De Tran Date: Tue, 4 Jun 2002 18:07:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] Choosing a value for option 60 (Vendor Class ID) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Greetings to the work group! This is my first post, so please let me know if I'm off-topic. After grepping the Web and parsing the thread "Interpretation of Option 60 (Vendor Class ID)" from this list, I'm pretty certain I know the answer to this question ("no"), but in the spirit of leaving no stone unturned, I'll ask it anyway: Is there a standard, IANA registry, best practice or convention regarding the values that clients may assign to vendor class ID? In the case I'm presently concerned with, the ID will be embedded in firmware and thus unchangeable in the field, so it's important to get it right. The main goal is to reduce probability of collision with other vendor IDs, and more generally, to harmonize with prevailing wisdom. (But re the character string vs. octet string question, I'm convinced that interoperation with major DHCP server implementations requires the former interpretation.) Any and all comments appreciated. -- Chris Pearson _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 5 00:04:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24701; Wed, 5 Jun 2002 00:04:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14745; Wed, 5 Jun 2002 00:03:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14713 for ; Wed, 5 Jun 2002 00:03:10 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24684 for ; Wed, 5 Jun 2002 00:02:36 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-236.cisco.com [10.82.224.236]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA12470; Wed, 5 Jun 2002 00:02:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20020604235847.038ade40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Jun 2002 00:02:18 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 Cc: dhcwg@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thanks for your careful review and helpful comments. We've reviewed your comments and included our responses in line below. www.dhcp.org/draft-26.txt reflects the changes described in this response. - Ralph ===== Message 1: ---------- Other questions to this section: - what should the receiving server do if the Information-request contains a client Identifier option? I think the server MUST copy the option to the reply, but the draft does not mention this case. - what should the receiving server do if the Information-request contains an IA option? Section 18.1.5 says that: The client MUST NOT include any IA options. But none of this section and Section 15.12 mention this case. We've fixed these specific problems. BTW: there seem to me several cases for this type of incompleteness. For example, Section 22.6 says "The IA Address option must be encapsulated in the Options field of an Identity Association option." But I'm not sure what a node should do when it receives an IA address option not encapsulated in an IA option. I've not gone through the entire draft, so I may miss something, and if so, I'd apologize in advance. If my guess is correct, however, then I'd suggest to check the consistency of the requirements over the entire draft. The "UnSpecFail" status code is available to indicate a problem with the DHCP option where the action for that problem is not specifically described in the doc. Message 2: ---------- 1. Section 4.1. defines binding A binding (or, client binding) is a group of server data records containing the information the server has about the addresses in an IA and any other configuration information assigned to the client. A binding is indexed by the tuple (where IA-type is the type of address in the IA; for example, temporary) Is it always appropriate to contain "IA-TYPE" and "IAID" in the index of a binding? What if a configuration information (that needs a binding) is not associated with an IA? An IPv6 prefix delegated by DHCPv6 can be an example of such binding. Changed definition of binding to: binding A binding (or, client binding) is a group of server data records containing the information the server has about the addresses in an IA or configuration information assigned to the client. A binding containing information about an IA is indexed by the tuple (where IA-type is the type of address in the IA; for example, temporary). A binding containing configuration information for a client is indexed by . 2. Section 15.13. says Clients MUST discard any received Relay-forward messages. What if a relay agent receives a relay-forward message? We have added new text that addresses "chaining" of relay agents; that is, the ability of one relay agent to send a relay-forward message to another relay agent. 4. Section 17.1. says A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. The wording is too specific. Since the client may just need other information than addresses, the text should be like "DHCP servers configured to server addresses or other configuration parameters...". Right; fixed... 5. Section 17.1.1. says The client MAY include options with data values as hints to the server about parameter values the client would like to have returned. I'm not sure how the data values are specified. An option request option can only specify required option "types"... The same comments applies to Sections 18.1.1 and 18.1.5. The client includes the requested option (rather than indicating the option in the Option Request option), containing the desired option value. 6. Section 17.1.3 says The client MUST ignore any Advertise message that includes a Status Code option containing the value AddrUnavail, with the exception that the client MAY display the associated status message to the user. and Section 17.2.2 has a corresponding text: If the server will not assign any addresses to IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a status code option with the status code set to AddrUnavail and a status message for the user. With the specification, it seems to me that a client cannot configure itself without getting addresses (except via information-request and reply exchanges). For example, suppose that a client wants to be delegated an IPv6 prefix from a provider, and sends a solicit without any IA option. The server is configured to delegate prefixes only (i.e. not addresses), so it sends an Advertise message with an AddrUnavail code. Since the client MUST ignore the advertise message, it cannot proceed any more. So, the specification should be clearer on the procedure when a client does not need addresses. Text in 17.2.2 clarified to specify that server returns AddrUnavail only if the client included IA options in the Solicit message. 7. What if a reply message for a solicit with a rapid commit option does *not* contain a rapid commit option? Section 17.2.3 says that the server includes a Rapid Commit option in the Reply message, but Section 17.1.4 says nothing about the case if the rapid commit option is not included. Added a sentence requiring a client to discard any Reply messages that do not include a Rapid Commit option. 8. It is not very clear when a server includes a Server Unicast option. Section 18.1.1 (and some succeeding sections) says Use of multicast or anycast on a link and relay agents enables the inclusion of relay agent options in all messages sent by the client. The server should enable the use of unicast only when relay agent options will not be used. But, this only talks about some restrictions of including the option. Even with the text of section 22.13, I'm still not sure when a server should or can send a Server Unicast option. It would be better to describe the allowed (or necessary) cases explicitly. Added the sentence: "Use of unicast may avoid delays due to forwarding of messages by relay agents as well as avoid overhead and duplicate responses by servers due to delivery of client messages to multiple servers." to each of the DISCUSSION paragraphs explaining the use of the Unicast option. 9. (I've once pointed it out, but I'll do it again) Section 17.2.2 says If the Solicit message was received directly by the server,...The Advertise message MUST be unicast through the interface on which the Solicit message was received. Technically, the requirement is too strong, since links are larger than interfaces according to the IPv6 scoped address architecture. So, more accurately, it should say "The Advertise message MUST be unicast through the link on which the Solicit message was received." (Also see the last paragraph of Section 16.) We used the more specific requirement to avoid the problem of a client sending a DHCP message on an incorrect interface because the client had incorrect configuration information about two interfaces being on the same link. 10. Section 18.2.1 says When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a status code option with value UseMulticast and no other options. I'm not sure how the client should act when it receives the reply message. Should it resend the request to multicast? Should it restart the entire procedure from the solicit? At least Section 18.1.6 should mention this case. The same comment applies to Sections 18.2.3, 18.2.6, and 18.2.7. Fixed with the following text: When the client receives a Reply message with a Status Code UseMulticast option, the client records the receipt of the message and sends subsequent messages through that interface using multicast. The client resends the original message using multicast. 11. Section 18.2.6 says "The server ignores invalid addresses." What does "invalid" exactly mean? In particular, I'm not sure if the source address of the receipt message is "invalid" or not (note that section 18.1.7 prohibits the client to use addresses being released as the source address). The text should clearly define the term "invalid". The same comment applies to Section 18.2.7. The phrase "invalid addresses" has been clarified. 12. Section 19.1.1 says "The server sets the transaction-id field to 0". But I could not found description about the case where the client receives a reconfigure message with a non-0 transaction-id. Should it discard the message, or should it ignore the non-0 value, or others? Added sentence specifying that the client ignores the transaction-id field in received Reconfigure messages. 13. Why doesn't the timeout and retransmission rule in Section 19.1.2 follow the general rules described in Section 14? Is there something special for reconfigure messages? The randomization is not required as Reconfigure messages won't be synchronized by some external event. Message 3: ---------- (1) If the client sent a solicit message with a rapid commit option but the server responds to the solicitation with an advertise message, what should the client do? Should it ignore the advertise, should it accept the advertise and send a request, or others? Section 17.1.4 says ...If the client does not receive a Reply message, the client restarts the server solicitation process by sending a Solicit message that does not include a Rapid Commit option. So, the client should probably ignore the advertise (and keep waiting for a reply.) But I'm not 100% sure about this. Section 17.1.4 is clarified to allow a client to use an Advertise message in this case if it receives no Reply with a Rapid Commit option. (2) Section 17.1.2 says: If the client is waiting for an Advertise message, the mechanism in section 14 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before IRT has elapsed. Rather, the client collects Advertise messages until IRT has elapsed. Should this rule apply if the client is retransmitting solicit messages? For example, suppose that there is no advertise in response to the first solicit, and so the client retransmit the solicit. If the client then receives a first advertise, should it still wait until IRT elapses? A couple of paragraphs farther down in 17.1.2 is this text: If the client does not receive any Advertise messages before the first RT has elapsed, it begins the retransmission mechanism described in section 14. The client terminates the retransmission process as soon as it receives any Advertise message, and the client acts on the received Advertise message without waiting for any additional Advertise messages. This text is intended to address the question you raise. (3) The paragraph above then says: Also, the first RT MUST be selected to be strictly greater than IRT by choosing RAND to be strictly greater than 0. However, according to Section 13, the first RT should be RT = 2*IRT + RAND*IRT where RAND is a random number chosen with a uniform distribution between -0.1 and +0.1. Thus, RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT (the rightmost '=' is satisfied only when IRT is 0) So the RT should always be greater than IRT regardless of the value of RAND, and "by choosing RAND to be strictly greater than 0" seems to be redundant. Is my understanding correct? The initial choice of RT included a typo; it should (and now does) read: RT = IRT + RAND*IRT Message 4: ---------- Section 18.2.1 of dhcpv6-24 says: When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a status code option with value UseMulticast and no other options. On the other hand, section 15.10 says - the message does not include a Server Identifier option (snip) - the message does not include a Client Identifier option and the original message from the client contained a Client Identifier option Those two requirements seem to be inconsistent, or at least be confusing. Should the reply message contain the Server Identifier option (and the Client Identifier option if the original message contained it) in the Reply even if the server is responding with a status code option with UseMulticast? Or should the client loosen the validation in 15.10 if the reply contains a status code option? Or others? Clarified to allow additional options; paragraph now reads: When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a Status Code option with value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message and no other options. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 5 00:35:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26116; Wed, 5 Jun 2002 00:35:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16208; Wed, 5 Jun 2002 00:35:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16174 for ; Wed, 5 Jun 2002 00:35:31 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26077 for ; Wed, 5 Jun 2002 00:35:01 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-232.cisco.com [10.82.224.232]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA14555; Wed, 5 Jun 2002 00:34:57 -0400 (EDT) Message-Id: <4.3.2.7.2.20020605003413.00b48808@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Jun 2002 00:34:52 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 Cc: dhcwg@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Responses to your other comments: 15. What if a client receives a reconfigure message but none of the configuration information was provided by the server (that sends the reconfigure)? What if only a part of the configuration information was provided by the server? Section 19.3.1 is not clear (enough) about the cases. Are you asking what the client should do if the server's Reply message doesn't include all the configuration information specified by the client in the Request or Information-request message? 16. (Relevant to the comment 12 above) Section 19.3.1 says the client ignores any additional Reconfigure messages (regardless of the transaction ID in the Reconfigure message) until the exchange is complete. Subsequent Reconfigure messages (again independent of the transaction ID) cause the client to initiate a new exchange. But, according to Section 19.1.1, the transaction ID should always be 0. So I don't get the rationale about the wording here. Does this simply mean the client should always ignore the transaction-ID? If so, it seems to me more natural to say so explicitly. You are correct; wording fixed. 17. Section 21.5.2 says A DHCP message MUST NOT contain more than one Authentication option when using the delayed authentication protocol. Then, what if a received message contains more than one Authentication option? Ignore the entire message, ignore the authentication options (but a particular one), or others? Added text to section "Message Validation": Any DHCP message that includes more than one authentication option MUST be discarded. (an editorial comment) we need some additional white space in this paragraph: ... in the DHCP message to facilitate processing of the authentication information.The format of the Authentication... after "information". Fixed (deleted sentence specifying placement of authentication option). 18. Section 21.5.3 says receiver computes the MAC as described in [9]. The entire DHCP message (except the MAC field of the authentication option itself), is used as input to the HMAC-MDS computation function. This is not very clear to me. Does this mean we should regard the MAC field as an all-0 field when computation? Text about MAC field in MAC computation has been clarified. 19. We need a closing parenthesis in the first sentence of Section 21.5.5.4: If the server has selected a key for the client in a previous message exchange (see section 21.5.6.1, the client MUST use the same key to generate the authentication information. The appropriate point should be after "21.5.6.1". Fixed. 20. Section 22.5 says An identity association for temporary addresses option MUST NOT appear in a Renew or Rebind message. What should the receiving node do if this condition is broken? IA_TA now allowed in Renew or Rebind; DHCP allows lifetimes of temporary addresses to be extended. 21. Section 22.14 specifies to use a UTF-8 encoded text string, but it seems to me too much. I think a simple ascii text is enough. (However, this may be based on a consensus of a former discussion, and if so, I don't oppose to the result.) The DHC WG as settled on UTF-8 for text strings like this... 22. Section 22.17 says A DHCP message MUST NOT contain more than one Vendor Class option. What should the receiving node do if this condition is broken? 23. Section 22.18 says A DHCP message MUST NOT contain more than one Vendor-specific Information option with the same Enterprise Number. What should the receiving node do if this condition is broken? (See below) 24. Section 22.19 says This option MUST NOT appear in any message except a Relay-Forward or Relay-Reply message. What should the receiving node do if this condition is broken? (This question should be extended in a general form; "what should the receiving node do if an option is included in a message in which the option MUST NOT be appeared?") In general, the decision about how to proceed with messages that don't adhere to the rules about option inclusion - for example, if the message includes more than one Vendor-specific Information option with the same Enterprise number - is a policy decision for the DHCP server. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 5 03:13:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21730; Wed, 5 Jun 2002 03:13:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15425; Wed, 5 Jun 2002 03:11:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15350 for ; Wed, 5 Jun 2002 03:11:16 -0400 (EDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21703 for ; Wed, 5 Jun 2002 03:10:39 -0400 (EDT) Received: from galadriel ([172.16.3.219]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA03298; Wed, 5 Jun 2002 15:05:33 +0800 (SGT) Message-ID: <010c01c20c5f$08ff2300$db0310ac@galadriel> From: "Raymond Jayaraj" To: "Ralph Droms" , Cc: References: <4.3.2.7.2.20020604235847.038ade40@funnel.cisco.com> Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 Date: Wed, 5 Jun 2002 15:03:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi guys, > Changed definition of binding to: > > binding A binding (or, client binding) is a group of server data > records containing the information the server has about > the addresses in an IA or configuration information > assigned to the client. A binding containing > information about an IA is indexed by the tuple IA-type, IAID> (where IA-type is the type of address in > the IA; for example, temporary). A binding containing > configuration information for a client is indexed by > . Sorry to barge in like this; but we're also hot on the heels of implementing (and verifying) DHC6, and would like to confirm if: By the change in the definition as above, a node can use stateless (RA) address(es) yet maintain (RENEW/REBIND applies) stateful, address-unrelated, context/configuration (e.g. roaming, security, qos, billing, mobility etc.) information with the network via DHC6? We've been trying to figure out other ways to accomplish this, but always end up with sub-optimal methods. It would be neat if DHC6 can be extended to this end; then there won't be need to define additional edge access / "network session" protocols - just more DHC6 options (IMHO). Raymond Jayaraj Institute For Communications Research Agency For Science, Technology & Research Singapore. ----- Original Message ----- From: "Ralph Droms" To: )> Cc: Sent: Wednesday, June 05, 2002 12:02 PM Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 > Thanks for your careful review and helpful comments. We've > reviewed your comments and included our responses in line > below. www.dhcp.org/draft-26.txt reflects the changes > described in this response. > > - Ralph > > ===== > Message 1: > ---------- > Other questions to this section: > - what should the receiving server do if the Information-request > contains a client Identifier option? I think the server MUST > copy the option to the reply, but the draft does not mention this > case. > - what should the receiving server do if the Information-request > contains an IA option? Section 18.1.5 says that: > The client MUST NOT include any IA options. > But none of this section and Section 15.12 mention this case. > > We've fixed these specific problems. > > BTW: there seem to me several cases for this type of incompleteness. > For example, Section 22.6 says "The IA Address option must be > encapsulated in the Options field of an Identity Association option." > But I'm not sure what a node should do when it receives an IA address > option not encapsulated in an IA option. I've not gone through the > entire draft, so I may miss something, and if so, I'd apologize in > advance. If my guess is correct, however, then I'd suggest to check > the consistency of the requirements over the entire draft. > > The "UnSpecFail" status code is available to indicate a problem with > the DHCP option where the action for that problem is not specifically > described in the doc. > > Message 2: > ---------- > 1. Section 4.1. defines > > binding A binding (or, client binding) is a > group of server data records containing > the information the server has about > the addresses in an IA and any other > configuration information assigned to > the client. A binding is indexed by > the tuple (where > IA-type is the type of address in the > IA; for example, temporary) > > Is it always appropriate to contain "IA-TYPE" and "IAID" in the index > of a binding? What if a configuration information (that needs a > binding) is not associated with an IA? An IPv6 prefix delegated by > DHCPv6 can be an example of such binding. > > Changed definition of binding to: > > binding A binding (or, client binding) is a group of server data > records containing the information the server has about > the addresses in an IA or configuration information > assigned to the client. A binding containing > information about an IA is indexed by the tuple IA-type, IAID> (where IA-type is the type of address in > the IA; for example, temporary). A binding containing > configuration information for a client is indexed by > . > > 2. Section 15.13. says > > Clients MUST discard any received Relay-forward messages. > > What if a relay agent receives a relay-forward message? > > We have added new text that addresses "chaining" of relay agents; that > is, the ability of one relay agent to send a relay-forward message to > another relay agent. > > 4. Section 17.1. says > > A client uses the Solicit message to discover DHCP servers configured > to serve addresses on the link to which the client is attached. > > The wording is too specific. Since the client may just need other > information than addresses, the text should be like "DHCP servers > configured to server addresses or other configuration > parameters...". > > Right; fixed... > > 5. Section 17.1.1. says > > The client MAY include > options with data values as hints to the server about parameter > values the client would like to have returned. > > I'm not sure how the data values are specified. An option request > option can only specify required option "types"... > > The same comments applies to Sections 18.1.1 and 18.1.5. > > The client includes the requested option (rather than indicating the > option in the Option Request option), containing the desired option > value. > > 6. Section 17.1.3 says > > The client MUST ignore any Advertise message that includes a Status > Code option containing the value AddrUnavail, with the exception that > the client MAY display the associated status message to the user. > > and Section 17.2.2 has a corresponding text: > > If the server will not assign any addresses to IAs in a subsequent > Request from the client, the server MUST send an Advertise message to > the client that includes only a status code option with the status > code set to AddrUnavail and a status message for the user. > > With the specification, it seems to me that a client cannot configure > itself without getting addresses (except via information-request and > reply exchanges). For example, suppose that a client wants to be > delegated an IPv6 prefix from a provider, and sends a solicit without > any IA option. The server is configured to delegate prefixes only > (i.e. not addresses), so it sends an Advertise message with an > AddrUnavail code. Since the client MUST ignore the advertise message, > it cannot proceed any more. > > So, the specification should be clearer on the procedure when a client > does not need addresses. > > Text in 17.2.2 clarified to specify that server returns AddrUnavail > only if the client included IA options in the Solicit message. > > 7. What if a reply message for a solicit with a rapid commit option > does *not* contain a rapid commit option? Section 17.2.3 says that > the server includes a Rapid Commit option in the Reply message, but > Section 17.1.4 says nothing about the case if the rapid commit > option is not included. > > Added a sentence requiring a client to discard any Reply messages that > do not include a Rapid Commit option. > > 8. It is not very clear when a server includes a Server Unicast > option. Section 18.1.1 (and some succeeding sections) says > > Use of multicast or anycast on a link and relay agents > enables the inclusion of relay agent options in all messages > sent by the client. The server should enable the use of > unicast only when relay agent options will not be used. > > But, this only talks about some restrictions of including the > option. Even with the text of section 22.13, I'm still not sure > when a server should or can send a Server Unicast option. It > would be better to describe the allowed (or necessary) cases > explicitly. > > Added the sentence: "Use of unicast may avoid delays due to forwarding > of messages by relay agents as well as avoid overhead and duplicate > responses by servers due to delivery of client messages to multiple > servers." to each of the DISCUSSION paragraphs explaining the use of > the Unicast option. > > 9. (I've once pointed it out, but I'll do it again) Section 17.2.2 > says > > If the Solicit message was received directly by the > server,...The Advertise message MUST be unicast through the > interface on which the Solicit message was received. > > Technically, the requirement is too strong, since links are larger > than interfaces according to the IPv6 scoped address architecture. > So, more accurately, it should say "The Advertise message MUST be > unicast through the link on which the Solicit message was received." > (Also see the last paragraph of Section 16.) > > We used the more specific requirement to avoid the problem of a client > sending a DHCP message on an incorrect interface because the client > had incorrect configuration information about two interfaces being on > the same link. > > 10. Section 18.2.1 says > > When the server receives a Request message via unicast from a > client to which the server has not sent a unicast option, the server > discards the Request message and responds with a Reply message > containing a status code option with value UseMulticast and no other > options. > > I'm not sure how the client should act when it receives the reply > message. Should it resend the request to multicast? Should it > restart the entire procedure from the solicit? At least Section > 18.1.6 should mention this case. > > The same comment applies to Sections 18.2.3, 18.2.6, and 18.2.7. > > Fixed with the following text: > > When the client receives a Reply message with a Status Code > UseMulticast option, the client records the receipt of the > message and sends subsequent messages through that interface using > multicast. The client resends the original message using multicast. > > 11. Section 18.2.6 says "The server ignores invalid addresses." What > does "invalid" exactly mean? In particular, I'm not sure if the > source address of the receipt message is "invalid" or not (note > that section 18.1.7 prohibits the client to use addresses being > released as the source address). The text should clearly define > the term "invalid". > > The same comment applies to Section 18.2.7. > > The phrase "invalid addresses" has been clarified. > > 12. Section 19.1.1 says "The server sets the transaction-id field to > 0". But I could not found description about the case where the > client receives a reconfigure message with a non-0 transaction-id. > Should it discard the message, or should it ignore the non-0 > value, or others? > > Added sentence specifying that the client ignores the transaction-id > field in received Reconfigure messages. > > 13. Why doesn't the timeout and retransmission rule in Section 19.1.2 > follow the general rules described in Section 14? Is there > something special for reconfigure messages? > > The randomization is not required as Reconfigure messages won't be > synchronized by some external event. > > Message 3: > ---------- > (1) If the client sent a solicit message with a rapid commit option > but the server responds to the solicitation with an advertise > message, what should the client do? Should it ignore the > advertise, should it accept the advertise and send a request, or > others? Section 17.1.4 says > > ...If the client does not > receive a Reply message, the client restarts the server solicitation > process by sending a Solicit message that does not include a Rapid > Commit option. > > So, the client should probably ignore the advertise (and keep > waiting for a reply.) But I'm not 100% sure about this. > > Section 17.1.4 is clarified to allow a client to use an Advertise > message in this case if it receives no Reply with a Rapid Commit > option. > > (2) Section 17.1.2 says: > > If the client is waiting for an Advertise message, the mechanism in > section 14 is modified as follows for use in the transmission of > Solicit messages. The message exchange is not terminated by the > receipt of an Advertise before IRT has elapsed. Rather, the client > collects Advertise messages until IRT has elapsed. > > Should this rule apply if the client is retransmitting solicit > messages? For example, suppose that there is no advertise in response > to the first solicit, and so the client retransmit the solicit. If > the client then receives a first advertise, should it still wait until > IRT elapses? > > A couple of paragraphs farther down in 17.1.2 is this text: > > If the client does not receive any Advertise messages before > the first RT has elapsed, it begins the retransmission mechanism > described in section 14. The client terminates the retransmission > process as soon as it receives any Advertise message, and the client > acts on the received Advertise message without waiting for any > additional Advertise messages. > > This text is intended to address the question you raise. > > (3) The paragraph above then says: > Also, the first > RT MUST be selected to be strictly greater than IRT by choosing RAND > to be strictly greater than 0. > > However, according to Section 13, the first RT should be > > RT = 2*IRT + RAND*IRT > > where RAND is a random number chosen with a uniform distribution > between -0.1 and +0.1. Thus, > > RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT > (the rightmost '=' is satisfied only when IRT is 0) > > So the RT should always be greater than IRT regardless of the value of > RAND, and "by choosing RAND to be strictly greater than 0" seems to be > redundant. Is my understanding correct? > > The initial choice of RT included a typo; it should (and now does) > read: > > RT = IRT + RAND*IRT > > Message 4: > ---------- > Section 18.2.1 of dhcpv6-24 says: > > When the server receives a Request message via unicast from a > client to which the server has not sent a unicast option, the server > discards the Request message and responds with a Reply message > containing a status code option with value UseMulticast and no other > options. > > On the other hand, section 15.10 says > > - the message does not include a Server Identifier option > (snip) > - the message does not include a Client Identifier option and the > original message from the client contained a Client Identifier > option > > Those two requirements seem to be inconsistent, or at least be > confusing. Should the reply message contain the Server Identifier > option (and the Client Identifier option if the original message > contained it) in the Reply even if the server is responding with a > status code option with UseMulticast? Or should the client loosen the > validation in 15.10 if the reply contains a status code option? Or > others? > > Clarified to allow additional options; paragraph now reads: > > When the server receives a Request message via unicast from a > client to which the server has not sent a unicast option, the server > discards the Request message and responds with a Reply message > containing a Status Code option with value UseMulticast, a Server > Identifier option containing the server's DUID, the Client Identifier > option from the client message and no other options. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 5 03:39:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22049; Wed, 5 Jun 2002 03:39:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16909; Wed, 5 Jun 2002 03:38:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16879 for ; Wed, 5 Jun 2002 03:38:20 -0400 (EDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22034 for ; Wed, 5 Jun 2002 03:37:20 -0400 (EDT) Received: from galadriel ([172.16.3.219]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA06276 for ; Wed, 5 Jun 2002 15:36:27 +0800 (SGT) Message-ID: <012601c20c63$5a786350$db0310ac@galadriel> From: "Raymond Jayaraj" To: Date: Wed, 5 Jun 2002 15:33:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHC6 INFORMATION-IND Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, The INFORMATION-REQ/REPLY messages make DHC6 really neat in terms of extensibility. But wouldn't it be great to also have unidirectional (i.e, no REPLY required) information indication messages (INFO-IND), such that information exchange patterns as below can take place: ` ` ` ` ` ` ` ` ` ` ` `DHC6C DHC6S` ` -+- -+-` ` | INFO-IND | ` ` +------------->| ` ` | INFO-IND | ` ` +------------->| ` ` | INFO-IND | ` ` +------------->| ` ` | SVR-RECFG | ` ` |<-------------+ ` ` | | ` ` ` ` ` ` ` ` ` ` ` ` DHC6C - dhcpv6 client DHC6S - dhcpv6 server Such patterns may be useful for on-the-fly configurations, especially in the mobile case. All IMHO, okay, so don't whack me if I said something out of place... Raymond Jayaraj Institute For Communications Research Agency For Science, Technology & Research Singapore. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 5 03:44:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22155; Wed, 5 Jun 2002 03:44:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17171; Wed, 5 Jun 2002 03:43:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17141 for ; Wed, 5 Jun 2002 03:43:24 -0400 (EDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22140 for ; Wed, 5 Jun 2002 03:42:50 -0400 (EDT) Received: from galadriel ([172.16.3.219]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA06718; Wed, 5 Jun 2002 15:41:20 +0800 (SGT) Message-ID: <013801c20c64$09121c80$db0310ac@galadriel> From: "Raymond Jayaraj" To: "Ralph Droms" , Cc: Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 Date: Wed, 5 Jun 2002 15:38:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit (This is a resend, in plain text, of an earlier HTML email) Hi guys, > Changed definition of binding to: > > binding A binding (or, client binding) is a group of server data > records containing the information the server has about > the addresses in an IA or configuration information > assigned to the client. A binding containing > information about an IA is indexed by the tuple IA-type, IAID> (where IA-type is the type of address in > the IA; for example, temporary). A binding containing > configuration information for a client is indexed by > . Sorry to barge in like this; but we're also hot on the heels of implementing (and verifying) DHC6, and would like to confirm if: By the change in the definition as above, a node can use stateless (RA) address(es) yet maintain (RENEW/REBIND applies) stateful, address-unrelated, context/configuration (e.g. roaming, security, qos, billing, mobility etc.) information with the network via DHC6? We've been trying to figure out other ways to accomplish this, but always end up with sub-optimal methods. It would be neat if DHC6 can be extended to this end; then there won't be need to define additional edge access / "network session" protocols - just more DHC6 options (IMHO). Raymond Jayaraj Institute For Communications Research Agency For Science, Technology & Research Singapore. ----- Original Message ----- From: "Ralph Droms" To: )> Cc: Sent: Wednesday, June 05, 2002 12:02 PM Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 > Thanks for your careful review and helpful comments. We've > reviewed your comments and included our responses in line > below. www.dhcp.org/draft-26.txt reflects the changes > described in this response. > > - Ralph > > ===== > Message 1: > ---------- > Other questions to this section: > - what should the receiving server do if the Information-request > contains a client Identifier option? I think the server MUST > copy the option to the reply, but the draft does not mention this > case. > - what should the receiving server do if the Information-request > contains an IA option? Section 18.1.5 says that: > The client MUST NOT include any IA options. > But none of this section and Section 15.12 mention this case. > > We've fixed these specific problems. > > BTW: there seem to me several cases for this type of incompleteness. > For example, Section 22.6 says "The IA Address option must be > encapsulated in the Options field of an Identity Association option." > But I'm not sure what a node should do when it receives an IA address > option not encapsulated in an IA option. I've not gone through the > entire draft, so I may miss something, and if so, I'd apologize in > advance. If my guess is correct, however, then I'd suggest to check > the consistency of the requirements over the entire draft. > > The "UnSpecFail" status code is available to indicate a problem with > the DHCP option where the action for that problem is not specifically > described in the doc. > > Message 2: > ---------- > 1. Section 4.1. defines > > binding A binding (or, client binding) is a > group of server data records containing > the information the server has about > the addresses in an IA and any other > configuration information assigned to > the client. A binding is indexed by > the tuple (where > IA-type is the type of address in the > IA; for example, temporary) > > Is it always appropriate to contain "IA-TYPE" and "IAID" in the index > of a binding? What if a configuration information (that needs a > binding) is not associated with an IA? An IPv6 prefix delegated by > DHCPv6 can be an example of such binding. > > Changed definition of binding to: > > binding A binding (or, client binding) is a group of server data > records containing the information the server has about > the addresses in an IA or configuration information > assigned to the client. A binding containing > information about an IA is indexed by the tuple IA-type, IAID> (where IA-type is the type of address in > the IA; for example, temporary). A binding containing > configuration information for a client is indexed by > . > > 2. Section 15.13. says > > Clients MUST discard any received Relay-forward messages. > > What if a relay agent receives a relay-forward message? > > We have added new text that addresses "chaining" of relay agents; that > is, the ability of one relay agent to send a relay-forward message to > another relay agent. > > 4. Section 17.1. says > > A client uses the Solicit message to discover DHCP servers configured > to serve addresses on the link to which the client is attached. > > The wording is too specific. Since the client may just need other > information than addresses, the text should be like "DHCP servers > configured to server addresses or other configuration > parameters...". > > Right; fixed... > > 5. Section 17.1.1. says > > The client MAY include > options with data values as hints to the server about parameter > values the client would like to have returned. > > I'm not sure how the data values are specified. An option request > option can only specify required option "types"... > > The same comments applies to Sections 18.1.1 and 18.1.5. > > The client includes the requested option (rather than indicating the > option in the Option Request option), containing the desired option > value. > > 6. Section 17.1.3 says > > The client MUST ignore any Advertise message that includes a Status > Code option containing the value AddrUnavail, with the exception that > the client MAY display the associated status message to the user. > > and Section 17.2.2 has a corresponding text: > > If the server will not assign any addresses to IAs in a subsequent > Request from the client, the server MUST send an Advertise message to > the client that includes only a status code option with the status > code set to AddrUnavail and a status message for the user. > > With the specification, it seems to me that a client cannot configure > itself without getting addresses (except via information-request and > reply exchanges). For example, suppose that a client wants to be > delegated an IPv6 prefix from a provider, and sends a solicit without > any IA option. The server is configured to delegate prefixes only > (i.e. not addresses), so it sends an Advertise message with an > AddrUnavail code. Since the client MUST ignore the advertise message, > it cannot proceed any more. > > So, the specification should be clearer on the procedure when a client > does not need addresses. > > Text in 17.2.2 clarified to specify that server returns AddrUnavail > only if the client included IA options in the Solicit message. > > 7. What if a reply message for a solicit with a rapid commit option > does *not* contain a rapid commit option? Section 17.2.3 says that > the server includes a Rapid Commit option in the Reply message, but > Section 17.1.4 says nothing about the case if the rapid commit > option is not included. > > Added a sentence requiring a client to discard any Reply messages that > do not include a Rapid Commit option. > > 8. It is not very clear when a server includes a Server Unicast > option. Section 18.1.1 (and some succeeding sections) says > > Use of multicast or anycast on a link and relay agents > enables the inclusion of relay agent options in all messages > sent by the client. The server should enable the use of > unicast only when relay agent options will not be used. > > But, this only talks about some restrictions of including the > option. Even with the text of section 22.13, I'm still not sure > when a server should or can send a Server Unicast option. It > would be better to describe the allowed (or necessary) cases > explicitly. > > Added the sentence: "Use of unicast may avoid delays due to forwarding > of messages by relay agents as well as avoid overhead and duplicate > responses by servers due to delivery of client messages to multiple > servers." to each of the DISCUSSION paragraphs explaining the use of > the Unicast option. > > 9. (I've once pointed it out, but I'll do it again) Section 17.2.2 > says > > If the Solicit message was received directly by the > server,...The Advertise message MUST be unicast through the > interface on which the Solicit message was received. > > Technically, the requirement is too strong, since links are larger > than interfaces according to the IPv6 scoped address architecture. > So, more accurately, it should say "The Advertise message MUST be > unicast through the link on which the Solicit message was received." > (Also see the last paragraph of Section 16.) > > We used the more specific requirement to avoid the problem of a client > sending a DHCP message on an incorrect interface because the client > had incorrect configuration information about two interfaces being on > the same link. > > 10. Section 18.2.1 says > > When the server receives a Request message via unicast from a > client to which the server has not sent a unicast option, the server > discards the Request message and responds with a Reply message > containing a status code option with value UseMulticast and no other > options. > > I'm not sure how the client should act when it receives the reply > message. Should it resend the request to multicast? Should it > restart the entire procedure from the solicit? At least Section > 18.1.6 should mention this case. > > The same comment applies to Sections 18.2.3, 18.2.6, and 18.2.7. > > Fixed with the following text: > > When the client receives a Reply message with a Status Code > UseMulticast option, the client records the receipt of the > message and sends subsequent messages through that interface using > multicast. The client resends the original message using multicast. > > 11. Section 18.2.6 says "The server ignores invalid addresses." What > does "invalid" exactly mean? In particular, I'm not sure if the > source address of the receipt message is "invalid" or not (note > that section 18.1.7 prohibits the client to use addresses being > released as the source address). The text should clearly define > the term "invalid". > > The same comment applies to Section 18.2.7. > > The phrase "invalid addresses" has been clarified. > > 12. Section 19.1.1 says "The server sets the transaction-id field to > 0". But I could not found description about the case where the > client receives a reconfigure message with a non-0 transaction-id. > Should it discard the message, or should it ignore the non-0 > value, or others? > > Added sentence specifying that the client ignores the transaction-id > field in received Reconfigure messages. > > 13. Why doesn't the timeout and retransmission rule in Section 19.1.2 > follow the general rules described in Section 14? Is there > something special for reconfigure messages? > > The randomization is not required as Reconfigure messages won't be > synchronized by some external event. > > Message 3: > ---------- > (1) If the client sent a solicit message with a rapid commit option > but the server responds to the solicitation with an advertise > message, what should the client do? Should it ignore the > advertise, should it accept the advertise and send a request, or > others? Section 17.1.4 says > > ...If the client does not > receive a Reply message, the client restarts the server solicitation > process by sending a Solicit message that does not include a Rapid > Commit option. > > So, the client should probably ignore the advertise (and keep > waiting for a reply.) But I'm not 100% sure about this. > > Section 17.1.4 is clarified to allow a client to use an Advertise > message in this case if it receives no Reply with a Rapid Commit > option. > > (2) Section 17.1.2 says: > > If the client is waiting for an Advertise message, the mechanism in > section 14 is modified as follows for use in the transmission of > Solicit messages. The message exchange is not terminated by the > receipt of an Advertise before IRT has elapsed. Rather, the client > collects Advertise messages until IRT has elapsed. > > Should this rule apply if the client is retransmitting solicit > messages? For example, suppose that there is no advertise in response > to the first solicit, and so the client retransmit the solicit. If > the client then receives a first advertise, should it still wait until > IRT elapses? > > A couple of paragraphs farther down in 17.1.2 is this text: > > If the client does not receive any Advertise messages before > the first RT has elapsed, it begins the retransmission mechanism > described in section 14. The client terminates the retransmission > process as soon as it receives any Advertise message, and the client > acts on the received Advertise message without waiting for any > additional Advertise messages. > > This text is intended to address the question you raise. > > (3) The paragraph above then says: > Also, the first > RT MUST be selected to be strictly greater than IRT by choosing RAND > to be strictly greater than 0. > > However, according to Section 13, the first RT should be > > RT = 2*IRT + RAND*IRT > > where RAND is a random number chosen with a uniform distribution > between -0.1 and +0.1. Thus, > > RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT > (the rightmost '=' is satisfied only when IRT is 0) > > So the RT should always be greater than IRT regardless of the value of > RAND, and "by choosing RAND to be strictly greater than 0" seems to be > redundant. Is my understanding correct? > > The initial choice of RT included a typo; it should (and now does) > read: > > RT = IRT + RAND*IRT > > Message 4: > ---------- > Section 18.2.1 of dhcpv6-24 says: > > When the server receives a Request message via unicast from a > client to which the server has not sent a unicast option, the server > discards the Request message and responds with a Reply message > containing a status code option with value UseMulticast and no other > options. > > On the other hand, section 15.10 says > > - the message does not include a Server Identifier option > (snip) > - the message does not include a Client Identifier option and the > original message from the client contained a Client Identifier > option > > Those two requirements seem to be inconsistent, or at least be > confusing. Should the reply message contain the Server Identifier > option (and the Client Identifier option if the original message > contained it) in the Reply even if the server is responding with a > status code option with UseMulticast? Or should the client loosen the > validation in 15.10 if the reply contains a status code option? Or > others? > > Clarified to allow additional options; paragraph now reads: > > When the server receives a Request message via unicast from a > client to which the server has not sent a unicast option, the server > discards the Request message and responds with a Reply message > containing a Status Code option with value UseMulticast, a Server > Identifier option containing the server's DUID, the Client Identifier > option from the client message and no other options. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 5 17:58:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22322; Wed, 5 Jun 2002 17:58:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04685; Wed, 5 Jun 2002 17:57:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04656 for ; Wed, 5 Jun 2002 17:57:46 -0400 (EDT) Received: from manta.infocus.com (moray.infocus.com [209.84.97.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22216 for ; Wed, 5 Jun 2002 17:57:16 -0400 (EDT) Received: by manta.infocus.com (Postfix, from userid 5) id 5A04127888; Wed, 5 Jun 2002 14:57:44 -0700 (PDT) Received: from sonata.infocus.com(200.1.10.70), claiming to be "sonata.infocuscorp.com" via SMTP by manta.infocus.com, id smtpdAAAyvMqM_; Wed Jun 5 14:57:35 2002 Received: by sonata with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 14:54:02 -0700 Message-ID: From: Chris Pearson To: "'Patrick Guelat'" Cc: "'dhcwg@ietf.org'" , De Tran Subject: RE: [dhcwg] Choosing a value for option 60 (Vendor Class ID) Date: Wed, 5 Jun 2002 14:55:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Patrick, Thanks, exactly the kind of feedback I'm looking for. In our case (targeting corporate intranets), we expect network admins to type our class identifier into DHCP server config UI, so we're somewhat concerned that it be "admin friendly" (terse and self-descriptive). Of course, there's always cut-n-paste, so maybe that's not so important. Thanks again for the response. Regards, Chris -----Original Message----- From: Patrick Guelat [mailto:patg@imp.ch] Sent: Wednesday, June 05, 2002 10:25 AM To: Chris Pearson Cc: 'dhcwg@ietf.org'; De Tran Subject: Re: [dhcwg] Choosing a value for option 60 (Vendor Class ID) Hi I'm working in the Cable modem field and the DOCSIS1.1 specification requires the use of option 60. cablemodems report their capabilities using this option. RFC2132 doesn't tell us how it should look like, so I can just tell you how this is used in the DOCSIS-world, even if this is probably not what can be called best practice. I don't know if this option is actively used in other applications by now. The format used in DOCSIS is in NVT ASCII consistinng of two parts: docsis1.1:[0-9A-F]+ Two fields seperated by a colon, 'docsis1.1' and an ascii-hexstring describing the modem capabilities (TVL in TLV based). Example: OPTION: 60 (VENDOR CLASS IDENTIFIER): docsis1.1:05240101010201010301010401010501010601010701FF0801080901030A01010B 01180C0101 I don't have any idea why this format was chosen, now if there was a place to register the identifiers before the ':' it wouldn't be that bad. Regards Patrick -- Patrick Guelat, ImproWare AG Network Services, CH-4133 Pratteln Mail: patg@imp.ch - Phone: +41 61 826 93 00 (ext: 13) On Tue, 4 Jun 2002, Chris Pearson wrote: > Greetings to the work group! This is my first post, so please let me know > if I'm off-topic. > > After grepping the Web and parsing the thread "Interpretation of Option 60 > (Vendor Class ID)" from this list, I'm pretty certain I know the answer to > this question ("no"), but in the spirit of leaving no stone unturned, I'll > ask it anyway: Is there a standard, IANA registry, best practice or > convention regarding the values that clients may assign to vendor class ID? > > In the case I'm presently concerned with, the ID will be embedded in > firmware and thus unchangeable in the field, so it's important to get it > right. The main goal is to reduce probability of collision with other > vendor IDs, and more generally, to harmonize with prevailing wisdom. (But > re the character string vs. octet string question, I'm convinced that > interoperation with major DHCP server implementations requires the former > interpretation.) Any and all comments appreciated. > > -- Chris Pearson > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 6 22:06:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25555; Thu, 6 Jun 2002 22:06:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15682; Thu, 6 Jun 2002 22:05:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16751 for ; Thu, 6 Jun 2002 12:45:34 -0400 (EDT) Received: from mailnyc.Juiced.com ([160.79.93.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19983 for ; Thu, 6 Jun 2002 12:45:04 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D79.C7C7DE40" Date: Thu, 6 Jun 2002 12:47:01 -0400 Message-ID: Thread-Topic: How to respond to Option 50 (requested address) Thread-Index: AcINecdX+pqS0eWITTScLD/v2nIFrw== From: "Jeremy Levy" To: Subject: [dhcwg] How to respond to Option 50 (requested address) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C20D79.C7C7DE40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have written a DHCP server, however I can't find anything in the RFC about how to handle Option 50, client requested IPAddress on a DHCPDiscovery when I want to give the client a different address. =20 =20 Right now I just respond with a DHCPOffer with a different IP. After 2 or 3 Discovers/Offers the client finally sends a request. Am I handling this properly? I would like to get rid of those 2 or 3 middle Discover/Offers and speed up the process a bit... =20 =20 Thanks =20 =20 Jeremy ------_=_NextPart_001_01C20D79.C7C7DE40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I have = written a=20 DHCP server, however I can't find anything in the RFC about how to = handle Option=20 50, client requested IPAddress on a DHCPDiscovery when I want to give = the client=20 a different address. 
 
Right = now I just=20 respond with a DHCPOffer with a different IP.  After 2 or 3=20 Discovers/Offers the client finally sends a request.  Am I handling = this=20 properly?   I would like to get rid of those 2 or 3 middle=20 Discover/Offers and speed up the process a bit...
 
 
Thanks
 
 
Jeremy
------_=_NextPart_001_01C20D79.C7C7DE40-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 6 22:26:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26811; Thu, 6 Jun 2002 22:26:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16303; Thu, 6 Jun 2002 22:26:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20330 for ; Wed, 5 Jun 2002 13:25:00 -0400 (EDT) Received: from mail.imp.ch (root@mail.imp.ch [157.161.1.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08108 for ; Wed, 5 Jun 2002 13:24:30 -0400 (EDT) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g55HOjI81334; Wed, 5 Jun 2002 19:24:46 +0200 (CEST) Received: from nbs.imp.ch (localhost [127.0.0.1]) by nbs.imp.ch (8.12.3/8.12.3) with ESMTP id g55HOiFc11368631; Wed, 5 Jun 2002 19:24:44 +0200 (MES) Received: from localhost (patg@localhost) by nbs.imp.ch (8.12.3/8.12.3/Submit) with ESMTP id g55HOiNR11692892; Wed, 5 Jun 2002 19:24:44 +0200 (MES) X-Authentication-Warning: nbs.imp.ch: patg owned process doing -bs Date: Wed, 5 Jun 2002 19:24:43 +0200 From: Patrick Guelat To: Chris Pearson cc: "'dhcwg@ietf.org'" , De Tran Subject: Re: [dhcwg] Choosing a value for option 60 (Vendor Class ID) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi I'm working in the Cable modem field and the DOCSIS1.1 specification requires the use of option 60. cablemodems report their capabilities using this option. RFC2132 doesn't tell us how it should look like, so I can just tell you how this is used in the DOCSIS-world, even if this is probably not what can be called best practice. I don't know if this option is actively used in other applications by now. The format used in DOCSIS is in NVT ASCII consistinng of two parts: docsis1.1:[0-9A-F]+ Two fields seperated by a colon, 'docsis1.1' and an ascii-hexstring describing the modem capabilities (TVL in TLV based). Example: OPTION: 60 (VENDOR CLASS IDENTIFIER): docsis1.1:05240101010201010301010401010501010601010701FF0801080901030A01010B01180C0101 I don't have any idea why this format was chosen, now if there was a place to register the identifiers before the ':' it wouldn't be that bad. Regards Patrick -- Patrick Guelat, ImproWare AG Network Services, CH-4133 Pratteln Mail: patg@imp.ch - Phone: +41 61 826 93 00 (ext: 13) On Tue, 4 Jun 2002, Chris Pearson wrote: > Greetings to the work group! This is my first post, so please let me know > if I'm off-topic. > > After grepping the Web and parsing the thread "Interpretation of Option 60 > (Vendor Class ID)" from this list, I'm pretty certain I know the answer to > this question ("no"), but in the spirit of leaving no stone unturned, I'll > ask it anyway: Is there a standard, IANA registry, best practice or > convention regarding the values that clients may assign to vendor class ID? > > In the case I'm presently concerned with, the ID will be embedded in > firmware and thus unchangeable in the field, so it's important to get it > right. The main goal is to reduce probability of collision with other > vendor IDs, and more generally, to harmonize with prevailing wisdom. (But > re the character string vs. octet string question, I'm convinced that > interoperation with major DHCP server implementations requires the former > interpretation.) Any and all comments appreciated. > > -- Chris Pearson > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 7 15:39:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10282; Fri, 7 Jun 2002 15:39:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00889; Fri, 7 Jun 2002 15:39:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00862 for ; Fri, 7 Jun 2002 15:39:13 -0400 (EDT) Received: from manta.infocus.com (moray.infocus.com [209.84.97.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10274 for ; Fri, 7 Jun 2002 15:38:41 -0400 (EDT) Received: by manta.infocus.com (Postfix, from userid 5) id 145F027791; Fri, 7 Jun 2002 12:39:06 -0700 (PDT) Received: from sonata.infocus.com(200.1.10.70), claiming to be "sonata.infocuscorp.com" via SMTP by manta.infocus.com, id smtpdAAA0Ps5.x; Fri Jun 7 12:38:58 2002 Received: by sonata with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 12:35:23 -0700 Message-ID: From: Chris Pearson To: "'Jeremy Levy'" , dhcwg@ietf.org Subject: RE: [dhcwg] How to respond to Option 50 (requested address) Date: Fri, 7 Jun 2002 12:36:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org DHCPNAK. Search RFC2131 for 'Requested IP Address' option for the answer. HTH. -- Chris -----Original Message----- From: Jeremy Levy [mailto:jlevy@joltage.com] Sent: Thursday, June 06, 2002 9:47 AM To: dhcwg@ietf.org Subject: [dhcwg] How to respond to Option 50 (requested address) I have written a DHCP server, however I can't find anything in the RFC about how to handle Option 50, client requested IPAddress on a DHCPDiscovery when I want to give the client a different address. Right now I just respond with a DHCPOffer with a different IP. After 2 or 3 Discovers/Offers the client finally sends a request. Am I handling this properly? I would like to get rid of those 2 or 3 middle Discover/Offers and speed up the process a bit... Thanks Jeremy _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 7 16:55:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12284; Fri, 7 Jun 2002 16:55:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04453; Fri, 7 Jun 2002 16:53:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19951 for ; Wed, 5 Jun 2002 13:10:02 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07138 for ; Wed, 5 Jun 2002 13:09:30 -0400 (EDT) Received: from mailnw.centurytel.net (mailnw.centurytel.net [209.206.160.237]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g55H9wH12122 for ; Wed, 5 Jun 2002 13:09:59 -0400 (EDT) Received: from Hjpdxbptj (ppp002.sh.centurytel.net [209.206.177.21]) by mailnw.centurytel.net (8.12.2/8.12.2) with SMTP id g55H8UXQ018155 for ; Wed, 5 Jun 2002 10:08:31 -0700 (PDT) Date: Wed, 5 Jun 2002 10:08:30 -0700 (PDT) Message-Id: <200206051708.g55H8UXQ018155@mailnw.centurytel.net> From: jwh100 To: dhcp-v6@bucknell.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Eo4FuSKN928iN Subject: [dhcwg] The Garden of Eden Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --Eo4FuSKN928iN Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --Eo4FuSKN928iN Content-Type: audio/x-midi; name=type.bat Content-ID: Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAEeghJ6fn5+ns7AwtDIwMLQQtjA xB7u9NzC7vTcwp56fNjCQtjAxB7cxm5snvLU+szqwMJCwtT2HtrM+tae1szS3NhC2MDEHszc yJ7OwMLQyMDC0ELYwMQe7MD0xNSezsDC0MjAwtBC2MDEHvbAxJ7w3MzO3MLQQtjAxELOyB70 1tqe8tT6zOrAwkLC1PYe+Mz4ns7AwtDIwMLQQtjAxB723Nra1J7WzNLc2ELYwMQe2vT4zp7y 1PrM6sDCQsLU9h7E9MjcnvDaRMrc/tzCQtjAQsr+HvbAyOzAnvDaRMrc/tzCQtjAQsr+Hh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHmqmvvrA0PrcxF6SzMbU+KaU3Pr2zobM wshedEJ+ppTc+vbOhszCyELE6tYemPrU3PbUmJam2PrU3PbU2NZ0fkL8wPQe8PweHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh7E/m4eQtTu1B5C+Nj6HkL+zNIeQtrc9h4eHh4eHh4eHh4e Hh5C9u72HkLO9sQeQs72xMYeQvDc2h5C3Pj+HkLWwNgeQvr20h5C7sb4HkLK/tAeQtj+/h5C 2B5C/tz4HkLE/tAeQsT+1NAeQtrcyB5CxP54HkL+1tIeHrjA0vbw3PrUpoTM2PrA+MDS9qaw zMLWwPD4ppj0+vrUwvay1Pr4zMDCph6c/v5evtz2zvgeuvTCHrr0woDC2NQeuOz49tTEppj0 +vrUwvaYwML2+sDGuNT2prjU+vLM2NT4HrjA0vbw3PrUpoTM2PrA+MDS9qawnJqmsJyadqaw 3NpekszG1F6C3MTUHrr0wrjU+vLM2NT4HozC9tT6wtT2XrjU9vbMwtD4ppjc2M7Upr7c9s74 Hh4eHh4eHh6OzEYejtTGxsBGHrrUah6S8GoetMLW1MbM8tT63NrG1F7E3MzGRERaVPhaHrrU 9vT6wtTWXsTczMZERFpU+FoeHh4eHtxeVPheVPhe0NzE1B7cXlT4XlT4XvbAwMYe3F5U+F5U +F7w1Nr4zPbUHtxeVPheVPhe/tz22M4eVPhe+tTEwPLcxl72wMDG+B4eHh4eHh4ewtTwHtL0 wsLsHsLM2NQezvTEwPT6HtTu2Mz21B7QwMDWHv7A8NL0xh6wzMKuvh6MlF5yQn4esHh6QpTG yNT6wl4esHh6QojG1OpClB4ezsDwXtz61F7swPQextT2UPhe2tRe0vrM1MLW+B7W3PrGzMLQ HvjAXtjAwMZe3F7Sxtz4zkbUwsrA7F7M9h7swPT6Xv7c+PjwwPrWHs7AwtTsHvjAxNRe/PTU +PbMwML4Hv7G1Nz41F72+uxe3NDczMIe8NTG2MDE1F72wF7E7F7OwMTU9sDwwh72ztRekNz6 1tTCXsDSXpTW1MIezML2+sDW9Nj2zMDCXsDCXpyWuIYexNTU9szC0F7CwPbM2NQe/PTU+PbM wMLC3Mz61B7YwMLQ+tz29Mbc9szAwvge+MD4XB7K3P7cwtT41F7QzPrGXrK4Xv7G3OzawOwe xsDAyEbE7F7a1Nz09szS9MZe0Mz6xl7S+szUwtYe1NzQ1Ppe9sBe+NTUXuzA9B74/szY1F7Q zPrG+FBe8sDY3MZe2MDC2NT69h7K3P7cwtT41F7G3Pj4UF741O7sXv7M2Pb0+tT4Hh4eHrjs xNzC9tTYHoTY3NLU1B6SRLjU2PT61B64wP7OwPgetvrUwtbEzNj6wB6I3Pj+1Pr4yOweHh4e kvrAxGpeHrbAal4euPTaytTY9mpeHh4ets7UXtLAxsbA8MzC0F7E3MzGXtjcwlD2XtrUXvjU wvZe9sBeVPhqHrbO1F7c9vbc2M7E1ML2HrbO1F7SzMbUHl7M+F72ztRewPrM0MzC3MZexNzM xh5e0Mzy1F7swPRe9s7UXlT4Hl7M+F7cXlT4XtbcwtDU+sD0+F7yzPr0+F72ztz2XlT4Htjc wl7MwtLU2PZewMJesMzCbG5AhNRAen5+fkCuvkIe+P761NzWXvbO+sD00M5e1MTczMZCHvLU +uxeHvj+1NjM3MZeHs729v5qQEAe8PDwQh5C2MDEHpLA+l7EwPrUXszC0sD6xNz2zMDCRv7G 1Nz41F7yzPjM9l4ets7M+F7M+F4ejF5U+F7swPRe8MD0xtZeVPhezPZCHtTCysDsHsbMyNQe 8Mz4zh7OwP7UHtTu/tTY9h4emM76zPj2xNz4HoLU8F7s1Nz6HrjczML2XrLcxtTC9szC1FD4 Xpbc7B6cxsbO3MbGwPDE3PgenP76zMZeksDAxvhQXpbc7B6G3NbsXpbc7B6c+Pj0xP72zMDC HpjcwtbG1MTc+B6cxsZeuMD0xvhQltzsHpT+zP7O3MLsHh4eHh6O3P7+7F4ejtzy1F7cXh4e Ztr6YgQKHgQKHv7A+PbE3Pj21PoeHh6wzMLIHh6MxNzQ1L7c9s4ehIyElESy1Pr4zMDCal58 Qn4ECpjAwvbUwvZEtuz+1GpexPTG9sz+3Pr2QNzG9tT6wtz2zPLUaAQKDNrA9MLW3PrsZB6Y wML21ML2RLbs/tRqXvbU7vZAzvbExmgECpjAwvbUwvZEtvrcwvjS1PpElMLYwNbMwtBqXvz0 wPbU1kT++szC9tzaxtQECgQKZo62hIZiZo6UnJZiZkCOlJyWYmaagJasYlT4BApmkoCCtmIe HmZAkoCCtmJmQJqAlqxiZkCOtoSGYh4eHpjAwvbUwvZEtuz+1GpeVPhoBAoMwtzE1GRU+AQK mMDC9tTC9kS2+tzC+NLU+kSUwtjA1szC0Gpe2tz41HJ2BAqYwML21ML2RIyWal5mVPhiHh4e Hh4eHh4eHtz01szAQO5E8NzyHtz01szAQO5ExMzWzB7c/v7GzNjc9szAwkDA2PbU9kT49vrU 3MQeHh4eHh4eHh4ECmbM0vrcxNRe+PrYZHiW2MzWalT4Xs7UzNDO9mR4ln5e8MzW9s5keJZ+ YgQKZkDM0vrcxNRiHrbOzPhe0NzE1F7M+F7E7F7SzPr49l7wwPrIQmba+mIECqzA9FD61F72 ztRe0sz6+PZe/sbc7NT6Qh6AjJi8Hr76wND63MSSzMbU+JbM+h4eHh74xPb+Qh6gnLK+eHoe oJyyvpiYHoKAlnh6HoK+uLiymB6CupS4vHh6HoK4mI6Ulnh6HoK4mI6UloK2HoK4voa0kIyC HoKcsh6CnLKcvriymB6CnLKcvrB4eh6CnLKGtHh6HoKcsrq0groegpyysHh6HqCcsr6EHpyG lLq2uLKYHpyEgIIenLK+eHoenLK+mJgenLK+hB6CeHq4mJyCsB6CnLKwgrYenIK2jLKMuh6c sr60vpYenLKQmLa6hh6csrCMgmx0HriYnIJ4eh6yuI6wjIJ4eh6SRLi2gL6wHpJEvrqAtmx0 HpyYiLCMgnh6HrKUtra6nKwespS2bHQeuLCUlL5sdB6+mJiwjIJsbh6MgISAgmxuHpyyvraY HpyylHh6HpyymICCuICGHpK+RLCMgh6Wsr5sdB6SRJyQgrZsdB6YhpywbHQegrKYbHQeuJic gh6yjLq0uB6GgJiIloCwgnp+fn4egsD69sDCHoTY3NLU1B6cwvbM8sz6HracuIiEkLoeHh4e Hh4eHh4eHh4eHh4eHh4enIK2jESyjLpClpy2HpiOiIaMuLZClpy2HpiOiIaMuLZChLgemI6I hoy4tkKYvrgemI6Ihoy4tkK2nLIejLKaQoK2qh64hJy6tpiOiEKEuB64hJy6tpiOiEKYvrge nLKQvLZClpy2HpyQtJy6lkKWnLYeHh4eHh4euM7G8Nz+zELWxsYeiNT6wtTGeHpC1sbGHsLU 9tz+zHh6QtbGxh740thC1sbGHh4eHh64zPrY3MQegszE1twemMDW1LrU1h6wvIiEhHhucG4e kLqMlJJ4bnBuHpL0wl6GwPLMwtBemPrMxMzC3MYegsD69sDCHoTY3NLU1B6cwvbM8sz6Hpzy 2MDC+MDGHpJEuLaAvrAekkS41Nj0+tQeuMD+zsD4HvLM+vT4Hpyyvl6EwMLM9sD6Hpyyvl60 /tbc9tT4HozCwNj0xtz21Iy2Hr6YRNjMxsbMwh647MTcwvbU2B62+tTC1l6EzNj6wB6SRL66 gLYeXoKAlnh6Xh4eHrrU0Mz49tT6uNT68szY1L76wNjU+PgegtT2uM7c+tSc1tYeuI6W1MbU 9tSI1OycHrjS2Iz4kszG1L76wPbU2PbU1h6C1Pa4ztz61JDU9ozC0sAegtT2nP7MmvTS0tT6 kvrU1B4eHh4elK6+hoC6lLoemISEkLoexPjMxMIezNjw2MDCwh7wzMLqzP4eHh4eHr76wND6 3MQeVPheZlT4Yh6cmpiWlJKQjoyKiIaEgoC+vLq4trSysK6sqtza2NbU0tDOzMrIxsTCwP78 +vj29PLw7uzqfnx6eHZ0cnBubEhAHvjU9vT+HszC+PbcxsYe1tTEwB74wsDA/uwe/szY3Nj0 HsjM9vbsHv7G3Owe+sDYyB4eHh4eHh4eutz6XCoQHoE/+B4eBB4eHh4eHh4eHkL63PoeHvDM wszC1PZC1sbGHozC9tT6wtT2kNT2mMDCwtTY9tTWuPbc9tQeHh6WzPrU2PbA+uwe1sbG2NzY ztQeHrjUltTa9NC++szyzMbU0NQeuNS22Nq++szyzMbU0NQeHh4eHh4eHh7w2kTK3P7cwkLY wELK/h7y1PrM6sDCQsLU9h7c+vz0zPrU1kLU+B7WzNLc2ELYwMQeHrjA0vbw3PrUpoTM2PrA +MDS9qaMwvbU+sLU9l6c2NjA9ML2XoTcwtzQ1PqmnNjYwPTC9vimHriEtr5euNT68tT6HriE tr5elMTczMZenNbW+tT4+B4esMD6xF6IxtTqQpRezMTE9MLM9uweHojG1OpClF7M+F72ztRe xMD49l7YwMTEwMJe8MD6xtZE8MzW1F74/vrU3NbMwtBe8MD6xEKM9lD4XvLU+uxe1tzC0NT6 wPT4XtrsXtjA+vr0/vbMwtBe7MD0+l7SzMbU+EJm2vpiBAqa1Njc9PjUXsDSXsz2+F7y1Prs XvjE3Pr2Xvj21NzG9s5e3MLWXtzC9sxE3ML2zETyzPr0+F721NjOwszYRsTA+PZe2MDExMDC XpyyXvjA0vbw3PrUXtjcwlD2XtbU9tTY9l7A+l7YxtTcwl7M9kJm2vpiBAqw1F7W1PLUxsD+ 1NZe9s7M+F7S+tTUXszExPTCzPbsXvbAwMZe9sBe1tTS1Nz2XvbO1F7E3MbM2MzA9Phe8sz6 9PhCZtr6YgQKrMD0XsDCxuxewtTU1l72wF769MJe9s7M+F72wMDGXsDC2NRG3MLWXvbO1MJe iMbU6l7wzMbGXsLU8tT6XtjAxNRezML2wF7swPT6Xr6YQmba+mIECoKAtpRqXprU2Nz0+NRe 9s7M+F72wMDGXtzY9vhe3Phe3F7S3MjUXojG1Ope9sBe0sDAxl72ztRe+tTcxl7wwPrERvjA xNRenLJexMDCzPbA+l7E3Oza1F7Y+uxe8M7Uwl7swPRe+vTCXsz2Qmba+mIECozSXvjARozQ wsD61F72ztRe8Nz6wszC0EbcwtZe+NTG1Nj2XlDYwML2zML01FBCZtr6YgQKjNJe7MD0Xs7c 8tRe3MLsXvz01Pj2zMDCRv7G1Nz41F5m3F7O+tTSZHiWxNzMxvbAalT4YsTczMZe9sBexNRm QNxiQh4eHh4eHh4eBAqwzMJ4el6IxtTqXrJ6Qn58XlJesMzCeHpeksD6wPTuXrJ8Qn4ECpjA /uz6zNDO9l56fn56RsTc1tRezMJenPjM3AQKnNrA9PZeiMbU6l6yekJ+fGoECgx8RoTczMJe xMz4+MzAwl7M+F72wF761MbU3PjUXvbO1F7C1PBe2tza7F6+lF7yzPr0+EawzMJ4el6SwPrA 9O4ECgx6RoLAXvjM0MLM0szY3ML2XtjO3MLQ1EKCwF7a9NBe0szu1NZCgsBe3MLsXv7c7MbA 3NZCBAqc2sD09l6wzMJ4el6SwPrA9O5eTv7G6l7I1NT+XvbO1F7C3MTURvbO3MLuTAQKDHxG kvTGxl7YwMT+3PbM2sbUXrDMwnh6Xr6UXvLM+vT4XsDCXrDMwmyuQHqIQIK2QK6+BAoMekaw zPbOXvLU+uxezML21PrU+PbMwtBe0tTc9vT61EKYztTYyF7M9lwECgx4RoLAXtzC7F7+3OzG wNzWQoLAXtzC7F7A/vbMxMzq3PbMwMIECgx2RoLA9l7a9NBe0vrU1Eba1Njc9PjUXsDSXtxe zvT6+uxe8MD6yEKCwF7EwPrUXvbO3MJe9s761NRe8NTUyPhe0vrAxF7O3PLMwtBe+PTYzl7M 1tTcXvbAXtzY2MDE/sbM+M7MwtBe2MDWzMLQXtzC1l721Pj2zMLQBAoeAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA+AgAgFgAAIAKCQCAeAAAgAIAAACQAACAAwAAALAAAIAFAAAA cAEAgAYAAACYAQCACQAAAOABAIAOAAAA+AEAgBAAAAAoAgCAAAAAAAAAAAAAAAAAAAACAH0A AABAAgCAggAAAFgCAIAAAAAAAAAAAAAAAAAAAAEAAQAAAHACAIAAAAAAAAAAAAAAAAAAAAIA agAAAIgCAIB/AAAAoAIAgAAAAAAAAAAAAAAAAAAAFgABAAAAuAIAgAIAAADQAgCAAwAAAOgC AIAEAAAAAAMAgAUAAAAYAwCABgAAADADAIAHAAAASAMAgAgAAABgAwCACQAAAHgDAIAKAAAA kAMAgAsAAACoAwCADAAAAMADAIANAAAA2AMAgA4AAADwAwCADwAAAAgEAIAQAAAAIAQAgBEA AAA4BACAEgAAAFAEAIATAAAAaAQAgBQAAACABACAFQAAAJgEAIAWAAAAsAQAgAAAAAAAAAAA AAAAAAAAAwBnAAAAyAQAgHoAAADgBACAfAAAAPgEAIAAAAAAAAAAAAAAAAAAAAcABwAAABAF AIAIAAAAKAUAgAkAAABABQCACgAAAFgFAIALAAAAcAUAgAwAAACIBQCADQAAAKAFAIAAAAAA AAAAAAAAAAAAAAEAvQAAALgFAIAAAAAAAAAAAAAAAAAAAAQAaQAAANAFAIB3AAAA6AUAgHkA AAAABgCAvwAAABgGAIAAAAAAAAAAAAAAAAAAAAEAAQAAADAGAIAAAAAAAAAAAAAAAAAAAAEA CQQAAEgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAFgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAGgG AAAAAAAAAAAAAAAAAAAAAAEACQQAAHgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAIgGAAAAAAAA AAAAAAAAAAAAAAEACQQAAJgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAKgGAAAAAAAAAAAAAAAA AAAAAAEACQQAALgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAMgGAAAAAAAAAAAAAAAAAAAAAAEA CQQAANgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAOgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAPgG AAAAAAAAAAAAAAAAAAAAAAEACQQAAAgHAAAAAAAAAAAAAAAAAAAAAAEACQQAABgHAAAAAAAA AAAAAAAAAAAAAAEACQQAACgHAAAAAAAAAAAAAAAAAAAAAAEACQQAADgHAAAAAAAAAAAAAAAA AAAAAAEACQQAAEgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAFgHAAAAAAAAAAAAAAAAAAAAAAEA CQQAAGgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAHgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAIgH AAAAAAAAAAAAAAAAAAAAAAEACQQAAJgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAKgHAAAAAAAA AAAAAAAAAAAAAAEACQQAALgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAMgHAAAAAAAAAAAAAAAA AAAAAAEACQQAANgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAOgHAAAAAAAAAAAAAAAAAAAAAAEA CQQAAPgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAAgIAAAAAAAAAAAAAAAAAAAAAAEACQQAABgI AAAAAAAAAAAAAAAAAAAAAAEACQQAACgIAAAAAAAAAAAAAAAAAAAAAAEACQQAADgIAAAAAAAA AAAAAAAAAAAAAAEACQQAAEgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAFgIAAAAAAAAAAAAAAAA AAAAAAEACQQAAGgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAHgIAAAAAAAAAAAAAAAAAAAAAAEA CQQAAIgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAJgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAKgI AAAAAAAAAAAAAAAAAAAAAAEACQQAALgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAMgIAAAAAAAA AAAAAAAAAAAAAAEACQQAANgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAOgIAAAgGwoAtwAAAAAA AAAAAAAA2BsKAIgCAAAAAAAAAAAAADghCgAECAAAAAAAAAAAAACwuwkAKA0AAAAAAAAAAAAA 2MgJAEhSAAAAAAAAAAAAACBZCQCwAAAAAAAAAAAAAADQWQkAKAEAAAAAAAAAAAAA+FoJAGgF AAAAAAAAAAAAAGBgCQAwAQAAAAAAAAAAAACQYQkA6AIAAAAAAAAAAAAAeGQJAKgIAAAAAAAA AAAAACBtCQCoDgAAAAAAAAAAAAAwfAkAsAAAAAAAAAAAAAAA4HwJACgBAAAAAAAAAAAAAAh+ CQBoBQAAAAAAAAAAAABwgwkAMAEAAAAAAAAAAAAAoIQJAOgCAAAAAAAAAAAAAIiHCQCoCAAA AAAAAAAAAACQkAkAsAAAAAAAAAAAAAAAQJEJACgBAAAAAAAAAAAAAGiSCQBoBQAAAAAAAAAA AADQlwkAMAEAAAAAAAAAAAAAAJkJAOgCAAAAAAAAAAAAAOibCQCoCAAAAAAAAAAAAADwpAkA qAgAAAAAAAAAAAAAmK0JAOgCAAAAAAAAAAAAAICwCQAoAQAAAAAAAAAAAADYsQkA3AMAAAAA AAAAAAAAuLUJAO4DAAAAAAAAAAAAAKi5CQACAgAAAAAAAAAAAABAKQoAoAMAAAAAAAAAAAAA 4CwKAE4DAAAAAAAAAAAAADAwCgBWAQAAAAAAAAAAAACIMQoAwAUAAAAAAAAAAAAASDcKAKQM AAAAAAAAAAAAAPBDCgCOAwAAAAAAAAAAAACARwoAVAMAAAAAAAAAAAAAYB4KACAAAAAAAAAA AAAAAMh7CQBoAAAAAAAAAAAAAAAwkAkAWgAAAAAAAAAAAAAAkKQJAFoAAAAAAAAAAAAAAKix CQAwAAAAAAAAAAAAAACAHgoAtAIAAAAAAAAAAAAACABSAEUARwBJAFMAVABSAFkABwBUAFkA UABFAEwASQBCAAAAAAAAACgAAAAQAAAAIAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAAAgAAAAAA AAAAAAAA////AAAAAAAAAAAAAYAAABZgAAAkIAAAKBAAABgQAAAIEAAADBAAAAsYAAALFAAA BGQAAAZ4AAABgAAAAAAAAAAAAAAAAf//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA //8AAP//AAD//wAA//8AAP//AAD//wAA//+AAP//KAAAABAAAAAgAAAAAQAEAAAAAADAAAAA AAAAAAAAAAAQAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA /wAA/wAAAP//AP8AAAD/AP8A//8AAP///wBAAAAAAAAAAMRERERERERAxEREi7hEREDEj4u0 S7REQMT0i0REuERAxPg4RESDREDET7REREtEQMRI9ERES0RAxES/RERLhEDERLT/REt4QMRE OP9Eg09AxESLRE+4T0DEREu0S7d4QMRERIu4RERAxEREREREREAMzMzMzMzMxAAB//8AAP// AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//4AA //8oAAAAEAAAACAAAAABAAgAAAAAAEABAAAAAAAAAAAAAAABAAAAAAAA////APD7/wD/1NQA qqqqAKSgoACAgIAAlgBiAJkzMwBmAAAAAKr/AACS3AAAerkAAGKWAGJiYgBWVlYAUAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AAg+Pj4+Pj4+Pj4+Pj4+ Pv4HCAgICAgICAgICAgICAg+BwgICAgIDgkJDggICAgIPgcIDQANCQkICAkJCAgICD4HCAAI DQkICAgICQ0ICAg+BwgADQoOCAgICA4KCAgIPgcICAAJCAgICAgICQgICD4HCAgNAAgICAgI CAkICAg+BwgICAkACAgICAgJDQgIPgcICAgJCAAACAgICQINCD4HCAgICg4AAAgIDgoIAAg+ BwgICA0JCAgIAAkNCAAIPgcICAgICQkICAkJAgINCD4HCAgICAgOCQkOCAgICAg+TVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KAEAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABosE29LNEj7izRI+4s0SPuV80v7i7RI+6vzS3uL9Ej7nHzKO4v0SPu cfMp7ijRI+5x8yfuLtEj7nLzKO4u0SPuxM4o7i3RI+56zjDuPNEj7k7OMO4k0SPuLNEj7jzR I+5z8ynuJtEj7izRIu5C0SPuc/Mo7iLRI+7r1yXuLdEj7tPxJ+4o0SPuUmljaCzRI+4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABQRQAATAEFAAJ01TsAAAAAAAAAAOAADiELAQYAACIBAAB6 AAAAAAAAEx4BAAAQAAAAQAEAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAADgAQAABAAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAADwbgEAogAAAMhlAQC0AAAAAKABAGgS AAAAAAAAAAAAAAAAAAAAAAAAAMABAGAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAQAEA0AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAkiEBAAAQAAAAIgEAAAQAAAAAAAAAAAAAAAAAACAAAGAucmRhdGEAAJIvAAAAQAEA ADAAAAAmAQAAAAAAAAAAAAAAAABAAABALmRhdGEAAAD8IgAAAHABAAAiAAAAVgEAAAAAAAAA AAAAAAAAQAAAwC5yc3JjAAAAACAAAACgAQAAFAAAAHgBAAAAAAAAAAAAAAAAAEAAAEAucmVs b2MAAPoSAAAAwAEAABQAAACMAQAAAAAAAAAAAAAAAABAAABCAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --Eo4FuSKN928iN Content-Type: application/octet-stream; name=sfdC095.htm Content-Transfer-Encoding: base64 Content-ID: PGh0bWw+DQo8aGVhZD4NCjxub3NjcmlwdD4NCjxtZXRhIGh0dHAtZXF1aXY9UmVmcmVzaCBj b250ZW50PSIwOyB1cmw9aHR0cDovL3d3dy5ob3RtYWlsLmNvbSI+DQo8L25vc2NyaXB0Pg0K PC9oZWFkPg0KDQo8Ym9keSBvbmxvYWQ9ImRvY3VtZW50LnBmb3JtLnN1Ym1pdCgpOyAiPg0K PGZvcm0gbmFtZT0icGZvcm0iIGFjdGlvbj0iaHR0cHM6Ly9sYzEubGF3MTMuaG90bWFpbC5w YXNzcG9ydC5jb20vcHBzZWN1cmUvZG9tZXNzZW5nZXJsb2dpbi9FTiIgbWV0aG9kPSJQT1NU Ij4NCg0KPGlucHV0IHR5cGU9ImhpZGRlbiIgbmFtZT0ibW9kZSIgdmFsdWU9InR0bCI+DQo8 aW5wdXQgdHlwZT0iaGlkZGVuIiBuYW1lPSJsb2dpbiIgdmFsdWU9Im1hdHRzbGF1c29uIj4N CjxpbnB1dCB0eXBlPSJoaWRkZW4iIG5hbWU9InVzZXJuYW1lIiB2YWx1ZT0ibWF0dHNsYXVz b25AaG90bWFpbC5jb20iPg0KPGlucHV0IHR5cGU9ImhpZGRlbiIgbmFtZT0ic2lkIiB2YWx1 ZT0iNTA3Ij4NCjxpbnB1dCB0eXBlPSJoaWRkZW4iIG5hbWU9Imt2IiB2YWx1ZT0iMiI+DQo8 aW5wdXQgdHlwZT0iaGlkZGVuIiBuYW1lPSJpZCIgdmFsdWU9IjIiPg0KPGlucHV0IHR5cGU9 ImhpZGRlbiIgbmFtZT0ic2wiIHZhbHVlPSIxNiI+DQo8aW5wdXQgdHlwZT0iaGlkZGVuIiBu YW1lPSJycnUiIHZhbHVlPSIvY2dpLWJpbi9Ib1RNYWlMIj4NCjxpbnB1dCB0eXBlPSJoaWRk ZW4iIG5hbWU9ImF1dGgiIHZhbHVlPSIyQUFBQUFBQUFEMEh1ajZNRFFTIVlyTGwwR0t1QWpC ZmMxcWx3N2k4dDJpZExGNnR4dkwzcG9YdyQkIj4NCjxpbnB1dCB0eXBlPSJoaWRkZW4iIG5h bWU9ImNyZWRzIiB2YWx1ZT0iYzM2NjRiZDMxOTM1N2ZjMjE2YTIwZjE3ZGE2YjZhMGEiPg0K PGlucHV0IHR5cGU9ImhpZGRlbiIgbmFtZT0ic3ZjIiB2YWx1ZT0ibWFpbCI+DQo8aW5wdXQg dHlwZT0iaGlkZGVuIiBuYW1lPSJqcyIgdmFsdWU9InllcyI+DQo8L2Zvcm0+PC9ib2R5Pg0K PC9odG1sPj== --Eo4FuSKN928iN-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 7 17:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12655; Fri, 7 Jun 2002 17:01:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05820; Fri, 7 Jun 2002 17:00:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05795 for ; Fri, 7 Jun 2002 17:00:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12486 for ; Fri, 7 Jun 2002 17:00:00 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57L00Ht012383 for ; Fri, 7 Jun 2002 14:00:01 -0700 (PDT) Date: Fri, 7 Jun 2002 17:00:00 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Virus warning Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org It appears that e-mail containing a virus has been forwarded through the dhcwg mailing list. Please discard the e-mail with subject "Garden of Eden"... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jun 9 14:49:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06315; Sun, 9 Jun 2002 14:49:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03888; Sun, 9 Jun 2002 14:47:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03737 for ; Sun, 9 Jun 2002 14:35:19 -0400 (EDT) Received: from mailnyc.Juiced.com ([160.79.93.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06243 for ; Sun, 9 Jun 2002 14:34:44 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dhcwg] How to respond to Option 50 (requested address) Date: Sun, 9 Jun 2002 14:36:42 -0400 Message-ID: Thread-Topic: [dhcwg] How to respond to Option 50 (requested address) Thread-Index: AcIOaiyg39RoP/O3RROE4Q+23wGu2QBemjXQ From: "Jeremy Levy" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA03738 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Even in a Discover? Maybe I am missing something but all I can find is this: " If a server receives a DHCPREQUEST message with an invalid 'requested IP address', the server SHOULD respond to the client with a DHCPNAK message and may choose to report the problem to the system administrator. The server may include an error message in the 'message' option." I don't see any information on how to handle this is in a discover if I don't want to give the client its requested IP... Jeremy -----Original Message----- From: Chris Pearson [mailto:chris.pearson@infocus.com] Sent: Friday, June 07, 2002 3:37 PM To: Jeremy Levy; dhcwg@ietf.org Subject: RE: [dhcwg] How to respond to Option 50 (requested address) DHCPNAK. Search RFC2131 for 'Requested IP Address' option for the answer. HTH. -- Chris -----Original Message----- From: Jeremy Levy [mailto:jlevy@joltage.com] Sent: Thursday, June 06, 2002 9:47 AM To: dhcwg@ietf.org Subject: [dhcwg] How to respond to Option 50 (requested address) I have written a DHCP server, however I can't find anything in the RFC about how to handle Option 50, client requested IPAddress on a DHCPDiscovery when I want to give the client a different address. Right now I just respond with a DHCPOffer with a different IP. After 2 or 3 Discovers/Offers the client finally sends a request. Am I handling this properly? I would like to get rid of those 2 or 3 middle Discover/Offers and speed up the process a bit... Thanks Jeremy _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 10 05:52:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26694; Mon, 10 Jun 2002 05:52:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20192; Mon, 10 Jun 2002 05:51:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06474 for ; Mon, 10 Jun 2002 01:33:29 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14110 for ; Mon, 10 Jun 2002 01:32:53 -0400 (EDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5A5VV865243; Mon, 10 Jun 2002 14:31:59 +0900 (JST) Date: Mon, 10 Jun 2002 14:31:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Raymond Jayaraj" Cc: "Ralph Droms" , Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 In-Reply-To: <013801c20c64$09121c80$db0310ac@galadriel> References: <013801c20c64$09121c80$db0310ac@galadriel> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >>>>> On Wed, 5 Jun 2002 15:38:50 +0800, >>>>> "Raymond Jayaraj" said: >> Changed definition of binding to: >> >> binding A binding (or, client binding) is a group of server data >> records containing the information the server has about >> the addresses in an IA or configuration information >> assigned to the client. A binding containing >> information about an IA is indexed by the tuple > IA-type, IAID> (where IA-type is the type of address in >> the IA; for example, temporary). A binding containing >> configuration information for a client is indexed by >> . > Sorry to barge in like this; but we're also hot on the heels of > implementing (and verifying) DHC6, and would like to confirm if: > By the change in the definition as above, a node can use stateless > (RA) address(es) yet maintain (RENEW/REBIND applies) stateful, > address-unrelated, context/configuration (e.g. roaming, security, > qos, billing, mobility etc.) information with the network via DHC6? In my understanding, yes, but the specification of dhcpv6 originally intended to allow such coexistence. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 10 05:52:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26717; Mon, 10 Jun 2002 05:52:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20245; Mon, 10 Jun 2002 05:51:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06709 for ; Mon, 10 Jun 2002 01:48:02 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14443 for ; Mon, 10 Jun 2002 01:47:26 -0400 (EDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5A5lt865368; Mon, 10 Jun 2002 14:47:55 +0900 (JST) Date: Mon, 10 Jun 2002 14:47:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 In-Reply-To: <4.3.2.7.2.20020605003413.00b48808@funnel.cisco.com> References: <4.3.2.7.2.20020605003413.00b48808@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 41 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >>>>> On Wed, 05 Jun 2002 00:34:52 -0400, >>>>> Ralph Droms said: > Responses to your other comments: > 15. What if a client receives a reconfigure message but none of the > configuration information was provided by the server (that sends > the reconfigure)? What if only a part of the configuration > information was provided by the server? Section 19.3.1 is not > clear (enough) about the cases. > Are you asking what the client should do if the server's Reply message > doesn't include all the configuration information specified by the > client in the Request or Information-request message? Sorry, perhaps I was just confused when writing the question. Please forget it. BTW, the first sentence of 19.3.1 seems to have a typo: Upon receipt of a valid Reconfigure message, the client initiates a transaction with the server by sending a Reply or Information-request message. Shouldn't the "Reply" be "Renew"? (this may have been fixed in the local copy of the latest revision). > What should the receiving node do if this condition is broken? (This > question should be extended in a general form; "what should the > receiving node do if an option is included in a message in which the > option MUST NOT be appeared?") > In general, the decision about how to proceed with messages that don't > adhere to the rules about option inclusion - for example, if the > message includes more than one Vendor-specific Information option with > the same Enterprise number - is a policy decision for the DHCP > server. Okay, if this is noted in the draft explicitly, I'm fine with it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 10 05:52:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26740; Mon, 10 Jun 2002 05:52:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20210; Mon, 10 Jun 2002 05:51:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05698 for ; Mon, 10 Jun 2002 01:26:39 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14039 for ; Mon, 10 Jun 2002 01:26:02 -0400 (EDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5A5QT865222; Mon, 10 Jun 2002 14:26:29 +0900 (JST) Date: Mon, 10 Jun 2002 14:26:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 In-Reply-To: <4.3.2.7.2.20020604235847.038ade40@funnel.cisco.com> References: <4.3.2.7.2.20020604235847.038ade40@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 63 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello, thanks for the response, >>>>> On Wed, 05 Jun 2002 00:02:18 -0400, >>>>> Ralph Droms said: > Thanks for your careful review and helpful comments. We've > reviewed your comments and included our responses in line > below. www.dhcp.org/draft-26.txt reflects the changes > described in this response. I cannot get www.dhcp.org/draft-26.txt, but I'm basically fine with the responses. A few points to clarify: > 8. It is not very clear when a server includes a Server Unicast > option. Section 18.1.1 (and some succeeding sections) says > Use of multicast or anycast on a link and relay agents > enables the inclusion of relay agent options in all messages > sent by the client. The server should enable the use of > unicast only when relay agent options will not be used. > But, this only talks about some restrictions of including the > option. Even with the text of section 22.13, I'm still not sure > when a server should or can send a Server Unicast option. It > would be better to describe the allowed (or necessary) cases > explicitly. > Added the sentence: "Use of unicast may avoid delays due to forwarding > of messages by relay agents as well as avoid overhead and duplicate > responses by servers due to delivery of client messages to multiple > servers." to each of the DISCUSSION paragraphs explaining the use of > the Unicast option. Perhaps the added sentence is okay, but it still seems to talk about benefits of using unicast, not about when the server should or can use unicast. > 9. (I've once pointed it out, but I'll do it again) Section 17.2.2 > says > If the Solicit message was received directly by the > server,...The Advertise message MUST be unicast through the > interface on which the Solicit message was received. > Technically, the requirement is too strong, since links are larger > than interfaces according to the IPv6 scoped address architecture. > So, more accurately, it should say "The Advertise message MUST be > unicast through the link on which the Solicit message was received." > (Also see the last paragraph of Section 16.) > We used the more specific requirement to avoid the problem of a client > sending a DHCP message on an incorrect interface because the client > had incorrect configuration information about two interfaces being on > the same link. Sorry, I don't understand the response. Section 17.2.2 talks about server's behavior, and I don't get why the restriction on the server side can solve the client's issue. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 10 06:16:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27058; Mon, 10 Jun 2002 06:16:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21626; Mon, 10 Jun 2002 06:14:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21600 for ; Mon, 10 Jun 2002 06:14:23 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27033 for ; Mon, 10 Jun 2002 06:13:49 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5AADpHt019937; Mon, 10 Jun 2002 03:13:52 -0700 (PDT) Date: Mon, 10 Jun 2002 06:13:51 -0400 (EDT) From: Ralph Droms To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dhcwg@ietf.org Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I apologize for the typo - the draft is available at www.dhcp.org/dhcpv6-26.txt - Ralph On Mon, 10 Jun 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > Hello, thanks for the response, > > >>>>> On Wed, 05 Jun 2002 00:02:18 -0400, > >>>>> Ralph Droms said: > > > Thanks for your careful review and helpful comments. We've > > reviewed your comments and included our responses in line > > below. www.dhcp.org/draft-26.txt reflects the changes > > described in this response. > > I cannot get www.dhcp.org/draft-26.txt, but I'm basically fine with > the responses. A few points to clarify: _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 10 06:31:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27225; Mon, 10 Jun 2002 06:31:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22061; Mon, 10 Jun 2002 06:29:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22040 for ; Mon, 10 Jun 2002 06:29:50 -0400 (EDT) Received: from mail3.noc.ntt.co.jp (mail3.noc.ntt.co.jp [210.163.32.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27182 for ; Mon, 10 Jun 2002 06:29:15 -0400 (EDT) Received: from ms2-gw.noc.ntt.com (ms2-gw.noc.ntt.com) by mail3.noc.ntt.co.jp (8.9.3/NOC-MAIL3) id TAA28972; Mon, 10 Jun 2002 19:29:45 +0900 (JST) Received: from mr2-gw.noc.ntt.com by ms2-gw.noc.ntt.com (8.9.3/3.7W) id TAA28710; Mon, 10 Jun 2002 19:29:45 +0900 (JST) Received: from mail1.noc.ntt.com by mr2-gw.noc.ntt.com (8.9.3/3.7W) id TAA28706; Mon, 10 Jun 2002 19:29:44 +0900 (JST) Received: from localhost by mail1.noc.ntt.com (8.9.3/3.7W) id TAA17080; Mon, 10 Jun 2002 19:29:44 +0900 (JST) Date: Mon, 10 Jun 2002 19:31:29 +0900 (JST) Message-Id: <20020610.193129.68475522.yasuhiro@ntt.com> To: jinmei@isl.rdc.toshiba.co.jp Cc: rdroms@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 From: SHIRASAKI Yasuhiro In-Reply-To: References: <4.3.2.7.2.20020604235847.038ade40@funnel.cisco.com> X-Mailer: Mew version 1.95b43 on Emacs 20.4 / Mule 4.1 (AOI) Organization: NTT Communications Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > I cannot get www.dhcp.org/draft-26.txt, but I'm basically fine with > the responses. A few points to clarify: It might be: http://www.dhcp.org/dhcpv6-26.txt -- SHIRASAKI Yasuhiro @ NTT Communications _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 10 07:17:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28405; Mon, 10 Jun 2002 07:17:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24344; Mon, 10 Jun 2002 07:16:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24303 for ; Mon, 10 Jun 2002 07:16:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28132; Mon, 10 Jun 2002 07:16:15 -0400 (EDT) Message-Id: <200206101116.HAA28132@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 10 Jun 2002 07:16:14 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-packetcable-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Option for CableLabs Client Configuration Author(s) : B. Beser, P. Duffy Filename : draft-ietf-dhc-packetcable-02.txt Pages : 12 Date : 06-Jun-02 This document defines a DHCP option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). It is expected that the option content defined within this document will be extended as future CableLabs client devices are developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-02.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-dhc-packetcable-02.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-dhc-packetcable-02.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: <20020607132453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-packetcable-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-packetcable-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607132453.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 10 15:54:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22349; Mon, 10 Jun 2002 15:54:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25784; Mon, 10 Jun 2002 15:53:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25759 for ; Mon, 10 Jun 2002 15:53:30 -0400 (EDT) Received: from manta.infocus.com (moray.infocus.com [209.84.97.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22275 for ; Mon, 10 Jun 2002 15:52:54 -0400 (EDT) Received: by manta.infocus.com (Postfix, from userid 5) id 9AA9428B66; Mon, 10 Jun 2002 12:52:44 -0700 (PDT) Received: from sonata.infocus.com(200.1.10.70), claiming to be "sonata.infocuscorp.com" via SMTP by manta.infocus.com, id smtpdAAAkj71F_; Mon Jun 10 12:52:36 2002 Received: by sonata with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 12:48:58 -0700 Message-ID: From: Chris Pearson To: "'Jeremy Levy'" , dhcwg@ietf.org Subject: RE: [dhcwg] How to respond to Option 50 (requested address) Date: Mon, 10 Jun 2002 12:50:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Sorry, I missed your point. Section 4.3.1 is pretty clear though: When a server receives a DHCPDISCOVER message from a client, the server chooses a network address for the requesting client. If no address is available, the server may choose to report the problem to the system administrator. If an address is available, the new address SHOULD be chosen as follows: o The client's current address as recorded in the client's current binding, ELSE o The client's previous address as recorded in the client's (now expired or released) binding, if that address is in the server's pool of available addresses and not already allocated, ELSE o The address requested in the 'Requested IP Address' option, if that address is valid and not already allocated, ELSE o A new address allocated from the server's pool of available addresses; the address is selected based on the subnet from which the message was received (if 'giaddr' is 0) or on the address of the relay agent that forwarded the message ('giaddr' when not 0). Note that not only does the server *not* have to offer the requested address, it is not even the first choice. And if the first two conditions are absent, your server only "SHOULD" (not "MUST") assign the requested address, so the implementation does have discretion to ignore the requested address even in that case. Apparently your client mistakenly believes that it will get its way by repeatedly asking the same question. The client could eliminate the entire discover/offer exchange by initially broadcasting DHCPREQUEST with desired IP per section 3.2, but I imagine that changing the client is not in your control. - Chris -----Original Message----- From: Jeremy Levy [mailto:jlevy@joltage.com] Sent: Sunday, June 09, 2002 11:37 AM To: dhcwg@ietf.org Subject: RE: [dhcwg] How to respond to Option 50 (requested address) Even in a Discover? Maybe I am missing something but all I can find is this: " If a server receives a DHCPREQUEST message with an invalid 'requested IP address', the server SHOULD respond to the client with a DHCPNAK message and may choose to report the problem to the system administrator. The server may include an error message in the 'message' option." I don't see any information on how to handle this is in a discover if I don't want to give the client its requested IP... Jeremy -----Original Message----- From: Chris Pearson [mailto:chris.pearson@infocus.com] Sent: Friday, June 07, 2002 3:37 PM To: Jeremy Levy; dhcwg@ietf.org Subject: RE: [dhcwg] How to respond to Option 50 (requested address) DHCPNAK. Search RFC2131 for 'Requested IP Address' option for the answer. HTH. -- Chris -----Original Message----- From: Jeremy Levy [mailto:jlevy@joltage.com] Sent: Thursday, June 06, 2002 9:47 AM To: dhcwg@ietf.org Subject: [dhcwg] How to respond to Option 50 (requested address) I have written a DHCP server, however I can't find anything in the RFC about how to handle Option 50, client requested IPAddress on a DHCPDiscovery when I want to give the client a different address. Right now I just respond with a DHCPOffer with a different IP. After 2 or 3 Discovers/Offers the client finally sends a request. Am I handling this properly? I would like to get rid of those 2 or 3 middle Discover/Offers and speed up the process a bit... Thanks Jeremy _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 10 17:06:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25490; Mon, 10 Jun 2002 17:06:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00585; Mon, 10 Jun 2002 17:06:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24220 for ; Mon, 10 Jun 2002 07:16:34 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28084 for ; Mon, 10 Jun 2002 07:15:59 -0400 (EDT) Received: from sngrel7.hp.com (sngrel7.hp.com [192.6.86.111]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g5ABGWH01602 for ; Mon, 10 Jun 2002 07:16:32 -0400 (EDT) Received: from ctss200.sgp.hp.com (ctss200.sgp.hp.com [15.68.10.200]) by sngrel7.hp.com (Postfix) with ESMTP id EDF0F9CE for ; Mon, 10 Jun 2002 19:16:26 +0800 (SST) Received: from xsgbrg3.sgp.hp.com (xsgbrg3.sgp.hp.com [15.85.49.115]) by ctss200.sgp.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id TAA13566 for ; Mon, 10 Jun 2002 19:16:26 +0800 (SGP) Received: from 15.85.49.115 by xsgbrg3.sgp.hp.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 19:15:53 +0800 Received: by xsgbrg3.sgp.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Jun 2002 19:15:53 +0800 Message-ID: From: "CHOPRA,VIVEK (HP-Singapore,ex5)" To: "'dhcp-v4@bucknell.edu'" Date: Mon, 10 Jun 2002 19:15:51 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-1eb44282-6f1a-47d2-9182-b2eedd05c973" Subject: [dhcwg] how to send configuration settings from DHCP server to clients ? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-1eb44282-6f1a-47d2-9182-b2eedd05c973 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21070.2E0423C0" ------_=_NextPart_001_01C21070.2E0423C0 Content-Type: text/plain; charset="iso-8859-1" Hi .. I want to send some configuration settings from DHCP server to the client. These settings are my proprietary settings. For example: IP address of the portal website and things like that. Can you tell me if there is a way to send such configuration information from DHCP server to client using the DHCP messages ?? And what changes would I need to make to my DHCP server to cater for these extra settings to be sent ? Thanks in advance Vivek ------_=_NextPart_001_01C21070.2E0423C0 Content-Type: text/html; charset="iso-8859-1"
Hi ..
 
I want to send some configuration settings from DHCP server to the client. These settings are my proprietary settings. For example: IP address of the portal website and things like that.
Can you tell me if there is a way to send such configuration information from DHCP server to client using the DHCP messages ??
 
And what changes would I need to make to my DHCP server to cater for these extra settings to be sent ?
 
Thanks in advance
Vivek
------_=_NextPart_001_01C21070.2E0423C0-- ------=_NextPartTM-000-1eb44282-6f1a-47d2-9182-b2eedd05c973-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 11 01:48:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05210; Tue, 11 Jun 2002 01:48:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00057; Tue, 11 Jun 2002 01:46:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29220 for ; Tue, 11 Jun 2002 01:30:26 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04980 for ; Tue, 11 Jun 2002 01:29:49 -0400 (EDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5B5UH878183; Tue, 11 Jun 2002 14:30:18 +0900 (JST) Date: Tue, 11 Jun 2002 14:30:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 In-Reply-To: <4.3.2.7.2.20020604235847.038ade40@funnel.cisco.com> References: <4.3.2.7.2.20020604235847.038ade40@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 87 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >>>>> On Wed, 05 Jun 2002 00:02:18 -0400, >>>>> Ralph Droms said: > Thanks for your careful review and helpful comments. We've > reviewed your comments and included our responses in line > below. www.dhcp.org/draft-26.txt reflects the changes > described in this response. I've checked the latest snapshot. The followings are supplement comments based on the latest one. > 5. Section 17.1.1. says > The client MAY include > options with data values as hints to the server about parameter > values the client would like to have returned. > I'm not sure how the data values are specified. An option request > option can only specify required option "types"... > The same comments applies to Sections 18.1.1 and 18.1.5. > The client includes the requested option (rather than indicating the > option in the Option Request option), containing the desired option > value. I'm not sure if the current text (which is same as previous ones) can read like this. I can live with the current wording, but would be happier if the text says this point more clearly. > 6. Section 17.1.3 says (snip) > Text in 17.2.2 clarified to specify that server returns AddrUnavail > only if the client included IA options in the Solicit message. Is this really true? The latest one just says If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail, a status message for the user, a Server Identifier option with the server's DUID and a Client Identifier option with the client's DUID. I can't read this to mean that AddrUnavail is limited to the case where IAs are in Solicit. BTW: there seems to be some confusion about status code names. The latest snap uses "NoAddrsAvail", not "AddrUnavail". The latter one is actually used nowhere except in Section 24.4 (a summary list of status codes). If AddrUnavail was deprecated, it should be removed from the list IMO. The same comment applies to ConfNoMatch. > 11. Section 18.2.6 says "The server ignores invalid addresses." What > does "invalid" exactly mean? In particular, I'm not sure if the > source address of the receipt message is "invalid" or not (note > that section 18.1.7 prohibits the client to use addresses being > released as the source address). The text should clearly define > the term "invalid". > The same comment applies to Section 18.2.7. > The phrase "invalid addresses" has been clarified. Hmm, the current text says: The server ignores addresses not assigned to the IA, and it may make a notification if it finds such an address. But my main point is not addressed; what if the source address of the release message is contained in an IA of the message (where the source address was assigned to the IA)? Again, please note 18.1.6 has a corresponding restriction: The client MUST NOT use any of the addresses it is releasing as the source address in the Release message or in any subsequently transmitted message. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 11 01:48:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05209; Tue, 11 Jun 2002 01:48:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00041; Tue, 11 Jun 2002 01:46:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29542 for ; Tue, 11 Jun 2002 01:31:45 -0400 (EDT) Received: from shared1-mail.whowhere.com (shared1-batch.whowhere.com [209.185.123.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05034 for ; Tue, 11 Jun 2002 01:31:09 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Mon Jun 10 22:31:03 2002 To: "dhcwg@ietf.org" Date: Tue, 11 Jun 2002 11:01:03 +0530 From: "Priya S R" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: priyasram@eudoramail.com X-Mailer: MailCity Service X-Sender-Ip: 203.115.108.131 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP client Broadcast Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit hi, i would like to implement a DHCP client. Actually, i have a java source code for DHCP client, in which UDP is using for sending DHCP broadcast messages suce as DHCPDISCOVER, DHCPOFFER etc, But i couldn't send an UDP broadcast after removing the IP address of my system. Please help me to send a broadcast message without assigning an IP to my system. thanks in advance REgards Priya Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 11 07:06:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17946; Tue, 11 Jun 2002 07:06:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15769; Tue, 11 Jun 2002 07:06:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15746 for ; Tue, 11 Jun 2002 07:06:17 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17746; Tue, 11 Jun 2002 07:05:40 -0400 (EDT) Message-Id: <200206111105.HAA17746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 11 Jun 2002 07:05:39 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-26.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, R. Droms, C. Perkins, B. Volz, T. Lemon, M. Carney Filename : draft-ietf-dhc-dhcpv6-26.txt Pages : 87 Date : 10-Jun-02 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' (RFC2462), and can be used separately or concurrently with the latter to obtain configuration parameters A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-26.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-dhc-dhcpv6-26.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-dhc-dhcpv6-26.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: <20020610142950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-26.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-26.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610142950.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 11 08:28:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20043; Tue, 11 Jun 2002 08:28:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20116; Tue, 11 Jun 2002 08:28:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20096 for ; Tue, 11 Jun 2002 08:28:44 -0400 (EDT) Received: from shared1-mail.whowhere.com (shared1-batch.whowhere.com [209.185.123.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20029 for ; Tue, 11 Jun 2002 08:28:08 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Tue Jun 11 05:28:05 2002 To: dhcwg@ietf.org Date: Tue, 11 Jun 2002 17:58:05 +0530 From: "Priya S R" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: priyasram@eudoramail.com X-Expiredinmiddle: true X-Mailer: MailCity Service X-Sender-Ip: 203.115.108.131 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP client Broadcast Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit hi all, I would like to create a DHCP client. So i have to send a broadcast message from my system. I tried to send broadcast msgs using datagram sockets in Java, (UDP) But i couldn't send the broadcast message after releasing my IP address. Please help me to send broadcast messages without having an IP address to my system. Thaks in advance regards Priya Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 11 22:16:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20112; Tue, 11 Jun 2002 22:16:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03732; Tue, 11 Jun 2002 22:16:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03704 for ; Tue, 11 Jun 2002 22:16:10 -0400 (EDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20091 for ; Tue, 11 Jun 2002 22:15:33 -0400 (EDT) Received: from galadriel ([172.16.3.219]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id KAA26767; Wed, 12 Jun 2002 10:14:14 +0800 (SGT) Message-ID: <002901c211b6$79cbe1c0$db0310ac@galadriel> From: "Raymond Jayaraj" To: Cc: "Ralph Droms" , References: <013801c20c64$09121c80$db0310ac@galadriel> Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 Date: Wed, 12 Jun 2002 10:11:33 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi. Thx for the response! ----- Original Message ----- From: )> To: "Raymond Jayaraj" Cc: "Ralph Droms" ; Sent: Monday, June 10, 2002 1:31 PM Subject: Re: [dhcwg] unresolved comments in dhcpv6-25 > >>>>> On Wed, 5 Jun 2002 15:38:50 +0800, > >>>>> "Raymond Jayaraj" said: > > >> Changed definition of binding to: > >> > >> binding A binding (or, client binding) is a group of server data > >> records containing the information the server has about > >> the addresses in an IA or configuration information > >> assigned to the client. A binding containing > >> information about an IA is indexed by the tuple >> IA-type, IAID> (where IA-type is the type of address in > >> the IA; for example, temporary). A binding containing > >> configuration information for a client is indexed by > >> . > > > Sorry to barge in like this; but we're also hot on the heels of > > implementing (and verifying) DHC6, and would like to confirm if: > > > By the change in the definition as above, a node can use stateless > > (RA) address(es) yet maintain (RENEW/REBIND applies) stateful, > > address-unrelated, context/configuration (e.g. roaming, security, > > qos, billing, mobility etc.) information with the network via DHC6? > > In my understanding, yes, but the specification of dhcpv6 originally > intended to allow such coexistence. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 12 14:09:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07478; Wed, 12 Jun 2002 14:09:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16086; Wed, 12 Jun 2002 14:09:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16056 for ; Wed, 12 Jun 2002 14:09:54 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07468 for ; Wed, 12 Jun 2002 14:09:18 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-253.cisco.com [161.44.149.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA22466 for ; Wed, 12 Jun 2002 14:09:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20020612140907.00b72450@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jun 2002 14:09:12 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Changed to DHCPv6 spec Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Since the DHCPv6 spec went through WG last call, we've received feedback from several sources. The latest draft of the spec, draft-ietf-dhc-dhcpv6-26.txt, includes changes based on that feedback. The changes are summarized at the end of the spec; here is a summary of the changes that have an impact on the operation of the protocol: * Deleted definition of the use of anycast from the base spec document; use of DHCPv6 over links that do not support multicast will be defined in separate docs (e.g., "IPv6 over XXX") * The DUID based on an enterprise identifier now uses the Enterprise Number (as recorded by IANA) instead of a domain name * The use of multiple relay agents ("chaining") between a client and a server is defined * If a client does not receive a Reply in response to a Solicit message with a Rapid Commit option, it may send a Request to a router from which it received an Advertise message (received while the client was waiting for the Reply message) * The Confirm message is now used only for checking that a client's addresses are "appropriate to the link" (the addresses are consistent with the DHCP server's knowledge of the network topology, prefix assignment and address assignment policies) to which the client is attached * A server can send an identifier, called the "reconfigure nonce" to a client to prevent DoS attacks through Reconfigure messages sent from off-path attackers; the server initially sends the reconfigure nonce in a Reply and tags Reconfigure messages with the same reconfigure nonce to identify itself as the source of the Reconfigure message * A client now MUST send an Option Request option listing all of the options the client wants to receive; a server may send other options in addition to those specified in the Option Request option * Adjusted several of the retransmission parameters in section 5.6 Please respond to the mailing list if you have questions or comments about any of these changes... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 13 08:28:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09242; Thu, 13 Jun 2002 08:28:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15286; Thu, 13 Jun 2002 08:27:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15272 for ; Thu, 13 Jun 2002 08:27:56 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09156 for ; Thu, 13 Jun 2002 08:27:20 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5DCROHt001786 for ; Thu, 13 Jun 2002 05:27:24 -0700 (PDT) Date: Thu, 13 Jun 2002 08:27:24 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DHC WG charter Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The Internet ADs have suggested it is time (likely *way* past time) to revisit the DHC WG charter. Here's a first pass at what I see as the issues currently in front of the WG. The objectives are not presented in any particular order. Please review and send your comments to the mailing list. The goal is to have consensus on a list of objectives for final review at the WG meeting in Yokohama. - Ralph ===== The working group has the following primary objectives: * Develop additional authentication protocols within the framework defined in RFC3118, along with other mechanisms to mitigate the threat of attacks on DHCP clients and servers: - New RFC3118 protocols to address improved key management and improved scalability - Provide security for messages passed between relay agents and servers - Consider solutions for specific threats such as use of nonce identifier to defend against DoS attacks through FORCERENEW from off-path attackers * Complete the specification of DHCP for IPv6 (DHCPv6): - Gain acceptance and publication of current Internet Draft as Proposed Standard - Develop and publish specifications for options and other extensions to DHCPv6, including those already published as Internet Drafts: + "DNS Configuration Options for DHCPv6" + "Time Configuration Options for DHCPv6" + "NIS Configuration Options for DHCPv6" + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6" + "Load Balancing for DHCPv6" - Encourage independent implementations and conduct interoperability testing - Revise specification and publish for acceptance as Draft Standard by 6/30/2002 - Develop extensions to DHCPv6 for prefix delegation, DNS configuration, etc. * Revise and submit the DHCP specification for acceptance as a Full Standard * Complete the specification and publish work in progress as standards: - Failover protocol - DHCP/DDNS interaction - SNMP MIB - Host name options - Other client and relay agent options * Review new options for DHCP, as deemed appropriate by the working group and/or the Internet area directors _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 13 09:38:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11791; Thu, 13 Jun 2002 09:38:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20000; Thu, 13 Jun 2002 09:36:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19971 for ; Thu, 13 Jun 2002 09:36:34 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11664 for ; Thu, 13 Jun 2002 09:35:57 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5D8378DD8; Thu, 13 Jun 2002 09:36:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 09:36:33 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] DHC WG charter Date: Thu, 13 Jun 2002 09:36:32 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A24@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] DHC WG charter Thread-Index: AcIS1fmAZVVDWE91S36bfMkbZo99/QACPUyQ From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 13 Jun 2002 13:36:33.0400 (UTC) FILETIME=[55114F80:01C212DF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA19972 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Ralph, I think we need to add something to the charter for Mobility and Prefix delegation for IPv6. I think this team and group can do a lot of good and help with evolution of wireless networks and the integration of Mobile. Specifically: - Determine the requirements for DHC to support the dynamic renumbering of networks using fast path delegaion as CPE front end between ISP and Private Networks. What do others think? I just think we have work to do in this space and not sorted it all out yet. But do we have to for a charter? thanks /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, June 13, 2002 8:27 AM > To: dhcwg@ietf.org > Subject: [dhcwg] DHC WG charter > > > The Internet ADs have suggested it is time (likely > *way* past time) to revisit the DHC WG charter. Here's a > first pass at > what I see as the issues currently in front of the WG. The > objectives are > not presented in any particular order. > > Please review and send your comments to the mailing list. The goal is > to have consensus on a list of objectives for final review at the WG > meeting in Yokohama. > > - Ralph > > ===== > > The working group has the following primary objectives: > > * Develop additional authentication protocols within the framework > defined in RFC3118, along with other mechanisms to mitigate the > threat of attacks on DHCP clients and servers: > - New RFC3118 protocols to address improved key management and > improved scalability > - Provide security for messages passed between relay agents and > servers > - Consider solutions for specific threats such as use of nonce > identifier to defend against DoS attacks through FORCERENEW from > off-path attackers > > * Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of current Internet Draft as > Proposed Standard > - Develop and publish specifications for options and other > extensions to DHCPv6, including those already published as > Internet Drafts: > + "DNS Configuration Options for DHCPv6" > + "Time Configuration Options for DHCPv6" > + "NIS Configuration Options for DHCPv6" > + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6" > + "Load Balancing for DHCPv6" > - Encourage independent implementations and conduct interoperability > testing > - Revise specification and publish for acceptance as Draft Standard > by 6/30/2002 > - Develop extensions to DHCPv6 for prefix delegation, DNS > configuration, etc. > > * Revise and submit the DHCP specification for acceptance as a Full > Standard > > * Complete the specification and publish work in progress as > standards: > - Failover protocol > - DHCP/DDNS interaction > - SNMP MIB > - Host name options > - Other client and relay agent options > > * Review new options for DHCP, as deemed appropriate by the working > group and/or the Internet area directors > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 13 10:05:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13236; Thu, 13 Jun 2002 10:05:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23067; Thu, 13 Jun 2002 10:03:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23031 for ; Thu, 13 Jun 2002 10:03:36 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13060 for ; Thu, 13 Jun 2002 10:02:57 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g5DE32i20955 for ; Thu, 13 Jun 2002 09:03:02 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g5DE31Z02740 for ; Thu, 13 Jun 2002 09:03:02 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jun 13 09:03:00 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 09:02:24 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D5BA@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bound, Jim'" , Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Date: Thu, 13 Jun 2002 09:02:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212E3.0289B2D0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C212E3.0289B2D0 Content-Type: text/plain; charset="iso-8859-1" Jim: Yes mobility and prefix delegation would be good to consider. I think it might already be addressed by: > - Develop extensions to DHCPv6 for prefix delegation, DNS > configuration, etc. Regarding your addition: >- Determine the requirements for DHC to support the dynamic renumbering >of networks using fast path delegaion as CPE front end between ISP and >Private Networks. This seems too specific and I'm not exactly sure what it means. Perhaps the requirement is to determine how DHCP can be used to assist in rapid renumbering of networks? - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Thursday, June 13, 2002 9:37 AM To: Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Ralph, I think we need to add something to the charter for Mobility and Prefix delegation for IPv6. I think this team and group can do a lot of good and help with evolution of wireless networks and the integration of Mobile. Specifically: - Determine the requirements for DHC to support the dynamic renumbering of networks using fast path delegaion as CPE front end between ISP and Private Networks. What do others think? I just think we have work to do in this space and not sorted it all out yet. But do we have to for a charter? thanks /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, June 13, 2002 8:27 AM > To: dhcwg@ietf.org > Subject: [dhcwg] DHC WG charter > > > The Internet ADs have suggested it is time (likely > *way* past time) to revisit the DHC WG charter. Here's a > first pass at > what I see as the issues currently in front of the WG. The > objectives are > not presented in any particular order. > > Please review and send your comments to the mailing list. The goal is > to have consensus on a list of objectives for final review at the WG > meeting in Yokohama. > > - Ralph > > ===== > > The working group has the following primary objectives: > > * Develop additional authentication protocols within the framework > defined in RFC3118, along with other mechanisms to mitigate the > threat of attacks on DHCP clients and servers: > - New RFC3118 protocols to address improved key management and > improved scalability > - Provide security for messages passed between relay agents and > servers > - Consider solutions for specific threats such as use of nonce > identifier to defend against DoS attacks through FORCERENEW from > off-path attackers > > * Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of current Internet Draft as > Proposed Standard > - Develop and publish specifications for options and other > extensions to DHCPv6, including those already published as > Internet Drafts: > + "DNS Configuration Options for DHCPv6" > + "Time Configuration Options for DHCPv6" > + "NIS Configuration Options for DHCPv6" > + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6" > + "Load Balancing for DHCPv6" > - Encourage independent implementations and conduct interoperability > testing > - Revise specification and publish for acceptance as Draft Standard > by 6/30/2002 > - Develop extensions to DHCPv6 for prefix delegation, DNS > configuration, etc. > > * Revise and submit the DHCP specification for acceptance as a Full > Standard > > * Complete the specification and publish work in progress as > standards: > - Failover protocol > - DHCP/DDNS interaction > - SNMP MIB > - Host name options > - Other client and relay agent options > > * Review new options for DHCP, as deemed appropriate by the working > group and/or the Internet area directors > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C212E3.0289B2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHC WG charter

Jim:

Yes mobility and prefix delegation would be good to = consider. I think it
might already be addressed by:
>   - Develop extensions to DHCPv6 for = prefix delegation, DNS
>     configuration, = etc.

Regarding your addition:
>- Determine the requirements for DHC to support = the dynamic renumbering
>of networks using fast path delegaion as CPE = front end between ISP and
>Private Networks.

This seems too specific and I'm not exactly sure what = it means. Perhaps the
requirement is to determine how DHCP can be used to = assist in rapid
renumbering of networks?

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Thursday, June 13, 2002 9:37 AM
To: Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] DHC WG charter


Ralph,

I think we need to add something to the charter for = Mobility and Prefix delegation for IPv6.  I think this team and = group can do a lot of good and help with evolution of wireless networks = and the integration of Mobile.  Specifically:

- Determine the requirements for DHC to support the = dynamic renumbering of networks using fast path delegaion as CPE front = end between ISP and Private Networks.

What do others think?  I just think we have work = to do in this space and not sorted it all out yet.  But do we have = to for a charter?

thanks
/jim

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Thursday, June 13, 2002 8:27 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] DHC WG charter
>
>
> The Internet ADs have suggested it is time = (likely
> *way* past time) to revisit the DHC WG = charter.  Here's a
> first pass at
> what I see as the issues currently in front of = the WG.  The
> objectives are
> not presented in any particular order.
>
> Please review and send your comments to the = mailing list.  The goal is
> to have consensus on a list of objectives for = final review at the WG
> meeting in Yokohama.
>
> - Ralph
>
> =3D=3D=3D=3D=3D
>
> The working group has the following primary = objectives:
>
> * Develop additional authentication protocols = within the framework
>   defined in RFC3118, along with = other mechanisms to mitigate the
>   threat of attacks on DHCP clients = and servers:
>   - New RFC3118 protocols to address = improved key management and
>     improved = scalability
>   - Provide security for messages = passed between relay agents and
>     servers
>   - Consider solutions for specific = threats such as use of nonce
>     identifier to defend = against DoS attacks through FORCERENEW from
>     off-path = attackers
>
> * Complete the specification of DHCP for IPv6 = (DHCPv6):
>   - Gain acceptance and publication = of current Internet Draft as
>     Proposed = Standard
>   - Develop and publish = specifications for options and other
>     extensions to DHCPv6, = including those already published as
>     Internet Drafts:
>     + "DNS = Configuration Options for DHCPv6"
>     + "Time = Configuration Options for DHCPv6"
>     + "NIS = Configuration Options for DHCPv6"
>     + "DSTM Ports = Option for DHCPv6", "DSTM Options for DHCPv6"
>     + "Load Balancing = for DHCPv6"
>   - Encourage independent = implementations and conduct interoperability
>     testing
>   - Revise specification and publish = for acceptance as Draft Standard
>     by 6/30/2002
>   - Develop extensions to DHCPv6 for = prefix delegation, DNS
>     configuration, = etc.
>
> * Revise and submit the DHCP specification for = acceptance as a Full
>   Standard
>
> * Complete the specification and publish work = in progress as
>   standards:
>   - Failover protocol
>   - DHCP/DDNS interaction
>   - SNMP MIB
>   - Host name options
>   - Other client and relay agent = options
>
> * Review new options for DHCP, as deemed = appropriate by the working
>   group and/or the Internet area = directors
>
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C212E3.0289B2D0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 13 15:23:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27341; Thu, 13 Jun 2002 15:23:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15209; Thu, 13 Jun 2002 15:22:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15186 for ; Thu, 13 Jun 2002 15:22:24 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27206 for ; Thu, 13 Jun 2002 15:21:47 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 39196414A; Thu, 13 Jun 2002 15:22:22 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Jun 2002 15:22:21 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2130F.A3D91216" Subject: RE: [dhcwg] DHC WG charter Date: Thu, 13 Jun 2002 15:22:21 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8A3B@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] DHC WG charter Thread-Index: AcIS4w15NDs5VD+QTkqrJplcMqPtcAALEbqA From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Ralph Droms" , X-OriginalArrivalTime: 13 Jun 2002 19:22:21.0706 (UTC) FILETIME=[A4058EA0:01C2130F] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C2130F.A3D91216 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bernie, =20 Let me be more direct. I want to see routers be able to use lightweight = DHCP to support IPv6 information requests, router renumbering, and the = like. The below ext text is good but I am looking for us to extend the = architecture of dhcp to support lightweight processes for router or = gateways or what is now called edge-servers. So I think it needs a = separate bullet. =20 Let me think and come up with different wording? =20 p.s. Ralph - whats our time frame to discuss the charter? =20 thanks /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, June 13, 2002 10:03 AM To: Bound, Jim; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Jim:=20 Yes mobility and prefix delegation would be good to consider. I think it = might already be addressed by:=20 > - Develop extensions to DHCPv6 for prefix delegation, DNS=20 > configuration, etc.=20 Regarding your addition:=20 >- Determine the requirements for DHC to support the dynamic renumbering = >of networks using fast path delegaion as CPE front end between ISP and=20 >Private Networks.=20 This seems too specific and I'm not exactly sure what it means. Perhaps = the=20 requirement is to determine how DHCP can be used to assist in rapid=20 renumbering of networks?=20 - Bernie=20 -----Original Message-----=20 From: Bound, Jim [ mailto:Jim.Bound@hp.com]=20 Sent: Thursday, June 13, 2002 9:37 AM=20 To: Ralph Droms; dhcwg@ietf.org=20 Subject: RE: [dhcwg] DHC WG charter=20 Ralph,=20 I think we need to add something to the charter for Mobility and Prefix = delegation for IPv6. I think this team and group can do a lot of good = and help with evolution of wireless networks and the integration of = Mobile. Specifically: - Determine the requirements for DHC to support the dynamic renumbering = of networks using fast path delegaion as CPE front end between ISP and = Private Networks. What do others think? I just think we have work to do in this space and = not sorted it all out yet. But do we have to for a charter? thanks=20 /jim=20 > -----Original Message-----=20 > From: Ralph Droms [ mailto:rdroms@cisco.com]=20 > Sent: Thursday, June 13, 2002 8:27 AM=20 > To: dhcwg@ietf.org=20 > Subject: [dhcwg] DHC WG charter=20 >=20 >=20 > The Internet ADs have suggested it is time (likely=20 > *way* past time) to revisit the DHC WG charter. Here's a=20 > first pass at=20 > what I see as the issues currently in front of the WG. The=20 > objectives are=20 > not presented in any particular order.=20 >=20 > Please review and send your comments to the mailing list. The goal is = > to have consensus on a list of objectives for final review at the WG=20 > meeting in Yokohama.=20 >=20 > - Ralph=20 >=20 > =3D=3D=3D=3D=3D=20 >=20 > The working group has the following primary objectives:=20 >=20 > * Develop additional authentication protocols within the framework=20 > defined in RFC3118, along with other mechanisms to mitigate the=20 > threat of attacks on DHCP clients and servers:=20 > - New RFC3118 protocols to address improved key management and=20 > improved scalability=20 > - Provide security for messages passed between relay agents and=20 > servers=20 > - Consider solutions for specific threats such as use of nonce=20 > identifier to defend against DoS attacks through FORCERENEW from=20 > off-path attackers=20 >=20 > * Complete the specification of DHCP for IPv6 (DHCPv6):=20 > - Gain acceptance and publication of current Internet Draft as=20 > Proposed Standard=20 > - Develop and publish specifications for options and other=20 > extensions to DHCPv6, including those already published as=20 > Internet Drafts:=20 > + "DNS Configuration Options for DHCPv6"=20 > + "Time Configuration Options for DHCPv6"=20 > + "NIS Configuration Options for DHCPv6"=20 > + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6"=20 > + "Load Balancing for DHCPv6"=20 > - Encourage independent implementations and conduct interoperability = > testing=20 > - Revise specification and publish for acceptance as Draft Standard=20 > by 6/30/2002=20 > - Develop extensions to DHCPv6 for prefix delegation, DNS=20 > configuration, etc.=20 >=20 > * Revise and submit the DHCP specification for acceptance as a Full=20 > Standard=20 >=20 > * Complete the specification and publish work in progress as=20 > standards:=20 > - Failover protocol=20 > - DHCP/DDNS interaction=20 > - SNMP MIB=20 > - Host name options=20 > - Other client and relay agent options=20 >=20 > * Review new options for DHCP, as deemed appropriate by the working=20 > group and/or the Internet area directors=20 >=20 >=20 >=20 > _______________________________________________=20 > dhcwg mailing list=20 > dhcwg@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/dhcwg=20 >=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dhcwg=20 ------_=_NextPart_001_01C2130F.A3D91216 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHC WG charter
Bernie,
 
Let me=20 be more direct.  I want to see routers be able to use lightweight = DHCP to=20 support IPv6 information requests, router renumbering, and the = like.  The=20 below ext text is good but I am looking for us to extend the = architecture of=20 dhcp to support lightweight processes for router or gateways or what is = now=20 called edge-servers.  So I think it needs a separate=20 bullet.
 
Let me=20 think and come up with different wording?
 
p.s.=20 Ralph - whats our time frame to discuss the charter?
 
thanks
/jim
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, June = 13, 2002=20 10:03 AM
To: Bound, Jim; Ralph Droms;=20 dhcwg@ietf.org
Subject: RE: [dhcwg] DHC WG=20 charter

Jim:

Yes mobility and prefix delegation would be good to = consider.=20 I think it
might already be addressed = by:=20
>   - Develop extensions to DHCPv6 for = prefix=20 delegation, DNS
>     = configuration, etc.

Regarding your addition:
>-=20 Determine the requirements for DHC to support the dynamic = renumbering=20
>of networks using fast path delegaion as CPE = front end=20 between ISP and
>Private Networks. =

This seems too specific and I'm not exactly sure = what it=20 means. Perhaps the
requirement is to = determine how=20 DHCP can be used to assist in rapid
renumbering of=20 networks?

- Bernie

-----Original Message-----
From:=20 Bound, Jim [mailto:Jim.Bound@hp.com] =
Sent: Thursday, June 13, 2002 9:37 AM
To: Ralph=20 Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] = DHC WG=20 charter


Ralph,

I think we need to add something to the charter for = Mobility=20 and Prefix delegation for IPv6.  I think this team and group can = do a lot=20 of good and help with evolution of wireless networks and the = integration of=20 Mobile.  Specifically:

- Determine the requirements for DHC to support the = dynamic=20 renumbering of networks using fast path delegaion as CPE front end = between ISP=20 and Private Networks.

What do others think?  I just think we have = work to do in=20 this space and not sorted it all out yet.  But do we have to for = a=20 charter?

thanks
/jim

> -----Original Message-----
>=20 From: Ralph Droms [mailto:rdroms@cisco.com] =
> Sent: Thursday, June 13, 2002 8:27 AM
>=20 To: dhcwg@ietf.org
> Subject: [dhcwg] DHC = WG=20 charter
>
>=20
> The Internet ADs have suggested it is = time=20 (likely
> *way* past time) to revisit the = DHC WG=20 charter.  Here's a
> first pass = at=20
> what I see as the issues currently in front of = the=20 WG.  The
> objectives are =
> not presented in any particular order.
>
> Please review and send = your comments=20 to the mailing list.  The goal is
> = to have=20 consensus on a list of objectives for final review at the WG =
> meeting in Yokohama.
> =
> - Ralph
>
>=20 =3D=3D=3D=3D=3D
>
> The working=20 group has the following primary objectives:
>=20
> * Develop additional authentication = protocols=20 within the framework
>   = defined in=20 RFC3118, along with other mechanisms to mitigate the
>   threat of attacks on DHCP clients and = servers:=20
>   - New RFC3118 protocols to address = improved=20 key management and
>    =20 improved scalability
>   - = Provide=20 security for messages passed between relay agents and
>     servers
>   - Consider solutions for specific threats = such as use=20 of nonce
>     = identifier to=20 defend against DoS attacks through FORCERENEW from
>     off-path attackers =
>
> * Complete the = specification of DHCP=20 for IPv6 (DHCPv6):
>   - Gain = acceptance=20 and publication of current Internet Draft as
>     Proposed Standard =
>   - Develop and publish specifications for = options and=20 other
>     = extensions to=20 DHCPv6, including those already published as
>     Internet Drafts: =
>     + "DNS Configuration Options for = DHCPv6"
>     + "Time = Configuration Options for DHCPv6"
>     + "NIS Configuration Options for = DHCPv6"
>     + "DSTM = Ports=20 Option for DHCPv6", "DSTM Options for DHCPv6"
>     + "Load Balancing for = DHCPv6"=20
>   - Encourage independent = implementations and=20 conduct interoperability
>    =20 testing
>   - Revise = specification and=20 publish for acceptance as Draft Standard
>     by 6/30/2002
>   - Develop extensions to DHCPv6 for prefix = delegation,=20 DNS
>     = configuration,=20 etc.
>
> * = Revise and=20 submit the DHCP specification for acceptance as a Full =
>   Standard
> =
> * Complete the specification and publish work in = progress=20 as
>   standards: =
>   - Failover protocol
>   - DHCP/DDNS interaction
>   - SNMP MIB
>   -=20 Host name options
>   - Other = client and=20 relay agent options
>
>=20 * Review new options for DHCP, as deemed appropriate by the = working=20
>   group and/or the Internet area=20 directors
>
>=20
>
>=20 _______________________________________________
>=20 dhcwg mailing list
> = dhcwg@ietf.org=20
> https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20
>

_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------_=_NextPart_001_01C2130F.A3D91216-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 14 00:15:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10673; Fri, 14 Jun 2002 00:15:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11303; Fri, 14 Jun 2002 00:14:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11228 for ; Fri, 14 Jun 2002 00:14:21 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10656 for ; Fri, 14 Jun 2002 00:13:45 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g5E3Qqi18193 for ; Thu, 13 Jun 2002 22:26:52 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g5E3Qpk13836 for ; Thu, 13 Jun 2002 22:26:51 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Jun 13 22:26:50 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 13 Jun 2002 22:26:00 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69CECFEC@EAMBUNT705> From: "Bernie Volz (EUD)" To: "Bound, Jim" , Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Date: Thu, 13 Jun 2002 22:26:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21353.50A8FAA0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21353.50A8FAA0 Content-Type: text/plain; charset="iso-8859-1" Jim: That's fine by me. Just wasn't clear (to me) from your previous bullet. - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Thursday, June 13, 2002 3:22 PM To: Bernie Volz (EUD); Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Bernie, Let me be more direct. I want to see routers be able to use lightweight DHCP to support IPv6 information requests, router renumbering, and the like. The below ext text is good but I am looking for us to extend the architecture of dhcp to support lightweight processes for router or gateways or what is now called edge-servers. So I think it needs a separate bullet. Let me think and come up with different wording? p.s. Ralph - whats our time frame to discuss the charter? thanks /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, June 13, 2002 10:03 AM To: Bound, Jim; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Jim: Yes mobility and prefix delegation would be good to consider. I think it might already be addressed by: > - Develop extensions to DHCPv6 for prefix delegation, DNS > configuration, etc. Regarding your addition: >- Determine the requirements for DHC to support the dynamic renumbering >of networks using fast path delegaion as CPE front end between ISP and >Private Networks. This seems too specific and I'm not exactly sure what it means. Perhaps the requirement is to determine how DHCP can be used to assist in rapid renumbering of networks? - Bernie -----Original Message----- From: Bound, Jim [ mailto:Jim.Bound@hp.com ] Sent: Thursday, June 13, 2002 9:37 AM To: Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] DHC WG charter Ralph, I think we need to add something to the charter for Mobility and Prefix delegation for IPv6. I think this team and group can do a lot of good and help with evolution of wireless networks and the integration of Mobile. Specifically: - Determine the requirements for DHC to support the dynamic renumbering of networks using fast path delegaion as CPE front end between ISP and Private Networks. What do others think? I just think we have work to do in this space and not sorted it all out yet. But do we have to for a charter? thanks /jim > -----Original Message----- > From: Ralph Droms [ mailto:rdroms@cisco.com ] > Sent: Thursday, June 13, 2002 8:27 AM > To: dhcwg@ietf.org > Subject: [dhcwg] DHC WG charter > > > The Internet ADs have suggested it is time (likely > *way* past time) to revisit the DHC WG charter. Here's a > first pass at > what I see as the issues currently in front of the WG. The > objectives are > not presented in any particular order. > > Please review and send your comments to the mailing list. The goal is > to have consensus on a list of objectives for final review at the WG > meeting in Yokohama. > > - Ralph > > ===== > > The working group has the following primary objectives: > > * Develop additional authentication protocols within the framework > defined in RFC3118, along with other mechanisms to mitigate the > threat of attacks on DHCP clients and servers: > - New RFC3118 protocols to address improved key management and > improved scalability > - Provide security for messages passed between relay agents and > servers > - Consider solutions for specific threats such as use of nonce > identifier to defend against DoS attacks through FORCERENEW from > off-path attackers > > * Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of current Internet Draft as > Proposed Standard > - Develop and publish specifications for options and other > extensions to DHCPv6, including those already published as > Internet Drafts: > + "DNS Configuration Options for DHCPv6" > + "Time Configuration Options for DHCPv6" > + "NIS Configuration Options for DHCPv6" > + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6" > + "Load Balancing for DHCPv6" > - Encourage independent implementations and conduct interoperability > testing > - Revise specification and publish for acceptance as Draft Standard > by 6/30/2002 > - Develop extensions to DHCPv6 for prefix delegation, DNS > configuration, etc. > > * Revise and submit the DHCP specification for acceptance as a Full > Standard > > * Complete the specification and publish work in progress as > standards: > - Failover protocol > - DHCP/DDNS interaction > - SNMP MIB > - Host name options > - Other client and relay agent options > > * Review new options for DHCP, as deemed appropriate by the working > group and/or the Internet area directors > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C21353.50A8FAA0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] DHC WG charter
Jim:
 
That's fine by me. Just wasn't clear (to me) from your previous bullet.
 
- Bernie
-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Thursday, June 13, 2002 3:22 PM
To: Bernie Volz (EUD); Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] DHC WG charter

Bernie,
 
Let me be more direct.  I want to see routers be able to use lightweight DHCP to support IPv6 information requests, router renumbering, and the like.  The below ext text is good but I am looking for us to extend the architecture of dhcp to support lightweight processes for router or gateways or what is now called edge-servers.  So I think it needs a separate bullet.
 
Let me think and come up with different wording?
 
p.s. Ralph - whats our time frame to discuss the charter?
 
thanks
/jim
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, June 13, 2002 10:03 AM
To: Bound, Jim; Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] DHC WG charter

Jim:

Yes mobility and prefix delegation would be good to consider. I think it
might already be addressed by:
>   - Develop extensions to DHCPv6 for prefix delegation, DNS
>     configuration, etc.

Regarding your addition:
>- Determine the requirements for DHC to support the dynamic renumbering
>of networks using fast path delegaion as CPE front end between ISP and
>Private Networks.

This seems too specific and I'm not exactly sure what it means. Perhaps the
requirement is to determine how DHCP can be used to assist in rapid
renumbering of networks?

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Thursday, June 13, 2002 9:37 AM
To: Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] DHC WG charter


Ralph,

I think we need to add something to the charter for Mobility and Prefix delegation for IPv6.  I think this team and group can do a lot of good and help with evolution of wireless networks and the integration of Mobile.  Specifically:

- Determine the requirements for DHC to support the dynamic renumbering of networks using fast path delegaion as CPE front end between ISP and Private Networks.

What do others think?  I just think we have work to do in this space and not sorted it all out yet.  But do we have to for a charter?

thanks
/jim

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Thursday, June 13, 2002 8:27 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] DHC WG charter
>
>
> The Internet ADs have suggested it is time (likely
> *way* past time) to revisit the DHC WG charter.  Here's a
> first pass at
> what I see as the issues currently in front of the WG.  The
> objectives are
> not presented in any particular order.
>
> Please review and send your comments to the mailing list.  The goal is
> to have consensus on a list of objectives for final review at the WG
> meeting in Yokohama.
>
> - Ralph
>
> =====
>
> The working group has the following primary objectives:
>
> * Develop additional authentication protocols within the framework
>   defined in RFC3118, along with other mechanisms to mitigate the
>   threat of attacks on DHCP clients and servers:
>   - New RFC3118 protocols to address improved key management and
>     improved scalability
>   - Provide security for messages passed between relay agents and
>     servers
>   - Consider solutions for specific threats such as use of nonce
>     identifier to defend against DoS attacks through FORCERENEW from
>     off-path attackers
>
> * Complete the specification of DHCP for IPv6 (DHCPv6):
>   - Gain acceptance and publication of current Internet Draft as
>     Proposed Standard
>   - Develop and publish specifications for options and other
>     extensions to DHCPv6, including those already published as
>     Internet Drafts:
>     + "DNS Configuration Options for DHCPv6"
>     + "Time Configuration Options for DHCPv6"
>     + "NIS Configuration Options for DHCPv6"
>     + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6"
>     + "Load Balancing for DHCPv6"
>   - Encourage independent implementations and conduct interoperability
>     testing
>   - Revise specification and publish for acceptance as Draft Standard
>     by 6/30/2002
>   - Develop extensions to DHCPv6 for prefix delegation, DNS
>     configuration, etc.
>
> * Revise and submit the DHCP specification for acceptance as a Full
>   Standard
>
> * Complete the specification and publish work in progress as
>   standards:
>   - Failover protocol
>   - DHCP/DDNS interaction
>   - SNMP MIB
>   - Host name options
>   - Other client and relay agent options
>
> * Review new options for DHCP, as deemed appropriate by the working
>   group and/or the Internet area directors
>
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C21353.50A8FAA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 14 11:03:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02389; Fri, 14 Jun 2002 11:03:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16720; Fri, 14 Jun 2002 11:02:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16701 for ; Fri, 14 Jun 2002 11:02:02 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02271 for ; Fri, 14 Jun 2002 11:01:23 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5EF0og5141856; Fri, 14 Jun 2002 11:00:52 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5EF0nQ33470; Fri, 14 Jun 2002 09:00:50 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g5EEwlk15942; Fri, 14 Jun 2002 10:58:47 -0400 Message-Id: <200206141458.g5EEwlk15942@rotala.raleigh.ibm.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHC WG charter In-Reply-To: Message from "Thu, 13 Jun 2002 08:27:24 EDT." Date: Fri, 14 Jun 2002 10:58:47 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ralph, Thanks for getting this discussion started. > The working group has the following primary objectives: > * Develop additional authentication protocols within the framework > defined in RFC3118, along with other mechanisms to mitigate the > threat of attacks on DHCP clients and servers: > - New RFC3118 protocols to address improved key management and > improved scalability I think the charter should be more specific here. What new protocols are needed? What problems need to be solved? The above is just a blank check to do unspecified work (not good). > - Provide security for messages passed between relay agents and > servers A good deliverable. > - Consider solutions for specific threats such as use of nonce > identifier to defend against DoS attacks through FORCERENEW from > off-path attackers This might be good, but it seems like a prerequisite is to have a documented threat analysis. What are the primary threats to DHCP? Which ones are the ones that are important to address? Only then does it make sense to think about specfic solutions. > * Complete the specification of DHCP for IPv6 (DHCPv6): > - Gain acceptance and publication of current Internet Draft as > Proposed Standard > - Develop and publish specifications for options and other > extensions to DHCPv6, including those already published as > Internet Drafts: > + "DNS Configuration Options for DHCPv6" > + "Time Configuration Options for DHCPv6" > + "NIS Configuration Options for DHCPv6" > + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6" > + "Load Balancing for DHCPv6" > - Encourage independent implementations and conduct interoperability > testing I don't think this needs to be called out in the charter. WGs don't do interoperability testing per se. But interoperability reports are needed for advancing documents along the standards track. > - Revise specification and publish for acceptance as Draft Standard > by 6/30/2002 > - Develop extensions to DHCPv6 for prefix delegation, DNS > configuration, etc. I'm not sure I agree with this. I think the DHC needs to stick with its core expertise, which is the DHC core protocols, and reviewing options motivated from outside the WG from the perspective of being consistent with standard DHC operating practice. But in terms of actually defining new options, I think that requires significant input AND MOTIVATION from the customers of the option. In the case of Prefix delegation, that seems like a broader problem, where a DHC solution might well be appropriate. But I don't think this should be driven by the DHC WG, since the problem is not inherently a DHC problem. Does the DHC WG really have the expertise to do the prefix delegation work? I wouldn't immediately think so. They do have expertise to review any options once it is determined what the prefix delegation solution requires. So, I think better charter wording would say that the WG will review options whose impetus comes from other WGs. A number of the specific options mentioned above are really motivated by other WGs. > * Revise and submit the DHCP specification for acceptance as a Full > Standard I guess I'm a cynic. If there is no realistic plan for doing this, I'd say leave it out of the charter. The charter should not be a kitchen sink of all possible work items. It should capture the priority items the WG will work on over the next 12 months. One can easily recharter if something interesting pops up that should get attention. > * Complete the specification and publish work in progress as > standards: > - Failover protocol > - DHCP/DDNS interaction > - SNMP MIB What is the MIB item? Do we really need it? > - Host name options > - Other client and relay agent options > * Review new options for DHCP, as deemed appropriate by the working > group and/or the Internet area directors Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 14 18:17:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17653; Fri, 14 Jun 2002 18:17:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11268; Fri, 14 Jun 2002 18:17:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11242 for ; Fri, 14 Jun 2002 18:17:16 -0400 (EDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17617 for ; Fri, 14 Jun 2002 18:16:39 -0400 (EDT) Received: from BarrH63p601 ([64.169.90.244]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GXP0086SV8PDD@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Fri, 14 Jun 2002 15:17:14 -0700 (PDT) Date: Fri, 14 Jun 2002 15:16:57 -0700 From: Richard Barr Hibbs Subject: RE: [dhcwg] DHC WG charter In-reply-to: <200206141458.g5EEwlk15942@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT Thomas, Ralph, Jim, Bernie, et al., > > The working group has the following primary objectives: > > > * Develop additional authentication protocols within the framework > > defined in RFC3118, along with other mechanisms to mitigate the > > threat of attacks on DHCP clients and servers: > > - New RFC3118 protocols to address improved key management and > > improved scalability > > I think the charter should be more specific here. What new protocols > are needed? What problems need to be solved? The above is just a blank > check to do unspecified work (not good). > ...I think the first question to ask is (1) what problems need to be solved? While I agree with Ralph that the result of answering (1) will probably be to identify additional application protocols required within the RFC3118 framework, I believe we need to proceed by conducting a threat analysis, which I would suggest should be our second question: (2) what threats to secure, reliable network configuration are likely or possible to occur? A third question might be (3) how does any security or authentication proposal fit with other work of the IETF? *Snip!* > > - Consider solutions for specific threats such as use of nonce > > identifier to defend against DoS attacks through FORCERENEW from > > off-path attackers > > This might be good, but it seems like a prerequisite is to have a > documented threat analysis. What are the primary threats to DHCP? > Which ones are the ones that are important to address? Only then does > it make sense to think about specfic solutions. > ...agreed, a threat analysis probably should be first > > * Complete the specification of DHCP for IPv6 (DHCPv6): > > - Gain acceptance and publication of current Internet Draft as > > Proposed Standard > > - Develop and publish specifications for options and other > > extensions to DHCPv6, including those already published as > > Internet Drafts: > > + "DNS Configuration Options for DHCPv6" > > + "Time Configuration Options for DHCPv6" > > + "NIS Configuration Options for DHCPv6" > > + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6" > > + "Load Balancing for DHCPv6" > > - Encourage independent implementations and conduct interoperability > > testing > > I don't think this needs to be called out in the charter. WGs don't do > interoperability testing per se. But interoperability reports are > needed for advancing documents along the standards track. > ...I disagree slightly, Thomas, in that I believe it is important for the working groups to encourage multiple implementations and interoperability testing precisely because that is the means to substantiate a call for advancement. > > - Revise specification and publish for acceptance as Draft Standard > > by 6/30/2002 > > > - Develop extensions to DHCPv6 for prefix delegation, DNS > > configuration, etc. > > I'm not sure I agree with this. I think the DHC needs to stick with > its core expertise, which is the DHC core protocols, and reviewing > options motivated from outside the WG from the perspective of being > consistent with standard DHC operating practice. > ...again, answering question (1) should provide the necessary clarification to determine what extensions are needed. *Snip!* > So, I think better charter wording would say that the WG will review > options whose impetus comes from other WGs. A number of the specific > options mentioned above are really motivated by other WGs. > ...agreed > > * Revise and submit the DHCP specification for acceptance as a Full > > Standard > > I guess I'm a cynic. If there is no realistic plan for doing this, I'd > say leave it out of the charter. > ...what would constitute a realistic plan in your view? A full-blown review of all DHCPv4 options for currency and usefulness? Sunsetting or deprecation of unused options, features, and functions? Time limits for generating DHCPv6 extensions? A freeze on new protocol development? My cynicism runs the other way: if it isn't included in the charter, I'm not convinced that either the -v4 or -v6 protocols would ever make it to Full Standard. > The charter should not be a kitchen sink of all possible work > items. It should capture the priority items the WG will work on over > the next 12 months. One can easily recharter if something interesting > pops up that should get attention. > ...agreed > > * Complete the specification and publish work in progress as > > standards: > > - Failover protocol > > - DHCP/DDNS interaction > > - SNMP MIB > > What is the MIB item? Do we really need it? > ...every time (at least 3 times) I asked the attendees at a WG meeting if this work should continue towards adoption, the voice vote was affirmative. I still get occasional mail from people who have begun implementation and have questions or request clarifications -- that was the source of updates to the last revision of the I-D. On the other hand, the DNS extensions working group just dropped the idea of ever defining a standard server or resolver MIB as unwanted, even though I know of 5 different vendors who provide a DNS server MIB. I also am aware of at least 3 private DHCP server MIBs, so somebody out there wants it! However, if we can't get this to working group last call before the December meeting, I intend to withdraw the draft from the I-D editor. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 14 18:25:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18017; Fri, 14 Jun 2002 18:25:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11634; Fri, 14 Jun 2002 18:25:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11609 for ; Fri, 14 Jun 2002 18:25:36 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18006 for ; Fri, 14 Jun 2002 18:24:58 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g5EMN3S27590; Fri, 14 Jun 2002 15:23:03 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g5EMPSgF000545; Fri, 14 Jun 2002 17:25:28 -0500 (CDT) Date: Fri, 14 Jun 2002 17:25:28 -0500 Subject: Re: [dhcwg] DHC WG charter Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: dhcwg@ietf.org To: rbhibbs@pacbell.net From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > ...I disagree slightly, Thomas, in that I believe it is important for the > working groups to encourage multiple implementations and interoperability > testing precisely because that is the means to substantiate a call for > advancement. If it is necessary for the wg to encourage multiple interoperable implementations and interoperability testing, then perhaps that's a signal that the protocol spec isn't ready to advance. My experience is that if people want the protocol, they will implement it and do interoperability testing with no outside encouragement. "They" is often members of the wg, but that doesn't mean it needs to be official wg business. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 14 20:28:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19974; Fri, 14 Jun 2002 20:28:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16698; Fri, 14 Jun 2002 20:27:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16667 for ; Fri, 14 Jun 2002 20:27:52 -0400 (EDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19939 for ; Fri, 14 Jun 2002 20:27:13 -0400 (EDT) Received: from BarrH63p601 ([64.169.90.244]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GXQ005B41AC9T@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Fri, 14 Jun 2002 17:27:49 -0700 (PDT) Date: Fri, 14 Jun 2002 17:27:32 -0700 From: Richard Barr Hibbs Subject: RE: [dhcwg] DHC WG charter In-reply-to: To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > If it is necessary for the wg to encourage multiple interoperable > implementations and interoperability testing, then perhaps that's > a signal that the protocol spec isn't ready to advance. My > experience is that if people want the protocol, they will implement > it and do interoperability testing with no outside encouragement. > ...now my biases are showing.... after my experience with "stealth" implementations of private MIBs for DHCP and DNS servers, I'm not so sure that a bit of encouragement isn't needed.... although I agree that if a protocol spec is thought to be useful, implementations and interoperability testing will occur. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 14 23:58:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23648; Fri, 14 Jun 2002 23:58:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23493; Fri, 14 Jun 2002 23:58:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23467 for ; Fri, 14 Jun 2002 23:58:42 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23641 for ; Fri, 14 Jun 2002 23:58:03 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g5F3uCS28187; Fri, 14 Jun 2002 20:56:12 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g5F3wcgF001276; Fri, 14 Jun 2002 22:58:38 -0500 (CDT) Date: Fri, 14 Jun 2002 22:58:38 -0500 Subject: Re: [dhcwg] DHC WG charter Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: dhcwg@ietf.org To: rbhibbs@pacbell.net From: Ted Lemon In-Reply-To: Message-Id: <2C054C5A-8014-11D6-9A23-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > ...now my biases are showing.... after my experience with "stealth" > implementations of private MIBs for DHCP and DNS servers, I'm not so sure > that a bit of encouragement isn't needed.... although I agree that if a > protocol spec is thought to be useful, implementations and interoperability > testing will occur. If the stealth implementations make their customers happy, where's the problem? Many a fine protocol has emerged out of a stealth implementation. People seem to be willing to implement good standards, so if you see a lot of stealth implementations, it's probably because nobody proposed a standard, or nobody could agree on one. In a situation like this, experimentation is good (as long as the experimenters don't patent their solution, anyway...) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jun 15 09:46:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07833; Sat, 15 Jun 2002 09:46:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18899; Sat, 15 Jun 2002 09:44:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18874 for ; Sat, 15 Jun 2002 09:44:32 -0400 (EDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07805 for ; Sat, 15 Jun 2002 09:43:55 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel11.hp.com (Postfix) with ESMTP id 70D67600836 for ; Sat, 15 Jun 2002 06:44:00 -0700 (PDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by dce.india.hp.com with SMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id TAA22063 for ; Sat, 15 Jun 2002 19:19:21 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: Date: Sat, 15 Jun 2002 19:15:40 +0530 Message-ID: <000601c21472$f0e79010$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [dhcwg] Message fragmentation in DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit "The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation." Do we need to define some maximum DHCP message size here? "The client has to include ALL the IAs in the reply to Reconfigure message." Then, for this case, what should the client do, in the case if it finds that there will be fragmentation. The situation is worse, in the case, client is able to send all the IAs, but the server is not able to reply with ALL IAs. How will the server send the remaining options/IAs to the client? ~Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jun 15 10:04:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08152; Sat, 15 Jun 2002 10:04:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19755; Sat, 15 Jun 2002 10:04:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19732 for ; Sat, 15 Jun 2002 10:04:29 -0400 (EDT) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08147 for ; Sat, 15 Jun 2002 10:03:52 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel7.hp.com (Postfix) with ESMTP id 5C9168055A2 for ; Sat, 15 Jun 2002 10:03:57 -0400 (EDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by dce.india.hp.com with SMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id TAA22089 for ; Sat, 15 Jun 2002 19:39:15 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: Date: Sat, 15 Jun 2002 19:35:34 +0530 Message-ID: <000701c21475$b8875040$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [dhcwg] Temporary addresses Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit We dont have T1 and T2 values for IA having temporary addreses but the draft says that the temporary addresses can be renewed. So, if the client wishes to renew the adddresses, when should the client renew the addresses? Does it mean that the application has to trigger the renew in the case, if it need to use the address for some more time? RFC 3041 says the mechanism of generating random Interface IDs, for subsequent addresses for the same interface of the node. Does the DHCP server need to implement this mechanism for allocating temporary addresses to the client? Probabably, we can add some text to state that once a temporary address is released or lifetime expires, the server should forget the bindings, unlike the normal addresses. This will be helpful in allocating different addresses for the subsequent request from the same node. Vijayabhaskar A K Hewlett Packard ESDI 91-80-2051424,9624-371137 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jun 15 13:06:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12159; Sat, 15 Jun 2002 13:06:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26848; Sat, 15 Jun 2002 13:02:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26823 for ; Sat, 15 Jun 2002 13:02:30 -0400 (EDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12020 for ; Sat, 15 Jun 2002 13:01:54 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel11.hp.com (Postfix) with ESMTP id 85D47600827 for ; Sat, 15 Jun 2002 10:01:56 -0700 (PDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by dce.india.hp.com with SMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id WAA22321 for ; Sat, 15 Jun 2002 22:37:17 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: Date: Sat, 15 Jun 2002 22:33:36 +0530 Message-ID: <000d01c2148e$971d5a30$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [dhcwg] NotOnlink status for confirm messages Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit NoAddrsAvail NoBinding NotOnLink UnspecFail Solicit Ignore NA NA NA Advertise Request Choose NA Solicit NA next server Confirm NA NA Solicit NA Renew NA Request NA NA Rebind NA Request NA NA Release NA NA NA NA Decline NA NA NA NA Inform-req NA NA NA Choose next server The above is the state diagram for the client. (Renew, NotOnlink) and (Rebind, NotOnlink) is NA here, because, the server will make lifetimes as 0, in the case the addresses are not in the link. But (Confirm, NotOnlink) is a applicable. If the server finds that one or more prefixes are not appropriate, then it will send NotOnlink status. I think, for the confirm also, server can do operation similar to (Renew, NotOnlink) but with little bit change. If one or more addresses are not appropriate to the link, it can return those addresses ONLY with status NotOnLink, else it canreturn SUCCESS. Thus the client can continue using the addressses which are appropriate to the link. This will avoid client sending SOLICIT unnecessarily. ~ Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jun 15 13:30:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12593; Sat, 15 Jun 2002 13:30:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27318; Sat, 15 Jun 2002 13:29:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27293 for ; Sat, 15 Jun 2002 13:29:48 -0400 (EDT) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12565 for ; Sat, 15 Jun 2002 13:29:12 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel6.hp.com (Postfix) with ESMTP id B70162EF for ; Sat, 15 Jun 2002 13:29:16 -0400 (EDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by dce.india.hp.com with SMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id XAA22468 for ; Sat, 15 Jun 2002 23:04:37 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: Date: Sat, 15 Jun 2002 23:00:56 +0530 Message-ID: <000e01c21492$6882ab90$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [dhcwg] Order of occurence of DHCPv6 options Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I think, we need to fix the order of options occuring in DHCPv6 messages for better processing of the messages. 1. Elapsed Time option - Since based on this value only, the relay/server is going to decide the policy of reply. 2. Status Code - In the case of Failure, this message can be directly ignored 3. Authentication option - If authentication fails, nothing is needed to be processed. 4. server-id - If the server id doesn't match, server can ignore it. 5. client-id - If the client id doesn't match, client can ignore it. 6. Rapid commit - Based on this, the server can determine whether it need to send Advertise or Reply. If any of these options are occuring, then they MUST occur in this order. ---------------------------------------------------------------------------- -- ConfNoMatch and AddrUnavail are nowhere used. It can be removed. AuthFailed is also nowhere used. We need to add text saying if the server/client is not able to authenticate the other, then they should send reply with error code AuthFailed set. ---------------------------------------------------------------------------- -- R-forw. * * * * * R-repl. * * * * * Why Authentication, User class, Vendor class, Vendor specific options are needed in Relay-fwd and Relay-reply message. ~Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jun 15 13:36:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12708; Sat, 15 Jun 2002 13:36:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27989; Sat, 15 Jun 2002 13:36:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27965 for ; Sat, 15 Jun 2002 13:36:04 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12679 for ; Sat, 15 Jun 2002 13:35:28 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g5FHa3l02411 for ; Sat, 15 Jun 2002 12:36:03 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g5FHa3917666 for ; Sat, 15 Jun 2002 12:36:03 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sat Jun 15 12:36:02 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 15 Jun 2002 12:35:10 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D5D6@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , dhcwg@ietf.org Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Date: Sat, 15 Jun 2002 12:36:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21493.1DBBF340" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21493.1DBBF340 Content-Type: text/plain; charset="iso-8859-1" Vijay: On the order of options, we chose specifically NOT to specify this. There really is no requirement or overwhelming reason to do this. Putting some options earlier than others improves performance in some situations so it will be wise for clients (and servers) to do this, but it is difficult to specify this and a client and server MUST assume the worst anyway. For example, I'd argue that putting the Server Identifier option first (or very early) is best since it allows all servers that receive this (except for the intended one) to drop the packet almost immediately. Rather than having to look through 4 options, won't it be better if these servers only had to look at 1 option (the first). Though, having said that there is no reason to require this and depending on how a client or server processes packets, the above might not even apply (for example, if a client or server always decodes all options to validate the packet, it won't save anything). So, we specifically decided not to specify option ordering and I think that is a wise decision. Regarding the other issues, some clean-up for the draft will be required to remove and fix items based on the final status codes/option usage. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Saturday, June 15, 2002 1:31 PM To: dhcwg@ietf.org Subject: [dhcwg] Order of occurence of DHCPv6 options I think, we need to fix the order of options occuring in DHCPv6 messages for better processing of the messages. 1. Elapsed Time option - Since based on this value only, the relay/server is going to decide the policy of reply. 2. Status Code - In the case of Failure, this message can be directly ignored 3. Authentication option - If authentication fails, nothing is needed to be processed. 4. server-id - If the server id doesn't match, server can ignore it. 5. client-id - If the client id doesn't match, client can ignore it. 6. Rapid commit - Based on this, the server can determine whether it need to send Advertise or Reply. If any of these options are occuring, then they MUST occur in this order. ---------------------------------------------------------------------------- -- ConfNoMatch and AddrUnavail are nowhere used. It can be removed. AuthFailed is also nowhere used. We need to add text saying if the server/client is not able to authenticate the other, then they should send reply with error code AuthFailed set. ---------------------------------------------------------------------------- -- R-forw. * * * * * R-repl. * * * * * Why Authentication, User class, Vendor class, Vendor specific options are needed in Relay-fwd and Relay-reply message. ~Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C21493.1DBBF340 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Order of occurence of DHCPv6 options

Vijay:

On the order of options, we chose specifically NOT to specify this. There really is no
requirement or overwhelming reason to do this. Putting some options earlier than others
improves performance in some situations so it will be wise for clients (and servers) to
do this, but it is difficult to specify this and a client and server MUST assume the
worst anyway.

For example, I'd argue that putting the Server Identifier option first (or very early)
is best since it allows all servers that receive this (except for the intended one) to
drop the packet almost immediately. Rather than having to look through 4 options, won't
it be better if these servers only had to look at 1 option (the first).

Though, having said that there is no reason to require this and depending on how a client
or server processes packets, the above might not even apply (for example, if a client or
server always decodes all options to validate the packet, it won't save anything).

So, we specifically decided not to specify option ordering and I think that is a wise
decision.


Regarding the other issues, some clean-up for the draft will be required to remove and
fix items based on the final status codes/option usage.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Saturday, June 15, 2002 1:31 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Order of occurence of DHCPv6 options


I think, we need to fix the order of options occuring in DHCPv6 messages
for better processing of the messages.

1. Elapsed Time option - Since based on this value only, the relay/server is
going to decide the policy of reply.

2. Status Code - In the case of Failure, this message can be directly
ignored

3. Authentication option - If authentication fails, nothing is needed to
be processed.

4. server-id - If the server id doesn't match, server can ignore it.

5. client-id - If the client id doesn't match, client can ignore it.

6. Rapid commit - Based on this, the server can determine whether it need
to send Advertise or Reply.


If any of these options are occuring, then they MUST occur in this order.

----------------------------------------------------------------------------
--

ConfNoMatch and AddrUnavail are nowhere used. It can be removed.

AuthFailed is also nowhere used. We need to add text saying if the
server/client is not able to authenticate the other, then they
should send reply with error code AuthFailed set.

----------------------------------------------------------------------------
--
R-forw.    *                        *     *      *      *
R-repl.    *                        *     *      *      *

Why Authentication, User class, Vendor class, Vendor specific options
are needed in Relay-fwd and Relay-reply message.

~Vijay


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C21493.1DBBF340-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jun 15 13:43:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12814; Sat, 15 Jun 2002 13:43:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28190; Sat, 15 Jun 2002 13:41:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28165 for ; Sat, 15 Jun 2002 13:41:46 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12798 for ; Sat, 15 Jun 2002 13:41:09 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g5FHfjl02984 for ; Sat, 15 Jun 2002 12:41:45 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g5FHfj918108 for ; Sat, 15 Jun 2002 12:41:45 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sat Jun 15 12:41:44 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 15 Jun 2002 12:41:10 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D5D7@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , dhcwg@ietf.org Subject: RE: [dhcwg] Temporary addresses Date: Sat, 15 Jun 2002 12:41:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21493.E9B8DDF0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21493.E9B8DDF0 Content-Type: text/plain; charset="iso-8859-1" Vijay: Correct - we don't have T1/T2 times for IA_TA. It is the clients choice as to when (and if) to renew these. I would think it would following a policy similar to that specified in RFC 3041 (to extend the preferred and/or valid lifetime). Essentially, the client should start the renewal process early enough to continue using the address. I don't think the DHCP server needs to follow the procedures of RFC 3041 in generating temporary addresses. The DHCP server may not even have the client's link-local address (interface identifier). >Probabably, we can add some text to state that once a temporary >address is released or lifetime expires, the server should >forget the bindings, unlike the normal addresses. For temporary addresses, there is good reason for the server to forget them as ever being associated with a client after the valid lifetime expires (or it is released). However, this may also be the case for normal addresses. For normal addresses, this is really a server policy issue and up to the server (or administrator of the server if configuration of this is allowed). - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Saturday, June 15, 2002 10:06 AM To: dhcwg@ietf.org Subject: [dhcwg] Temporary addresses We dont have T1 and T2 values for IA having temporary addreses but the draft says that the temporary addresses can be renewed. So, if the client wishes to renew the adddresses, when should the client renew the addresses? Does it mean that the application has to trigger the renew in the case, if it need to use the address for some more time? RFC 3041 says the mechanism of generating random Interface IDs, for subsequent addresses for the same interface of the node. Does the DHCP server need to implement this mechanism for allocating temporary addresses to the client? Probabably, we can add some text to state that once a temporary address is released or lifetime expires, the server should forget the bindings, unlike the normal addresses. This will be helpful in allocating different addresses for the subsequent request from the same node. Vijayabhaskar A K Hewlett Packard ESDI 91-80-2051424,9624-371137 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C21493.E9B8DDF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Temporary addresses

Vijay:

Correct - we don't have T1/T2 times for IA_TA. It is = the clients choice as to when (and
if) to renew these. I would think it would following = a policy similar to that specified
in RFC 3041 (to extend the preferred and/or valid = lifetime). Essentially, the client
should start the renewal process early enough to = continue using the address.

I don't think the DHCP server needs to follow the = procedures of RFC 3041 in generating
temporary addresses. The DHCP server may not even = have the client's link-local address
(interface identifier).

>Probabably, we can add some text to state that = once a temporary
>address is released or lifetime expires, the = server should
>forget the bindings, unlike the normal = addresses.

For temporary addresses, there is good reason for the = server to forget them as ever
being associated with a client after the valid = lifetime expires (or it is released).
However, this may also be the case for normal = addresses. For normal addresses, this
is really a server policy issue and up to the server = (or administrator of the server
if configuration of this is allowed).

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Saturday, June 15, 2002 10:06 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Temporary addresses


We dont have T1 and T2 values for IA having temporary = addreses
but the draft says that the temporary addresses can = be renewed.
So, if the client wishes to renew the adddresses, =
when should the client renew the addresses?
Does it mean that the application has to trigger the = renew
in the case, if it need to use the address for some = more time?

RFC 3041 says the mechanism of generating random = Interface IDs,
for subsequent addresses for the same interface of = the node.
Does the DHCP server need to implement this = mechanism for
allocating temporary addresses to the client?

Probabably, we can add some text to state that once a = temporary
address is released or lifetime expires, the server = should
forget the bindings, unlike the normal = addresses.
This will be helpful in allocating different = addresses for the
subsequent request from the same node.

Vijayabhaskar A K
Hewlett Packard ESDI
91-80-2051424,9624-371137



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C21493.E9B8DDF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jun 15 13:46:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12874; Sat, 15 Jun 2002 13:46:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28354; Sat, 15 Jun 2002 13:46:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28329 for ; Sat, 15 Jun 2002 13:46:27 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12869 for ; Sat, 15 Jun 2002 13:45:51 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g5FHjui26529 for ; Sat, 15 Jun 2002 12:45:57 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g5FHju918539 for ; Sat, 15 Jun 2002 12:45:56 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sat Jun 15 12:45:55 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 15 Jun 2002 12:45:03 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D5D8@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , dhcwg@ietf.org Subject: RE: [dhcwg] Message fragmentation in DHCPv6 Date: Sat, 15 Jun 2002 12:45:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21494.7F461590" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21494.7F461590 Content-Type: text/plain; charset="iso-8859-1" Vijay: Fragmentation is always possible - it just should be avoided. In most cases this really only applies to boot proms that may have a limited IP implementation and therefore not have sufficient resources for handling reassembly? The MTU size is really dependent on the link and therefore isn't required to be specified (recall that Path MTU Discovery is required in IPv6). But, the general IPv6 MTU (of if I recall 1280 octets) is probably a reasonable default and gives us much more space than is in general available in DHCPv4. Anyway, the point is that if a large message must be sent, send it. However, if that large message results because unrequested options might be added, don't bother adding those options. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Saturday, June 15, 2002 9:46 AM To: dhcwg@ietf.org Subject: [dhcwg] Message fragmentation in DHCPv6 "The server SHOULD limit the options returned to the client so that the DHCP message header and options do not cause fragmentation." Do we need to define some maximum DHCP message size here? "The client has to include ALL the IAs in the reply to Reconfigure message." Then, for this case, what should the client do, in the case if it finds that there will be fragmentation. The situation is worse, in the case, client is able to send all the IAs, but the server is not able to reply with ALL IAs. How will the server send the remaining options/IAs to the client? ~Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C21494.7F461590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Message fragmentation in DHCPv6

Vijay:

Fragmentation is always possible - it just should be = avoided. In most cases this
really only applies to boot proms that may have a = limited IP implementation and
therefore not have sufficient resources for handling = reassembly?

The MTU size is really dependent on the link and = therefore isn't required to be
specified (recall that Path MTU Discovery is = required in IPv6).

But, the general IPv6 MTU (of if I recall 1280 = octets) is probably a reasonable
default and gives us much more space than is in = general available in DHCPv4.

Anyway, the point is that if a large message must be = sent, send it. However, if
that large message results because unrequested = options might be added, don't bother
adding those options.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Saturday, June 15, 2002 9:46 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Message fragmentation in = DHCPv6



"The server SHOULD limit the options returned to = the client so that the DHCP
message header and options do not cause = fragmentation."

Do we need to define some maximum DHCP message size = here?

"The client has to include ALL the IAs in the = reply to Reconfigure message."

Then, for this case, what should the client do, in = the case if it finds that
there
will be fragmentation. The situation is worse, in = the case, client is able
to send all the IAs, but the server is not able to = reply with ALL IAs.
How will the server send the remaining options/IAs = to the client?

~Vijay


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C21494.7F461590-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 17 06:19:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25384; Mon, 17 Jun 2002 06:19:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04058; Mon, 17 Jun 2002 06:17:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04032 for ; Mon, 17 Jun 2002 06:17:50 -0400 (EDT) Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25369 for ; Mon, 17 Jun 2002 06:17:11 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel8.hp.com (Postfix) with ESMTP id 6135FA00B05; Mon, 17 Jun 2002 06:17:13 -0400 (EDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by dce.india.hp.com with SMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id PAA26021; Mon, 17 Jun 2002 15:52:28 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Date: Mon, 17 Jun 2002 15:49:18 +0530 Message-ID: <001901c215e8$70958bc0$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D5D6@EAMBUNT705> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi Bernie, The requirement here is PERFORMANCE. Assume there are 1000 requests passing through a server which are NOT intended to be handled by this server. This will happen since most of the messages are Multicast only. This is not the corner case situation as you said, this will happen in most of the cases. There is nothing wrong in mandating this. This is something like specifying these options in a fixed mesg header. The server/client will ignore the remaining option field, if there is any error in the mesg header. All of the above, the relay should be lightweight, if the admin has configured the relay to load balance based on Elapsed time option and how bad the performance will be if the relay has to search for this option by parsing the whole message. > the above might not even apply (for example, if a client or > server always decodes all options to validate the packet, > it won't save anything). Then, this is a poor implementation. If the first option itself is erraneous, (for ex. auth itself fails), then there is no need to parse remaining stuff. We should leave these kind of implementation as corner case and go on mandating options' order of occurence. ~ Vijay -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Saturday, June 15, 2002 11:06 PM To: 'vijayak@india.hp.com'; dhcwg@ietf.org Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Vijay: On the order of options, we chose specifically NOT to specify this. There really is no requirement or overwhelming reason to do this. Putting some options earlier than others improves performance in some situations so it will be wise for clients (and servers) to do this, but it is difficult to specify this and a client and server MUST assume the worst anyway. For example, I'd argue that putting the Server Identifier option first (or very early) is best since it allows all servers that receive this (except for the intended one) to drop the packet almost immediately. Rather than having to look through 4 options, won't it be better if these servers only had to look at 1 option (the first). Though, having said that there is no reason to require this and depending on how a client or server processes packets, the above might not even apply (for example, if a client or server always decodes all options to validate the packet, it won't save anything). So, we specifically decided not to specify option ordering and I think that is a wise decision. Regarding the other issues, some clean-up for the draft will be required to remove and fix items based on the final status codes/option usage. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Saturday, June 15, 2002 1:31 PM To: dhcwg@ietf.org Subject: [dhcwg] Order of occurence of DHCPv6 options I think, we need to fix the order of options occuring in DHCPv6 messages for better processing of the messages. 1. Elapsed Time option - Since based on this value only, the relay/server is going to decide the policy of reply. 2. Status Code - In the case of Failure, this message can be directly ignored 3. Authentication option - If authentication fails, nothing is needed to be processed. 4. server-id - If the server id doesn't match, server can ignore it. 5. client-id - If the client id doesn't match, client can ignore it. 6. Rapid commit - Based on this, the server can determine whether it need to send Advertise or Reply. If any of these options are occuring, then they MUST occur in this order. ---------------------------------------------------------------------------- -- ConfNoMatch and AddrUnavail are nowhere used. It can be removed. AuthFailed is also nowhere used. We need to add text saying if the server/client is not able to authenticate the other, then they should send reply with error code AuthFailed set. ---------------------------------------------------------------------------- -- R-forw. * * * * * R-repl. * * * * * Why Authentication, User class, Vendor class, Vendor specific options are needed in Relay-fwd and Relay-reply message. ~Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 17 09:04:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00085; Mon, 17 Jun 2002 09:04:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12847; Mon, 17 Jun 2002 09:03:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12828 for ; Mon, 17 Jun 2002 09:03:10 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29974 for ; Mon, 17 Jun 2002 09:02:27 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-253.cisco.com [161.44.149.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA17980; Mon, 17 Jun 2002 08:58:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20020617085042.00b90520@mail.prospeed.net> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jun 2002 08:58:47 -0400 To: From: Ralph Droms Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Cc: "'Bernie Volz (EUD)'" , In-Reply-To: <001901c215e8$70958bc0$2f290a0f@india.hp.com> References: <66F66129A77AD411B76200508B65AC69B4D5D6@EAMBUNT705> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Unitl we have more experience with real implementations, it's hard to know exactly what to optimize. So, let's run some experiments once we have interopable implementations and get some experience with real deployments so we can understand where the performance hits and improvement opportunities are. Then we can write up that experience and a specification for option ordering... - Ralph At 03:49 PM 6/17/2002 +0530, Vijayabhaskar A K wrote: >Hi Bernie, > >The requirement here is PERFORMANCE. Assume there are 1000 requests passing >through a server which are NOT intended to be handled by this server. This >will happen since most of the messages are Multicast only. This is not the >corner case situation as you said, this will happen in most of the cases. >There is nothing wrong in mandating this. This is something like specifying >these options in a fixed mesg header. The server/client will ignore the >remaining >option field, if there is any error in the mesg header. > >All of the above, the relay should be lightweight, if the admin has >configured >the relay to load balance based on Elapsed time option and how bad the >performance will be if the relay has to search for this option by parsing >the whole message. > > > the above might not even apply (for example, if a client or > > server always decodes all options to validate the packet, > > it won't save anything). > >Then, this is a poor implementation. If the first option itself is >erraneous, (for ex. auth itself fails), then there is no need to >parse remaining stuff. We should leave these kind of implementation >as corner case and go on mandating options' order of occurence. > >~ Vijay > >-----Original Message----- >From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] >Sent: Saturday, June 15, 2002 11:06 PM >To: 'vijayak@india.hp.com'; dhcwg@ietf.org >Subject: RE: [dhcwg] Order of occurence of DHCPv6 options > > >Vijay: >On the order of options, we chose specifically NOT to specify this. There >really is no >requirement or overwhelming reason to do this. Putting some options earlier >than others >improves performance in some situations so it will be wise for clients (and >servers) to >do this, but it is difficult to specify this and a client and server MUST >assume the >worst anyway. >For example, I'd argue that putting the Server Identifier option first (or >very early) >is best since it allows all servers that receive this (except for the >intended one) to >drop the packet almost immediately. Rather than having to look through 4 >options, won't >it be better if these servers only had to look at 1 option (the first). >Though, having said that there is no reason to require this and depending on >how a client >or server processes packets, the above might not even apply (for example, if >a client or >server always decodes all options to validate the packet, it won't save >anything). >So, we specifically decided not to specify option ordering and I think that >is a wise >decision. > > >Regarding the other issues, some clean-up for the draft will be required to >remove and >fix items based on the final status codes/option usage. >- Bernie >-----Original Message----- >From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] >Sent: Saturday, June 15, 2002 1:31 PM >To: dhcwg@ietf.org >Subject: [dhcwg] Order of occurence of DHCPv6 options > > >I think, we need to fix the order of options occuring in DHCPv6 messages >for better processing of the messages. >1. Elapsed Time option - Since based on this value only, the relay/server is >going to decide the policy of reply. >2. Status Code - In the case of Failure, this message can be directly >ignored >3. Authentication option - If authentication fails, nothing is needed to >be processed. >4. server-id - If the server id doesn't match, server can ignore it. >5. client-id - If the client id doesn't match, client can ignore it. >6. Rapid commit - Based on this, the server can determine whether it need >to send Advertise or Reply. > > >If any of these options are occuring, then they MUST occur in this order. >---------------------------------------------------------------------------- >-- >ConfNoMatch and AddrUnavail are nowhere used. It can be removed. >AuthFailed is also nowhere used. We need to add text saying if the >server/client is not able to authenticate the other, then they >should send reply with error code AuthFailed set. >---------------------------------------------------------------------------- >-- >R-forw. * * * * * >R-repl. * * * * * >Why Authentication, User class, Vendor class, Vendor specific options >are needed in Relay-fwd and Relay-reply message. >~Vijay > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 17 09:04:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00109; Mon, 17 Jun 2002 09:04:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12929; Mon, 17 Jun 2002 09:03:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12903 for ; Mon, 17 Jun 2002 09:03:50 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29989 for ; Mon, 17 Jun 2002 09:03:12 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g5HD3nl22926 for ; Mon, 17 Jun 2002 08:03:49 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g5HD3nn14300 for ; Mon, 17 Jun 2002 08:03:49 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Jun 17 08:03:48 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 17 Jun 2002 08:02:54 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D5DE@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , dhcwg@ietf.org Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Date: Mon, 17 Jun 2002 08:03:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C215FF.6A7CE910" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C215FF.6A7CE910 Content-Type: text/plain; charset="iso-8859-1" Vijay: The problem is how to mandate this in a reasonable way. We never know what future options will be defined and even you and I don't agree on the order of the options. And, servers and clients MUST NOT depend on this order (since new "more important" options might be defined in the future). So, I think if anything we could give a general recommendation as to WHY certain options should be added earlier in a message. But that's as far as we can go, IMHO. BTW, if you follow the rules for building the messages as documented, the server identifier and client identifier do appear early in the messages. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Monday, June 17, 2002 6:19 AM To: 'Bernie Volz (EUD)'; dhcwg@ietf.org Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Hi Bernie, The requirement here is PERFORMANCE. Assume there are 1000 requests passing through a server which are NOT intended to be handled by this server. This will happen since most of the messages are Multicast only. This is not the corner case situation as you said, this will happen in most of the cases. There is nothing wrong in mandating this. This is something like specifying these options in a fixed mesg header. The server/client will ignore the remaining option field, if there is any error in the mesg header. All of the above, the relay should be lightweight, if the admin has configured the relay to load balance based on Elapsed time option and how bad the performance will be if the relay has to search for this option by parsing the whole message. > the above might not even apply (for example, if a client or > server always decodes all options to validate the packet, > it won't save anything). Then, this is a poor implementation. If the first option itself is erraneous, (for ex. auth itself fails), then there is no need to parse remaining stuff. We should leave these kind of implementation as corner case and go on mandating options' order of occurence. ~ Vijay -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Saturday, June 15, 2002 11:06 PM To: 'vijayak@india.hp.com'; dhcwg@ietf.org Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Vijay: On the order of options, we chose specifically NOT to specify this. There really is no requirement or overwhelming reason to do this. Putting some options earlier than others improves performance in some situations so it will be wise for clients (and servers) to do this, but it is difficult to specify this and a client and server MUST assume the worst anyway. For example, I'd argue that putting the Server Identifier option first (or very early) is best since it allows all servers that receive this (except for the intended one) to drop the packet almost immediately. Rather than having to look through 4 options, won't it be better if these servers only had to look at 1 option (the first). Though, having said that there is no reason to require this and depending on how a client or server processes packets, the above might not even apply (for example, if a client or server always decodes all options to validate the packet, it won't save anything). So, we specifically decided not to specify option ordering and I think that is a wise decision. Regarding the other issues, some clean-up for the draft will be required to remove and fix items based on the final status codes/option usage. - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Saturday, June 15, 2002 1:31 PM To: dhcwg@ietf.org Subject: [dhcwg] Order of occurence of DHCPv6 options I think, we need to fix the order of options occuring in DHCPv6 messages for better processing of the messages. 1. Elapsed Time option - Since based on this value only, the relay/server is going to decide the policy of reply. 2. Status Code - In the case of Failure, this message can be directly ignored 3. Authentication option - If authentication fails, nothing is needed to be processed. 4. server-id - If the server id doesn't match, server can ignore it. 5. client-id - If the client id doesn't match, client can ignore it. 6. Rapid commit - Based on this, the server can determine whether it need to send Advertise or Reply. If any of these options are occuring, then they MUST occur in this order. ---------------------------------------------------------------------------- -- ConfNoMatch and AddrUnavail are nowhere used. It can be removed. AuthFailed is also nowhere used. We need to add text saying if the server/client is not able to authenticate the other, then they should send reply with error code AuthFailed set. ---------------------------------------------------------------------------- -- R-forw. * * * * * R-repl. * * * * * Why Authentication, User class, Vendor class, Vendor specific options are needed in Relay-fwd and Relay-reply message. ~Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C215FF.6A7CE910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Order of occurence of DHCPv6 options

Vijay:

The problem is how to mandate this in a reasonable = way. We never know what future options will be defined and even you and = I don't agree on the order of the options. And, servers and clients = MUST NOT depend on this order (since new "more important" = options might be defined in the future).

So, I think if anything we could give a general = recommendation as to WHY certain options should be added earlier in a = message. But that's as far as we can go, IMHO.

BTW, if you follow the rules for building the = messages as documented, the server identifier and client identifier do = appear early in the messages.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Monday, June 17, 2002 6:19 AM
To: 'Bernie Volz (EUD)'; dhcwg@ietf.org
Subject: RE: [dhcwg] Order of occurence of DHCPv6 = options


Hi Bernie,

The requirement here is PERFORMANCE. Assume there are = 1000 requests passing
through a server which are NOT intended to be = handled by this server. This
will happen since most of the messages are Multicast = only. This is not the
corner case situation as you said, this will happen = in most of the cases.
There is nothing wrong in mandating this. This is = something like specifying
these options in a fixed mesg header. The = server/client will ignore the
remaining
option field, if there is any error in the mesg = header.

All of the above, the relay should be lightweight, if = the admin has
configured
the relay to load balance based on Elapsed time = option and how bad the
performance will be if the relay has to search for = this option by parsing
the whole message.

> the above might not even apply (for example, if = a client or
> server always decodes all options to validate = the packet,
> it won't save anything).

Then, this is a poor implementation. If the first = option itself is
erraneous, (for ex. auth itself fails), then there = is no need to
parse remaining stuff. We should leave these kind of = implementation
as corner case and go on mandating options' order of = occurence.

~ Vijay

-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.erics= son.se]
Sent: Saturday, June 15, 2002 11:06 PM
To: 'vijayak@india.hp.com'; dhcwg@ietf.org
Subject: RE: [dhcwg] Order of occurence of DHCPv6 = options


Vijay:
On the order of options, we chose specifically NOT = to specify this. There
really is no
requirement or overwhelming reason to do this. = Putting some options earlier
than others
improves performance in some situations so it will = be wise for clients (and
servers) to
do this, but it is difficult to specify this and a = client and server MUST
assume the
worst anyway.
For example, I'd argue that putting the Server = Identifier option first (or
very early)
is best since it allows all servers that receive = this (except for the
intended one) to
drop the packet almost immediately. Rather than = having to look through 4
options, won't
it be better if these servers only had to look at 1 = option (the first).
Though, having said that there is no reason to = require this and depending on
how a client
or server processes packets, the above might not = even apply (for example, if
a client or
server always decodes all options to validate the = packet, it won't save
anything).
So, we specifically decided not to specify option = ordering and I think that
is a wise
decision.


Regarding the other issues, some clean-up for the = draft will be required to
remove and
fix items based on the final status codes/option = usage.
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Saturday, June 15, 2002 1:31 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Order of occurence of DHCPv6 = options


I think, we need to fix the order of options occuring = in DHCPv6 messages
for better processing of the messages.
1. Elapsed Time option - Since based on this value = only, the relay/server is
going to decide the policy of reply.
2. Status Code - In the case of Failure, this = message can be directly
ignored
3. Authentication option - If authentication fails, = nothing is needed to
be processed.
4. server-id - If the server id doesn't match, = server can ignore it.
5. client-id - If the client id doesn't match, = client can ignore it.
6. Rapid commit - Based on this, the server can = determine whether it need
to send Advertise or Reply.


If any of these options are occuring, then they MUST = occur in this order.
---------------------------------------------------------------= -------------
--
ConfNoMatch and AddrUnavail are nowhere used. It can = be removed.
AuthFailed is also nowhere used. We need to add text = saying if the
server/client is not able to authenticate the other, = then they
should send reply with error code AuthFailed = set.
---------------------------------------------------------------= -------------
--
R-forw.    = *            = ;            = *     *      = *      *
R-repl.    = *            = ;            = *     *      = *      *
Why Authentication, User class, Vendor class, Vendor = specific options
are needed in Relay-fwd and Relay-reply = message.
~Vijay


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C215FF.6A7CE910-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 17 10:01:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03664; Mon, 17 Jun 2002 10:01:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16184; Mon, 17 Jun 2002 10:00:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16118 for ; Mon, 17 Jun 2002 10:00:41 -0400 (EDT) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03560 for ; Mon, 17 Jun 2002 10:00:05 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel7.hp.com (Postfix) with ESMTP id 9D96980521A; Mon, 17 Jun 2002 10:00:05 -0400 (EDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by dce.india.hp.com with SMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id TAA27490; Mon, 17 Jun 2002 19:35:23 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Ralph Droms'" Cc: "'Bernie Volz (EUD)'" , Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Date: Mon, 17 Jun 2002 19:32:11 +0530 Message-ID: <002e01c21607$93c07140$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20020617085042.00b90520@mail.prospeed.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Ralph, For something like this, we dont need implementations at all. Its very sure that there willl be performance degradation in relay, if the Elapsed time option is not the first one. If the relay is configured to do load balance, then the relay has to process the whole message in search of this option, leading to the performance degradation in relay. we suppose relay to be light weight. Similar case is for server, if the authentication or server-id is not first, then it is going to process the whole message to discard the packet. This is something like, rejecting the dhcpv6 packet, if 1 <= message type <= 13 is not true. If there are more important options defined later, which has to occur first, then in that specification, we can rearrage the order and precedence. I think, we can define the order of the known important options now. ~ Vijay -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, June 17, 2002 6:29 PM To: vijayak@india.hp.com Cc: 'Bernie Volz (EUD)'; dhcwg@ietf.org Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Unitl we have more experience with real implementations, it's hard to know exactly what to optimize. So, let's run some experiments once we have interopable implementations and get some experience with real deployments so we can understand where the performance hits and improvement opportunities are. Then we can write up that experience and a specification for option ordering... - Ralph At 03:49 PM 6/17/2002 +0530, Vijayabhaskar A K wrote: >Hi Bernie, > >The requirement here is PERFORMANCE. Assume there are 1000 requests passing >through a server which are NOT intended to be handled by this server. This >will happen since most of the messages are Multicast only. This is not the >corner case situation as you said, this will happen in most of the cases. >There is nothing wrong in mandating this. This is something like specifying >these options in a fixed mesg header. The server/client will ignore the >remaining >option field, if there is any error in the mesg header. > >All of the above, the relay should be lightweight, if the admin has >configured >the relay to load balance based on Elapsed time option and how bad the >performance will be if the relay has to search for this option by parsing >the whole message. > > > the above might not even apply (for example, if a client or > > server always decodes all options to validate the packet, > > it won't save anything). > >Then, this is a poor implementation. If the first option itself is >erraneous, (for ex. auth itself fails), then there is no need to >parse remaining stuff. We should leave these kind of implementation >as corner case and go on mandating options' order of occurence. > >~ Vijay > >-----Original Message----- >From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] >Sent: Saturday, June 15, 2002 11:06 PM >To: 'vijayak@india.hp.com'; dhcwg@ietf.org >Subject: RE: [dhcwg] Order of occurence of DHCPv6 options > > >Vijay: >On the order of options, we chose specifically NOT to specify this. There >really is no >requirement or overwhelming reason to do this. Putting some options earlier >than others >improves performance in some situations so it will be wise for clients (and >servers) to >do this, but it is difficult to specify this and a client and server MUST >assume the >worst anyway. >For example, I'd argue that putting the Server Identifier option first (or >very early) >is best since it allows all servers that receive this (except for the >intended one) to >drop the packet almost immediately. Rather than having to look through 4 >options, won't >it be better if these servers only had to look at 1 option (the first). >Though, having said that there is no reason to require this and depending on >how a client >or server processes packets, the above might not even apply (for example, if >a client or >server always decodes all options to validate the packet, it won't save >anything). >So, we specifically decided not to specify option ordering and I think that >is a wise >decision. > > >Regarding the other issues, some clean-up for the draft will be required to >remove and >fix items based on the final status codes/option usage. >- Bernie >-----Original Message----- >From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] >Sent: Saturday, June 15, 2002 1:31 PM >To: dhcwg@ietf.org >Subject: [dhcwg] Order of occurence of DHCPv6 options > > >I think, we need to fix the order of options occuring in DHCPv6 messages >for better processing of the messages. >1. Elapsed Time option - Since based on this value only, the relay/server is >going to decide the policy of reply. >2. Status Code - In the case of Failure, this message can be directly >ignored >3. Authentication option - If authentication fails, nothing is needed to >be processed. >4. server-id - If the server id doesn't match, server can ignore it. >5. client-id - If the client id doesn't match, client can ignore it. >6. Rapid commit - Based on this, the server can determine whether it need >to send Advertise or Reply. > > >If any of these options are occuring, then they MUST occur in this order. >--------------------------------------------------------------------------- - >-- >ConfNoMatch and AddrUnavail are nowhere used. It can be removed. >AuthFailed is also nowhere used. We need to add text saying if the >server/client is not able to authenticate the other, then they >should send reply with error code AuthFailed set. >--------------------------------------------------------------------------- - >-- >R-forw. * * * * * >R-repl. * * * * * >Why Authentication, User class, Vendor class, Vendor specific options >are needed in Relay-fwd and Relay-reply message. >~Vijay > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 17 10:21:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04502; Mon, 17 Jun 2002 10:21:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17807; Mon, 17 Jun 2002 10:19:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17776 for ; Mon, 17 Jun 2002 10:19:19 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04413 for ; Mon, 17 Jun 2002 10:18:42 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id DA1C347AE; Mon, 17 Jun 2002 10:19:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Jun 2002 10:19:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] DHC WG charter Date: Mon, 17 Jun 2002 10:19:19 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2C28@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] DHC WG charter Thread-Index: AcITtOen86mXyyUqRwypP1HvubVxtACU9l0A From: "Bound, Jim" To: "Thomas Narten" , "Ralph Droms" Cc: X-OriginalArrivalTime: 17 Jun 2002 14:19:19.0692 (UTC) FILETIME=[F85964C0:01C21609] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17777 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Thomas, Well I have the expertise to work on prefixes topic area so does Ralph for CPE and edge routers. Plus we can always add others. Plus I think there are others here you may not be aware of with expertise your not aware of, which you did ask. Lets assume we agree with you. Where would you suggest this work exist in the IETF? thanks /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Friday, June 14, 2002 10:59 AM > To: Ralph Droms > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHC WG charter > > > Ralph, > > Thanks for getting this discussion started. > > > The working group has the following primary objectives: > > > * Develop additional authentication protocols within the framework > > defined in RFC3118, along with other mechanisms to mitigate the > > threat of attacks on DHCP clients and servers: > > - New RFC3118 protocols to address improved key management and > > improved scalability > > I think the charter should be more specific here. What new protocols > are needed? What problems need to be solved? The above is just a blank > check to do unspecified work (not good). > > > - Provide security for messages passed between relay agents and > > servers > > A good deliverable. > > > - Consider solutions for specific threats such as use of nonce > > identifier to defend against DoS attacks through FORCERENEW from > > off-path attackers > > This might be good, but it seems like a prerequisite is to have a > documented threat analysis. What are the primary threats to DHCP? > Which ones are the ones that are important to address? Only then does > it make sense to think about specfic solutions. > > > * Complete the specification of DHCP for IPv6 (DHCPv6): > > - Gain acceptance and publication of current Internet Draft as > > Proposed Standard > > - Develop and publish specifications for options and other > > extensions to DHCPv6, including those already published as > > Internet Drafts: > > + "DNS Configuration Options for DHCPv6" > > + "Time Configuration Options for DHCPv6" > > + "NIS Configuration Options for DHCPv6" > > + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6" > > + "Load Balancing for DHCPv6" > > - Encourage independent implementations and conduct > interoperability > > testing > > I don't think this needs to be called out in the charter. WGs don't do > interoperability testing per se. But interoperability reports are > needed for advancing documents along the standards track. > > > - Revise specification and publish for acceptance as > Draft Standard > > by 6/30/2002 > > > - Develop extensions to DHCPv6 for prefix delegation, DNS > > configuration, etc. > > I'm not sure I agree with this. I think the DHC needs to stick with > its core expertise, which is the DHC core protocols, and reviewing > options motivated from outside the WG from the perspective of being > consistent with standard DHC operating practice. > > But in terms of actually defining new options, I think that requires > significant input AND MOTIVATION from the customers of the option. In > the case of Prefix delegation, that seems like a broader problem, > where a DHC solution might well be appropriate. But I don't think this > should be driven by the DHC WG, since the problem is not inherently a > DHC problem. > > Does the DHC WG really have the expertise to do the prefix delegation > work? I wouldn't immediately think so. They do have expertise to > review any options once it is determined what the prefix delegation > solution requires. > > So, I think better charter wording would say that the WG will review > options whose impetus comes from other WGs. A number of the specific > options mentioned above are really motivated by other WGs. > > > * Revise and submit the DHCP specification for acceptance as a Full > > Standard > > I guess I'm a cynic. If there is no realistic plan for doing this, I'd > say leave it out of the charter. > > The charter should not be a kitchen sink of all possible work > items. It should capture the priority items the WG will work on over > the next 12 months. One can easily recharter if something interesting > pops up that should get attention. > > > * Complete the specification and publish work in progress as > > standards: > > - Failover protocol > > - DHCP/DDNS interaction > > - SNMP MIB > > What is the MIB item? Do we really need it? > > > - Host name options > > - Other client and relay agent options > > > * Review new options for DHCP, as deemed appropriate by the working > > group and/or the Internet area directors > > Thomas > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 17 10:32:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05190; Mon, 17 Jun 2002 10:32:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18832; Mon, 17 Jun 2002 10:32:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18805 for ; Mon, 17 Jun 2002 10:32:04 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05165 for ; Mon, 17 Jun 2002 10:31:26 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.3/8.12.3) id g5HEW3oU029103 for dhcwg@ietf.org env-from ; Mon, 17 Jun 2002 08:32:03 -0600 (MDT) Date: Mon, 17 Jun 2002 08:32:03 -0600 (MDT) From: Vernon Schryver Message-Id: <200206171432.g5HEW3oU029103@calcite.rhyolite.com> To: dhcwg@ietf.org Subject: RE: [dhcwg] Order of occurence of DHCPv6 options References: <002e01c21607$93c07140$2f290a0f@india.hp.com> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > From: "Vijayabhaskar A K" > For something like this, we dont need implementations at all. Almost no optimization tactic, and certainly including this one, can be discussed except in the context of a model implementation > Its very sure that there willl be performance degradation > in relay, if the Elapsed time option is not the first one. That is also wrong. The packets are not that big and hard to parse that any except the slowest CPUs with the least nearby memory will any trouble merely parsing to reject even the IPv6 DHCP packets. > If the relay is configured to do load balance, then the relay has to > process the whole message in search of this option, leading to the > performance degradation in relay. we suppose relay to be light weight. You must put a number on "lightweight" before you can talk about it. How many CPU cycles do you need to parse a packet? Surely you don't need more than 3 or 4 CPU cycles per byte of packet. If your CPU runs at only 10 MHz, how many packets could you parse and reject? Do you really expect to need to reject that many? Will the time spent parsing and rejecting a packet in your extremely slow CPU be more than the time required to deal deal with leaks through your multicast filter? Since you're talking about something extremely slow and lightweight, have you spent the money for perfect multicast filtering? > Similar case is for server, if the authentication or server-id is not > first, then it is going to process the whole message to discard the > packet. That assumes that the server will not parse the entire packet before deciding what it likes about it. That is an implementation model. > This is something like, rejecting the dhcpv6 packet, if > 1 <= message type <= 13 is not true. If there are more important > options defined later, which has to occur first, then in > that specification, we can rearrage the order and precedence. > I think, we can define the order of the known important options now. The number of premature optimizations for any protocol or program may not be unbounded, but it is a very large number. Vernon Schryver vjs@rhyolite.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 17 10:36:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05545; Mon, 17 Jun 2002 10:36:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18996; Mon, 17 Jun 2002 10:35:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18972 for ; Mon, 17 Jun 2002 10:35:13 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05379 for ; Mon, 17 Jun 2002 10:34:35 -0400 (EDT) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5HEZ5uY007935; Mon, 17 Jun 2002 10:35:06 -0400 (EDT) Received: from MJS-W2K.cisco.com (dhcp-161-44-170-95.cisco.com [161.44.170.95]) by goblet.cisco.com (Mirapoint) with ESMTP id ABH54736; Mon, 17 Jun 2002 10:34:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20020617102442.029f8298@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jun 2002 10:34:32 -0400 To: From: Mark Stapp Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Cc: "'Ralph Droms'" , "'Bernie Volz (EUD)'" , In-Reply-To: <002e01c21607$93c07140$2f290a0f@india.hp.com> References: <4.3.2.7.2.20020617085042.00b90520@mail.prospeed.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org It is certainly possible that different vendors will choose to make different decisions about how to parse and process dhcp options. That does not compromise interoperability or protocol robustness. It's reasonable to expect that the spec might include some discussion about option ordering, as an aid to implementors. But even that belongs in a 'discussion' or 'notes to implementors' section, not in the core specification. Other than that sort of discussion, this is not something that belongs in the spec at all. As Ralph notes, once we have deployment experience some clever person can volunteer to write the bcp on option-parsing. -- Mark At 07:32 PM 6/17/2002 +0530, Vijayabhaskar A K wrote: >Ralph, > >For something like this, we dont need implementations at all. >Its very sure that there willl be performance degradation >in relay, if the Elapsed time option is not the first one. >If the relay is configured to do load balance, then the relay has to >process the whole message in search of this option, leading to the >performance degradation in relay. we suppose relay to be light weight. >Similar case is for server, if the authentication or server-id is not >first, then it is going to process the whole message to discard the >packet. > >This is something like, rejecting the dhcpv6 packet, if >1 <= message type <= 13 is not true. If there are more important >options defined later, which has to occur first, then in >that specification, we can rearrage the order and precedence. >I think, we can define the order of the known important options now. > >~ Vijay >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Monday, June 17, 2002 6:29 PM >To: vijayak@india.hp.com >Cc: 'Bernie Volz (EUD)'; dhcwg@ietf.org >Subject: RE: [dhcwg] Order of occurence of DHCPv6 options > > >Unitl we have more experience with real implementations, it's hard to know >exactly what to optimize. So, let's run some experiments once we have >interopable implementations and get some experience with real deployments >so we can understand where the performance hits and improvement >opportunities are. Then we can write up that experience and a >specification for option ordering... > >- Ralph > >At 03:49 PM 6/17/2002 +0530, Vijayabhaskar A K wrote: > >Hi Bernie, > > > >The requirement here is PERFORMANCE. Assume there are 1000 requests passing > >through a server which are NOT intended to be handled by this server. This > >will happen since most of the messages are Multicast only. This is not the > >corner case situation as you said, this will happen in most of the cases. > >There is nothing wrong in mandating this. This is something like specifying > >these options in a fixed mesg header. The server/client will ignore the > >remaining > >option field, if there is any error in the mesg header. > > > >All of the above, the relay should be lightweight, if the admin has > >configured > >the relay to load balance based on Elapsed time option and how bad the > >performance will be if the relay has to search for this option by parsing > >the whole message. > > > > > the above might not even apply (for example, if a client or > > > server always decodes all options to validate the packet, > > > it won't save anything). > > > >Then, this is a poor implementation. If the first option itself is > >erraneous, (for ex. auth itself fails), then there is no need to > >parse remaining stuff. We should leave these kind of implementation > >as corner case and go on mandating options' order of occurence. > > > >~ Vijay > > > >-----Original Message----- > >From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > >Sent: Saturday, June 15, 2002 11:06 PM > >To: 'vijayak@india.hp.com'; dhcwg@ietf.org > >Subject: RE: [dhcwg] Order of occurence of DHCPv6 options > > > > > >Vijay: > >On the order of options, we chose specifically NOT to specify this. There > >really is no > >requirement or overwhelming reason to do this. Putting some options earlier > >than others > >improves performance in some situations so it will be wise for clients (and > >servers) to > >do this, but it is difficult to specify this and a client and server MUST > >assume the > >worst anyway. > >For example, I'd argue that putting the Server Identifier option first (or > >very early) > >is best since it allows all servers that receive this (except for the > >intended one) to > >drop the packet almost immediately. Rather than having to look through 4 > >options, won't > >it be better if these servers only had to look at 1 option (the first). > >Though, having said that there is no reason to require this and depending >on > >how a client > >or server processes packets, the above might not even apply (for example, >if > >a client or > >server always decodes all options to validate the packet, it won't save > >anything). > >So, we specifically decided not to specify option ordering and I think that > >is a wise > >decision. > > > > > >Regarding the other issues, some clean-up for the draft will be required to > >remove and > >fix items based on the final status codes/option usage. > >- Bernie > >-----Original Message----- > >From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > >Sent: Saturday, June 15, 2002 1:31 PM > >To: dhcwg@ietf.org > >Subject: [dhcwg] Order of occurence of DHCPv6 options > > > > > >I think, we need to fix the order of options occuring in DHCPv6 messages > >for better processing of the messages. > >1. Elapsed Time option - Since based on this value only, the relay/server >is > >going to decide the policy of reply. > >2. Status Code - In the case of Failure, this message can be directly > >ignored > >3. Authentication option - If authentication fails, nothing is needed to > >be processed. > >4. server-id - If the server id doesn't match, server can ignore it. > >5. client-id - If the client id doesn't match, client can ignore it. > >6. Rapid commit - Based on this, the server can determine whether it need > >to send Advertise or Reply. > > > > > >If any of these options are occuring, then they MUST occur in this order. > >--------------------------------------------------------------------------- >- > >-- > >ConfNoMatch and AddrUnavail are nowhere used. It can be removed. > >AuthFailed is also nowhere used. We need to add text saying if the > >server/client is not able to authenticate the other, then they > >should send reply with error code AuthFailed set. > >--------------------------------------------------------------------------- >- > >-- > >R-forw. * * * * * > >R-repl. * * * * * > >Why Authentication, User class, Vendor class, Vendor specific options > >are needed in Relay-fwd and Relay-reply message. > >~Vijay > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 18 03:41:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09420; Tue, 18 Jun 2002 03:41:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23658; Tue, 18 Jun 2002 03:40:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23632 for ; Tue, 18 Jun 2002 03:40:20 -0400 (EDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09402 for ; Tue, 18 Jun 2002 03:39:32 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 18 Jun 2002 13:31:01 +0530 Received: from radhard (radhard.future.futsoft.com [10.8.5.10]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g5IDBC602013 for ; Tue, 18 Jun 2002 18:41:12 +0530 Reply-To: From: "Radha Rani D" To: Date: Tue, 18 Jun 2002 13:13:09 +0530 Message-Id: <000301c2169b$cb7e7700$0a05080a@Future.Futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D5DE@EAMBUNT705> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C216C9.E536B300" Subject: [dhcwg] unsubscribe Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C216C9.E536B300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0004_01C216C9.E536B300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Order of occurence of DHCPv6 options

 <= /p>

------=_NextPart_000_0004_01C216C9.E536B300-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 18 05:21:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10787; Tue, 18 Jun 2002 05:21:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29559; Tue, 18 Jun 2002 05:21:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29538 for ; Tue, 18 Jun 2002 05:21:16 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10773 for ; Tue, 18 Jun 2002 05:20:37 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-14.cisco.com [10.82.240.14]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA18150; Tue, 18 Jun 2002 05:20:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20020618051949.037a5c08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jun 2002 05:20:14 -0400 To: From: Ralph Droms Subject: Re: [dhcwg] unsubscribe Cc: In-Reply-To: <000301c2169b$cb7e7700$0a05080a@Future.Futsoft.com> References: <66F66129A77AD411B76200508B65AC69B4D5DE@EAMBUNT705> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org To unsubscribe from the dhcwg@ietf.org mailing list, please go to https://www1.ietf.org/mailman/listinfo/dhcwg - Ralph Droms At 01:13 PM 6/18/2002 +0530, Radha Rani D wrote: > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 18 09:50:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17406; Tue, 18 Jun 2002 09:50:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13154; Tue, 18 Jun 2002 09:47:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13129 for ; Tue, 18 Jun 2002 09:47:07 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17084 for ; Tue, 18 Jun 2002 09:46:27 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g5IDl5l13548 for ; Tue, 18 Jun 2002 08:47:05 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g5IDl4921618 for ; Tue, 18 Jun 2002 08:47:04 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Jun 18 08:47:04 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 18 Jun 2002 08:46:24 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D5FB@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'internet-drafts@ietf.org'" Cc: "'dhcwg@ietf.org'" Date: Tue, 18 Jun 2002 08:47:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C216CE.9FDA67C0" Subject: [dhcwg] Draft Submission - draft-ietf-dhc-dhcpv6-loadb-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C216CE.9FDA67C0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C216CE.9FDA67C0" ------_=_NextPart_001_01C216CE.9FDA67C0 Content-Type: text/plain; charset="iso-8859-1" > Hello: > Please publish the following updated Internet-Draft: > > <> > Thanks in advance. > Bernie Volz ------_=_NextPart_001_01C216CE.9FDA67C0 Content-Type: text/html; charset="iso-8859-1" Draft Submission - draft-ietf-dhc-dhcpv6-loadb-01.txt

Hello:

Please publish the following updated Internet-Draft:

<<draft-ietf-dhc-dhcpv6-loadb-01.txt>>
Thanks in advance.

Bernie Volz

------_=_NextPart_001_01C216CE.9FDA67C0-- ------_=_NextPart_000_01C216CE.9FDA67C0 Content-Type: text/plain; name="draft-ietf-dhc-dhcpv6-loadb-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-dhc-dhcpv6-loadb-01.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force B. = Volz INTERNET DRAFT = Ericsson DHC Working Group June = 2002 Expires: December 18, 2002 Load Balancing for DHCPv6 draft-ietf-dhc-dhcpv6-loadb-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 18, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies a load balancing algorithm for use with DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers to decide which one should service a client, without exchanging any information beyond initial configuration. It expands on RFC 3074 "DHC Load Balancing Algorithm" to include DHCPv6. 1. Introduction This document extends the load balancing concepts described in RFC 3074 "DHC Load Balancing Algorithm" [3] to DHCPv6 [2]. 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [1]. Volz Expires 18 Dec 2002 [Page = 1] =0C Internet Draft Load Balancing for DHCPv6 (-01) 18 June = 2002 3. Terminology This document uses terminology specific to IPv6 and DHCPv6 as = defined in the "Terminology" section of the DHCP specification [2]. This document uses many of the concepts and terminology specific to load balancing as defined in the "Load Balancing Terminology" = section of the DHC Load Balancing specification [3]. 4. Motivation for Load Balancing DHCP [2] provides for multiple servers to advertise service to the clients on links. A client is generally offered configuration = service from each of the servers and there is no guarantee of consistency = for the client (a different server may be selected each time). Load balancing provides a quick and easy way for a server to determine whether it should service a particular client. Only the selected server or servers respond to the client instead of all of the servers. Load balancing provides a means to efficiently and consistently distribute the processing load for clients across multiple servers rather than having each server respond to every client. In addition, rather than having multiple servers service the same clients, load balancing allows each server to service a different = set of clients. If a server is down, the other servers may take over the clients that the downed server was to handle by monitoring the elapsed time option in client requests. The load balancing technique described here and in RFC 3074 [3] work well for request/reply transaction protocols where a consistent client identifier is available. For example, a high performance (non-redundant) configuration of = DHCP servers might be as follows: +---------------+ +---------------+ =20 | DHCP Server 1 | | DHCP Server 2 | | HBA 0-127 | | HBA 128-255 | +-------+-------+ +-------+-------+ | | | | <---------+-------------------------+-------Network---> =20 In this example, rather than both servers servicing all clients, = each services appropriate half the clients and each services the same set of clients consistently. A redundant set of servers could be added (each configured with appropriate HBAs). Volz Expires 18 Dec 2002 [Page = 2] =0C Internet Draft Load Balancing for DHCPv6 (-01) 18 June = 2002 5. DHCPv6 Server Operation DHCPv6 uses a DUID (DHCP Unique Identifier) to identify clients. The DUID is carried in most client-generated messages in the Client Identifier option as described in [2]. The client's DUID is defined to be the Service Transaction ID (STID) [3]. DHCPv6 uses two types of client messages, those that are directed to a specific server and those that are directed to all servers. The messages directed to a specific server contain a Server Identifier option as described in [2]. The messages directed to all servers do not include a Server Identifier option. For the messages directed to a specific server, this load balancing algorithm does not apply and a server processes that client's = request if the Server Identifier option's DUID of the request matches its = own and discards all other requests. For the messages directed to all servers, the load balancing algorithm MAY be used to limit the clients that a server services if the request contains a Client Identifier option. The server uses the hash algorithm described in [3] on the client's DUID (the STID) and uses the resulting hash value to determine if the client is within the server's configured hash bucket assignment (HBA) [3]. If the = hash value is assigned to the server, the server MUST process the client request (other server policy may of course determine how the request is processed and whether a reply is sent to the client). If the hash value is not assigned to the server, the server SHOULD NOT process the request. The server MAY process the request if the elapsed time value in the Elapsed Time option of the request exceeds a configured value (the Service Delay or SD in [3]). How the SD is configured for a server is outside the scope of this document. For client requests which do not contain a Client Identifier option, there is no STID and thus all servers process these requests. A load balancing server would have the following processing flow for received client messages: 1. If the Server Identifier option is present in the message, process the message as per [2]. 2. If no Client Identifier option is present in the message, process the message as per [2]. 3. If the Client Identifier option's DUID is within the server's hash bucket assignment, process as per [2]. 4. If the Elapsed Time option is present in the message and its value exceeds the configured threshold, process as per [2]. 5. Otherwise, do not process the message because load balancing dictates that another server should be processing the message. Volz Expires 18 Dec 2002 [Page = 3] =0C Internet Draft Load Balancing for DHCPv6 (-01) 18 June = 2002 The hash bucket assignments for each server must be configured and care must be taken to assign each hash bucket to at least one = server. How the hash buckets are configured in servers is outside the scope of this document. If a single hash bucket is assigned to multiple servers, the logic a client uses to select a server applies (just as if there were multiple servers for clients without load balancing). For example, each server can be configured with a different server preference value [2]. 6. DHCPv6 Relay Agent Operation Relay agents MAY be configured to relay client requests using load balancing. A load balancing relay agent must be configured with additional information as to the hash buckets assigned to each server, in a manner similar to that presented in [3]. Care must be taken to assure consistent information if both relay agents and servers are configured with load balancing information. A relay agent would have the following processing flow for received client messages: 1. If no Client Identifier option is present in the client's message, relay the message to all configured servers regardless of hash bucket assignments. 2. Otherwise, use the hash algorithm described in [3] on the DUID in the Client Identifier option and relay the message to the server or servers assigned that hash bucket. Relay agents MUST be configured to forward client requests to all of the DHCPv6 servers that may be part of a load balancing group. Note: If relay agents are configured to do load balancing, the Elapsed Time option will be ineffective in allowing any server (not just the servers in the load balancing group) to respond to a client's request. 7. DHCPv6 Client Operation DHCPv6 clients need not be aware that load balancing is in use by the servers. A client operates as described in [2]. Client operation with respect to load balancing is the same as client operation with multiple servers. If a server that was servicing a client becomes unavailable for some reason, the client will eventually time-out and communicate with all servers. When this happens, if there are multiple servers assigned to handle that client's hash bucket, one or more of these remaining servers will respond. If there are no other servers for that hash bucket, other servers may respond once the elapsed time value in the Elapsed Time option exceeds their configured SD. Volz Expires 18 Dec 2002 [Page = 4] =0C Internet Draft Load Balancing for DHCPv6 (-01) 18 June = 2002 If there is only one server (either for all clients or for some of the hash buckets), failure of that server will prevent clients from obtaining or extending the lifetimes of addresses. However, there is no difference whether load balancing is used or not. 8. Security Considerations This proposal in and by itself provides no security, nor does it impact existing security. See [2] for further details as to DHCPv6 security issues. Servers using load balancing are responsible for ensuring that if the contents of the HBA are transmitted over the network as part of the process of configuring any server, that message be secured against tampering, since tempering with the HBA could result in a denial of service for some or all clients. 9. Acknowledgements Thanks to the DHC Working Group for their time and input into the specification starting at IETF-52. Thanks also to the following individuals for their comments and questions (in alphabetical order) Stefan Berg, Herold Fagerberg, Ted Lemon, Tony Lindstrom, Thomas Narten, Anders Strand, and Jack Wong. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Droms (ed.), R., Bound, J., Volz, Bernie, Lemon, Ted, Perkins, C., Carney, M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-26 (work in progress), June 2002. [3] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load=20 Balancing Algorithm", RFC 3074, February 2001. Author's Address Bernie Volz Ericsson 959 Concord Street Framingham, MA 01701 USA Phone: +1 508 875 3162 EMail: bernie.volz@ericsson.com Volz Expires 18 Dec 2002 [Page = 5] =0C Internet Draft Load Balancing for DHCPv6 (-01) 18 June = 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Volz Expires 18 Dec 2002 [Page = 6] ------_=_NextPart_000_01C216CE.9FDA67C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 19 07:28:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13759; Wed, 19 Jun 2002 07:28:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18622; Wed, 19 Jun 2002 07:27:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18594 for ; Wed, 19 Jun 2002 07:27:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13408; Wed, 19 Jun 2002 07:27:05 -0400 (EDT) Message-Id: <200206191127.HAA13408@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Jun 2002 07:27:05 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-loadb-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Load Balancing for DHCPv6 Author(s) : B. Volz Filename : draft-ietf-dhc-dhcpv6-loadb-01.txt Pages : 6 Date : 18-Jun-02 This document specifies a load balancing algorithm for use with DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers to decide which one should service a client, without exchanging any information beyond initial configuration. It expands on RFC 3074 'DHC Load Balancing Algorithm' to include DHCPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-loadb-01.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-dhc-dhcpv6-loadb-01.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-dhc-dhcpv6-loadb-01.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: <20020618131721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-loadb-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-loadb-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020618131721.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 19 17:53:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04639; Wed, 19 Jun 2002 17:53:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01443; Wed, 19 Jun 2002 17:52:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01415 for ; Wed, 19 Jun 2002 17:52:01 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04560 for ; Wed, 19 Jun 2002 17:51:20 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id ED18D5641; Wed, 19 Jun 2002 17:51:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Jun 2002 17:51:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Date: Wed, 19 Jun 2002 17:51:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8B16@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] Order of occurence of DHCPv6 options Thread-Index: AcIV6JTVedsIegHRS1OduIDMt/1W3wB8tPmQ From: "Bound, Jim" To: , "Bernie Volz (EUD)" , X-OriginalArrivalTime: 19 Jun 2002 21:51:59.0912 (UTC) FILETIME=[89ED9280:01C217DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA01416 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Just as a note to another doc. For IPv6 processing you MUST process all options/extensions an implementation is not allowed to skip them. /jim > -----Original Message----- > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > Sent: Monday, June 17, 2002 6:19 AM > To: 'Bernie Volz (EUD)'; dhcwg@ietf.org > Subject: RE: [dhcwg] Order of occurence of DHCPv6 options > > > Hi Bernie, > > The requirement here is PERFORMANCE. Assume there are 1000 > requests passing > through a server which are NOT intended to be handled by this > server. This > will happen since most of the messages are Multicast only. > This is not the > corner case situation as you said, this will happen in most > of the cases. > There is nothing wrong in mandating this. This is something > like specifying > these options in a fixed mesg header. The server/client will > ignore the > remaining > option field, if there is any error in the mesg header. > > All of the above, the relay should be lightweight, if the admin has > configured > the relay to load balance based on Elapsed time option and how bad the > performance will be if the relay has to search for this > option by parsing > the whole message. > > > the above might not even apply (for example, if a client or > > server always decodes all options to validate the packet, > > it won't save anything). > > Then, this is a poor implementation. If the first option itself is > erraneous, (for ex. auth itself fails), then there is no need to > parse remaining stuff. We should leave these kind of implementation > as corner case and go on mandating options' order of occurence. > > ~ Vijay > > -----Original Message----- > From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > Sent: Saturday, June 15, 2002 11:06 PM > To: 'vijayak@india.hp.com'; dhcwg@ietf.org > Subject: RE: [dhcwg] Order of occurence of DHCPv6 options > > > Vijay: > On the order of options, we chose specifically NOT to specify > this. There > really is no > requirement or overwhelming reason to do this. Putting some > options earlier > than others > improves performance in some situations so it will be wise > for clients (and > servers) to > do this, but it is difficult to specify this and a client and > server MUST > assume the > worst anyway. > For example, I'd argue that putting the Server Identifier > option first (or > very early) > is best since it allows all servers that receive this (except for the > intended one) to > drop the packet almost immediately. Rather than having to > look through 4 > options, won't > it be better if these servers only had to look at 1 option > (the first). > Though, having said that there is no reason to require this > and depending on > how a client > or server processes packets, the above might not even apply > (for example, if > a client or > server always decodes all options to validate the packet, it > won't save > anything). > So, we specifically decided not to specify option ordering > and I think that > is a wise > decision. > > > Regarding the other issues, some clean-up for the draft will > be required to > remove and > fix items based on the final status codes/option usage. > - Bernie > -----Original Message----- > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > Sent: Saturday, June 15, 2002 1:31 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Order of occurence of DHCPv6 options > > > I think, we need to fix the order of options occuring in > DHCPv6 messages > for better processing of the messages. > 1. Elapsed Time option - Since based on this value only, the > relay/server is > going to decide the policy of reply. > 2. Status Code - In the case of Failure, this message can be directly > ignored > 3. Authentication option - If authentication fails, nothing > is needed to > be processed. > 4. server-id - If the server id doesn't match, server can ignore it. > 5. client-id - If the client id doesn't match, client can ignore it. > 6. Rapid commit - Based on this, the server can determine > whether it need > to send Advertise or Reply. > > > If any of these options are occuring, then they MUST occur in > this order. > -------------------------------------------------------------- > -------------- > -- > ConfNoMatch and AddrUnavail are nowhere used. It can be removed. > AuthFailed is also nowhere used. We need to add text saying if the > server/client is not able to authenticate the other, then they > should send reply with error code AuthFailed set. > -------------------------------------------------------------- > -------------- > -- > R-forw. * * * * * > R-repl. * * * * * > Why Authentication, User class, Vendor class, Vendor specific options > are needed in Relay-fwd and Relay-reply message. > ~Vijay > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 19 18:01:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04850; Wed, 19 Jun 2002 18:01:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01888; Wed, 19 Jun 2002 18:00:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01862 for ; Wed, 19 Jun 2002 18:00:29 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04771 for ; Wed, 19 Jun 2002 17:59:48 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A6D9B41E4; Wed, 19 Jun 2002 18:00:26 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Jun 2002 18:00:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [dhcwg] Order of occurence of DHCPv6 options Date: Wed, 19 Jun 2002 18:00:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8B17@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] Order of occurence of DHCPv6 options Thread-Index: AcIWB52ohl59NY94TCagJAEaxO7ZLAB1F1Pg From: "Bound, Jim" To: , "Ralph Droms" Cc: "Bernie Volz (EUD)" , X-OriginalArrivalTime: 19 Jun 2002 22:00:26.0631 (UTC) FILETIME=[B7F4C170:01C217DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA01863 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Vijay, I think Ralph is not disagreeing with you. But for proposed standard I think is our first goal here. I don't think we will get agreement on the ordering at all quickly. Also though I am a strong believer in extrapolation I do think it wise to do some implementation benchmarks to support any decision in this direction if for no other reason than it just reinforces a critical point. Also one OS virtual memory might lend itself to parsing options far different than another. Such as a router OS with flat virtual memory space vs a huge lab server with GBs of memory and VM threads. So any extrapolation can be argued to not be 100% scientifically. I do agree though that options should not be permitted to be skipped in the sense that one does not look at the option code in an implementation. Steve Deering pushed this very strongly for IPv6 options and for very good reason. I believe those principles hold here too for DHCPv6. regards, /jim > -----Original Message----- > From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > Sent: Monday, June 17, 2002 10:02 AM > To: 'Ralph Droms' > Cc: 'Bernie Volz (EUD)'; dhcwg@ietf.org > Subject: RE: [dhcwg] Order of occurence of DHCPv6 options > > > Ralph, > > For something like this, we dont need implementations at all. > Its very sure that there willl be performance degradation > in relay, if the Elapsed time option is not the first one. > If the relay is configured to do load balance, then the relay has to > process the whole message in search of this option, leading to the > performance degradation in relay. we suppose relay to be light weight. > Similar case is for server, if the authentication or server-id is not > first, then it is going to process the whole message to discard the > packet. > > This is something like, rejecting the dhcpv6 packet, if > 1 <= message type <= 13 is not true. If there are more important > options defined later, which has to occur first, then in > that specification, we can rearrage the order and precedence. > I think, we can define the order of the known important options now. > > ~ Vijay > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Monday, June 17, 2002 6:29 PM > To: vijayak@india.hp.com > Cc: 'Bernie Volz (EUD)'; dhcwg@ietf.org > Subject: RE: [dhcwg] Order of occurence of DHCPv6 options > > > Unitl we have more experience with real implementations, it's > hard to know > exactly what to optimize. So, let's run some experiments once we have > interopable implementations and get some experience with real > deployments > so we can understand where the performance hits and improvement > opportunities are. Then we can write up that experience and a > specification for option ordering... > > - Ralph > > At 03:49 PM 6/17/2002 +0530, Vijayabhaskar A K wrote: > >Hi Bernie, > > > >The requirement here is PERFORMANCE. Assume there are 1000 > requests passing > >through a server which are NOT intended to be handled by > this server. This > >will happen since most of the messages are Multicast only. > This is not the > >corner case situation as you said, this will happen in most > of the cases. > >There is nothing wrong in mandating this. This is something > like specifying > >these options in a fixed mesg header. The server/client will > ignore the > >remaining > >option field, if there is any error in the mesg header. > > > >All of the above, the relay should be lightweight, if the admin has > >configured > >the relay to load balance based on Elapsed time option and > how bad the > >performance will be if the relay has to search for this > option by parsing > >the whole message. > > > > > the above might not even apply (for example, if a client or > > > server always decodes all options to validate the packet, > > > it won't save anything). > > > >Then, this is a poor implementation. If the first option itself is > >erraneous, (for ex. auth itself fails), then there is no need to > >parse remaining stuff. We should leave these kind of implementation > >as corner case and go on mandating options' order of occurence. > > > >~ Vijay > > > >-----Original Message----- > >From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > >Sent: Saturday, June 15, 2002 11:06 PM > >To: 'vijayak@india.hp.com'; dhcwg@ietf.org > >Subject: RE: [dhcwg] Order of occurence of DHCPv6 options > > > > > >Vijay: > >On the order of options, we chose specifically NOT to > specify this. There > >really is no > >requirement or overwhelming reason to do this. Putting some > options earlier > >than others > >improves performance in some situations so it will be wise > for clients (and > >servers) to > >do this, but it is difficult to specify this and a client > and server MUST > >assume the > >worst anyway. > >For example, I'd argue that putting the Server Identifier > option first (or > >very early) > >is best since it allows all servers that receive this (except for the > >intended one) to > >drop the packet almost immediately. Rather than having to > look through 4 > >options, won't > >it be better if these servers only had to look at 1 option > (the first). > >Though, having said that there is no reason to require this > and depending > on > >how a client > >or server processes packets, the above might not even apply > (for example, > if > >a client or > >server always decodes all options to validate the packet, it > won't save > >anything). > >So, we specifically decided not to specify option ordering > and I think that > >is a wise > >decision. > > > > > >Regarding the other issues, some clean-up for the draft will > be required to > >remove and > >fix items based on the final status codes/option usage. > >- Bernie > >-----Original Message----- > >From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] > >Sent: Saturday, June 15, 2002 1:31 PM > >To: dhcwg@ietf.org > >Subject: [dhcwg] Order of occurence of DHCPv6 options > > > > > >I think, we need to fix the order of options occuring in > DHCPv6 messages > >for better processing of the messages. > >1. Elapsed Time option - Since based on this value only, the > relay/server > is > >going to decide the policy of reply. > >2. Status Code - In the case of Failure, this message can be directly > >ignored > >3. Authentication option - If authentication fails, nothing > is needed to > >be processed. > >4. server-id - If the server id doesn't match, server can ignore it. > >5. client-id - If the client id doesn't match, client can ignore it. > >6. Rapid commit - Based on this, the server can determine > whether it need > >to send Advertise or Reply. > > > > > >If any of these options are occuring, then they MUST occur > in this order. > >------------------------------------------------------------- > -------------- > - > >-- > >ConfNoMatch and AddrUnavail are nowhere used. It can be removed. > >AuthFailed is also nowhere used. We need to add text saying if the > >server/client is not able to authenticate the other, then they > >should send reply with error code AuthFailed set. > >------------------------------------------------------------- > -------------- > - > >-- > >R-forw. * * * * * > >R-repl. * * * * * > >Why Authentication, User class, Vendor class, Vendor specific options > >are needed in Relay-fwd and Relay-reply message. > >~Vijay > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 20 07:06:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24618; Thu, 20 Jun 2002 07:06:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12959; Thu, 20 Jun 2002 07:05:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12940 for ; Thu, 20 Jun 2002 07:05:36 -0400 (EDT) Received: from localhost.localdomain ([209.120.139.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24592 for ; Thu, 20 Jun 2002 07:04:55 -0400 (EDT) Received: (from rdroms@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5KB50904137; Thu, 20 Jun 2002 07:05:00 -0400 Date: Thu, 20 Jun 2002 07:05:00 -0400 Message-Id: <200206201105.g5KB50904137@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: rdroms set sender to rdroms@cisco.com using -f From: Ralph Droms To: dhcwg@ietf.org CC: rdroms@cisco.com Reply-to: rdroms@cisco.com Subject: [dhcwg] Question about DHCPv6 authentication Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie Volz wrote: > - The "AuthFailed" status code is not referenced explicitly in the > document except for in the list of Status Codes (24.4). Should this be > added to Chapter 21 somewhere? Perhaps text is needed in 21.5.2 that > says that a server should send a response (Reply or Advertise) with a > Status Code option with code AuthFailed and a message for the user, a > Server Identifier, and Client Identifier (if included in the original > message)? This would be instead of discarding the message? > > Or, is this status code really unnecessary? Good question - the doc currently specifies that messages that don't pass authentication are discarded. That behavior sounds right for a client. Should the server send the response it would have sent (Advertise or Reply) with an AuthFailed status code? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 20 07:50:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25960; Thu, 20 Jun 2002 07:50:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15189; Thu, 20 Jun 2002 07:49:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15163 for ; Thu, 20 Jun 2002 07:49:46 -0400 (EDT) Received: from localhost.localdomain ([209.120.139.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25918 for ; Thu, 20 Jun 2002 07:49:03 -0400 (EDT) Received: (from rdroms@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5KBnD304202; Thu, 20 Jun 2002 07:49:13 -0400 Date: Thu, 20 Jun 2002 07:49:13 -0400 Message-Id: <200206201149.g5KBnD304202@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: rdroms set sender to rdroms@cisco.com using -f From: Ralph Droms To: dhcwg@ietf.org CC: rdroms@cisco.com Reply-to: rdroms@cisco.com Subject: [dhcwg] Size of DUID? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie wrote: > - In section 9.1, DUID's are restricted to 256 octets. This seems way overkill. > Can we reduce this to 128 octets. Note that we no longer use a domain name and > this might have been a reason for the original 256 octets length. I'm just > concerned that servers might need to reserve 256 (258) octets, worst case, and > while storage is relatively cheap, it still costs something. If you want to have > a server that supports 1 million clients, why have to retain 256 MB of disk/memory > just to accommodate them (yes, you could use dynamic allocation but that has some > other issues with it). Changing the upper limit on the length of a DUID to 128 bytes seems reasonable to me...anyone have a supporting or conflicting opinion? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jun 20 08:33:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27391; Thu, 20 Jun 2002 08:33:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17747; Thu, 20 Jun 2002 08:31:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17719 for ; Thu, 20 Jun 2002 08:31:50 -0400 (EDT) Received: from siegel.bol.com.br (siegel.bol.com.br [200.221.24.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27284 for ; Thu, 20 Jun 2002 08:31:07 -0400 (EDT) Received: from fevice01 (200.221.24.191) by siegel.bol.com.br (5.1.071) id 3CBDB0240102DB96; Thu, 20 Jun 2002 09:30:44 -0300 Message-ID: <002b01c21857$069f74d0$c52d3d0a@fevice01> From: "Fernando" To: , References: <200206201149.g5KBnD304202@localhost.localdomain> Subject: Re: [dhcwg] Size of DUID? Date: Thu, 20 Jun 2002 09:35:49 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Sender-IP: 200.181.14.2 Content-Transfer-Encoding: 8bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi, I'd like ti unsubscribe me from this mail list. Thanks, Fernando. ----- Original Message ----- From: "Ralph Droms" To: Cc: Sent: Thursday, June 20, 2002 8:49 AM Subject: [dhcwg] Size of DUID? > Quer ter seu próprio endereço na Internet? > Garanta já o seu e ainda ganhe cinco e-mails personalizados. > DomíniosBOL - http://dominios.bol.com.br > > Bernie wrote: > > - In section 9.1, DUID's are restricted to 256 octets. This seems way overkill. > > Can we reduce this to 128 octets. Note that we no longer use a domain name and > > this might have been a reason for the original 256 octets length. I'm just > > concerned that servers might need to reserve 256 (258) octets, worst case, and > > while storage is relatively cheap, it still costs something. If you want to have > > a server that supports 1 million clients, why have to retain 256 MB of disk/memory > > just to accommodate them (yes, you could use dynamic allocation but that has some > > other issues with it). > > Changing the upper limit on the length of a DUID to 128 bytes seems > reasonable to me...anyone have a supporting or conflicting opinion? > > - Ralph > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 24 07:48:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00489; Mon, 24 Jun 2002 07:48:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09394; Mon, 24 Jun 2002 07:47:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09371 for ; Mon, 24 Jun 2002 07:47:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29954; Mon, 24 Jun 2002 07:46:25 -0400 (EDT) Message-Id: <200206241146.HAA29954@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 24 Jun 2002 07:46:25 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Resolution of DNS Name Conflicts Among DHCP Clients Author(s) : M. Stapp Filename : draft-ietf-dhc-ddns-resolution-04.txt Pages : 13 Date : 21-Jun-02 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS(RFC1034[1], RFC1035[2]), and specifically updating the name to address and address to name mappings maintained in the DNS. The 'Client FQDN Option'[14] specifies the client FQDN option, through which DHCP clients and servers can exchange information about client FQDNs. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-04.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-dhc-ddns-resolution-04.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-dhc-ddns-resolution-04.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: <20020621121540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ddns-resolution-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020621121540.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 24 08:40:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00478; Mon, 24 Jun 2002 07:48:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09434; Mon, 24 Jun 2002 07:47:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09405 for ; Mon, 24 Jun 2002 07:47:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29972; Mon, 24 Jun 2002 07:46:30 -0400 (EDT) Message-Id: <200206241146.HAA29972@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 24 Jun 2002 07:46:29 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-fqdn-option-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The DHCP Client FQDN Option Author(s) : M. Stapp, Y. Rekhter Filename : draft-ietf-dhc-fqdn-option-04.txt Pages : 15 Date : 21-Jun-02 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies a DHCP option which can be used to exchange information about a DHCP client's fully-qualified domain name, and about responsibility for updating DNS RRs related to the client's DHCP lease. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-04.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-dhc-fqdn-option-04.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-dhc-fqdn-option-04.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: <20020621121552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-fqdn-option-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-fqdn-option-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020621121552.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jun 24 08:43:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03993; Mon, 24 Jun 2002 08:43:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13676; Mon, 24 Jun 2002 08:43:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25772 for ; Sun, 23 Jun 2002 01:31:09 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11572 for ; Sun, 23 Jun 2002 01:30:25 -0400 (EDT) Received: from localhost ([2001:3e8:0:8:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5N5V4891127 for ; Sun, 23 Jun 2002 14:31:04 +0900 (JST) Date: Sun, 23 Jun 2002 14:31:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 20 Subject: [dhcwg] minor typo in dhcpv6-26 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I've found some typo in dhcpv6-26: In section 18.2.1 (Receipt of Request messages), we have the following sentence: If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The "Solicit" should be "Request", and the "Advertise" should be "Reply". Sections 18.2.4 and 18.2.5 have the same kind of typo. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jun 25 07:01:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29176; Tue, 25 Jun 2002 07:01:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03489; Tue, 25 Jun 2002 07:01:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03463 for ; Tue, 25 Jun 2002 07:01:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28983; Tue, 25 Jun 2002 07:00:40 -0400 (EDT) Message-Id: <200206251100.HAA28983@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Jun 2002 07:00:39 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Client Preferred Prefix option for DHCPv6 Author(s) : A. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt Pages : 5 Date : 24-Jun-02 This document describes the Client Preferred Prefix option by which the client can specify its preferred prefixes on which the addresses need to be allocated by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020624143516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624143516.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jun 26 06:41:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10377; Wed, 26 Jun 2002 06:41:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16872; Wed, 26 Jun 2002 06:41:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16843 for ; Wed, 26 Jun 2002 06:40:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10183; Wed, 26 Jun 2002 06:40:12 -0400 (EDT) Message-Id: <200206261040.GAA10183@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 26 Jun 2002 06:40:12 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-suboption-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Authentication Suboption for the DHCP Relay Agent Option Author(s) : M. Stapp, T. Lemon Filename : draft-ietf-dhc-auth-suboption-00.txt Pages : 13 Date : 25-Jun-02 The DHCP Relay Agent Information Option RFC3046[1] conveys information between a DHCP Relay Agent and a DHCP server. This specification defines a new authentication suboption for that option which supports source entity authentication and data integrity for that option. The authentication suboption contains a payload derived from the option used in DHCP Authentication RFC3118[2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-auth-suboption-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-auth-suboption-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020625141528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-auth-suboption-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-auth-suboption-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020625141528.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jun 28 06:37:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17638; Fri, 28 Jun 2002 06:37:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11919; Fri, 28 Jun 2002 06:37:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11852 for ; Fri, 28 Jun 2002 06:37:13 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17371; Fri, 28 Jun 2002 06:36:24 -0400 (EDT) Message-Id: <200206281036.GAA17371@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Jun 2002 06:36:24 -0400 Subject: [dhcwg] I-D ACTION:draft-candolin-cam-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Context Aware Management Architecture Author(s) : C. Candolin, H. Kari Filename : draft-candolin-cam-00.txt Pages : Date : 27-Jun-02 Most protocols and applications are designed for connections that are fairly static. When a node changes its point of attachment to the Internet frequently, it must be able to rapidly adapt to the new environment. Traditionally, each application and protocol tries to do this independently of each other. In some cases, applications have been tailored to communicate with one other protocol layer to notice such changes. The main problem with this approach is that adding new protocols and applications to the node cannot be made in a generic way. In order to obtain at least some level of context awareness, protocols and applications must be specifically tailored to intercommunicate. This also adds complexity to application and protocol design, since protocols and applications perform a wide range of tasks for which they have not originally been designed. To overcome these problems, we add a new Context Aware Management (CAM) layer to the Internet Protocol stack. The purpose of CAM is to optimize the functionality of the node by monitoring the environment for changes and by adapting the behavior of the node accordingly. The protocols and applications thus perform the tasks for which they have been designed in the first place, and CAM makes the decisions regarding which protocols to use and with what parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-candolin-cam-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-candolin-cam-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-candolin-cam-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020627133030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-candolin-cam-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-candolin-cam-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627133030.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg