Since, DDNS updates is still TBD, i don't = know, what=20 are the fields needed for FQDN option. Let us decide whether the client = or=20 server is doing dns updates. Then based on=20 that,we=20 can decide the fields on FQDN option. I feel that if we are = strictly moving=20 some=20 part or complete dns updates to client, we don't need one or both of the = RCODE*. Do correct me, if i am wrong.=20

Vijay:

I don't understand your desire to do DDNS updates = for=20 temporary addresses. We specifically do NOT want to do them. The -22 = draft=20 just says that if a server does DDNS updates, it must follow the rules = of RFC=20 3041.

I think you have things backwards a bit. = Non-temporary=20 addresses are the addresses that need domain names (FQDNs) assoicated = with=20 them. Temporary addresses really shouldn't since that defeats the = purpose of=20 temporary addresses. However, what RFC 3041 says, is that if DDNS = updates are=20 done, the name should be something that doesn't identify the client. = It gives=20 one reason for doing this and that is to keep applications happy that=20 "authenticate" clients by doing a reverse and then forward lookup to = assure=20 the client is in DNS.

We need a general FQDN option. Where it is placed = (encapulated within=20 the option area of an IA Address option, inside the option area of an = IA=20 option, or outside IA options) determines its scope (to one address, = several=20 addresses, or all addresses). For temporary addresses, the scope = should be to=20 that one address (since even using the same name with two temporary = addresses=20 could leak information about the client).

So, I see no value in an option that is just for = temporary=20 addresses. We should define a FQDN option and use it whenever DDNS = updates are=20 done. The format should be defined as in = draft-ietf-dhc-fqdn-option-03.txt=20 with the following differences:

- a 16-bit option number/option length =
- "A" RRs replaced by "AAAA" RRs.
- = Name=20 encoding should be as per section 10 of the -22 draft on DNS encodings = (hence=20 we technically don't need the "E" bit in the flag field but I would = recommend=20 we simply specify it MUST always be set to allow common code to be = used on the=20 client and/or server).

------=_NextPart_000_000C_01C1A212.327E3ED0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sun Jan 20 14:21: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 OAA15041 for ; Sun, 20 Jan 2002 14:21:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24818 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 14:21:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24742; Sun, 20 Jan 2002 14:13:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24721 for ; Sun, 20 Jan 2002 14:13:45 -0500 (EST) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14961 for ; Sun, 20 Jan 2002 14:13:41 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel9.hp.com (Postfix) with ESMTP id 507AEE002D2 for ; Sun, 20 Jan 2002 14:13:13 -0500 (EST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id AAA26612; Mon, 21 Jan 2002 00:38:56 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: Cc: "Vijayabhaskar A K (E-mail)" Date: Mon, 21 Jan 2002 00:44:12 +0530 Message-ID: <001701c1a1e6$a5aca670$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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Error codes for Decline message 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 need error codes to be defined for Decline message. AddrInUse - Address already in use. Is there any other scenario for which the client can send decline message? Will the following scenarios contribute to decline message? - The lease time the client has got is not sufficient for it. - The client has asked for a prefix A. But the server's admin policy says that for that client assign address with prefix B and it does so. I think, a mere release is not enough for these above situations. This has to be notified to the admin to take corrective action. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sun Jan 20 16:20: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 QAA16328 for ; Sun, 20 Jan 2002 16:20:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27494 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 16:20:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27424; Sun, 20 Jan 2002 16:11:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27352 for ; Sun, 20 Jan 2002 16:11:52 -0500 (EST) Received: from quiet-like-a-panther.org (r140-248-dsl.sea.lightrealm.net [209.203.248.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16198 for ; Sun, 20 Jan 2002 16:11:46 -0500 (EST) Received: (qmail 16930 invoked by uid 511); 20 Jan 2002 21:11:13 -0000 Message-ID: <20020120211113.16929.qmail@quiet-like-a-panther.org> References: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705> In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705> From: Michael Johnston To: "Bernie Volz $EUD$" Cc: "'Jim Bound'" , dhcwg Date: Sun, 20 Jan 2002 21:11:13 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments 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 This would work for me. I do not really see a need for making VUID length a bit count versus an octet count, but it is just a shift away. %%michael Bernie Volz (EUD) writes: > What about considering a variable length field for this type and adding a 16-bit length to allow the length to be specified? That way, a vendor can use what they like. The server treats it as opaque anyway. > > So, in 11.3 we could change it to be: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VUID length (in bits) | VUID (variable length) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . VUID (variable length) | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . domain name (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > VUID length is the number of bits of the VUID. > > VUID is the VUID (of (VUID length + 7)/8 bytes). > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Sunday, January 20, 2002 12:52 PM > To: Michael Johnston > Cc: Bernie Volz (EUD); dhcwg > Subject: Re: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments > > > Infiniband spec uses 128 bit global UIDs too. I think it makes sense to > have a 128bit option but keep the 64bit too. If we can just add it as > another option which I think we can. But we don't want to hold up the > spec either. > > > /jim > > > On Sun, 20 Jan 2002, Michael Johnston wrote: > >> Bernie, >> >> Intel-ish systems are what I use the most, so my information is skewed in >> that direction. >> >> The UUIDs being used today are derived from the algorithm in this document: >> http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt >> >> Mechanisms for retrieving (and in many cases storing) the platform UUID from >> (to) non-volatile storage are included in (or with) most x86PC compatible >> laptop and desktop systems and all Intel Itanium workstations and servers. >> >> In order to get Microsoft WHQL or Intel WfM certification all systems with >> network boot support must contain or generate a valid platform UUID. >> >> EFI (Extensible Firmware Interface) also requires a platform UUID. >> >> >> %%michael >> >> >> Bernie Volz (EUD) writes: >> >> > Hi: >> > >> > If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). >> > >> > Do you or does anyone else have some good information about the what new systems are using for UUIDs? >> > >> > - Bernie Volz >> > >> > -----Original Message----- >> > From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org] >> > Sent: Saturday, January 19, 2002 3:00 PM >> > To: dhcwg >> > Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments >> > >> > >> > Gentles, >> > >> > For the DUID contents definition (Section 11): >> > >> > Would you be adverse to expanding the size of the VUID to 128 bits or >> > creating an additional type (4) for a 128 bit UUID? >> > >> > Reasoning: >> > >> > According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT >> > change over time...". From what I have seen, most new laptops, desktops & >> > workstations (especially those that come with network installed) already >> > contain, or have space reserved for, a 128 bit UUID that is intended to be >> > used to manage/track the system identity. Why have a vendor or IT assign >> > yet another ID number to the system. >> > >> > Using the link-layer address is also not a unique solution. Consider the >> > two cases of (1) laptops connecting to docking stations that contain network >> > adapters and (2) replacing defective or upgrading to new network adapters. >> > >> > >> > %%michael >> > >> > _______________________________________________ >> > 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 daemon@optimus.ietf.org Sun Jan 20 19:29: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 TAA17775 for ; Sun, 20 Jan 2002 19:29:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01913 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 19:29:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01815; Sun, 20 Jan 2002 19:23:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01792 for ; Sun, 20 Jan 2002 19:23:04 -0500 (EST) Received: from quiet-like-a-panther.org (r140-248-dsl.sea.lightrealm.net [209.203.248.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17735 for ; Sun, 20 Jan 2002 19:23:01 -0500 (EST) Received: (qmail 17649 invoked by uid 511); 21 Jan 2002 00:22:31 -0000 Message-ID: <20020121002231.17648.qmail@quiet-like-a-panther.org> From: Michael Johnston To: "dhcwg" Date: Mon, 21 Jan 2002 00:22:31 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Am I missing something? 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 There is no bootfile or TFTP server information in the DHCPv6 draft. Maybe this is intentional. Is there another mechanism that is to be used by network boot clients to locate image servers and download images? %%michael _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sun Jan 20 20:23: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 UAA18246 for ; Sun, 20 Jan 2002 20:23:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03671 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 20:24:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03459; Sun, 20 Jan 2002 20:16:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03431 for ; Sun, 20 Jan 2002 20:16:03 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18149 for ; Sun, 20 Jan 2002 20:15:57 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA01918; Sun, 20 Jan 2002 20:15:53 -0500 Date: Sun, 20 Jan 2002 20:15:53 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: Michael Johnston , dhcwg Subject: RE: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705> 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 Bernie, This is a good idea I think. /jim On Sun, 20 Jan 2002, Bernie Volz (EUD) wrote: > What about considering a variable length field for this type and adding a 16-bit length to allow the length to be specified? That way, a vendor can use what they like. The server treats it as opaque anyway. > > So, in 11.3 we could change it to be: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VUID length (in bits) | VUID (variable length) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . VUID (variable length) | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . domain name (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > VUID length is the number of bits of the VUID. > > VUID is the VUID (of (VUID length + 7)/8 bytes). > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Sunday, January 20, 2002 12:52 PM > To: Michael Johnston > Cc: Bernie Volz (EUD); dhcwg > Subject: Re: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments > > > Infiniband spec uses 128 bit global UIDs too. I think it makes sense to > have a 128bit option but keep the 64bit too. If we can just add it as > another option which I think we can. But we don't want to hold up the > spec either. > > > /jim > > > On Sun, 20 Jan 2002, Michael Johnston wrote: > > > Bernie, > > > > Intel-ish systems are what I use the most, so my information is skewed in > > that direction. > > > > The UUIDs being used today are derived from the algorithm in this document: > > http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt > > > > Mechanisms for retrieving (and in many cases storing) the platform UUID from > > (to) non-volatile storage are included in (or with) most x86PC compatible > > laptop and desktop systems and all Intel Itanium workstations and servers. > > > > In order to get Microsoft WHQL or Intel WfM certification all systems with > > network boot support must contain or generate a valid platform UUID. > > > > EFI (Extensible Firmware Interface) also requires a platform UUID. > > > > > > %%michael > > > > > > Bernie Volz (EUD) writes: > > > > > Hi: > > > > > > If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). > > > > > > Do you or does anyone else have some good information about the what new systems are using for UUIDs? > > > > > > - Bernie Volz > > > > > > -----Original Message----- > > > From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org] > > > Sent: Saturday, January 19, 2002 3:00 PM > > > To: dhcwg > > > Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments > > > > > > > > > Gentles, > > > > > > For the DUID contents definition (Section 11): > > > > > > Would you be adverse to expanding the size of the VUID to 128 bits or > > > creating an additional type (4) for a 128 bit UUID? > > > > > > Reasoning: > > > > > > According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT > > > change over time...". From what I have seen, most new laptops, desktops & > > > workstations (especially those that come with network installed) already > > > contain, or have space reserved for, a 128 bit UUID that is intended to be > > > used to manage/track the system identity. Why have a vendor or IT assign > > > yet another ID number to the system. > > > > > > Using the link-layer address is also not a unique solution. Consider the > > > two cases of (1) laptops connecting to docking stations that contain network > > > adapters and (2) replacing defective or upgrading to new network adapters. > > > > > > > > > %%michael > > > > > > _______________________________________________ > > > 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 daemon@optimus.ietf.org Sun Jan 20 20:27:01 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 UAA18270 for ; Sun, 20 Jan 2002 20:27:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03731 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 20:27:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03607; Sun, 20 Jan 2002 20:22:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03576 for ; Sun, 20 Jan 2002 20:22:10 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18214 for ; Sun, 20 Jan 2002 20:22:04 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06468; Sun, 20 Jan 2002 20:20:12 -0500 Date: Sun, 20 Jan 2002 20:20:12 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: "'Vijay Bhaskar A K'" , mjs@cisco.com, dhcwg@ietf.org Subject: RE: [dhcwg] additional option for dhcpv6 In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC6@EAMBUNT705> 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 Folks, I have mixed feelings. I see Vijay's point but I also agree with Bernie. I suggest we not in DHC6 try to resolve the rules for DDNS and just make sure we have mechanism to permit DHC6 process FQDN's. Temp addr RFC 3041, DDSN, and FQDN DHC specs define the rules and interoperability issues. I suggest we not try to do that in DHC6. /jim On Sun, 20 Jan 2002, Bernie Volz (EUD) wrote: > Vijay: > > I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041. > > I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. > > We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client). > > So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences: > - a 16-bit option number/option length > - "A" RRs replaced by "AAAA" RRs. > - Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server). > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Sunday, January 20, 2002 9:34 AM > To: mjs@cisco.com > Cc: vijayak@india.hp.com; dhcwg@ietf.org > Subject: Re: [dhcwg] additional option for dhcpv6 > > > Mark, > > Thanks for your thorough review. See my comments inline. > > ~ Vijay > > > 1) The FQDN option needs, I think, to look a lot like the FQDN option for > > dhcpv4. > > The option i defined here is, for just transfering the FQDN releated to > temporary address. It is similar to hostname option in DHCPv4. I > will rename it to hostname option. I feel like, since the DDNS updates > are still TBD, we can define the FQDN option with appropriate fields > needed later, once DDNS specs are finalised. > > > The name encoding must be specified. > > Yes. It is needed. I will add the appropriate text. > > > There needs to be > > specification about hosts who do not initially know their entire fqdn. > > There needs to be a way to communicate about which party (if any) will be > > updating DNS. It's probably on my plate to produce that, actually. > > For the temporary addresses, DNS update is done by server. So, these > fields are not necessary. > > > > > 2) The subnet-selection option text should not compel the server to somehow > > obey the client's suggestion. It should be explict that the server > > administrator's configuration takes precedence, and that the client's > > indication that it desires a specific subnet can only be a hint that's > > considered along with all of the other information available to the server. > > This is the only way the client can tell its prefernce for the prefix. > If the server is not supposed to allocate address for that prefix, then > it wont. If the client is not very particular about the prefix, it > should not use this option. This option will be more helpful in the > network with two prefixes and the client wants a particular one. > > > > > A nit: isn't the option-len sufficient to determine the prefix length? Is > > the prefix-len byte necessary? > > No, it is not sufficient. Without the prefix-len field, you cannot find > out the exact prefix length. For example, you can identify whether the > prefix length is between 57 and 64. You cannot find out the exact > prefix length. > > > > > 3) The encoding for the domain names in the NIS and NIS+ Domain Name > > options should be DNS encoding, shouldn't it? That seems more robust than > > ASCII to me. > > Agreed. > > > > > 4) The 'Service Location Protocol Directory Agent Option' places the > > 'typed-scope-list-len' field before the 'DA address', rather than before > > the 'typed scope list'. Couldn't the length of the list immediately precede > > the list? > > I think, it won't make any difference. Let me know, if there are any > serious issues on this. > > > _______________________________________________ > 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 daemon@optimus.ietf.org Sun Jan 20 20:37: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 UAA18411 for ; Sun, 20 Jan 2002 20:37:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04337 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 20:37:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04228; Sun, 20 Jan 2002 20:31:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04189 for ; Sun, 20 Jan 2002 20:31:08 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18341 for ; Sun, 20 Jan 2002 20:31:04 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA10488; Sun, 20 Jan 2002 20:29:50 -0500 Date: Sun, 20 Jan 2002 20:29:50 -0500 (EST) From: Jim Bound To: Vijayabhaskar A K Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Error codes for Decline message In-Reply-To: <001701c1a1e6$a5aca670$2f290a0f@india.hp.com> 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 Vijay, Your ahead of us with hands on code for dhc6. And thanks for putting it in the public domain that was very nice. We are trying to get to PS. I suggest that we will find more needed error codes once we begin more implementations and more error codes. Right now I believe we have the generic onces to to resolve a response for all errors trying to extrapolate the possibilities from the spec without writing the code myself. So I think adding a new code before PS as you have found as bonifided implementor is good. But I caution the WG positively to not head down all these paths we will find many new pieces we need from more implementation and getting to PS is important so other folks are not implementing specs 3 revs behind as it has engineering cost and thats part of our job in the IETF is to keep that to a minimum in our work for the folks that write code. /jim On Mon, 21 Jan 2002, Vijayabhaskar A K wrote: > We need error codes to be defined for Decline message. > AddrInUse - Address already in use. > Is there any other scenario for which the client can > send decline message? > Will the following scenarios contribute to decline message? > - The lease time the client has got is not sufficient for it. > - The client has asked for a prefix A. But the server's > admin policy says that for that client assign address > with prefix B and it does so. > I think, a mere release is not enough for these above > situations. This has to be notified to the admin to take > corrective action. > > _______________________________________________ > 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 daemon@optimus.ietf.org Sun Jan 20 20:47: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 UAA18517 for ; Sun, 20 Jan 2002 20:47:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04580 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 20:47:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04412; Sun, 20 Jan 2002 20:39:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04382 for ; Sun, 20 Jan 2002 20:39:42 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18442 for ; Sun, 20 Jan 2002 20:39:38 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA12138; Sun, 20 Jan 2002 20:39:39 -0500 Date: Sun, 20 Jan 2002 20:39:39 -0500 (EST) From: Jim Bound To: Michael Johnston Cc: dhcwg Subject: Re: [dhcwg] Am I missing something? In-Reply-To: <20020121002231.17648.qmail@quiet-like-a-panther.org> 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 Michael, This as a note showed up in some work I did for Infinband engineers who chose IPv6 as the address to do that DL/API layer. We may need an option for a path to the boot file image but the approach we took for AD proto code was as follows (back at about draft 15 with mini dhc6 code base) Use dhc6 to find the SLP server. Use SLP protocol and servers to find the image file. So the question is with dhc6 is this the job of SLP now as we have transfered other things to SLP within the thinking model of dhc6? Also most server vendors that will build dhc6 will have SLP for IPv6 too? /jim On Mon, 21 Jan 2002, Michael Johnston wrote: > There is no bootfile or TFTP server information in the DHCPv6 draft. Maybe > this is intentional. Is there another mechanism that is to be used by > network boot clients to locate image servers and download images? > > %%michael > > _______________________________________________ > 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 daemon@optimus.ietf.org Sun Jan 20 20: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 UAA18545 for ; Sun, 20 Jan 2002 20:50:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04624 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 20:50:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04504; Sun, 20 Jan 2002 20:42:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04486 for ; Sun, 20 Jan 2002 20:42:30 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18482 for ; Sun, 20 Jan 2002 20:42:23 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06438; Sun, 20 Jan 2002 20:41:01 -0500 Date: Sun, 20 Jan 2002 20:41:01 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: "'Vijay Bhaskar A K'" , mjs@cisco.com, dhcwg@ietf.org Subject: RE: [dhcwg] additional option for dhcpv6 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 whoops meant DDNS not DDSN below. .jim /jim On Sun, 20 Jan 2002, Jim Bound wrote: > Folks, > > I have mixed feelings. I see Vijay's point but I also agree with Bernie. > I suggest we not in DHC6 try to resolve the rules for DDNS and just make > sure we have mechanism to permit DHC6 process FQDN's. Temp addr RFC > 3041, DDSN, and FQDN DHC specs define the rules and interoperability > issues. I suggest we not try to do that in DHC6. > > > /jim > > > On Sun, 20 Jan 2002, Bernie Volz (EUD) wrote: > > > Vijay: > > > > I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041. > > > > I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. > > > > We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client). > > > > So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences: > > - a 16-bit option number/option length > > - "A" RRs replaced by "AAAA" RRs. > > - Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server). > > > > - Bernie > > > > -----Original Message----- > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > Sent: Sunday, January 20, 2002 9:34 AM > > To: mjs@cisco.com > > Cc: vijayak@india.hp.com; dhcwg@ietf.org > > Subject: Re: [dhcwg] additional option for dhcpv6 > > > > > > Mark, > > > > Thanks for your thorough review. See my comments inline. > > > > ~ Vijay > > > > > 1) The FQDN option needs, I think, to look a lot like the FQDN option for > > > dhcpv4. > > > > The option i defined here is, for just transfering the FQDN releated to > > temporary address. It is similar to hostname option in DHCPv4. I > > will rename it to hostname option. I feel like, since the DDNS updates > > are still TBD, we can define the FQDN option with appropriate fields > > needed later, once DDNS specs are finalised. > > > > > The name encoding must be specified. > > > > Yes. It is needed. I will add the appropriate text. > > > > > There needs to be > > > specification about hosts who do not initially know their entire fqdn. > > > There needs to be a way to communicate about which party (if any) will be > > > updating DNS. It's probably on my plate to produce that, actually. > > > > For the temporary addresses, DNS update is done by server. So, these > > fields are not necessary. > > > > > > > > 2) The subnet-selection option text should not compel the server to somehow > > > obey the client's suggestion. It should be explict that the server > > > administrator's configuration takes precedence, and that the client's > > > indication that it desires a specific subnet can only be a hint that's > > > considered along with all of the other information available to the server. > > > > This is the only way the client can tell its prefernce for the prefix. > > If the server is not supposed to allocate address for that prefix, then > > it wont. If the client is not very particular about the prefix, it > > should not use this option. This option will be more helpful in the > > network with two prefixes and the client wants a particular one. > > > > > > > > A nit: isn't the option-len sufficient to determine the prefix length? Is > > > the prefix-len byte necessary? > > > > No, it is not sufficient. Without the prefix-len field, you cannot find > > out the exact prefix length. For example, you can identify whether the > > prefix length is between 57 and 64. You cannot find out the exact > > prefix length. > > > > > > > > 3) The encoding for the domain names in the NIS and NIS+ Domain Name > > > options should be DNS encoding, shouldn't it? That seems more robust than > > > ASCII to me. > > > > Agreed.. > > > > > > > > 4) The 'Service Location Protocol Directory Agent Option' places the > > > 'typed-scope-list-len' field before the 'DA address', rather than before > > > the 'typed scope list'. Couldn't the length of the list immediately precede > > > the list? > > > > I think, it won't make any difference. Let me know, if there are any > > serious issues on this. > > > > > > _______________________________________________ > > 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 daemon@optimus.ietf.org Mon Jan 21 02:37: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 CAA02168 for ; Mon, 21 Jan 2002 02:37:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA23988 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 02:37:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23423; Mon, 21 Jan 2002 02:29:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23347 for ; Mon, 21 Jan 2002 02:29:07 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02001 for ; Mon, 21 Jan 2002 02:29:03 -0500 (EST) 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 g0L7SaS09076 for ; Mon, 21 Jan 2002 01:28:36 -0600 (CST) 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 g0L7Saf06140 for ; Mon, 21 Jan 2002 01:28:36 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jan 21 01:28:35 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 01:28:34 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC9@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Comments on 22 rev of the draft Date: Mon, 21 Jan 2002 01:28:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A24D.3B39A6A0" 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_01C1A24D.3B39A6A0 Content-Type: text/plain; charset="iso-8859-1" Vijay: How a client determines it has (possibly) moved to a new link is a client issue. If you're using wired Ethernet, the client can easily detect when the cable is disconnected/reconnected. If a client powers on (from Standby, etc), it should assume it MAY have moved to a new link and Confirm. The DHCP server, as in IPv4, needs complete network configuration information. If you don't provide it all of the information it needs to operate, it will not be able to service clients successfully. This is true in IPv4 today and if you have multiple prefixes active on a single link, you need to tell the DHCP server this. See below (prefixed by BV4>). - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Sunday, January 20, 2002 1:15 PM To: 'Bernie Volz (EUD)' Cc: dhcwg@ietf.org; vijayak@india.hp.com Subject: RE: [dhcwg] Comments on 22 rev of the draft Hi Bernie, See my reply inline prefixed by VB3> BV3> You are forgetting ONE case ... what if the client was allowed to unicast to the server. In that case, we really do need to use the address supplied by the client as that is the only way the server can determine were the client is. VB3> This is where the problem arises. If the client network has two prefixes, 3ffe::/64 and 5ffe::/64 and the client wants the address with 3ffe::/64 prefix, it has not the flexibility of choosing the source address. The source address selection algorithm may choose any address. It is based on the destination address. If the destination address (server addr) is 5ffe::/64, then the source address selection chooses the source address from 5ffe::/64 only. So, the subnet selection option is the only way of indicating the client's wish of the prefix. And you are not considering the rules for the source address that the client is supposed to be using. So, if we assume clients are playing by the rules (which they MUST IMHO), you have the following possibilities: 1) The client is communicating via a relay agent. In that case things are easy since the server receives a Reply-Forw. 2) The client is on the local link (and NOT unicasting), in that case the client's address MUST be the link-local address and the server uses the interface on which the request was received. 3) The client is UNICASTING because the server has allowed it to do so. In that case, the server MUST use the client's source address to determine the address. The client MUST also use a source address that is of sufficient scope to reach the server. Ideally, this should be a global address as that avoids any issues with the client moving to a new link (since global addresses are "valid" anywhere). VB3> I am sure that global address is unique over the world, but i am not sure, whether it is valid anywhere. I am not sure, whether the host with subnet preifx 3ffe::/64 moved to 5ffe::/64, will be able to receive the packet with destined to its 3ffe::/64 address. BV4> The client has to Confirm the address when it detects that it may have moved. In this case you also don't have any problems because if the client has moved to a new link, it should be sending a CONFIRM which is *NOT* unicast. VB3> Regarding the confirm, i have few doubts. - draft says that, when the client moves to new link, it has to send confirm message. How can the host identify it has moved to a new network? Are we taking care of ICMP error messages? BV4> See above. - Link local address is unique within the link. When a node is moved from one link to another one, we cannot surely say that the link local address is unique. What will happen, the link local address of the interface is used by some other node in that link? BV4> How the link local address is determined is controlled by Stateless Autoconfiguration. If a client believes the link has changed, it should take steps to make sure that the link-local address it wants to use (was using) is still valid and not duplicated. - since, this address is the one, which has to be used as source address for confirm, does the client has to do a ND first for confirming uniqueness within the link? BV4> Only a valid link local address (per stateless autoconfiguration) may be used. VB3> As i told earlier, a text has to be added for checking whether the addresses in the IA has the same prefix as that of the link it resides, when confirm message is received in the server. Otherwise, the confirm will get a positive reply from the server, resulting in defeat of the purpose of confirm. VB3> Here, i have another doubt. Assume the following scenario. Assume the Relay agent has addresses from two prefix A and B in the link attached to the client. Client has some addresses of prefix A. It has been rebooted now. So, it sends the confirm packet. The confirm is received in the relay agent's interface. Now, what prefix it has to put in the link-address field. If it chooses to put B, then the addresses assigned to client becomes invalid. In what basis, the Relay agent chooses the prefixes, if the interface attached to the client's link has more than one prefixes? BV4> You have misconfigured your DHCP environment. Fix the configuration so that either the relay always supplies the correct prefix or configure the DHCPv6 server to know about both prefixes. ------_=_NextPart_001_01C1A24D.3B39A6A0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Comments on 22 rev of the draft

Vijay:

How a client determines it has (possibly) moved to a new link is a client issue. If you're using wired Ethernet, the client can easily detect when the cable is disconnected/reconnected. If a client powers on (from Standby, etc), it should assume it MAY have moved to a new link and Confirm.

The DHCP server, as in IPv4, needs complete network configuration information. If you don't provide it all of the information it needs to operate, it will not be able to service clients successfully. This is true in IPv4 today and if you have multiple prefixes active on a single link, you need to tell the DHCP server this.

See below (prefixed by BV4>).

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Sunday, January 20, 2002 1:15 PM
To: 'Bernie Volz (EUD)'
Cc: dhcwg@ietf.org; vijayak@india.hp.com
Subject: RE: [dhcwg] Comments on 22 rev of the draft

Hi Bernie,

See my reply inline prefixed by VB3>

BV3> You are forgetting ONE case ... what if the client was allowed to
unicast to the server. In that case, we really do need to use the address
supplied by the client as that is the only way the server can determine
were the client is.

VB3> This is where the problem arises. If the client network

has two prefixes, 3ffe::/64 and 5ffe::/64 and the client wants

the address with 3ffe::/64 prefix, it has not the flexibility of

choosing the source address. The source address selection

algorithm may choose any address. It is based on the destination

address. If the destination address (server addr) is 5ffe::/64,

then the source address selection chooses the source address

from 5ffe::/64 only. So, the subnet selection option is the only

way of indicating the client's wish of the prefix.

And you are not considering the rules for the source address that the
client is supposed to be using. So, if we assume clients are playing by
the rules (which they MUST IMHO), you have the following possibilities:
1) The client is communicating via a relay agent. In that case things are
easy since the server receives a Reply-Forw.
2) The client is on the local link (and NOT unicasting), in that case
the client's address MUST be the link-local address and the server uses
the interface on which the request was received.
3) The client is UNICASTING because the server has allowed it to do so.
In that case, the server MUST use the client's source address to determine
the address. The client MUST also use a source address that is of sufficient
scope to reach the server. Ideally, this should be a global address as that
avoids any issues with the client moving to a new link (since global addresses
are "valid" anywhere).

VB3> I am sure that global address is unique over the world, but i am not sure,

whether it is valid anywhere. I am not sure, whether the host with

subnet preifx 3ffe::/64 moved to 5ffe::/64, will be able to receive the

packet with destined to its 3ffe::/64 address.

BV4> The client has to Confirm the address when it detects that it may have moved.

In this case you also don't have any problems because
if the client has moved to a new link, it should be sending a CONFIRM which
is *NOT* unicast.

VB3> Regarding the confirm, i have few doubts.

- draft says that, when the client moves to new link, it has to send confirm

message. How can the host identify it has moved to a new network?

Are we taking care of ICMP error messages?

BV4> See above.

- Link local address is unique within the link. When a node is moved

from one link to another one, we cannot surely say that the link local

address is unique. What will happen, the link local address of the

interface is used by some other node in that link?

BV4> How the link local address is determined is controlled by Stateless Autoconfiguration.

If a client believes the link has changed, it should take steps to make sure that the link-local

address it wants to use (was using) is still valid and not duplicated.

- since, this address is the one, which has to be used as source address for confirm,

does the client has to do a ND first for confirming uniqueness within the link?

BV4> Only a valid link local address (per stateless autoconfiguration) may be used.

VB3> As i told earlier, a text has to be added for checking whether the addresses

in the IA has the same prefix as that of the link it resides, when confirm message

is received in the server. Otherwise, the confirm will get a positive reply from the

server, resulting in defeat of the purpose of confirm.

VB3> Here, i have another doubt. Assume the following scenario.

Assume the Relay agent has addresses from two prefix A and B

in the link attached to the client. Client has some addresses of

prefix A. It has been rebooted now. So, it sends the confirm packet.

The confirm is received in the relay agent's interface. Now, what

prefix it has to put in the link-address field. If it chooses to put B,

then the addresses assigned to client becomes invalid. In what

basis, the Relay agent chooses the prefixes, if the interface

attached to the client's link has more than one prefixes?

BV4> You have misconfigured your DHCP environment. Fix the configuration so that either

the relay always supplies the correct prefix or configure the DHCPv6 server to know about

both prefixes.

------_=_NextPart_001_01C1A24D.3B39A6A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Jan 21 02:47:54 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 CAA02289 for ; Mon, 21 Jan 2002 02:47:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA24201 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 02:47:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24029; Mon, 21 Jan 2002 02:38:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24004 for ; Mon, 21 Jan 2002 02:38:11 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02183 for ; Mon, 21 Jan 2002 02:38:07 -0500 (EST) 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 g0L7beS09653 for ; Mon, 21 Jan 2002 01:37:40 -0600 (CST) 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 g0L7bef06997 for ; Mon, 21 Jan 2002 01:37:40 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Jan 21 01:37:39 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 01:37:39 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDCA@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , mjs@cisco.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] additional option for dhcpv6 Date: Mon, 21 Jan 2002 01:37:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A24E.80B8D470" 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_01C1A24E.80B8D470 Content-Type: text/plain; charset="iso-8859-1" My feeling is that we should follow the work being done in DHCPv4 in this area (FQDN) as defined by draft-ietf-dhc-fqdn-option-03.txt. Whether we also have a host name option is still TBD - I believe Carl Smith and Ted Lemon will be working up some text for DHCPv4 and it would be good to wait until we have some clear definitions around proper behavior and interactions between the host name, domain name, and FQDN options. Unless there are some significant reasons to defer from DHCPv4 options, I would recommend using the DHCPv4 options as closely as possible. We have a lot of experience with those options already! - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Sunday, January 20, 2002 1:56 PM To: 'Bernie Volz (EUD)'; mjs@cisco.com Cc: dhcwg@ietf.org; Vijayabhaskar A K (E-mail) Subject: RE: [dhcwg] additional option for dhcpv6 Bernie, I didn't talked anything about DDNS updates for temporary addresses. What i have defined is similar one like "hostname" option (option 12) in DHCPv4. It has the same functionality as option 12 in DHCPv4. If there is any FQDN related to address assigned, i wanted an option that informs the FQDN to client. This can be used for transfering hostnames/FQDN from client to server and vise versa. This holds for both normal addresses and temp addresses also. It is just a "hostname" option not an FQDN option. Since, DDNS updates is still TBD, i don't know, what are the fields needed for FQDN option. Let us decide whether the client or server is doing dns updates. Then based on that,we can decide the fields on FQDN option. I feel that if we are strictly moving some part or complete dns updates to client, we don't need one or both of the RCODE*. Do correct me, if i am wrong. Vijay: I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041. I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client). So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences: - a 16-bit option number/option length - "A" RRs replaced by "AAAA" RRs. - Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server). ------_=_NextPart_001_01C1A24E.80B8D470 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] additional option for dhcpv6

My feeling is that we should follow the work being done in DHCPv4 in this area (FQDN) as defined by draft-ietf-dhc-fqdn-option-03.txt. Whether we also have a host name option is still TBD - I believe Carl Smith and Ted Lemon will be working up some text for DHCPv4 and it would be good to wait until we have some clear definitions around proper behavior and interactions between the host name, domain name, and FQDN options. Unless there are some significant reasons to defer from DHCPv4 options, I would recommend using the DHCPv4 options as closely as possible. We have a lot of experience with those options already!

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Sunday, January 20, 2002 1:56 PM
To: 'Bernie Volz (EUD)'; mjs@cisco.com
Cc: dhcwg@ietf.org; Vijayabhaskar A K (E-mail)
Subject: RE: [dhcwg] additional option for dhcpv6

Bernie,

I didn't talked anything about DDNS updates for temporary addresses. What i have defined is similar one like "hostname" option (option 12) in DHCPv4. It has the same functionality as option 12 in DHCPv4. If there is any FQDN related to address assigned, i wanted an option that informs the FQDN to client. This can be used for transfering hostnames/FQDN from client to server and vise versa. This holds for both normal addresses and temp addresses also. It is just a "hostname" option not an FQDN option.

Since, DDNS updates is still TBD, i don't know, what are the fields needed for FQDN option. Let us decide whether the client or server is doing dns updates. Then based on that,we can decide the fields on FQDN option. I feel that if we are strictly moving some part or complete dns updates to client, we don't need one or both of the RCODE*. Do correct me, if i am wrong.

Vijay:

I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041.

I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS.

We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client).

So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences:

- a 16-bit option number/option length
- "A" RRs replaced by "AAAA" RRs.
- Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server).

------_=_NextPart_001_01C1A24E.80B8D470-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Jan 21 02:54:05 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 CAA02331 for ; Mon, 21 Jan 2002 02:54:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA24335 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 02:54:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24157; Mon, 21 Jan 2002 02:45:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24131 for ; Mon, 21 Jan 2002 02:45:11 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02249 for ; Mon, 21 Jan 2002 02:45:07 -0500 (EST) 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 g0L7jAh03688 for ; Mon, 21 Jan 2002 01:45:10 -0600 (CST) 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 g0L7jAf07686 for ; Mon, 21 Jan 2002 01:45:10 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jan 21 01:45:09 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 01:45:09 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDCB@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Jim Bound'" , Vijayabhaskar A K Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Error codes for Decline message Date: Mon, 21 Jan 2002 01:45:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A24F.8C378750" 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_01C1A24F.8C378750 Content-Type: text/plain; charset="iso-8859-1" I agree with Jim (we may want to add some additional error codes down the road). At one point in the discussions, we were about to abandon all error codes and simply have a success / failure indication. So, please think minimal error codes! I don't agree with Vijay's position that the two instances given are Decline cases. They should instead result in Releases (if a client doesn't want an address the server gave it, it should Release it). Also, other than for "logging", I don't believe the server really cares. Decline says to basically "Abandon" the address as it appears to be in use by a system already when it should not be. Release says just to release the addresses and place them back into the available pool of addresses. The status codes don't change the processing, IMHO. You don't even need to set them to specific values (the error codes are more for server to client communication in Reply's, IMHO). - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Sunday, January 20, 2002 8:30 PM To: Vijayabhaskar A K Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Error codes for Decline message Hi Vijay, Your ahead of us with hands on code for dhc6. And thanks for putting it in the public domain that was very nice. We are trying to get to PS. I suggest that we will find more needed error codes once we begin more implementations and more error codes. Right now I believe we have the generic onces to to resolve a response for all errors trying to extrapolate the possibilities from the spec without writing the code myself. So I think adding a new code before PS as you have found as bonifided implementor is good. But I caution the WG positively to not head down all these paths we will find many new pieces we need from more implementation and getting to PS is important so other folks are not implementing specs 3 revs behind as it has engineering cost and thats part of our job in the IETF is to keep that to a minimum in our work for the folks that write code. /jim On Mon, 21 Jan 2002, Vijayabhaskar A K wrote: > We need error codes to be defined for Decline message. > AddrInUse - Address already in use. > Is there any other scenario for which the client can > send decline message? > Will the following scenarios contribute to decline message? > - The lease time the client has got is not sufficient for it. > - The client has asked for a prefix A. But the server's > admin policy says that for that client assign address > with prefix B and it does so. > I think, a mere release is not enough for these above > situations. This has to be notified to the admin to take > corrective action. > > _______________________________________________ > 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_01C1A24F.8C378750 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Error codes for Decline message

I agree with Jim (we may want to add some additional error codes down the road).
At one point in the discussions, we were about to abandon all error codes and
simply have a success / failure indication. So, please think minimal error codes!

I don't agree with Vijay's position that the two instances given are Decline
cases. They should instead result in Releases (if a client doesn't want an address
the server gave it, it should Release it).

Also, other than for "logging", I don't believe the server really cares. Decline
says to basically "Abandon" the address as it appears to be in use by a system
already when it should not be.

Release says just to release the addresses and place them back into the available
pool of addresses.

The status codes don't change the processing, IMHO. You don't even need to set
them to specific values (the error codes are more for server to client communication
in Reply's, IMHO).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Sunday, January 20, 2002 8:30 PM
To: Vijayabhaskar A K
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Error codes for Decline message

Hi Vijay,

Your ahead of us with hands on code for dhc6. And thanks for putting it
in the public domain that was very nice. We are trying to get to PS. I
suggest that we will find more needed error codes once we begin more
implementations and more error codes. Right now I believe we have the
generic onces to to resolve a response for all errors trying to
extrapolate the possibilities from the spec without writing the code
myself. So I think adding a new code before PS as you have found as
bonifided implementor is good. But I caution the WG positively to not
head down all these paths we will find many new pieces we need from more
implementation and getting to PS is important so other folks are not
implementing specs 3 revs behind as it has engineering cost and thats part
of our job in the IETF is to keep that to a minimum in our work for the
folks that write code.

/jim

On Mon, 21 Jan 2002, Vijayabhaskar A K wrote:

> We need error codes to be defined for Decline message.
> AddrInUse - Address already in use.
> Is there any other scenario for which the client can
> send decline message?
> Will the following scenarios contribute to decline message?
> - The lease time the client has got is not sufficient for it.
> - The client has asked for a prefix A. But the server's
> admin policy says that for that client assign address
> with prefix B and it does so.
> I think, a mere release is not enough for these above
> situations. This has to be notified to the admin to take
> corrective action.
>
> _______________________________________________
> 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_01C1A24F.8C378750-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Jan 21 03:37: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 DAA02766 for ; Mon, 21 Jan 2002 03:37:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26069 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 03:37:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25489; Mon, 21 Jan 2002 03:28:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25462 for ; Mon, 21 Jan 2002 03:28:06 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02652 for ; Mon, 21 Jan 2002 03:28:02 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0L8RGH81290; Mon, 21 Jan 2002 09:27:17 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 68309C05B; Mon, 21 Jan 2002 09:26:41 +0100 (CET) Date: Mon, 21 Jan 2002 09:26:41 +0100 From: Martin Stiemerling To: John Schnizlein , vijayak@india.hp.com Cc: "'Jim Bound'" , dhcwg@ietf.org Subject: RE: [dhcwg] static route option for dhcpv6 Message-ID: <11550000.1011601601@elgar> In-Reply-To: <4.3.2.7.2.20020118151943.01892130@diablo.cisco.com> References: <8140000.1011342023@elgar> <4.3.2.7.2.20020118151943.01892130@diablo.cisco.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --On Freitag, Januar 18, 2002 15:22:36 -0500 John Schnizlein wrote: > At 01:05 PM 1/18/2002, Vijayabhaskar A K wrote: > >> Please note that, there are no routers in the networks. That's why >> i mentioned that node as the one conneceted to two network and having >> ipv6forwarding enabled, instead of routers. This is for the networks >> which have not deployed IPv6 routing completely. I think there is no >> harm in having this option. > > If the purpose of the option is to enable situations where hosts > have ipv6forwarding enabled, but do not act as proper v6 routers, > then we should not support it. That is just bad practice. (IMHO) I totaly agree with this. > The use for tunnelling might be justifiable. This is, what I have mentioned some emails before. Give the child the proper name and it is OK. Martin > > John > > > _______________________________________________ > 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 daemon@optimus.ietf.org Mon Jan 21 09:54: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 JAA11132 for ; Mon, 21 Jan 2002 09:54:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10051 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 09:54:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09764; Mon, 21 Jan 2002 09:43:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09742 for ; Mon, 21 Jan 2002 09:43:51 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10892 for ; Mon, 21 Jan 2002 09:43:48 -0500 (EST) Received: from goblet.cisco.com (mirapoint@goblet.cisco.com [161.44.168.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24010; Mon, 21 Jan 2002 09:43:21 -0500 (EST) Received: from MJS-PC.cisco.com (mjs-pc.cisco.com [172.27.181.69]) by goblet.cisco.com (Mirapoint) with ESMTP id AAM58926; Mon, 21 Jan 2002 09:43:21 -0500 (EST) Message-Id: <4.3.2.7.2.20020121092051.021d8468@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jan 2002 09:44:31 -0500 To: Vijay Bhaskar A K From: Mark Stapp Subject: Re: [dhcwg] additional option for dhcpv6 Cc: dhcwg@ietf.org In-Reply-To: <200201201434.UAA22474@dce.india.hp.com> References: <4.3.2.7.2.20020118165044.019a0ef0@goblet.cisco.com> 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 Vijay, 1) FQDN Option. I really think that we should use a single option that can convey both a complete FQDN or a partial 'hostname'. It's unnecessary to try to specify two options and the relationship between them. Certainly, there's no need to include the RCODE fields that were part of the v4 FQDN option: like the two name encodings in the v4 version, those fields were left in place because there was a large base of deployed clients who expected those fields to be present. I'd suggest that we specify the same method that's used in the v4 option to distinguish between fully-qualified and unqualified names: if the last label in the name field is null-length, the name is fully-qualified. If a client believes it knows a complete FQDN, it sends that name and terminates it accordingly. If it only knows a partial name, it sends the labels it knows. > There needs to be > specification about hosts who do not initially know their entire fqdn. > There needs to be a way to communicate about which party (if any) will be > updating DNS. It's probably on my plate to produce that, actually. >For the temporary addresses, DNS update is done by server. So, these >fields are not necessary. As I said, I think that DNS updates will be performed by different parties in different environments, just as they are in IP4 networks. The option must contain enough information to permit a network's administrators to influence the choice of updater for zones that are under their control. Like Bernie, I don't know what you mean here when you claim that no additional data is necessary. Your claim that temporary addresses' updates will be done by servers is a little confusing to me. Why do you assume that? You imply that non-temporary updates are clearly understood to be the responsibility of one party. I disagree: I think that the years of field experience we have demonstrates that there are a variety of valid dns update models. > > > > 2) The subnet-selection option text should not compel the server to > somehow > > obey the client's suggestion. It should be explict that the server > > administrator's configuration takes precedence, and that the client's > > indication that it desires a specific subnet can only be a hint that's > > considered along with all of the other information available to the server. > >This is the only way the client can tell its prefernce for the prefix. >If the server is not supposed to allocate address for that prefix, then >it wont. If the client is not very particular about the prefix, it >should not use this option. This option will be more helpful in the >network with two prefixes and the client wants a particular one. I think that the specification must be clear about the behavior that the paragraph in your reply describes. The server MAY consider the subnet specified as it considers the other information available to it about its allocation policies and about the client. > > > > 4) The 'Service Location Protocol Directory Agent Option' places the > > 'typed-scope-list-len' field before the 'DA address', rather than before > > the 'typed scope list'. Couldn't the length of the list immediately > precede > > the list? > >I think, it won't make any difference. Let me know, if there are any >serious issues on this. There are so many examples of the field len/field value convention that I think it's much clearer to continue using that convention unless there's a very good reason not to. I don't think that there is such a reason in this case, and I think that it will make the specification and implementation of this option more robust if we retain that convention. -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Jan 21 09:56: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 JAA11228 for ; Mon, 21 Jan 2002 09:56:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10152 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 09:56:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09824; Mon, 21 Jan 2002 09:47:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09805 for ; Mon, 21 Jan 2002 09:47:36 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10999 for ; Mon, 21 Jan 2002 09:47:33 -0500 (EST) Received: from goblet.cisco.com (mirapoint@goblet.cisco.com [161.44.168.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24334; Mon, 21 Jan 2002 09:47:06 -0500 (EST) Received: from MJS-PC.cisco.com (mjs-pc.cisco.com [172.27.181.69]) by goblet.cisco.com (Mirapoint) with ESMTP id AAM58968; Mon, 21 Jan 2002 09:47:05 -0500 (EST) Message-Id: <4.3.2.7.2.20020121094439.01942580@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jan 2002 09:48:09 -0500 To: Michael Johnston From: Mark Stapp Subject: Re: [dhcwg] Am I missing something? Cc: dhcwg In-Reply-To: References: <20020121002231.17648.qmail@quiet-like-a-panther.org> 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 Michael, I agree with you. I don't think that we should force our users to deploy and configure any additional protocols in order to locate their ftp servers. Those servers are a fundamental part of the boot process in some environments, and that's what DHCP is for, right? FTP and TFTP server options should be part of the base option set. -- Mark On Mon, 21 Jan 2002, Michael Johnston wrote: > > There is no bootfile or TFTP server information in the DHCPv6 > draft. Maybe > > this is intentional. Is there another mechanism that is to be used by > > network boot clients to locate image servers and download images? > > > > %%michael > > > > _______________________________________________ > > 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 daemon@optimus.ietf.org Mon Jan 21 10:47:10 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 KAA13079 for ; Mon, 21 Jan 2002 10:47:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13473 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 10:47:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13339; Mon, 21 Jan 2002 10:39:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13317 for ; Mon, 21 Jan 2002 10:39:57 -0500 (EST) Received: from firewall.agranat.com (agranat.com [198.113.147.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12813 for ; Mon, 21 Jan 2002 10:39:54 -0500 (EST) From: dworley@globespanvirata.com Received: from agranat.com (alice.agranat.com [10.21.0.130]) by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id KAA00981 for ; Mon, 21 Jan 2002 10:39:27 -0500 Received: from dhcp75.ma.virata.com (dhcp75.ma.virata.com [10.21.0.75]) by agranat.com (8.11.6/8.11.6) with ESMTP id g0LFdQQ07512 for ; Mon, 21 Jan 2002 10:39:26 -0500 Received: (from worley@localhost) by dhcp75.ma.virata.com (8.11.0/8.11.0) id g0LFdQU10176; Mon, 21 Jan 2002 10:39:26 -0500 Date: Mon, 21 Jan 2002 10:39:26 -0500 Message-Id: <200201211539.g0LFdQU10176@dhcp75.ma.virata.com> X-Authentication-Warning: dhcp75.ma.virata.com: worley set sender to dworley@globespanvirata.com using -f To: dhcwg@ietf.org In-reply-to: <4.3.2.7.2.20020121094439.01942580@goblet.cisco.com> (message from Mark Stapp on Mon, 21 Jan 2002 09:48:09 -0500) Subject: Re: [dhcwg] Am I missing something? References: <20020121002231.17648.qmail@quiet-like-a-panther.org> <4.3.2.7.2.20020121094439.01942580@goblet.cisco.com> X-Scanned-By: MIMEDefang 2.2 (www dot roaringpenguin dot com slash mimedefang) 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: Mark Stapp I agree with you. I don't think that we should force our users to deploy and configure any additional protocols in order to locate their ftp servers. Those servers are a fundamental part of the boot process in some environments, and that's what DHCP is for, right? FTP and TFTP server options should be part of the base option set. I'm not that familiar with DHCP usage, but my belief is that the most common use for DHCP is distributing IPv4 addresses, and the second-most-common use is for distributing TFTP addresses and file names for fetching boot images. If so, we would need a very strong reason for eliminating the FTP server options. Also, if the DHCP FTP server information is to be distributed by another mechanism, we must ensure that existing boot ROMs will be able to hold the code for the additional mechanism. If not, a vendor will recreate the FTP server options as a vendor-specific option, and 1,000 other vendors will copy it. Dale -- Dale R. WORLEY Director, ABU Engineering GlobespanVirata Applications Infrastructure http://emweb.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Jan 21 14:29:20 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 OAA21167 for ; Mon, 21 Jan 2002 14:29:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24100 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 14:29:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23837; Mon, 21 Jan 2002 14:19:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23811 for ; Mon, 21 Jan 2002 14:19:45 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20647 for ; Mon, 21 Jan 2002 14:19:36 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01776 for ; Mon, 21 Jan 2002 14:19:09 -0500 (EST) Message-Id: <4.3.2.7.2.20020121141605.032339d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jan 2002 14:19:36 -0500 To: "dhcwg" From: Ralph Droms Subject: Re: [dhcwg] Am I missing something? In-Reply-To: <20020121002231.17648.qmail@quiet-like-a-panther.org> 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 We've taken an "on-demand" approach to adding options to DHCPv6 - that is, as options are requested, we've added them. There hasn't been any intentional oversight; to avoid carrying forward unnecessary options (e.g., "Impress server"), we've simply started with a clean (or almost clean) slate. 'bootfile' and 'TFTP server' seem like good candidates for inclusion in DHCPv6. For WG discussion - should the 'bootfile' and 'TFTP server' options be carried over verbatim to DHCPv6 or are there changes that should be made? - Ralph At 12:22 AM 1/21/2002 +0000, Michael Johnston wrote: >There is no bootfile or TFTP server information in the DHCPv6 >draft. Maybe this is intentional. Is there another mechanism that is to >be used by network boot clients to locate image servers and download images? > >%%michael >_______________________________________________ >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 daemon@optimus.ietf.org Mon Jan 21 15:04:18 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 PAA22248 for ; Mon, 21 Jan 2002 15:04:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25452 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 15:04:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24908; Mon, 21 Jan 2002 14:57:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24887 for ; Mon, 21 Jan 2002 14:57:35 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22052 for ; Mon, 21 Jan 2002 14:57:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05939; Mon, 21 Jan 2002 14:53:22 -0500 (EST) Message-Id: <4.3.2.7.2.20020121144941.0324ff90@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jan 2002 14:53:49 -0500 To: Vijay Bhaskar A K From: Ralph Droms Subject: Re: [dhcwg] Comments on 22 rev of the draft Cc: Bernie.Volz@am1.ericsson.se, vijayak@india.hp.com, Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org In-Reply-To: <200201181738.XAA16245@dce.india.hp.com> References: <66F66129A77AD411B76200508B65AC69B4CDB4@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 At 11:08 PM 1/18/2002 +0530, Vijay Bhaskar A K wrote: >Bernie, > >See my comments prefixed by VB2> > >~ Vijay > > > Vijay, see BV2> comments. > > > > - Bernie > > > > -----Original Message----- > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > Sent: Thursday, January 17, 2002 4:35 AM > > To: Bernie.Volz@am1.ericsson.se > > Cc: vijayak@india.hp.com; dhcwg@ietf.org > > Subject: Re: [dhcwg] Comments on 22 rev of the draft > > > > > > See my comments inline prefixed by VB> > > > > ~Vijay > > > > > Let me try to answer these based on my understanding/view of -22. > > > > > > See below. > > > > > > - Bernie > > > > > > -----Original Message----- > > > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > > > Sent: Wednesday, January 16, 2002 1:05 PM > > > To: dhcwg@ietf.org > > > Cc: vijayak@dce.india.hp.com > > > Subject: [dhcwg] Comments on 22 rev of the draft > > > > > > > > > I had gone through the latest rev of DHCPv6 draft. Sorry for the delay > > > in telling the comments. > > > >[...] > > > - Till what time, these OFFERED addresses are preserved for those > > > clients to assign? > > > > > > BV> My opinion is that the ADVERTISED addresses are just a possible > set of > > > addresses the client will get and may not be the exact addresses. The > client > > > must wait until the Reply to the Request before it knows which > addresses it > > > got and before it does Duplicate Address Detection. The ADVERTISE should > > > include all of the parameters the client is likely to receive in the > Reply, > > > but they are just possible values and not the actual values. > > > > VB> What i am asking is, in V4, there is a concept called OFFERED > > addresses, which will be reserved to a client. The server reserves that > > addresses for the some predefined time. At the expiration of the time, > > if the client has not sent the request, it will be allocated to some > > other clients. I disagree that DHCPv4 requires that a server explicitly reserve an address it has offered to a client. From RFC2131: 3.1 Client-server interaction - allocating a network address [...] 2. Each server may respond with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). Servers need not ^^^^^^^^^^^^^^^^ reserve the offered network address, although the protocol will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ work more efficiently if the server avoids allocating the offered network address to another client. When allocating a new address, servers SHOULD check that the offered network address is not already in use; e.g., the server may probe the offered address with an ICMP Echo Request. Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly allocated addresses. The server transmits the DHCPOFFER message to the client, using the BOOTP relay agent if necessary. > I think, if we follow the same policy, it will be > > better. Assume, a client sends a SOLICIT and the server replies with > > ADVERTISE with some addresses. Before the client sending the Request, > > if some other client requests for the addresses, with the current > > mechanism, the server will assign the addresses to new client. It may > > lead to server to send AddrUnavail to the first client, if the server > > has only limited number of addresses. It will lead to unnecessary > > packet transactions. > > > > BV2> I don't agree. It is much better if the server can just send something > > out and not have to do anything to remember it. With IPv6, what's the > likelyhood > > that an address won't be available - we have 2^64 addresses on each prefix! > > > > BV2> What I view the ADVERTISE message to be is for the server to say I am > > willing to give you this stuff [assuming it is avaiable] but that I haven't > > given you the EXACT stuff you will get (since that happens in the Reply to > > the Request). > > > > BV2> BUT please note that this really is up to each SERVER to do what it > > wants. A SERVER can chose to ADVERTISE real stuff and "reserve" it for some > > period of time (and that is a SERVER implementation issue). In my server, > > I might chose that time to be 0 seconds. In your server, you can set it to > > 1 hour. The client can't do anything with ADVERTISEd information other than > > make a decision based on which ADVERTISE it wants to accept (assuming > it gets > > multiple). In any case, the information from the Reply is what it must > install. > > So, this is purely a server implementation issue. > >VB2> Yes. I agree that this is purely an implementation issue. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Mon Jan 21 20:36:09 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 UAA29650 for ; Mon, 21 Jan 2002 20:36:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA06027 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 20:36:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05485; Mon, 21 Jan 2002 20:27:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05460 for ; Mon, 21 Jan 2002 20:27:13 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29533 for ; Mon, 21 Jan 2002 20:27:09 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA16485; Mon, 21 Jan 2002 20:27:04 -0500 Date: Mon, 21 Jan 2002 20:27:04 -0500 (EST) From: Jim Bound To: Ralph Droms Cc: dhcwg Subject: Re: [dhcwg] Am I missing something? In-Reply-To: <4.3.2.7.2.20020121141605.032339d8@funnel.cisco.com> 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 Ralph, I believe the IETF wants to move to SLP for this. I think we need to check. I just don't want to build competing functions. If we do it fine but I think this requires some discussions iwth SLP folks too. /jim On Mon, 21 Jan 2002, Ralph Droms wrote: > We've taken an "on-demand" approach to adding options to DHCPv6 - that is, > as options are requested, we've added them. There hasn't been any > intentional oversight; to avoid carrying forward unnecessary options (e.g., > "Impress server"), we've simply started with a clean (or almost clean) > slate. 'bootfile' and 'TFTP server' seem like good candidates for > inclusion in DHCPv6. > > For WG discussion - should the 'bootfile' and 'TFTP server' options be > carried over verbatim to DHCPv6 or are there changes that should be made? > > - Ralph > > At 12:22 AM 1/21/2002 +0000, Michael Johnston wrote: > >There is no bootfile or TFTP server information in the DHCPv6 > >draft. Maybe this is intentional. Is there another mechanism that is to > >be used by network boot clients to locate image servers and download images? > > > >%%michael > >_______________________________________________ > >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 daemon@ns.ietf.org Mon Jan 21 20:55: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 UAA29848 for ; Mon, 21 Jan 2002 20:55:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA06365 for dhcwg-archive@odin.ietf.org; Mon, 21 Jan 2002 20:55:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06206; Mon, 21 Jan 2002 20:47:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06169 for ; Mon, 21 Jan 2002 20:47:57 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29743 for ; Mon, 21 Jan 2002 20:47:53 -0500 (EST) 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 g0M1lQS10773 for ; Mon, 21 Jan 2002 19:47:26 -0600 (CST) 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 g0M1lPD11323 for ; Mon, 21 Jan 2002 19:47:26 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Jan 21 19:47:25 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 19:47:25 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDDB@EAMBUNT705> From: "Bernie Volz (EUD)" To: dhcwg@ietf.org Cc: "'Jun-ichiro itojun Hagino '" Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt comments Date: Mon, 21 Jan 2002 19:47:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A2E6.BD0D7C80" 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_01C1A2E6.BD0D7C80 Content-Type: text/plain; charset="iso-8859-1" Sorry, forgot to include the main list on this issue so resending. -----Original Message----- From: Bernie Volz (EUD) Sent: Monday, January 21, 2002 8:46 PM To: 'Jun-ichiro itojun Hagino' Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt comments Itojun: Is this really a major concern for you? We aren't asking that much of the client - we already ask it to retransmit messages and keep this much state, is asking it to ignore additional Reconfigure messages really that much state to keep? It doesn't have to remember this state if it crashes or is shutdown (since it should do an Inform when it starts to make sure its current configuration is accurate). In fact, we might want to add some text to the draft (if it isn't already there) that a client that has used Inform should re-Inform when it detects that it may have moved to a new link (ie, send an Inform when a Confirm was to have been used if the client obtained addresses). - Bernie -----[Modified] Original Message----- From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net] Sent: Wednesday, December 26, 2001 3:54 AM To: rdroms@cisco.com Cc: dhcwg@ietf.org Subject: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt comments (text cut) 4. As far as I understand the goal of Inform message is to make it possible to make it possible to implement a stateless client which obtains various information from DHCPv6 server (draft-droms-dnsconfig-dhcpv6-00.txt). My question - does it make you any trouble if there's a client implementation that does not understand Reconfigure message? If we try to support Reconfigure (Inform solicited by DHCP server) client implementation becomes stateful. Also, it would have been easier if Inform message does not mandate DUID... _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A2E6.BD0D7C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt comments

Sorry, forgot to include the main list on this issue = so resending.

-----Original Message-----
From: Bernie Volz (EUD)
Sent: Monday, January 21, 2002 8:46 PM
To: 'Jun-ichiro itojun Hagino'
Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt = comments

Itojun:

Is this really a major concern for you? We aren't = asking that much of the client - we already ask it to retransmit = messages and keep this much state, is asking it to ignore additional = Reconfigure messages really that much state to keep?

It doesn't have to remember this state if it crashes = or is shutdown (since it should do an Inform when it starts to make = sure its current configuration is accurate).

In fact, we might want to add some text to the draft = (if it isn't already there) that a client that has used Inform should = re-Inform when it detects that it may have moved to a new link (ie, = send an Inform when a Confirm was to have been used if the client = obtained addresses).

- Bernie

-----[Modified] Original Message-----
From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net]
Sent: Wednesday, December 26, 2001 3:54 AM
To: rdroms@cisco.com
Cc: dhcwg@ietf.org
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-22.txt = comments

(text cut)

4.
As far as I understand the goal of Inform message is = to make it possible
to make it possible to implement a stateless client = which obtains various
information from DHCPv6 server = (draft-droms-dnsconfig-dhcpv6-00.txt).
My question - does it make you any trouble if = there's a client implementation
that does not understand Reconfigure message? = If we try to support
Reconfigure (Inform solicited by DHCP server) client = implementation becomes
stateful. Also, it would have been easier if = Inform message does not mandate
DUID...

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

------_=_NextPart_001_01C1A2E6.BD0D7C80-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Jan 22 03:44: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 DAA13857 for ; Tue, 22 Jan 2002 03:44:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26857 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 03:44:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26746; Tue, 22 Jan 2002 03:36:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26721 for ; Tue, 22 Jan 2002 03:36:07 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13770 for ; Tue, 22 Jan 2002 03:36:04 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23334; Tue, 22 Jan 2002 01:36:05 -0700 (MST) Received: from sun.com (vpn-129-159-0-15.EMEA.Sun.COM [129.159.0.15]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id JAA02926; Tue, 22 Jan 2002 09:36:03 +0100 (MET) Message-ID: <3C4D2411.1000908@sun.com> Date: Tue, 22 Jan 2002 09:34:25 +0100 From: Erik Guttman Reply-To: erik.guttman@sun.com Organization: Sun Microsystems, GmbH User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jim Bound CC: Ralph Droms , dhcwg Subject: Re: [dhcwg] Am I missing something? References: Content-Type: text/plain; charset=us-ascii; format=flowed 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 Jim, > I believe the IETF wants to move to SLP for this. I think we need to > check. I just don't want to build competing functions. If we do it > fine but I think this requires some discussions iwth SLP folks too. I must admit it's hard for me to conceive of DHCP without boot parameter options. I guess I'm showing my age. SLP is great for discoving 'differentiated' services - that is services which are not generic. Boot images that can be found by look-up-by-name are generic. This does require that DHCP servers be configured to know about TFTP servers and their contents, but in practice, this has worked out fairly well. Boot images which require multiple round trips between client and server (as per PXE) are NOT generic and would be better discovered via SLP. [Aside: PXE uses a hacked set of non- standard DHCP messages to perform iterative queries to configure a client to boot.] Further examples of non-generic services include, say, peer to peer file sharing services. There is no standard way to update the DHCP server dynamically, to know which service are available on the network, or what (characteristics) differentiates them. Clients seeking non-generic services don't want *just any* file server, they want the file server with the name, description, access permissions, etc. that they are seeking. This is a great application for SLP and an inappropriate one for DHCP. Ralph, >>We've taken an "on-demand" approach to adding options to DHCPv6 - that is, >>as options are requested, we've added them. There hasn't been any >>intentional oversight; to avoid carrying forward unnecessary options (e.g., >>"Impress server"), we've simply started with a clean (or almost clean) >>slate. 'bootfile' and 'TFTP server' seem like good candidates for >>inclusion in DHCPv6. I would like to see option 78 and 79 for DHCPv6 as well (SLPv2 DA and SLPv2 scope list options.) We are revising RFC2610 as part of bringing SLPv2 to draft standard. I guess we should include a description of the DHCPv6 options there as well? Are there any examples of how to do that? How do you suggest we proceed? Thanks, Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Jan 22 05:35:39 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 FAA15158 for ; Tue, 22 Jan 2002 05:35:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01224 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 05:35:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00585; Tue, 22 Jan 2002 05:24:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00564 for ; Tue, 22 Jan 2002 05:24:32 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14999 for ; Tue, 22 Jan 2002 05:24:28 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-61.cisco.com [10.82.240.61]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA01521; Tue, 22 Jan 2002 05:24:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020122050446.036870b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 05:24:27 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Issues raised during last call for DHCPv6 specification 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 following issues were raised during the last call for the DHCPv6 spec ; I will kick off separate discussion threads for each open issue later today. - Ralph Droms Open issues ----------- * We've experienced a proliferation of DHCPv6 options. Should all options *not* used in the base protocol be moved out to separate drafts? * Does DHCPv6 need a "default routes" option? * Does DHCPv6 need a "static routes" option? * Does DHCPv6 need an FQDN option (basically identical to proposed DHCPv4 FQDN option)? * Other options: - NTP servers - NIS servers - NIS+ servers - Subnet selection - NIS domain name - NIS+ domain name - IEEE 1003.1 POSIX timezone - SLP directory agent - SLP service scope * Should the DHCPv6 option codes start at 256 to avoid overlap with DHCPv4 option codes; overlap of option codes would be an issue for the DHCID RR. * What error codes may a server send in response to an Information-Request message? * Should the Decline message have error codes defining the reason for the Decline? * Does the Information-Request message require a DUID? Could the "MUST" in the third paragraph of 18.1.5 be changed to "SHOULD"? If a DUID "SHOULD" be included, text needs to be added pointing out the client-specific information (based on identifying the client with a DUID) cannot be returned if a DUID is not included. * Is a client required to implement the Reconfigure message - supporting Reconfigure will require that the client maintain state. * Do we want to allow a client to request that more normal addresses be added to an IA, perhaps through use of the equivalent of the RTA option? * DHCP/DDNS interaction * Is the text in section 17.1.3 sufficient? Changes to be made in -23 ------------------------- * Editorial changes: - Change "Inform message" to "Information-request message" and "INFORM" to "INFORMATION-REQUEST" throughout the document - In the list of DHCP messages in section 7, fix Reconfigure to start Renew/Reply or Inform/Reply sequence (not Request/Reply) - Fix page 10 (which is blank in -22 draft) - In third paragraph of section 14, change "Requested Temporary Addresses Option 22.5" to "Requested Temporary Addresses Option (see section 22.5)" - Change "Rebind" to "Inform" in the last paragraph of section 18.1.5 (cut-and-paste error) - Fix redundancy between sections 18.2.5 and 18.2.8 - Edit third paragraph of section 19.2 to delete references to IAs - In section 19.3.4, change "Rebind or Information-Request" to "Renew or Information-Request" - Change last sentence of section 22.5 to: "A client MUST only include this option when it wants to have additional temporary address allocated; a client SHOULD NOT send this option if 'num-requested' is 0". - Edit section 22.14 to indicate that the server-address field is in the fixed-format part of the DHCP message, not the unicast option - Clarify the text in section 22.19 to indicate that the 'user class data' items are carried in the data area of the 'user class option' * Clarify text in section 13 about address selection based on source of message from client * Remove references to "IAs" in section 19.2 * Fix chart in Appendix B to allow DSTM option in same messages as IA option * Modify SIP server option according to input from Henning Schulzrinne * Require that the DUID option appear before any IA options to improve processing efficiency * Require that the authentication option be first in th elist of options to reduce the work that a server must expend before discarding a message that fails authentication (reduces effect of denial of service attacks) * Clean up text specifying selection of address by server to insert into 'server-address' field * Clarify that a server MAY return fewer temporary addresses than requested by the client and MUST return AddrUnavail only if no temporary addresses are available * Clarify that a client MUST include all requested options in an ORO and MAY include suggested values by including specific options; also, the server MAY ignore suggestions from client and the client MUST use whatever the server returns * Clarify that a server MAY renew only some of the IAs sent by a client * Change DUID/VUID to have a length field to allow for longer IDs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Jan 22 10:51: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 KAA27357 for ; Tue, 22 Jan 2002 10:51:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14281 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 10:51:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13938; Tue, 22 Jan 2002 10:41:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13890 for ; Tue, 22 Jan 2002 10:41:33 -0500 (EST) Received: from email2.byu.edu (email2.byu.edu [128.187.22.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27105 for ; Tue, 22 Jan 2002 10:41:29 -0500 (EST) Received: from tj ([128.187.7.248]) by EMAIL1.BYU.EDU (PMDF V6.0-24 #38579) with ESMTP id <01KDD68O9E8U8ZHUAW@EMAIL1.BYU.EDU> for dhcwg@ietf.org; Tue, 22 Jan 2002 08:40:58 -0700 (MST) Date: Tue, 22 Jan 2002 08:41:14 -0700 From: Terrance Humphries Subject: RE: [dhcwg] additional option for dhcpv6 In-reply-to: To: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook, Build 10.0.2627 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 Please remove me from your list. Thanks, Terrance Humphries Network Security and Administration Manager Tjay@byu.edu 801-224-7513 -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Vijay Bhaskar A K Sent: Sunday, January 20, 2002 7:34 AM To: mjs@cisco.com Cc: vijayak@india.hp.com; dhcwg@ietf.org Subject: Re: [dhcwg] additional option for dhcpv6 Mark, Thanks for your thorough review. See my comments inline. ~ Vijay > 1) The FQDN option needs, I think, to look a lot like the FQDN option > for > dhcpv4. The option i defined here is, for just transfering the FQDN releated to temporary address. It is similar to hostname option in DHCPv4. I will rename it to hostname option. I feel like, since the DDNS updates are still TBD, we can define the FQDN option with appropriate fields needed later, once DDNS specs are finalised. > The name encoding must be specified. Yes. It is needed. I will add the appropriate text. > There needs to be > specification about hosts who do not initially know their entire fqdn. > There needs to be a way to communicate about which party (if any) will be > updating DNS. It's probably on my plate to produce that, actually. For the temporary addresses, DNS update is done by server. So, these fields are not necessary. > > 2) The subnet-selection option text should not compel the server to > somehow > obey the client's suggestion. It should be explict that the server > administrator's configuration takes precedence, and that the client's > indication that it desires a specific subnet can only be a hint that's > considered along with all of the other information available to the server. This is the only way the client can tell its prefernce for the prefix. If the server is not supposed to allocate address for that prefix, then it wont. If the client is not very particular about the prefix, it should not use this option. This option will be more helpful in the network with two prefixes and the client wants a particular one. > > A nit: isn't the option-len sufficient to determine the prefix length? > Is > the prefix-len byte necessary? No, it is not sufficient. Without the prefix-len field, you cannot find out the exact prefix length. For example, you can identify whether the prefix length is between 57 and 64. You cannot find out the exact prefix length. > > 3) The encoding for the domain names in the NIS and NIS+ Domain Name > options should be DNS encoding, shouldn't it? That seems more robust than > ASCII to me. Agreed. > > 4) The 'Service Location Protocol Directory Agent Option' places the > 'typed-scope-list-len' field before the 'DA address', rather than before > the 'typed scope list'. Couldn't the length of the list immediately precede > the list? I think, it won't make any difference. Let me know, if there are any serious issues on this. _______________________________________________ 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 daemon@ns.ietf.org Tue Jan 22 14:13:38 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 OAA05641 for ; Tue, 22 Jan 2002 14:13:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05788 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 14:13:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03890; Tue, 22 Jan 2002 13:44:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03869 for ; Tue, 22 Jan 2002 13:44:50 -0500 (EST) Received: from NS1.US.PRSERV.NET ([64.180.246.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04276 for ; Tue, 22 Jan 2002 13:44:46 -0500 (EST) From: sydney@vkistudios.org Message-Id: <200201221844.NAA04276@ietf.org> Reply-To: seo@vkistudios.org To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 22 Jan 2002 10:48:20 -0800 Subject: [dhcwg] ADV: Professional Internet Marketing 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 Professional Internet Marketing, VKI Studios 1-866-733-8899

	1-866-733-8899
"VKI increased our web traffic by 550% which resulted in a 20% increase in revenues in less than six months." John Keith-King, Curator, Granville Island Museums. Would you like to see if you can achieve similar results? Call us at 1-866-733-8899 or fill out our online consultation and receive a FREE Search Engine Report (value $75.00)

THE BENEFITS
Your website will become highly visible Your traffic will grow exponentially Measurable and trackable results You will have an ongoing strategy that adapts as search engines change
THE ELEVATION
Strategy development Keyword Formulation Creation of keyword & description META tags Creation of keyword entry pages FTP file transfer to server Submission of web address (URL) to search engines Submission of web address (URL) to directory sites more info
THE PUSH - ongoing maintenance includes:
Optimization - HTML optimization to be search engine friendly Submission - Proper submission protocol for each individual engine Registration - Verification of successful submissions Monitoring - Evaluation of server file logs for search engine activity Positioning - Fine-tuning of submitted pages Maintenance - Continuous attendance to all the above actions Online consultation
Many Search Engines are moving to paid listings so ACT NOW! Contact us today to take advantage of our limited time offer. Please call us: 1-866-733-8899 or (604) 733-1474 - VKI Studios Inc.

If you do not wish to receive further mailings, please unsubscribe here.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Jan 22 15:03: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 PAA08481 for ; Tue, 22 Jan 2002 15:03:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09347 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 15:03:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08685; Tue, 22 Jan 2002 14:55:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08650 for ; Tue, 22 Jan 2002 14:55:47 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08143 for ; Tue, 22 Jan 2002 14:55:43 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01054 for ; Tue, 22 Jan 2002 14:55:14 -0500 (EST) Message-Id: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 14:55:41 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Options in base doc for 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 We've recently experienced a proliferation of proposed and defined options for DHCPv6. Initially, the WG agreed to publish all options that were defined at the time the base spec was completed in the same doc. I'm having second thoughts about that decision. Here's what I'm thinking: * The new options are adding more weight to an already hefty document * Keeping all the options in one doc make updating any one option more complicated * Reviewing all of these options will slow down the acceptance process I propose that we put a moratorium on adding any new options to draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of "essential" is open to discussion; here's a first pass at a list of the options to retain in draft-ietf-dhc-dhcpv6-22.txt: * DHCP unique identifier option * Identity association option * IA Address option * Requested Temporary Addresses (RTA) Option * Option request option * Preference option * Elapsed Time * Client message option * Server message option * Authentication option * Server unicast option * Domain Search Option * Domain Name Server Option * Status Code Option - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Jan 22 15:28: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 PAA09158 for ; Tue, 22 Jan 2002 15:28:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10976 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 15:28:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09566; Tue, 22 Jan 2002 15:11:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09546 for ; Tue, 22 Jan 2002 15:11:01 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08656 for ; Tue, 22 Jan 2002 15:10:57 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-85.cisco.com [161.44.149.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA03276 for ; Tue, 22 Jan 2002 15:10:29 -0500 (EST) Message-Id: <4.3.2.7.2.20020122145946.036d26a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 15:10:55 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Two options proposed during WG last call 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 These two options were proposed during the WG last call on draft-ietf-dhc-dhcpv6-22.txt. - Default routes A default routes option is unnecessary because of neighbor discovery/router advertisements; is there some other reason to configure a host with default routes? - Static routes The static routes option has been discussed in the thread "static route option for dhcpv6". The summary of the discussion is that a static routes option might be useful to configure a host for tunnels. Please follow up with comments about whether we should define these two options for DHCPv6. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Jan 22 15:36:05 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 PAA09384 for ; Tue, 22 Jan 2002 15:36:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11630 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 15:36:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10817; Tue, 22 Jan 2002 15:23:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10796 for ; Tue, 22 Jan 2002 15:23:33 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09008 for ; Tue, 22 Jan 2002 15:23:29 -0500 (EST) Received: from goblet.cisco.com (mirapoint@goblet.cisco.com [161.44.168.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA04910; Tue, 22 Jan 2002 15:23:01 -0500 (EST) Received: from MJS-W2K.cisco.com (dhcp-161-44-149-110.cisco.com [161.44.149.110]) by goblet.cisco.com (Mirapoint) with ESMTP id AAM73107; Tue, 22 Jan 2002 15:23:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020122152250.025e3638@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 15:26:13 -0500 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] Options in base doc for DHCPv6 Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> 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 I think that this proposal makes a great deal of sense. I do think that the boot-file and tftp server address(es) options need to be added to the core list: they really are 'core' to the boot process. -- Mark At 02:55 PM 1/22/2002 -0500, Ralph Droms wrote: >We've recently experienced a proliferation of proposed and defined options >for DHCPv6. Initially, the WG agreed to publish all options that were >defined at the time the base spec was completed in the same doc. I'm >having second thoughts about that decision. Here's what I'm thinking: > >* The new options are adding more weight to > an already hefty document >* Keeping all the options in one doc make > updating any one option more complicated >* Reviewing all of these options will slow > down the acceptance process > >I propose that we put a moratorium on adding any new options to >draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of >draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of >"essential" is open to discussion; here's a first pass at a list of the >options to retain in draft-ietf-dhc-dhcpv6-22.txt: > >* DHCP unique identifier option >* Identity association option >* IA Address option >* Requested Temporary Addresses (RTA) Option >* Option request option >* Preference option >* Elapsed Time >* Client message option >* Server message option >* Authentication option >* Server unicast option >* Domain Search Option >* Domain Name Server Option >* Status Code Option > >- 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 daemon@ns.ietf.org Tue Jan 22 16:28:47 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 QAA11276 for ; Tue, 22 Jan 2002 16:28:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13069 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 16:28:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12161; Tue, 22 Jan 2002 15:56:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12135 for ; Tue, 22 Jan 2002 15:56:41 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10017 for ; Tue, 22 Jan 2002 15:56:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09696 for ; Tue, 22 Jan 2002 13:56:32 -0700 (MST) Received: from gullwing.eng.sun.com (gullwing.Eng.Sun.COM [129.146.111.80]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20449 for ; Tue, 22 Jan 2002 12:56:32 -0800 (PST) Received: from gullwing (gullwing [129.146.111.80]) by gullwing.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id g0MKuUD06061 for ; Tue, 22 Jan 2002 12:56:30 -0800 (PST) Message-Id: <200201222056.g0MKuUD06061@gullwing.eng.sun.com> Date: Tue, 22 Jan 2002 12:56:30 -0800 (PST) From: Warren Belfer Reply-To: Warren Belfer Subject: Re: [dhcwg] Two options proposed during WG last call To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BMdQUZFPrPiPQ5NPv76XoQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc 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 >- Default routes > >A default routes option is unnecessary because of neighbor discovery/router >advertisements; is there some other reason to configure a host with default >routes? Yes; for security reasons; I (and others, I presume) do not want hosts responding to spurious routing information. My routers do not advertise routes (neither RIP nor router discovery) and my clients don't listen for them. warren Warren Belfer Lead Operations Engineer Internet Services Engineering Sun Microsystems, Inc. >- Static routes > >The static routes option has been discussed in the thread "static route >option for dhcpv6". The summary of the discussion is that a static routes >option might be useful to configure a host for tunnels. > >Please follow up with comments about whether we should define these two >options for DHCPv6. > >- 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 daemon@ns.ietf.org Tue Jan 22 19:34: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 TAA15462 for ; Tue, 22 Jan 2002 19:34:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA19939 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 19:34:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19418; Tue, 22 Jan 2002 19:26:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19401 for ; Tue, 22 Jan 2002 19:26:34 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15321 for ; Tue, 22 Jan 2002 19:26:31 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA13524; Tue, 22 Jan 2002 19:25:06 -0500 Date: Tue, 22 Jan 2002 19:25:06 -0500 (EST) From: Jim Bound To: Erik Guttman Cc: Ralph Droms , dhcwg Subject: Re: [dhcwg] Am I missing something? In-Reply-To: <3C4D2411.1000908@sun.com> 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 Eric, Yourone of the tech leads for SLP and first driver in the IETF for this so thats fine with me. ACK. Lets put it in DHC6 then. /jim On Tue, 22 Jan 2002, Erik Guttman wrote: > > Jim, > > > I believe the IETF wants to move to SLP for this. I think we need to > > check. I just don't want to build competing functions. If we do it > > fine but I think this requires some discussions iwth SLP folks too. > > I must admit it's hard for me to conceive of DHCP without boot > parameter options. I guess I'm showing my age. > > SLP is great for discoving 'differentiated' services - that is > services which are not generic. Boot images that can be found > by look-up-by-name are generic. This does require that DHCP > servers be configured to know about TFTP servers and their > contents, but in practice, this has worked out fairly well. > > Boot images which require multiple round trips between client > and server (as per PXE) are NOT generic and would be better > discovered via SLP. [Aside: PXE uses a hacked set of non- > standard DHCP messages to perform iterative queries to > configure a client to boot.] > > Further examples of non-generic services include, say, peer to > peer file sharing services. There is no standard way to update > the DHCP server dynamically, to know which service are available > on the network, or what (characteristics) differentiates them. > Clients seeking non-generic services don't want *just any* file > server, they want the file server with the name, description, > access permissions, etc. that they are seeking. This is a great > application for SLP and an inappropriate one for DHCP. > > Ralph, > > >>We've taken an "on-demand" approach to adding options to DHCPv6 - that is, > >>as options are requested, we've added them. There hasn't been any > >>intentional oversight; to avoid carrying forward unnecessary options (e.g., > >>"Impress server"), we've simply started with a clean (or almost clean) > >>slate. 'bootfile' and 'TFTP server' seem like good candidates for > >>inclusion in DHCPv6. > > I would like to see option 78 and 79 for DHCPv6 as well (SLPv2 DA > and SLPv2 scope list options.) We are revising RFC2610 as part of > bringing SLPv2 to draft standard. I guess we should include a > description of the DHCPv6 options there as well? Are there any > examples of how to do that? How do you suggest we proceed? > > Thanks, > > Erik > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Jan 22 19:48: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 TAA15687 for ; Tue, 22 Jan 2002 19:48:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA20243 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 19:48:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20081; Tue, 22 Jan 2002 19:40:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20058 for ; Tue, 22 Jan 2002 19:40:08 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15549 for ; Tue, 22 Jan 2002 19:40:03 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA16493; Tue, 22 Jan 2002 19:40:03 -0500 Date: Tue, 22 Jan 2002 19:40:03 -0500 (EST) From: Jim Bound To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Options in base doc for DHCPv6 In-Reply-To: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> 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 We require the IPv6 options for IPv6 Transition now. /jim On Tue, 22 Jan 2002, Ralph Droms wrote: > We've recently experienced a proliferation of proposed and defined options > for DHCPv6. Initially, the WG agreed to publish all options that were > defined at the time the base spec was completed in the same doc. I'm > having second thoughts about that decision. Here's what I'm thinking: > > * The new options are adding more weight to > an already hefty document > * Keeping all the options in one doc make > updating any one option more complicated > * Reviewing all of these options will slow > down the acceptance process > > I propose that we put a moratorium on adding any new options to > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > "essential" is open to discussion; here's a first pass at a list of the > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > * DHCP unique identifier option > * Identity association option > * IA Address option > * Requested Temporary Addresses (RTA) Option > * Option request option > * Preference option > * Elapsed Time > * Client message option > * Server message option > * Authentication option > * Server unicast option > * Domain Search Option > * Domain Name Server Option > * Status Code Option > > - 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 daemon@ns.ietf.org Tue Jan 22 20:07:47 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 UAA16139 for ; Tue, 22 Jan 2002 20:07:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA21034 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 20:07:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20444; Tue, 22 Jan 2002 19:56:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20419 for ; Tue, 22 Jan 2002 19:56:14 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15867 for ; Tue, 22 Jan 2002 19:56:11 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11518; Tue, 22 Jan 2002 19:56:09 -0500 Date: Tue, 22 Jan 2002 19:56:09 -0500 (EST) From: Jim Bound To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Two options proposed during WG last call In-Reply-To: <4.3.2.7.2.20020122145946.036d26a0@funnel.cisco.com> 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 Ralph, An essential option set for dhc6 is that which will assist with the deployment of IPv6 immediately. That is the case for configured tunnels. Right now I am not convinced that we should add default routes to clients for dhc6. Not because they are learned (provided is not the case) by ND, as I believe the Dentist Office Scenario may justify them or a Home IPv6 Gateway box that wants to provide them instead of the router because it is not running full routing protocol to learn all routes. In this case my ISP tells me my static route and I configure that with DHC6. The reason for not doing it now is it requires more analysis and discussion than I think we should do before final last call and to PS process. I will argue that wee should permit this but it will take a long time to discuss. So in the interest of moving forward I suggest we not include default routes for now. /jim On Tue, 22 Jan 2002, Ralph Droms wrote: > These two options were proposed during the WG last call on > draft-ietf-dhc-dhcpv6-22.txt. > > - Default routes > > A default routes option is unnecessary because of neighbor discovery/router > advertisements; is there some other reason to configure a host with default > routes? > > - Static routes > > The static routes option has been discussed in the thread "static route > option for dhcpv6". The summary of the discussion is that a static routes > option might be useful to configure a host for tunnels. > > Please follow up with comments about whether we should define these two > options for DHCPv6. > > - 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 daemon@ns.ietf.org Tue Jan 22 20:32: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 UAA16739 for ; Tue, 22 Jan 2002 20:32:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22005 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 20:32:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21301; Tue, 22 Jan 2002 20:21:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21282 for ; Tue, 22 Jan 2002 20:21:56 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16478 for ; Tue, 22 Jan 2002 20:21:52 -0500 (EST) 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 g0N1LOS07907 for ; Tue, 22 Jan 2002 19:21:24 -0600 (CST) 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 g0N1LO717097 for ; Tue, 22 Jan 2002 19:21:24 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jan 22 19:21:23 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 19:21:23 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69BC7757@EAMBUNT705> From: "Bernie Volz (EUD)" To: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Options in base doc for DHCPv6 Date: Tue, 22 Jan 2002 19:21:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3AC.44E22BE0" 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_01C1A3AC.44E22BE0 Content-Type: text/plain; charset="iso-8859-1" Ralph: I agree with this. It also means we can divide the work by having many people write drafts. Reviewing is also easier as people can focus on those documents that they feel are critical to them. I also think your initial list of options looks good and is the basic set for protocol operation. It may not provide the basic set for client configuration and we might even argue that two, the Domain Search Option and Domain Name Server Option, could even be moved to that other document since they aren't related to the operational issues of the DHCP protocol. For IESG review, I think it will be important to point out that this is the basic set required for proper DHCP protocol operation and not the basic set to provide client configuration. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, January 22, 2002 2:56 PM To: dhcwg@ietf.org Subject: [dhcwg] Options in base doc for DHCPv6 We've recently experienced a proliferation of proposed and defined options for DHCPv6. Initially, the WG agreed to publish all options that were defined at the time the base spec was completed in the same doc. I'm having second thoughts about that decision. Here's what I'm thinking: * The new options are adding more weight to an already hefty document * Keeping all the options in one doc make updating any one option more complicated * Reviewing all of these options will slow down the acceptance process I propose that we put a moratorium on adding any new options to draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of "essential" is open to discussion; here's a first pass at a list of the options to retain in draft-ietf-dhc-dhcpv6-22.txt: * DHCP unique identifier option * Identity association option * IA Address option * Requested Temporary Addresses (RTA) Option * Option request option * Preference option * Elapsed Time * Client message option * Server message option * Authentication option * Server unicast option * Domain Search Option * Domain Name Server Option * Status Code Option - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A3AC.44E22BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Options in base doc for DHCPv6

Ralph:

I agree with this. It also means we can divide the = work by having many people write drafts. Reviewing is also easier as = people can focus on those documents that they feel are critical to = them.

I also think your initial list of options looks good = and is the basic set for protocol operation. It may not provide the = basic set for client configuration and we might even argue that two, = the Domain Search Option and Domain Name Server Option, could even be = moved to that other document since they aren't related to the = operational issues of the DHCP protocol.

For IESG review, I think it will be important to = point out that this is the basic set required for proper DHCP protocol = operation and not the basic set to provide client = configuration.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, January 22, 2002 2:56 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Options in base doc for = DHCPv6

We've recently experienced a proliferation of = proposed and defined options
for DHCPv6. Initially, the WG agreed to = publish all options that were
defined at the time the base spec was completed in = the same doc. I'm
having second thoughts about that decision. = Here's what I'm thinking:

* The new options are adding more weight to
   an already hefty document
* Keeping all the options in one doc make
   updating any one option more = complicated
* Reviewing all of these options will slow
   down the acceptance process

I propose that we put a moratorium on adding any new = options to
draft-ietf-dhc-dhcpv6-22.txt, and move any = non-essential options out of
draft-ietf-dhc-dhcpv6-22.txt into individual = drafts. The definition of
"essential" is open to discussion; here's = a first pass at a list of the
options to retain in = draft-ietf-dhc-dhcpv6-22.txt:

* DHCP unique identifier option
* Identity association option
* IA Address option
* Requested Temporary Addresses (RTA) Option
* Option request option
* Preference option
* Elapsed Time
* Client message option
* Server message option
* Authentication option
* Server unicast option
* Domain Search Option
* Domain Name Server Option
* Status Code Option

- Ralph

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

------_=_NextPart_001_01C1A3AC.44E22BE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Jan 22 20:35:01 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 UAA16780 for ; Tue, 22 Jan 2002 20:35:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22076 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 20:35:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21258; Tue, 22 Jan 2002 20:21:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21235 for ; Tue, 22 Jan 2002 20:21:28 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16470 for ; Tue, 22 Jan 2002 20:21:25 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0N1LRh29312 for ; Tue, 22 Jan 2002 19:21:27 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0N1LRJ29478 for ; Tue, 22 Jan 2002 19:21:27 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Tue Jan 22 19:21:27 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 19:21:26 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69BC7758@EAMBUNT705> From: "Bernie Volz (EUD)" To: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Two options proposed during WG last call Date: Tue, 22 Jan 2002 19:21:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3AC.45085180" 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_01C1A3AC.45085180 Content-Type: text/plain; charset="iso-8859-1" Ralph: I don't see these as required for protocol operation and therefore would recommend (per your other message) to put them in a separate document. Also, these are probably not critical options as they deal with cases that will hopefully only exist in very few environments. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, January 22, 2002 3:11 PM To: dhcwg@ietf.org Subject: [dhcwg] Two options proposed during WG last call These two options were proposed during the WG last call on draft-ietf-dhc-dhcpv6-22.txt. - Default routes A default routes option is unnecessary because of neighbor discovery/router advertisements; is there some other reason to configure a host with default routes? - Static routes The static routes option has been discussed in the thread "static route option for dhcpv6". The summary of the discussion is that a static routes option might be useful to configure a host for tunnels. Please follow up with comments about whether we should define these two options for DHCPv6. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A3AC.45085180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Two options proposed during WG last call

Ralph:

I don't see these as required for protocol operation = and therefore would recommend (per your other message) to put them in a = separate document. Also, these are probably not critical options as = they deal with cases that will hopefully only exist in very few = environments.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, January 22, 2002 3:11 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Two options proposed during WG last = call

These two options were proposed during the WG last = call on
draft-ietf-dhc-dhcpv6-22.txt.

- Default routes

A default routes option is unnecessary because of = neighbor discovery/router
advertisements; is there some other reason to = configure a host with default
routes?

- Static routes

The static routes option has been discussed in the = thread "static route
option for dhcpv6". The summary of the = discussion is that a static routes
option might be useful to configure a host for = tunnels.

Please follow up with comments about whether we = should define these two
options for DHCPv6.

- Ralph

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

------_=_NextPart_001_01C1A3AC.45085180-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Jan 22 21:52: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 VAA18864 for ; Tue, 22 Jan 2002 21:51:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA25193 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 21:52:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24279; Tue, 22 Jan 2002 21:36:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24201 for ; Tue, 22 Jan 2002 21:36:54 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18609 for ; Tue, 22 Jan 2002 21:36:50 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-594.cisco.com [10.82.242.82]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA06580 for ; Tue, 22 Jan 2002 21:36:22 -0500 (EST) Message-Id: <4.3.2.7.2.20020122212127.03678058@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 21:36:48 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Other options for 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 Included below is a list of other options that are currently in draft-ietf-dhc-dhcpv6-22.txt or have been suggested for definition for DHCPv6. I propose that the WG agree on the list of additional options and that these options be documented individually or in small groups of related options (e.g., DSTM Global IPv4 Address Option and DSTM Tunnel EndPoint Option). I'll volunteer to extract the options that are currently in draft-ietf-dhc-dhcpv6-22.txt and generate separate docs for each; those options should get through process quickly. Your favorite option will get in the process a lot faster if you volunteer to write a draft for it... - Bootfile name - TFTP server - DSTM Global IPv4 Address Option - DSTM Tunnel EndPoint Option - Circuit-ID Option - User Class Option - Vendor Class Option - SIP Servers Domain Name List - SIP Servers IPv6 Address List - FQDN - Static routes - Default routes - NTP servers - NIS servers - NIS+ servers - Subnet selection - NIS domain name - NIS+ domain name - IEEE 1003.1 POSIX timezone - SLP directory agent - SLP service scope _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Jan 22 22:01: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 WAA19130 for ; Tue, 22 Jan 2002 22:01:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA25824 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 22:01:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25081; Tue, 22 Jan 2002 21:50:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25056 for ; Tue, 22 Jan 2002 21:50:02 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18821 for ; Tue, 22 Jan 2002 21:49:58 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-594.cisco.com [10.82.242.82]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA07144 for ; Tue, 22 Jan 2002 21:49:30 -0500 (EST) Message-Id: <4.3.2.7.2.20020122213702.03702ea0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 21:49:56 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Assigning DHCPv6 option codes 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 There is a potential collision problem between DHCPv4 and DHCPv6 option codes. The DHCID RR uses the option code to identify the source of the information stored in the RR. If DHCPv4 and DHCPv6 use overlapping option codes that identify different options, the source of the information in the RR will be ambiguous. One proposed solution is to start numbering DHCPv6 options at 256, to avoid collisions with DHCPv4 option codes. Another solution is to assign new codes for the identification field in the DHCID RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other sources of information not encoded in a DHCP option. For example, DHCID RR code 1 might identify the contents of the RR as a DHCPv4 client identifier, while DHCID RR code 2 might indicate a DHCPv6 DUID. Comments on the two solutions? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Jan 22 23:52:33 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 XAA21919 for ; Tue, 22 Jan 2002 23:52:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA28641 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 23:52:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28508; Tue, 22 Jan 2002 23:42:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28479 for ; Tue, 22 Jan 2002 23:42:49 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21728 for ; Tue, 22 Jan 2002 23:42:44 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06053; Tue, 22 Jan 2002 23:42:45 -0500 Date: Tue, 22 Jan 2002 23:42:45 -0500 (EST) From: Jim Bound To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Other options for DHCPv6 In-Reply-To: <4.3.2.7.2.20020122212127.03678058@funnel.cisco.com> 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 SIP is on that needed deployment list too. The Telcos want it follks for SIP phones and multimedia. /jim On Tue, 22 Jan 2002, Ralph Droms wrote: > Included below is a list of other options that are currently in > draft-ietf-dhc-dhcpv6-22.txt or have been suggested for definition for DHCPv6. > > I propose that the WG agree on the list of additional options and that > these options be documented individually or in small groups of related > options (e.g., DSTM Global IPv4 Address Option and DSTM Tunnel EndPoint > Option). I'll volunteer to extract the options that are currently in > draft-ietf-dhc-dhcpv6-22.txt and generate separate docs for each; those > options should get through process quickly. Your favorite option will get > in the process a lot faster if you volunteer to write a draft for it... > > - Bootfile name > - TFTP server > - DSTM Global IPv4 Address Option > - DSTM Tunnel EndPoint Option > - Circuit-ID Option > - User Class Option > - Vendor Class Option > - SIP Servers Domain Name List > - SIP Servers IPv6 Address List > - FQDN > - Static routes > - Default routes > - NTP servers > - NIS servers > - NIS+ servers > - Subnet selection > - NIS domain name > - NIS+ domain name > - IEEE 1003.1 POSIX timezone > - SLP directory agent > - SLP service scope > > > _______________________________________________ > 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 daemon@ns.ietf.org Tue Jan 22 23:53: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 XAA21943 for ; Tue, 22 Jan 2002 23:53:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA28670 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 23:53:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28455; Tue, 22 Jan 2002 23:40:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28423 for ; Tue, 22 Jan 2002 23:40:43 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21668 for ; Tue, 22 Jan 2002 23:40:38 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA13444; Tue, 22 Jan 2002 23:40:37 -0500 Date: Tue, 22 Jan 2002 23:40:37 -0500 (EST) From: Jim Bound To: "Bernie Volz (EUD)" Cc: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Options in base doc for DHCPv6 In-Reply-To: <66F66129A77AD411B76200508B65AC69BC7757@EAMBUNT705> 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 Bernie, Again DNS options are needed NOW for IPv6 deployment. Specifically for IPv6 DNS Stateless discovery. That which is needed for IPv6 deployment is as important to any option we have in the spec. Implementors like VJ and others need these now the reason is we are so late with DHC6 for the market we do not have the luxury to not include basic options which which are required by the IPv6 market early adopters. So I would argue this should affect our thinking on this discussion. Right now boot server for diskess nodes is less important to the market (our customer here) than configured tunnel option. /jim On Tue, 22 Jan 2002, Bernie Volz (EUD) wrote: > Ralph: > > I agree with this. It also means we can divide the work by having many people write drafts. Reviewing is also easier as people can focus on those documents that they feel are critical to them. > > I also think your initial list of options looks good and is the basic set for protocol operation. It may not provide the basic set for client configuration and we might even argue that two, the Domain Search Option and Domain Name Server Option, could even be moved to that other document since they aren't related to the operational issues of the DHCP protocol. > > For IESG review, I think it will be important to point out that this is the basic set required for proper DHCP protocol operation and not the basic set to provide client configuration. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, January 22, 2002 2:56 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Options in base doc for DHCPv6 > > > We've recently experienced a proliferation of proposed and defined options > for DHCPv6. Initially, the WG agreed to publish all options that were > defined at the time the base spec was completed in the same doc. I'm > having second thoughts about that decision. Here's what I'm thinking: > > * The new options are adding more weight to > an already hefty document > * Keeping all the options in one doc make > updating any one option more complicated > * Reviewing all of these options will slow > down the acceptance process > > I propose that we put a moratorium on adding any new options to > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > "essential" is open to discussion; here's a first pass at a list of the > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > * DHCP unique identifier option > * Identity association option > * IA Address option > * Requested Temporary Addresses (RTA) Option > * Option request option > * Preference option > * Elapsed Time > * Client message option > * Server message option > * Authentication option > * Server unicast option > * Domain Search Option > * Domain Name Server Option > * Status Code Option > > - 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 daemon@optimus.ietf.org Wed Jan 23 01:56: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 BAA23717 for ; Wed, 23 Jan 2002 01:56:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA10749 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 01:56:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10579; Wed, 23 Jan 2002 01:42:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10555 for ; Wed, 23 Jan 2002 01:42:13 -0500 (EST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23541 for ; Wed, 23 Jan 2002 01:42:12 -0500 (EST) Received: from chitha.india.hp.com (chitha.india.hp.com [15.10.43.31]) by palrel10.hp.com (Postfix) with ESMTP id A8404C0018E; Tue, 22 Jan 2002 22:41:40 -0800 (PST) Received: (from jitesh@localhost) by chitha.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id LAA15347; Wed, 23 Jan 2002 11:55:35 +0530 (IST) From: Jitesh N Verma Message-Id: <200201230625.LAA15347@chitha.india.hp.com> Subject: Re: [dhcwg] Options in base doc for DHCPv6 To: mjs@cisco.com Date: Wed, 23 Jan 2002 11:55:34 +0530 (IST) Cc: rdroms@cisco.com, dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020122152250.025e3638@goblet.cisco.com> from Mark Stapp at Jan "22," 2002 "03:26:13" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] 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 Hi List, I strongly agree with Mark. Booting mechanism belongs to DHCP domain. Regards, Jitesh > I think that this proposal makes a great deal of sense. I do think that the > boot-file and tftp server address(es) options need to be added to the core > list: they really are 'core' to the boot process. > > -- Mark > > At 02:55 PM 1/22/2002 -0500, Ralph Droms wrote: > >We've recently experienced a proliferation of proposed and defined options > >for DHCPv6. Initially, the WG agreed to publish all options that were > >defined at the time the base spec was completed in the same doc. I'm > >having second thoughts about that decision. Here's what I'm thinking: > > > >* The new options are adding more weight to > > an already hefty document > >* Keeping all the options in one doc make > > updating any one option more complicated > >* Reviewing all of these options will slow > > down the acceptance process > > > >I propose that we put a moratorium on adding any new options to > >draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > >draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > >"essential" is open to discussion; here's a first pass at a list of the > >options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > > >* DHCP unique identifier option > >* Identity association option > >* IA Address option > >* Requested Temporary Addresses (RTA) Option > >* Option request option > >* Preference option > >* Elapsed Time > >* Client message option > >* Server message option > >* Authentication option > >* Server unicast option > >* Domain Search Option > >* Domain Name Server Option > >* Status Code Option > > > >- 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 > -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 02:17:33 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 CAA02443 for ; Wed, 23 Jan 2002 02:17:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12152 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 02:17:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11302; Wed, 23 Jan 2002 02:03:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11218 for ; Wed, 23 Jan 2002 02:03:07 -0500 (EST) Received: from e3500.vnn.vn (e3500.vnn.vn [203.162.0.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26917 for ; Wed, 23 Jan 2002 02:02:48 -0500 (EST) Date: Wed, 23 Jan 2002 02:02:48 -0500 (EST) Message-Id: <200201230702.CAA26917@ietf.org> Received: from aol.com ([203.162.12.241]) by e3500.vnn.vn (Netscape Messaging Server 4.15 e3500 Sep 28 2000 18:20:45) with SMTP id GQDQ9G00.EWA for ; Wed, 23 Jan 2002 14:03:16 +0700 From: "cao hai van" <_hndelta@hn.vnn.vn> To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="====_ABC1234567890DEF_====" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 Subject: [dhcwg] Re: 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 --====_ABC1234567890DEF_==== Content-Type: multipart/alternative; boundary="====_ABC0987654321DEF_====" --====_ABC0987654321DEF_==== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --====_ABC0987654321DEF_====-- --====_ABC1234567890DEF_==== Content-Type: audio/x-wav; name="fun.MP3.pif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAAoxs1SbKejAWynowFsp6MBF7uvAWinowHvu60BbqejAYS4qQF2p6MBhLin AW6nowEOuLABZaejAWynogHyp6MBhLioAWCnowHUoaUBbaejAVJpY2hsp6MBAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAUEUAAEwBAwCoIP47AAAAAAAAAADgAA8BCwEGAABwAAAAEAAAANAAAEBHAQAA 4AAAAFABAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQ AAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAABkUAEAMAEAAABQAQBkAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAAAEAAAAAAAAAAEAAAA AAAAAAAAAAAAAACAAADgAAAAAAAAAAAAcAAAAOAAAABqAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5y c3JjAAAAABAAAABQAQAAAgAAAG4AAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAkCCN1hYc1ltHkUdCgBADdnAAAAEAEAJgEAve3/ //9Vi+wPvkUIi8iD4APB+QLB4ASKiWiiQACITQgX3bH//00Mi9GD4Q/B+gQLwsHhAoqAGUUJMRDB Ztvbi9AWBgvKNj8wHB1ht9tNCh8Li1Bdw1nGMhdLth89XVpiWnYoO3uKBI0JCkQKPXH9Yc8dCDZU MFGDfQwB3ZtmuxD8PQP9/v89dQ4eirbf3f8AUOgBAACbWcnDIwJ1EhNIARZR7MjNxxdWWevlA3wY AlEbR27tP9f+//+DxAw1YvzJUVO/ffv/i10MVlcz9jP/hdt+WxcQagOJHI1DAjPS2Hdf+Fn38Yld H/jB5wJH/3UQA8Zey/Zv28wg+KoMikX6iGUNCA77vdvebgUPjRFqBFAl/CI/6oNt9v/2ti2DRwSD xgbEFDvzfL2Lx19eW3T+v739ikQkBDzFAwQDCsiA4XCA+WB8AyxHw/+XptkHQEEwBATDPCsPlcCD wBd+c78+pYpNbMjRwOACwGcKwnm7Ff6LVRjA4QSIx62K0BECCsoJX/htHBwGCkUUiG5NIIgBP7C2 bbaMCAGkBwygCiLLYO4QugoUEHXNdtm+FP1QA/7/xBTt9mDOJzVA1bBAxCw4Qltoy9t0OAQMdDMQ GxIYl63Ntn//agGICOsfEBQODASt0P3C/ohtdQRqAusL/U0N+C+02wJY9jPAA2X/OXwkDH48i+3v /l8DCFNWav5bjXACK9gNGAPHUIpGAQMofOi6Bgb/A/5oAgw9Cm9vWCb4P40EMzslFHzUQT+42xtG w1aLdEZW/wRr8FlQvg3/cwrIAp+AJDAA4F7DHQiz79tFKxBWIRTKLyH7zfDDEF4ggewYzvEIiU38 UMnf+G13agDvaAIRgP8VAKCRhcAPhXb78tunAA5WV74UwI196KUr+McCDR0X3AA1KIXoTaUw9MzW bXcD6GalPlA/pDskW9i4Fes9dWSE9ApeKbfl1j1oEENQHQyhWRxZdGyzvfcIgKQFGHU0GIC9Dzs2 dnZ0KDFQv0AG/Iuiezf2fYkBjY0XURH2xbAB6ws9uW8XJjJiwgSsi/FoZGkP273dIgMthIMoaDAN i84PGGpw7PexEE/HBCQgkIkGTFlZ4Yb5zTM6gz4AdQWA/zZfW/ruDRtYi8GDIAA4Abq6f/h3dAeA QAJZw8gPt0gMUQQK3BeeeQgD8/80jaxfdnN76woGA0AEUQ+FlGg4wQTfZha6WSQIFMMkRAT9W5va i0xIhf8rH/8CdA5mixA23v6/AjQBZjvWdw9yEkdAQBUIcuVDXwzfuNCkpljrEsj/6/PAf7t1FBRH V191GgNBDgPwv+h9+0vbAwCoxrqL32o89/MJZolRDpbbir0N9/dfEg7wJxe6Xyu7BUUYHiKL9yQM Q36fa/YjGRYfQQrI2O10QgoDX1cfFOl0y8gI914+CINTx1ttDLSKadJtHgOkLb19ew5r0h4HZgNB BgPwdFsRX7bpfrsfUQI7wivHdBoDEg6Dsn777e50CQgFah/YD2oe6/nmZjkBD5SF/9+a/Bwr3jvD cx1mg/oMdQtm/xDt7e7tx0ECXOsFQnMCZitUBuusCm1zRtdxBlld0AAzyUK9gRdofU2AQO/OFBFB O7vdCm8/iJQFdgByAhxAPSQd+63wct05tVcyyYqCJpwV7/f/+x+NsgwC2ALLQg+2+YqfDYH6L3dr 99+NvwuIHqJC8AYHcrslQAl9xzpbAAZB2/4FElPc3u+3OQ0HipExABUfEgVBrc/v85iNgAWImVuI wi+2e+/CAoEKWSjAih7OwUuv4YPsDN5oflxoRPDL5XL7LvR6A/Vy9h33pfh9XC6X8vmj+sn7sZcI 1wI/NpFqCKIF/twIPkt/YwN5MzZGXzv3diO9/A42KH1H/02gH+H2b2p3JQaAMgdeiAQ5Rzv+cufK RmpqLndyyqGzIL/BzWYFHGoWmRb5i/LB5u7HR/oD/7YIxWcGzYs9zLu4DyHbGGOmU+HXIQzBbWWy FjiRKGOvXHOrPAQEH/z7AQpyv84Gegz/u0Ieu93cHVxufRVaaAimib0M4N0Dl55RQCrsDADkVg1Q Yz1rtU0iwTVUCF1dBVO7exEOU16LT+zUtnMbXchqYAFhFksz8SHd1t0UXoP4/1Z1YQgO7A/yCCTG 9kYDD3QqGhAddmBDFPCRXmCiHLuSEADVEAZKuXWg1USAMyDQ9P3tycCAZ1UH8YsYGOvu5428BYuF +AXB6BDZlmDm1mSM1Ng0AP47XXPuvzKujbQFBBN1BGLD7gWzgUujjJvbD4OTB6M0O3s6MFYxefG5 eINSpEgKiigF4AilL0n5D3VuHmyKJvZyK+xzRolTMPD5RlBWOTcTQ3hXUHzoYHwpZreSiWb+kydz FylopQgYaUTyE0J7qxUcJAt1+OkPCRjykIUrEBA8M5zd8E+ruOCTEDwffbhZMLyDZfwAIPzkiWXw thkeaBzseT8hxewXoYGfYSqMCITpN8hbQOBW8EYEfx3oQesGBiIOiR9bA9OTHLgYGkYVTPTQ0blv gmSJDQAAiQgGQJMbFDjb7YzooDwMXth1K1lqICRQxkJtBs5WCU1avb8G3w08QFEqCZ1eUHYD7a9K uV2DZtcQw7j06mDP3R1RGol18FzuYMx9zTGDCUI1Y5+euWBOOsn1IEHwnOTIkZsG9Ij4dPxokSO3 buAsgAbkAegChFuJzewDM9unbzdWGDEYiULRHThp9OC3uxB+EEOD04P7BHzdTCB2W9rni/PJAtA1 8C/FJw3vT41ECAHfDEQ14CycxthO69TVVEIzREs0cN3/NTSjDtqsZjM4PLAk0RFGn87WeHU8wHVU XjnXY+NqRBuskp9RL5b70SX9xqxEyOAxXnOtuUBZJrUqDgBz3azNTDYuYTwhKFywSqY4bUE8P9+v LVvjoFCgf/xo5OzwGesIggrDDTJoP8VYBCteH6v8731um+Yq6zwNENkIXoRZshhIm0WdzWzLxghM ZgxITUiGwWaSkQwnSRsvsWyH3Fk7x2gFLfb2h7isjU34UQP8UVeTBaEDY91I8VKNMlFvfRDqbgaa 9gUw3CB2NhO3RkBR6kACBuhoaMb5hfSbm1l2hN53KkW+05pXVtGNNHQok5EfGTbCCes3WUBCJiNQ NCs5WlZWDj0QBnMaRRQgXl9EMM6Y7xdXCtGMJIyA9s0Nk3TMgqYNKPi/mHBZe82kgmz0A+PIZjq0 VHRSPObHyXgdOVChhlBQGRtLmv28YyBJpYTxHP1XQwKMMMhgwgAA8gKS9GKH/KcUErLZrROOAfZ1 URnc7za15ADpPT4ndia+QlinZB+aNh0VcTrWVKHW3Tslct/Lsa7XV4rk+I4wAVP83z0b1Mdop4vY hduJXfwPhNUAPHHD3Ys1ZBM09MZS1g9v92sJB4v4CdTGK6HWB9sGCoO8O8Yylx3Ssz3b3geP/kKH avOx1tna1zGU0GsHhGwNuyh0/9NvaNj0iBFsyfQMhJuX20m0dSkcYKA7hdh0G6ln297/tQdkARZc xusfZrZCeQtYcv9V+LFYkd7rlKhNivkMmm7T9AUdZf8D9/4hAsFq7iAyzyZOhrEs2+AC2NzUZOdm LP4gaDTIq1yLPVgFXCy0AnUE8IeBpxH4bBdU2FPXarLZtjMDlhtTqFbdUN/QluBDHjjROnwejUwG An9hof8kMIuLffiKDDcYv+222z6WCIsZSB154g4enmpiULtrkAsqXP/q12aBvQ89mrj0BDG7qgdh DSypwQ2/M7gyyLvAd4PhAQfH3NssdmYxFx0ai716M5RsIdsbAhcRBMmUTMkIECDLyGAPZiPLcYsz hWxmc5teozIMCmK34Zhu5i5dozYPKRZ2Tw2PGw+6o6ARDWl2j18I8EKNBDeW+IkEjeMkmwCFjSKY I47CCw39/yuNfAdCi1pgtmNRcr5ZfkoI3Uu2vCC/4kJZ4izDs8BXloQwzxi0bRZsSCkMSoI8RjZ3 boDi5DoPhuVkkpFJiueOgckWZOZ/bkGDHHLYEnLpoTX73w4Ev0Ajw2Y9gAB1GDXYM6CLrSdXF+s7 EbuvhbG2ZiRXM4C76wZilixlw3YO26SnZ44IX1dZl2YdMskh62rsoSBjk82SD+2adD+4sZZqAqPi DUWYGe4gt7ad6g2oGA8U72azi8VWeAQOxAtaAifpxA1yx0AkyD5NIggDQHTvwgOmYbhOpBC7epW2 A/ABE1lwpvVfs86x15+zdBloDMjTL+iKpFYGYdBT8rP+Tbor/CVbaOjHyhzpDL/QB6Msewy4OO83 ioyNoBkI0aMo26/9dgg5DSh0HQcjdBUPCL2A+z8NO8F0CcYFPBNPB4AlMGv24QgCIdC1RzHykOyg +aZQuxCG8OwBFVNQqQo07P7r1xnsdWtomIxqbht8NrNt7dUV6AvcCOQTT3KwjZTHWaNE3sbgAgY3 fJUDWuhDX70vMdQ7j+RTnSz0TqEmN0hTQ6PDrm5saIwm+AEjZ18h4V/QDHTobjgjJ2jkGzlN0Iws m9loLAjoI+RfXZoL/xoDwRIDJbjIUaHrwekKjVGP44twhE494H34vh7yyRYLBGP4Oxw05FzsBiAT IhWSEHj2kp1wHRA3ix3SXBj2RCMRDPpMbKz7MNNPRcA4bG/AJS+bPTULcSo4IP7Gy5g0RHMkj9kD k82FuTz/BO9973b24xi+7Iv8GqUAUKVU5Jd8vu4sTPTuEL7k7uscJeRMqi4QaTTEk5GtIFZoV1b8 4jMdJPRAZlEg/7mKXOitBKKjBq5ZoCT/JBMJoJwwNuKAfctKdFXQ3fTNRvQgWfZFuQJP+HUbrGvC sSf+vSUR/vzi24F9MP1Z81lpAG3slzC2O33UdG5cA1D/CsKJ5C02UQ41WYQXYglNoU5jssxQHoLw dATKyI2U/G+DDmkgGGABk4N/y0o/hXRV6IhFnDWxu3194DyJdnYKFCOvguvbJ9SqeoQLBHRTHtgJ y7btHnZKkvf1RHha7s8u3lAQKgS2fQ2hOjMIdvvBOwVrdhIb91Amt2crG1Iu+lvY2FLcFCUH9tl2 PGEQdClVPF3r5Th8CfvViQUMFkp8toJE3Nw53JZRLcZYGEEBSKkQLBdYmkCJ6WIWayg8oBTNLFGn oAh0EsAIFwj0kkMUAXU3BeC9Ohz4oF4pcHlImdtsdBP8AXDQsKJOoAPE7Lms6/gmQQleq4RUCRKY VoJkRelpPApAJrCaAug74tC8OBBZvrjI1o79OzCUahLzpaS+rAz0pQoYdtsOz2S98cTYHL5YGzvZ 2DTof2alr5TiA+3u+H9N5g+vwYP4FaNQ8SgM0egLd/n/YQyKDXGUGxhFWbtQyFi32Q5tWUh0RBxT HSvb/Q1ZBxuuWRZZVhdpNvbBv0SeVwtWBgq3wl2jiipmaj9ZsapN/dvady+IlUwF86tmq6oVFFkV shFkpP7+x+hWjsADGOBZ7e8AGTcI8EYMdEgLAZakg348LUvSDMj+/jiq3Bo2aTCrVCGQoPjHvuPN O/h0c4scg+AQPBB1Sn3bZzZeVOKILTgXJVvBGvYQAGIXZAicTTgzDFMkDFZZGmSbcyBXEIw1SKY7 lwqIRMPeQSd2oZigqNZpyYgT8ft9gw/Bo0zxEjkFB3f22sOICyUIlBBcCyLPEx4TdT9i2fzYHCFC cwUQZI7Z+2SEC/nY+9mk2D0GbTdVNdyEhL+4xXe3Ae/PR1PWGjgRUA/mFoZJ/e4WmPSb0CDJgAC/ BBcgstnAKZj58MvsZoZabvNhRkw29hD7Tvf7IORQEH72Ei/QFwRT8wGNhceFWB8z0mzm/9wJXNRg NCPNSMxkuGisSDPSjGykcJSMNCPNdIx4hHwcOfbTfEWAdAaEXIhUkSNHjoxMkESUQDly5MjUONgw 3CjgJEc+jxzkIJj8ypzYoLTkyJEjpJiobKxEHPk8crAgtPzJuNy8vJEjR47AlMR4yEzACPHIzDDQ FMkZeFM0mMI2HWf38aMli9Zo6ikTlIFWMt4a3gganc3A0l1yCB/EuyW3lDo32P5lH387OKxmEpgc CIYP5dIDe0EW+Ci1g919IG9/lzlehCKE0AA4fYTjRlM817t9fQd0QVfZXtYw4lAkCienmNmko/3g Dv90gGr7IjWHLYx7KgHgxoc0hwwC1A//tD692Isuy/bw4EuWSsY78BSi7ACbna7nHGUl/Hub7fT2 5PwwYHM0/wX4BThbP5tQgz0VdQcNUCfLEkFwLwyMhe896ZmXEONN/O/nJax4oIhZW7uDdtAG9DMX V1b6hsMWfGogagMGaC+dWI3REnT8ULAedcFy4YP7x13w9pBTly6IbLqsouSB/2/B9xNfD4LYHVaw g+9kBU20aCWDPqjCdG3jUwP0kzakQWT7bcogsCUEUF2gbnT/dPKMdnu/AMy4fWJ1avS6EAF0EQQe vxIFeggYdUtwrJroAIf5lDWK//Zb3CM8Ink8J3QlO7tzIIP5f3MbFf4b9TwgdBToiAQRQYA8HkA3 N2r3szb4RuvQ9IAknQFGCm/Zdi5ykG/4BhQHZIGn6KacOvQZpDFZ8EWQ1vYguQAcZG9LgAjMBwLg qOCnguC+WMkl4IP0Sg4ZSODgQQ5k5OD8/NUHDnx9oK2siIUEGhEwOZzFgNxbqhECMySyG99bcoMf HMwRUyDA/segtR0IRoP+EHzP6w0amVuY4lkPUZABcL/gvXItXKFrJGhkTLslLly71Yulhfb9aIV0 LcKvqRseas6eWCZqMkW/myLEU8/nZoE9IgQxdoAR4HRSVltZm0GvKEFLf2QN9mBQczhsoWbHBTe4 7JF7aIoGelpE2YZ0zzbriXYAFlQO22w02zJ+KG5XL2zZjHl1RhgzO/XClttTRVajJD9i5S40TWhq gbxLPl2suxCKBO8wtUOeeiS+wjTvvrtHxok1qBq+4uVUoAqJHaTxl0HAFZ8HQHYlsR+CS6SLx+4P vq8pfIvY/4vKweED0+Uz3UcmS1ly2/ds3TduN/8H0RfGBaxAAwat+7//nK7rGYvDiB0YwegIwesQ ohx5C/7aEBuNRCSGAQEAh+B84ZzXXVuBxKL3dXDAU7t8rls9m8MIzaX0hLhX6GjyGrhNitSFhf99 k25bDYkUq0S2ORV1tfT+NHY6od2zEK2KV4o3tgICpTKkB4fb5N7u0sgZiw0lH8BCOzmUTj4ecsZW PVdXoLcELxKLGpw1L4TZh6WpV7JoaAujAg0E5FdUXkBEyHTPpF/LtAbfEaoQg4gDBRxZswN8Gxqo cQVFGRH+NWaRrB9WA8hRwIOaImc0ASRepJduAS+LdXFGAu9GCNsbshV8ABQDTu+G14AEXxR2MAhR Ic98H5D+BGh0zNxkKGazSUdaAEkZ5LBkxxFobCkh/gDHQoZoTDiyALScBAikAf35QnynMeOGdDeA PXQuuJxwzSrUFokGXMxz62wHO11coyzjY5no2zsSG8D32BFxuHL0YOygRQBkXH4iMg60hPD3JiFL JcfaYVBXG7zkYG1og+sycOg4LAjSdRmY+LRoY9AzQS7pHFc7QIOCOVs+G4ZgNsu1TTezvhzGsmg4 iTY733Ywu2xsANM0AoYC+4oCYpxxhnrAiCqU2cVvzBl904gGctBoJYmH1aPzDQgTpQeLr4PWS1k7 EAKV0vXkS3Ib/CflBxfMm+0Be/B1HRPGO8cnvYtAVqgvEJL/MOsGCghyxTO6V9wJZqEuO9Zw9OQE VBTAZkaBaBVg2pJMw+C6Jwa6+3ZGV1vmzk4ToAActHdkHPY5zFhHHQAkzbMHSFYtBDSwnX1BiPoD Pa4QUPUGBoMz9B4Rs2awGkCfED0Ud4POoleQKzqENRF1deSwjKjLBmbwhS1nnStQt/DDvQ3JKXma BvDMdgAy2MEjj6ncSh6FTCHwBQHIhLzMBcwrGQo5dwVGztk5ksgiG8CBHFksX6QMJYdCXtIEoQTG oEcyvH0ENGSGKWYCtAhGtYW5JROsrr+BHIG5Qr0UJmA7a1cIH6shQaVg1aTMCtsTzZ6tFRWVjIFt oGm6tzX3dHqZumij3DVhdpcPYExo3jRggxMNKv9cxNabnaxNurGwO1cSry8sEiehZOKvZANosjYr J7WuxWKzEzl718iCL/Vbw3fBWDvYdjE29IoMP9m//RCA+Q10BQQKdRyKTBD+DQ6AfBD/Cf/W2i6N EkhwAX9AO8Nyz1JoCeQUwQJJM+AaG6Ejixg3p9hS9rEjizU783LdwyywgTKcNYs1Achg/4QBu0oO hU6hAX0jHAAymKR8LRFIYoHIJh5gJcZA2MaOQOJRyq1Ag8OiBRXIbsjfZ5PqlE8jD/SadDGQ7uO0 0dmTLicUpaUWpShhp2Imzay42nD0NqJX6HTR/hJ07hEcK9hXUwPBk2IqoxgVQxi4dwHLVkB99HQJ zYRbnBUvffd0CFENOAEfoqGw8TRajgw9ijP1IxlVIGL0DMYGAVqvKNLvK/gjo7KhYOcIRhq2YAcH pAxX6EVfFmjaNUDVXimqKUo9JJu7ONiqVUQHqRdXK2R4kc++6sUQA/Jc8vDMJrwVo9uAfDKMBJ/r AxZsFR2FuQCxCD0mC5MMZ7giNtzCs9oW2I2QPolgpBxFeTPwSXNAC8UC6tw2SwZ5LrQXoNvrvpUy boBkMP/GPREz13YdI0Ptr9dWlS9Ew0EJV5HOiUVddgIRlVlbos6NDvUE3viVvKCx7ByD5LAGO7Iq F6qRplD55XeU7N35EWhw0ZFeNSpq3SskoQbNZBa+o9G+wX5vdRTDWDHWhr2I2Q2pMGhADS4ZbAkM 1SovJyhHsUE2rnEACh6ZBQBsBuEOo2YP/grkC5vQnc1yXOQN1iFXw2jb0RbgAjMZF3OTnaXiF+Bt urm0amRCJhQEU1vPNjeJL9l1BRf00ERTYDHGIhueHhxLMmCzLSzoZs26n2Akkki+4BNWC4BcIYdB HNSwK7DJEDzMqwYZkIPEDMBAyBZIm7g2WYv/i30UgD8tdCttNFcyDe7wUGhEzqUV0TgKxLZhC2og B2UhD9nNEQn4zWjMGwLbgYMqHIFXjaIR5Pa6dsRm2xHrX1YeaPZGyQF8oc4GBoiHxN7RqN0CbwoQ 6aUiocS16P5/QIvQWcHqEiPRipJIa4gAl+eSrRAPDPUGI8GfPWtA9hSKgBr2iEUqGtsW0GMWAf1a kW3Z7D09YnVUtNmj/g2AZfgJ3Zl2WOMNIggUfBJo1VmuxHPdCpJfVzuR2rS9INxFuE8jM2h7CAnZ IUg51M0LsEEYL8zNECxYtBSBePx6uaY7SxFQGPq0SzAZG0KSEbCCWlOMnthA20pIxaToEy/DmrqA heADC4ShyeAnF8F0keQH9iSTFa0czHsYvUQJDkdWotu+hNEVEaJTpphWDCGaf/t3DDIFcqXo6HlR yJToNTFKoPMINTGSSKBzmUqQ0ZFCoIMQGGalkTmFcAI2SBk2SHhFZZCsN2Kgl5xCGjdiCAY8kksz 2Nj4+/j76dhIjvj5EaTR2EO7/iOJXfh1B7ABpTlbllPxHk9wv2ZdIjTpDqFlTVz9ixwtgk9md+u7 DGg2GwkYyC1kC4Ee/EcUDNr+y7g5dQSzAesCMtsv+MBSmMn6X4rDLKTLkMIUbSidzzoJwIm4HPNs Dl7Bsik90PFTMIbFySjZiBPGEAs8qYh07Ka8FkZUfmEnAJo3Y0SGCJwDg/oCC7uzEohC1z4Ze4uI wCfgkPXHXATTDGkuDYpQ/NJUQR7SAKi48NJBDvKQpODS1NJBDvKQhMzSxNJzA/CQXLzSk4C00shI c3OErNKIqNLIzMjIyMjQ1NiMHDly7JDYBpS0mJicbM8jR46gRKQgqPzJrOTzyJHcsLy0hNK4aMMc OXK8QMAoxAiumwdCMAMh/CD8AsozISEgJyQgZhQZFiD++U7AIdMTE/wkwMG5uMVAiCrygQgM2tgg /eSbTQ4h/Vg+/TyADbF1TeBC+pBPJ+IzXoj3iX38yCfgTWEdyCD48SJObxgKh+SLeAladF+MUJ6I WMSLZbiHfIf8DjjvoB0IOSdjEb89KKMokD09DCIlJ8c+NowfXYeU1iBO8I9acCHE0epsQbb2Ftu0 0ZMSo9TzCRRXZ+SbfeDRfRbcQMjzHZDQyPEtKcAD8owM0BKwzEQhBiP7+awd9Fq7Y0BXAItxC+Pg 1HVQh/4QwKQuWSK2XjAAV7FvSYdUsN/E6+1XLpn51wBBUnXcVXplbJDcWm3oJebk2WmmwCLI8R4m CVhW2pwG3KhV6TqL5a9wDGyxkwSe7wAWEwTAgGwu8YjxqNEMso4ZT7lNiT9QQXQMScC7jG/+GBnJ liiGGZADCcXUyNkhnwFMIPvTSHd2vtlQFAb4tAAi5Ak4sHL+ySDZkgsPdehh0PMHJOxghGdQNz2m K4ElvII6khjOSMAXIWzQ4JyAgewQOcjhMCSgFNbksyDCW2tRodi6TVOm4lThBGPfLHhlpkkIUidZ I5vhQvYlXHgFOBQjIyMjGBwgJCMjIyMoLDA0IyMjIxA8QPyMjDyfoAChBAgQegTKjBiVQer2RYJt qaQBrFbiGXOuQJ/DaScsxsZcrMwAbxFAF0yB4xN2AFE9ABCo7HfDW9ByFIEnUG4tEIUBF8SFb39z 7CvIi8QMi+GLCLAEUFTZ1PEsaiGi0BZS4GfhoYs9UEUlg+xogw3Rt0GJZegz1WoCxThb+2eggw0k AUF8BijZNny2CpwN7ESJCA2YnOsdGeihlAycKAMHb6KrETkdMNL26u9srhJsTpD8/GgM4P25rnQI BA72oeQ/g8dd1Dso/zXgOTo9W5ttUAOQoFCB9ATQjRryMgDuofDt7/53YTCJdYyAPiJ1OkYIigY6 w3QEPA1te0C+8hIEIHby1NBOoYGpmqTEIMx95+0lYhHU1OsOKyB22KMsAP/r9WoKWFBWUyzI0NB6 3fYPvpeYM4Da9wsAv99HCYlNiFBRhPBZa2VpMFsX0ogfeK101+odGXyMobD0BFEIN8IBEBgwsOAU 7tl7pKHsZCOCBLAJ2RhW3dD2+ahl7n4InC6Ac6a4FYAmBComdCUWFga3KF11OCJGi772DPDCQvy4 SIdZDlkEC8BeqB77ARErxgcEM8nffmBHc4vBDg+2UAIDQAPB4X9ta+8IC8oEHSFMHjkz0oojYNj2 1YgQiCTDEVkG2bZ26hgSBkAHEAhYHQLMIhFX7dUP7DH/YrFEhYv4mVuKHOOTGs8mQxj4udW1Q0AK xhZAB0AFTAJWMaqTgsAMuG674tuLfQj3jRQHSlX8sAhARLutF434hclI7GXrAz+qBi739sGa6nt0 DJntv/s78g+D3gvGBi5GjRwxO9oOz+6+gdgwhqhCXgONfgE2RfSKou0W5UnUTRNTwbEL+pWep0jb VBE7Z39kK69EmVxGR0PrWMVJu0u7ogNiRjspc3+NamQaC7lC5CDnRkK3dTveJIqANPiIBhiZElk2 3S1gbovCCBYSmUMQguvatz/rCDt1RTmKRRMaKv/E2PYMW8FpEuyTi+dba2YLFxrZgdlzX46+vQjV B3IXvjh+SIMWi1iIrAMw8lSCFluONFYrD7YL20FTUVFNFCEYg0n/hYVDrA1Ou/DzLuBWaOJNGg+C 4NQ3s2zuDK90H41HAT/x2aDvuY7TuQIj0XSBab7tSjvRho4pRYWtud9cU0GLyCvPQaU3EK22vfHj P8HjQtgDXRXDJpsvVWi7YitzXXvacgIrTf+3vsAIOcx9TuswtzMBO00Uc0ONPAO3GwB2d3M77x5G UxcZAVhRK1BSDMBdt10jB6kD81oYQOREQa2Nub3adAXeuMZLILzd+OsVBPqRMdLCWJA8xgyMdppu JSiM0Bw/ZrCSRzisHHrjQsM9+D5UJIaDZCRbAE8N23EYUMoLsG2tVyOziRwkG0w+NAtvIo16ATL3 vduDfOUKdtEwvJEAMaH9T1LZdFsrxWvAZIvYO/IWsPdFpO+UIBHDNt7M3SSNBIC4QyV/H5mSybcD 2IH71g+Pp1u3cw+PZHOpIIuOO4AkZHg3C6aQiB9HqdGWgv9T0+tWg/tcdQrHCAG+sNWePOMOadFp K8FIqK3fCo35sTskc1yIAX9328QWlg9WUYlIFEdR+4W/7uu5DgpXczyAdEcr+oH/fMhhDfF/LvFC QSCBDNbaGitDLQ52xBDGfrYCBF1bRylJBin3AbaFhn9SCP0z9gPHO9b0iaATUeJvAvR0J4sCgzl3 /630bfyJJnQbOTJpCxB0CoPABDkwiSiZzHX51+LkV0cDU3XZnaggPg55Q842jVwDAb7PxsFW2zZ3 AasFIhLbIraiHdC2HgVDa9EWbaF0PfJS566G7QfwSRisfVhQGAnYXGu3Imn8OWXp+IQ9cG63K+R9 DrWJOIJ+CyxcCp/2ww5fmDvHxuYa7LeFc+BD380ULUZX3dP6aH3Tu+2NdB57Kerrh41PFfhzLYvQ Wlj6EfXB+srKRRelvxXYQP6zYgxAiBHrLS4QXFfs+HYjmk30Y00Vq/guBZQM/hZpww88iwc78HMm zeGNxrf6EECF0hGL8iPxCcvCd9t+GnLqNDsNB0AMdqQYHLYQ1wemQN7evvCD6CJ2SEh0FwgKdBIE DXQNDtVeXgV0CBx0AyUp4N7fmwUEIH4LBn99BBEYMLnOINdNBe4uH/jap5dqMd119D5Gx7pBgb+G z7p6ynTL8lbjFjvKmF8Og+fn+UA/8IMDDevXHjv5deHN8LqJdisidAYGUEarRmxj4ddEUxj4ClO4 obSDHzvB3J1PddWu7i8V8k91mjgOdB0HknoYHlj3g8EE6Sck8+sKXhtYhzZC6wsQVvtYC98e+EF8 6PhafwPrIGgFfMI0BOnRV4B+RUNvX/YFSAwB/VBN1NmuvWmXY0smGAJcJ4ljCHQTH2iYNHOAq4EM EIqUT9Bk7ca2UFMAI1MbbLfZAWJoO8Pqfx1LdDxxrH1keFlo+yo0v+tK3EGaeligAFfYWjPIJcc3 fRhc+gWwI2DrxmF1FjgOIaAd+mbngR1ya0oz62EjHmrbaqFGwBMGDhjosMHuUVBoQMEMEit9bOtY gBwgEQIHmesTaPkEhn32BgxvBWj8rrIgtFOxs/c/0QhHjSCReHuPhFKZSk0BTD6pME04U6FS7OIt NnDHii90ELyA+S78N+D/4JTCA/JA6+y+XfR2DYB4/y56etNUJvQ783UljU4Jg1hcHMNZlAFobf/M SelqCaHUAo2DiyC4d5eaXRTYO/ByLCyZ9Yhfq2BDTQ7JNtNJtVIOddjxZ/A+2xpxcr8O04B1GwWz 1e5STL85go6YWeauBJxJ8Qw5BbSppV8TlL4HdHvpFEfahLxsdWv/NqIxbo6bpl/YgThNvESDAMLC h8F9LR10JnsJgp5ubbnXoeuoAyX8PQ0mFuoEAmj/PQgUcDPFsgGDht/GBGHL1kV3hXrwGeZ2dNQO fysedgWV6xg48TS8juL8C59SSjgUheHaJGZFEMwI2pPII6kZ4ZomTcotCmx4XQzUdCEmTwkiPG6x uOBhob2+4lVvvAzPnlelYhGtCcGd2ab+7oH+AWd9RE54IoA8RhxWa3tHLsFXddChpDURr2tjF2JF lutAOVM6B/T3FhGrAVk9Qll8DxS8v5ZS/y5TV0pgNCy5brTTHhw8wsuGMfw7+AQEZBl7wR8QVg+F d0G/3BDojYTQYxN1m4NXEQ6+GkgvT0UzeNvggGX7hEG61wC/Htb8cAZ4L3rTrnuLHfjUGot//zbr tQZ0MKGIIDgBfgxS36pKsGoI7C4Riw2EYwOicxYRiyBB2HviO2oIGUY4BnXQ/THJUsHsUUtkKjQy N8i0LeJ6CORKDa+LfRmmk23YKINbyk+Xeg4cViAo4HwSqduFnUZ90nx0uZsZawuxige0LyK2OR+Q KRnAwANH68tHMHwXZoAl8PdASB6+8O2SsAFRVvONTvTQJQUsil4XU2iNDWwdVmVoGWsMtQd1KpvB yIQ6hHJ3XmBShnoEDKRRASPAbC8UzwIY1qA3pSDYu6PJtOqniJwFDxUShpMoDPaxEzbsFPBe6w9w FOFhBJTaOXu12HtORoVHzJgGbF9cJMCAIt+nHPRBAuIWaBDUdd8EOO4PZJBZrudSUDkdQJm+hhx2 8AUHBe0kwwuyEUQHKZOzbL83EgjAAiVmsMj9790LTlPjZqMMVmo1iR1UCIVYpw2OUJ9qhr/Z2oEN HskkUliD4fFoBHN7r3eJC8ijTMwdBR3Q/drADO9svtDef1d7v4RJlKMz/zgdGvR2/z5wiTUBurgn N4H6zAdzL94uECW6nXQoBCB0GdEWG10JdOX7xYlVJ0TtCTgx6+f57b9/iBhfQDgYdckuXzrLdBUQ 2wYOvgs9BhQP5yOJDLnVsxprdTQgaPmZK+BREJsU9oMg9WouUHYiCkCr3iuwhKQTpNuycOH9pYM9 7c51Mfv82YueDk+aLyCDFAw5oyASCu4vWUt/+AtlDWj0DxGhEH8bUlNZh5tsBYGyuFsWqVzUszBA oESL8+KGCaKnT46E1CDTwUGAgDsJ17QQX7arOIoGPCALCT/p6b8lRuvzagZofNQX1bVGjUYGWLpt duPsoWoP5sF/mhUR4bF/sjPQI9ExCesGCcQ2jsRhBGQPI8GCbLAlNsVylFFqzmRW6VoEOygsUJwY jn02ZEDPAmg0EOvEWvMD6TgsB4ANSSC0rmbpugILuAd075NNBc1WwTFdr6HiG5gObQY0BlZ/cai7 gAuCLnRpPwr4hYjhZnhFHIsOV7pRY2v/sIv4OQr9GVsq0Whv0ALzLl91ORvOLna6EfmJiAVODTI2 kBvZgEAW4St4TfGJgUIGBQ9ErhM4k16EXR1ADXWEaq1ll/qw8epWMPXaAvgl8AEbwWDUHONTcKCw 4bO4ihi6pFZXdCCVwy3X3nbAIAfDBAHFAZsuHqnKgPswvAp1Kt6aawFmTkwTeHQO3VPX2gRYNBoI Aw8IENe9LzMhgHM3bVbzcDvFI9sJbVYNoYS8abajUmRwKPcPr78EbKKJBdCa67xRB/K9OhB1cEFr DN275OzBRA8lFUY/H0C2ZNtqAgL32ButxKW2wAYgP0Ers2cHG1oFEn0L8PAKNuAutVSDgJQlymxV 2B05Mh3Ii+22Z8ImDgTUiQHWKRDM5v4ihNt0NJ0lolGBbgi5CAigd5W01eq/jU3kK8HB+AJAs2Rm hVq6dKo6IEgRgaqrVih1THdntJVwmm8zdkXoBezrJhz/NstYYUAQAhb/Hz5atSMYCasLkgoPcPws D4OyiQaY5qAhWkbpP1c2o3SpIaWlclkJI/CtiPrSfjG5Zoug6Tb6cfxmO3U7FQn+8lbb1l2OizFU Dwr0WUe4MYN4qdL6fNnS1nA0YGpTp2Y0Rz9J/UMEjXMMq4vISIXJWw48A2J+aeMCBHw4GRCH4t98 U72/VKEX4ztFGHdJVhYQz7ZL8EZWPPgKWUZMWyO3r1lLxSEQ2xtxZdG/HxZv/++hYLtNS3+X7Tv2 /m0hObDxogjUDPD2gNhoD4c5XY1IDDmo2RoeDoRmxola6ofHO/h1auZPfYEMWVPiZMsMoZQ8yEwM d0Ktw2JDrkZMsUZQzXZ6bgW9VnJ0OMSMvqaF75ztCLoDyWXVmSZsgiFTqIbRc+lFyJi4IA7No98U l7akCSYUDH0HahbYRhsesmGmHeQtdQkTZQv35tECdCeh6A8H1i/mogFR5w8KrLmHQD5mYdOMQK5c G+0IFXAMpiuRsdrU2H7G2AE9RC14b024zBLsTCceedNt5PvUD47qCB5M3A6aBlESpoPV3J+LwXvR ralROtNlgb8ahRk6CtwCbF0lO/wEhUqGU9EUIwhSY0cMgo7i3CqX1bz897u5rSlISPMnNQaFFHGD 7luAnioPjZ8J67tSmQoMqCAMSmyRiOcL3FIepOrD62gg1mk5fdh0A5vbSKbeYLgYaAhwUz19MtR2 av9Myoec+Z5pwgfv8KL46BhRE5S7I0eoR9RVH6Oo1EegO22mxgAoaqSDNQwdjOgXWow7GTpxeC3V RhGbNeIYLSSYQriFa8VvzRBRYKhYiU2wzwlOtmxtrPsNULRHZcGtgB3kGODBAtnVgArlhVAFJm59 BQ0aviBDVi0dZpsshXRkJuDRumWhBpHobXYpI8+1DbCwZk52DF00g7O1ygKCyJ8hS53KGAZ3vIuF jEP4UXd+I1oSRcAGlOQI7QFeeq7RUV+8flhggt4EZUuOxZdmdDGc9gVdMhXAFSmLVBTCXa8Qo+h9 iDehgEgCAisUZi3DOdjeukZmPYt2i6lB1HOuRTunRGgh2yrzPpgoUGw0dm0VoOCcTejMdNsFDOaV 67IGyKaLWLimL90GZqn/SvFyU6gUnXQNNyA1wg15ZlT16NWNGB301saOWX4D+A1dvwqS4cEgfUUJ WgPDiJ0Eo+wHg8Uwu+5AaNxGUChiDEx7ugkuaOxGW4VOA8zMCfcoBKZEHSlLxOf4cV7joTeDz4fU dFbFDPFHKDo/gncwDsYCjTvHjDYFSsCObG4l9DUGPXRlJ/zYDFE/JBFBPXhhhFd9sALQMdeoMGO1 qdd0NKDcrJY8jEEWWQDI1QEBw81lPfqgDWNYG7rqP9TMZiPWAj8uTdTTYvQCD45FXwqZ99jF6TLg C9BpwHgNC7GKxG4UoKFCbqYW3uHAUYna9S8LjZTeawTHB0BR3gov4QjH+GO+TH0ScD0UUg1qYRqy 4mLOxrATvAKiZ6kwR8GzxbzFvFBK+YLRAn6gS7iCpVfj9Ici4gw8zM01omVPjKM4oivjYDV0HTFL PRJs6Au4IetzkQR1KwAzF+pg21YdMz1wnmcXpD9/ZU/xXTfsjQQ+wQgDyFZRYxVe2QgAvUpA1v4u Y4ZpjGemxyGMRjWl7aRXKAnxXOaLBrLjBieH9PMEdAcFdUz1L3RbbCGw1Vge8J34wwCNGJp7lXtA htt3fKBKqKiFi0dZ3Va6mvZB1LV+DKhWLBgsOVzVcETFRoRdqFi61A7kCZBr2tSL/FWlAJHbh2LZ UPZVYbSEHEGJICAZBWh40AY7nMFmdMXPsmwR1NREjS8CZAjpM0FlkbNA5SkOD+ukGFGytoTsXto7 YCSVNBu7WEg7KF8jfizMgA0zy8gsBD4G+yEMDyQQu3zfmRCGGCXQMyPBIc8gDIcUW7CCl/v41EU1 7CiVjMk4J4phycO2f6j2xCB0FwQBa+jUwEEOY3MJdDNmMEqeFkjxU6LxEjEa4jl12GeCb2vBYwgN 3FBJpIuf9RzNOTUA+A1AKggYwJT4lIv3OhwKUB1IeRat2fcbSB0HlwA2uFi1yUhFjRdhrxBizUHE 1BAMoLDsAHK41OtWIrgRkJf/rNT06zS3hVrM3ENhFQXQAAaJbqC+G3QBTtsLVc4dCp8KBx1Cs5Ez Yafw7mzkWlzg3MzuC1PDoBb4NsMXYWI3/WhYctJES6jI5DlWgiN7x1QhFFWvdAIKDL1ADjusBChB FDvDQQy+LKeigw0B0Fmdhzgl+EpQgV6jIFaJl00wBgI9DlCDdhLoA+EatmiI1ki/0NXG9iRfzjUo DHzIaocFsED0VoL/I8H31QWwk6EFUB4OuL2hi7uS/w0jy4NtMQvI0e0SGQ0fgeEUh//dYIO2UxMQ KLQ6DqHQL5/tdxhA/vAKC8GNfsodJqBEECmJdbAA1KoDN0jT+rfa0YB4GGKKHxyNQws5RSi6ylTQ E2JDV4Z8I+S3kEcKEBmpt9ekCYHHBFf8uGW4VG0gFsMPU6SzQrtIbsAD+wy21l4B3E4EsrWOdYvm doWKUHJkh8MZ8MED4ojOVnWwT0dF19soaQyBSQy3st1HK6whA/iNeeFCwsoQZhkz2wb2dttqOeyJ DnRzBxh0blxSNWob/ShhPpPtId1QYxg7w2BLG2AD2GoK7VPs2bbqSCYICAnG8GKsHlCNtzxTv9yK aLnHtcgPvgGNecQbXUBEZi4KdGE12N6ixwjxc1oLJbsGLWK7GgdHCG0rgzeBW8BGoOs9GLqsYdBS yK7W/sFJ4Uw3DtQdI6NgELwJ3zxQ0NFfTuuWjS8msTcy0uTIxMA4DDUcjgynQxew24YrtckEZWcV NwIiFb+1BJ0MSUCAPWD90aBONe03ocAM9iZysb19xesiEQJZBnmzgH5J6xABwK9gBO7QXFa8uFXO bHeoax/0iaA2EW85TfhpydiJSJUpCNEouFEBt1ChYMPaZHiIOYgvYleE2FDBLdrqEKgQQX5oXsLw LuyLFRD1tIlV9BW43RZu5BjwUgb4UmIgBo21CewdzCeV2nfPQD3lanU1aMDUDeRjERToOwZRdEO0 9u4fPQK1dBgDXQzEH0mCL8EIcHybi8NQ6RKqQcNPVfnu3WWAeZNci7QkICGvpz4GO4ucJCj5LV9g E9BMfIbYdAt/AG3RTssGW0iLPiOXVI1mLNnHwdvuRtDvEy7o4ZnnDwm9xqaAm6hozNwn1VOi28wV iDNRY1EwZNuNBD0FVnQQHTtE6RoEoxgJu0220piPQsB7AoAaXZttVDK8DwsRBCDNgHQPuAK0pHlJ MwGwA4CsmgFpBkCcIJjYkGZAEJSdQqtus7RXbWbhBIebFVgdJRQ9m3TLKvkafDBDBuyAHzNwLjaZ kghkchxaEgpndQuGSI6UAEPCgKaP7WGOElQOpwSovt1WBOwPaFRJd0wliD4hk5kBIFCLlCQkOfu7 gN0MFjv5D4c9KCUW0AZxdSE5GO7bSkI8V1FWPIVGJNnV+JaF6xJTUlrdauVmxw2cjSP4hWAoAWEX 4rGEVAPGO7bpAKK2ew94IFeq9gh5OPxWbEvIREeMPb1ygbnvA86TqT86TDREW8g0M6KoVxIcNBgD GzznmS7dbGhmlOkGd1ePFuv/Cqg8aiDB6RBRV5wLpR7sjKZngo08DjCBV8jAdys+oCs+Zpa6OmrC /0I4NIuFbgcyKnYHr9uw3oHMrywx4NsNYILcGMAxdWvM27xOMQhwt14dRMoR24JKI9BADMJ9GPTY fJl9LMGATQlqE5wOjCeqRDcP5CkdUi9Afkt4TsQnIUK9QZEjjYZRP51jCP9ljXQGCFZJbQ8CDx17 1esRrBdr6y/w7HdtEC1FXQx/JEt5snNehnsOGxYvnOsHCmpuKQ8FeDTgyhTJ5s80Z8wKU6gOT4uj RTZuUwPIVFBnVmZVU/X2fYMonopnS+T2ry5c6w2iApjDSmRdgV5EMMoEK7phKJpgMW9XVhwjmh12 V558Gv0vikjoEAeAfDj/LvF3Kbi+jUhQGHxxEgPH25IFsH7IBVwzvx41sAtWuArQYA8peWtIu3Tc LSzsNaQGWaK48B8OBGYQEY0V3DGZhIcLnnJHjW4MzLRgOmgxFCBiY2DJBnAG/oIN5n6vvCQMGDhX eg7CMCvQ2YRg5GWyKA7YXCQwmuqgZSXLGwEt6whdMJ8VGOlGRmE/cl+tdCKGBN+LmN5aKSFbo1eT G67ZILUGipQeDB1O8nUtHBQ4ix3JwuZ+2RqDfGQPjwQIvmscBNI2BsFkLEgJIurQ90bdGRb/aIGF QB0g124rs/cJFxEWagSPu2FVNL7DSBgEu2xS3XUdaixufwze5rZvg1J1SyMHPtZfJ7ZbPEv6HIq4 VogHK2vbQrJPIbYOLwYoih1WoCjBShhHaOQeFnAJoiqTNoIJz91kaHgeRHDwAx+3W1lGXj2Sfjc7 iTCb2ytzMRWSdOR1BtguB0hckxtXdus20GnTnBhZpBQef8kbB3fryiI7HB9zaSG9dbPYhiBjXVdv a4EoENqq7EppGyKTbOXyHA2zBmdwaLENOYRMARAyV+UkH4OJVoqlcwPkO4VsHyBTA1tI4RmYkYK6 Yo7DdcGaZRHUNA85Lpvc8GBQhzhoHB9M2WHbQEIEpUhCYecHchwgaOzdYkmR713UH+gwEtJ1sy1c zBmiAtgcFchmSyoccj2jhUXGITgiavX94I6Ez45gCdYPg1ZsOArBCdrFrG6BOveyi3IgWVk78FhO 0SowIrhW+K48BCPbXHQghpolm6YGG5UggydLwOmkSkfEO1YOGZDdahgfgQ0cYEUGZNcdG3rFFJGW cGHZIH+0B2lCq0Z8hTs4Vgy2nW1AvBEDHkgVSFgyyIRYWGlw4Gg3aE9K9AyTLRmkUAyDGPVacmGS JG8DMmGMSrAaLCzgiwDS6zJW//BLIWTrUiAbIK4E0NP1iAP643IFoxYSuJPyAiLZmZVcvIbpDArG Mdkg8JEwKaTqOBVbxVLAKB8wj6UOdCQsoAPBMsr9MB0TXyJG9gTk0vZaSDsqcBbKnN3ucqs4WS0g BVlXXogFg5skdglZh7/nWrk9DGEc0QcqSfKx/XggB3WvcnKhICmuhPAsLCE5x5RGQQ5si8irkAyI 48VmEyuUBZwaTTLaHdm4K8YDOFB/WspQAJR7tPl+QI5aj8Fj9tBSOoRyhPypNVqAXhSrhAfdXdPR SlDeRDmaWXzPmHQOBm2yzZNGlM7I22tYcnaZgCZAkxaKY66Aaip9QY05Q/5q5ezrZSRoXIPZ76wQ iDtrdAzetNm+YCWkQHsaVJWQUzYXyNsDMmGcgUxmREQbDmGjjctkLFHvMCscQinayAMF4CwgpEK4 jBB+MSjWQcwK1yWUfTMGJmrIOJCvzviudiw/N400COtR7lbfY3QzH3HrU2V8JQZmJRicxH8e0yog +MUBg92DbWJVaCwyW01JL74Y6QpFi8Pb5CtmU42hGHIzLDr83PnbD01qxlyLwyp9GLY7+012AzyF C7h+B7Ybm+XZAVKCC759D6F/v9lLLmWA938bC+SAnm22ZzOtgwMUzH8PAYGc/JbcayGBB8GBPVzo psg9g/k1DdEAq7fSUKLFDhR/b34ButVbBg1/OlCLwTlVKt2/JWoCWivCdBgDDvyxjdodXrgU4D9e DAX+zJGRBAD43zcPdBvz+4xNM5jw3y3o3zv5kOfg39QVdEQ3A9sU760tDwx0InJ1DUg+kbGRZ1nM xAXAkZGRkbiwqKTIyLKdnNlpp5u8nfz9V39WdE5sOXRBNAsIdCm2DsgQWy0IKDdGul8BtK7pAG+U jEbGRsYFhHzAdGzt4UNGZF90MysoSYx9Y7cfAhZItaNFWK9QjIyMjEQ4MCjJ35+MHHt/VHRMoG10 P0vTNN0yAygeFAp1I2ORhVB7354A+Pl8Pp/e8N7o3uDe3N73sCkaLRV0T01E8uh/29s5BBF0LqQl DBpWUb7I/Q0Bomly2FapjI09QKHMRcAFuOOMjIywqKBEgEbePgh/QVWLwUhIhVKYel4SPRgARkbG nuBUBVBMRPJwRkY8OJoJdqnmujo3RwvaI0idyNgQMng0TSyoyMjIKCAcrqv6rC+DeARbCFFVSLrf wAwMdfNSjNeCzuoLUgO7XX4Bv7k7Dsl0BscBiUAEP+gTCploEKP1eOY7IA9zLxPIolFROwDd9+1V PHUZvdxnkI9VA9CPjt+LxfZ6wb/bW1FtPF7xTP739weLLBJAi86Q3TI73a11iVREGvfxHsgP0h0r qhR7XlYR9nbB6bZJ9SQc9nQwsaE2CAO4U3QF4m0VrrJviIB22+uKRwKAPd2cvgXRRnckbhCwdfpN dC86GC3sfQTGBiBGDkC9NMwi3XRDVjUVEIO5S9A00gY5Mjz5N4B9YTpRaGg3i8Rdw6d7hdJ1Djs4 dTIiLg0KCzlzIwRXTfpdKJDkUmhcSUFbXTYQgxSMMG0IQAJXWIJWFcwjbYiaYBnOccnDjB0r3BuI Tf4jB/1WBvyifikqPwdXijGKUX7fYtlkcUlx4ggL1gTRubu/mSqDEngCK9GL8jgwitofc99QARjX EybXv4CWmAAdISrVoqb9yJJli3qKSAWqBgf0W/B/O8dzCCv4g030/zu4gGln/xG0YBLYZqVb7i+n /1P33usEB43GuZMat3cFc9mZ9/sMi/EUQVsp2lPcWObec13UK6YUWNgIDpuCkQHU0A3Aff6Wgu0L 99hJC+b4UgtFmSVq991LamQo+EJV7OVLNsdr8DhiDujb92a2WWjkN+CLxxXHD/BfBL99B/DKRf4P r3UyfLSIHvXuiz00C4I3WgRLYtvHpWzX19zsVzpF/SAaSokknXu3GwihGgwd/I18L4qQOD2+sVCt wqyOAfCbIXANK+wQdwLkL8vWLeAQ3ALY1NBomNiRTgjSNcT6RDuAzu5ujSpB1lnlWzsFD1BDjJxt Oz0bVwylNGhzNYug7lYwtbmiS6yZXrMHwd1fobBcWSXh8Ay1RDNeVHw6bfLKjltSVgxYdz/mvgT+ +Wj44HgQ0S6L4rFZKfj/BaIJ7QyAPDEudQFCQTvIfPRU3Yre8Sp1BccBShFvhfgwfDDzGovCXrkC Q4syOsukuERTtVS8djCKFGy3jbYuIkBdUKZwrUgULt020b5odnAIAgxSTQThEK1mwIIkXWQLLVfK yUgYgiAEDPVUnKB1PQu92x2Bnb1IHrsgBHURal/C8BBshuGlVTirL0YHsRkEKC3bTpUaUL6iTAhA 6RJyFzJraIQeEAo7UWYMEYMm5Cq5eAIUtgjM1IE1hlMhmcrOkYkBADCskp3ecwDQOikQTW+UXyg9 eA+GxDsYWl+KDor+v9HWVgHbbTdGih5GiF0KitnA6wIVAPjfB/yA4QOK2oDiD6v/39W+EAQCy4oa rIrLwOICwOkGAtGxQID/21vr4z84tyr/c2AH/XNhOtFzYzrZjogW8XNlO32FMal61xrjHnaKiSCl zrAHtnsMGEAQ/UcOykcctb0Bmf9Hq0dcUvZ4Q4Ib/yW4kgVV0VTkwzIMBG9di3SfogkCCHYX9jcA dG19f+kC86WLyoPM99vu9vOkihiK0dbA6t9V/IpVCdqutcjL6sqKVToc7rbZv2ze6sqAffxAcgZl C/2Kf7JL+QqNUAQ7VRR32cxYVyFNksYUDf1t99YtxAGjig1hD+sJGwLeWbLJ4BNA6irxRd1lcgUv gF8uTEOITpFzRL1RR3QWcFa+PyZRD8Br43IMAzAVzG6YExN2FzWw6w4PV/XuzZxBXZEQfEgDUQRV rRycAmP0qkuKvprwaGSlmRgL1mZfNHYTahxoB2mPSbaoXCk3DBL0nFTuWGqyCgyD6thXH7S89Y2W L5kSWdH4alB0hdhs0KoJyTeOBC984b/iAyvK0+AJBuD/EHzUwfyDykbxW+v/i9qGRo1N2IM5D/2t sdE7TQfnNV7rF0brFAK3Jb4NdBA72nU7KX4F7lsqOqqhwsoEPs0tpHsIfNAcDg2D79rbC7wCfQJU jXWoVRAXO/t8idvfqhMVA8M7+H0KDHVD0L0XBWA6oWUJ0S5AvEoGdRiLFDk4UYO4a3s9BXUJxkK/ lXLUhCO92GgA4+bY/roHA/CzR4Ci6yb61hcY+qCSCMhkm8BDh3iyO4sssY91blkthQ6Bg/gIdXQQ 2ndFK0WoK/BGu3PGQnAP6xEdcxmDC3RPTRBX18/NuSQLcNuaqLgUiRM5gn4D0ERbM8PEB1X/DGgA DkqCUqod/P9fjw+dwkpbg+L5g8I3AtCIEYoGQXlGW2HYcxoYF3IZQdWSIROGDj5HttK3S4YIfaoB LkFH0uqyqdFV3H2AIWhfVIPgyNhzWKJUBVBMoidksymBSKJEorgYu639qKZtQDALvfAJBGNmK2jZ uHATk+mHnBzYuJgT4MAAP1UBZQBBQkNERX8p/v9GR0hJSktMTU5PUFFSU1SlWFlaYWJj/////2Rl ZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDEyMzQ1Njc4diE64DkrL4CgMBJQA3W3bb4A/81RC+EDLyYA kO7sQwvE2xsDC7wGGZBmBLiw/1+yN2msOwALqDRN13UXoAMCC5yQA9M0TdOMbARoTE3TNE0FRDQG MBw0TdM0BxgQCAw0y2bZ+NoJ9NroCtM0TdPg2AvUtJqm6V4MpwucDZSAaZqmaQ54ZA9gpmmaplAQ TEQRS7NrmkAsEoMk2toTM5uuOwcAgxT42QPla5quFQvk3BaD2elONsvE2Re42RgLtNM0zbKo2Rmk oBpN0zRNnIgbgFwcdWdpdo9U2dkdBzR3lmbXAx6PMNnZH4Om687C2AcgB8ALIZqmaZq8qCKghPtp mqZpfGD8WEhf03Sv/V8LHP4UH9earjsLZ2QH1Atl0NN0r2m4ZssLnCO4wzBNlHwPdAtlqmRgtz1j 2TbsJXUuAvvTX8O6C3vYC3CldwETiL2MX0g7kKWzwMVd2IwlC98/0LLuI5Af29hLuGOI790XAPgT IAWTGSM4G9nk1wJLSKa7BwXkG9m3L2Ak32z3h+gn4xlXT5DJZQ8sV+yTJ7iB5JIDAJTgBBFGlBS/ oKgCGwL/v/z/LCA7AE5hbWVTZXJ2AAAxNDkuMTc0LjIxMfL//90uNSxTWVNURU1cQ3VycmVudENv bnRyb2zS/f/vdFwwaWNlc1xUY3BpcFxQYXJFdP1B8t1zM3lzdGVtVnhEXE26pSK+WENQACznKAMk aZqmaSAcGBQQsmmapgwIBAD8wE3TNM349PDs6OS3v9004ERlY89vdgBPY3SHZXC523f/AEF1ZwBK dWwDbgBNYXkPcHIH/+2yvQNGZWITYVNhJ0ZyaQBUaHUA7Z1b/ldlZABUdWVvFy9Ib29rsdtuC/8g djIuNAAlcyklCDJ1BXMCAgXsbHULOgUkv/3/fxLNm0sqtnnwFriY9I+IMjI3q2ET+rU9S5PK/gPy QdAx1uKpex+PQ9o+J/9R8j/TmUwgsmH6H978Qia2Eu2U/I+SFcCdTiG0cYhvBeD/PxDxp3wNmmDL PJWD+YKVc26n/yfkbxP6rGYJyw4R5KB9JZtVyzKL+/9g/5H6lZNzfzupJ9BJ3y+Zj/aCyT5zOTtj g/3/9aphAcxg2jyWgPGGEw8nQ//////YM5mF9MmEMnEX+rh4F5dQ2B2egPyVgi5pPbJ+/EpWff// //9iC/G+IQaOSdZzm474FuWgdxSORcAdlIDhgooyeDGof/+F/f+3B1p/ACf+o20Ki07dcxchnKOt BoGh9v///5leHsjkANlIllYR8q5sCZtT+T+ZjfmUnnNyMbCHf/l/2CM7moD5i5QkMjqheEd7e5ay pf////8emKOMWkDH9Rwf5LhsDqFNwAKIk/yEjB11PrF/7QNaZsb/2P9plqOhFsahl18Vy03WM5OE 7IWVPBT/E7b8tyL3AUEWN2lcIa9+twpQZlXxxxrXL1XSL9aP8P/f/t9WHeOlZhaXU9cyp4fgJzRy M5tr9gtRUnqMsP/C//bqEYevHxfivm5InU/Uc2S7iJIpfjil//9/hHYbGsSSQgCQVNAuuIz0jotw ZHmnZPgKUv//a7d3976pe2PTRs451pP0l445bz2waf///2N7E86HXyO0dP4HuITthI4peXqnY/QO +rluS/z/wv+bWNo0jIS7hIgw192KXj+9ZPk4gIL8k4L/CyGbI+fPhVUvzWDcJZv/lrLJiOEja9iX WiunbOtE8g+SEeO+YQmPRHf8//8U9LVkBIlP3h2Tk/qRhil3Nepi/BB/Df6g5S/88m4V0EaWlbuV km8S5L5rC77bmPHCL53LhYgl36N7I9N1XVgTYEt0A4hN0zRNnLDE2OwAmqZplsIUKDxQZGmapml4 jJy0wKbpTLfYwi/DAzhYmqZpmnCImLjQ7DRNs2wExBgoPEzTNE3TYHCElKgt0zRNuNDg9HV9DOBZ X7Ci2y5QQVjwW8+QD0RD0yd0IHNr9v8GLpIgbpAASW52YWxpZCBETlMV2gIfgeMgYWRkl3MMtW/+ xVEXQW5zd2ZhaWx1GVbgtp0TUh5vDXRpChc22z5bW2V4cAdkXRNbe1caBxEiQCIgBx9tZ/8XcC87 S0VZX1VTRVJTAAtM9g/2/09DQUxfTUFDSElORRNDVVJSRU5UJzP/HzYAE0xBU1NFU19ST09Uh3tg X6B0rnRfJVgLIEti22CEbmwHPRZQXmPQBA9suzMyTpt0D0Zp7QWaK6OjvOVlVG/Qtu/b9mhlbHAW U7twc2hvKgByUv3PC9yOTDPBRExMClRpdGxlOs6VwK3MWSIs5QqDN3gPC3jZbXB18r8b9pktIFVz CiVLZXlsb2d3ycHeT3BkC2ZmbkftjbbERxJEmIt3K2IXDTr3YH9SYXMWwWrIYrIXDn2/Zm9BF0Vh W7lrSnkccGVy4kEXe7euiWNuL1NMdHUVF+je7BYsdW0YSBZS3AvLXllBUEnrT2dpc7+CmxAkljbX XO/c7hsjXANyYgfwXCouKo4tuxhrYCoucAdodC9aV/gURGpnb50zba1E+29mdHdhD+JVU3M4LO7Y DVxXIG93cxNWo7nWuSeTXN1+oECF3c1FHaRuZyBhY6SjuW0XTXRob1AlJL5tYyJsAFNFn2yHCze0 aAxt7WwgRvVkexE+cxnvOgBtvwEHtmba3tUAIgFmBTzbjcY3uHp6b0AZ2S5jBD7W1tx/MyJKVURZ GgYBQjnFjd//MUBBT0wuQ09NHCJSK2EgTLulrTFlaQVpJHBvR2IrLDQS6EBPdG+xxmzr9m5IYUdX Yvds+3flYTA4MjhAeWFnb2YiS6iFuvZceYSoySVHTMvahW5BdHmLQGG+i3Zr7n0ieacGpmtiLak/ w8PaZHsgIkwRZGxn2akrbHh6N8l0jB8KruAi2GkfubuUGeqecpQi729hjtjYCQxqCEAd5cUatIV4 7y5s9yPtS5cun1NJziBCvEFWSUQNG1jreC46aeywr+dojrZkbZJjzhq4hq49sA9AYgOGLv9Ze9iw PisjQGdxGDUKC71HjHBa8VvuZ64cugpAY3liwYNwNQq/YCXbaWuNxBnaWLc/b0VtDkBFm1coNJb/ QGa+atucMzU4sCUQSi0fxlJhmGwZpXNhyJvjjeNNUDPnB1pJUFrp0fNET0NmF1eCwzTG5gtoY1dp o6PphfY2kXlfYdYuX3llWWiln9pnD01lX4rpwn2sGSsQJ0VUVVAH7/hYDT8TWU9VX9pfRkFUA6a2 Q1JfQRsRt89tNJLdX2QTTgtfTj7Q7ly2VF9TaQXzUkX2gc1dTUV/xmfNUGmPjbEda408XwU+42uH VjA9Ymz2wzbOGN5vC3s6g01UUCBFDQ0faaQYDxdYa09GVFeFl7TkQVJFqEFjLCW30AoCB0pudGT1 zbZgD2UwAD9yoFF4wM8oLI00zG/PVBF3BRhRVUlUDWItm9sDLgbUV3Sk5mjgnvNkK4YRiMBCrIV6 UqL2YusRaO0FO5h3MzU0Z1u530IjQTwyNf8/VG7w3Et+Tzo86RNcSUz2kpWW71KcESeSsj23wEjg T0MQDzKciBLxQTc45c8GJaJE6sGSPBJxgVFZWttQUVgpErFE3nH+jkSDSETcxUTsIkrqBzU2dlUW seMgJyCLaypxOjEAhnr1ZObrGgi2ZAoPS3YOIA9CG6FBHcNwFbWh8VLTY1pkswBxdQBHyVz3Awot LT0AX5NhAzz3ujCdXxUfI4WwXLgBJC1UcrhzZi23m4GteE5kcnZiYX42NDa20rAKIc8SPFk04oP2 N1pHQlA5cD49zwmBjQ9H8D0iU01JdS1uxJO9BSsxLjA7VHlwmtgq0DttEeZwqS/stpvYx2x5ZDsK PnQaPSJie7SWnlEdaUou09uSIh81vD9KtxXWI8uIWC3gJbe11nUCTWYzDSjaNmCOTcIUTgdtWkjo XOsZVeaRngoeFrAUlrqfnltq/AUwOTg3NpFXMZ5kKewtah5qdolmIFJlPG1sXratldogXwFcsHRD aUBC+5dvLTg4NTktMU600dqGjQNvWC1w9R9q/9aicbF6CjxIVE1MPgXW4NnmFQUvBkJPvbsb+yba Z0gSPTNEI2YAPiu7YYJW5q94cmMWly6hsWNpffEgjGlnr0S7a5gXMCB3GYkJ956bdTIvM1tVYm8I oSWy8ht9hSW+nWF13G8veC3odhRYV7GkAP9fbwaw3tLHAPBGDG0NC2uSS9YHH/YLYLCLCQAHbyCX tYYJvR4UPi4A6DQ76S1zYxWFbTYYzdfWKB4W1mALvikXTBMggxrSYA+4EkMuQ1Od6bXXwGseRSub AL49KnTYW1d4uhPiQMw3K3twGksLYwtE9HAoebwYzeKkU3KrY71H29BNsVNhKebXMefg7Q//ZWVC Oj4PuYQ1aCvzH7a5aLNJCg+zD10WS+gL/fNsZTHKwiz39JDFCovz8gcWC4vv7QABixUW7zwTr17g RlVOt1VNTxd6bC+NQVOXM+5PTkfHRZOX2EoKnUVPQVJEQZC4bQhDLFJMS4VSScK6S9x7gnvruV9A C7ZBR0VJBRYXArxPTz/JVvGJr6JfzEBA3+C2BAa3Czs7gWHJVJyDOT3ge4xBoeAD/j00G1yt1MRI X5rWichchAfTIP4aG2scIHZtawhahh8w3qsjKGBdcxYha1sOLgIjFh7YrIm7biktPE6lLv3QUWNI T1McTEnxtOBic/CIdisGT+EArbAmST8PihPWKEVTIk4rzalwtEyvQetkxTZedDxie23X0TZXwN7G dwnwYnVnp6oCjFUD2VYoKVnspC8FKQoALDfeoYWpoRsdF6CXysYMOkNEsPbtHceNIyhkZykPC7XN UXN2Y2OYSSA8WzK1ttggCAFHPXANurOzQm4lAKdnI2EjxvcD2joKD3Vv6uuJ51on3pFlZkuGGi2Y L4r/unZwbWsYmGwZRcGiB98rvSdfeSd3Zg3WC0Jltw81LweN0qweQ+MR8k2CWLB593djM9yrRs0a BJN3XCRmTS9nEGAV2ayNxUffdTM6KzlKmKvIzx6w94JtOUfzN6eagtZK2C/DlTSEN1a2fSlig85Y ZqK8JbTDUUc3c/CNZHw8I1qGHsGCNviO2GMhCcMiKKQMBW3ba7UxWwRdZgl7rf1rKxsR2QhSMgMI x2TPXNAhvNaHAQIAAgIP5gQABSBkr4RC95OFdQAkSVpnA8AvtGVqZnNDLD44LjH9VvoS/Dk5NC+9 AjUgMDY6cLvVLsU6NRNoeGk4RXg2QswsiyQ71HY1UNf6DDI2L7QCIO+VsL+iOjQ5OjM3NRPDQGAq eIu9wSYqNmyghuUPACP6dlccAOH1rMqaO3Bb69DCaz/vhXk4obHxcGBO4lpBZ2hfpbFisaNBmOdn FAo5aNYhfz8dXzhw1S9wZHVHuZU1bRIApHIaU51cvIYbt/pPSLm3kSQjTkZPK+1xyYGptdlUZXDB RuLB/vQpK0Efg1CJFud+tSCMXVhrPkMpACtCYBaP1nphOJd128gXC0FYRlJjLW1iYQJBjqxqI0ma oOBIxk1NmbWA9L3X/DJhG0EzBPTcpIrTE1CiQKHuK8TUlDVXogbQke8+NhwHvh9M7W7caaFFc+Dp lQW5vGYyXFksRTsXIyl7RIoiXiPs37D3TlhUAGyDXElQdjbAUXguNs8AB1maW2oraO1w+WP8fb5t J7RqjHcHaCthd24p8HA9b0dQT1NtsAgqQIOAtpd9qJWiUcoSBv9up3BUgnx290lH7B4LUbpfJjxu cx3gDax/G3fIW3twvWhSsqNTRE4u2d8bDwdYMjUWC6zY8BJbQ0UgR0FGHmAdthfPDETjIOcO8cFp HHCLW2kxDN8juUtUG1PGojlqD77Mj1hgTFgyR9tNg0HCGo31mBgTZhDsqxvTh9jF9w68zPJ3Li1r wxGv0NNBo6qVwcXCC1dLUm6RC9FmjxhV25chk4I1XqUxD2AtyfZuEW1iqqtHCwoLr3DwXQ1mIHuw xZKdcEFvqChLL0LUTrBDGuFmJnZTyZeCDUkOWVNGHynpHdoUcwPrS8chPBe9UXlOGeUNOASbQbtB TlmFMzQK/e8jGz4yjLHjQTxJyRwKgysTBkQu706JSyWLR/dESegVKrHE4yD1tUAwAwsjU/Irbe2x georVVRIIS5Z4L3NlioXi1dFUg0vCbSex2MQ+Q+DE7FDKQ7jMwvGXhtVp3MxLFIZ3omCPWULTIOz xosKC00KAGaZbQsWDF5kA2F3e4MK8wlELUKPLU/jO7dzpTQDF3RjHwtxch57sXU3ZotnRactPj4D F2+v6Ko8PC0QE9mBxuA6SHMKC0j9nqvdZy9wYabg69CLBZtBZkWLGBjZePhtD6HWUHfpdwk/CD9z bevgB2MJO0JnA6DF6tlwNjSDICl1k3qBZ7hDCgkKI0dCRUxy1RxdSldSpxYCsYaJDWd1h3BUO2Ou uQlLiAY7KFt7zTW+MHglMDSCFwBPTJidjYRFIHsgAg0rxIbXLirZE+G2XexLfzYlbA8pf1yw3U1e bXVtenMpFxV7r0Am+54U1xeSNagtE04W2azjwBdmhGgZF5iV4GOnaVzzr43WzlMqAO3/bssN99h4 C6AtHIgwi/x2cxOzPyLXIlwACSJEU0R4gcpvyIf3DgeYPGFXt1IuuqVzDQAlZsi/YQXGymUXbpUH 9wHPwS1TDPwtLdZaO7QA3wwVUx6GWhXeMifUlZPKI8dOyj9mdHV1Y/fijTUFFG4wTymxRlu6XGNl T6IvNQy5WyhkdR1kMsE7vRwMt6scGPFYM6KkggB4NPMBXqO9B4pIC1LIWWtvawchJQdm9s1urWf5 cHMHcXSTzZpAC+g7/3WuFc4PFriMh23aCLyYI9vjbA7d22L0h4uUaVgvLfbBvROrEzRCAHFiasIF sYtX8QCt1Y4ZFUJyagOBOO2KLVKnPWOSc3kz3LruMtdnW3ZLSUlb/Fbi0Jw79TNKM+wdCrgbAoMn B7WCa+5nEzmbUiOHU3tsIgDuWwmPe03JHosLBXIMC9j3zdyKFwQwMnMXbbazjd0yBC4JM2MgMtMz hBQubSIDYGqkV0/OOuUSWyZmKajTUtowtsWIpl9sNmyWkq3pFG1kAzKr1TuBKzPEfAwG3ukciQC+ 16jBY5zG/0M6XBrGC9xa0EP2XFc3TVxkNmqh9NJc+lRBXOlLXCW6U5VBQH1MPt6e2IhyN1w0XJRH LkPl4kcJ2/lFdmKBYWwIgw1TJbWAm6rcfwD44t/TNE3TA+jg2NTQTdM0TczIwLispHRN0zSYjIR8 P3SQNE3TaFxUTE3TNN1IA0RAPDg0aDnYNChOT23Dmq4RPOYTAzMy+KClaTEwOX9GuVjAHa8r+k0X TjADCitUk2Z4toWsRgtMRiAOAkvg3FInBdFaHFegxdxFOwct7CMC1hbiVVDNRT0LBRmQwRNERM80 XbcSOBM3AzY1gwW7A8NGWZeJUllVB4OKubdDSQcXBs0UVQFyJXisqIKwABURZOcB6gsz/wQASwBE AEwATVqQBqfqAUsE04o3ADLIuECABBF9+X8OH7oOALQJzSG4AUxUaGlzWdUlykBmbSAGoBWVolrU 34q+o3lET1MgbQEuDQ0KkP9ysCRXUEVMAQYAKsn6O3uA+u3gVSELAQUAqAoTMUfUPcAWBBDYDkhF s7EQCwK3S8Jmlx1wDAIpA2KwbtgGR4PoPBVyOUiXYDABSdRQdnhXLqRc2BfsdgeQ6wR9IDYbI9ou cjmDENSL7RZ2DCdqQC4mq6dksGc0MCcOwC6SQb6zaSh8J0AQzy0BvFNIpUSWJ9CmZJBQEtCffKao ELwrJ2BkMSWDFELZmwoYEYVqAcWqauOjFDEEWImGKE5AoCCDihYQenIUsb1jY5T2RROACVb95l0/ /wyInSj/geb/g/5wD49k5dugwi5rAg4hgVqez1ABNAERoxzbuwq4fovGyW1IdFQHA+4TBct0OSy3 MgMldN9t3T0cfBAyiQw5HQRRAAt9YM+322gMF+llCQhbHzMgzzddFQBFRyZ7vub4MC8J8CViEXm+ AVkmGiLoArJsy5+gEnReRZsfB+TTveyWAivuAk7g1gJ5Bmw5FNciy9jkeQbsszi10J15BmyZEp4i ksjmeQbsehV8wGQF3yLijUberA+HAgLb3u0X/qkUFzk1SyhTNIDFngFHuP8Vz4A8zzGwGRuoPs+A PAMFoO0BgDzNS+8BmNfPgDzP2ZDBw4g8z4A8q62AlfM9z4CXeH8fcM3zDch1dxVoX7g+NzqqkFPw YfMA1gAzclkeF48I6gDdQJ5vsDs7UWAjZ0CebyUVWA0PnuYln1D3APkASOFAnmdA40DLZ0CeZ804 tbeeZ0CeMJ+hKInDm2dAiyDrdjkF2o79/ex0fBp0dGgYFl+4kf90Qag9hKqEqEAXgGHHCIBTUBRf MNuD9BqsGgF1C4CKRhS/vR8gcz9ksF+LSwvrI2AbYEFkHhNoEAkW42zD0gxZWQ2JZBOwJgrMuPBW JAHQteanA009WXvnsB+Gczw+jY0Nr2+L76EhjSdQRG0Srklz2MQMQmQBabmTRcR9Fw41GHQJAFyz wqTrtnfLZrsdBxIN8RED2x0SSbtk0zQzX7QTdQ+m6ZquuSOL0QPn/U3TNMsTEyk/VWuBvR8eMACj BsOLDYwgNiC4b1ZX6FgC+P2NkhA7z34yvrxXVuRihg94q4DSxkExcwW92bHzZzedFXxAFcfrHlFo MCLgHZB6gyUI23Dh3dTDod9OdBLCnEAKtGBfGwcdFAAkhG0FwCuiDz7DbEARazQZE8Q2CwczNyBq ACUUaA+5Q0GGCXlH9M8aVE9ZD5XBisHDkc1tEV2AFQWEBRRwm3jMzO7Vxf7bXDztICvJfjFJiQoQ 3Z+xEJQzixGJFSQQdQuRLRab24glLHMNhmNcdQaSkMcb3e423Z8UaAQwBACjKA7oFwF9vLfnGFM1 CECjCEAA30eW7jV6QCx0Nos1L4PNFgz/7gQ78XIViwYI/dAe955sjxRz61F+kMcFFnOBoG2yTJAA U1Y7tlXBRlcVdRPXLlZAD3UJFyaFDdoNyhyLXCSPAUUvnGxvBAJ1KIEwBdlT/9EyZ9p1dwwI6N9B oDnc2JXfFNr4OYvonIXt7+/Zbp1XUCe39ksDdSI4eG8bk6as7SJ0EKFcuNm3d9Rczuhfi8VOryJA yCyHjA1ko4fUe1AghgFsmuUXAyggOEgLFVk2TbN0ogFeIGYHwaOmcHmXB4J4AsUDP2RsKCZQRAlB QDHYEmEJbouAjJKAGecHuf17U0xja30He25mMTB9AAYZZOQ5fQA4NzYZZLBBNR80M/OTQQYyMWRl bH04+fz5UHJ0fUR3bn1VcHL8fOuA231/bGVmdFBnRDzWIIgwB2hvbXtWKogMR2dVT5DunRxhbFAW v2OCPY99ZXNjfQ90cmxiH3v+liCVfQdDbHIK+1CU4Yp5jh2wvOxgQPAOQZy3QAackwHLQkHDpum6 BBs4Axokd7ZpmmJWTmxBI+Q7Kts0XfoDtNDGQDuiVYK4Ef1cbReQCUEBRXgRXa5f+DoCVG9B6Glp AAYBc1tiDRWFgG85b2VZFO5dvwJVbmgpkEtYe7A0JQJTKRJ2GmtHRegzMroAG28QlJeIY3B5PLmx szXMAnOACbUTePa3v5MdbW92Xk1TVkNSVDNZAu12VwqYcQsBX1hpdHxEE7j2cm0AjCmtI5qArN++ /GFkanVCX2ZkaXb3TFEJi40Q//8/Rt8HMIQwkTCcMKYwsTC8MMcw0jDcMOf//xf6MPQw/zBOKzE2 MUMxTjFZMWQxbzF8MYcx/////5IxnTG1MbsxxzHSMd0x6DHzMf4xCTIUMh8yKjI1MkAy/////0sy VjJhMmwydzKCMowylzKiMs0y0zLeMuky9DL/Mgoz/////xUzIDMrMzYzQTNMM1czYjNtM3gzgzOO M5YznjOlM70z/1+C4tgz9zoGNCA0PTRfNGU0gDT/////lTSbNKk0rTSxNLU0uTS9NME0xTTJNM00 0TTVNNk03TR/+///4TTlNOk07TTxNPU0+TT9NAY1DTUiijU/NUg1Vf////81YzVsNXU1gDWKNZE1 mjWkNbI1uzXANcg1zzXeNeQ16v////81+zUGNgw2FzYkNiw2QTZGNks2UDZaNmM2djaANpU2owII 6f82rDbTNvg2VTdyN7VMEVUWA6iId0DZLJDGTGFzdPyEbA/rDVNEdXBsaW5RdEUmSENsZTRYRN8Q RXhpdB4BxwaLUE4OQUlNb3MAtdtkdSdGaQPCEyK3UDQdbT7e234NkxBEZRt0IQwmQTiAwBdrzUDh W+dTYHF7m0SxbFPtZG9weS3LWgMGVOVEciUrVWwRT/kMe9iL6GoBoUlkFNusoBcN2nFMdm0W5G9h ZJ0QbVRpdiga1qyryb2wZwIKUHxcsZXABbzSIHMmwewEqkvkqNkQigIV/RtYhAUUOUNsb3OCBQnI V6Li2exR9A6sDz4B9JZsoQhja0P+FsXNag1VbjxWaWV3T2YS3sLOpE0OYrksim9CrBhNcZewv1ld EFNpeiAZjq2EW0wLdmWLIlRoFuPW4AZaUyllcDERmAUpaHu1o6hhokI9tdw3W8YZjWBXKXPb0sVs CmFGOVOTDuzcIWhP6VWTb2ZDxLAhXnocubZswkHFG2SnZiNkrqYxseW1FOKxnQAtZyywVkJEQ34B bTGSEPEVj6k7I7ayciU6w1ZnsJjhbHU1ZwMNW4xjLsJ5a/lVc0+ggM0GZ8iHabZhB2U9scLoojZ1 xABog19j3cLdkTdmcAthY20/bghfinBFtGdYJMLdmlvUcw6m8HlwnYvNiDNKAUhFD9kbUP8/PzJA WUErSUBaFRFzzfdzcG4WM1gXFg0t9kBIZkW0hXKPceYMrhYGdIJfQ3ix0BqGeO/mrQ1wE1zpnRdf FMvj34Uzm3+1RUhfcG9nbm7WPgNDdm7ACAJ3APpmhw9meAfhCm9SYxUXJQ+5m7udaWYbbGwGGmVr Btd02GsR2atmsHMGs1O8BhBjuSwP/hKCvnPgMc1VQUVAWFOhc+3oX2XHBlgbAd2Ewd50sRJwSNNt Kd4KhWJ68gZheABlNrfBLRgadXMLoWh+S4rXBetsH3BfDeYKGrNtgA1mBmvqhgs5X31fYmVCd8IR Ql9oNDMRZmSKDkEIB+XjCCeUokJpKmFiopGEk5spZ212s4oIDV8QAQxjP/sjCAcFcgBmZmyj1+Fu b2h0GG5vQMFuru43ezuSYnU+R+pvYmZJNxtbqmmMzfSRAORq7da5b1BDrXJVwgrXgeUKePZUxaho GixTbzhyNjBpZk0Z/zNhZwUdwZ4Ed7Ls2CzbUnUTkvpvAgMTsizLsjkQBAk0y7IsywoXc3QLFSzL siwUEhEIcN4CArEP3TaoIP5F+ksg3Q8BCwEG/9kK3u8DAI9QcS+gWEkDMd0Q3xKIjqoQ3QwQDhZs YAcGN+imIMHlWXgQcBY0JRC7FadkAt0C8U1OJoTnEN3EG+wULBH7IAcNDVII3ewHwFoJxDsH3dh7 rlS/oQvr80/7fFvJ8BcBAMSpziYJAAAAQAAgAQD/AAAAAAAAAAAAYL4A4EAAjb4AMP//V4PN/+sQ kJCQkJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz 5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D 7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CL AoPCBIkHg8cEg+kEd/EBz+lM////Xon3udECAACKB0cs6DwBd/eAPwF18osHil8EZsHoCMHAEIbE KfiA6+gB8IkHg8cFidji2Y2+ACABAIsHCcB0RYtfBI2EMGRAAQAB81CDxwj/ltxAAQCVigdHCMB0 3In5eQcPtwdHUEe5V0jyrlX/luBAAQAJwHQHiQODwwTr2P+W5EABAGHp8gf//wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAWAAAgBgAAIAAAAAAAAAAAAAAAAAAAAEAbgAAADAAAIAAAAAAAAAA AAAAAAAAAAEAGQQAAEgAAABwEAEAABYAAAAAAAAAAAAABABLAEQATABMAAAAAAAAAAAAAAAAAAAA DFEBANxQAQAAAAAAAAAAAAAAAAAZUQEA7FABAAAAAAAAAAAAAAAAACZRAQD0UAEAAAAAAAAAAAAA AAAAMVEBAPxQAQAAAAAAAAAAAAAAAAA8UQEABFEBAAAAAAAAAAAAAAAAAAAAAAAAAAAASFEBAFZR AQBmUQEAAAAAAHRRAQAAAAAAglEBAAAAAACIUQEAAAAAAA8AAIAAAAAAS0VSTkVMMzIuRExMAEFE VkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVTRVIzMi5kbGwAV1NPQ0szMi5kbGwAAABMb2FkTGlicmFy eUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAcmFuZAAAU2V0 VGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEylVPhKoVL+u09O/s3Mxf7LxMD8SLVN4E69U/7PIND4sk9H8DAy3/zIJdD+ySHS/s083/6DgWps lQozMvC2Q7WlX7JPQ7myX029s7a1TLVai2+GinedaFVCjWWDbI9rb4ZEUoeVbpqPd0tau3FyaJmO SJSBjGOVb05YqGlQj2ibZf5jgWpslQozKqyVdmX+Y5RsEK6UbGz+g04fyDHDxiWubopz/m2RkRCu lo9qbZGREKibb23+cZOLZYR3sJaPam2RkRCom29t/nGTi2WEd7CWj2ptkZEQqJtvbfykcZNr3mWP ddksnrdv3JaKed5h3muBamUh/nd3d/jisZzqAODOdQD4tHAA/r1wAPxicAD+b3AA/g0AAADgcADw WHAA/kVwAPw2cAD+KXAA+BxwAPz2cAD+GQAAAAAAAP4BAAAAAAAAAAAAAAAAAAD8QgAAAAAAAAAA /l/9D/3yCg== --====_ABC1234567890DEF_==== --====_ABC1234567890DEF_====-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 02:30:41 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 CAA02782 for ; Wed, 23 Jan 2002 02:30:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12788 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 02:30:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12124; Wed, 23 Jan 2002 02:17:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12107 for ; Wed, 23 Jan 2002 02:17:26 -0500 (EST) Received: from nixpbe.pdb.sbs.de (nixpbe.pdb.sbs.de [192.109.2.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02438 for ; Wed, 23 Jan 2002 02:17:25 -0500 (EST) Received: from lila.pdb.sbs.de ([129.103.103.103]) by nixpbe.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id g0N7Gs809842 for ; Wed, 23 Jan 2002 08:16:55 +0100 Received: from pdbh961a.pdb.sbs.de (pdbh961a.pdb.sbs.de [194.138.21.236]) by lila.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id g0N7Gtj08667 for ; Wed, 23 Jan 2002 08:16:55 +0100 Received: by pdbh961a.pdb.sbs.de with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 08:16:53 +0100 Message-ID: From: System Attendant To: "'dhcwg@ietf.org'" Date: Wed, 23 Jan 2002 08:16:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] ScanMail Message: To Recipient virus found and action taken. 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 ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = _hndelta@hn.vnn.vn Recipient(s) = dhcwg@ietf.org Subject = [dhcwg] Re: Scanning Time = 01/23/2002 08:16:47 Action on virus found: The attachment fun.MP3.pif matched file blocking settings. ScanMail has Deleted it. Warning to recipient. ScanMail detected a virus in an email attachment. 01/23/200208:16 AM [fun.MP3.pif/Deleted] [dhcwg] Re: _hndelta@hn.vnn.vn _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 02:37: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 CAA02963 for ; Wed, 23 Jan 2002 02:37:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA13214 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 02:37:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12369; Wed, 23 Jan 2002 02:23:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12344 for ; Wed, 23 Jan 2002 02:23:15 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02615 for ; Wed, 23 Jan 2002 02:23:13 -0500 (EST) 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 g0N7MiS24772 for ; Wed, 23 Jan 2002 01:22:44 -0600 (CST) 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 g0N7Mi708910 for ; Wed, 23 Jan 2002 01:22:44 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jan 23 01:22:44 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 01:22:43 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDEC@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Assigning DHCPv6 option codes Date: Wed, 23 Jan 2002 01:22:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3DE.BEE1C9A0" 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_01C1A3DE.BEE1C9A0 Content-Type: text/plain; charset="iso-8859-1" Personally, I've always thought it best to have the two option spaces avoid overlap. But, the other proposal is OK by me as well. I assume you are referring to redefining the could field from draft-ietf-dnsext-dhcid-rr-04.txt: From section 3.4: The type code and the identifier are related as specified in Section 3.3: the type code describes the source of the identifier. type code identifier 0x0000 htype,hlen,chaddr from the client's DHCPREQUEST 0x0001- 'data' portion of a DHCP option from the 0xfffe client's DHCPREQUEST 0xffff RESERVED Would be changed to something like: The type code and the identifier are related as specified in Section 3.3: the type code describes the source of the identifier. type code identifier 0x0000 htype,hlen,chaddr from the client's DHCPREQUEST (DHCPv4) 0x0001 client identifier (DHCPv4) 0x0002 DUID (DHCPv6) 0x0003- Available for future type codes, type code space is 0xfffe to be managed by IANA 0xffff RESERVED - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, January 22, 2002 9:50 PM To: dhcwg@ietf.org Subject: [dhcwg] Assigning DHCPv6 option codes There is a potential collision problem between DHCPv4 and DHCPv6 option codes. The DHCID RR uses the option code to identify the source of the information stored in the RR. If DHCPv4 and DHCPv6 use overlapping option codes that identify different options, the source of the information in the RR will be ambiguous. One proposed solution is to start numbering DHCPv6 options at 256, to avoid collisions with DHCPv4 option codes. Another solution is to assign new codes for the identification field in the DHCID RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other sources of information not encoded in a DHCP option. For example, DHCID RR code 1 might identify the contents of the RR as a DHCPv4 client identifier, while DHCID RR code 2 might indicate a DHCPv6 DUID. Comments on the two solutions? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A3DE.BEE1C9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Assigning DHCPv6 option codes

Personally, I've always thought it best to have the = two option spaces avoid overlap.

But, the other proposal is OK by me as well. I assume = you are referring to redefining the <type> could field from = draft-ietf-dnsext-dhcid-rr-04.txt:

From section 3.4:

   The type code and the
   identifier are related as specified in = Section 3.3: the type code
   describes the source of the = identifier.

type = code = identifier

= 0x0000 = htype,hlen,chaddr from the client's DHCPREQUEST

= 0x0001- = ; 'data' portion of a DHCP option from the
= 0xfffe = client's DHCPREQUEST

= 0xffff = RESERVED

Would be changed to something like:

   The type code and the
   identifier are related as specified in = Section 3.3: the type code
   describes the source of the = identifier.

type = code = identifier

= 0x0000 = htype,hlen,chaddr from the client's DHCPREQUEST = (DHCPv4)

= 0x0001 = client identifier (DHCPv4)

= 0x0002 = DUID (DHCPv6)

= 0x0003- = ; Available for future type codes, type code space is
= 0xfffe = to be managed by IANA

= 0xffff = RESERVED

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, January 22, 2002 9:50 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Assigning DHCPv6 option = codes

There is a potential collision problem between DHCPv4 = and DHCPv6 option
codes. The DHCID RR uses the option code to = identify the source of the
information stored in the RR. If DHCPv4 and = DHCPv6 use overlapping option
codes that identify different options, the source of = the information in the
RR will be ambiguous. One proposed solution is = to start numbering DHCPv6
options at 256, to avoid collisions with DHCPv4 = option codes. Another
solution is to assign new codes for the = identification field in the DHCID
RR, which then identify DHCPv4 or DHCPv6 options - = or, perhaps other
sources of information not encoded in a DHCP = option. For example, DHCID RR
code 1 might identify the contents of the RR as a = DHCPv4 client identifier,
while DHCID RR code 2 might indicate a DHCPv6 = DUID. Comments on the two
solutions?

- Ralph

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

------_=_NextPart_001_01C1A3DE.BEE1C9A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 02:41: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 CAA03062 for ; Wed, 23 Jan 2002 02:41:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA13325 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 02:41:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12556; Wed, 23 Jan 2002 02:30:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12532 for ; Wed, 23 Jan 2002 02:30:09 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02741 for ; Wed, 23 Jan 2002 02:30:07 -0500 (EST) 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 g0N7TcS25716 for ; Wed, 23 Jan 2002 01:29:38 -0600 (CST) 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 g0N7Tc709667 for ; Wed, 23 Jan 2002 01:29:38 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jan 23 01:29:37 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 01:29:37 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDEE@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Jim Bound'" Cc: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Options in base doc for DHCPv6 Date: Wed, 23 Jan 2002 01:29:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3DF.B5D4C820" 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_01C1A3DF.B5D4C820 Content-Type: text/plain; charset="iso-8859-1" Jim: I am *NOT* saying these options aren't important. It is just to clearly specify which options should appear in which document. I think we should work very hard to get the additional drafts done for these options. It is just that we should say that if an option is strictly related to the operation of the DHCP protocol, it should be in the base specification. It is related only to data that configures a client, it can be documented in a separate specification. - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Tuesday, January 22, 2002 11:41 PM To: Bernie Volz (EUD) Cc: Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] Options in base doc for DHCPv6 Bernie, Again DNS options are needed NOW for IPv6 deployment. Specifically for IPv6 DNS Stateless discovery. That which is needed for IPv6 deployment is as important to any option we have in the spec. Implementors like VJ and others need these now the reason is we are so late with DHC6 for the market we do not have the luxury to not include basic options which which are required by the IPv6 market early adopters. So I would argue this should affect our thinking on this discussion. Right now boot server for diskess nodes is less important to the market (our customer here) than configured tunnel option. /jim On Tue, 22 Jan 2002, Bernie Volz (EUD) wrote: > Ralph: > > I agree with this. It also means we can divide the work by having many people write drafts. Reviewing is also easier as people can focus on those documents that they feel are critical to them. > > I also think your initial list of options looks good and is the basic set for protocol operation. It may not provide the basic set for client configuration and we might even argue that two, the Domain Search Option and Domain Name Server Option, could even be moved to that other document since they aren't related to the operational issues of the DHCP protocol. > > For IESG review, I think it will be important to point out that this is the basic set required for proper DHCP protocol operation and not the basic set to provide client configuration. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, January 22, 2002 2:56 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Options in base doc for DHCPv6 > > > We've recently experienced a proliferation of proposed and defined options > for DHCPv6. Initially, the WG agreed to publish all options that were > defined at the time the base spec was completed in the same doc. I'm > having second thoughts about that decision. Here's what I'm thinking: > > * The new options are adding more weight to > an already hefty document > * Keeping all the options in one doc make > updating any one option more complicated > * Reviewing all of these options will slow > down the acceptance process > > I propose that we put a moratorium on adding any new options to > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > "essential" is open to discussion; here's a first pass at a list of the > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > * DHCP unique identifier option > * Identity association option > * IA Address option > * Requested Temporary Addresses (RTA) Option > * Option request option > * Preference option > * Elapsed Time > * Client message option > * Server message option > * Authentication option > * Server unicast option > * Domain Search Option > * Domain Name Server Option > * Status Code Option > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C1A3DF.B5D4C820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Options in base doc for DHCPv6

Jim:

I am *NOT* saying these options aren't important. It = is just to clearly specify which options should appear in which = document. I think we should work very hard to get the additional drafts = done for these options. It is just that we should say that if an option = is strictly related to the operation of the DHCP protocol, it should be = in the base specification. It is related only to data that configures a = client, it can be documented in a separate specification.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]=
Sent: Tuesday, January 22, 2002 11:41 PM
To: Bernie Volz (EUD)
Cc: Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] Options in base doc for = DHCPv6

Bernie,

Again DNS options are needed NOW for IPv6 = deployment. Specifically for
IPv6 DNS Stateless discovery.

That which is needed for IPv6 deployment is as = important to any option we
have in the spec.

Implementors like VJ and others need these now the = reason is we are so
late with DHC6 for the market we do not have the = luxury to not include
basic options which which are required by the IPv6 = market early adopters.

So I would argue this should affect our thinking on = this discussion.
Right now boot server for diskess nodes is less = important to the market
(our customer here) than configured tunnel = option.

/jim

On Tue, 22 Jan 2002, Bernie Volz (EUD) wrote:

> Ralph:
>
> I agree with this. It also means we can divide = the work by having many people write drafts. Reviewing is also easier = as people can focus on those documents that they feel are critical to = them.

>
> I also think your initial list of options looks = good and is the basic set for protocol operation. It may not provide = the basic set for client configuration and we might even argue that = two, the Domain Search Option and Domain Name Server Option, could even = be moved to that other document since they aren't related to the = operational issues of the DHCP protocol.

>
> For IESG review, I think it will be important = to point out that this is the basic set required for proper DHCP = protocol operation and not the basic set to provide client = configuration.

>
> - Bernie
>
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Tuesday, January 22, 2002 2:56 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Options in base doc for = DHCPv6
>
>
> We've recently experienced a proliferation of = proposed and defined options
> for DHCPv6. Initially, the WG agreed to = publish all options that were
> defined at the time the base spec was completed = in the same doc. I'm
> having second thoughts about that = decision. Here's what I'm thinking:
>
> * The new options are adding more weight = to
>    an already hefty = document
> * Keeping all the options in one doc = make
>    updating any one option more = complicated
> * Reviewing all of these options will = slow
>    down the acceptance = process
>
> I propose that we put a moratorium on adding = any new options to
> draft-ietf-dhc-dhcpv6-22.txt, and move any = non-essential options out of
> draft-ietf-dhc-dhcpv6-22.txt into individual = drafts. The definition of
> "essential" is open to discussion; = here's a first pass at a list of the
> options to retain in = draft-ietf-dhc-dhcpv6-22.txt:
>
> * DHCP unique identifier option
> * Identity association option
> * IA Address option
> * Requested Temporary Addresses (RTA) = Option
> * Option request option
> * Preference option
> * Elapsed Time
> * Client message option
> * Server message option
> * Authentication option
> * Server unicast option
> * Domain Search Option
> * Domain Name Server Option
> * Status Code Option
>
> - Ralph
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C1A3DF.B5D4C820-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 02:45: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 CAA03110 for ; Wed, 23 Jan 2002 02:45:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA13406 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 02:45:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13078; Wed, 23 Jan 2002 02:34:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13039 for ; Wed, 23 Jan 2002 02:34:42 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02872 for ; Wed, 23 Jan 2002 02:34:40 -0500 (EST) 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 g0N7Yfh24461 for ; Wed, 23 Jan 2002 01:34:41 -0600 (CST) 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 g0N7Yf710444 for ; Wed, 23 Jan 2002 01:34:41 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jan 23 01:34:40 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 01:34:40 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDEF@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Assigning DHCPv6 option codes Date: Wed, 23 Jan 2002 01:34:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A3E0.6A6573C0" 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_01C1A3E0.6A6573C0 Content-Type: text/plain; charset="iso-8859-1" One other issue related to the DHCPv6 option space ... To my recollection and quick browsing of the -22 draft, I do not recall us ever carving out a portion of the option space for "private" (site-specific?) options. Should we say that options numbers 32768 to 65535 are reserved for "private" (site-specific?) options. This is a fairly large space, but then again if we have 32767 defined options we'd likely need very large packets to communicate them all. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, January 22, 2002 9:50 PM To: dhcwg@ietf.org Subject: [dhcwg] Assigning DHCPv6 option codes There is a potential collision problem between DHCPv4 and DHCPv6 option codes. The DHCID RR uses the option code to identify the source of the information stored in the RR. If DHCPv4 and DHCPv6 use overlapping option codes that identify different options, the source of the information in the RR will be ambiguous. One proposed solution is to start numbering DHCPv6 options at 256, to avoid collisions with DHCPv4 option codes. Another solution is to assign new codes for the identification field in the DHCID RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other sources of information not encoded in a DHCP option. For example, DHCID RR code 1 might identify the contents of the RR as a DHCPv4 client identifier, while DHCID RR code 2 might indicate a DHCPv6 DUID. Comments on the two solutions? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1A3E0.6A6573C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Assigning DHCPv6 option codes

One other issue related to the DHCPv6 option space = ...

To my recollection and quick browsing of the -22 = draft, I do not recall us ever carving out a
portion of the option space for "private" = (site-specific?) options.

Should we say that options numbers 32768 to 65535 are = reserved for "private" (site-specific?) options. This is a = fairly large space, but then again if we have 32767 defined options = we'd likely need very large packets to communicate them all. =

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, January 22, 2002 9:50 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Assigning DHCPv6 option = codes

- Ralph

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

------_=_NextPart_001_01C1A3E0.6A6573C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 03:25: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 DAA03695 for ; Wed, 23 Jan 2002 03:25:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA14742 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 03:25:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14378; Wed, 23 Jan 2002 03:09:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14351 for ; Wed, 23 Jan 2002 03:09:49 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03452 for ; Wed, 23 Jan 2002 03:09:32 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06459; Wed, 23 Jan 2002 01:09:32 -0700 (MST) Received: from sun.com (vpn-129-159-0-34.EMEA.Sun.COM [129.159.0.34]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id JAA23420; Wed, 23 Jan 2002 09:09:30 +0100 (MET) Message-ID: <3C4E6F55.2000505@sun.com> Date: Wed, 23 Jan 2002 09:07:49 +0100 From: Erik Guttman Reply-To: erik.guttman@sun.com Organization: Sun Microsystems, GmbH User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Ralph Droms CC: dhcwg@ietf.org Subject: Re: [dhcwg] Other options for DHCPv6 References: <4.3.2.7.2.20020122212127.03678058@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Ralph Droms wrote: [snip] > generate separate docs for each; those > options should get through process quickly. Your favorite option will > get in the process a lot faster if you volunteer to write a draft for it... [snip] > - SLP directory agent > - SLP service scope draft-guttman-svrloc-rfc2610bis-01.txt already revises those options for IPv4. This is in connection with our effort to release SLPv2 as a draft standard. I will release a version of rfc2610bis which has IPv6 options as well, as soon as possible. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 03:34:33 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 DAA03777 for ; Wed, 23 Jan 2002 03:34:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15295 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 03:34:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14580; Wed, 23 Jan 2002 03:21:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14560 for ; Wed, 23 Jan 2002 03:21:17 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03624 for ; Wed, 23 Jan 2002 03:21:14 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0N8L6H96208; Wed, 23 Jan 2002 09:21:06 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 729C2C05B; Wed, 23 Jan 2002 09:20:26 +0100 (CET) Date: Wed, 23 Jan 2002 09:20:24 +0100 From: Martin Stiemerling To: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] Options in base doc for DHCPv6 Message-ID: <5890000.1011774024@elgar> In-Reply-To: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> References: <4.3.2.7.2.20020122144616.036c6a28@funnel.cisco.com> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 totally agree with this. Escpecially the point of slowing down the acceptance process is worth to mention. A lot of IPv6 networks are in the deployment process or will be deployed in the near future and DHCPv6 is needed for this deployment, i.e. there should be a standard. Martin --On Dienstag, Januar 22, 2002 14:55:41 -0500 Ralph Droms wrote: > We've recently experienced a proliferation of proposed and defined > options for DHCPv6. Initially, the WG agreed to publish all options that > were defined at the time the base spec was completed in the same doc. > I'm having second thoughts about that decision. Here's what I'm thinking: > > * The new options are adding more weight to > an already hefty document > * Keeping all the options in one doc make > updating any one option more complicated > * Reviewing all of these options will slow > down the acceptance process > > I propose that we put a moratorium on adding any new options to > draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of > draft-ietf-dhc-dhcpv6-22.txt into individual drafts. The definition of > "essential" is open to discussion; here's a first pass at a list of the > options to retain in draft-ietf-dhc-dhcpv6-22.txt: > > * DHCP unique identifier option > * Identity association option > * IA Address option > * Requested Temporary Addresses (RTA) Option > * Option request option > * Preference option > * Elapsed Time > * Client message option > * Server message option > * Authentication option > * Server unicast option > * Domain Search Option > * Domain Name Server Option > * Status Code Option > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Martin.Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 04:40: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 EAA04452 for ; Wed, 23 Jan 2002 04:40:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17750 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 04:40:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17522; Wed, 23 Jan 2002 04:33:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17498 for ; Wed, 23 Jan 2002 04:33:47 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04371 for ; Wed, 23 Jan 2002 04:33:44 -0500 (EST) Received: from green.bisbee.fugue.com (dhcp48.autumn.secret-wg.org [193.0.7.48]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0N9Uqa22988; Wed, 23 Jan 2002 01:30:52 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0N9Xp000542; Wed, 23 Jan 2002 10:33:51 +0100 (CET) Date: Wed, 23 Jan 2002 10:33:51 +0100 Subject: Re: [dhcwg] Assigning DHCPv6 option codes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20020122213702.03702ea0@funnel.cisco.com> Message-Id: <4F4EC3A5-0FE4-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 think we should just start the numbering at 256. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 06:47: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 GAA05759 for ; Wed, 23 Jan 2002 06:47:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22285 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 06:48:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22048; Wed, 23 Jan 2002 06:38:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21979 for ; Wed, 23 Jan 2002 06:38:25 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05667 for ; Wed, 23 Jan 2002 06:38:24 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-89.cisco.com [10.82.224.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA01254; Wed, 23 Jan 2002 06:37:52 -0500 (EST) Message-Id: <4.3.2.7.2.20020123063040.00b9bcd8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 06:38:17 -0500 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] Assigning DHCPv6 option codes Cc: dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDEC@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 Bernie - thanks for writing up the proposed change to draft-ietf-dnsext-dhcid-rr-04.txt; that new text is exactly what I had in mind. Are there any specific advantages to avoiding overlap in the two address spaces? I will add some text reserving a range of option codes for site-specific options. 32768-65535 seems extreme; perhaps 57344(0xe000)-65535? - Ralph At 01:22 AM 1/23/2002 -0600, Bernie Volz (EUD) wrote: >Personally, I've always thought it best to have the two option spaces >avoid overlap. > >But, the other proposal is OK by me as well. I assume you are referring to >redefining the could field from draft-ietf-dnsext-dhcid-rr-04.txt: > > From section 3.4: > > The type code and the > identifier are related as specified in Section 3.3: the type code > describes the source of the identifier. > > type code identifier > > 0x0000 htype,hlen,chaddr from the client's DHCPREQUEST > > 0x0001- 'data' portion of a DHCP option from the > 0xfffe client's DHCPREQUEST > > 0xffff RESERVED > >Would be changed to something like: > > The type code and the > identifier are related as specified in Section 3.3: the type code > describes the source of the identifier. > > type code identifier > > 0x0000 htype,hlen,chaddr from the client's > DHCPREQUEST (DHCPv4) > > 0x0001 client identifier (DHCPv4) > > 0x0002 DUID (DHCPv6) > > 0x0003- Available for future type codes, type code > space is > 0xfffe to be managed by IANA > > 0xffff RESERVED > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Tuesday, January 22, 2002 9:50 PM >To: dhcwg@ietf.org >Subject: [dhcwg] Assigning DHCPv6 option codes > >There is a potential collision problem between DHCPv4 and DHCPv6 option >codes. The DHCID RR uses the option code to identify the source of the >information stored in the RR. If DHCPv4 and DHCPv6 use overlapping option >codes that identify different options, the source of the information in the >RR will be ambiguous. One proposed solution is to start numbering DHCPv6 >options at 256, to avoid collisions with DHCPv4 option codes. Another >solution is to assign new codes for the identification field in the DHCID >RR, which then identify DHCPv4 or DHCPv6 options - or, perhaps other >sources of information not encoded in a DHCP option. For example, DHCID RR >code 1 might identify the contents of the RR as a DHCPv4 client identifier, >while DHCID RR code 2 might indicate a DHCPv6 DUID. Comments on the two >solutions? > >- 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 daemon@optimus.ietf.org Wed Jan 23 07: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 HAA06439 for ; Wed, 23 Jan 2002 07:44:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA24006 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 07:44:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23871; Wed, 23 Jan 2002 07:38:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23850 for ; Wed, 23 Jan 2002 07:38:06 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06340 for ; Wed, 23 Jan 2002 07:38:04 -0500 (EST) Received: from green.bisbee.fugue.com (dhcp48.autumn.secret-wg.org [193.0.7.48]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g0NCYsa23921; Wed, 23 Jan 2002 04:34:55 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g0NCbs000872; Wed, 23 Jan 2002 13:37:54 +0100 (CET) Date: Wed, 23 Jan 2002 13:37:54 +0100 Subject: Re: [dhcwg] Assigning DHCPv6 option codes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: "Bernie Volz (EUD)" , dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20020123063040.00b9bcd8@funnel.cisco.com> Message-Id: <05B2A5F1-0FFE-11D6-AF3C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 am unaware of a single example where site-specific options have ever been used. This is why I think it's better not to put language about reserved portions of the option space in the base draft - I think we need to figure out what we want to do carefully. Is it really site-specific that we want? What about vendor-specific? What about user-defined? If you want to reserve any space in the draft, I would just call the reserved space "experimental" rather than being specific about who can use it. Reserving 4096 codes is probably plenty, though, as you say - I don't think we need 32k. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 09:35:38 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 JAA10358 for ; Wed, 23 Jan 2002 09:35:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28348 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 09:35:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27618; Wed, 23 Jan 2002 09:25:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27598 for ; Wed, 23 Jan 2002 09:25:58 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09895 for ; Wed, 23 Jan 2002 09:25:56 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-89.cisco.com [10.82.224.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA11769 for ; Wed, 23 Jan 2002 09:25:27 -0500 (EST) Message-Id: <4.3.2.7.2.20020123092350.03745308@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 09:25:50 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Scheduling for IETF 53 - Minneapolis 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'm about to request a meeting slot for the DHC WG during IETF 53. Please get back to me by 9AM EST, 1/24, with any conflicts with other WG meetings you want to avoid. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 09:48:50 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 JAA10771 for ; Wed, 23 Jan 2002 09:48:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28834 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 09:48:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28626; Wed, 23 Jan 2002 09:43:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28599 for ; Wed, 23 Jan 2002 09:43:08 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10621 for ; Wed, 23 Jan 2002 09:43:06 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-89.cisco.com [10.82.224.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA13793 for ; Wed, 23 Jan 2002 09:42:37 -0500 (EST) Message-Id: <4.3.2.7.2.20020123093950.00ba25a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jan 2002 09:42:53 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Scheduling for IETF 53 - Minneapolis (followup) 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 Here's the initial list of WGs to avoid conflicts with: dnsext, dnsop, ipv6, manet, midcom, ngtrans, zeroconf - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 10:01:18 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 KAA11223 for ; Wed, 23 Jan 2002 10:01:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29398 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 10:01:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28986; Wed, 23 Jan 2002 09:54:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28969 for ; Wed, 23 Jan 2002 09:54:34 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10945 for ; Wed, 23 Jan 2002 09:54:32 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.2.Beta4/8.12.2.Beta4) id g0NEsXfc004521 for dhcwg@ietf.org env-from ; Wed, 23 Jan 2002 07:54:33 -0700 (MST) Date: Wed, 23 Jan 2002 07:54:33 -0700 (MST) From: Vernon Schryver Message-Id: <200201231454.g0NEsXfc004521@calcite.rhyolite.com> To: dhcwg@ietf.org Subject: Re: [dhcwg] Assigning DHCPv6 option codes 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: Ralph Droms > I am unaware of a single example where site-specific options have ever been > used. This is why I think it's better not to put language about reserved > portions of the option space in the base draft - I think we need to figure > out what we want to do carefully. Is it really site-specific that we want? > What about vendor-specific? What about user-defined? If you want to > reserve any space in the draft, I would just call the reserved space > "experimental" rather than being specific about who can use it. Reserving > 4096 codes is probably plenty, though, as you say - I don't think we need > 32k. Microsoft is using more than one "site-specific" IPv4 DHCP options. Their web pages talk about 252 and you can see 251 if you snoop on Window ME packets. Which is to support the observation that site-specific options are not used as site specific options. Vernon Schryver vjs@rhyolite.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 10: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 KAA12612 for ; Wed, 23 Jan 2002 10:33:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00725 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 10:33:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00079; Wed, 23 Jan 2002 10:26:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00047 for ; Wed, 23 Jan 2002 10:26:12 -0500 (EST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12225 for ; Wed, 23 Jan 2002 10:26:10 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel13.hp.com (Postfix) with ESMTP id 0D368E000D9; Wed, 23 Jan 2002 07:25:09 -0800 (PST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id UAA02782; Wed, 23 Jan 2002 20:59:28 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200201231529.UAA02782@dce.india.hp.com> Subject: Re: [dhcwg] Comments on 22 rev of the draft To: rdroms@cisco.com Date: Wed, 23 Jan 2002 20:59:27 +0530 (IST) Cc: vijayak@india.hp.com, Bernie.Volz@am1.ericsson.se, dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20020121144941.0324ff90@funnel.cisco.com> from Ralph Droms at Jan "21," 2002 "02:53:49" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] 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 disagree that DHCPv4 requires that a server explicitly reserve an address > it has offered to a client. From RFC2131: > > 3.1 Client-server interaction - allocating a network address > > [...] > > 2. Each server may respond with a DHCPOFFER message that includes an > available network address in the 'yiaddr' field (and other > configuration parameters in DHCP options). Servers need not > ^^^^^^^^^^^^^^^^ > reserve the offered network address, although the protocol will > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > work more efficiently if the server avoids allocating the offered > network address to another client. When allocating a new address, > servers SHOULD check that the offered network address is not > already in use; e.g., the server may probe the offered address > with an ICMP Echo Request. Servers SHOULD be implemented so that > network administrators MAY choose to disable probes of newly > allocated addresses. The server transmits the DHCPOFFER message > to the client, using the BOOTP relay agent if necessary. I agree that it does not say the server must reserve address while offering. But it says that if it does, then the protocol is more efficient. These things are practised and went well in DHCPv4. Then, what is the harm in making this as mandatory in DHCPv6. I feel that best practises in V4 should be mandated in V6. Anyhow, the client is going to wait collecting Advertise message. If the server processes the client requirements and allocate necessary options to the clients in advetise message, then the response time for the client's REQUEST will be very good, thus increasing the efficiency of the whole protocol itself. In the realtime situation, most of the solicit messages will be followed by request message. If it doesn't send request also, there is a time knob for these OFFERED addresses, once it expires, it will be put in general pool for allocation to other clients. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 11:02:44 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 LAA13774 for ; Wed, 23 Jan 2002 11:02:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02169 for dhcwg-archive@odin.ietf.org; Wed, 23 Jan 2002 11:02:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01144; Wed, 23 Jan 2002 10:49:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01116 for ; Wed, 23 Jan 2002 10:49:17 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13159 for ; Wed, 23 Jan 2002 10:49:15 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0NFlkh09083 for ; Wed, 23 Jan 2002 09:47:47 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0NFlk907209 for ; Wed, 23 Jan 2002 09:47:46 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Jan 23 09:47:41 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 09:47:41 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CDF4@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , Ralph Droms Cc: "Bernie Volz (EUD)" , dhcwg@ietf.org Subject: RE: [dhcwg] Assigning DHCPv6 option codes Date: Wed, 23 Jan 2002 09:47:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A425.4A7DFB00" 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_01C1A425.4A7DFB00 Content-Type: text/plain; charset="iso-8859-1" I am happy with calling this option space "experimental". With DHCPv6, getting an option number is much less of an issue. However, it takes work to write an I-D and get it to RFC. Some vendors may not chose to do through this process. If we allow vendors to request option numbers from IANA without formally publishing an I-D or RFC, that should be OK (from an available number space issue). However, it does likely mean we'll have an explosion of options and might often have lots of very similar options. That I think would be bad. Having a space for vendors and others to experiment with new options (or use site options if they so chose) is a good idea. This can be a smaller range. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, January 23, 2002 7:38 AM To: Ralph Droms Cc: Bernie Volz (EUD); dhcwg@ietf.org Subject: Re: [dhcwg] Assigning DHCPv6 option codes I am unaware of a single example where site-specific options have ever been used. This is why I think it's better not to put language about reserved portions of the option space in the base draft - I think we need to figure out what we want to do carefully. Is it really site-specific that we want? What about vendor-specific? What about user-defined? If you want to reserve any space in the draft, I would just call the reserved space "experimental" rather than being specific about who can use it. Reserving 4096 codes is probably plenty, though, as you say - I don't think we need 32k. ------_=_NextPart_001_01C1A425.4A7DFB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am happy with calling this option space = "experimental".

With DHCPv6, getting an option number is much less of = an issue. However, it takes work to write an I-D and get it to RFC. = Some vendors may not chose to do through this process.

If we allow vendors to request option numbers from = IANA without formally publishing an I-D or RFC, that should be OK (from = an available number space issue). However, it does likely mean we'll = have an explosion of options and might often have lots of very similar = options. That I think would be bad.

Having a space for vendors and others to experiment = with new options (or use site options if they so chose) is a good idea. = This can be a smaller range.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Wednesday, January 23, 2002 7:38 AM
To: Ralph Droms
Cc: Bernie Volz (EUD); dhcwg@ietf.org
Subject: Re: [dhcwg] Assigning DHCPv6 option = codes

I am unaware of a single example where site-specific = options have ever been
used.   This is why I think it's better = not to put language about reserved
portions of the option space in the base draft - I = think we need to figure
out what we want to do carefully.   Is it = really site-specific that we want?
    What about = vendor-specific?   What about user-defined?   If = you want to
reserve any space in the draft, I would just call = the reserved space
"experimental" rather than being specific = about who can use it.   Reserving
4096 codes is probably plenty, though, as you say - = I don't think we need
32k.

------_=_NextPart_001_01C1A425.4A7DFB00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Jan 23 11:15:05 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 LAA14297 for