From owner-dhcp-v4@bucknell.edu  Sun Jul  2 10:48:17 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08306
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 2 Jul 2000 10:48:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e62EiPW16372;
	Sun, 2 Jul 2000 10:44:25 -0400 (EDT)
Received: from monitor.internaut.com (mg-206191146-48.ricochet.net [206.191.146.48])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e62EiFW27081
	for <dhcp-v4@bucknell.edu>; Sun, 2 Jul 2000 10:44:16 -0400 (EDT)
Received: from kidneybean ([204.57.137.38])
	by monitor.internaut.com (8.9.2/8.8.8) with SMTP id HAA64641;
	Sun, 2 Jul 2000 07:41:28 -0700 (PDT)
From: aboba@internaut.com
Reply-To: <aboba@internaut.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: ASCII text message option (option 56) 
Date: Sun, 2 Jul 2000 07:44:03 -0700
Message-ID: <000201bfe433$f7c28a50$268939cc@ntdev.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200006292254.PAA01256@grosse.bisbee.fugue.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

>That was probably a poor choice of words.   I'm talking about network
>registration.   You walk into a new site, plug in your laptop, and
>bang, up comes a registration page where you can identify yourself to
>the network and potentially register so that you can get access to
>it.   I'm not talking about network signon in the sense of a known
>user authenticating him- or herself.

I don't think we should be going down the road toward thinking of
DHCP as a network access control mechanism. It cannot be effective
for that, since a client can choose a static address. 

Typically, the functionality that has been described exists within
the chosen access method. For example, PPP and IEEE 8021.X have 
provisions for this. So the "registration for access to the network"
scenario does not seem compelling.   

I also really do not like the idea of being able to cause all clients
on the network to go to a web page. Just think about all the opportunities
to make a "statement" via this facility. So it seems like there are some
security issues here -- possibly requiring this option to only be  
used with authenticated DHCP or https URLs. 



From owner-dhcp-v4@bucknell.edu  Sun Jul  2 23:52:47 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14551
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 2 Jul 2000 23:52:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e633nZW24237;
	Sun, 2 Jul 2000 23:49:35 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e633nMW20710
	for <dhcp-v4@bucknell.edu>; Sun, 2 Jul 2000 23:49:22 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <N42TBDG0>; Sun, 2 Jul 2000 23:49:06 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBEAE@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: "'mjs@cisco.com'" <mjs@cisco.com>
Subject: RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12
Date: Sun, 2 Jul 2000 23:48:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I think some previous discussion had suggested the use of the TXT record
instead? But, I could be wrong.

Perhaps Mark Stapp will jump in here and answer some of these issues.

- Bernie

-----Original Message-----
From: jjcorc@us.ibm.com [mailto:jjcorc@us.ibm.com]
Sent: Friday, June 30, 2000 10:02 AM
To: DHCPv4 discussion list
Subject: RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12



Thanks for the reply. I do understand the concept of who owns each record.
I just didn't see a purpose for the DHCID associated with the PTR, other
than as you suggested, it being a mechanism for an administrator to try and
tell who updated the record. Although, if it is "scrambled" via a hash
algorithm, I'm still not sure how useful it would be.

I guess I was just looking for a more definitive answer, like "oh that's
there because in the next version of the draft you'll see...." or "Yes you
are correct, and there really isn't a need for a DHCID record associated
with a PTR record."

Presently, since BIND8 DNS doesn't support DHCID (at least to my
knowledge), does anyone see a problem with using the KEY RR in place of the
DHCID which was the proposed method in a previous version of the subject
draft? At least that way a DHCP server capable of dynamic DNS updates could
be developed now that would interface to any BIND 8 DNS server.

Jack Corcoran
jjcorc@us.ibm.com
 Ph  607-752-5570,  T/L 852-5570, FAX: 607-752-5421



From owner-dhcp-v4@bucknell.edu  Mon Jul  3 18:20:07 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08057
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 3 Jul 2000 18:20:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e63MGlW29103;
	Mon, 3 Jul 2000 18:16:48 -0400 (EDT)
Received: from postal.metaip.checkpoint.com (metaip.checkpoint.com [204.29.28.25])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e63MGaW13144
	for <dhcp-v4@bucknell.edu>; Mon, 3 Jul 2000 18:16:36 -0400 (EDT)
Received: from cartman.metainfo.com (cartman.metainfo.com [204.29.28.145])
	by postal.metaip.checkpoint.com (8.9.3/8.9.3VRJ666) with ESMTP id PAA29616;
	Tue, 4 Jul 2000 15:10:18 -0700
Received: by cartman.metainfo.com with Internet Mail Service (5.5.2650.21)
	id <MLNK3M3P>; Mon, 3 Jul 2000 15:09:31 -0700
Message-ID: <B5C5D2CDB8BCD2118E4800A0C9D8E4C7C37F49@cartman.metainfo.com>
From: richardj@metaip.checkpoint.com
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: mjs@cisco.com
Subject: RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12
Date: Mon, 3 Jul 2000 15:09:28 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: richardj@metaip.checkpoint.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I wasn't at the IETF meeting in Adelaide, but I was told that there was some
substantial discussion of breaking this draft into two separate drafts. Mark
Stapp has mentioned in a private message that he and some others are
working now on deciding how to proceed. 

As far as the DHCID record goes, there was a draft submitted by a member
of the dnsext working group, but for reasons we don't know it was allowed
to expire. Mark is in the process of submitting a new draft to define a
DHCID record, which will presumably be much like the earlier draft. 

The use of the KEY RR caused much consternation in the dnsext working
group, and I think was vigorously opposed by some of its members, though
I can't restate the discussion. Hopefully Mark will be able to comment on
the type of RR to use soon.

One good reason for associating an ID RR of some sort with PTR records
has to do with the failover protocol, which is in draft form right now, but
quite solid. Failover partners want to know who has been responsible for
updating name servers for the express purpose of not duplicating updates
when one or the other handles lease transactions. The use of an ID RR, 
along with a knowledge of the partner's state, makes it easy to decide if
a particular partner should perform an update, especially when the client
has exercised the FQDN option and done the A RR itself.

Richard
	-----Original Message-----
	From:	Bernie Volz [SMTP:Volz@ipworks.com]
	Sent:	Sunday, July 02, 2000 8:49 PM
	To:	DHCPv4 discussion list
	Cc:	'mjs@cisco.com'
	Subject:	RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12

	I think some previous discussion had suggested the use of the TXT
record
	instead? But, I could be wrong.

	Perhaps Mark Stapp will jump in here and answer some of these
issues.

	- Bernie

	-----Original Message-----
	From: jjcorc@us.ibm.com [mailto:jjcorc@us.ibm.com]
	Sent: Friday, June 30, 2000 10:02 AM
	To: DHCPv4 discussion list
	Subject: RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12



	Thanks for the reply. I do understand the concept of who owns each
record.
	I just didn't see a purpose for the DHCID associated with the PTR,
other
	than as you suggested, it being a mechanism for an administrator to
try and
	tell who updated the record. Although, if it is "scrambled" via a
hash
	algorithm, I'm still not sure how useful it would be.

	I guess I was just looking for a more definitive answer, like "oh
that's
	there because in the next version of the draft you'll see...." or
"Yes you
	are correct, and there really isn't a need for a DHCID record
associated
	with a PTR record."

	Presently, since BIND8 DNS doesn't support DHCID (at least to my
	knowledge), does anyone see a problem with using the KEY RR in place
of the
	DHCID which was the proposed method in a previous version of the
subject
	draft? At least that way a DHCP server capable of dynamic DNS
updates could
	be developed now that would interface to any BIND 8 DNS server.

	Jack Corcoran
	jjcorc@us.ibm.com
	 Ph  607-752-5570,  T/L 852-5570, FAX: 607-752-5421



From owner-dhcp-v4@bucknell.edu  Mon Jul  3 23:15:32 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11895
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 3 Jul 2000 23:15:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e643CdW32137;
	Mon, 3 Jul 2000 23:12:39 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e643CaW28632
	for <dhcp-v4@bucknell.edu>; Mon, 3 Jul 2000 23:12:36 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a43.pm3-28.theriver.com [206.102.195.59]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id EAA18545; Mon, 3 Jul 2000 04:32:28 -0700 (PDT)
Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id UAA01568; Mon, 3 Jul 2000 20:13:00 -0700 (MST)
Message-Id: <200007040313.UAA01568@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>, mjs@CISCO.COM
Subject: Re: Use of DHCID in draft-ietf-dhc-dhcp-dns-12 
In-Reply-To: Message from richardj@metaip.checkpoint.com 
   of "Mon, 03 Jul 2000 15:09:28 MST." <B5C5D2CDB8BCD2118E4800A0C9D8E4C7C37F49@cartman.metainfo.com> 
Date: Mon, 03 Jul 2000 20:13:00 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> One good reason for associating an ID RR of some sort with PTR records
> has to do with the failover protocol, which is in draft form right now, but
> quite solid. Failover partners want to know who has been responsible for
> updating name servers for the express purpose of not duplicating updates
> when one or the other handles lease transactions. The use of an ID RR, 
> along with a knowledge of the partner's state, makes it easy to decide if
> a particular partner should perform an update, especially when the client
> has exercised the FQDN option and done the A RR itself.

I don't understand why this is considered useful.   You can avoid
updating the zone by just making the prerequisite for the update be
that the PTR record not contain the same information.   I think BIND
may even optimize out the update if it doesn't cause a change.   So I
don't see how it helps to put the ID on the PTR.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Wed Jul  5 12:56:45 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11460
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 5 Jul 2000 12:56:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e65Gr3W03881;
	Wed, 5 Jul 2000 12:53:03 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e65GqqW11221
	for <dhcp-v4@bucknell.edu>; Wed, 5 Jul 2000 12:52:52 -0400 (EDT)
Received: from mjs-pc (mjs-pc.cisco.com [172.27.181.69]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA22272; Wed, 5 Jul 2000 12:52:04 -0400 (EDT)
Message-Id: <4.2.0.58.20000705090051.01d3f740@funnel.cisco.com>
X-Sender: mjs@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 05 Jul 2000 12:54:11 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Mark Stapp <mjs@cisco.com>
Subject: RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12
Cc: dhcp-v4@bucknell.edu
In-Reply-To: <8525690E.004D0F6C.00@D51MTA06.pok.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: mjs@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Sorry I was out of the loop for the start of this exchange. Let me try to 
answer the specific questions you asked, and explain what I plan to do for 
the next ietf.

I've specified that a DHCID rr be associated with any A or PTR rr that's 
added by a dhcp client or server. There's no way for an updater to 
distinguish between RRs that have been added by an administrator and RRs 
that have been added via ddns updates without such an association. It's 
seemed to me that the presence of the DHCID rr makes it possible to do two 
things. First, updaters who discover PTR rrs without an appropriate DHCID 
rr could be configured to avoid updates (or at least log warnings about 
them) if they might interfere with some administrator's intentions. Second, 
administrative applications can use the presence of the DHCID rr to warn a 
user that an administrative change may affect rrs that dhcp servers think 
they are responsible for.

I had proposed using a form of the KEY rr to associate dhcp information 
with other rrs in earlier versions of the draft. The DNSEXT folks were 
adamant in reserving the use of KEY for security-related information 
exclusively, and a clever DNS person proposed the DHCID rr as a solution. I 
agree that it's unfortunate that there are deployment difficulties in 
adding a new rrtype, but that's sort of where we are.

As a result of some discussions that took place during the Adelaide ietf, 
I'm splitting the single dhcp-dns draft into three pieces. There will be an 
"FQDN Option" draft, a draft on the use of the DHCID rr to detect and 
resolve DDNS conflicts, and a draft with suggestions for using the DDNS 
prerequisites to accomplish that. I'll also be re-submitting the DHCID 
draft to the dnsext working group. At this point, I don't plan to make 
significant changes to the mechanism as it stands in dhcp-dns-12.

Regards,
Mark

At 09:01 AM 6/30/00 -0500, you wrote:

>Thanks for the reply. I do understand the concept of who owns each record.
>I just didn't see a purpose for the DHCID associated with the PTR, other
>than as you suggested, it being a mechanism for an administrator to try and
>tell who updated the record. Although, if it is "scrambled" via a hash
>algorithm, I'm still not sure how useful it would be.
>
>I guess I was just looking for a more definitive answer, like "oh that's
>there because in the next version of the draft you'll see...." or "Yes you
>are correct, and there really isn't a need for a DHCID record associated
>with a PTR record."
>
>Presently, since BIND8 DNS doesn't support DHCID (at least to my
>knowledge), does anyone see a problem with using the KEY RR in place of the
>DHCID which was the proposed method in a previous version of the subject
>draft? At least that way a DHCP server capable of dynamic DNS updates could
>be developed now that would interface to any BIND 8 DNS server.
>
>Jack Corcoran
>jjcorc@us.ibm.com
>  Ph  607-752-5570,  T/L 852-5570, FAX: 607-752-5421
>



From owner-dhcp-v4@bucknell.edu  Wed Jul  5 15:40:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15443
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 5 Jul 2000 15:40:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e65JbpW28713;
	Wed, 5 Jul 2000 15:37:51 -0400 (EDT)
Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e65JbbW11537
	for <dhcp-v4@bucknell.edu>; Wed, 5 Jul 2000 15:37:37 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-140.cisco.com [161.44.133.140])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id PAA09492;
	Wed, 5 Jul 2000 15:37:34 -0400 (EDT)
Message-Id: <4.3.1.2.20000705153158.00b62ac0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 05 Jul 2000 15:33:26 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12
Cc: dhcp-v4@bucknell.edu
In-Reply-To: <4.2.0.58.20000705090051.01d3f740@funnel.cisco.com>
References: <8525690E.004D0F6C.00@D51MTA06.pok.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: droms@bucknell.edu
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Mark - is there any chance you will be able to rev the drafts by the 
publication deadline for the Pittsburgh IETF (7/14)?  Anything I can do to 
help?

- Ralph



From owner-dhcp-v4@bucknell.edu  Thu Jul  6 16:49:44 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25326
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 6 Jul 2000 16:49:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e66KjgW12537;
	Thu, 6 Jul 2000 16:45:42 -0400 (EDT)
Received: from mail.coreon.net (IDENT:mirapoint@node-64-248-71-34.dslspeed.zyan.com [64.248.71.34])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e66KjUW02018
	for <dhcp-v4@bucknell.edu>; Thu, 6 Jul 2000 16:45:30 -0400 (EDT)
Received: from rmoats (tconl88113.tconl.com [204.26.88.113])
	by mail.coreon.net (Mirapoint)
	with ESMTP id AAA34653 (AUTH rmoats);
	Thu, 6 Jul 2000 16:45:24 -0400 (EDT)
From: "Ryan Moats" <rmoats@coreon.net>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: <dhcp-v4@bucknell.edu>, <dhcp-schema@lists.process.com>
Subject: Comments on -schema-02
Date: Thu, 6 Jul 2000 15:44:53 -0500
Message-ID: <OAEPJLLCHIJCOBJMOMBOOEICCBAA.rmoats@coreon.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0006_01BFE761.20931FA0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Reply-To: rmoats@coreon.net
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01BFE761.20931FA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Having sat down this week and read through 
the LDAP schema draft thoroughly, I have a
lot of comments.  My apologies for sending
them as a RTF attachment, but I didn't want
to pollute those folks who don't like HTML
and there were enough comments/questions/
changes that I thought some callout was 
necessary.  On the plus side, the
attachment contains ABNF that is conforms
to RFC 2252.

My apologies if these topics have been
discussed previously.  I didn't see them
in the mailing list archives and couldn't
find any archives for the sublist.  If they've
already been hashed out, that's great, but
some of the decision process should be captured
in the draft.

Looking forward to discussing points, as
needed.

Ryan Moats
Coreon, Inc.
rmoats@coreon.net


------=_NextPart_000_0006_01BFE761.20931FA0
Content-Type: application/msword;
	name="draft-ietf-dhc-schema-02-comments.rtf"
Content-Disposition: attachment;
	filename="draft-ietf-dhc-schema-02-comments.rtf"
Content-Transfer-Encoding: quoted-printable

{\rtf1\ansi\ansicpg1252\deff0{\fonttbl{\f0\fnil\fcharset0 Courier New;}}
{\colortbl ;\red255\green0\blue0;\red0\green0\blue0;}
\viewkind4\uc1\pard\cf1\lang1033\f0\fs20 My comments are delimited by =
<rm> and </rm>\par
\cf0\par
Network Working Group                                       Andy =
Bennett\par
INTERNET-DRAFT                                               Bernie =
Volz\par
                                                        Process =
Software\par
\par
                                                              March =
2000\par
                                                  Expires September =
2000\par
\par
\par
                          DHCP Schema for LDAP\par
                     <draft-ietf-dhc-schema-02.txt>\par
\par
Status of this Memo\par
\par
   This document is an Internet-Draft and is in full conformance =
with\par
   all provisions of Section 10 of RFC2026.\par
\par
   Internet-Drafts are working documents of the Internet Engineering\par
   Task Force (IETF), its areas, and its working groups.  Note that\par
   other groups may also distribute working documents as Internet-\par
   Drafts.\par
\par
   Internet-Drafts are draft documents valid for a maximum of six =
months\par
   and may be updated, replaced, or obsoleted by other documents at =
any\par
   time.  It is inappropriate to use Internet-Drafts as reference\par
   material or to cite them other than as "work in progress."\par
\par
   The list of current Internet-Drafts can be accessed at\par
   http://www.ietf.org/ietf/1id-abstracts.txt\par
\par
   The list of Internet-Draft Shadow Directories can be accessed at\par
   http://www.ietf.org/shadow.html.\par
\par
Copyright Notice\par
\par
   Copyright (C) The Internet Society (2000). All Rights Reserved.\par
\par
Abstract\par
\par
   This document presents an LDAP schema to represent the =
configuration\par
   of the DHCP protocol within a TCP/IP network.  It can be used to\par
   represent the configuration(s) of an entire enterprise network, a\par
   subset of the network, or even a single server.\par
\par
1.  Terminology\par
\par
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =
NOT",\par
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in =
this\par
   document are to be interpreted as described in RFC 2119 =
[RFC2119].\par
   In places where different sets of terminology are commonly used =
to\par
   represent similar DHCP concepts, this schema uses the terminology =
of\par
   the Internet Software Consortium's DHCP server reference =
implementa-\par
   tion.  For more information see www.isc.org.\par
\par
2.  Design Considerations\par
\par
   Some of the design considerations for this schema were:\par
\par
   o Heterogeneous server environment - This schema is not designed =
to\par
     represent the configuration of a specific DHCP server =
implementa-\par
     tion.  The intent of this schema is to provide a basic =
framework\par
     for the representation of the most common elements used in the =
con-\par
     figuration of DHCP.  This should allow other network services =
to\par
     obtain and use basic DHCP configuration information in a =
server-\par
     independent way.  Also note that it is highly unlikely that =
this\par
     schema will be able to represent every feature of every =
implementa-\par
     tion (and it is not intended to do so).  It is expected that =
some\par
     implementations may need to extend the schema objects in order =
to\par
     fully implement all their features.\par
\par
   o Use of the schema - This draft does not define any "minimal =
compli-\par
     ance criteria" for using the schema.  It is recommended that =
you\par
     use the object classes defined in this draft if you are =
represent-\par
     ing DHCP configuration information in an LDAP directory.  Some\par
     implementations may choose not to support all of the objects\par
     defined here.  In particular, the following two decisions are\par
     explicitly left up to the implementation:\par
\par
     - it is up to the implementation to determine whether or not =
the\par
       lease information will be stored in the directory.  Some =
imple-\par
       mentations may choose not to store this information.\par
\par
     - it is up to the implementation to determine if the data in =
the\par
       directory is considered "authoritative", or if it is simply a\par
       copy of data from an authoritative source.\par
\par
\cf1 <rm>There is also the layout of objects in the DIT.  If this is =
not\par
specified, it should be included in the above list.</rm>\cf0\par
\par
   o The schema is focused on the representation of configuration =
infor-\par
     mation.  It does not provide for the representation of =
statistical\par
     data, or historical lease data, only the current state of the =
DHC\par
     protocol's configuration.\par
\par
   o The information in this schema will be used primarily by two =
types\par
     of applications:  DHCP servers (for loading their =
configuration)\par
     and Management Interfaces (for defining/editing =
configurations).\par
     The schema should must be efficient for the needs of both types =
of\par
     applications.\par
\par
   o The schema is designed to allow objects managed by DHCP (such =
as\par
     computers, subnets, etc) to be present anywhere in a directory\par
     hierarchy (to allow those objects to be placed in the directory =
for\par
     managing administrative control and access to the objects).  =
How-\par
     ever, the schema also provides for the possibility that any =
given\par
     object may have multiple sets of configuration parameters =
defined\par
     for different servers.\par
\par
   o The schema uses a few naming conventions - all object classes =
and\par
     attributes are prefixed with "dhcp" and there are no object =
classes\par
     and attributes that have the same name.  The schema also uses =
stan-\par
     dard naming attributes ("cn", "ou", etc) for all objects.  In =
some\par
     cases it is recommended that the "cn" matches another attribute\par
     value.\par
\par
\cf1 <rm>Your schema doesn't actually specify naming attributes (via =
NAMEFORM\par
rules), so you are in effect, leaving it up to the directory\par
administrator. Futher, using "cn" as the ONLY naming attribute\par
(certain implementations aside) is in general a BAD thing.\par
You should be specific here that this naming attributes are "hints"\par
or provide a true naming discussion.</rm>\cf0\par
\par
   o Relationship to DEN/DMTF - This document takes into =
consideration\par
     the object-oriented information model for representing Network\par
     information (including DHCP information) currently under =
develop-\par
     ment as part of the Common Information Model (CIM) activity in =
the\par
     Distributed Management Task Force (DMTF).  It should be noted =
that\par
     the CIM schema is still under development and subject to =
change.\par
     The DMTF efforts continue and draw upon the Directory-Enabled =
Net-\par
     works (DEN) specification.  The schema described in this =
Internet-\par
     Draft is intended to be an LDAP implementation of the =
appropriate\par
     objects in the DMTF model.  The DMTF schema was used as a =
source\par
     for defining certain terminology within this schema.  For more\par
     information see [DMTF] and [DEN].  Prior versions of this draft\par
     included a mapping between the two schemas, but this has been\par
     removed since the DMTF schema is still under development.  When =
it\par
     is complete a new draft may be published to document the =
mapping\par
     between the schemas.\par
\par
\cf1 <rm>Having read this draft, I'm not sure I feel that this statement =
is defensible.  There are several LDAP mappings from the DMTF available =
at\par
http://www.dmtf.org/spec/denh.html that this draft has ignored. =
Since\par
these mappings include the framework for services, this mapping =
should\par
at minimum include a reference and discussion.</rm>\cf0\par
\par
   o Relationship to Policy Framework working group - Much of the =
infor-\par
     mation in this schema could be represented using the =
generalized\par
     schema being developed by the Policy Framework.  However, there\par
     were two issues that we felt would make this a very complex and\par
     most likely inefficient representation: (1) the complexity of =
the\par
     inheritance relationships between the dhcp policy objects =
defined\par
     in this document and (2) the Policy Framework schema represents\par
     each of the conditions and actions of a policy as separate =
objects.\par
     However, it is still a fairly straightforward process to map =
the\par
     objects from this schema into the Policy Framework Core Schema\par
     objects.  For more information see [POLICY].\par
\par
\cf1 <rm>I read this as another "red flag" with this schema, as I =
don't\par
think that departing from the Policy Framework without mapping\par
informaiton is a good idea</rm>\par
\cf0\par
3.  Common Attributes\par
\par
   Although DHCP manages several different types of objects, the =
config-\par
   uration of those objects is often very similar.  Consequently, =
most\par
   of these objects have a common set of attributes.\par
\par
   The dhcpConfigurableObject class is an auxiliary class which can =
be\par
   used to associate the basic set of configuration attributes with\par
   another object.  Since some directories do not provide auxiliary\par
   classes we have also repeated these common attributes in the =
defini-\par
   tion of each of the DHCP object class definitions.\par
\par
\cf1 <rm>Rather than repeat the attributes, a super class might make =
more\par
sense.</rm>\cf0\par
\par
   An implementation of this schema is not required to provide this =
aux-\par
   iliary object class, but it SHOULD provide it if auxiliary =
classes\par
   are supported.  This is useful for associating DHCP configuration\par
   settings for objects that are not directly defined as part of =
this\par
   schema.\par
\par
3.1.  dhcpConfigurableObject Object Class\par
\par
   NAME                dhcpConfigurableObject\par
   DESCRIPTION         A class that provides attributes for =
configuring\par
                       options and server parameters for DHCP.\par
   TYPE                Auxiliary\par
   DERIVED FROM        Top\par
   POSSIBLE SUPERIORS  ( )\par
   MUST CONTAIN        ( )\par
   MAY CONTAIN         ( dhcpOptionSetting dhcpParameterSetting\par
                         dhcpFieldSetting dhcpForcedOptions\par
                         dhcpIncludeOptionSet )\par
\par
\cf1 <rm>This is not a schema object.  RFC 2252 requires objects be =
specified\par
in ABNF.  I also don't like inheriting from top.  Rather, all of the =
dhcp\par
classes should be rooted at a common point other than that.\par
\par
I would suggest the following class (note, all tokens delimited\par
by <> are TBD OIDs):\par
\par
   ( <dhcp-oid-oc-1> NAME 'dhcpConfiguratbleObject'\par
     DESC 'A class that provides attributes for configuring\par
\tab      options and server parameters for DHCP.'\par
     AUXILIARY\par
     SUP dhcpService\par
   )\par
</rm>\cf0\par
\par
3.2.  Common Attribute Definitions\par
\par
   NAME         dhcpOptionSetting\par
   DESCRIPTION  Encoded option values to be sent to clients.  Each =
value\par
                represents a single option and contains (OptionTag,\par
                Length, OptionValue) encoded in the 16-bit format =
used\par
                by DHCP.  For more information see [DHCPOPT].\par
   SYNTAX       OctetString MULTI-VALUE\par
\par
\cf1 <rm>This should be\par
   ( <dhcp-oid-at-1> NAME 'dhcpOptionSetting'\par
     DESC 'Encoded option values to be sent to clients.  Each value\par
           represents a single option and contains (OptionTag,\par
           Length, OptionValue) encoded in the 16-bit format used\par
           by DHCP.'\par
     SYNTAX OctetString\par
   )\par
</rm>\cf0\par
\par
   NAME         dhcpParameterSetting\par
   DESCRIPTION  Encoded values of parameters that control server =
behav-\par
                ior.  Each value represents a single parameter =
setting\par
                in the form (ParameterName, ParameterValue) where =
the\par
                parameter name is a set of ASCII characters followed =
by\par
                a space followed by the parameter value as a string.\par
   SYNTAX       IA5String MULTI-VALUE\par
\par
\cf1 <rm>This should be\par
   ( <dhcp-oid-at-2> NAME 'dhcpParameterSetting'\par
     DESC 'Encoded values of parameters that control server\par
\tab      behavior.  Each value represents a single parameter\par
\tab      setting in the form (ParameterName, ParameterValue)\par
\tab      where the parameter name is a set of ASCII characters\par
\tab      followed by a space followed by the parameter value\par
\tab      as a string.'\par
     SYNTAX IA5String\par
   )\par
\par
However, there also needs to be a clarification statement of the\par
fact that ParameterValue and ParameterName will never contain\par
spaces.  If they in fact will, then there needs to be a discussion\par
of how the embeddd spaces are encoded.\par
</rm>\cf0\par
\par
   NAME         dhcpFieldSetting\par
   DESCRIPTION  Encoded settings of fields (such as siaddr, file) in =
the\par
                DHCP message whose values may be configurable for =
send-\par
                ing back to a client.  For more information see\par
                [RFC951].  Encoded in the form (FieldName, =
FieldValue)\par
                where the field name is a set of ASCII characters =
fol-\par
                lowed by a space followed by the field value as a\par
                string.\par
   SYNTAX       IA5String MULTI-VALUE\par
\par
\cf1 <rm>This should be\par
   ( <dhcp-oid-at-3> NAME 'dhcpFieldSetting'\par
     DESC 'Encoded settings of fields (such as siaddr, file) in the\par
           DHCP message whose values may be configurable for sending\par
           back to a client.  For more information see [RFC951].\par
\tab      Encoded in the form (FieldName, FieldValue) where the\par
\tab      field name is a set of ASCII characters followed by a\par
\tab      space followed by the field value as a string.\par
     SYNTAX IA5String\par
   )\par
\par
As above, there also needs to be a clarification statement of the\par
fact that ParameterValue and ParameterName will never contain\par
spaces.  If they in fact will, then there needs to be a discussion\par
of how the embeddd spaces are encoded.\par
</rm>\cf0\par
\par
   NAME         dhcpForcedOptions\par
   DESCRIPTION  This is a list of DHCP option tags that MUST be sent =
to\par
                clients.  If not specified, the server only sends =
the\par
                options back to the client which were requested.\par
   SYNTAX       Integer MULTI-VALUE\par
\par
\cf1 <rm>This should be\par
   ( <dhcp-oid-at-4> NAME 'dhcpForcedOptions'\par
     DESC 'This is a list of DHCP option tags that MUST be sent to\par
           clients.  If not specified, the server only sends the\par
           options back to the client which were requested.'\par
     SYNTAX Integer\par
   )\par
</rm>\cf0\par
\par
   NAME         dhcpIncludeOptionSet\par
   DESCRIPTION  The distinguished name(s) of dhcpNamedOptionSet =
objects\par
                whose settings should be included for this object.  =
If\par
                there are multiple option sets, the order is =
important\par
                so each value is preceded by it's precedence, =
followed\par
                by a colon as in "1:dn1", "2:dn2", etc.  Settings\par
                defined on the object take precedence over any =
settings\par
                found in an included option set.\par
   SYNTAX       IA5String MULTI-VALUE\par
\par
\cf1 <rm>This should read\par
   ( <dhcp-oid-at-5> NAME 'dhcpIncludeOptionSet'\par
     DESC 'The distinguished name(s) of dhcpNamedOptionSet objects\par
           whose settings should be included for this object.  If\par
           there are multiple option sets, the order is important\par
           so each value is preceded by it's precedence, followed\par
           by a colon as in "1:dn1", "2:dn2", etc.  Settings\par
           defined on the object take precedence over any settings\par
           found in an included option set.'\par
     SYNTAX IA5String\par
   )\par
\par
While this method of encoding precedence with DNs was initial =
proposed\par
in POLICY, it has been depricated in favor of using children objects\par
for each entry.  A statement that this method of encoding prefernece\par
("<precedence>:<dn>") will require extra client code to process the\par
encoding is necessary.\par
</rm>\cf0\par
\par
4.  Configurations and Services\par
\par
   The DHC working group is currently considering several proposals =
for\par
   failover and redundancy of DHCP servers.  These may require the =
shar-\par
   ing of configuration information between servers.  This schema =
pro-\par
   vides a generalized mechanism for supporting any of these =
proposals,\par
   by separating the definition of a server from the definition of =
the\par
   configuration being provided by the server.\par
\par
\cf1 <rm>This is essentially the DMTF approach</rm>\cf0\par
\par
   By separating these two concepts, a configuration may be provided =
by\par
   one or by several servers, and similarly, a server may provide one =
or\par
   more configurations. The schema does allow for a server to be =
config-\par
   ured as either a primary or secondary provider of a =
configuration.\par
\par
   Configurations are also defined so that one configuration can =
include\par
   some of the objects that are defined in another configuration =
(see\par
   "dhcpIncludeObjects" attribute).  This allows for sharing and/or =
a\par
   hierarchy of related configuration items.\par
\par
4.1.  dhcpService Object Class\par
\par
   A "dhcpService" is a single instance of DHC server software =
running\par
   on a computer system that provides the DHCP service defined by a\par
   "dhcpConfiguration".\par
\par
   NAME                dhcpService\par
   DESCRIPTION         This represents a single DHCP server.\par
   TYPE                Structural\par
   DERIVED FROM        Top\par
   POSSIBLE SUPERIORS  ( )\par
   MUST CONTAIN        ( cn )\par
   MAY CONTAIN         ( dhcpConfigurationDn dhcpImplementation )\par
\par
\cf1 <rm>This looks really broken.  If cn is a MUST for naming, then =
this is\par
really broken.  A better object would be\par
\par
   ( <dhcp-oid-oc-2> NAME 'dhcpService'\par
     DESC 'Superclass for all dhcp related objects'\par
     SUP cim23Service\par
     MAY ( cn $ dhcpOptionSetting $ dhcpParameterSetting $\par
\tab      dhcpFieldSetting $ dhcpForcedOptions $\par
\tab      dhcpIncludeOptionSet $ dhcpConfigurationDn $\par
\tab      dhcpImplementation )\par
   )\par
    \par
This takes advantage of the DMTF CIM_Service mapping (cim23Service).  =
The\par
whole naming issue for this class needs to be added.\par
</rm>\par
\cf0\par
4.1.1.  dhcpService Attribute Definitions\par
\par
   NAME         cn\par
   DESCRIPTION  The "common name" of the server.  This does not have =
any\par
                significance to the server process that provides the\par
                DHCP service - it is simply a unique name used to =
refer\par
                to the server.  This attribute should be used as the\par
                naming attribute when constructing the dn.\par
\par
\cf1 <rm>First, you should state that cn's definition is copied from =
RFC2256.\par
Then you should do so:\par
\par
   ( 2.5.4.3 NAME 'cn' SUP name )\par
\par
Finally, cn should not be the only attribute that can be used for =
naming.\par
A perfectly good value would be the FQDN of the server, and while =
that\par
could be stuffed into the cn attribute, I would claim that is =
overloading\par
the semantics of cn.</rm>\par
\cf0\par
   NAME         dhcpConfigurationDn\par
   DESCRIPTION  The distinguished name(s) of the configurations =
provided\par
                by the server.\par
   SYNTAX       DN MULTI-VALUE\par
\par
\cf1 <rm>This should be:\par
   ( <dhcp-oid-at-6> NAME 'dhcpConfigurationDn'\par
     DESC 'The distinguished name(s) of the configurations provided\par
           by the server.'\par
     SYNTAX DN\par
   )\par
</rm>\par
\par
\cf0    NAME         dhcpImplementation\par
   DESCRIPTION  This is a string value that identifies the hard-\par
                ware/software platform and version which is =
providing\par
                the service.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\par
\cf1 <rm>Does this information have to be in English?  If not, it should =
be\par
DirectoryString:\par
   ( <dhcp-oid-at-7> NAME 'dhcpImplementation'\par
     DESC 'This is a string value that identifies the hard-\par
           ware/software platform and version which is providing\par
           the service.'\par
     SYNTAX DirectoryString SINGLE-VALUE\par
   )\par
If it does have to be in English, an explanation of why is in order.\par
</rm>\par
\par
\cf0 4.2.  dhcpConfiguration Object Class\par
\par
   A "dhcpConfiguration" is the collection of configuration =
information\par
   that represents everything a server would need to know to provide =
DHC\par
   service to some set of clients.\par
\par
   From the perspective of the schema, it is basically a collection =
of\par
   objects.  This object class is used to capture information common =
to\par
   all the objects in a configuration.  The algorithm used to locate =
all\par
   the objects in a configuration is discussed later.\par
\par
   NAME                dhcpConfiguration\par
   DESCRIPTION         This represents a configuration, or a =
collection\par
                       of settings for related objects.  A single =
ser-\par
                       vice may have multiple configurations.  A =
config-\par
                       uration may be provided by multiple services, =
but\par
                       only one can be primary.\par
   TYPE                Structural\par
   DERIVED FROM        Top\par
   POSSIBLE SUPERIORS  ( )\par
   MUST CONTAIN        ( cn )\par
   MAY CONTAIN         ( dhcpPrimaryService dhcpSecondaryService\par
                         dhcpIncludeObjects dhcpOptionSetting\par
                         dhcpParameterSetting dhcpFieldSetting\par
                         dhcpForcedOptions dhcpIncludeOptionSet )\par
\par
\cf1 <rm>I don't understand why you aren't inheriting from\par
cim23Configuration.  I would suggest the following definition:\par
   ( <dhcp-oid-oc-3> NAME 'dhcpConfiguration'\par
     DESC 'This represents a configuration, or a collection\par
           of settings for related objects.  A single ser-\par
           vice may have multiple configurations.  A config-\par
           uration may be provided by multiple services, but\par
           only one can be primary.'\par
     SUP cim23Configuration\par
     MAY ( cn $ dhcpPrimaryService $ dhcpSecondaryService $\par
           dhcpIncludeObjects $ dhcpOptionSetting $\par
           dhcpParameterSetting $ dhcpFieldSetting $\par
           dhcpForcedOptions $ dhcpIncludeOptionSet\cf0  \cf1 )\par
   )\par
</rm>\cf0\par
\par
4.2.1.  dhcpConfiguration Attribute Definitions\par
\par
   NAME         cn\par
   DESCRIPTION  The "common name" of the configuration. This should =
be\par
                used as the naming attribute when constructing the =
dn.\par
\par
\cf1 <rm>Once this has been defined in this file, it doesn't need to =
be\par
stated again</rm>\cf0\par
\par
   NAME         dhcpPrimaryService\par
   DESCRIPTION  The "dhcpService" which is the primary for the =
configu-\par
                ration.\par
   SYNTAX       DN SINGLE-VALUE\par
\par
\cf1 <rm>\par
   ( <dhcp-oid-at-8> NAME 'dhcpPrimaryService'\par
     DESC 'The "dhcpService" which is the primary for the configu-\par
           ration.'\par
     SYNTAX DN SINGLE-VALUE\par
   )\par
</rm>\par
\par
\cf0    NAME         dhcpSecondaryService\par
   DESCRIPTION  The "dhcpService(s)" which provide backup for the =
con-\par
                figuration.\par
   SYNTAX       DN MULTI-VALUE\par
\cf1\par
<rm>\par
   ( <dhcp-oid-at-9> NAME 'dhcpSecondaryService'\par
     DESC 'The "dhcpService(s)" which provides backup for the =
configu-\par
           ration.'\par
     SYNTAX DN\par
   )\par
</rm>\par
\cf0\par
   NAME         dhcpIncludeObjects\par
   DESCRIPTION  This attribute defines objects that are included in =
a\par
                configuration.  Each value is an LdapURL [RFC2255]\par
                (specifying search criteria) that is evaluated to =
find\par
                other objects that are included in this =
configuration.\par
                Note that in addition to these objects, all objects =
that\par
                are children of the configuration object in the =
direc-\par
                tory are automatically included in the =
configuration.\par
   SYNTAX       IA5String MULTI-VALUE\par
\cf1\par
<rm>\par
   ( <dhcp-oid-at-10> NAME 'dhcpIncludeObjects'\par
     DESC 'This attribute defines objects that are included in a\par
           configuration.  Each value is an LdapURL [RFC2255]\par
           (specifying search criteria) that is evaluated to find\par
           other objects that are included in this configuration.\par
           Note that in addition to these objects, all objects that\par
           are children of the configuration object in the direc-\par
           tory are automatically included in the configuration.\par
\tab      Note, this value should only be used for objects that\par
\tab      are not held by this server.  Objects held by this server\par
\tab      may be referenced by including alias objects under this\par
\tab      configuration object.'\par
     SYNTAX IA5String\par
   )\par
</rm>\par
\cf0\par
5.  Objects that represent Assignment Rules\par
\par
   Most of a DHCP configuration is the definition of rules that =
govern\par
   the assignment of DHCP options and addresses to clients.  This =
schema\par
   defines a set of object classes which are common to most server\par
   implementations for defining these rules.  All of these object\par
   classes are based on a higher level abstraction that represents a\par
   dhcp assignment rule.\par
\par
   This is done for several reasons: it simplifies the organization =
of\par
   the data and it also facilitates the mapping of the dhcp schema =
to\par
   other schemas being developed in other working groups (see =
[POLICY]\par
   for example).\par
\par
\cf1 <rm>This argues (a) for inheriting from POLICY's schema, rather =
than directly from top and (b) for adding an example of the =
mapping.</rm>\cf0\par
\par
   This schema separates the definition of an assignment rule for an\par
   object from the object itself.  This allows for the definition of\par
   multiple rules for a single object (possibly in different dhcp =
con-\par
   figurations).  However, each assignment rule does maintain a link\par
   back to the definition of the object (see the "dhcpSourceObject"\par
   attribute).\par
\par
   The structure of a "source object" is not defined in this schema.  =
It\par
   can be any LDAP object, and it is not required to even exist.  =
How-\par
   ever, if it does exist that object can use the =
"dhcpConfigurableOb-\par
   ject" auxiliary class to directly associate dhcp configuration =
infor-\par
   mation with that object.  If an object is defined in this way, =
this\par
   information is used on every assignment rule that references the\par
   object.\par
\par
\cf1 <rm>There needs to be some more explanation and examples here, as I =
am\par
not sure what good a rule is with a "source object" that doesn't =
exist.\par
Further, I think I understand what the last sentence is trying to =
say,\par
but it took me several tries.  An example of object definition would\par
add clarity</rm>\cf0\par
\par
   The assignment rule objects in the directory can be organized in =
a\par
   hierarchical fashion.  If objects are organized this way, the =
"child"\par
   rule object inherits settings from the "parent" rule object.  =
This\par
   can be done recursively.  Furthermore, the "child" rule object =
inher-\par
   its any conditions from the "parent" rule as well.  This means =
that\par
   the "child" rule's settings will only be used when both sets of =
con-\par
   ditions are met.\par
\par
   As an example, if a "dhcpClass" is a child of a "dhcpSubnet" then =
the\par
   settings for that class will only be used if the client request is =
a\par
   member of that class AND it is also from the specified subnet.\par
\par
\cf1 <rm>This implies that you pull the whole dhcp rule tree every time =
you\par
need to load objects.  While a possible implementation, I'm dubious\par
about its effeciency</rm>\cf0\par
\par
   The algorithm for resolving which option settings are applied for =
a\par
   policy object is defined in a later section.\par
\par
5.1.  dhcpRule Object Class\par
\par
   The "dhcpRule" class is an abstract class that defines attributes\par
   that are common to the DHCP configuration objects that define =
these\par
   rules.\par
\par
   This class is the base class from which others are derived.  Also\par
   note that it includes all the attributes from the =
dhcpConfigurableOb-\par
   ject class.\par
\par
   NAME                dhcpRule\par
   DESCRIPTION         The base class for defining rules for address =
and\par
                       option assignment.\par
   TYPE                Abstract\par
   DERIVED FROM        Top\par
   POSSIBLE SUPERIORS  ( )\par
   MUST CONTAIN        ( cn dhcpRuleType )\par
   MAY CONTAIN         ( dhcpVendorCondition dhcpSourceObject\par
                         dhcpOptionSetting dhcpParameterSetting\par
                         dhcpFieldSetting dhcpForcedOptions\par
                         dhcpIncludeOptionSet )\par
\par
\cf1 <rm>There are several things I do not understand about this class: =
First,\par
I see no reason why this can't inherit from policyRule.  That would =
allow\par
policyRuleName to be used as a RDN, which IMHO is a good thing.  =
Second,\par
what is dhcpRuleType doing here?  If it is limited to the =
enumeration\par
stated later, it isn't adding anything, because any filter on =
dhcpRuleType\par
could just as easily be written as a filter on objectClass.  Third, =
this\par
really needs examples because I don't understand how instances of =
this\par
class (and its children) would actually work.  Having said this, I =
would\par
suggest the following class definition (which may be changed based =
on\par
answers to these issues)\par
   ( <dhcp-oid-oc-4> NAME 'dhcpRule'\par
     DESC 'The base class for defining rules for address and\par
           option assignment.'\par
     SUP policyRule ABSTRACT\par
     MAY ( cn $ dhcpVendorCondition $\par
\tab      dhcpSourceObject $ dhcpOptionSetting $\par
\tab      dhcpParameterSetting $ dhcpFieldSetting $ \par
\tab      dhcpForcedOptions $ dhcpIncludeOptionSet )\par
   )</rm>\cf0\par
\par
5.2.  dhcpRule Attribute Definitions\par
\par
   NAME         cn\par
   DESCRIPTION  The "common name" of the rule. This should be used =
as\par
                the naming attribute when constructing the dn.\par
\cf1 <rm>Again, once this has been defined in this file, it doesn't need =
to be\par
stated again. Further, since this is an ABSTRACT class, a dn for =
this\par
class will never be constructed (it can't be instantiated in a =
directory.\par
</rm>\par
\cf0\par
   NAME         dhcpRuleType\par
   DESCRIPTION  The type of assignment rule.  This should be one of\par
                'POOL', 'SUBNET', 'SHAREDNETWORK', 'CLIENT', 'CLASS'\par
                unless the server implementation extends this with a =
new\par
                type of rule.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>As I said before, this attribute isn't doing anything unless =
it\par
is extended by an implementation that DOESN'T create a new =
objectClass.\par
Since, I can't see this happening, this attribute should be =
removed.</rm>\par
\cf0\par
   NAME         dhcpVendorCondition\par
   DESCRIPTION  If the server extends the rule types, this attribute =
MAY\par
                be used to specify the conditions under which the =
rule\par
                should be applied.  The content of this attribute is\par
                defined by the vendor/server implementation.\par
   SYNTAX       IA5String MULTI-VALUE\par
\cf1\par
<rm>   ( <dhcp-oid-at-11> NAME 'dhcpVendorCondition'\par
     DESC 'If the server extends the rule types, this attribute MAY\par
           be used to specify the conditions under which the rule\par
           should be applied.  The content of this attribute is\par
           defined by the vendor/server implementation.'\par
     SYNTAX IA5String\par
   )</rm>\cf0\par
\par
   NAME         dhcpSourceObject\par
   DESCRIPTION  If the rule applies to an object that is defined =
else-\par
                where in the directory, this attribute has the =
distin-\par
                guished name of that object.  The source object =
SHOULD\par
                be a dhcpConfigurableObject.  Also note that the =
source\par
                object is used to determine option & parameter =
settings\par
                (see the algorithm discussed later in this =
document).\par
   SYNTAX       DN SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-12> NAME 'dhcpVendorCondition'\par
     DESC 'If the rule applies to an object that is defined else-\par
           where in the directory, this attribute has the distin-\par
           guished name of that object.  The source object SHOULD\par
           be a dhcpConfigurableObject.  Also note that the source\par
           object is used to determine option & parameter settings.'\par
     SYNTAX DN SINGLE-VALUE\par
   )</rm>\cf0\par
\par
5.3.  dhcpPool Object Class\par
\par
   A "dhcpPool" represents a rule for a collection of addresses =
speci-\par
   fied by one or more ranges of addresses.  If there are multiple\par
   ranges specified, they do not need to be contiguous, and it is =
not\par
   required that all the addresses be contained on the same IP =
subnet.\par
\par
   The "dhcpRuleType" attribute MUST be set to 'POOL', and the "cn"\par
   SHOULD be set to the value of the "dhcpPoolName" attribute".\par
\cf1 <rm>If cn is set to the dhcpPoolName attribute for this class, =
then\par
I could just as easily use dhcpPoolName as the RDN, so that should =
be\par
allowed</rm>\cf0\par
\par
   NAME                dhcpPool\par
   DESCRIPTION         This stores configuration information about =
one\par
                       (or more) ranges of addresses.\par
   TYPE                Structural\par
   DERIVED FROM        dhcpRule\par
   POSSIBLE SUPERIORS  ( OrganizationalUnit dhcpRule )\par
   MUST CONTAIN        ( cn dhcpPoolName dhcpAddressRange )\par
   MAY CONTAIN         ( )\par
\cf1 <rm>As to possible superiors, dhcpRule cannot be used as it is an =
ABSTRACT\par
class above and cannot be instantiated.  If you mean one of the =
structural\par
child objects of dhcpRule, then the text should list them.  In =
addition,\par
you could specify name form and structural rules, but these will only =
be\par
hints as most directory implementations don't support them (and can =
be\par
added later).  This comment applies throughout. Further, I do not\par
understand why organizationalUnit is a possible superior.  More on =
this\par
later.\cf0\par
\cf1    ( <dhcp-oid-oc-5> NAME 'dhcpPool'\par
     DESC 'This stores configuration information about one\par
           (or more) ranges of addresses.'\par
     SUP dhcpRule\par
     MUST ( cn $ dhcpPoolName $ dhcpAddressRange )\par
   )</rm>\par
\cf0\par
5.3.1.  dhcpPool Attribute Definitions\par
\par
   NAME         dhcpPoolName\par
   DESCRIPTION  A descriptive name of the pool.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-13> NAME 'dhcpPoolName'\par
     DESC 'A descriptive name of the pool. May be used as the RDN.'\par
     SYNTAX IA5-String SINGLE-VALUE EQUALITY caseExactIA5Match\par
   )</rm>\par
\cf0\par
   NAME         dhcpAddressRange\par
   DESCRIPTION  The starting & ending IP Addresses in the range =
(inclu-\par
                sive), separated by a hyphen; if the range only =
contains\par
                one address, then just the address can be specified =
with\par
                no hyphen.  Each range is defined as a separate =
value.\par
   SYNTAX       IA5String MULTI-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-14> NAME 'dhcpVendorCondition'\par
     DESC 'The starting & ending IP Addresses in the range (inclu-\par
           sive), separated by a hyphen; if the range only contains\par
           one address, then just the address can be specified with\par
           no hyphen.  Each range is defined as a separate value.'\par
     SYNTAX IA5-String\par
   )</rm>\par
\cf0\par
5.4.  dhcpSubnet Object Class\par
\par
   A "dhcpSubnet" represents an assignment rule for an IP subnet.\par
\par
   The "dhcpRuleType" attribute MUST be set to 'SUBNET', and the =
"cn"\par
   SHOULD be set to the value of the "dhcpSubnetName" attribute".\par
\cf1 <rm>Again, if cn is set to the dhcpSubnetName attribute for this =
class,\par
then I could just as easily use dhcpSubnetName as the RDN, so that\par
should be allowed</rm>\cf0\par
\par
   NAME                dhcpSubnet\par
   DESCRIPTION         This class defines a subnet.\par
   TYPE                Structural\par
   DERIVED FROM        dhcpRule\par
   POSSIBLE SUPERIORS  ( OrganizationalUnit dhcpRule )\par
   MUST CONTAIN        ( cn dhcpSubnetAddress dhcpSubnetMaskLength\par
                         dhcpSubnetName )\par
   MAY CONTAIN         ( )\par
\cf1 <rm>My comment in section 5.3 about possible superiors applies =
here.\cf0\par
\cf1    ( <dhcp-oid-oc-6> NAME 'dhcpSubnet'\par
     DESC 'This class defines a subnet.'\par
     SUP dhcpRule\par
     MUST ( cn $ dhcpSubnetAddress $ dhcpSubnetMaskLength $\par
\tab       dhcpSubnetName )\par
   )</rm>\cf0\par
\par
5.4.1.  dhcpSubnet Attribute Definitions\par
\par
   NAME         dhcpSubnetAddress\par
   DESCRIPTION  The network address for the subnet.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1\par
<rm>   ( <dhcp-oid-at-15> NAME 'dhcpSubnetAddress'\par
     DESC 'The network address for the subnet'\par
     SYNTAX IA5-String SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpSubnetMaskLength\par
   DESCRIPTION  The subnet mask length for the subnet.  The mask can =
be\par
                easily computed from this length.\par
   SYNTAX       Integer SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-16> NAME 'dhcpSubnetMaskLength'\par
     DESC 'The subnet mask length for the subnet.  The mask can be\par
           easily computed from this length.'\par
     SYNTAX Integer SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpSubnetName\par
   DESCRIPTION  A descriptive name of the subnet.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-17> NAME 'dhcpSubnetName'\par
     DESC 'A descriptive name of the subnet. May be used as the =
RDN.'\par
     SYNTAX IA5String SINGLE-VALUE EQUALITY caseExactIA5Match\par
   )</rm>\cf0\par
\par
5.5.  dhcpSharedNetwork Object Class\par
\par
   A "dhcpSharedNetwork" represents an assignment rule for multiple =
sub-\par
   nets on the same physical cabling.\par
\par
   The "dhcpRuleType" attribute MUST be set to 'SHAREDNETWORK', and =
the\par
   "cn" SHOULD be set to the value of the "dhcpSharedNetworkName"\par
   attribute".\par
\cf1 <rm>Again, if cn is set to the dhcpSharedNetworkName attribute =
for\par
this class, then I could just as easily use dhcpSharedNetworkName\par
as the RDN, so that should be allowed</rm>\cf0\par
\par
   NAME                dhcpSharedNetwork\par
   DESCRIPTION         This represents multiple subnets on the same\par
                       physical cabling.\par
   TYPE                Structural\par
   DERIVED FROM        dhcpRule\par
   POSSIBLE SUPERIORS  ( OrganizationalUnit dhcpRule )\par
   MUST CONTAIN        ( cn dhcpSharedNetworkName )\par
   MAY CONTAIN         ( )\par
\cf1 <rm>My comment in section 5.3 about possible superiors applies =
here.\cf0\par
\cf1    ( <dhcp-oid-oc-7> NAME 'dhcpSharedNetwork'\par
     DESC 'This represents multiple subnets on the same\par
           physical cabling.'\par
     SUP dhcpRule\par
     MUST ( cn $ dhcpSharedNetworkName )\par
   )</rm>\cf0\par
\par
5.5.1.  dhcpSharedNetwork Attribute Definitions\par
\par
   NAME         dhcpSharedNetworkName\par
   DESCRIPTION  A descriptive name of the shared network.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-17> NAME 'dhcpSharedNetworkName'\par
     DESC 'A descriptive name of the shared network. May\par
\tab      be used as the RDN.'\par
     SYNTAX IA5String SINGLE-VALUE EQUALITY caseExactIA5Match\par
   )</rm>\cf0\par
\par
5.6.  dhcpClient Object Class\par
\par
   The "dhcpClient" object class is used to store configuration =
informa-\par
   tion related to a specific host.\par
\par
   The "dhcpRuleType" attribute MUST be set to 'CLIENT'.\par
\cf1 <rm>Why doesn't this class have a dhcpClientName that could be used =
as\par
the RDN?</rm>\cf0\par
\par
   NAME                dhcpClient\par
   DESCRIPTION         This represents client-specific DHCP =
assignments.\par
   TYPE                Structural\par
   DERIVED FROM        dhcpRule\par
   POSSIBLE SUPERIORS  ( OrganizationalUnit dhcpRule )\par
   MUST CONTAIN        ( cn dhcpClientIdentifier )\par
   MAY CONTAIN         ( dhcpClassMember dhcpReservedAddress )\par
\cf1 <rm>My comment in section 5.3 about possible superiors applies =
here.\cf0\par
\cf1    ( <dhcp-oid-oc-8> NAME 'dhcpClient'\par
     DESC 'This represents client-specific DHCP assignments.'\par
     SUP dhcpRule\par
     MUST ( cn $ dhcpClientIdentifier $ dhcpClientName )\par
     MAY ( dhcpClassMember $ dhcpReservedAddress )\par
   )</rm>\cf0\par
\par
5.6.1.  dhcpClient Attribute Definitions\par
\par
   NAME         dhcpClientIdentifier\par
   DESCRIPTION  A unique identifier for the client.  This is encoded =
as\par
                follows: the first two octets represent a type and =
sub-\par
                type for the identifier.  If the type field has a =
value\par
                of 0, then the subtype is a dhcp option tag, and the\par
                remainder of the octets are the value of that option =
to\par
                use as an id (represented as it would be sent using =
the\par
                DHCP protocol, including the bytes for the length).  =
If\par
                the type field has a value of 1, then the subtype =
octet\par
                is the ARP hardware type (see [RFC2132]) and the =
remain-\par
                der of the bytes are the hardware address.  Server\par
                implementations may choose to extend the set of =
types,\par
                but these two MUST be recognized.  Note that a =
client\par
                can have more than one unique identifier specified - =
it\par
                is left to the server implementation to decide if one =
or\par
                all identifiers must be matched or which take =
precedence\par
                over others.\par
   SYNTAX       OctetString MULTI-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-18> NAME 'dhcpSharedNetworkName'\par
     DESC 'A unique identifier for the client.  This is encoded as\par
           follows: the first two octets represent a type and sub-\par
           type for the identifier.  If the type field has a value\par
           of 0, then the subtype is a dhcp option tag, and the\par
           remainder of the octets are the value of that option to\par
           use as an id (represented as it would be sent using the\par
           DHCP protocol, including the bytes for the length).  If\par
           the type field has a value of 1, then the subtype octet\par
           is the ARP hardware type (see [RFC2132]) and the remain-\par
           der of the bytes are the hardware address.  Server\par
           implementations may choose to extend the set of types,\par
           but these two MUST be recognized.  Note that a client\par
           can have more than one unique identifier specified - it\par
           is left to the server implementation to decide if one or\par
           all identifiers must be matched or which take precedence\par
           over others.'\par
     SYNTAX OctetString\par
   )</rm>\cf0\par
\par
   NAME         dhcpClassMember\par
   DESCRIPTION  This attribute indicates that the client is a member =
of\par
                the specified class(es).\par
   SYNTAX       IA5String MULTI-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-19> NAME 'dhcpClassMember'\par
     DESC 'This attribute indicates that the client is a member of\par
           the specified class(es).'\par
     SYNTAX IA5String\par
   )</rm>\cf0\par
\par
   NAME         dhcpReservedAddress\par
   DESCRIPTION  This attribute indicates the reserved (aka fixed)\par
                address(es) for this client (if there are any).  =
There\par
                MAY be corresponding "dhcpAddress" objects created =
for\par
                tracking this reservation.\par
   SYNTAX       IA5String MULTI-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-19> NAME 'dhcpReservedAddress'\par
     DESC 'This attribute indicates the reserved (aka fixed)\par
           address(es) for this client (if there are any).  There\par
           MAY be corresponding "dhcpAddress" objects created for\par
           tracking this reservation.'\par
     SYNTAX IA5String\par
   )\par
\par
   ( <dhcp-oid-at-20> NAME 'dhcpClientName'\par
     DESC 'A descriptive name of the client. May be used as\par
\tab      the RDN.'\par
     SYNTAX IA5String SINGLE-VALUE EQUALITY caseExactIA5Match\par
   )</rm>\cf0\par
\par
5.7.  dhcpClass Object Class\par
\par
   A "dhcpClass" represents information about a collection of =
clients.\par
   The DHC protocol provides 2 mechanisms for managing this =
information\par
   (User Class and Vendor Class).  The schema also provides 2 =
additional\par
   mechanisms for configuring groups of clients that are supported =
by\par
   some servers.  Clients may be explicitly added to a class by =
setting\par
   the "dhcpClassMember" attribute in the "dhcpClient" object class.\par
   Some servers also support forms of dynamic class membership =
beyond\par
   the User Class and Vendor Class mechanisms - the =
"dhcpVendorCondi-\par
   tion" attribute allows for the definition of dynamic classes.\par
\par
   The "dhcpRuleType" attribute MUST be set to 'CLASS', and the "cn"\par
   SHOULD be set to the value of the "dhcpClassName" attribute".\par
\cf1 <rm>Again, if cn is set to the dhcpClassName attribute for this =
class,\par
then I could just as easily use dhcpClassName as the RDN, so that\par
should be allowed</rm>\cf0\par
\par
   NAME                dhcpClass\par
   DESCRIPTION         Represents information about a collection of\par
                       related clients.\par
   TYPE                Structural\par
   DERIVED FROM        dhcpRule\par
   POSSIBLE SUPERIORS  ( OrganizationalUnit dhcpRule )\par
   MUST CONTAIN        ( cn dhcpClassName dhcpClassType)\par
   MAY CONTAIN         ( )\par
\cf1 <rm>My comment in section 5.3 about possible superiors applies =
here.\cf0\par
\cf1    ( <dhcp-oid-oc-9> NAME 'dhcpClass'\par
     DESC 'Represents information about a collection of\par
           related clients.'\par
     SUP dhcpRule\par
     MUST ( cn $ dhcpClassName $ dhcpClassType )\par
   )</rm>\par
\cf0\par
5.7.1.  dhcpClass Attribute Definitions\par
\par
   NAME         dhcpClassName\par
   DESCRIPTION  A descriptive name for the class.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-21> NAME 'dhcpClassName'\par
     DESC 'A descriptive name for the class. May be used as\par
\tab      the RDN.'\par
     SYNTAX IA5String SINGLE-VALUE EQUALITY caseExactIA5Match\par
   )</rm>\cf0\par
\par
   NAME         dhcpClassType\par
   DESCRIPTION  This attribute indicates the type of the class.  It\par
                should be one of 'USERCLASS', 'VENDORCLASS', =
'STATIC'\par
                (the only members of the class are enumerated =
clients),\par
                'DYNAMIC' (membership is determined by some =
vendor-spe-\par
                cific conditions).\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-22> NAME 'dhcpClassType'\par
     DESC 'This attribute indicates the type of the class.  It\par
           should be one of 'USERCLASS', 'VENDORCLASS', 'STATIC'\par
           (the only members of the class are enumerated clients),       =
    'DYNAMIC' (membership is determined by some vendor-spe-\par
           cific conditions).'\par
     SYNTAX IA5String SINGLE-VALUE\par
   )</rm>\cf0\par
\par
6.  Other Configuration objects\par
\par
   Many server implementations provide other objects that simplify =
the\par
   configuration of the DHCP protocol.  One example is the ability =
to\par
   assign a name to a group of option settings and then to refer to =
the\par
   entire group of settings by referencing the name.  This is =
addressed\par
   by the "dhcpNamedOptionSet" object class.\par
\par
   It is also fairly common for server implementations to allow users =
to\par
   extend the default set of options with site specific option =
defini-\par
   tions.  This is addressed by the "dhcpDictionary" object class.  =
This\par
   object class is also used to define the implementation-specific\par
   parameters (and their values) that can be specified in the =
"dhcpPa-\par
   rameterSetting" attribute.\par
\par
6.1.  dhcpNamedOptionSet Object Class\par
\par
   A "dhcpNamedOptionSet" is an object class for associating a name =
with\par
   a collection of option settings.  The entire set of options can =
be\par
   associated with a DHCP object by referring to the name.  This =
allows\par
   a common set of option settings to be re-used without repeating =
the\par
   option settings on each configured object.  To see how an option =
set\par
   is referenced, see the "dhcpIncludeOptionSet" attribute.\par
\par
   NAME                dhcpNamedOptionSet\par
   DESCRIPTION         This is a named collection of settings for\par
                       options and/or server parameters.\par
   TYPE                Structural\par
   DERIVED FROM        Top\par
   POSSIBLE SUPERIORS  ( OrganizationalUnit )\par
   MUST CONTAIN        ( cn )\par
   MAY CONTAIN         ( dhcpOptionSetting dhcpParameterSetting\par
                         dhcpFieldSetting dhcpForcedOptions\par
                         dhcpIncludeOptionSet )\par
\cf1 <rm>My comment in section 5.3 about possible superiors applies =
here.\par
Further, this class should also have an attribute dhcpOptionSetName\par
that can be used as the RDN.\cf0\par
\cf1    ( <dhcp-oid-oc-10> NAME 'dhcpNamedOptionSet'\par
     DESC 'This is a named collection of settings for\par
           options and/or server parameters.'\par
     SUP dhcpService\par
     MUST ( cn $ dhcpOptionSetName )\par
   )\par
\par
   ( <dhcp-oid-at-23> NAME 'dhcpOptionSetName'\par
     DESC 'A descriptive name for the option set. May be used as\par
\tab      the RDN.'\par
     SYNTAX IA5String SINGLE-VALUE EQUALITY caseExactIA5Match\par
   )</rm>\cf0\par
\par
\cf1 <rm>6.2</rm>\cf0 6.1.1.  dhcpDictionary Object Class\par
\par
   "dhcpDictionary" objects define the options and/or parameters =
that\par
   can be set when configuring various DHCP entities.\par
\par
   NAME                dhcpDictionary\par
   DESCRIPTION         This class defines an option or parameter =
that\par
                       can have a value.\par
   TYPE                Structural\par
   DERIVED FROM        Top\par
   POSSIBLE SUPERIORS  ( OrganizationalUnit )\par
   MUST CONTAIN        ( cn dhcpTag )\par
   MAY CONTAIN         ( dhcpDisplayName dhcpDataType dhcpDefault\par
                         dhcpMultiValued dhcpLegalValues\par
                         dhcpTypeRestriction dhcpImplementation )\par
\cf1 <rm>Again, the comment from 5.3 about possible superiors =
applies.\par
This class is sufficiently different from the other classes in this\par
schema that inheriting from top makes sense.  OTOH, =
dhcpTypeRestriction\par
could be just as easily dhcpObjectClassRestriction:\par
   ( <dhcp-oid-oc-11> NAME 'dhcpDictionary'\par
     DESC 'This class defines an option or parameter that\par
           can have a value.'\par
     SUP top\par
     MUST ( cn $ dhcpTag )\par
     MAY ( dhcpDisplayName $ dhcpDataType $ dhcpDefault $\par
           dhcpMultiValued $ dhcpLegalValues $\par
           dhcpObjectClassRestriction $ dhcpImplementation )\par
   )\par
\par
6.2.1.</rm>\cf0 6.2.  dhcpDictionary Attribute Definitions\par
\par
   NAME         cn\par
   DESCRIPTION  The "common name" of the option or parameter.  This =
will\par
                usually be the same as the "dhcpTag" attribute.\par
   SYNTAX       Integer SINGLE-VALUE\par
\cf1 <rm>This should be in the sectional text of the class. Maybe =
I'm\par
missing something, but having cn match the value of the dhcpTag (a =
number)\par
doesn't make sense for a dictionary, so an example of this is named\par
and fits in the DIT would help.</rm>\cf0\par
\par
   NAME         dhcpTag\par
   DESCRIPTION  A unique value that identifies an option or =
parameter\par
                and that is encoded in the values of the =
"dhcpOptionSet-\par
                ting" and "dhcpParameterSetting" attributes.  For\par
                options this SHOULD be the numeric tag for the =
option\par
                (stored as a string).\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-24> NAME 'dhcpTag'\par
     DESC 'A unique value that identifies an option or parameter\par
           and that is encoded in the values of the "dhcpOptionSet-\par
           ting" and "dhcpParameterSetting" attributes.  For\par
           options this SHOULD be the numeric tag for the option\par
           (stored as a string).'\par
     SYNTAX IA5String SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpDisplayName\par
   DESCRIPTION  This is a string identifier for the option or =
parameter.\par
                This is intended for display by a management tool or\par
                GUI.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-25> NAME 'dhcpDisplayName'\par
     DESC 'This is a string identifier for the option or parameter.\par
           This is intended for display by a management tool or\par
           GUI.'\par
     SYNTAX IA5String SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpDataType\par
   DESCRIPTION  The data type for values of this option.  One of the\par
                following: 'INT8', 'INT16', 'INT32', 'UINT8', =
'UINT16',\par
                'UINT32' , 'ADDRESS', 'ADDRESS-MASK-PAIR', =
'BOOLEAN',\par
                'STRING', 'BINARY'.  Other values may be specified =
if\par
                the server implementation provides them.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-26> NAME 'dhcpDataType'\par
     DESC 'The data type for values of this option.  One of the\par
           following: "INT8", "INT16", "INT32", "UINT8", "UINT16",\par
           "UINT32" , "ADDRESS", "ADDRESS-MASK-PAIR", "BOOLEAN",\par
           "STRING", "BINARY".  Other values may be specified if\par
           the server implementation provides them.'\par
     SYNTAX IA5String SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpDefault\par
   DESCRIPTION  Indicates the default value of a parameter or option\par
                definition in a dictionary object.  This is  encoded =
as\par
                it would be in the "dhcpOptionSetting" or =
"dhcpParame-\par
                terSetting" attribute.\par
   SYNTAX       OctetString SINGLE-VALUE\par
\cf1 <rm>Since dhcpParameterSetting is an IA5String, the reference here =
makes\par
no sense to me.\par
   ( <dhcp-oid-at-27> NAME 'dhcpDefault'\par
     DESC 'Indicates the default value of a parameter or option\par
           definition in a dictionary object.  This is  encoded as\par
           it would be in the "dhcpOptionSetting" attribute.'\par
     SYNTAX OctetString SINGLE-VALUE\par
   )</rm>\par
\par
\cf0    NAME         dhcpMultiValued\par
   DESCRIPTION  Indicates whether the parameter or option can have =
more\par
                than one value.\par
   SYNTAX       Boolean SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-28> NAME 'dhcpMultiValued'\par
     DESC 'Indicates whether the parameter or option can have more\par
           than one value.'\par
     SYNTAX Boolean SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpLegalValues\par
   DESCRIPTION  The list of allowed values for the option or =
parameter.\par
                Each "legal value" is stored as a separate value for =
the\par
                attribute, and is encoded based on the =
"dhcpDataType"\par
                attribute setting.\par
   SYNTAX       OctetString MULTI-VALUE\par
\cf1 <rm>You need to add a section+examples on how this encoding is =
done,\par
because I don't think it is always trivial.\par
   ( <dhcp-oid-at-29> NAME 'dhcpLegalValues'\par
     DESC 'The list of allowed values for the option or parameter.\par
           Each "legal value" is stored as a separate value for the\par
           attribute, and is encoded based on the "dhcpDataType"\par
           attribute setting.'\par
     SYNTAX OctetString\par
   )</rm>\par
\par
\cf0    NAME         dhcpTypeRestriction\par
   DESCRIPTION  This attribute is used to specify that the option or\par
                parameter should only be used with specific types of\par
                assignment rules.  This is restricted to the same set =
of\par
                values as the "dhcpRuleType" attribute.  If not =
speci-\par
                fied it is assumed that the definition applies to =
all\par
                types.\par
   SYNTAX       IA5String MULTI-VALUE\par
\cf1 <rm>Because the dhcp classes are distinguishable by object class, =
this\par
can be replaced with:\par
   ( <dhcp-oid-at-30> NAME 'dhcpObjectClassRestriction'\par
     DESC 'This attribute is used to specify that the option or\par
           parameter should only be used with specific types of\par
           assignment rules.  This is restricted to the same set of\par
           values as the "dhcpRuleType" attribute.  If not present\par
\tab      in the class, it is assumed that the definition applies\par
\tab      to all types.'\par
     SYNTAX IA5String\par
   )</rm>\cf0\par
\par
   NAME         dhcpImplementation\par
   DESCRIPTION  This attribute is used to specify that the option or\par
                parameter should only be used with specific server\par
                implementations.  If not specified it is assumed =
that\par
                the definition applies to all implementations.\par
   SYNTAX       IA5String MULTI-VALUE\par
\cf1 <rm>This attribute doesn't have to be specified again<rm>\cf0\par
\par
7.  Tracking Addresses\par
\par
   The behavior of a DHCP server is influenced by two factors - it's\par
   configuration and the current state of the addresses that have =
been\par
   assigned to clients.  This schema defined a set of objects for\par
   storing the configuration of the server, and the following object\par
   class provides the ability to record how addresses are used.\par
\par
7.1.  dhcpAddress Object Class\par
\par
   This class represents an IP address.  It may or may not be =
leaseable,\par
   and the object may exist even though a lease is not currently =
active\par
   for the associated IP address.\par
\cf1 <rm>will this class work for both IPv4 and IPv6 addresses?  If =
so,\par
say that specifically.</rm>\cf0\par
\par
   Note that this object class has some of the "Settings" attributes\par
   that are defined for the "dhcpConfigurableObject", but they are =
not\par
   used for configuration - only for tracking the settings that were\par
   assigned to the client.  It is not required that the server =
implemen-\par
   tation record options that were offered to the client.\par
\par
   NAME                dhcpAddress\par
   DESCRIPTION         This class represents an IP Address, which may =
or\par
                       may not have been leased.\par
   TYPE                Structural\par
   DERIVED FROM        Top\par
   POSSIBLE SUPERIORS  ( )\par
   MUST CONTAIN        ( cn dhcpAddressState )\par
   MAY CONTAIN         ( dhcpExpirationTime dhcpStartTimeOfState\par
                         dhcpLastTransactionTime dhcpBootpFlag\par
                         dhcpDomainName dhcpDnsStatus\par
                         dhcpRequestedHostName dhcpAssignedHostName\par
                         dhcpReservedForClient dhcpAssignedToClient\par
                         dhcpRelayAgentInfo dhcpOptionSetting\par
                         dhcpParameterSetting dhcpFieldSetting )\par
\cf1 <rm>Using cn for an IP Address is overloading the semantics of cn.  =
I\par
would suggest uid as an alternate RDN for those directory =
administrators\par
not wanting to use cn:\par
   ( <dhcp-oid-oc-12> NAME 'dhcpAddress'\par
     DESC 'This class represents an IP Address, which may or\par
           may not have been leased.'\par
     SUP top\par
     MUST ( cn $ dhcpAddressState $ uid )\par
     MAY ( dhcpExpirationTime $ dhcpStartTimeOfState\par
           dhcpLastTransactionTime $ dhcpBootpFlag\par
           dhcpDomainName $ dhcpDnsStatus\par
           dhcpRequestedHostName $ dhcpAssignedHostName\par
           dhcpReservedForClient $ dhcpAssignedToClient\par
           dhcpRelayAgentInfo $ dhcpOptionSetting\par
           dhcpParameterSetting $ dhcpFieldSetting )\par
   )\par
</rm>\par
\par
\cf0 7.2.  dhcpAddress Attribute Definitions\par
\par
   NAME         cn\par
   DESCRIPTION  The IP address, as a string.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>the above text is not necessary and in fact is incorrect.  =
LDAP\par
attributes are specified globally</rm>\par
\par
\cf0    NAME         dhcpAddressState\par
   DESCRIPTION  This stores information about the current =
binding-status\par
                of an address.  For dynamic addresses managed by =
DHCP,\par
                the values should be restricted to the states defined =
in\par
                the safe-failover draft: 'FREE', 'ACTIVE', =
'EXPIRED',\par
                'RELEASED', 'RESET', 'ABANDONED', 'BACKUP'.  For =
more\par
                information on these states see [FAILOVR].  For =
other\par
                addresses, it SHOULD be one of the following: =
'UNKNOWN',\par
                'RESERVED' (an address that is managed by DHCP that =
is\par
                reserved for a specific client), 'RESERVED-ACTIVE' =
(same\par
                as reserved, but address is currently in use),\par
                'ASSIGNED' (assigned manually or by some other =
mecha-\par
                nism), 'UNASSIGNED', 'NOTASSIGNABLE'.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>\par
   ( <dhcp-oid-at-31> NAME 'dhcpAddressState'\par
     DESC 'This stores information about the current binding-status\par
           of an address.  For dynamic addresses managed by DHCP,\par
           the values should be restricted to the following: "FREE",\par
\tab      "ACTIVE", "EXPIRED", "RELEASED", "RESET", "ABANDONED",\par
\tab      "BACKUP".  For other addresses, it SHOULD be one of the\par
           following: "UNKNOWN", "RESERVED" (an address that is\par
           managed by DHCP that is reserved for a specific client),\par
           "RESERVED-ACTIVE" (same as reserved, but address is\par
           currently in use), "ASSIGNED" (assigned manually or by\par
           some other mechanism), "UNASSIGNED", "NOTASSIGNABLE".'\par
     SYNTAX IA5String SINGLE-VALUE\par
   )</rm>\cf0\par
\par
\cf1 <rm>You should add a discussion of the appropriateness of =
storing\par
this information in a directory (i.e. guidelines about what the\par
lease times should be so as to not overload the directory)</rm>\par
\par
\cf0    NAME         dhcpExpirationTime\par
   DESCRIPTION  This is the time the current lease for an address\par
                expires.\par
   SYNTAX       DateTime SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-32> NAME 'dhcpExpirartionTime'\par
     DESC 'This is the time the current lease for an address\par
           expires.'\par
     SYNTAX generalizedTime SINGLE-VALUE\par
   )</rm>\cf0\par
\par
   NAME         dhcpStartTimeOfState\par
   DESCRIPTION  This is the time of the last state change for a =
leased\par
                address.\par
   SYNTAX       DateTime SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-33> NAME 'dhcpStartTimeOfState'\par
     DESC 'This is the time of the last state change for a leased\par
           address.'\par
     SYNTAX generalizedTime SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpLastTransactionTime\par
   DESCRIPTION  This is the last time a valid DHCP packet was =
received\par
                from the client.\par
   SYNTAX       DateTime SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-34> NAME 'dhcpLastTransactionTime'\par
     DESC 'This is the last time a valid DHCP packet was received\par
           from the client.'\par
     SYNTAX generalizedTime SINGLE-VALUE\par
   )</rm>\cf0\par
\par
   NAME         dhcpBootpFlag\par
   DESCRIPTION  This indicates whether the address was assigned via\par
                BOOTP\par
   SYNTAX       Boolean SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-35> NAME 'dhcpBootpFlag'\par
     DESC 'This indicates whether the address was assigned via\par
           BOOTP.'\par
     SYNTAX Boolean SINGLE-VALUE\par
   )</rm>\cf0\par
\par
   NAME         dhcpDomainName\par
   DESCRIPTION  This is the name of the domain sent to the client by =
the\par
                server.  It is essentially the same as the value for\par
                DHCP option 15 sent to the client, and represents =
only\par
                the domain - not the full FQDN.  To obtain the full =
FQDN\par
                assigned to the client you must prepend the "dhcpAs-\par
                signedHostName" to this value with a ".".\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1 <rm>   ( <dhcp-oid-at-36> NAME 'dhcpDomainName'\par
     DESC 'This is the name of the domain sent to the client by the\par
           server.  It is essentially the same as the value for\par
           DHCP option 15 sent to the client, and represents only\par
           the domain - not the full FQDN.  To obtain the full FQDN\par
           assigned to the client you must prepend the "dhcpAs-\par
           signedHostName" to this value with a ".".'\par
     SYNTAX IA5String SINGLE-VALUE\par
   )</rm>\cf0\par
\par
   NAME         dhcpDnsStatus\par
   DESCRIPTION  This indicates the status of updating DNS resource\par
                records on behalf of the client by the DHCP server =
for\par
                this address.  The value is a 16-bit bitmask that =
has\par
                the same values as specified by the Failover-DDNS =
option\par
                (see [FAILOVR]).\par
   SYNTAX       Integer SINGLE-VALUE\par
\cf1 <rm>The reference to [FAILOVR] should go in surrounding text.  In =
a\par
directory schema, it won't mean much.  Further, you should note that\par
LDAP only stores unsigned Integers...:\par
   ( <dhcp-oid-at-37> NAME 'dhcpDnsStatus'\par
     DESC 'This indicates the status of updating DNS resource\par
           records on behalf of the client by the DHCP server for\par
           this address.  The value is a 16-bit bitmask.'\par
     SYNTAX Integer SINGLE-VALUE\par
   )</rm>\cf0\par
\par
   NAME         dhcpRequestedHostName\par
   DESCRIPTION  \cf2 This is the hostname that was requested by the =
client.\cf0\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1  <rm>  ( <dhcp-oid-at-38> NAME 'dhcpRequestedHostName'\par
     DESC 'This is the hostname that was requested by the client.'\par
     SYNTAX IA5String SINGLE-VALUE\par
   )</rm>\cf0\par
\par
   NAME         dhcpAssignedHostName\par
   DESCRIPTION  This is the actual hostname that was assigned toa\par
                client. It may not be the name that was requested by =
the\par
                client.  The fully qualified domain name can be =
deter-\par
                mined by appending the value of "dhcpDomainName" (with =
a\par
                dot separator) to this name.\par
   SYNTAX       IA5String SINGLE-VALUE\par
\cf1  <rm>  ( <dhcp-oid-at-39> NAME 'dhcpAssignedHostName'\par
     DESC 'This is the actual hostname that was assigned toa\par
           client. It may not be the name that was requested by the\par
           client.  The fully qualified domain name can be deter-\par
           mined by appending the value of "dhcpDomainName" (with a\par
           dot separator) to this name.'\par
     SYNTAX IA5String SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpReservedForClient\par
   DESCRIPTION  The distinguished name of a "dhcpClient" that an =
address\par
                is reserved for.  This may not be the same as the =
"dhc-\par
                pAssignedToClient" attribute if the address is being\par
                reassigned but the current lease has not yet =
expired.\par
   SYNTAX       DN SINGLE-VALUE\par
\cf1  <rm>  ( <dhcp-oid-at-40> NAME 'dhcpReservedForClient'\par
     DESC 'The distinguished name of a "dhcpClient" that an address\par
           is reserved for.  This may not be the same as the\par
           "dhcpAssignedToClient" attribute if the address is being\par
           reassigned but the current lease has not yet expired.'\par
     SYNTAX DN SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpAssignedToClient\par
   DESCRIPTION  This is the distinguished name of a "dhcpClient" that =
an\par
                address is currently assigned to.  This only has a =
value\par
                when the address is leased.\par
   SYNTAX       DN SINGLE-VALUE\par
\cf1 <rm>  ( <dhcp-oid-at-41> NAME 'dhcpAssignedToClient'\par
     DESC 'This is the distinguished name of a "dhcpClient" that an\par
           address is currently assigned to.  This attribute is\par
           only present in the class when the address is leased.'\par
     SYNTAX DN SINGLE-VALUE\par
   )</rm>\par
\cf0\par
   NAME         dhcpRelayAgentInfo\par
   DESCRIPTION  If the client request was received via a relay =
agent,\par
                this contains information about the relay agent that =
was\par
                available from the DHCP request.  This is a =
hex-encoded\par
                option value.  For more information see [AGENT].\par
   SYNTAX       OctetString SINGLE-VALUE\par
\cf1 <rm>  ( <dhcp-oid-at-42> NAME 'dhcpAssignedToClient'\par
     DESC 'If the client request was received via a relay agent,\par
           this contains information about the relay agent that was\par
           available from the DHCP request.  This is a hex-encoded\par
           option value.'\par
     SYNTAX OctetString SINGLE-VALUE\par
   )</rm>\par
\cf0\par
8.  Object Containment\par
\par
   These diagrams depict the containment hierarchy of the objects.\par
   <Administrative-Container> can be any LDAP object.\par
\cf1 <rm>First, you should say that this is a suggested (MAY) =
containment\par
hierarchy. Whether a directory administrator will want to use\par
organizationalUnits or something else for structuring the directory\par
is oft driven by business needs and should not be standardized.  =
Also,\par
some additional branches to show the multiplicity of object =
instances\par
under each branch would be a good thing (exactly how do multiple =
copies\par
of dhcpDictionary play together?).  Finally, state that dhcpRule\par
actually refers to subclasses of that class.  A perfectly good\par
alternate tree whould be (in slightly compressed format).\par
\par
<A-C>-+-dhcpService\par
      +-dhcpConfig-+-dhcpDictionary\par
                   +-dhcpNamedOptionSet\par
                   +-children of dhcpRule-children of...\par
                   +-dhcpAddresses\par
</rm>\cf0\par
\par
   <Administrative-Container>\par
      |\par
      +---dhcpConfiguration\par
          |\par
          +--- ou =3D OptionDictionary\par
          |  |\par
          |  +---dhcpDictionary\par
          |\par
          +--- ou =3D ParameterDictionary\par
          |  |\par
          |  +---dhcpDictionary\par
          |\par
          +--- ou =3D NamedOptionSets\par
          |  |\par
          |  +---dhcpNamedOptionSet\par
          |\par
          +--- ou =3D Rules\par
          |  |\par
          |  +---dhcpRule\par
          |      |\par
          |      +---dhcpRule . . .\par
          |\par
          +--- ou =3D Addresses\par
             |\par
             +---dhcpAddress\par
\par
\par
   <Administrative-Container>\par
      |\par
      +---dhcpService\par
\par
\par
9.  Object Class Inheritance\par
\par
   The following diagram shows the inheritance hierarchy of the =
classes:\par
\par
\cf1 <rm>based on the suggested classes above, this becomes (the <cim =
tree>\par
is available from the "LDAP Mapping of the CIM 2.3 Core Schema"\par
available from http://www.dmtf.org/spec/denh.html)\par
\par
\cf0       Top\par
      |\par
      +---dhcpDictionary\par
      |\par
      +-\cf1 <cim tree>-cim23Service---\cf0 dhcpService\cf1 =
-+-dhcpConfigurableObject\par
      |                                       =
+-dhcpNamedOptionSet\cf0\par
      |\par
      +-\cf1 <cim tree>-cim23Configuration---\cf0 dhcpConfiguration\par
      |\par
      +---dhcpAddress\par
      |\par
      +-\cf1 <policy tree>-policyRule-\cf0 --dhcpRule\par
                                   |\par
                                   +---dhcpClass\par
                                   |\par
                                   +---dhcpClient\par
                                   |\par
                                   +---dhcpPool\par
                                   |\par
                                   +---dhcpSharedNetwork\par
                                   |\par
                                   +---dhcpSubnet\par
\cf1 </rm>\cf0\par
\par
10.  Determining Assignment Rule settings\par
\par
   This section of the document defines the algorithm that should be\par
   used for determining the settings for options and/or parameters =
for\par
   an assignment rule.  Most DHCP server implementations provide for\par
   some degree of inheritance of options between configuration =
objects.\par
   This algorithm is flexible enough to allow server implementations =
to\par
   represent their existing behavior.\par
\par
   The option settings directly associated with a "dhcpRule" object =
MUST\par
   take precedence over all other option settings.  The rule also =
inher-\par
   its options from the following objects (in order of precedence):\par
   - options from one or more included "dhcpNamedOptionSet" objects, =
as\par
     defined in the "dhcpIncludeOptionSet" attribute.  If there is =
more\par
     than one option set, the attribute values define the order in =
which\par
     the option sets should be included.\par
   - options from the "dhcpSourceObject" for the rule.\par
   - options from "dhcpNamedOptionSet" objects associated with the\par
     "dhcpSourceObject" for the rule.\par
   - options from the "parent" rule (only if the object's parent in =
the\par
     directory is also a "dhcpRule" object.\par
   - options from "dhcpNamedOptionSet" objects associated with the =
"par-\par
     ent" rule.\par
   - options from walking up the directory hierarchy inheriting from\par
     ancestor rules until the "dhcpConfiguration" object is reached.\par
\par
\cf1 <rm>I read this several times and I still can't seem to get my =
head\par
around it.  I think a specific example would help, because it would\par
clarify the optimizations necessary for the schema</rm>\cf0\par
\par
11.  References\par
   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC =
2131,\par
             March 1997.\par
   [RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP =
Vendor\par
             Extensions", RFC 2132, March 1997.\par
   [DMTF]    Distributed Management Task Force, "Common Information\par
             Model (CIM) Specification", Version 2.0, Mar 1998.\par
   [DEN]     Strassner, J., "Directory-Enabled Networks, Information\par
             Model and Base Schema", DEN Specification v3.0c, July =
1998.\par
\cf1 <rm>There are specific DEN LDAP mappings that should be =
referenced</rm>\cf0\par
   [MSDHCP]  Gu, Y., Vyaghrapuri, R., "An LDAP Schema for Dynamic =
Host\par
             Configuration Protocol Service", Internet Draft\par
             <draft-gu-dhcp-ldap-schema-00.txt>, August 1998.\par
   [NOVDHCP] Miller, T., Patel, A., Rao, P., "Lightweight Directory\par
             Access Protocol (v3): Schema for Dynamic Host =
Configuration\par
             Protocol (DHCP)", Internet Draft\par
             <draft-miller-dhcp-ldap-schema-00.txt>, June 1998.\par
   [FAILOVR] Droms, R., Rabil, G., Dooley, M., Kapur, A., Gonczi, =
S.,\par
             Volz, B., "DHCP Failover Protocol", Internet Draft\par
             <draft-ietf-dhc-failover-05.txt>, October 1999.\par
   [AGENT]   Patrick, M., "DHCP Relay Agent Information Option", =
Inter-\par
             net Draft <draft-ietf-dhc-agent-options-09.txt>, March\par
             2000.\par
   [DHCPOPT] Carney, M., "New Option Review Guidelines and =
Additional\par
             Option Namespace", Internet Draft\par
             <draft-ietf-dhc-option_review_and_namespace-01.txt>, =
Octo-\par
             ber 1999.\par
   [POLICY]  Strassner, J., Elleson, E., Moore, B., "Policy =
Framework\par
             LDAP Core Schema", Internet Draft\par
             <draft-ietf-policy-core-schema-06.txt>, November 1999.\par
\cf1 <rm>[POLICY\} reference needs to be updated</rm>\par
\cf0    [RFC2251] Wahl, M., Howes, T., Kille, S., "Lightweight =
Directory\par
             Access Protocol (v3)", RFC 2251, December 1997.\par
   [RFC2252] Wahl, M., Coulbeck, A., Howes, T., Kille, S., =
"Lightweight\par
             Directory Access Protocol (v3) Attribute Syntax Defini-\par
             tions", RFC 2252, December 1997.\par
   [RFC2255] Howes, T., Smith, M., "The LDAP URL Format", RFC 2255,\par
             December 1997.\par
   [RFC951]  Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", =
RFC\par
             951, September 1985.\par
   [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate =
Require-\par
             ment Levels", RFC 2119, March 1997.\par
\par
12.  Acknowledgements\par
\par
      This document is closely aligned with the work being done in =
the\par
      Distributed Management Task Force (DMTF) Networks working =
group.\par
      Design ideas included in this document are primarily based on =
dis-\par
      cussions during two meetings with some members of the IETF DHC\par
      Working Group and the DMTF Networks working group.  The =
contribu-\par
      tions of these individuals is gratefully acknowledged.\par
\par
      Special thanks to Andrea Westerinen, Lee Rafalow, Steve =
Gonczi,\par
      Steve Chirokas, Kim Kinnear, Ellen Stokes, Tom Miller, Ye Gu,\par
      Glenn Waters, Mike Carney, Ralph Droms, Greg Rabil, Ted Lemon =
and\par
      Steve Bazyl for their contributions.\par
\par
      Thanks also to Ester Burwell, Andy Sudduth, Fred Hunter, Paul =
Rai-\par
      son, Josh Littlefield, Peter Heitman, Neil Russell and Linda =
Scobo\par
      for their participation in these meetings.\par
\par
13.  Author information\par
\par
      Andy Bennett\par
      Bernie Volz\par
      Process Software Corporation\par
      959 Concord St.\par
      Framingham, MA 01701\par
      Phone: (508) 879-6994\par
      Email: bennett@process.com\par
      Email: volz@process.com\par
\par
14.  Full Copyright Statement\par
\par
      Copyright (C) The Internet Society (1999). All Rights =
Reserved.\par
\par
      This document and translations of it may be copied and =
furnished\par
      to others, and derivative works that comment on or otherwise\par
      explain it or assist in its implementation may be prepared,\par
      copied, published and distributed, in whole or in part, =
without\par
      restriction of any kind, provided that the above copyright =
notice\par
      and this paragraph are included on all such copies and =
derivative\par
      works.  However, this document itself may not be modified in =
any\par
      way, such as by removing the copyright notice or references to =
the\par
      Internet Society or other Internet organizations, except as =
needed\par
      for the  purpose of developing Internet standards in which =
case\par
      the procedures for copyrights defined in the Internet =
Standards\par
      process must be followed, or as required to translate it into =
lan-\par
      guages other than English.\par
\par
      The limited permissions granted above are perpetual and will =
not\par
      be revoked by the Internet Society or its successors or =
assigns.\par
\par
      This document and the information contained herein is provided =
on\par
      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET\par
      ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR\par
      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE =
OF\par
      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY =
IMPLIED\par
      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR =
PURPOSE.\par
\par
}
=00
------=_NextPart_000_0006_01BFE761.20931FA0--



From owner-dhcp-v4@bucknell.edu  Thu Jul  6 17:14:39 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25708
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 6 Jul 2000 17:14:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e66LDvW11791;
	Thu, 6 Jul 2000 17:13:57 -0400 (EDT)
Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e66LDoW14232;
	Thu, 6 Jul 2000 17:13:50 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-140.cisco.com [161.44.133.140])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA10093;
	Thu, 6 Jul 2000 17:13:49 -0400 (EDT)
Message-Id: <4.3.1.2.20000706171247.00b693d0@funnel.cisco.com>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 06 Jul 2000 17:16:10 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Upcoming WG meeting in Pittsburgh
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: droms@bucknell.edu
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Remember that the cutoff for acceptance of I-Ds to be published before the 
Pittsburgh IETF is next Friday, 7/14...

As is our custom, I have scheduled two DHC WG sessions - one for DHCPv4 
issues and one for DHCPv6 issues.  If you have an agenda item for either 
meeting, please forward it to me so I can put together schedules for the 
two meetings.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Jul  6 17:19:09 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25780
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 6 Jul 2000 17:19:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e66LIaW13952;
	Thu, 6 Jul 2000 17:18:37 -0400 (EDT)
Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e66LISW19737
	for <dhcp-v6@bucknell.edu>; Thu, 6 Jul 2000 17:18:28 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-140.cisco.com [161.44.133.140])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA10097
	for <dhcp-v6@bucknell.edu>; Thu, 6 Jul 2000 17:18:28 -0400 (EDT)
Message-Id: <4.3.1.2.20000706172033.00b929a0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 06 Jul 2000 17:20:42 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Upcoming WG meeting in Pittsburgh
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Remember that the cutoff for acceptance of I-Ds to be published before the 
Pittsburgh IETF is next Friday, 7/14...

As is our custom, I have scheduled two DHC WG sessions - one for DHCPv4 
issues and one for DHCPv6 issues.  If you have an agenda item for either 
meeting, please forward it to me so I can put together schedules for the 
two meetings.

- Ralph



From owner-dhcp-v4@bucknell.edu  Thu Jul  6 18:07:32 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26588
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 6 Jul 2000 18:07:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e66M4LW08728;
	Thu, 6 Jul 2000 18:04:21 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e66M4GW08586
	for <dhcp-v4@bucknell.edu>; Thu, 6 Jul 2000 18:04:16 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <3G7H067Y>; Thu, 6 Jul 2000 18:04:01 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBED6@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu, dhcp-schema@lists.process.com
Subject: RE: Comments on -schema-02
Date: Thu, 6 Jul 2000 18:03:50 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ryan:

Thanks much for your in depth review and comments!!! We've wanted some
feedback on this effort.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Ryan Moats [mailto:rmoats@coreon.net]
Sent: Thursday, July 06, 2000 4:45 PM
To: bennett@process.com; volz@process.com
Cc: dhcp-v4@bucknell.edu; dhcp-schema@lists.process.com
Subject: Comments on -schema-02


Having sat down this week and read through 
the LDAP schema draft thoroughly, I have a
lot of comments.  My apologies for sending
them as a RTF attachment, but I didn't want
to pollute those folks who don't like HTML
and there were enough comments/questions/
changes that I thought some callout was 
necessary.  On the plus side, the
attachment contains ABNF that is conforms
to RFC 2252.

My apologies if these topics have been
discussed previously.  I didn't see them
in the mailing list archives and couldn't
find any archives for the sublist.  If they've
already been hashed out, that's great, but
some of the decision process should be captured
in the draft.

Looking forward to discussing points, as
needed.

Ryan Moats
Coreon, Inc.
rmoats@coreon.net



From owner-dhcp-v4@bucknell.edu  Fri Jul  7 06:55:34 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19991
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 7 Jul 2000 06:55:34 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e67Aq5W21596;
	Fri, 7 Jul 2000 06:52:05 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e67ApqW30544
	for <dhcp-v4@bucknell.edu>; Fri, 7 Jul 2000 06:51:52 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19929;
	Fri, 7 Jul 2000 06:51:50 -0400 (EDT)
Message-Id: <200007071051.GAA19929@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-authentication-14.txt
Date: Fri, 07 Jul 2000 06:51:50 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Authentication for DHCP Messages
	Author(s)	: R. Droms, W. Arbaugh
	Filename	: draft-ietf-dhc-authentication-14.txt
	Pages		: 16
	Date		: 06-Jul-00
	
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network.
In some situations, network administrators may wish to constrain the
allocation of addresses to authorized hosts.  Additionally, some
network administrators may wish to provide for authentication of the
source and contents of DHCP messages.  This document defines a new
DHCP option through which authorization tickets can be easily
generated and newly attached hosts with proper authorization can be
automatically configured from an authenticated DHCP server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-14.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-authentication-14.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-authentication-14.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000706151833.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-authentication-14.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-authentication-14.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000706151833.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Mon Jul 10 06:34:28 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02382
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 10 Jul 2000 06:34:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6AAU6W08073;
	Mon, 10 Jul 2000 06:30:06 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6AATqW07283
	for <dhcp-v4@bucknell.edu>; Mon, 10 Jul 2000 06:29:52 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01613;
	Mon, 10 Jul 2000 06:29:51 -0400 (EDT)
Message-Id: <200007101029.GAA01613@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-userclass-08.txt
Date: Mon, 10 Jul 2000 06:29:50 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: The User Class Option for DHCP
	Author(s)	: G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, 
                          A. Demirtjis, B. Beser, J. Privat
	Filename	: draft-ietf-dhc-userclass-08.txt
	Pages		: 5
	Date		: 07-Jul-00
	
This option is used by a DHCP client to optionally identify the type
or category of user or applications it represents.
The information contained in this option is an opaque field that
represents the user class of which the client is a member.
Based on this class, a DHCP server selects the appropriate address
pool to assign an address to the client and the appropriate
configuration parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-userclass-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-userclass-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000707143038.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-userclass-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-userclass-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000707143038.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Mon Jul 10 16:32:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27398
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 10 Jul 2000 16:32:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6AKTNW18548;
	Mon, 10 Jul 2000 16:29:23 -0400 (EDT)
Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6AKTBW29124
	for <dhcp-v4@bucknell.edu>; Mon, 10 Jul 2000 16:29:11 -0400 (EDT)
Received: from log3.in.utoronto.ca ([128.100.100.195] EHLO log3.in.utoronto.ca ident: NO-IDENT-SERVICE [port 36240]) by bureau6.utcc.utoronto.ca with ESMTP id <464155-26720>; Mon, 10 Jul 2000 16:29:03 -0400
Date: Mon, 10 Jul 2000 16:29:00 -0400 (EDT)
From: jordan.melzer@utoronto.ca
X-Sender: 04092187@log3.in.utoronto.ca
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: DHCP and IPSec
Message-ID: <Pine.GSO.4.10.10007101608260.18537-100000@log3.in.utoronto.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: jordan.melzer@utoronto.ca
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Hello,

I am probably not the first to ask this, but are there any provisions for
IPSec to provide authentication during host configuration or for the
authentication proposed for DHCP to work as part of the IP Security
Architecture?

Thank you,
Jordan



From owner-dhcp-v4@bucknell.edu  Mon Jul 10 17:30:47 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29192
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 10 Jul 2000 17:30:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6ALS7W17701;
	Mon, 10 Jul 2000 17:28:07 -0400 (EDT)
Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6ALS0W15358
	for <dhcp-v4@bucknell.edu>; Mon, 10 Jul 2000 17:28:00 -0400 (EDT)
Received: from localhost (waa@localhost)
	by codex.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id e6ALRtt20016;
	Mon, 10 Jul 2000 17:27:55 -0400 (EDT)
Date: Mon, 10 Jul 2000 17:27:55 -0400 (EDT)
From: "William A. Arbaugh" <waa@dsl.cis.upenn.edu>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP and IPSec
In-Reply-To: <Pine.GSO.4.10.10007101608260.18537-100000@log3.in.utoronto.ca>
Message-ID: <Pine.SOL.4.21.0007101726110.15846-100000@codex.cis.upenn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: waa@dsl.cis.upenn.edu
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> 
> I am probably not the first to ask this, but are there any provisions for
> IPSec to provide authentication during host configuration or for the
> authentication proposed for DHCP to work as part of the IP Security
> Architecture?
> 
The current proposal can work as part of the IP Security Architecture. A
client would first obtain a lease through use of the DHCP authentication
framework.  Once the lease is obtained, the client can negotiate a IPSec
SA in the usual way.

Bill



From owner-dhcp-v4@bucknell.edu  Mon Jul 10 18:09:27 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29890
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 10 Jul 2000 18:09:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6AM6jW06092;
	Mon, 10 Jul 2000 18:06:45 -0400 (EDT)
Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6AM6aW30317
	for <dhcp-v4@bucknell.edu>; Mon, 10 Jul 2000 18:06:36 -0400 (EDT)
Received: from log3.in.utoronto.ca ([128.100.100.195] EHLO log3.in.utoronto.ca ident: NO-IDENT-SERVICE [port 39791]) by bureau6.utcc.utoronto.ca with ESMTP id <464221-1098>; Mon, 10 Jul 2000 18:06:29 -0400
Date: Mon, 10 Jul 2000 18:06:19 -0400 (EDT)
From: jordan.melzer@utoronto.ca
X-Sender: 04092187@log3.in.utoronto.ca
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP and IPSec
In-Reply-To: <Pine.SOL.4.21.0007101726110.15846-100000@codex.cis.upenn.edu>
Message-ID: <Pine.GSO.4.10.10007101751160.3918-100000@log3.in.utoronto.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: jordan.melzer@utoronto.ca
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


I suppose.  It doesn't really work with it, though.  I can't take
advantage of ISAKMP to re-key me.  Is there a way that DHCP can be more
integrated?  Is there a reason why it shouldn't be?  The proposed DHCP
authentication method only allows me to authenticate DHCP messages.  I
think it would make sense to make DHCP part of the larger authentication
and encryption framework.  

The security side of networking is fairly new to me, so what I'm saying
could well be ridiculous and I would be happy if someone would point it
out to me.

Thanks,
Jordan

On Mon, 10 Jul 2000, William A. Arbaugh wrote:

> > 
> > I am probably not the first to ask this, but are there any provisions for
> > IPSec to provide authentication during host configuration or for the
> > authentication proposed for DHCP to work as part of the IP Security
> > Architecture?
> > 
> The current proposal can work as part of the IP Security Architecture. A
> client would first obtain a lease through use of the DHCP authentication
> framework.  Once the lease is obtained, the client can negotiate a IPSec
> SA in the usual way.
> 
> Bill
> 
> 



From owner-dhcp-v4@bucknell.edu  Tue Jul 11 04:22:44 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22184
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 11 Jul 2000 04:22:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6B8JWW16183;
	Tue, 11 Jul 2000 04:19:32 -0400 (EDT)
Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6B8JGW19446
	for <dhcp-v4@bucknell.edu>; Tue, 11 Jul 2000 04:19:16 -0400 (EDT)
Received: from internaut.com (uucp@localhost)
	by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id BAA06705;
	Tue, 11 Jul 2000 01:19:10 -0700 (PDT)
Received: by internaut.com (NX5.67e/NeXT-3.0)
	id AA01566; Mon, 10 Jul 00 23:23:32 -0800
Date: Mon, 10 Jul 2000 23:23:30 -0800 (GMT-0800)
From: "Bernard D. Aboba" <aboba@internaut.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP and IPSec
In-Reply-To: <Pine.GSO.4.10.10007101608260.18537-100000@log3.in.utoronto.ca>
Message-Id: <Pine.NXT.3.90.1000710232320.1551B-100000@internaut.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: aboba@internaut.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

See draft-ietf-ipsec-dhcp-0x.txt

On Mon, 10 Jul 2000 jordan.melzer@utoronto.ca wrote:

> 
> Hello,
> 
> I am probably not the first to ask this, but are there any provisions for
> IPSec to provide authentication during host configuration or for the
> authentication proposed for DHCP to work as part of the IP Security
> Architecture?
> 
> Thank you,
> Jordan
> 
> 



From owner-dhcp-v4@bucknell.edu  Tue Jul 11 06:35:18 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24031
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 11 Jul 2000 06:35:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6BAVDW15956;
	Tue, 11 Jul 2000 06:31:13 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6BAV0W30888
	for <dhcp-v4@bucknell.edu>; Tue, 11 Jul 2000 06:31:00 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23429;
	Tue, 11 Jul 2000 06:30:59 -0400 (EDT)
Message-Id: <200007111030.GAA23429@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
CC: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-smedvinsky-dhc-kerbauth-01.txt
Date: Tue, 11 Jul 2000 06:30:59 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Kerberos V Authentication Mode for Uninitialized     
                          Clients
	Author(s)	: S. Medvinsky, P. Lalwaney
	Filename	: draft-smedvinsky-dhc-kerbauth-01.txt
	Pages		: 16
	Date		: 10-Jul-00
	
The Dynamic Host Configuration Protocol (DHCP) [1] includes an
option that allows authentication of all DHCP messages, as specified
in [2].  This document specifies a DHCP authentication mode based on
Kerberos V tickets. This provides mutual authentication between a
DHCP client and server, as well as authentication of all DHCP
messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-smedvinsky-dhc-kerbauth-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-smedvinsky-dhc-kerbauth-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-smedvinsky-dhc-kerbauth-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000710151338.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-smedvinsky-dhc-kerbauth-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-smedvinsky-dhc-kerbauth-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000710151338.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Tue Jul 11 09:12:46 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29241
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 11 Jul 2000 09:12:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6BD9FW11155;
	Tue, 11 Jul 2000 09:09:15 -0400 (EDT)
Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6BD9EW10364
	for <dhcp-v4@bucknell.edu>; Tue, 11 Jul 2000 09:09:14 -0400 (EDT)
Received: from log3.in.utoronto.ca ([128.100.100.195] EHLO log3.in.utoronto.ca ident: NO-IDENT-SERVICE [port 51165]) by bureau6.utcc.utoronto.ca with ESMTP id <464279-2847>; Tue, 11 Jul 2000 09:08:59 -0400
Date: Tue, 11 Jul 2000 09:08:44 -0400 (EDT)
From: jordan.melzer@utoronto.ca
X-Sender: 04092187@log3.in.utoronto.ca
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP and IPSec
In-Reply-To: <Pine.NXT.3.90.1000710232320.1551B-100000@internaut.com>
Message-ID: <Pine.GSO.4.10.10007110827180.16761-100000@log3.in.utoronto.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: jordan.melzer@utoronto.ca
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


That draft discusses VPN operation.  If I understand correctly, the
operation is roughly as follows:

1) The remote host acquires an IP address which the VPN gateway
understands.  The draft is not concerned with this step.

2) The remote host creates a security association with the VPN gateway and
then creates an IPSec tunnel to it for DHCP.

3) The remote host acquires a second IP address using DHCP . . .

This not the scenario that the DHCP authentication mechanism addresses.
DHCP auth is intended to provide identity guarantees when IP addresses are
being assigned.  If the VPN gateway uses DHCP to configure the remote host
in (1) it is still open to attacks on its address pool which DHCP auth
would address.  But now it has to conform to a second security
architecture because DHCP authentication does its own thing.

I realize that the VPN gateway is unlikely to be the one giving out the IP
address to the remote client in normal VPN operation, but someone will
have to give out the IP address, and they may want guarantees about who
they're giving the address out to.  They may also want guarantees about
who is using the address.  IPSec can be used to provide this second
guarantee.

Is there a way to make the two of them work together?  Is there a reason
not to do so?

Thanks,
Jordan

On Mon, 10 Jul 2000, Bernard D. Aboba wrote:

> See draft-ietf-ipsec-dhcp-0x.txt
> 
> On Mon, 10 Jul 2000 jordan.melzer@utoronto.ca wrote:
> 
> > 
> > Hello,
> > 
> > I am probably not the first to ask this, but are there any provisions for
> > IPSec to provide authentication during host configuration or for the
> > authentication proposed for DHCP to work as part of the IP Security
> > Architecture?
> > 
> > Thank you,
> > Jordan
> > 
> > 
> 



From owner-dhcp-v4@bucknell.edu  Tue Jul 11 13:46:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11612
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 11 Jul 2000 13:46:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6BHfBW08871;
	Tue, 11 Jul 2000 13:41:11 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6BHc2W19518
	for <dhcp-v4@bucknell.edu>; Tue, 11 Jul 2000 13:38:06 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-227.ip.theriver.com [206.97.58.227]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA21220; Mon, 10 Jul 2000 18:57:50 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id KAA00664; Tue, 11 Jul 2000 10:38:35 -0700 (MST)
Message-Id: <200007111738.KAA00664@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP and IPSec 
In-Reply-To: Message from jordan.melzer@utoronto.ca 
   of "Tue, 11 Jul 2000 09:08:44 -0400." <Pine.GSO.4.10.10007110827180.16761-100000@log3.in.utoronto.ca> 
Date: Tue, 11 Jul 2000 10:38:34 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


The trick is to establish a security association without a network
connection.  :'} So it either has to be prearranged, or you have to
add a packet exchange to the DHCP protocol and probably use bigger
packets.  We have talked about this, but nobody's put a serious
proposal on the table other than the "get an address and then get a
security association" model.  Also, people have expressed resistance
to using DHCP as part of a network sign-on, for reasons I won't
attempt to explain because I don't quite accept that this is a bad
idea.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Wed Jul 12 06:58:21 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15781
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 12 Jul 2000 06:58:21 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6CAsZW13221;
	Wed, 12 Jul 2000 06:54:35 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6CAsPW13639
	for <dhcp-v4@bucknell.edu>; Wed, 12 Jul 2000 06:54:25 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1])
	by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA01206;
	Wed, 12 Jul 2000 06:53:19 -0400
Message-Id: <200007121053.GAA01206@hygro.adsl.duke.edu>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP and IPSec 
In-Reply-To: Message from jordan.melzer@utoronto.ca 
   of "Tue, 11 Jul 2000 09:08:44 EDT." <Pine.GSO.4.10.10007110827180.16761-100000@log3.in.utoronto.ca> 
Date: Wed, 12 Jul 2000 06:53:19 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

jordan.melzer@utoronto.ca writes:

> Is there a way to make the two of them work together?  Is there a reason
> not to do so?

Ted has already pointed out that it's hard to use IPsec if one doesn't
already have an address. Another fundamental one is that relay agents
modify DHCP packets. IPsec, not surprisingly, notices this and barfs.

I have a hard time coming to any conclusion other than that DHCP needs
a tailor-made authentication solution because of its unique situation
stemming from the fact that the IP stack is not fully configured at
the time DHCP is typically invoked.

Thomas



From owner-dhcp-v4@bucknell.edu  Wed Jul 12 14:58:18 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08927
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 12 Jul 2000 14:58:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6CIsCW13574;
	Wed, 12 Jul 2000 14:54:12 -0400 (EDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6CIs6W04842;
	Wed, 12 Jul 2000 14:54:06 -0400 (EDT)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA20052;
	Wed, 12 Jul 2000 14:53:41 -0400
Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA19066;
	Wed, 12 Jul 2000 14:53:44 -0400
Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA08837; Wed, 12 Jul 2000 14:52:31 -0400
Message-Id: <200007121852.OAA08837@ludwigia.raleigh.ibm.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: dhcp-v4@bucknell.edu, "Ralph E. Droms" <droms@bucknell.edu>
Subject: draft-ietf-dhc-userclass-08.txt
Date: Wed, 12 Jul 2000 14:52:30 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Folks:

The IESG has been discussing this document and some of the wording  in
it has attracted some attention. Specifically:

> 1. Introduction
 
> It is often desirable to provide different levels of service to
> different users of an IP network.  In order for an IP network to
> implement this service differentiation, it needs a way to classify
> users. A simple solution to this is to use source IP addresses for
> classification.  Under this scheme, network administrators first
> configure network devices such as routers to recognize traffic from
> a particular source IP address (or address range) and handle it
> specially to meet the desired level of service. Next, they assign
> the IP addresses to the hosts of the intended users so that the user
> will receive the appropriate level of service.

The issue is that this isn't done today, and is not where QOS (ala
diffserv) is heading. RSVP also has a different model. Finally, it has
been stated that the above is not a reflection of real deployments
today. So, the motivational introductory text is problematic and
possibly out of touch with reality.

Then, the security considerations section points out that without
authentication, doing the above is dubious anyway (which leads the
IESG to wonder what this option is really good for). So again, using
this as an example is far from ideal.

My guess (which may be wrong) is that this is not actually what the
primary usage of this option is intended for. I thought it was more
for configuring all the folks in the accounting department to use a
different printer than the folks in marketing.

I see two ways out:

1) Make it clear what the real relationship between this DHCP option
   and related QOS mechanisms. Note that even making this clear will
   probably still not leave the IESG happy, given the reasons cited
   above. So if this is the approach the WG wants to take, we should
   discuss first.

2) take the example out and use a more appropriate one.

Comments?

Thomas



From owner-dhcp-v4@bucknell.edu  Wed Jul 12 15:23:37 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10128
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 12 Jul 2000 15:23:37 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6CJMvW22941;
	Wed, 12 Jul 2000 15:22:57 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6CJMgW20844;
	Wed, 12 Jul 2000 15:22:42 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <3RCW92QV>; Wed, 12 Jul 2000 15:22:27 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBF1E@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: "Ralph E. Droms" <droms@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt
Date: Wed, 12 Jul 2000 15:22:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Thomas, et al:

>The issue is that this isn't done today, and is not where QOS (ala
diffserv) is heading.

I wonder what world the IESG lives in? While I would question whether this
option would be used to do this, this is exactly what several companies
we've been dealing with want to do. But again, this may be a useless debate
since using this option is not how they intend to do this.


Since this option is supposed to be configured by the "user", I agree that
it is much more useful for setting other options, such as the default
printer, etc. I think this makes for a perfectly good example and is useful.

It might also be used to indicate the type of system. For example, a
"laptop" is more likely to be mobile and therefore giving it a shorter lease
has value (desktop systems can have longer leases).

I am a bit surprised that the IESG didn't find the option name bad. DHCP is
for giving client systems addresses, not users. While in today's world it is
pretty common for the same user to use the same system day in and day out,
that is by no means certain. But, what's in a name after all?


In summary, I'd suggest your second approach.

- Bernie Volz
  IPWorks, Inc.


-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com]
Sent: Wednesday, July 12, 2000 2:53 PM
To: DHCPv4 discussion list
Cc: dhcp-v4@bucknell.edu; Ralph E. Droms
Subject: draft-ietf-dhc-userclass-08.txt


Folks:

The IESG has been discussing this document and some of the wording  in
it has attracted some attention. Specifically:

> 1. Introduction
 
> It is often desirable to provide different levels of service to
> different users of an IP network.  In order for an IP network to
> implement this service differentiation, it needs a way to classify
> users. A simple solution to this is to use source IP addresses for
> classification.  Under this scheme, network administrators first
> configure network devices such as routers to recognize traffic from
> a particular source IP address (or address range) and handle it
> specially to meet the desired level of service. Next, they assign
> the IP addresses to the hosts of the intended users so that the user
> will receive the appropriate level of service.

The issue is that this isn't done today, and is not where QOS (ala
diffserv) is heading. RSVP also has a different model. Finally, it has
been stated that the above is not a reflection of real deployments
today. So, the motivational introductory text is problematic and
possibly out of touch with reality.

Then, the security considerations section points out that without
authentication, doing the above is dubious anyway (which leads the
IESG to wonder what this option is really good for). So again, using
this as an example is far from ideal.

My guess (which may be wrong) is that this is not actually what the
primary usage of this option is intended for. I thought it was more
for configuring all the folks in the accounting department to use a
different printer than the folks in marketing.

I see two ways out:

1) Make it clear what the real relationship between this DHCP option
   and related QOS mechanisms. Note that even making this clear will
   probably still not leave the IESG happy, given the reasons cited
   above. So if this is the approach the WG wants to take, we should
   discuss first.

2) take the example out and use a more appropriate one.

Comments?

Thomas



From owner-dhcp-v4@bucknell.edu  Wed Jul 12 15:42:00 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10904
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 12 Jul 2000 15:41:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6CJdPW19284;
	Wed, 12 Jul 2000 15:39:25 -0400 (EDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6CJdKW12917
	for <dhcp-v4@bucknell.edu>; Wed, 12 Jul 2000 15:39:20 -0400 (EDT)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA36986;
	Wed, 12 Jul 2000 15:38:59 -0400
Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA29578;
	Wed, 12 Jul 2000 15:39:01 -0400
Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA09146; Wed, 12 Jul 2000 15:37:50 -0400
Message-Id: <200007121937.PAA09146@ludwigia.raleigh.ibm.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: dhcp-v4@bucknell.edu
Subject: Re: draft-ietf-dhc-userclass-08.txt 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 12 Jul 2000 15:22:26 EDT." <63D30D6E10CFD11190A90000F805FE8602BEBF1E@lespaul.process.com> 
Date: Wed, 12 Jul 2000 15:37:50 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi Bernie.

> I wonder what world the IESG lives in?

You aren't the first person to wonder that. :-)

> While I would question whether this option would be used to do this,
> this is exactly what several companies we've been dealing with want
> to do.

I think the issue is scalability. So while some folks may think it
makes sense to do QOS based on IP addresses if they haven't thought
through it in a lot of detail, it's not clear that its used in
anything other than very restricted environments. It certainly isn't
used in backbones.  But as you say, debating this point is probably
academic.

Thomas



From owner-dhcp-v4@bucknell.edu  Wed Jul 12 15:53:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11228
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 12 Jul 2000 15:53:11 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6CJqVW23581;
	Wed, 12 Jul 2000 15:52:31 -0400 (EDT)
Received: from honts308.wal-mart.com (honts308.wal-mart.com [146.132.234.38])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6CJqSW00941
	for <dhcp-v4@bucknell.edu>; Wed, 12 Jul 2000 15:52:28 -0400 (EDT)
Received: from honts385.homeoffice.wal-mart.com (fwnts001.wal-mart.com [146.132.235.8]) by honts308.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 3XS8P7C0; Wed, 12 Jul 2000 14:59:15 -0500
Received: from honts305.homeoffice.wal-mart.com (unverified) by honts385.homeoffice.wal-mart.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a8e08618a4d5c543fc7@honts385.homeoffice.wal-mart.com> for <dhcp-v4@bucknell.edu>;
 Wed, 12 Jul 2000 14:51:47 -0500
Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21)
	id <3ZK9725R>; Wed, 12 Jul 2000 14:52:12 -0500
Message-ID: <D3EA66988D05D411BFFB00A0C9899382468123@honts333.homeoffice.wal-mart.com>
From: Nathan Lane <ndlane@wal-mart.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt
Date: Wed, 12 Jul 2000 14:52:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Reply-To: ndlane@wal-mart.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN



> The issue is that this isn't done today, and is not where QOS (ala
> diffserv) is heading. RSVP also has a different model. Finally, it has
> been stated that the above is not a reflection of real deployments
> today. So, the motivational introductory text is problematic and
> possibly out of touch with reality.
> 
	When it comes right down to it, in networks of today this is exactly
how it ends up being done.  While it may not be QoS in the IETF sense, it is
required to simplify the management of such things as access lists and
firewall rules.  In the real world, the business needs most often preceed
the standardized solutions.  Even the standardized solutions often require
the layering of significant extra software and hardware that increases
complexity without necessarily increasing level of service to the end user.

	We are doing exactly what is described above as a mechanism to allow
certain groups of users different access to the Internet.  Firewalls are
mostly still at the point where they cannot even understand DNS reverse
lookups, let alone more sophisticated methods like mapping an IP address to
an actual username.

> My guess (which may be wrong) is that this is not actually what the
> primary usage of this option is intended for. I thought it was more
> for configuring all the folks in the accounting department to use a
> different printer than the folks in marketing.
> 
	My use of this option would be a combination of the first example
and the above example.  While I'd really like to see the world where every
intermediate device "knew" diffserv and RSVP, it's just not happening as
rapidly as we'd like to see.

	I think it is a valid example.  If we throw out the sections on it
assigning clients to specific address pools based on user-class, most of the
draft is gone according to my recent read of it.  A valid example, but
perhaps not the right example for strong consensus building.

	Any site that has a need for this option should also have an
acceptable security infrastructure for their own needs.  Maybe not
academically perfect, but acceptable for business use.

	Nathan Lane
	Diana Lane
>  


**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************



From owner-dhcp-v4@bucknell.edu  Wed Jul 12 16:00:40 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11638
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 12 Jul 2000 16:00:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6CJxEW17618;
	Wed, 12 Jul 2000 15:59:14 -0400 (EDT)
Received: from Arachnid.NTRG.com ([209.31.7.46])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6CJx7W11516
	for <dhcp-v4@bucknell.edu>; Wed, 12 Jul 2000 15:59:07 -0400 (EDT)
Received: from ehsco.com (ferret.ntrg.com [192.168.10.10])
          by Arachnid.NTRG.com (Netscape Messaging Server 3.62)  with ESMTP
          id 496 for <dhcp-v4@bucknell.edu>;
          Wed, 12 Jul 2000 12:58:58 -0700
Message-ID: <396CCE01.909FF0F6@ehsco.com>
Date: Wed, 12 Jul 2000 12:58:57 -0700
From: "Eric A. Hall" <ehall@ehsco.com>
Organization: EHS Company
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: draft-ietf-dhc-userclass-08.txt
References: <200007121852.OAA08837@ludwigia.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: ehall@ehsco.com
Sender: owner-dhcp-v4@bucknell.edu
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


> The issue is that this isn't done today, and is not where QOS (ala
> diffserv) is heading. RSVP also has a different model. Finally, it has
> been stated that the above is not a reflection of real deployments
> today. So, the motivational introductory text is problematic and
> possibly out of touch with reality.

Not to defend the text, but there are those of us who believe that RSVP
and DiffServ are also problematic and out of touch with reality.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/



From owner-dhcp-v4@bucknell.edu  Wed Jul 12 16:03:58 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11743
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 12 Jul 2000 16:03:58 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6CK3JW09987;
	Wed, 12 Jul 2000 16:03:19 -0400 (EDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6CK37W05911;
	Wed, 12 Jul 2000 16:03:07 -0400 (EDT)
Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA17203; Wed, 12 Jul 2000 13:02:16 -0700 (PDT)
Message-Id: <4.1.20000712152915.00b59d60@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 12 Jul 2000 15:47:15 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: John Schnizlein <jschnizl@cisco.com>
Subject: Re: draft-ietf-dhc-userclass-08.txt
Cc: dhcp-v4@bucknell.edu, "Ralph E. Droms" <droms@bucknell.edu>
In-Reply-To: <200007121852.OAA08837@ludwigia.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: jschnizl@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 02:52 PM 07/12/2000 -0400, Thomas Narten wrote:
>
>> 1. Introduction
> 
>> ... A simple solution to this is to use source IP addresses for
>> classification.  Under this scheme, network administrators first
>> configure network devices such as routers to recognize traffic from
>> a particular source IP address (or address range) and handle it
>> specially to meet the desired level of service. Next, they assign
>> the IP addresses to the hosts of the intended users so that the user
>> will receive the appropriate level of service.
>
>The issue is that this isn't done today, and is not where QOS (ala
>diffserv) is heading. RSVP also has a different model. Finally, it has
>been stated that the above is not a reflection of real deployments
>today. So, the motivational introductory text is problematic and
>possibly out of touch with reality.

I don't understand the assertion that this is not done today.
Is it a question of the order in which these steps are performed?
Is it that where queues with different link shares are used for
special traffic, the DiffServ model implies marking at the edge
and current deployments use source or destination addresses?
Does the IESG know that those organizations using custom queuing
to protect SNA/IP traffic have changed to something else?
How much current deployment does there have to be to justify making
this more easily configured through DHCP.

IntServ's model is different; it uses signalling instead of the
simple configuration described in this example. Is this just the
signal or not question in different clothing?

>Then, the security considerations section points out that without
>authentication, doing the above is dubious anyway (which leads the
>IESG to wonder what this option is really good for). So again, using
>this as an example is far from ideal.

Yes, classification of traffic based on addresses, especially source
addresses as long as source address verification is not universal in
the routing infrastructure, has authenticity problems. But they are
used despite this in lots of places, including security. Why block
DHCP from what is done by so many others? Because it did not do it
until after the source address authenticity problem was raised? ;-)

We do not have host authentication solved, but experience with how
(much) the proposed option is used could help us decide if/how to
address this problem.

Has the style of Internet development changed from implementing
simple extensions to existing protocols to one in which every
example has to be part of a broad model? I didn't get the memo. :-)

John



From owner-dhcp-v4@bucknell.edu  Wed Jul 12 16:53:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14563
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 12 Jul 2000 16:53:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6CKogW26143;
	Wed, 12 Jul 2000 16:50:42 -0400 (EDT)
Received: from west8.flashcom.com (d82020d0.hb.flashcom.com [216.32.32.208])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6CKoVW12861
	for <dhcp-v4@bucknell.edu>; Wed, 12 Jul 2000 16:50:31 -0400 (EDT)
Received: by west8.hb.flashcom.com with Internet Mail Service (5.5.2650.21)
	id <M393MKLM>; Wed, 12 Jul 2000 13:49:18 -0700
Message-ID: <29E02FADFCBBD311B24E0008C75B936EEC5081@west8.hb.flashcom.com>
From: Jerry Roy <jroy@flashcom.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt 
Date: Wed, 12 Jul 2000 13:49:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: jroy@flashcom.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Shouldn't QOS be done at BOTH the IP and Mac Layers?

-----Original Message-----
From: Thomas Narten [mailto:narten@RALEIGH.IBM.COM]
Sent: Wednesday, July 12, 2000 12:38 PM
To: DHCPv4 discussion list
Cc: dhcp-v4@bucknell.edu
Subject: Re: draft-ietf-dhc-userclass-08.txt 


Hi Bernie.

> I wonder what world the IESG lives in?

You aren't the first person to wonder that. :-)

> While I would question whether this option would be used to do this,
> this is exactly what several companies we've been dealing with want
> to do.

I think the issue is scalability. So while some folks may think it
makes sense to do QOS based on IP addresses if they haven't thought
through it in a lot of detail, it's not clear that its used in
anything other than very restricted environments. It certainly isn't
used in backbones.  But as you say, debating this point is probably
academic.

Thomas



From owner-dhcp-v4@bucknell.edu  Thu Jul 13 04:18:51 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09934
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 13 Jul 2000 04:18:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6D8FpW27653;
	Thu, 13 Jul 2000 04:15:51 -0400 (EDT)
Received: from gollum.axion.bt.co.uk (gollum.axion.bt.co.uk [132.146.17.41])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6D8FnW07886;
	Thu, 13 Jul 2000 04:15:49 -0400 (EDT)
Received: from cbtlipnt02.btlabs.bt.co.uk by gollum (local) with ESMTP;
          Thu, 13 Jul 2000 09:09:56 +0100
Received: by cbtlipnt02.btlabs.bt.co.uk 
          with Internet Mail Service (5.5.2651.88) id <3GKHBTMF>;
          Thu, 13 Jul 2000 09:08:41 +0100
Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB207E89890@mbtlipnt02.btlabs.bt.co.uk>
From: jerome.privat@bt.com
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt
Date: Thu, 13 Jul 2000 09:06:42 +0100
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Reply-To: jerome.privat@bt.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I suggest we don't enter the debate to decide whether the QoS
example is a good one or not. Let's take this example out and
use a less controversial one (such as the one you gave about
the 2 different printers).

If the WG agrees with this approach, I will update the draft
accordingly (this will be version -10 as there is already a version
-09 in the ID queue with a more correct formatting).
I will probably not have time to produce this new version before the
cut-off date (tomorrow). So I will submit it after the Pittsburg meeting.
Please also note that I cannot make the Pittsburg meeting, so if you
have any issues, please post them on this mailing list.

Jerome


-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com]
Sent: 12 July 2000 19:53
To: jerome.privat@bt.com
Cc: dhcp-v4@bucknell.edu; Ralph E. Droms
Subject: draft-ietf-dhc-userclass-08.txt


Folks:

The IESG has been discussing this document and some of the wording  in
it has attracted some attention. Specifically:

> 1. Introduction
 
> It is often desirable to provide different levels of service to
> different users of an IP network.  In order for an IP network to
> implement this service differentiation, it needs a way to classify
> users. A simple solution to this is to use source IP addresses for
> classification.  Under this scheme, network administrators first
> configure network devices such as routers to recognize traffic from
> a particular source IP address (or address range) and handle it
> specially to meet the desired level of service. Next, they assign
> the IP addresses to the hosts of the intended users so that the user
> will receive the appropriate level of service.

The issue is that this isn't done today, and is not where QOS (ala
diffserv) is heading. RSVP also has a different model. Finally, it has
been stated that the above is not a reflection of real deployments
today. So, the motivational introductory text is problematic and
possibly out of touch with reality.

Then, the security considerations section points out that without
authentication, doing the above is dubious anyway (which leads the
IESG to wonder what this option is really good for). So again, using
this as an example is far from ideal.

My guess (which may be wrong) is that this is not actually what the
primary usage of this option is intended for. I thought it was more
for configuring all the folks in the accounting department to use a
different printer than the folks in marketing.

I see two ways out:

1) Make it clear what the real relationship between this DHCP option
   and related QOS mechanisms. Note that even making this clear will
   probably still not leave the IESG happy, given the reasons cited
   above. So if this is the approach the WG wants to take, we should
   discuss first.

2) take the example out and use a more appropriate one.

Comments?

Thomas



From owner-dhcp-v4@bucknell.edu  Thu Jul 13 08:54:10 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16593
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 13 Jul 2000 08:54:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6DCnfW30815;
	Thu, 13 Jul 2000 08:49:41 -0400 (EDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6DCnQW18011
	for <dhcp-v4@bucknell.edu>; Thu, 13 Jul 2000 08:49:26 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id FAA22402; Thu, 13 Jul 2000 05:49:23 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id FAA08228; Thu, 13 Jul 2000 05:49:23 -0700 (MST)]
Received: from dma.isg.mot.com (cabs2.dma.isg.mot.com [150.21.2.48])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id IAA21142;
	Thu, 13 Jul 2000 08:49:22 -0400 (EDT)
Message-Id: <200007131249.IAA21142@noah.dma.isg.mot.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: dhcp-v4@bucknell.edu, narten@raleigh.ibm.com
Subject: draft 11 of relay agent options
Date: Thu, 13 Jul 2000 08:49:21 -0400
From: "Michael W. Patrick" <mpatrick@dma.isg.mot.com>
Reply-To: mpatrick@dma.isg.mot.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I've updated the relay agent options draft per IESG editorial
requests and am now issuing draft-dhc-agent-options-11.txt as
the hopefully final text for IESG approval.

-mike







INTERNET DRAFT


DHC  Working Grop                                      Michael Patrick
<draft-ietf-dhc-agent-options-11.txt>                  Motorola BCS
                                                       July 13, 2000


                  DHCP Relay Agent Information Option

Status of this Memo


   This document is an Internet Draft and is in full conformance of
   section 10 of RFC2026.  Internet Drafts are working documents of the
   Internet Engineering Task Force (IETF), its Areas, and its Working
   Groups.  Note that other groups may also distribute working documents
   as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shado Directories can be accessed at
   http://ww.ietf.org/shadow.html


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

Abstract

   Newer high-speed public Internet access technologies call for a
   high-speed modem to have a LAN attachment to one or more customer
   premise hosts.  It is advantageous to use the Dynamic Host
   Configuration Protocol as defined in RFC 2131 [1] to assign customer
   premise host IP addresses in this environment. However, a number of
   security and scaling problems arise with such "public" DHCP use.
   This document describes a new DHCP option to address these issues.
   This option extends the set of DHCP options as defined in RFC 2132
   [2].




Expires January 2001                                            [Page 1]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


   The new option is called the Relay Agent Information option and is
   inserted by the DHCP relay agent when forwarding client-originated
   DHCP packets to a DHCP server.  Servers recognizing the Relay Agent
   Information option may use the information to implement IP address or
   other parameter assignment policies. The DHCP Server echoes the
   option back verbatim to the relay agent in server-to-client replies,
   and the relay agent strips the option before forwarding the reply to
   the client.

   The "Relay Agent Information" option is organized as a single DHCP
   option that contains one or more "sub-options" that convey
   information known by the relay agent.  The initial sub-options are
   defined for a relay agent that is co-located in a public circuit
   access unit.  These include a "circuit ID" for the incoming circuit,
   and a "remote ID" which provides a trusted identifier for the remote
   high-speed modem.

Table of Contents

        1   Introduction........................................... 2
        1.1 High-Speed Circuit Switched Data Networks.............. 2
        1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4
        2.0 Relay Agent Information Option......................... 5
        2.1 Agent Operation........................................ 6
        2.1.1 Reforwarded DHCP requests............................ 7
        2.2 Server Operation....................................... 7
        3.0 Relay Agent Information Suboptions..................... 8
        3.1 Agent Circuit ID....................................... 8
        3.2 Agent Remote ID........................................ 9
        4.0 Issues Resolved........................................ 10
        5.0 Security Considerations................................ 11
        6.0 IANA Considerations.................................... 11
        7.0 Intellectual Property Notice........................... 12
        8.0 References............................................. 12
        9.0 Glossary............................................... 13
        10.0 Author's Address...................................... 13



1   Introduction

1.1 High-Speed Circuit Switched Data Networks

   Public Access to the Internet is usually via a circuit switched data
   network.  Today, this is primarily implemented with dial-up modems
   connecting to a Remote Access Server.  But higher speed circuit
   access networks also include ISDN, ATM, Frame Relay, and Cable Data
   Networks.  All of these networks can be characterized as a "star"



Expires January 2001                                            [Page 2]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


   topology where multiple users connect to a "circuit access unit" via
   switched or permanent circuits.

   With dial-up modems, only a single host PC attempts to connect to the
   central point.  The PPP protocol is widely used to assign IP
   addresses to be used by the single host PC.

   The newer high-speed circuit technologies, however, frequently
   provide a LAN interface (especially Ethernet) to one or more host
   PCs.  It is desirable to support centralized assignment of the IP
   addresses of host computers connecting on such circuits via DHCP.
   The DHCP server can be, but usually is not, co-implemented with the
   centralized circuit concentration access device.  The DHCP server is
   often connected as a separate server on the "Central LAN" to which
   the central access device (or devices) attach.

   A common physical model for high-speed Internet circuit access is
   shown in Figure 1, below.




                      +---------------+                          |
        Central       |   Circuit     |-- ckt 1--- Modem1-- Host-|- Host A
        LAN     |     |   Access      |                     Lan  |- Host B
                |     |   Unit 1      |                          |- Host C
                |-----|               |--                        |
                |     |(relay agent)  |...
   +---------+  |     +---------------+
   |  DHCP   |--|
   | Server  |  |
   +---------+  |
                |
                |     +---------------+
   +---------+  |     |   Circuit     |-- ckt 1--- Modem2-- Host--- Host D
   | Other   |  |     |   Access      |                     Lan
   | Servers |--|-----|   Unit 2      |
   |  (Web,  |  |     |               |-- ckt 2--- Modem3-- Host--- Host E
   |   DNS)  |  |     |(relay agent)  |...                  Lan
   |         |        +---------------+
   +---------+
            Figure 1:  DHCP High Speed Circuit Access Model


   Note that in this model, the "modem" connects to a LAN at the user
   site, rather than to a single host. Multiple hosts are implemented at
   this site.  Although it is certainly possible to implement a full IP
   router at the user site, this requires a relatively expensive piece



Expires January 2001                                            [Page 3]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


   of equipment (compared to typical modem costs).  Furthermore, a
   router requires an IP address not only for every host, but for the
   router itself. Finally, a user-side router requires a dedicated
   Logical IP Subnet (LIS) for each user.  While this model is
   appropriate for relatively small corporate networking environments,
   it is not appropriate for large, public accessed networks. In this
   scenario, it is advantageous to implement an IP networking model that
   does not allocate an IP address for the modem (or other networking
   equipment device at the user site), and especially not an entire LIS
   for the user side LAN.

   Note that using this method to obtain IP addresses means that IP
   addresses can only be obtained while communication to the central
   site is available. Some host lan installations may use a local DHCP
   server or other methods to obtain IP addresses for in-house use.

1.2 DHCP Relay Agent in the Circuit Access Unit

   It is desirable to use DHCP to assign the IP addresses for public
   high-speed circuit access.  A number of circuit access units (e.g.
   RAS's, cable modem termination systems, ADSL access units, etc)
   connect to a LAN (or local internet) to which is attached a DHCP
   server.

   For scaling and security reasons, it is advantageous to implement a
   "router hop" at the circuit access unit, much like high-capacity
   RAS's do today.  The circuit access equipment acts as both a router
   to the circuits and as the DHCP relay agent.

   The advantages of co-locating the DHCP relay agent with the circuit
   access equipment are:

   DHCP broadcast replies can be routed to only the proper circuit,
   avoiding, say, the replication of the DCHP reply broadcast onto
   thousands of access circuits;

   The same mechanism used to identify the remote connection of the
   circuit (e.g. a user ID requested by a Remote Access Server acting as
   the circuit access equipment) may be used as a host identifier by
   DHCP, and used for parameter assignment.  This includes centralized
   assignment of IP addresses to hosts.  This provides a secure remote
   ID from a trusted source -- the relay agent.

   A number of issues arise when forwarding DHCP requests from hosts
   connecting publicly accessed high-speed circuits with LAN connections
   at the host. Many of these are security issues arising from DHCP
   client requests from untrusted sources.  How does the relay agent
   know to which circuit to forward replies?  How does the system



Expires January 2001                                            [Page 4]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


   prevent  DHCP IP exhaustion attacks?  This is when an attacker
   requests all available IP addresses from a DHCP server by sending
   requests with fabricated client MAC addresses.  How can an IP address
   or LIS be permanently assigned to a particular user or modem?  How
   does one prevent "spoofing" of client identifer fields used to assign
   IP addresses?  How does one prevent denial of service by "spoofing"
   other client's MAC addresses?

   All of these issues may be addressed by having the circuit access
   equipment, which is a trusted component, add information to DHCP
   client requests that it forwards to the DHCP server.

2.0 Relay Agent Information Option

   This document defines a new DHCP Option called the Relay Agent
   Information Option.  It is a "container" option for specific agent-
   supplied sub-options.  The format of the Relay Agent Information
   option is:


            Code   Len     Agent Information Field
           +------+------+------+------+------+------+--...-+------+
           |  82  |   N  |  i1  |  i2  |  i3  |  i4  |      |  iN  |
           +------+------+------+------+------+------+--...-+------+

   The length N gives the total number of octets in the Agent
   Information Field. The Agent Information field consists of a sequence
   of SubOpt/Length/Value tuples for each sub-option, encoded in the
   following manner:


            SubOpt  Len     Sub-option Value
           +------+------+------+------+------+------+--...-+------+
           |  1   |   N  |  s1  |  s2  |  s3  |  s4  |      |  sN  |
           +------+------+------+------+------+------+--...-+------+
            SubOpt  Len     Sub-option Value
           +------+------+------+------+------+------+--...-+------+
           |  2   |   N  |  i1  |  i2  |  i3  |  i4  |      |  iN  |
           +------+------+------+------+------+------+--...-+------+


   No "pad" sub-option is defined, and the Information field shall NOT
   be terminated with a 255 sub-option.  The length N of the DHCP Agent
   Information Option shall include all bytes of the sub-option
   code/length/value tuples. Since at least one sub-option must be
   defined, the minimum Relay Agent Information length is two (2).  The
   length N of the sub-options shall be the number of octets in only
   that sub-option's value field.  A sub-option length may be zero.  The



Expires January 2001                                            [Page 5]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


   sub-options need not appear in sub-option code order.


   The initial assignment of DHCP Relay Agent Sub-options is as follows:


                   DHCP Agent              Sub-Option Descrption
                   Sub-option Code
                   ---------------         ----------------------
                       1                   Agent Circuit ID Sub-option
                       2                   Agent Remote ID Sub-option



2.1 Agent Operation

   Overall adding of the DHCP relay agent option SHOULD be configurable,
   and SHOULD be disabled by default. Relay agents SHOULD have separate
   configurables for each sub-option to control whether it is added to
   client-to-server packets.

   A DHCP relay agent adding a Relay Agent Information field SHALL add
   it as the last DHCP agent option in the DHCP options field of any
   recognized BOOTP or DHCP packet forwarded from a client to a server.

   Relay agents receiving a DHCP packet from an untrusted source with
   giaddr set to zero (indicating that they are the first-hop router)
   but with a Relay Agent Information option already present in the
   packet SHALL discard the packet and increment an error count. A
   trusted network element (e.g. a bridge) between the relay agent and
   the client MAY add a relay agent option but not set the giaddr field.
   In this case, the relay agent does NOT add a "second" relay agent
   option, but forwards the DHCP packet per normal DHCP relay agent
   operations.

   Relay agents MAY have a configurable for the maximum size of the DHCP
   packet to be created after appending the Agent Information option.
   Packets which, after appending the Relay Agent Information option,
   would exceed this configured maximum size shall be forwarded WITHOUT
   adding the Agent Information option. An error counter SHOULD be
   incremented in this case.  In the absence of this configurable, the
   agent SHALL NOT increase a forwarded DHCP packet size to exceed the
   MTU of the interface on which it is forwarded.

   The Relay Agent Information option echoed by a server MUST be removed
   by the agent when forwarding a server-to-client response back to the
   client.




Expires January 2001                                            [Page 6]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


   The agent SHALL NOT add an "Option Overload" option to the packet or
   use the "file" or "sname" fields for adding Relay Agent Information
   option.  It SHALL NOT parse or remove Relay Agent Information options
   that may appear in the sname or file fields of a server-to-client
   packet forwarded through the agent.

   The operation of relay agents for specific sub-options is specified
   with that sub-option.

   Relay agents are NOT required to monitor or modify client-originated
   DHCP packets addressed to a server unicast address. This  includes
   the DHCP-REQUEST sent when entering the RENEWING state.

   Relay agents MUST NOT modify DHCP packets that use the IPSEC
   Authentication Header or IPSEC Encapsulating Security Payload [6].

2.1.1 Reforwarded DHCP requests

   A DHCP relay agent may receive a client DHCP packet forwarded from a
   BOOTP/DHCP relay agent closer to the client. Such a packet will have
   giaddr as non-zero, and may or may not already have a DHCP Relay
   Agent option in it.

   Relay agents configured to add a Relay Agent option which receive a
   client DHCP packet with a nonzero giaddr SHALL discard the packet if
   the giaddr spoofs a giaddr address implemented by the local agent
   itself.

   Otherwise, the relay agent SHALL forward any received DHCP packet
   with a valid non-zero giaddr WITHOUT adding any relay agent options.
   Per RFC 2131, it shall also NOT modify the giaddr value.


2.2     Server Operation

   DHCP servers unaware of the Relay Agent Information option will
   ignore the option upon receive and will not echo it back on
   responses.  This is the specified server behavior for unknown
   options.

   DHCP servers claiming to support the Relay Agent Information option
   SHALL echo the entire contents of the Relay Agent Information option
   in all replies.  Servers SHOULD copy the Relay Agent Information
   option as the last DHCP option in the response.  Servers SHALL NOT
   place the echoed Relay Agent Information option in the overloaded
   sname or file fields.  If a server is unable to copy a full Relay
   Agent Information field into a response, it SHALL send the response
   without the Relay Information Field, and SHOULD increment an error



Expires January 2001                                            [Page 7]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


   counter for the situation.

   The operation of DHCP servers for specific sub-options is specified
   with that sub-option.

   Note that DHCP relay agents are not required to monitor unicast DHCP
   messages sent directly between the client and server (i.e, those that
   aren't sent via a relay agent). However, some relay agents MAY chose
   to do such monitoring and add relay agent options. Consequently,
   servers SHOULD be prepared to handle relay agent options in unicast
   messages, but MUST NOT expect them to always be there.

3.0 Relay Agent Information Sub-options

3.1 Agent Circuit ID Sub-option

   This sub-option MAY be added by DHCP relay agents which terminate
   switched or permanent circuits.  It encodes an agent-local identifier
   of the circuit from which a DHCP client-to-server packet was
   received.  It is intended for use by agents in relaying DHCP
   responses back to the proper circuit.  Possible uses of this field
   include
       - Router interface number
       - Switching Hub port number
       - Remote Access Server port number
       - Frame Relay DLCI
       - ATM virtual circuit number
       - Cable Data virtual circuit number

   Servers MAY use the Circuit ID for IP and other parameter assignment
   policies. The Circuit ID SHOULD be considered an opaque value, with
   policies based on exact string match only; that is, the Circuit ID
   SHOULD NOT be internally parsed by the server.

   The DHCP server SHOULD report the Agent Circuit ID value of current
   leases in statistical reports (including its MIB) and in logs.  Since
   the Circuit ID is local only to a particular relay agent, a circuit
   ID should be qualified with the giaddr value that identifies the
   relay agent.


            SubOpt   Len     Circuit ID
           +------+------+------+------+------+------+------+------+--
           |  1   |   n  |  c1  |  c2  |  c3  |  c4  |  c5  |  c6  | ...
           +------+------+------+------+------+------+------+------+--






Expires January 2001                                            [Page 8]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


3.2 Agent Remote ID Sub-option

   This sub-option MAY be added by DHCP relay agents which terminate
   switched or permanent circuits and have mechanisms to identify the
   remote host end of the circuit.  The Remote ID field may be used to
   encode, for instance:
       -- a "caller ID" telephone number for dial-up connection
       -- a "user name" prompted for by a Remote Access Server
       -- a remote caller ATM address
       -- a "modem ID" of a cable data modem
       -- the remote IP address of a point-to-point link
       -- a remote X.25 address for X.25 connections

   The remote ID MUST be globally unique.

   DHCP servers MAY use this option to select parameters specific to
   particular users, hosts, or subscriber modems. The option SHOULD be
   considered an opaque value, with policies based on exact string match
   only; that is, the option SHOULD NOT be internally parsed by the
   server.

   The relay agent MAY use this field in addition to or instead of the
   Agent Circuit ID field to select the circuit on which to forward the
   DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this
   value in any reports or MIBs associated with a particular client.



            SubOpt   Len     Agent Remote ID
           +------+------+------+------+------+------+------+------+--
           |  2   |   n  |  r1  |  r2  |  r3  |  r4  |  r5  |  r6  | ...
           +------+------+------+------+------+------+------+------+--



















Expires January 2001                                            [Page 9]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


4.0 Issues Resolved

   The DHCP relay agent option resolves several issues in an environment
   in which untrusted hosts access the intervet via a circuit based
   public network. This resolution assumes that all DHCP protocol
   traffic by the public hosts traverse the DHCP relay agent and that
   the IP network between the DHCP relay agent and the DHCP server is
   uncompromised.

   Broadcast Forwarding

      The circuit access equipment forwards the normally broadcasted
      DHCP response only on the circuit indicated in the Agent Circuit
      ID.

   DHCP Address Exhaustion

      In general, the DHCP server may be extended to maintain a database
      with the "triplet" of


                  (client IP address,  client MAC address,  client remote ID)


      The DHCP server SHOULD implement policies that restrict the number
      of IP addresses to be assigned to a single remote ID.


   Static Assignment

      The DHCP server may use the remote ID to select the IP address to
      be assigned.  It may permit static assignment of IP addresses to
      particular remote IDs, and disallow an address request from an
      unauthorized remote ID.


   IP Spoofing

      The circuit access device may associate the IP address assigned by
      a DHCP server in a forwarded DHCP Ack packet with the circuit to
      which it was forwarded. The circuit access device MAY prevent
      forwarding of IP packets with source IP addresses -other than-
      those it has associated with the receiving circuit.  This prevents
      simple IP spoofing attacks on the Central LAN, and IP spoofing of
      other hosts.






Expires January 2001                                           [Page 10]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


   Client Identifer Spoofing

      By using the agent-supplied Agent Remote ID option, the untrusted
      and as-yet unstandardized client identifer field need not be used
      by the DHCP server.

   MAC Address Spoofing

      By associating a MAC address with an Agent Remote ID, the DHCP
      server can prevent offering an IP address to an attacker spoofing
      the same MAC address on a different remote ID.

5.0 Security Considerations

   DHCP as currently defined provides no authentication or security
   mechanisms.  Potential exposures to attack are discussed in section 7
   of the DHCP protocol specification in RFC 2131 [1].

   This document introduces mechanisms to address several security
   attacks on the operation of IP address assignment, including IP
   spoofing, Client ID spoofing, MAC address spoofing, and DHCP server
   address exhaustion. It relies on an implied trusted relationship
   between the DHCP Relay Agent and the DHCP server, with an assumed
   untrusted DHCP client.  It introduces a new identifer, the "Remote
   ID", that is also assumed to be trusted. The Remote ID is provided by
   the access network or modem and not by client premise equipment.
   Cryptographic or other techniques to authenticate the remote ID are
   certainly possible and encouraged, but are beyond the scope of this
   document.

   Note that any future mechanisms for authenticating DHCP client to
   server communications must take care to omit the DHCP Relay Agent
   option from server authentication calculations. This was the
   principal reason for organizing the DHCP Relay Agent Option as a
   single option with sub-options, and for requiring the relay agent to
   remove the option before forwarding to the client.

   While it is beyond the scope of this document to specify the general
   forwarding algorithm of public data circuit access units, note that
   automatic reforwarding of IP or ARP broadcast packets back downstream
   exposes serious IP security risks.  For example, if an upstream
   broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back
   downstream, any public host may easily spoof the desired DHCP server.

6.0 IANA Considerations

   IANA is required to maintain a new number space of "DHCP Relay Agent
   Sub-options", with the initial sub-options as described in this



Expires January 2001                                           [Page 11]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000


   document.

   IANA assigns future DHCP Relay Agent Sub-options with a "IETF
   Consensus" policy as described in RFC 2434 [3].  Future proposed
   sub-options are to be referenced symbolically in the internet-drafts
   that describe them, and shall be assigned numeric codes by IANA when
   and if the draft is approved by IESG for Proposed Standard RFC
   status.

7.0 Intellectual Property Notices

   This section contains two notices as required by [5] for standards
   track documents.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

8.0 References

        [1]     Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
                Bucknell University, March 1997.



        [2]     Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor
                Extension"  RFC 2132.



        [3]     Narten,T. and Alvestrand, H. "Guidelines for Writing an
                IANA Considerations Section in RFCs", RFC 2434.




Expires January 2001                                           [Page 12]





<draft-ietf-dhc-agent-options-11.txt>                      July 13, 2000



        [4]     Bradner, S. "Key words for use in RFCs to Indicate Requirement
                Levels", RFC 2119.



        [5]     Bradner, S. "The Internet Standards Process -- Revision 3",
                RFC 2026.



        [6]     Kent, S. and Atkinson, R. "Security Architecture for the
                Internet Protocol", RFS 2401.


9.0 Glossary


           IANA    Internet Assigned Numbers Authority
           LIS     Logical IP Subnet
           MAC     Message Authentication Code
           RAS     Remote Access Server

10.0 Author's Address

               Michael Patrick
               Motorola Broadband Communications Sector
               20 Cabot Blvd., MS M4-30
               Mansfield, MA 02048

               Phone: (508) 261-5707
               Email: michael.patrick@motorola.com



















Expires January 2001                                           [Page 13]





From owner-dhcp-v4@bucknell.edu  Fri Jul 14 06:54:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09933
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 14 Jul 2000 06:54:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6EAoMW00399;
	Fri, 14 Jul 2000 06:50:22 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6EAoBW02464
	for <dhcp-v4@bucknell.edu>; Fri, 14 Jul 2000 06:50:11 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08680;
	Fri, 14 Jul 2000 06:50:10 -0400 (EDT)
Message-Id: <200007141050.GAA08680@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-agent-options-11.txt
Date: Fri, 14 Jul 2000 06:50:10 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: DHCP Relay Agent Information Option
	Author(s)	: M. Patrick
	Filename	: draft-ietf-dhc-agent-options-11.txt
	Pages		: 13
	Date		: 13-Jul-00
	
Newer high-speed public Internet access technologies call for a
high-speed modem to have a LAN attachment to one or more customer
premise hosts.  It is advantageous to use the Dynamic Host
Configuration Protocol as defined in RFC 2131 [1] to assign customer
premise host IP addresses in this environment. However, a number of
security and scaling problems arise with such 'public' DHCP use.
This document describes a new DHCP option to address these issues.
This option extends the set of DHCP options as defined in RFC 2132
[2].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-11.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-agent-options-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-agent-options-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000713145033.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-agent-options-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-agent-options-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000713145033.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Fri Jul 14 12:26:14 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21650
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 14 Jul 2000 12:26:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6EGMRW19024;
	Fri, 14 Jul 2000 12:22:27 -0400 (EDT)
Received: from monitor.internaut.com (mg-206191146-48.ricochet.net [206.191.146.48])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6EGMKW16658
	for <dhcp-v4@bucknell.edu>; Fri, 14 Jul 2000 12:22:21 -0400 (EDT)
Received: from kidneybean ([204.57.137.38])
	by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA85377;
	Fri, 14 Jul 2000 09:18:22 -0700 (PDT)
From: aboba@internaut.com
Reply-To: <aboba@internaut.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt
Date: Fri, 14 Jul 2000 09:22:05 -0700
Message-ID: <013501bfedaf$a720d630$268939cc@ntdev.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <D3EA66988D05D411BFFB00A0C9899382468123@honts333.homeoffice.wal-mart.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

>It is required to simplify the management of such things as access lists
and
>firewall rules.

If that's the intent, there are a few problems:

a. DHCP isn't an access control mechanism, even with authenticated DHCP;
   the user can choose their own static address and thereby get around
   any rules you impose.
b. Authenticated DHCP presumes that the identity is asserted in the
   client identifier option, not the userclass option. Remember that the
   key for authenticated DHCP is a function of the master key and the
   client identifer. Therefore the user can claim any userclass they
   want unless the DHCP server intends to verify the userclass
   assignment based on the client identifier.



From owner-dhcp-v4@bucknell.edu  Fri Jul 14 12:32:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24047
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 14 Jul 2000 12:32:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6EGWAW19073;
	Fri, 14 Jul 2000 12:32:10 -0400 (EDT)
Received: from honts308.wal-mart.com (honts308.wal-mart.com [146.132.234.38])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6EGW5W04823
	for <dhcp-v4@bucknell.edu>; Fri, 14 Jul 2000 12:32:05 -0400 (EDT)
Received: from fwnts001.wal-mart.com ([146.132.235.8]) by honts308.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 3XS8R5MA; Fri, 14 Jul 2000 11:38:56 -0500
Received: from walmart.com by fwnts001.wal-mart.com
          via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 14 Jul 2000 16:31:49 UT
Received: from honts305.homeoffice.wal-mart.com (unverified) by honts388.homeoffice.wal-mart.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Ta1ad84531484d65e9e7d0@honts388.homeoffice.wal-mart.com> for <dhcp-v4@bucknell.edu>;
 Fri, 14 Jul 2000 11:31:49 -0500
Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21)
	id <3ZK0DMAW>; Fri, 14 Jul 2000 11:31:49 -0500
Message-ID: <D3EA66988D05D411BFFB00A0C9899382468132@honts333.homeoffice.wal-mart.com>
From: Nathan Lane <ndlane@wal-mart.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt
Date: Fri, 14 Jul 2000 11:31:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Reply-To: ndlane@wal-mart.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN



> -----Original Message-----
> From:	aboba@INTERNAUT.COM [SMTP:aboba@INTERNAUT.COM]
> Sent:	Friday, July 14, 2000 11:22 AM
> To:	DHCPv4 discussion list
> Subject:	RE: draft-ietf-dhc-userclass-08.txt
> 
> >It is required to simplify the management of such things as access lists
> and
> >firewall rules.
> 
> If that's the intent, there are a few problems:
> 
> a. DHCP isn't an access control mechanism, even with authenticated DHCP;
>    the user can choose their own static address and thereby get around
>    any rules you impose.
> 
	Not necessarily.  If the DHCP server writes the access list in the
router or uses other means to limit the ability to route addresses not
assigned by the DHCP server.  This doesn't prevent LAN access, of course,
unless the DHCP server also dynamically writes VLAN information into the
switch.

> Therefore the user can claim any userclass they
>    want unless the DHCP server intends to verify the userclass
>    assignment based on the client identifier.
	I would certainly do that.  The draft doesn't enforce any specific
server behavior on this option.

	-Nathan Lane
>  


**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************



From owner-dhcp-v4@bucknell.edu  Fri Jul 14 12:53:09 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29707
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 14 Jul 2000 12:53:08 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6EGmwW29813;
	Fri, 14 Jul 2000 12:48:58 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6EGmoW08166
	for <dhcp-v4@bucknell.edu>; Fri, 14 Jul 2000 12:48:51 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-246.ip.theriver.com [206.97.58.246]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA04221; Thu, 13 Jul 2000 18:08:35 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id JAA00555; Fri, 14 Jul 2000 09:49:23 -0700 (MST)
Message-Id: <200007141649.JAA00555@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: draft-ietf-dhc-userclass-08.txt 
In-Reply-To: Message from Nathan Lane <ndlane@wal-mart.com> 
   of "Fri, 14 Jul 2000 11:31:45 EST." <D3EA66988D05D411BFFB00A0C9899382468132@honts333.homeoffice.wal-mart.com> 
Date: Fri, 14 Jul 2000 09:49:23 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


The user class option was originally intended to be something where
the user typed in a user class and got different options on that
basis, probably as documented by the system administration staff.   It
has no authentication.   You can't use it as a credential - if you
have to look the credential up on the server, there's no point in the
client sending it.

However, as most of us know but usually don't write in RFCs, the only
reason the Internet hasn't been taken over by bandits already is that
most of us are trustworthy.   It's certainly not because we have much
security.   Sometimes it works to just tell people they should use a
certain value for the user class, and trust them to honor your
request.   This is useful, despite the fact that it isn't secure.   It
is also useful to use the user class option to say where you're
located, so you get the right printer.

So I think it's perfectly legitimate to use these as examples in the
draft, although you'll spend less time arguing with security people if
you don't mention any access control mechanism that depends on the
honor system.   So using the printer selection bit as an example is
probably the best thing to do.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Fri Jul 14 13:18:23 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06608
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 14 Jul 2000 13:18:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6EHEHW27142;
	Fri, 14 Jul 2000 13:14:17 -0400 (EDT)
Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6EHECW18780
	for <dhcp-v4@bucknell.edu>; Fri, 14 Jul 2000 13:14:12 -0400 (EDT)
Received: from fwnts001.wal-mart.com ([146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 3XSVQPV9; Fri, 14 Jul 2000 12:18:21 -0500
Received: from honts386.homeoffice.wal-mart.com by fwnts001.wal-mart.com
          via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 14 Jul 2000 17:13:57 UT
Received: from honts305.homeoffice.wal-mart.com (unverified) by honts386.homeoffice.wal-mart.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a8e0871ca4d660cf4f8@honts386.homeoffice.wal-mart.com> for <dhcp-v4@bucknell.edu>;
 Fri, 14 Jul 2000 12:10:06 -0500
Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21)
	id <38JCBYZC>; Fri, 14 Jul 2000 12:13:56 -0500
Message-ID: <D3EA66988D05D411BFFB00A0C9899382468134@honts333.homeoffice.wal-mart.com>
From: Nathan Lane <ndlane@wal-mart.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt 
Date: Fri, 14 Jul 2000 12:13:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Reply-To: ndlane@wal-mart.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN



> -----Original Message-----
> From:	Ted Lemon [SMTP:mellon@nominum.com]
> You can't use it as a credential - if you
> have to look the credential up on the server, there's no point in the
> client sending it.
> 
	I actually hadn't intended to imply I was going to use it as a
credential.  In a situation where a user class is valid on network A, but
not network B, there would have to be a mechanism to choose not to apply the
user class.  I chose unfortunate wording of "look it up", implying an
external credential data store.

	Would it be a bad thing to validate the user class for applicability
at least?  We wouldn't want people breaking their machines.

	These are off topic for the draft, though so if anyone has thoughts,
I'd like to hear them off-line.

	-Nathan Lane



**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************



From owner-dhcp-v6@bucknell.edu  Fri Jul 14 14:03:02 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22632
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 14 Jul 2000 14:03:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6EI06W23286;
	Fri, 14 Jul 2000 14:00:06 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6EHxvW06918
	for <dhcp-v6@bucknell.edu>; Fri, 14 Jul 2000 13:59:57 -0400 (EDT)
Received: from esvir03nok.ntc.nokia.com (esvir03nok.ntc.nokia.com [131.228.10.152])
	by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6EEBFi05019
	for <dhcp-v6@bucknell.edu>; Fri, 14 Jul 2000 17:11:16 +0300 (EET DST)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir03nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <B83e40a984d65cea658@esvir03nok.ntc.nokia.com> for <dhcp-v6@bucknell.edu>;
 Fri, 14 Jul 2000 11:02:03 +0300
Received: by esebh02nok with Internet Mail Service (5.5.2650.10)
	id <3VVZLNZR>; Fri, 14 Jul 2000 11:02:03 +0300
Message-ID: <EDA081458FB6D211A7BC0008C7D9B33103594B84@eseis08nok>
From: Harri.Paloheimo@nokia.com
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6 & BIND version ?
Date: Fri, 14 Jul 2000 11:02:02 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi,

I would appreciate answers to the following questions or hints that point to
a source of information:

1. What version(s) of BIND support (or are going to support) DHCPv6?
2. What type of DHCP can be integrated with DNS, i.e. DDNS?
3. Can both be placed within a same machine or not?

Cheers,

Harri Paloheimo



From owner-dhcp-v6@bucknell.edu  Sat Jul 15 09:20:01 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20062
	for <DHC-ARCHIVE@odin.ietf.org>; Sat, 15 Jul 2000 09:20:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6FDHHW07040;
	Sat, 15 Jul 2000 09:17:17 -0400 (EDT)
Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6FDHBW12240;
	Sat, 15 Jul 2000 09:17:11 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (pm3mi2-28.uplink.net [209.173.86.77])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA14940;
	Sat, 15 Jul 2000 09:17:10 -0400 (EDT)
Message-Id: <4.3.1.2.20000713200826.00b92e70@funnel.cisco.com>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 13 Jul 2000 20:12:27 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: DHC WG meetings in Pittsburgh
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

As posted in the *DRAFT* agenda, the DHC WG will meet Monday evening and 
Tuesday morning in Pittsburgh.  Tentatively, the WG will discuss DHCPv4 
issues in the first meeting and DHCPv6 issues in the second meeting.  See 
the schedule below for a list of other WGs meeting at the same time.  If 
you have a conflict, let me know.

Also, please contact me as soon as possible with any requests for agenda time.

- Ralph

MONDAY, July 31, 2000
1930-2200  Evening Sessions

APP  spatial	Spatial Location BOF
INT  dhc	Dynamic Host Configuration WG
INT  ipcdn	IP Over Cable Data Network WG
OPS  mboned	MBONE Depoloyement WG
SEC  ipsra	IP Security Remote Access WG
TSV  diffserv	Differentiated Services WG
TSV  mmusic	Multiparty Multimedia Session Control WG
			

TUESDAY, August 1, 2000
0900-1130  Morning Sessions

APP  vpim	Voice Profile for Internet Mail WG
INT  dhc	Dynamic Host Configuration WG
OPS  snmpconf	Configuration Management with SNMP WG
RTG  pim	Protocol Independent Multicast WG	
SEC  pkix	Public-Key Infrastructure (X.509) WG
TSV  enum	Telephone Number Mapping WG
TSV  issll	Integrated Services over Specific Link Layers WG
TSV  nfsv4	Network File System Version 4 WG



From owner-dhcp-v4@bucknell.edu  Sat Jul 15 09:20:15 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20117
	for <DHC-ARCHIVE@odin.ietf.org>; Sat, 15 Jul 2000 09:20:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6FDHHW11215;
	Sat, 15 Jul 2000 09:17:17 -0400 (EDT)
Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6FDHBW12240;
	Sat, 15 Jul 2000 09:17:11 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (pm3mi2-28.uplink.net [209.173.86.77])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA14940;
	Sat, 15 Jul 2000 09:17:10 -0400 (EDT)
Message-Id: <4.3.1.2.20000713200826.00b92e70@funnel.cisco.com>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 13 Jul 2000 20:12:27 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: DHC WG meetings in Pittsburgh
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: droms@bucknell.edu
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

As posted in the *DRAFT* agenda, the DHC WG will meet Monday evening and 
Tuesday morning in Pittsburgh.  Tentatively, the WG will discuss DHCPv4 
issues in the first meeting and DHCPv6 issues in the second meeting.  See 
the schedule below for a list of other WGs meeting at the same time.  If 
you have a conflict, let me know.

Also, please contact me as soon as possible with any requests for agenda time.

- Ralph

MONDAY, July 31, 2000
1930-2200  Evening Sessions

APP  spatial	Spatial Location BOF
INT  dhc	Dynamic Host Configuration WG
INT  ipcdn	IP Over Cable Data Network WG
OPS  mboned	MBONE Depoloyement WG
SEC  ipsra	IP Security Remote Access WG
TSV  diffserv	Differentiated Services WG
TSV  mmusic	Multiparty Multimedia Session Control WG
			

TUESDAY, August 1, 2000
0900-1130  Morning Sessions

APP  vpim	Voice Profile for Internet Mail WG
INT  dhc	Dynamic Host Configuration WG
OPS  snmpconf	Configuration Management with SNMP WG
RTG  pim	Protocol Independent Multicast WG	
SEC  pkix	Public-Key Infrastructure (X.509) WG
TSV  enum	Telephone Number Mapping WG
TSV  issll	Integrated Services over Specific Link Layers WG
TSV  nfsv4	Network File System Version 4 WG



From owner-dhcp-v4@bucknell.edu  Mon Jul 17 06:43:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26627
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 17 Jul 2000 06:43:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6HAd1W17631;
	Mon, 17 Jul 2000 06:39:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6HAcxW32282
	for <dhcp-v4@bucknell.edu>; Mon, 17 Jul 2000 06:39:00 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24550;
	Mon, 17 Jul 2000 06:38:58 -0400 (EDT)
Message-Id: <200007171038.GAA24550@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-loadb-02.txt
Date: Mon, 17 Jul 2000 06:38:58 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: DHC load balancing algorithm
	Author(s)	: B. Volz, S. Gonczi, T. Lemon, R. Stevens
	Filename	: draft-ietf-dhc-loadb-02.txt
	Pages		: 9
	Date		: 14-Jul-00
	
This draft proposes a method of algorithmic load balancing. It enables
multiple, cooperating servers to decide which one should service a
client, without exchanging any information beyond initial configuration.
The server selection is based on the servers hashing client MAC
addresses, when multiple DHCP servers are available to service DHCP
clients. The benefits are similar to those enumerated in [SSO-03], but
this draft does not require modifications to existing DHCP clients. The
same method is proposed to select the target server of a forwarding
agent such as a BOOTP relay.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-loadb-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-loadb-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-loadb-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000714142527.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-loadb-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-loadb-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000714142527.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Mon Jul 17 06:45:38 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27281
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 17 Jul 2000 06:45:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6HAgvW19661;
	Mon, 17 Jul 2000 06:42:57 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6HAd4W20327
	for <dhcp-v4@bucknell.edu>; Mon, 17 Jul 2000 06:39:04 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24587;
	Mon, 17 Jul 2000 06:39:03 -0400 (EDT)
Message-Id: <200007171039.GAA24587@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-new-opt-msg-02.txt
Date: Mon, 17 Jul 2000 06:39:02 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Procedure for Defining New DHCP Options and Message 
                          Types
	Author(s)	: R. Droms
	Filename	: draft-ietf-dhc-new-opt-msg-02.txt
	Pages		: 7
	Date		: 14-Jul-00
	
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network.
Configuration parameters and other control information are carried in
tagged data items that are stored in the 'options' field of the DHCP
message.  The data items themselves are also called 'options.'
DHCP protocol messages are identified by the 'DHCP Message Type'
option (option code 51).  Each message type is defined by the data
value carried in the 'DHCP Message Type' option.
New DHCP options and message types may be defined after the
publication of the DHCP specification to accommodate requirements for
conveyance of new configuration parameters or to accommodate new
protocol semantics. This document describes the procedure for
defining new DHCP options and message types.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-new-opt-msg-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-new-opt-msg-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-new-opt-msg-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000714142536.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-new-opt-msg-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-new-opt-msg-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000714142536.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Mon Jul 17 13:24:40 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10404
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 17 Jul 2000 13:24:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6HHJmW17417;
	Mon, 17 Jul 2000 13:19:48 -0400 (EDT)
Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6HHJYW26137
	for <dhcp-v4@bucknell.edu>; Mon, 17 Jul 2000 13:19:34 -0400 (EDT)
Received: (qmail 12367 invoked from network); 17 Jul 2000 17:19:33 -0000
Received: from dnai-216-15-7-195.cust.dnai.com (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 17 Jul 2000 17:19:33 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt 
Date: Mon, 17 Jul 2000 10:19:42 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNOEIECEAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <200007141649.JAA00555@grosse.bisbee.fugue.com>
Reply-To: rbhibbs@ultraDNS.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

[Ted Lemon]
> The user class option was originally intended to be something
> where the user typed in a user class and got different options
> on that basis, probably as documented by the system administration
> staff.  It has no authentication.   You can't use it as a
> credential - if you have to look the credential up on the server,
> there's no point in the client sending it.

[Barr Hibbs]
I suggest thinking about this in business terms:  a system administrator
might choose to organize their clients in several different ways to simplify
their ability to understand and configure them for their operating
environment.

For example, older clients probably do not include any sort of machine
readable serial number (useful for inventory purchases), while newer systems
do.  Is it useful to group older machines in one vendor class and newer
machines in another?  It certainly may be for some implementations.

Likewise, in an automatic call distributor (ACD) application, an
ACD-attached client may need to use a DNS server integrated with the ACD, so
a User Class Identifier that categorizes clients as belonging to the user
class of ACD-attached clients or to a general class would be quite useful.

Don't obscure the purpose of the class identifier by changing it into some
sort of authenticator.

[Ted]
> It is also useful to use the user class option to say where you're
> located, so you get the right printer.

[Barr]
...another useful application of the User Class Identifier....

[Ted]
> So I think it's perfectly legitimate to use these as examples in
> the draft, although you'll spend less time arguing with security
> people if you don't mention any access control mechanism that
> depends on the honor system.

[Barr]
Actually, any discussion of how to use a DHCP option to address a "problem"
in the routing or security areas is bound to draw argument from the other
areas.

--Barr



From owner-dhcp-v4@bucknell.edu  Mon Jul 17 13:54:36 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10403
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 17 Jul 2000 13:24:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6HHL1W10786;
	Mon, 17 Jul 2000 13:21:01 -0400 (EDT)
Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6HHJYW18419
	for <dhcp-v4@bucknell.edu>; Mon, 17 Jul 2000 13:19:34 -0400 (EDT)
Received: (qmail 12371 invoked from network); 17 Jul 2000 17:19:33 -0000
Received: from dnai-216-15-7-195.cust.dnai.com (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 17 Jul 2000 17:19:33 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt 
Date: Mon, 17 Jul 2000 10:19:43 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNAEIFCEAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <D3EA66988D05D411BFFB00A0C9899382468134@honts333.homeoffice.wal-mart.com>
Reply-To: rbhibbs@ultraDNS.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

[Ted Lemon]
> > You can't use it as a credential - if you have to look the
> > credential up on the server, there's no point in the
> > client sending it.

[Nathan Lane]
> I actually hadn't intended to imply I was going to use it as a
> credential.  In a situation where a user class is valid on
> network A, but not network B, there would have to be a mechanism
> to choose not to apply the user class.
>
> Would it be a bad thing to validate the user class for
> applicability at least?

[Barr Hibbs]
In general, this is an implementation decision:  what to do when an unknown
User Class Identifier is presented?  This is quite important when trying to
build a robust server implementation, but very difficult to completely
specify in an RFC.  While we could try to insert language in every RFC
covering the protocol and options requiring servers to adequately cover all
cases of valid and invalid (or unknown) values for options, but that would
be largely hollow.

If anyone can offer some practical wording for handling these cases, but
which does not unduly restrict current or future implementors by
overspecifying, I would definitely support its inclusion.

--Barr



From owner-dhcp-v4@bucknell.edu  Mon Jul 17 13:54:36 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10405
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 17 Jul 2000 13:24:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6HHLSW19249;
	Mon, 17 Jul 2000 13:21:28 -0400 (EDT)
Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6HHJYW32666
	for <dhcp-v4@bucknell.edu>; Mon, 17 Jul 2000 13:19:34 -0400 (EDT)
Received: (qmail 12363 invoked from network); 17 Jul 2000 17:19:33 -0000
Received: from dnai-216-15-7-195.cust.dnai.com (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 17 Jul 2000 17:19:33 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt
Date: Mon, 17 Jul 2000 10:19:42 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNMEIECEAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <D3EA66988D05D411BFFB00A0C9899382468132@honts333.homeoffice.wal-mart.com>
Reply-To: rbhibbs@ultraDNS.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

[Bernard Aboba]
>> DHCP isn't an access control mechanism, even with authenticated
>> DHCP;  the user can choose their own static address and thereby
>> get around any rules you impose.

[Nathan Lane]
> Not necessarily.  If the DHCP server writes the access list in
> the router or uses other means to limit the ability to route
> addresses not assigned by the DHCP server.  This doesn't prevent
> LAN access, of course, unless the DHCP server also dynamically
> writes VLAN information into the switch.

[Barr Hibbs]
Are you proposing to write a new Internet-Draft to support DHCP server to
router or switch updates, Nathan?  While that is an interesting idea that
certainly deserves review and comment, I think it strays pretty far from the
purpose of the User Class Identifier.

I have always seen a need for finer classification of DHCP clients than the
Vendor Class Identifier provided, going all the way back to when Glenn Stump
first proposed this option:  in fact, depending on the business organization
and processes of an enterprise, there may be other useful classifiers that
could be proposed.

But back to the question of whether this option could be used to alter
router or switch configurations:  that discussion opens a whole new thread
that probably should be introduced simultaneously in the routing aread.
Let's keep the User Class Identifier focussed on what I believe to be its
original purpose as another useful way to classify clients so that an
administrator can deliver different sets of options based on some
identifiable characteristic.

[Bernard]
> > Therefore the user can claim any userclass they want unless
> > the DHCP server intends to verify the userclass assignment
> > based on the client identifier.

[Nathan]
> I would certainly do that.  The draft doesn't enforce any
> specific server behavior on this option.

[Barr]
We have long had an unwritten principle for DHCP options, that one option
generally does not depend on the value of another.  While that occasionally
leads to curious situations such as the FQDN in the DHCP-DNS options not
being required to bear any relationship to options 12 and 15, I would
strongly question any requirement for cross-validation of the User Class
Identifier with the Client Identifier before accepting it as the desired
mode of operation, and especially as I see immediate application for a User
Class Identifier without any relationship to routing, it would have to be a
very strong argument to win my support.

--Barr



From owner-dhcp-v4@bucknell.edu  Mon Jul 17 13:56:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25338
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 17 Jul 2000 13:56:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6HHs3W22826;
	Mon, 17 Jul 2000 13:54:03 -0400 (EDT)
Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6HHrxW18066
	for <dhcp-v4@bucknell.edu>; Mon, 17 Jul 2000 13:53:59 -0400 (EDT)
Received: from fwnts001.wal-mart.com ([146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 3XSVSFFQ; Mon, 17 Jul 2000 12:58:13 -0500
Received: from honts388.homeoffice.wal-mart.com by fwnts001.wal-mart.com
          via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 17 Jul 2000 17:53:44 UT
Received: from honts305.homeoffice.wal-mart.com (unverified) by honts388.homeoffice.wal-mart.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Ta1ad84531484d75a7f7b4@honts388.homeoffice.wal-mart.com> for <dhcp-v4@bucknell.edu>;
 Mon, 17 Jul 2000 12:53:43 -0500
Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21)
	id <38JC29J3>; Mon, 17 Jul 2000 12:53:43 -0500
Message-ID: <D3EA66988D05D411BFFB00A0C989938246813A@honts333.homeoffice.wal-mart.com>
From: Nathan Lane <ndlane@wal-mart.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: draft-ietf-dhc-userclass-08.txt
Date: Mon, 17 Jul 2000 12:53:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Reply-To: ndlane@wal-mart.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> [Barr Hibbs]
> Are you proposing to write a new Internet-Draft to support DHCP server to
> router or switch updates, Nathan?  
> 
	Not at the moment - I've got to try it first!  However, it is one
potential way to prevent the type of usage that Bernard implied could not be
prevented.

> Let's keep the User Class Identifier focussed on what I believe to be its
> original purpose as another useful way to classify clients so that an
> administrator can deliver different sets of options based on some
> identifiable characteristic.
> 
	The option to give different sets of options...including IP address.
Again, though, that use does not need to be included in the draft if it
stirs up controversey.

> [Bernard]
> > > Therefore the user can claim any userclass they want unless
> > > the DHCP server intends to verify the userclass assignment
> > > based on the client identifier.
> 
> [Nathan]
> > I would certainly do that.  The draft doesn't enforce any
> > specific server behavior on this option.
> 
> [Barr]
> We have long had an unwritten principle for DHCP options, that one option
> generally does not depend on the value of another.  
> 
	[Nathan Lane]  I would say "make use of" rather than "depends on".
In the draft, it is still open to ignore the user class if the server cannot
make proper use of it.  I'm not suggesting codifying in a draft the behavior
I intend on implementing, which is ignoring the user class if it will break
the client OR doesn't meet some operational criteria that I'd like control
over.

	Maybe I'm just too focused on finding a way to use and integrate the
products of this working group (to solve real-world problems) when they
reach RFC status rather than on defining the option in a way that will get
the draft to that status.

	-Nathan




**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************



From owner-dhcp-v4@bucknell.edu  Tue Jul 18 06:38:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15045
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 18 Jul 2000 06:38:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6IAWdW12455;
	Tue, 18 Jul 2000 06:32:39 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6IAWYW07070
	for <dhcp-v4@bucknell.edu>; Tue, 18 Jul 2000 06:32:34 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12189;
	Tue, 18 Jul 2000 06:32:34 -0400 (EDT)
Message-Id: <200007181032.GAA12189@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-nsso-05.txt
Date: Tue, 18 Jul 2000 06:32:33 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: The Name Service Search Option for DHCP
	Author(s)	: C. Smith
	Filename	: draft-ietf-dhc-nsso-05.txt
	Pages		: 4
	Date		: 17-Jul-00
	
This document defines a new DHCP option which is passed from the DHCP
Server to the DHCP Client to specify the order in which name services
should be consulted when resolving hostnames and other information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-nsso-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-nsso-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-nsso-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000717145332.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-nsso-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-nsso-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000717145332.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Fri Jul 21 09:11:24 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10300
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 21 Jul 2000 09:11:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6LD6lW15090;
	Fri, 21 Jul 2000 09:06:47 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6LD6eW29357
	for <dhcp-v4@bucknell.edu>; Fri, 21 Jul 2000 09:06:44 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07284;
	Fri, 21 Jul 2000 09:06:38 -0400 (EDT)
Message-Id: <200007211306.JAA07284@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-subnet-option-06.txt
Date: Fri, 21 Jul 2000 09:06:38 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: The IPv4 Subnet Selection Option for DHCP
	Author(s)	: G. Waters
	Filename	: draft-ietf-dhc-subnet-option-06.txt
	Pages		: 6
	Date		: 20-Jul-00
	
This memo defines a new DHCP option for selecting the subnet on which 
to allocate an address. This option would override a DHCP server's 
normal methods of selecting the subnet on which to allocate an address 
for a client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-option-06.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-subnet-option-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-subnet-option-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000720141310.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-subnet-option-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-subnet-option-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000720141310.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Fri Jul 21 09:12:16 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10821
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 21 Jul 2000 09:12:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6LDBUW30776;
	Fri, 21 Jul 2000 09:11:30 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6LD6jW26515
	for <dhcp-v4@bucknell.edu>; Fri, 21 Jul 2000 09:06:45 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07231;
	Fri, 21 Jul 2000 09:06:34 -0400 (EDT)
Message-Id: <200007211306.JAA07231@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-failover-07.txt
Date: Fri, 21 Jul 2000 09:06:34 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: DHCP Failover Protocol
	Author(s)	: R. Droms, K. Kinnear, M. Stapp, B. Volz, 
                          S. Gonczi, G. Rabil, M. Dooley, A. Kapur
	Filename	: draft-ietf-dhc-failover-07.txt
	Pages		: 121
	Date		: 20-Jul-00
	
DHCP [RFC 2131] allows for multiple servers to be operating on a
single network.  Some sites are interested in running multiple
servers in such a way so as to provide redundancy in case of server
failure.  In order for this to work reliably, the cooperating primary
and secondary servers must maintain a consistent database of the
lease information.  This implies that servers will need to coordinate
any and all lease activity so that this information is synchronized
in case of failover.
This document defines a protocol to provide such synchronization
between two servers.  One server is designated the 'primary' server,
the other is the 'secondary' server.  This document also describes a
way to integrate the failover protocol with the DHCP load balancing
approach.
This document is a substantial reorganization as well as a technical
and editorial revision of draft-ietf-dhc-failover-05.txt.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-07.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-failover-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-failover-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000720141301.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-failover-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-failover-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000720141301.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Mon Jul 24 06:40:01 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09948
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 24 Jul 2000 06:40:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6OAYvi05450;
	Mon, 24 Jul 2000 06:34:58 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6OAYqi04965
	for <dhcp-v4@bucknell.edu>; Mon, 24 Jul 2000 06:34:52 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07769;
	Mon, 24 Jul 2000 06:34:46 -0400 (EDT)
Message-Id: <200007241034.GAA07769@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-fqdn-option-00.txt
Date: Mon, 24 Jul 2000 06:34:45 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: The DHCP Client FQDN Option
	Author(s)	: M. Stapp, Y. Rekhter
	Filename	: draft-ietf-dhc-fqdn-option-00.txt
	Pages		: 14
	Date		: 21-Jul-00
	
DHCP provides a powerful mechanism for IP host configuration.
However, the configuration capability provided by DHCP does not
include updating DNS, and specifically updating the name to address
and address to name mappings maintained in the DNS.
This document specifies a DHCP option which can be used to exchange
information about a DHCP client's fully-qualified domain name, or
'FQDN'.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-fqdn-option-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-fqdn-option-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000721171408.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-fqdn-option-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-fqdn-option-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000721171408.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Mon Jul 24 21:26:52 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08303
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 24 Jul 2000 21:26:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6P1Nei28348;
	Mon, 24 Jul 2000 21:23:40 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6P1NYi25069;
	Mon, 24 Jul 2000 21:23:34 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-73.cisco.com [161.44.133.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA20347; Mon, 24 Jul 2000 12:50:52 -0400 (EDT)
Message-Id: <4.3.1.2.20000724124050.00b13d90@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Jul 2000 12:48:27 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: DHC WG meetings in Pittsburgh
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: rdroms@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Here is the tentative agenda for the DHC WG meetings in Pittsburgh.  If you 
scheduled a slot and don't appear on the agenda, or if you would like to 
schedule a slot, please contact me.

- Ralph Droms

7/31, 1930-2200

             Topic                       Presenter
             =====                       =========
WG charter and milestones review       Ralph Droms

DHCP LDAP schema                       Bernie Volz

DHCP load balancing                    Bernie Volz

DRCP                                   Subir Das

DHCP MIB                               Barr Hibbs

Kerberos authentication                Lalwaney Poornima

DNS-DHCP interaction                   Mark Stapp

Failover                               Bernie Volz



8/1, 0900-1130

             Topic                       Presenter
             =====                       =========
DHCPv6 draft review                    Jim Bound,
                                        Mike Carney,
                                        Charlie Perkins





From owner-dhcp-v6@bucknell.edu  Mon Jul 24 21:26:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08326
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 24 Jul 2000 21:26:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6P1Nei26370;
	Mon, 24 Jul 2000 21:23:41 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6P1NYi25069;
	Mon, 24 Jul 2000 21:23:34 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-73.cisco.com [161.44.133.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA20347; Mon, 24 Jul 2000 12:50:52 -0400 (EDT)
Message-Id: <4.3.1.2.20000724124050.00b13d90@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Jul 2000 12:48:27 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: DHC WG meetings in Pittsburgh
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Here is the tentative agenda for the DHC WG meetings in Pittsburgh.  If you 
scheduled a slot and don't appear on the agenda, or if you would like to 
schedule a slot, please contact me.

- Ralph Droms

7/31, 1930-2200

             Topic                       Presenter
             =====                       =========
WG charter and milestones review       Ralph Droms

DHCP LDAP schema                       Bernie Volz

DHCP load balancing                    Bernie Volz

DRCP                                   Subir Das

DHCP MIB                               Barr Hibbs

Kerberos authentication                Lalwaney Poornima

DNS-DHCP interaction                   Mark Stapp

Failover                               Bernie Volz



8/1, 0900-1130

             Topic                       Presenter
             =====                       =========
DHCPv6 draft review                    Jim Bound,
                                        Mike Carney,
                                        Charlie Perkins





From owner-dhcp-v6@bucknell.edu  Mon Jul 24 21:27:14 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08449
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 24 Jul 2000 21:27:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6P1Oii28704;
	Mon, 24 Jul 2000 21:24:44 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6P1NZi28915;
	Mon, 24 Jul 2000 21:23:35 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-73.cisco.com [161.44.133.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA21843; Mon, 24 Jul 2000 13:02:06 -0400 (EDT)
Message-Id: <4.3.1.2.20000724125237.00b142a0@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Jul 2000 13:04:12 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: WG charter review
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I've added an agenda item for Pittsburgh to review the WG charter and 
milestones.  Included below is our current charter (which is obviously 
sadly out of date).  If you have any suggestions, corrections (yes, I know 
there are five main objectives, not four) or other comments you'd like to 
make, please feel free to post them prior to next week's meeting.  In 
Pittsburgh, we'll take 30 minutes to draft an updated charter.

- Ralph Droms


Description of Working Group:


This working group has developed DHCP for automated allocation,
configuration and management of IP addresses and TCP/IP protocol stack
parameters.  DHCP is currently a "Draft Standard" (RFC2131, RFC2132).
The working group now has four main objectives:

* Revise and submit the DHCP specification for acceptance as a Full
   Standard

* Develop a roadmap for the review and acceptance of new options,
   define a new option syntax, develop an accurate list of assigned
   option codes and identify option codes that can be safely reassigned

* Develop a specification for DHCP for IPv6

* Develop an inter-server communication for coordination of multiple
   servers

* Review new options for DHCP, as deemed appropriate by the working
   group chair and/or the Internet area directors; specific options
   currently under review in the working group include:

   o Mechanisms for the authentication of clients and servers

   o Interaction between DHCP and DNS dynamic update protocol

   o Definition of a DHCP MIB for management of DHCP servers through SNMP

   O Definition of an LDAP schema to provide a standardized format for
     the storage and retrieval of DHCP information, primarily
     configuration and lease data; this schema will be developed in
     coordination with the Policy Frameworks Working Group as
     appropriate.

   o Options through which DHCP relay agents can pass information to DHCP
     servers

   o Other options: user class, server selection, domain search


Goals and Milestones:

Jun 1999    Submit Internet-Draft on subnet selection option in time
             for Oslo IETF.

Jun 1999    Submit Internet-Draft on LDAP schema for DHCP in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on DHCP authentication in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on failover protocol in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on relay agent options in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on DHCP-DNS interaction in time for
             Oslo IETF.

Jul 1999    Submit Internet-Draft on DHCP authentication for WG last
             call.

Jul 1999    Develop plan for review of DHCP specification and
             acceptance as Internet Standard.

Sep 1999    Submit DHCP server MIB specification for WG
             last call.

Sep 1999    Submit subnet selection option specification
             for WG last call.

Sep 1999    Interim meeting on failover protocol

Nov 1999    Submit DHCP server MIB specification for IESG
             consideration as a Proposed Standard.

Nov 1999    Submit LDAP schema specification for WG last
             call.

Nov 1999    Final review version of failover protocol specification

Mar 2000    Submit LDAP schema specification for IESG
             consideration as a Proposed Standard.

Mar 2000    Submit failover protocol specification for WG last call




From owner-dhcp-v4@bucknell.edu  Mon Jul 24 22:05:29 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08304
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 24 Jul 2000 21:26:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6P1QLi29837;
	Mon, 24 Jul 2000 21:26:21 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6P1NZi28915;
	Mon, 24 Jul 2000 21:23:35 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-73.cisco.com [161.44.133.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA21843; Mon, 24 Jul 2000 13:02:06 -0400 (EDT)
Message-Id: <4.3.1.2.20000724125237.00b142a0@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 24 Jul 2000 13:04:12 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: WG charter review
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: rdroms@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I've added an agenda item for Pittsburgh to review the WG charter and 
milestones.  Included below is our current charter (which is obviously 
sadly out of date).  If you have any suggestions, corrections (yes, I know 
there are five main objectives, not four) or other comments you'd like to 
make, please feel free to post them prior to next week's meeting.  In 
Pittsburgh, we'll take 30 minutes to draft an updated charter.

- Ralph Droms


Description of Working Group:


This working group has developed DHCP for automated allocation,
configuration and management of IP addresses and TCP/IP protocol stack
parameters.  DHCP is currently a "Draft Standard" (RFC2131, RFC2132).
The working group now has four main objectives:

* Revise and submit the DHCP specification for acceptance as a Full
   Standard

* Develop a roadmap for the review and acceptance of new options,
   define a new option syntax, develop an accurate list of assigned
   option codes and identify option codes that can be safely reassigned

* Develop a specification for DHCP for IPv6

* Develop an inter-server communication for coordination of multiple
   servers

* Review new options for DHCP, as deemed appropriate by the working
   group chair and/or the Internet area directors; specific options
   currently under review in the working group include:

   o Mechanisms for the authentication of clients and servers

   o Interaction between DHCP and DNS dynamic update protocol

   o Definition of a DHCP MIB for management of DHCP servers through SNMP

   O Definition of an LDAP schema to provide a standardized format for
     the storage and retrieval of DHCP information, primarily
     configuration and lease data; this schema will be developed in
     coordination with the Policy Frameworks Working Group as
     appropriate.

   o Options through which DHCP relay agents can pass information to DHCP
     servers

   o Other options: user class, server selection, domain search


Goals and Milestones:

Jun 1999    Submit Internet-Draft on subnet selection option in time
             for Oslo IETF.

Jun 1999    Submit Internet-Draft on LDAP schema for DHCP in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on DHCP authentication in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on failover protocol in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on relay agent options in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on DHCP-DNS interaction in time for
             Oslo IETF.

Jul 1999    Submit Internet-Draft on DHCP authentication for WG last
             call.

Jul 1999    Develop plan for review of DHCP specification and
             acceptance as Internet Standard.

Sep 1999    Submit DHCP server MIB specification for WG
             last call.

Sep 1999    Submit subnet selection option specification
             for WG last call.

Sep 1999    Interim meeting on failover protocol

Nov 1999    Submit DHCP server MIB specification for IESG
             consideration as a Proposed Standard.

Nov 1999    Submit LDAP schema specification for WG last
             call.

Nov 1999    Final review version of failover protocol specification

Mar 2000    Submit LDAP schema specification for IESG
             consideration as a Proposed Standard.

Mar 2000    Submit failover protocol specification for WG last call




From owner-dhcp-v4@bucknell.edu  Tue Jul 25 06:38:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24652
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 25 Jul 2000 06:38:11 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6PAWxi08896;
	Tue, 25 Jul 2000 06:32:59 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6PAWri06871
	for <dhcp-v4@bucknell.edu>; Tue, 25 Jul 2000 06:32:53 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22236;
	Tue, 25 Jul 2000 06:32:51 -0400 (EDT)
Message-Id: <200007251032.GAA22236@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-ddns-resolution-00.txt
Date: Tue, 25 Jul 2000 06:32:51 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Resolution of DNS Name Conflicts Among DHCP Clients
	Author(s)	: M. Stapp
	Filename	: draft-ietf-dhc-ddns-resolution-00.txt
	Pages		: 12
	Date		: 24-Jul-00
	
DHCP provides a powerful mechanism for IP host configuration.
However, the configuration capability provided by DHCP does not
include updating DNS(RFC1034[1], RFC1035[2]), and specifically
updating the name to address and address to name mappings maintained
in the DNS.
The 'Client FQDN Option'[14] specifies the client FQDN option,
through which DHCP clients and servers can exchange information
about client FQDNs.  This document describes techniques for the
resolution of DNS name conflicts among DHCP clients.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-ddns-resolution-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000724141706.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-ddns-resolution-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000724141706.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Tue Jul 25 09:25:52 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14405
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 25 Jul 2000 09:25:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6PDLLi20712;
	Tue, 25 Jul 2000 09:21:21 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6PDLFi02587
	for <dhcp-v4@bucknell.edu>; Tue, 25 Jul 2000 09:21:15 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <PNZ51062>; Tue, 25 Jul 2000 09:20:56 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBF78@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: WG charter review
Date: Tue, 25 Jul 2000 09:20:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph:

Regarding the charter and the schema and LOADB, how about the following
milestones:

SCHEMA:
Sep 00	Submit revised Internet-Draft on LDAP schema for DHCP.

Nov 00	Submit LDAP schema specification for WG last call.

Jan 01	Submit LDAP schema specification for IESG consideration as a
		Proposed Standard.

LOADB:
Aug 00	Submit Load Balancing specification for WG last call.

Oct 00	Submit Load Balancing specification for IESG consideration
		as a Proposed Standard.

I'm sure Kim will have a proposal for FAILOVER, but here's my 2 cents:

Sep 00	Interim meeting (conference call) on failover protocol

Nov 00	Submit Internet-Draft on LDAP schema for DHCP in time for
		San Diego IETF

Jan 01	Final review version of failover protocol specification

Feb 01	Submit failover protocol specification for WG last call

Apr 01	Submit failover protocol for IESG consideration as a
		Proposed Standard.


I suspect that the above timetables are somewhat aggressive, but I think it
is better to err on that side to push us into doing it.


BTW: Has the WG discussed whether to take on Dynamic Registration and
Configuration Protocol (DRCP) by A. McAuley, S. Das, S. Madhani, S. Baba, Y.
Shobatake, draft-itsumo-drcp-01.txt. (Haven't read this version yet so can't
comment on its merit.)

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, July 24, 2000 1:04 PM
To: DHCPv4 discussion list
Subject: WG charter review


I've added an agenda item for Pittsburgh to review the WG charter and 
milestones.  Included below is our current charter (which is obviously 
sadly out of date).  If you have any suggestions, corrections (yes, I know 
there are five main objectives, not four) or other comments you'd like to 
make, please feel free to post them prior to next week's meeting.  In 
Pittsburgh, we'll take 30 minutes to draft an updated charter.

- Ralph Droms


Description of Working Group:


This working group has developed DHCP for automated allocation,
configuration and management of IP addresses and TCP/IP protocol stack
parameters.  DHCP is currently a "Draft Standard" (RFC2131, RFC2132).
The working group now has four main objectives:

* Revise and submit the DHCP specification for acceptance as a Full
   Standard

* Develop a roadmap for the review and acceptance of new options,
   define a new option syntax, develop an accurate list of assigned
   option codes and identify option codes that can be safely reassigned

* Develop a specification for DHCP for IPv6

* Develop an inter-server communication for coordination of multiple
   servers

* Review new options for DHCP, as deemed appropriate by the working
   group chair and/or the Internet area directors; specific options
   currently under review in the working group include:

   o Mechanisms for the authentication of clients and servers

   o Interaction between DHCP and DNS dynamic update protocol

   o Definition of a DHCP MIB for management of DHCP servers through SNMP

   O Definition of an LDAP schema to provide a standardized format for
     the storage and retrieval of DHCP information, primarily
     configuration and lease data; this schema will be developed in
     coordination with the Policy Frameworks Working Group as
     appropriate.

   o Options through which DHCP relay agents can pass information to DHCP
     servers

   o Other options: user class, server selection, domain search


Goals and Milestones:

Jun 1999    Submit Internet-Draft on subnet selection option in time
             for Oslo IETF.

Jun 1999    Submit Internet-Draft on LDAP schema for DHCP in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on DHCP authentication in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on failover protocol in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on relay agent options in time for
             Oslo IETF.

Jun 1999    Submit Internet-Draft on DHCP-DNS interaction in time for
             Oslo IETF.

Jul 1999    Submit Internet-Draft on DHCP authentication for WG last
             call.

Jul 1999    Develop plan for review of DHCP specification and
             acceptance as Internet Standard.

Sep 1999    Submit DHCP server MIB specification for WG
             last call.

Sep 1999    Submit subnet selection option specification
             for WG last call.

Sep 1999    Interim meeting on failover protocol

Nov 1999    Submit DHCP server MIB specification for IESG
             consideration as a Proposed Standard.

Nov 1999    Submit LDAP schema specification for WG last
             call.

Nov 1999    Final review version of failover protocol specification

Mar 2000    Submit LDAP schema specification for IESG
             consideration as a Proposed Standard.

Mar 2000    Submit failover protocol specification for WG last call



From owner-dhcp-v4@bucknell.edu  Tue Jul 25 10:27:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04470
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 25 Jul 2000 10:27:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6PEN8i05415;
	Tue, 25 Jul 2000 10:23:08 -0400 (EDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6PEMui02169
	for <dhcp-v4@bucknell.edu>; Tue, 25 Jul 2000 10:22:56 -0400 (EDT)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA23916
	for <dhcp-v4@bucknell.edu>; Tue, 25 Jul 2000 10:22:39 -0400
Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA04018
	for <dhcp-v4@bucknell.edu>; Tue, 25 Jul 2000 10:22:40 -0400
Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA09409 for <dhcp-v4@bucknell.edu>; Tue, 25 Jul 2000 10:21:02 -0400
Message-Id: <200007251421.KAA09409@ludwigia.raleigh.ibm.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: FWD: I-D ACTION:draft-itsumo-drcp-01.txt
Date: Tue, 25 Jul 2000 10:21:01 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Anyone had a look at this one? Comments?

Thomas

------- Forwarded Message

From: Internet-Drafts@ietf.org
To: IETF-Announce: ;
CC: dhc-v4@bucknell.edu
Date: Tue, 25 Jul 2000 06:32:37 -0400
Subject: I-D ACTION:draft-itsumo-drcp-01.txt
Reply-to: Internet-Drafts@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Dynamic Registration and Configuration Protocol (DRCP)
	Author(s)	: A. McAuley, S. Das, S. Madhani, 
                          S. Baba, Y. Shobatake
	Filename	: draft-itsumo-drcp-01.txt
	Pages		: 15
	Date		: 24-Jul-00
	
The Dynamic Host  Configuration  Protocol (DHCP) provides a framework
for  passing  configuration  information  to hosts  [DHC].  DHCP was,
however,  designed  for hosts on a fixed  LAN, not for nodes  roaming
among commercial  wireless networks.  A Mobile IP [MIP] Foreign Agent
gives some  powerful  plug and play  capability  for  roaming  hosts,
especially  when  combined  with some recent  proposals  [e.g., MIPA,
MIPC, MIPD, MIPN, HAW, CEL, TIA].  Mobile IP  functionality,  however
is not  always  needed  and  for  some  dynamic  networks  it  may be
undesirable to use Foreign Agents.  This draft proposes a lightweight
dynamic  configuration  protocol, called the Dynamic Registration and
Configuration  Protocol  (DRCP).  DRCP borrows  heavily from DHCP and
can switch to using DHCP protocol if only DHCP servers are present in
the  network;  but adds  features  critical  to roaming  users.  Most
importantly,  DRCP  allows  rapid  configuration  by  moving  address
consistency  checking  from the  critical  path.  Other new  features
allow:  a) clients to know when to get a new address  independent  of
the layer-2 access  technology,  b) efficient use of scarce  wireless
bandwidth, c) clients to be routers, d) dynamic  addition or deletion
of address  pools to any DRCP node, and e) message  exchange  without
broadcast.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-itsumo-drcp-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-itsumo-drcp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-itsumo-drcp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000724141850.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-itsumo-drcp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-itsumo-drcp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000724141850.I-D@ietf.org>

--OtherAccess--

--NextPart--


------- End of Forwarded Message



From owner-dhcp-v4@bucknell.edu  Tue Jul 25 12:05:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09769
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 25 Jul 2000 12:05:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6PG2ti29432;
	Tue, 25 Jul 2000 12:02:55 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6PG2Zi27385
	for <dhcp-v4@bucknell.edu>; Tue, 25 Jul 2000 12:02:35 -0400 (EDT)
Received: from esvir06nok.ntc.nokia.com (esvir06nok.ntc.nokia.com [131.228.10.155])
	by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e6PG1wR26398
	for <dhcp-v4@bucknell.edu>; Tue, 25 Jul 2000 19:02:19 +0300 (EET DST)
Received: from daebh02nok.americas.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e40a9bce4da02bbd81@esvir06nok.ntc.nokia.com>;
 Tue, 25 Jul 2000 19:01:42 +0300
Received: by daebh02nok with Internet Mail Service (5.5.2448.0)
	id <3VXA99WG>; Tue, 25 Jul 2000 11:01:41 -0500
Message-ID: <D1CFF66A2428D311B6320008C7C5668802215747@sdeis01nok>
From: Poornima.Lalwaney@nokia.com
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: draft-smedvinsky-dhc-kerbauth-01.txt
Date: Tue, 25 Jul 2000 11:01:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Poornima.Lalwaney@nokia.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi,

Sasha Medvinsky and myself will be presenting the following draft at the
Pittsburgh meeting next week and would like the WG comments.  The method
outlined in the draft decouples Kerberos Key Management exchange from the
authenticated DHCP exchange. The draft can be found at:


FILE {
http://search.ietf.org/internet-drafts/draft-smedvinsky-dhc-kerbauth-01.txt
}

title:	Kerberos V Authentication Mode for Uninitialized Clients

abstract:
	     The Dynamic Host Configuration Protocol (DHCP) [1] includes an
option that allows authentication of all DHCP messages, as specified
    in [2].  This document specifies a DHCP authentication mode based on
    Kerberos V tickets. This provides mutual authentication between a
    DHCP client and server, as well as authentication of all DHCP
    messages.                                                              

author: Sasha Medvinsky, Poornima Lalwaney

date:	07/10/2000

id:	draft-smedvinsky-dhc-kerbauth-01.txt


Comments, concerns, suggestions..all welcome.

Thanks,
Poornima Lalwaney

------------------------------
Poornima Lalwaney
Nokia
858-831-4727
poornima.lalwaney@nokia.com
-------------------------------



From owner-dhcp-v4@bucknell.edu  Tue Jul 25 18:15:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26317
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 25 Jul 2000 18:15:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6PMCAi20733;
	Tue, 25 Jul 2000 18:12:10 -0400 (EDT)
Received: from honts308.wal-mart.com (honts308.wal-mart.com [146.132.234.38])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6PMC0i22164
	for <dhcp-v4@bucknell.edu>; Tue, 25 Jul 2000 18:12:00 -0400 (EDT)
Received: from fwnts001.wal-mart.com ([146.132.235.8]) by honts308.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id PT6WBY13; Tue, 25 Jul 2000 17:19:10 -0500
Received: from honts388.homeoffice.wal-mart.com by fwnts001.wal-mart.com
          via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 25 Jul 2000 22:11:38 UT
Received: from honts305.homeoffice.wal-mart.com (unverified) by honts388.homeoffice.wal-mart.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Ta1ad84531484d9fc6f6ce@honts388.homeoffice.wal-mart.com>;
 Tue, 25 Jul 2000 17:11:38 -0500
Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21)
	id <PKDCT2VM>; Tue, 25 Jul 2000 17:11:38 -0500
Message-ID: <D3EA66988D05D411BFFB00A0C989938246815C@honts333.homeoffice.wal-mart.com>
From: Nathan Lane <ndlane@wal-mart.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: "'dhcp-v4@bucknell.edu'" <dhcp-v4@bucknell.edu>
Subject: RE: I-D ACTION:draft-itsumo-drcp-01.txt
Date: Tue, 25 Jul 2000 17:10:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Reply-To: ndlane@wal-mart.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

	-----Original Message-----
	From:	Thomas Narten [SMTP:narten@raleigh.ibm.com]
	Sent:	Tuesday, July 25, 2000 9:21 AM
	To:	DHCPv4 discussion list
	Subject:	FWD: I-D ACTION:draft-itsumo-drcp-01.txt

	Anyone had a look at this one? Comments?

	Thomas

I don't see a real need for it when taking into account the body of work
already on DHC's plate in regards to addressing the issues.  In the list of
issues with DHCP that make a new protocol required, many, if not most, of
the issues are already addressed or being rapdily addressed by DHC.  One
major assertion in the draft is that broadcast is not used as much in DRCP
as in DHCP when indeed it is used and with a potentially worse impact to the
network than the very few broadcasts that are used in DHCP.

Issue #1 "Rapid client configuration": there is no reason DHCP cannot
configure a client in milliseconds.  It requires less aversion to dangerous
situations (duplicate IP address assignment), but it is very possible since
the current wording indicates "SHOULD", not "MUST".

Issue #3 "Rapid client reconfiguration": There is a draft out for a
DHCPFORCERENEW message already.  However, this is the only issue that is
more difficult to solve.  A broadcast-able FORCERENEW would be useful, but
highly dangerous (as is the DRCP equivalent.)

Issue #4 in the list "Allowing clients to be routers" is only due to
unfortunate wording in the old 2131 which I believe we've all agreed to
strike from the revised version.

My issues: The danger of duplicate IP address assignment is much higher with
DRCP as clients do not check the assignment.  Is this worth it?  An entirely
new protocol requires entirely new servers and infrastructure.  Is this
worth it when there is something already 80% workable with possibly zero
changes to the core protocol and a few minor extensions that are handled in
the least disruptive manner?  I believe most of the requirements could be
addressed by Category One or Category two options (or guidelines C, D and E)
as in "draft-ietf-dhc-option-review-and-namespace-02.txt".  FORCERENEW is
the odd-man out but I think it does not actually change DHCP itself, just
adds some requirements to the client that could be implemented separately.

Also, in "draft-ietf-dhc-enhance-requirements-00.txt", it is stated that
DHCP clients go to sleep until lease times deem a wakeup.  This is not
necessary and is not specified anywhere to my knowledge.  A DRCP client in
sleep mode would have to still listen for DRCP_ADVERTISEMENTS.  I do not see
how his is different from a DHCP client listening for a DHCPFORCERENEW.

-Nathan Lane



**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************



From owner-dhcp-v4@bucknell.edu  Wed Jul 26 06:55:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05128
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 26 Jul 2000 06:55:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6QAoDi18639;
	Wed, 26 Jul 2000 06:50:13 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6QAo3i17861
	for <dhcp-v4@bucknell.edu>; Wed, 26 Jul 2000 06:50:03 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03370;
	Wed, 26 Jul 2000 06:50:01 -0400 (EDT)
Message-Id: <200007261050.GAA03370@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-new-opt-review-00.txt
Date: Wed, 26 Jul 2000 06:50:01 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: New Option Review Guidelines for DHCP
	Author(s)	: M. Carney
	Filename	: draft-ietf-dhc-new-opt-review-00.txt
	Pages		: 8
	Date		: 25-Jul-00
	
This document outlines deficiencies that have become evident since
RFC 2131 and RFC 2132 were published regarding the allocation of
new option codes, the review of drafts covering these new option
codes, and the availability of option codes for new parameters. The
document then presents proposals for correcting these deficiencies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-new-opt-review-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-new-opt-review-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-new-opt-review-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000725113112.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-new-opt-review-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-new-opt-review-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000725113112.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Wed Jul 26 13:44:50 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01705
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 26 Jul 2000 13:44:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6QHf0i10121;
	Wed, 26 Jul 2000 13:41:00 -0400 (EDT)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6QHeqi12377
	for <dhcp-v4@bucknell.edu>; Wed, 26 Jul 2000 13:40:52 -0400 (EDT)
Received: from earth.research.telcordia.com (earth [192.4.18.66])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6QHdLR03111;
	Wed, 26 Jul 2000 13:39:21 -0400 (EDT)
Sender: owner-dhcp-v4@bucknell.edu
Message-ID: <397F2248.36C20FBA@earth.research.telcordia.com>
Date: Wed, 26 Jul 2000 13:39:21 -0400
From: Tony McAuley <mcauley@earth.research.telcordia.com>
Organization: Telcordia
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 4.1.4 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
CC: subir@research.telcordia.com
Subject: Re: FWD: I-D ACTION:draft-itsumo-drcp-01.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: mcauley@earth.research.telcordia.com
X-Sender: mcauley@research.telcordia.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Nathan and Thomas,

We agree that we should keep the benefits of DHCP if possible. We
are prototyping DRCP in order to gain some experience in the wireless
configuration arena and bring these experiences to  the DHC-WG.
I hope our work will at least give added momentum to some changes
already underway  (e.g., adding a DHCPFORCERENEW), but also will
give rise to some new features (e.g., an advertisement message).

However, adding wireless features to DHCP will increase the message
size which is a concern in the wireless environment. For example,
a DISCOVER message is about 20-30 bytes in DRCP versus 236 bytes
in DHCP. Beyond the bandwidth issue, which we believe is important,
I agree that many of the "DRCP features" can be (and are being) added
to DHCP without affecting the core protocol (e.g., allowing routers,
fast configuration, or allowing dynamic changes of address pools).
Others can be done with minor extensions (e.g., add DHCPFORCERENEW
or to add options about roaming services). However, our DRCP
advertisement message (to detect movement to a new subnet and allow
a roaming node to unicast to a server) does change the core protocol.

To address the danger of not ARP checking, our DRCP server does
some background checking of addresses it is going to allocate.

Any comments?

Thanks
 Tony & Subir

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

Anthony J. McAuley                     email:
mcauley@research.telcordia.com
MCC 1C235B, Telcordia Technologies                    phone: +1 973 829
4698
445 South Street, Morristown, NJ 07960                  fax: +1 973 829
5888
----------------------------------------------------------------------------

> Subject: RE: I-D ACTION:draft-itsumo-drcp-01.txt
> Date: Tue, 25 Jul 2000 17:10:39 -0500
> From: Nathan Lane <ndlane@wal-mart.com>
> To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
> CC: "'dhcp-v4@bucknell.edu'" <dhcp-v4@bucknell.edu>
>
>         -----Original Message-----
>         From:   Thomas Narten [SMTP:narten@raleigh.ibm.com]
>         Sent:   Tuesday, July 25, 2000 9:21 AM
>         To:     DHCPv4 discussion list
>         Subject:        FWD: I-D ACTION:draft-itsumo-drcp-01.txt
>
>         Anyone had a look at this one? Comments?
>
>         Thomas
>
> I don't see a real need for it when taking into account the body of
work
> already on DHC's plate in regards to addressing the issues.  In the
list of
> issues with DHCP that make a new protocol required, many, if not most,
of
> the issues are already addressed or being rapdily addressed by DHC.
One
> major assertion in the draft is that broadcast is not used as much in
DRCP
> as in DHCP when indeed it is used and with a potentially worse impact
to the
> network than the very few broadcasts that are used in DHCP.
>
> Issue #1 "Rapid client configuration": there is no reason DHCP cannot
> configure a client in milliseconds.  It requires less aversion to
dangerous
> situations (duplicate IP address assignment), but it is very possible
since
> the current wording indicates "SHOULD", not "MUST".
>
> Issue #3 "Rapid client reconfiguration": There is a draft out for a
> DHCPFORCERENEW message already.  However, this is the only issue that
is
> more difficult to solve.  A broadcast-able FORCERENEW would be useful,
but
> highly dangerous (as is the DRCP equivalent.)
>
> Issue #4 in the list "Allowing clients to be routers" is only due to
> unfortunate wording in the old 2131 which I believe we've all agreed
to
> strike from the revised version.
>
> My issues: The danger of duplicate IP address assignment is much
higher with
> DRCP as clients do not check the assignment.  Is this worth it?  An
entirely
> new protocol requires entirely new servers and infrastructure.  Is
this
> worth it when there is something already 80% workable with possibly
zero
> changes to the core protocol and a few minor extensions that are
handled in
> the least disruptive manner?  I believe most of the requirements could
be
> addressed by Category One or Category two options (or guidelines C, D
and E)
> as in "draft-ietf-dhc-option-review-and-namespace-02.txt".  FORCERENEW
is
> the odd-man out but I think it does not actually change DHCP itself,
just
> adds some requirements to the client that could be implemented
separately.
>
> Also, in "draft-ietf-dhc-enhance-requirements-00.txt", it is stated
that
> DHCP clients go to sleep until lease times deem a wakeup.  This is not

> necessary and is not specified anywhere to my knowledge.  A DRCP
client in
> sleep mode would have to still listen for DRCP_ADVERTISEMENTS.  I do
not see
> how his is different from a DHCP client listening for a
DHCPFORCERENEW.
>
> -Nathan Lane



From owner-dhcp-v4@bucknell.edu  Wed Jul 26 16:31:03 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10919
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 26 Jul 2000 16:31:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6QKRdi01231;
	Wed, 26 Jul 2000 16:27:39 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6QKRVi05217
	for <dhcp-v4@bucknell.edu>; Wed, 26 Jul 2000 16:27:31 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-73.cisco.com [161.44.133.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA07623 for <dhcp-v4@bucknell.edu>; Wed, 26 Jul 2000 16:27:15 -0400 (EDT)
Message-Id: <4.3.1.2.20000726162648.00ae8200@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 26 Jul 2000 16:29:34 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Minutes at DHC WG meeting
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: rdroms@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I need to identify an official Scribe prior to the DHC WG meeting next 
Monday evening.  The Scribe's responsibilities will be to generate a short 
summary of the WG meeting before 8/4 and to prepare minutes for the WG 
meeting.  If you'd like to volunteer, please let me know.

- Ralph



From owner-dhcp-v6@bucknell.edu  Wed Jul 26 16:32:30 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11517
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 26 Jul 2000 16:32:30 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6QKT4i10801;
	Wed, 26 Jul 2000 16:29:04 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6QKSsi05282
	for <dhcp-v6@bucknell.edu>; Wed, 26 Jul 2000 16:28:54 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-73.cisco.com [161.44.133.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA07795 for <dhcp-v6@bucknell.edu>; Wed, 26 Jul 2000 16:28:38 -0400 (EDT)
Message-Id: <4.3.1.2.20000726162943.00aeb670@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 26 Jul 2000 16:30:10 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Minutes at DHC WG meeting
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I need to identify an official Scribe prior to the DHC WG meeting on DHCPv6 
next Tuesday morning.  The Scribe's responsibilities will be to generate a 
short summary of the WG meeting before 8/4 and to prepare minutes for the 
WG meeting.  If you'd like to volunteer, please let me know.

- Ralph



From owner-dhcp-v4@bucknell.edu  Thu Jul 27 07:46:43 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06045
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 27 Jul 2000 07:46:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6RBgai11650;
	Thu, 27 Jul 2000 07:42:36 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6RBgVi13791;
	Thu, 27 Jul 2000 07:42:32 -0400 (EDT)
Received: from rdroms-nt.cisco.com (rtp-dial-1-96.cisco.com [10.83.97.96]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA03583; Thu, 27 Jul 2000 07:42:08 -0400 (EDT)
Message-Id: <4.3.1.2.20000727073834.00adfc50@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 27 Jul 2000 07:39:20 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Meeting agenda and information
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: rdroms@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Information about the upcoming DHC WG meetings in Pittsburgh is available 
at http://www.dhcp.org/0007-meeting.html

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Jul 27 08:09:30 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06061
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 27 Jul 2000 07:46:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6RBgai18438;
	Thu, 27 Jul 2000 07:42:36 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6RBgVi13791;
	Thu, 27 Jul 2000 07:42:32 -0400 (EDT)
Received: from rdroms-nt.cisco.com (rtp-dial-1-96.cisco.com [10.83.97.96]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA03583; Thu, 27 Jul 2000 07:42:08 -0400 (EDT)
Message-Id: <4.3.1.2.20000727073834.00adfc50@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 27 Jul 2000 07:39:20 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Meeting agenda and information
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Information about the upcoming DHC WG meetings in Pittsburgh is available 
at http://www.dhcp.org/0007-meeting.html

- Ralph



From owner-dhcp-v4@bucknell.edu  Thu Jul 27 10:13:17 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29915
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 27 Jul 2000 10:13:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6REAAi06305;
	Thu, 27 Jul 2000 10:10:10 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6REA9i00038
	for <dhcp-v4@bucknell.edu>; Thu, 27 Jul 2000 10:10:09 -0400 (EDT)
Received: from rdroms-nt.cisco.com (sj-dial-1-111.cisco.com [171.68.179.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA17802 for <dhcp-v4@bucknell.edu>; Thu, 27 Jul 2000 10:09:52 -0400 (EDT)
Message-Id: <4.3.1.2.20000727101039.00b14e30@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 27 Jul 2000 10:11:16 -0400
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: List archive
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: rdroms@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Reminder - an archive for this mailing list is available at 
http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v4

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Jul 27 10:13:22 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29940
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 27 Jul 2000 10:13:22 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6REAPi06860;
	Thu, 27 Jul 2000 10:10:25 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6REACi06163
	for <dhcp-v6@bucknell.edu>; Thu, 27 Jul 2000 10:10:12 -0400 (EDT)
Received: from rdroms-nt.cisco.com (sj-dial-1-111.cisco.com [171.68.179.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA17818 for <dhcp-v6@bucknell.edu>; Thu, 27 Jul 2000 10:09:55 -0400 (EDT)
Message-Id: <4.3.1.2.20000727101135.00b17180@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 27 Jul 2000 10:11:53 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: List archive
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Reminder - an archive for this mailing list is available at 
http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v6

- Ralph



From owner-dhcp-v4@bucknell.edu  Thu Jul 27 14:57:06 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29031
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 27 Jul 2000 14:57:06 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6RIqPi23065;
	Thu, 27 Jul 2000 14:52:26 -0400 (EDT)
Received: from gidget.incognito.com (GIDGET.INCOGNITO.COM [207.102.214.80])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6RIqIi26214
	for <dhcp-v4@bucknell.edu>; Thu, 27 Jul 2000 14:52:18 -0400 (EDT)
Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21)
	id <PDQW0NB4>; Thu, 27 Jul 2000 11:57:10 -0700
Message-ID: <716D440F8C29D311991100A0C92048748246B1@GIDGET.INCOGNITO.COM>
From: "Kostur, Andre" <Andre@incognito.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: I-D ACTION:draft-ietf-dhc-agent-options-11.txt
Date: Thu, 27 Jul 2000 11:57:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BFF7FC.7785A160"
Reply-To: Andre@incognito.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFF7FC.7785A160
Content-Type: text/plain;
	charset="iso-8859-1"

Question about the content of the suboptions:

Is the data within the suboptions necessarily printable? (IE: 7-bit ASCII?)

The ambiguity (for me) arises in sections 3.1 and 3.2 where it mentions:

"The Circuit ID SHOULD be considered an opaque value, with policies based on
exact string match only,..."

Now if the options aren't necessarily printable, shouldn't the wording
reflect that you're not doing an exact string match, but an exact binary
data match?  Or am I reading to much into the meaning of the word "string" ?

--------------------------------------
Andre Kostur
Incognito Software Inc.
Ph: (604)688-4332   Fax: (604)688-4339
http://www.incognito.com


------_=_NextPart_000_01BFF7FC.7785A160
Content-Type: application/octet-stream;
	name="Andre Kostur.vcf"
Content-Disposition: attachment;
	filename="Andre Kostur.vcf"

BEGIN:VCARD
VERSION:2.1
N:Kostur;Andre
FN:Andre Kostur
ORG:Incognito Software Inc.;R & D
TITLE:Senior Software Engineer
TEL;WORK;VOICE:(604)688-4332x106
TEL;WORK;FAX:(604)688-4339
ADR;WORK:;;#300 - 1128 Hornby St.;Vancouver;BC;V6Z 2L4;Canada
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:#300 - 1128 Hornby St.=0D=0AVancouver, BC V6Z 2L4=0D=0ACanada
URL:
URL:http://www.incognito.com
EMAIL;PREF;INTERNET:akostur@incognito.com
REV:20000616T172533Z
END:VCARD

------_=_NextPart_000_01BFF7FC.7785A160--



From owner-dhcp-v4@bucknell.edu  Thu Jul 27 15:53:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16576
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 27 Jul 2000 15:53:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6RJp3i03326;
	Thu, 27 Jul 2000 15:51:03 -0400 (EDT)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6RJoli09419
	for <dhcp-v4@bucknell.edu>; Thu, 27 Jul 2000 15:50:47 -0400 (EDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Thu, 27 Jul 2000 14:45:39 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <P3N0ZJ4C>; Thu, 27 Jul 2000 14:47:05 -0500
Message-ID: <F033F6FEF3F1D111BD150000F8CD143104539563@zcard007.ca.nortel.com>
From: "Peter Tam" <ptam@nortelnetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: List archive
Date: Thu, 27 Jul 2000 14:47:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF803.6F6C92C0"
X-Orig: <ptam@americasm01.nt.com>
Reply-To: ptam@nortelnetworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

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_01BFF803.6F6C92C0
Content-Type: text/plain;
	charset="iso-8859-1"

Raph,

Does this archive cover DHCPv6 stuff as well? 

Thanks....Peter Tam,
Nortel Networks

	-----Original Message-----
	From:	Ralph Droms [SMTP:rdroms@cisco.com]
	Sent:	Thursday, July 27, 2000 10:11 AM
	To:	DHCPv4 discussion list
	Subject:	List archive

	Reminder - an archive for this mailing list is available at 
	http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v4

	- Ralph
	

------_=_NextPart_001_01BFF803.6F6C92C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: List archive</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Raph,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Does this archive cover DHCPv6 stuff =
as well? </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks....Peter Tam,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nortel Networks</FONT>
</P>
<UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Ralph Droms =
[SMTP:rdroms@cisco.com]</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Thursday, July 27, 2000 10:11 AM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">DHCPv4 discussion list</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">List archive</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Reminder - an archive for this mailing =
list is available at </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.listproc.bucknell.edu/cgi-bin/archdex?list=3Ddhcp-v4"=
 =
TARGET=3D"_blank">http://www.listproc.bucknell.edu/cgi-bin/archdex?list=3D=
dhcp-v4</A></FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- Ralph</FONT>
<BR>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFF803.6F6C92C0--



From owner-dhcp-v4@bucknell.edu  Thu Jul 27 16:03:06 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19276
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 27 Jul 2000 16:03:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6RK2Fi11803;
	Thu, 27 Jul 2000 16:02:15 -0400 (EDT)
Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6RK23i13593
	for <dhcp-v4@bucknell.edu>; Thu, 27 Jul 2000 16:02:03 -0400 (EDT)
Received: from dns.dhcp.org (dns.dhcp.org [134.82.56.120])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA21928;
	Thu, 27 Jul 2000 16:01:55 -0400 (EDT)
Date: Thu, 27 Jul 2000 16:01:55 -0400 (EDT)
From: "Ralph E. Droms" <droms@bucknell.edu>
X-Sender: droms@leo
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: List archive
In-Reply-To: <F033F6FEF3F1D111BD150000F8CD143104539563@zcard007.ca.nortel.com>
Message-ID: <Pine.GSO.4.03.10007271601160.21920-100000@leo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: droms@bucknell.edu
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

The DHCPv6 project has its own archive:

http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v6

- Ralph

On Thu, 27 Jul 2000, Peter Tam wrote:

> Raph,
> 
> Does this archive cover DHCPv6 stuff as well? 
> 
> Thanks....Peter Tam,
> Nortel Networks
> 
> 	-----Original Message-----
> 	From:	Ralph Droms [SMTP:rdroms@cisco.com]
> 	Sent:	Thursday, July 27, 2000 10:11 AM
> 	To:	DHCPv4 discussion list
> 	Subject:	List archive
> 
> 	Reminder - an archive for this mailing list is available at 
> 	http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v4
> 
> 	- Ralph
> 	
> 



From owner-dhcp-v4@bucknell.edu  Thu Jul 27 17:02:19 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04140
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 27 Jul 2000 17:02:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6RKxai22288;
	Thu, 27 Jul 2000 16:59:36 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6RKxNi23212
	for <dhcp-v4@bucknell.edu>; Thu, 27 Jul 2000 16:59:23 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-106.ip.theriver.com [206.97.58.106]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA07859; Wed, 26 Jul 2000 20:06:23 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id NAA00807; Thu, 27 Jul 2000 13:59:48 -0700 (MST)
Message-Id: <200007272059.NAA00807@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: I-D ACTION:draft-ietf-dhc-agent-options-11.txt 
In-Reply-To: Message from "Kostur, Andre" <Andre@incognito.com> 
   of "Thu, 27 Jul 2000 11:57:01 MST." <716D440F8C29D311991100A0C92048748246B1@GIDGET.INCOGNITO.COM> 
Date: Thu, 27 Jul 2000 13:59:48 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Now if the options aren't necessarily printable, shouldn't the wording
> reflect that you're not doing an exact string match, but an exact binary
> data match?  Or am I reading to much into the meaning of the word "string" ?

You are reading too much into it, but this is a fairly common thing -
many people at Microsoft have misread other portions of the
specification in this way.   So I think your proposed change in
wording is good, although it's a bit late in the game to be changing
the document...   :'}

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Thu Jul 27 18:12:28 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19933
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 27 Jul 2000 18:12:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6RM92i28175;
	Thu, 27 Jul 2000 18:09:02 -0400 (EDT)
Received: from proxy3.bigplanet.com (proxy3.bigplanet.com [216.169.193.145])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6RM8mi01305
	for <dhcp-v4@bucknell.edu>; Thu, 27 Jul 2000 18:08:48 -0400 (EDT)
Received: from bigplanet.net (soulspace.bigplanet.com)
 by proxy3.bigplanet.com (Sun Internet Mail Server
 sims.3.5.1999.07.30.00.05.p8) with ESMTP id
 <0FYD000LPMUM0K@proxy3.bigplanet.com> for dhcp-v4@bucknell.edu; Thu,
 27 Jul 2000 16:08:46 -0600 (MDT)
Date: Thu, 27 Jul 2000 16:11:39 -0600
From: "Larry H. Raab" <larry.raab@bigplanet.net>
Subject: Questions about syntax for LIUNX DHCP configs.
Sender: owner-dhcp-v4@bucknell.edu
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Message-id: <3980B39B.84B20F52@bigplanet.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
Reply-To: larry.raab@bigplanet.net
X-Sender: larry@soulspace.bigplanet.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

I need to know the following:

What is the syntax for the netbios-node-type...I can't figure it
out...probally easy question.

Also I need to know how to format the file for multiple networks...
i.e...
If the DHCP needs to give out subnets masks to like 30 diffrent networks
and they are 30 diffrent masks....

Please email if you can help me...

Thanks,

Larry Raab



From owner-dhcp-v6@bucknell.edu  Fri Jul 28 10:53:46 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07123
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 28 Jul 2000 10:53:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6SEmui17481;
	Fri, 28 Jul 2000 10:48:56 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6SEmoi21550
	for <dhcp-v6@bucknell.edu>; Fri, 28 Jul 2000 10:48:50 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-73.cisco.com [161.44.133.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA27320 for <dhcp-v6@bucknell.edu>; Fri, 28 Jul 2000 10:48:34 -0400 (EDT)
Message-Id: <4.3.1.2.20000728105028.00b3dc00@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 28 Jul 2000 10:50:51 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Minutes at DHC WG meeting
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I'm still looking for an official Scribe prior to the DHC WG meeting on 
DHCPv6 next Tuesday morning.  The Scribe's responsibilities will be to 
generate a short summary of the WG meeting before 8/4 and to prepare 
minutes for the WG meeting.  If you'd like to volunteer, please let me know.

- Ralph



From owner-dhcp-v6@bucknell.edu  Fri Jul 28 11:09:31 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11136
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 28 Jul 2000 11:09:31 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6SF7fi22193;
	Fri, 28 Jul 2000 11:07:41 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6SF7Yi22919
	for <dhcp-v6@bucknell.edu>; Fri, 28 Jul 2000 11:07:34 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA20532
	for <dhcp-v6@bucknell.edu>; Fri, 28 Jul 2000 08:07:14 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA08758
	for <dhcp-v6@bucknell.edu>; Fri, 28 Jul 2000 08:07:12 -0700
X-Virus-Scanned:  Fri, 28 Jul 2000 08:07:12 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdCpDnpt; Fri, 28 Jul 2000 08:07:11 PDT
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3981A1A0.9C2DD291@iprg.nokia.com>
Date: Fri, 28 Jul 2000 08:07:12 -0700
From: "Charles E. Perkins" <charliep@IPRG.NOKIA.COM>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Minutes at DHC WG meeting
References: <4.3.1.2.20000728105028.00b3dc00@funnel.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: charliep@iprg.nokia.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


Ralph,

Please put my name at the bottom of the list of volunteers.

Regards,
Charlie P.


Ralph Droms wrote:
> 
> I'm still looking for an official Scribe prior to the DHC WG meeting on
> DHCPv6 next Tuesday morning.  The Scribe's responsibilities will be to
> generate a short summary of the WG meeting before 8/4 and to prepare
> minutes for the WG meeting.  If you'd like to volunteer, please let me know.
> 
> - Ralph



From owner-dhcp-v6@bucknell.edu  Fri Jul 28 11:56:14 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26341
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 28 Jul 2000 11:56:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6SFpwi02766;
	Fri, 28 Jul 2000 11:51:58 -0400 (EDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6SFpti01542
	for <dhcp-v6@bucknell.edu>; Fri, 28 Jul 2000 11:51:55 -0400 (EDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA24464;
	Fri, 28 Jul 2000 11:51:29 -0400
Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA06442;
	Fri, 28 Jul 2000 11:51:29 -0400
Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id LAA21642; Fri, 28 Jul 2000 11:49:14 -0400
Message-Id: <200007281549.LAA21642@ludwigia.raleigh.ibm.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: dhcp-v6@bucknell.edu
Subject: Latest DHCPv6 drafts
Date: Fri, 28 Jul 2000 11:49:13 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Jim, Mike, Charlie:

I've finally managed to read both of the new DHCPv6 drafts, and must
say that they are (IMO) quite an improvement over the previous
drafts. They are much more concise than before and provide a clearer
basis for having followup discussions.  It's clear that a lot of
effort went into these documents, and it shows. Thanks for putting in
the time that it took to revise the documents.

Having said that, I'm concerned that we may still be quite a ways from
having a final document. With the IPv6 market pressures having shifted
quite noticeably over the last 9 months, there is a much greater
urgency for getting this spec done than there might have been even a
year ago.

Looking at the list of open issues listed in the document, I have to
ask if that list is intended to be complete, or whether there are
still other issues that the WG needs to consider. Specifically, I'm
thinking that there have been a number of threads in the past in which
issues were raised, but I'm not entirely certain that closure was
reached on all of them with the results of that closure documented in
the current ID.

In the following, I mention some examples of possible issues discussed
in the past that may still need further consideration (but are not
listed in the open issues section of the document). No claim is being
made that this list is complete, BTW.

Consider the message:

    From: Mike Carney - SNT Internet Engineering <Michael.Carney@East.Sun.COM>
    To: Multiple recipients of list <dhcp-v6@bucknell.edu>
    Date: Wed, 10 Nov 1999 18:51:57 -0500 (EST)
    Subject: List of DHCPv6 Issues with Responses, Part 2 of 2

It seems like some of the resolutions listed in this message are not
fully reflected in the current draft. For example:

   - a versioning scheme for the protocol
   - rules for option encoding intented to ease introduction of new
     options without requiring client and server code changes
   - state transition diagram
   - how clients request addresses and what addresses the server
     returns
   
On the last point, it seems that the current spec still isn't entirely
clear on how addresses are requested by clients and returned by
servers. To be clear, I mean *exactly* what is a client supposed to do
to request addresses (in typical cases), and *exactly* what is a
server supposed to do when it gets such a request (in typical
cases). The document doesn't seem to be explicit about this, other
than giving packet formats and suggesting some general
possibilities. I worry that different implementors will make different
choices in what they put in packets, with resultant interoperability
issues. As background, I think it would be useful to review a couple
of threads on this topic to see if all of the cases discussed before
are adequately covered. Reference:

         To: <dhcp-v6@bucknell.edu>
	 Date: Thu, 23 Dec 1999 11:14:48 -0500
	 Subject: DHCPv6 address allocation model
	 From: Thomas Narten <narten@hygro.adsl.duke.edu>

	 (and followups)


	 From: Mike Carney - SNT Internet Engineering <Michael.Carney@East.Sun.COM>
	 To: Multiple recipients of list <dhcp-v6@bucknell.edu>
	 Date: Tue, 16 Nov 1999 14:54:13 -0500 (EST)
	 Subject: DC meeting: Discussion question #2, multiple IP addresses

	 (and followups)

Finally, I haven't yet seen an agenda for the dhcpv6 topics to be
discussed in Pittsburgh.  What are the plans?
	 	 
Thomas



From owner-dhcp-v6@bucknell.edu  Fri Jul 28 22:51:09 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06234
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 28 Jul 2000 22:51:08 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6T2jCi09311;
	Fri, 28 Jul 2000 22:45:12 -0400 (EDT)
Received: from lychee.itojun.org (dialup0.itojun.org [210.160.95.108])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6T2j3i07937
	for <dhcp-v6@bucknell.edu>; Fri, 28 Jul 2000 22:45:04 -0400 (EDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
	by itojun.org (8.10.0/3.7W) with ESMTP id e6T2f4M11900
	for <dhcp-v6@bucknell.edu>; Sat, 29 Jul 2000 11:41:04 +0900 (JST)
Message-Id: <200007290241.e6T2f4M11900@itojun.org>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
In-reply-to: narten's message of Fri, 28 Jul 2000 11:49:13 -0400.
      <200007281549.LAA21642@ludwigia.raleigh.ibm.com> 
X-Template-Reply-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: Latest DHCPv6 drafts 
From: Jun-ichiro itojun Hagino <itojun@ITOJUN.ORG>
Date: Sat, 29 Jul 2000 11:41:04 +0900
Sender: owner-dhcp-v6@bucknell.edu
Reply-To: dhcp-v6@bucknell.edu
X-Sender: itojun@itojun.org
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>I've finally managed to read both of the new DHCPv6 drafts, and must
>say that they are (IMO) quite an improvement over the previous
>drafts. They are much more concise than before and provide a clearer
>basis for having followup discussions.  It's clear that a lot of
>effort went into these documents, and it shows. Thanks for putting in
>the time that it took to revise the documents.

	Hello, thanks for the new documents (15 draft).

	One comment from implementors POV.  I think the following items
	must be clarificed.

itojun


	- padding requirement for variable length fields in extension.
	- similarly, string termination requirement for string fields.
	  are these field needs to be terminated by 0x00, or we must leave
	  them as is?

	  this question affects the following fields:
		DNS name field in IP address extension (extension document 4.1)
		IEEE timezone string in timezone extension (5.1)
		domain name suffix in domain name suffix extension (5.3)
		NIS domain name in NIS domain name extension (5.7)
		NIS+ domain name in NIS+ domain name extension (5.9)

	  for example, suppose we would like to transmit timezone string
	  "UTC" using extension type 8193.  which is the correct way to
	  send this?

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type = 8193           |             Length = 3        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    "U"        |   "T"         |   "C"         |   next extensin start here
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type = 8193           |             Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    "U"        |   "T"         |   "C"         |   0x00        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   next extension starts here

	  or, if we would like to send NIS domain name "KAME" using extension
	  type 8199, which is the correct one?

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Type = 8199          |             Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    "K"        |   "A"         |   "M"         |   "E"         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   next extension starts here

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Type = 8199          |             Length = 5        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    "K"        |   "A"         |   "M"         |   "E"         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   0x00        |   next extension starts here
   +-+-+-+-+-+-+-+-+

	- "subnet prefix octets" field in subnet prefix extension is
	  defined as variable length, however, I think we should make it
	  fixed length (16 bytes).  otherwise, implementers may do different
	  byte truncation and validation gets trickier.  also, padding
	  requirement is unclear if we do truncation.  i'd suggest wording
	  like this:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 8207         |             Length = 16       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Prefix Len (number of left-most bits) (1 octet)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Subnet Prefix Octets                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Subnet Prefix Octets                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Subnet Prefix Octets                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Subnet Prefix Octets                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   A subnet prefix is specified by the ``Subnet Prefix Octets'' field
   and the ``Prefix-Len'' field.  Any unused bits in the last octet of
   this field MUST be set to off (zero).

   The length of this extension is 16.



From owner-dhcp-v6@bucknell.edu  Sat Jul 29 16:51:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16965
	for <DHC-ARCHIVE@odin.ietf.org>; Sat, 29 Jul 2000 16:51:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6TKmvi29927;
	Sat, 29 Jul 2000 16:48:57 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6TKmfi19465
	for <dhcp-v6@bucknell.edu>; Sat, 29 Jul 2000 16:48:41 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10075;
	Sat, 29 Jul 2000 13:48:37 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id NAA03870;
	Sat, 29 Jul 2000 13:48:36 -0700 (PDT)
Received: from jurassic (jurassic [129.146.89.31])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6TKmYI703793;
	Sat, 29 Jul 2000 13:48:35 -0700 (PDT)
Date: Sat, 29 Jul 2000 13:48:34 -0700 (PDT)
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Reply-To: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Subject: Re: Latest DHCPv6 drafts
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM, "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>,
        "Charles E. Perkins" <charliep@IPRG.NOKIA.COM>, dhcp-v6@bucknell.edu
In-Reply-To: "Your message with ID" <200007281549.LAA21642@ludwigia.raleigh.ibm.com>
Message-ID: <Roam.SIMC.2.0.6.964903714.25600.mwc@jurassic.eng.sun.com.>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> Jim, Mike, Charlie:
> 
> I've finally managed to read both of the new DHCPv6 drafts, and must
> say that they are (IMO) quite an improvement over the previous
> drafts. They are much more concise than before and provide a clearer
> basis for having followup discussions.  It's clear that a lot of
> effort went into these documents, and it shows. Thanks for putting in
> the time that it took to revise the documents.

Thanks. We were hoping we'd have more comment on them than we got.

> 
> Having said that, I'm concerned that we may still be quite a ways from
> having a final document. With the IPv6 market pressures having shifted
> quite noticeably over the last 9 months, there is a much greater
> urgency for getting this spec done than there might have been even a
> year ago.
> 
> Looking at the list of open issues listed in the document, I have to
> ask if that list is intended to be complete, or whether there are
> still other issues that the WG needs to consider. Specifically, I'm
> thinking that there have been a number of threads in the past in which
> issues were raised, but I'm not entirely certain that closure was
> reached on all of them with the results of that closure documented in
> the current ID.

No, that list is not seen as a complete list, but rather one we'd figured
we'd add / subtract from as we had discussion on the list.

> 
> In the following, I mention some examples of possible issues discussed
> in the past that may still need further consideration (but are not
> listed in the open issues section of the document). No claim is being
> made that this list is complete, BTW.
> 
> Consider the message:
> 
>     From: Mike Carney - SNT Internet Engineering
> <Michael.Carney@East.Sun.COM>
>     To: Multiple recipients of list <dhcp-v6@bucknell.edu>
>     Date: Wed, 10 Nov 1999 18:51:57 -0500 (EST)
>     Subject: List of DHCPv6 Issues with Responses, Part 2 of 2
> 
> It seems like some of the resolutions listed in this message are not
> fully reflected in the current draft. For example:
> 
>    - a versioning scheme for the protocol
>    - rules for option encoding intented to ease introduction of new
>      options without requiring client and server code changes
>    - state transition diagram
>    - how clients request addresses and what addresses the server
>      returns
>    
> On the last point, it seems that the current spec still isn't entirely
> clear on how addresses are requested by clients and returned by
> servers. To be clear, I mean *exactly* what is a client supposed to do
> to request addresses (in typical cases), and *exactly* what is a
> server supposed to do when it gets such a request (in typical
> cases). The document doesn't seem to be explicit about this, other
> than giving packet formats and suggesting some general
> possibilities. I worry that different implementors will make different
> choices in what they put in packets, with resultant interoperability
> issues. As background, I think it would be useful to review a couple
> of threads on this topic to see if all of the cases discussed before
> are adequately covered. Reference:
> 
>          To: <dhcp-v6@bucknell.edu>
> 	 Date: Thu, 23 Dec 1999 11:14:48 -0500
> 	 Subject: DHCPv6 address allocation model
> 	 From: Thomas Narten <narten@hygro.adsl.duke.edu>
> 
> 	 (and followups)
> 
> 
> 	 From: Mike Carney - SNT Internet Engineering <Michael.Carney@East.Sun.COM>
> 	 To: Multiple recipients of list <dhcp-v6@bucknell.edu>
> 	 Date: Tue, 16 Nov 1999 14:54:13 -0500 (EST)
> 	 Subject: DC meeting: Discussion question #2, multiple IP addresses
> 
> 	 (and followups)
> 
> Finally, I haven't yet seen an agenda for the dhcpv6 topics to be
> discussed in Pittsburgh.  What are the plans?


I'm going to be presenting a list of issues/discussion points from the issues
list in the document, Carl Smith's input, and Francis' input.

I was hoping to get this list out to the working group last week, but
unfortunately due to an event out of my control, that didn't happen. I'll
submit the items to the list (one thread per item) for those folks not going
to pittsburg, as well as present the items at tuesday's meeting (for those
folks who are attending the meeting).

> 	 	 
> Thomas
> 



Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
(650) 786-4171
Mailstop UMPK17-202
901 San Antonio Rd
Palo Alto, CA 94303



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 01:02:10 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22931
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 01:02:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V4woi30003;
	Mon, 31 Jul 2000 00:58:50 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V4wgi27388
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 00:58:42 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA22954;
	Sun, 30 Jul 2000 21:58:29 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id VAA15998;
	Sun, 30 Jul 2000 21:58:29 -0700 (PDT)
Received: from eng.sun.com (hobo231.Eng.Sun.COM [129.146.31.231])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V4wN8129889;
	Sun, 30 Jul 2000 21:58:23 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984EB56.46BF8386@eng.sun.com>
Date: Sun, 30 Jul 2000 19:58:30 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
CC: Jim Bound <bound@ZK3.DEC.COM>, Charles Perkins <charliep@IPRG.NOKIA.COM>,
        Mike Carney <Michael.carney@east.sun.com>, dhcp-v6@bucknell.edu
Subject: Re: some comments about DHCPv6 I-Ds
References: <200007111752.TAA76100@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


Hi Francis,

Thanks for the comments. My points are added below.

Francis Dupont wrote:
> 
> Here are some comments about DHCPv6 I-Ds by our Indian student
> who is supposed to do a DHCPv6 first implementation for the next week.
> 
> I disagree with him about (1) because in fact you can get the link
> from an address. With a prefix-length the test is an equality (same
> length and prefix), without it is a matching (harder but still possible).
> (more accurately it is a matching between the relay address for off-link
> clients and one of the prefixes configurated (in the config file) for the
> link).
> Proposal: get rid of the prefix length field.
> 
> (2) is really misleading, (3) is a general comment (too much freedom).
> 
> You already know (4) (:-) but I have not perverted Dhawal (he has found
> the issue by himself).
> 
> (5) is about poor wording
> 
> (6) => remove the R bit (the C bit is enough).
> 
> (7) is from an older draft (today relay is very easy to implement :-).
> 
> (8) is like (3) (and Dhawal has looked for a missing profile).
> 
> (9) is about the rules for I-D format which is *mandatory*:
> please replace word by a text editor (:-), cfd RFC 2223:
> 
>    3a.  ASCII Format Rules
> 
>       The character codes are ASCII.
> 
>       Each page must be limited to 58 lines followed by a form feed on a
>       line by itself.
> 
>       Each line must be limited to 72 characters followed by carriage
>       return and line feed.
> 
>       No overstriking (or underlining) is allowed.
> 
>       These "height" and "width" constraints include any headers,
>       footers, page numbers, or left side indenting.
> 
>       Do not fill the text with extra spaces to provide a straight right
>       margin.
> 
>       Do not do hyphenation of words at the right margin.
> 
>       Do not use footnotes.  If such notes are necessary, put them at
>       the end of a section, or at the end of the document.
> 
>       Use single spaced text within a paragraph, and one blank line
>       between paragraphs.
> 
>       Note that the number of pages in a document and the page numbers
>       on which various sections fall will likely change with
>       reformatting.  Thus cross references in the text by section number
>       usually are easier to keep consistent than cross references by
>       page number.
> 
>       RFCs in ASCII Format may be submitted to the RFC Editor in e-mail
>       messages (or as online files) in either the finished publication
>       format or in nroff.  If you plan to submit a document in nroff
>       please consult the RFC Editor first.
> 
> Regards
> 
> Francis.Dupont@enst-bretagne.fr
> 
> PS: we have not found a problem which makes implementation impossible.
>
> Dear Sir,
> I have the following problems in context of the two drafts:
> (a) draft-ietf-dhc-dhcpv6-15.txt
> (b) draft-ietf-dhc-dhcpv6exts-12.txt
>
> (1) Client binding has been defined as "a group of server
> data records indexed by <client's link-local address,
> subnet prefix> containing the releasable resource data
> which a DHCP server has assigned to a client" on page
> 3 of (a) but there is no prefix-len field in a DHCP
> Request or Release message. The result is that if a server
> receives a request message with c bit set and no IP Address
> Extension or a release message without any IP Address Extension,
> it can't release a resource because it can't identify a
> binding without prefix-len.

Agreed. Seems that unicasting messages directly to off-link servers
complicates the server's job of the identification of a binding. In
order to disambiguate requests/releases, the client would need to
provide a link identifier (subnet prefix?) which it cannot know.
Suggestions?

>
> (2) On page 27 of (b) the figure for Subnet Prefix Extension shows
> it to be 32-bit field while its actually only 8-bit field.
> (Poor drawing).

Will fix.

>
> (3) Nothing has been mentioned in either of the drafts regarding
> when a non IP Address Extension should be sent. (Which ones
> are mandatory and which ones are optional in a DHCP message.)
> e.x. Can I send an extension other than Subnet Prefix Extension
> in an advertise message even if "administrative policy requires it"?
> (page 3 of (b)).

Actually, only subnet prefix extensions and authentication extensions
make sense for advertisements, at this time. Are they the only ones
moving toward the future? Probably not. So is the suggestion that we
itemize which extensions are legal for each message?

>
> (4) There is no clause saying "multi-link-subnets" are not allowed in DHCP.

Is such support required to make DHCP useful immediately? (are such
architectures going to be common place?)

>
> (5) Page 27 of (a) says: "The client waits ADV_MSG_TIMEOUT, collecting
> Advertise messages." while page 45 of same draft says "A client MUST
> wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message
> to collect Advertise messages". I think that the clause on page 45
> should be modified to "A client MUST wait for SRVR_PREF_WAIT seconds
> after receiving first advertise to collect Advertise messages".

Good find. A couple of things need to happen here -

        a) Spec must be clarified to state that a client MUST stop
        waiting for advertise messages after one with a preference of
        255 is detected. Only that advertise message is accepted for
        processing (others are ignored).

        b) The server preference section (14.4 of (a) (page 45)) really
        belongs in the main body of the document where preference is
        described, and not languish in its own enty in the DHCP client
        implementors notes. (part of the protocol). This will happen in
        the next draft.  

>
> (6) Page 47 of (a) says that Transaction-ID cache "enables the server to
> quickly determine whether a Request is a retransmission or a new Request".
> Page 46 of the same draft says that "server MUST include the
> transaction-ID from the client's Request along with the releasable
> resource identifier(s) within the binding". Thus clearing transaction
> ID cache entries through "R" bit in request message is of no use. The
> server can still detect a retransmission because transaction-ID is still
> there in stable storage.

In general, the purpose / use of the transaction ID (cache or otherwise)
needs to be clarified. If we are planning on using the transaction ID to
preserve idempotence by including it within the client's binding, then
the entry for binding in the DHCP terminology section needs to be
updated, and the client's requirement to preserve transaction ID over
restarts becomes apparent, and the purpose of the 'R' bit goes away. A
server may implement the cache for performance reasons, but it isn't a
protocol requirement.

>
> (7) "ICMPError" defined on page 8 of (a) has been used nowhere else.
> Probably this is used by relays when server is unreachable.

May mean DNS server is unavailable. Need to clarify if that's the case,
remove otherwise.

>
> (8) There should be table of allowed combination of bits (C, I, L, Q, A,
> P) in IP Address Extension.

Nice suggestion. I'll discuss this with the other authors.

>
> (9) The last problem is same as yours: "Format of the drafts".

The document is in LaTex, and the dvi2tty converter I have isn't the
greatest. For sure in the next version, the formating will be corrected
and the tables fixed (no underlining).

>
> Thanking you,
> Yours sincerely,
> Dhawal Kumar.
>



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:01:43 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20097
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:01:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V5x5i31668;
	Mon, 31 Jul 2000 01:59:05 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V5wti03840
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 01:58:56 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA02089
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 22:58:55 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id WAA21491
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 22:58:55 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V5wr8133625
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 22:58:53 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984F983.EEF794D3@eng.sun.com>
Date: Sun, 30 Jul 2000 20:58:59 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


Rather than include all of the discussion points in one email, I've
generated an email for each point to facilitate email discussion.

1) We plan on stating that there is no support for multi-link-subnets in
DHCPv6. Comments?



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:03:23 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22555
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:03:22 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V60Ji00805;
	Mon, 31 Jul 2000 02:00:19 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V608i24608
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:00:08 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA02283
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:00:07 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA21695
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:00:07 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V6058133677
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:00:05 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984F9CB.EC7AFB19@eng.sun.com>
Date: Sun, 30 Jul 2000 21:00:11 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

2) We have a request to enumerate which extensions are legal for which
messages. Comments?
        Examples:

        a) limit extensions in advertise messages to subnet prefix or
           authentication.
        b) limit extensions in reconfigure-init to ERE and
           authentication.



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:03:37 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22902
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:03:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V61Ei26545;
	Mon, 31 Jul 2000 02:01:14 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V61Ai04762
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:01:10 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA02492
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:01:09 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA21902
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:01:09 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V6178133767
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:01:07 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FA0A.C4B2B00@eng.sun.com>
Date: Sun, 30 Jul 2000 21:01:14 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

3) We have a request to clarify use of the preference field in advertise
messages.

        a) Toward that end, I plan on clarifying the text to state that
           a client does not wait for more advertise messages once it
           receives an advertise message with preference value of 255.
           Furthermore, if other advertise messages were received before
           the authoritative message (255), those are ignored in favor
of the
           authoritative advertise message. How does this sound?

        b) The original draft specified the default preference value to
           be 255 (authoritative), whereas the march draft specified a
           default value of 0. What do people think?



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:06:14 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26112
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:06:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V65qi04221;
	Mon, 31 Jul 2000 02:05:52 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V65gi06259
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:05:42 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA03369
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:05:41 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA22377
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:05:41 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V65d8133924
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:05:39 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FB1A.991B518D@eng.sun.com>
Date: Sun, 30 Jul 2000 21:05:46 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

4) We have a request to clarify the client binding, specifically:

        a) Some messages (Request/Release) don't contain enough
        information to allow the server to identify the client's binding
        (subnet prefix missing). Thus, interaction with the relay for
        off-link clients seems to be a requirement. Otherwise, a client
        must be presented with some sort of unique link identifier
        provided in advertise messages for use in communication with the
        server. Comments?

        b) Server Implementor notes state that transaction ID MUST be
        associated with a releasable resource within a client's binding
        in order for the server to detect separate requests from
        retransmissions. The text is inconsistent WRT transaction IDs,
        transaction ID caches, ``R'' bit of a Request, requirements of a
        client to remember its last transaction ID.

        If the transaction ID is specified to be associated with a
        releasable resource within the client's binding, then ``R'' bit
        of Requests is no longer needed. Transaction ID caches then
        become an optional server implementation feature, not a
        requirement of the protocol. The description of bindings
        throughout the draft would be updated with this point in mind.



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:07:22 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26481
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:07:22 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V674i32625;
	Mon, 31 Jul 2000 02:07:04 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V66pi00921
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:06:51 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA03596
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:06:51 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA22517
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:06:51 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V66n8134037
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:06:49 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FB5F.D30EFED8@eng.sun.com>
Date: Sun, 30 Jul 2000 21:06:55 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

5) The text infers that modification of DHCP messages in flight by
relays is not permitted (other than the relay-agent field). Comments?



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:08:21 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26815
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:08:20 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V67ui27268;
	Mon, 31 Jul 2000 02:07:56 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V67ii05337
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:07:44 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA03789
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:07:43 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA22620
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:07:43 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V67f8134088
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:07:42 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FB94.AB19776F@eng.sun.com>
Date: Sun, 30 Jul 2000 21:07:48 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

6) We have a request to clarify client behavior upon reciept of Reply
messages w/ non-zero status. Perhaps a table showing behavior for each
status value. Comments?



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:09:06 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27060
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:09:06 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V68mi03477;
	Mon, 31 Jul 2000 02:08:48 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V68gi06565
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:08:42 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA03982
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:08:41 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA22705
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:08:41 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V68d8134130
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:08:40 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FBCE.26D1F45D@eng.sun.com>
Date: Sun, 30 Jul 2000 21:08:46 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


[from the issues section of the march draft]

7)  Trade-offs:  Optional fields in DHCP messages

   You'll notice that the message formats have changed.  In particular,
   some of the optional fields are now required.  This will increase the
   size of DHCP messages in some cases, consuming network bandwidth and
   memory on the DHCP client (an issue for small devices such as PDAs).

   The changes were made for the following reasons:

     o Fields that were used most of the time were made required.

     o Some fields that were optional were either made required or added
       to messages which previously didn't have them.  This was done for
       robustness reasons (receivers can validate that the message is
       for them, and in the case of clients, know which interface the
       message is intended for).

     o Simplicity.

   Please look at the messages as they are now defined, and let us know
   your opinion.



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:09:46 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27282
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:09:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V69Pi06006;
	Mon, 31 Jul 2000 02:09:25 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V69Li03425
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:09:21 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04175
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:09:20 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA22761
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:09:20 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V69I8134175
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:09:18 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FBF5.F1BB182C@eng.sun.com>
Date: Sun, 30 Jul 2000 21:09:25 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

[also from issues section of march draft]

8) Use DHCPv4 authentication or the current DHCPv6 method?

   Now that the DHCPv4 authentication draft is in last call, should
   we use the technique described in that document to provide
   authentication for DHCPv6, or should we continue with the
   authentication technique currently documented in the extensions
   draft?



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:11:28 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27836
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:11:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V6B2i14599;
	Mon, 31 Jul 2000 02:11:02 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V6Awi00954
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:10:58 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04439
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:10:57 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA22875
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:10:57 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V6At8134266
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:10:56 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FC56.8F8C4750@eng.sun.com>
Date: Sun, 30 Jul 2000 21:11:02 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

[one more from the may draft's issue section] (yes, that's may, not
march ;^)

9) The Reconfigure Message and Subnet Prefix Extensions

   The drafts currently specify that Releasable resources (such as an IP
   address) can only be reconfigured using the Reconfigure-init trigger
   message.  This was done for simplicity (enables clients to perform
   DAD on the new address and return the appropriate result to the
   server) using the same mechanism as a standard Request/Reply/Release
   exchange.  This method also makes no assumptions about the
   charactistics of the releasable resource.

   However, for IP addresses with interface IDs, one could send out
   two IP address extensions, one for the old prefix and one for the
   new, and cause clients to change the prefix and thus renumber over
   time.  This scheme avoids the added DHCP Request traffic - clients
   acknowledge with a Reconfigure-reply message.



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:12:42 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28229
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:12:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V6COi00399;
	Mon, 31 Jul 2000 02:12:24 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V6CAi04428
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:12:10 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04645
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:12:09 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA22965
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:12:09 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V6C78134346
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:12:08 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FC9E.C3DA1A59@eng.sun.com>
Date: Sun, 30 Jul 2000 21:12:14 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #10
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

10) We've had requests for client and server implementation state
diagrams.  Would people find these useful, or is the draft enough?



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:13:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28474
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:13:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V6D7i02130;
	Mon, 31 Jul 2000 02:13:07 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V6Cui00899
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:12:56 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04801
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:12:55 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA23037
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:12:55 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V6Cr8134379
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:12:54 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FCCA.6BDA9766@eng.sun.com>
Date: Sun, 30 Jul 2000 21:12:58 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #11
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


11) Current draft doesn't define a method for carrying the version of
the protocol. We have discussed this in the past, and this feature was
planned for the protocol but was accidently dropped during the editing
process (my bad). Anyway, should the protocol version be carried within
a field in the message headers, or should it be carried as an extension?



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 02:14:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28727
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 02:14:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6V6Doi05983;
	Mon, 31 Jul 2000 02:13:50 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6V6Dji05986
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 02:13:45 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04947
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:13:44 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA23140
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:13:45 -0700 (PDT)
Received: from eng.sun.com (hobo229.Eng.Sun.COM [129.146.31.229])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V6Dh8134427
	for <dhcp-v6@bucknell.edu>; Sun, 30 Jul 2000 23:13:43 -0700 (PDT)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <3984FCFE.E3EACDA6@eng.sun.com>
Date: Sun, 30 Jul 2000 21:13:50 -0700
From: "Michael W. Carney" <Michael.Carney@ENG.SUN.COM>
Organization: SNT Internet Engineering
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6, tues discussion point #12 - last one
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Michael.Carney@eng.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

12) There is no discussion in the current draft regarding
extension/message review guidelines a'la the New options review
guidelines draft for DHCPv4. IMHO, we should ensure that the new options
review draft is general enough to be used by both protocols, and point
at
that draft.



From owner-dhcp-v4@bucknell.edu  Mon Jul 31 10:54:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16066
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 10:54:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6VElYi14155;
	Mon, 31 Jul 2000 10:47:34 -0400 (EDT)
Received: from kitab.cisco.com (wireless-133-25.ietf.marconi.com [147.73.133.25])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6VElOi03081;
	Mon, 31 Jul 2000 10:47:24 -0400 (EDT)
Received: (from raj@localhost)
	by kitab.cisco.com (8.9.3/8.9.2) id KAA01170;
	Mon, 31 Jul 2000 10:47:15 -0700 (PDT)
	(envelope-from raj)
From: Richard Johnson <raj@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14725.47959.37256.738608@kitab.cisco.com>
Date: Mon, 31 Jul 2000 10:45:58 -0700 (PDT)
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: dhcp-v4@bucknell.edu
Subject: Question re. DHCP auth. draft
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Reply-To: raj@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

I don't see any discussion of using public key authentication.  It'd
be really nice to come to an IETF and be told (via the terminal room
info sheet) what the public key is for the DHCP server, then configure 
this on your DHCP client, and know that you're getting an address from 
a legitimate server.

There was a scenario a few IETFs ago where someone in the terminal
room was running a DHCP server on their laptop (and probably didn't
know it, but they could have simply been malicious).  A shared secret
doesn't help avoid this situation because anyone else attending would
know the secret key and could easily setup a server using it.  A
public key method would avoid this since only the true server would
know the private key and everyone else could be given the public key.

In particular, I know there are some companies which would like to use 
wireless technology but are waiting for some useful type of DHCP
authentication first.  I believe a shared key will simply not work for 
these companies, but a public key would.

/raj



From owner-dhcp-v4@bucknell.edu  Mon Jul 31 11:16:01 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19132
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 11:16:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6VFFMi18656;
	Mon, 31 Jul 2000 11:15:23 -0400 (EDT)
Received: from nausicaa.coritel.it ([193.205.242.5])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6VFF8i21468
	for <dhcp-v4@bucknell.edu>; Mon, 31 Jul 2000 11:15:08 -0400 (EDT)
Received: from archimede (archimede.coritel.it [193.205.242.44])
	by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id RAA16857
	for <dhcp-v4@bucknell.edu>; Mon, 31 Jul 2000 17:03:09 +0200 (MET DST)
Message-ID: <00a301bffb01$d1610a00$2cf2cdc1@coritel.it>
From: "Raffaele Pellicciotta" <pellicciotta@coritel.it>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Information
Date: Mon, 31 Jul 2000 17:13:01 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A0_01BFFB12.949F1560"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Reply-To: pellicciotta@coritel.it
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

This is a multi-part message in MIME format.

------=_NextPart_000_00A0_01BFFB12.949F1560
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

How can I unsuscribe from this mailing list????
Thanks a lot,
  Raffaele

------=_NextPart_000_00A0_01BFFB12.949F1560
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>How can I unsuscribe from this mailing=20
list????</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks a lot,</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;Raffaele</FONT></DIV></BODY></HTML>

------=_NextPart_000_00A0_01BFFB12.949F1560--



From owner-dhcp-v4@bucknell.edu  Mon Jul 31 11:46:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27393
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 11:46:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6VFhIi10232;
	Mon, 31 Jul 2000 11:43:18 -0400 (EDT)
Received: from gidget.incognito.com (GIDGET.INCOGNITO.COM [207.102.214.80])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6VFh6i18076
	for <dhcp-v4@bucknell.edu>; Mon, 31 Jul 2000 11:43:07 -0400 (EDT)
Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21)
	id <PDQW0P0G>; Mon, 31 Jul 2000 08:48:46 -0700
Message-ID: <716D440F8C29D311991100A0C92048748246D3@GIDGET.INCOGNITO.COM>
From: "Kostur, Andre" <Andre@incognito.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Question re. DHCP auth. draft
Date: Mon, 31 Jul 2000 08:48:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Andre@incognito.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ummm... as I recall, it is infeasable to post the public key on an info
sheet since the size of the key is rather large.  I suppose one could post
the fingerprint of the key and use that to confirm the key on the terminal,
but who's to say that the terminal room info sheet hasn't been replaced?

> -----Original Message-----
> From: Richard Johnson [mailto:raj@cisco.com]
> Sent: Monday, July 31, 2000 10:46 AM
> To: DHCPv4 discussion list
> Cc: dhcp-v4@bucknell.edu
> Subject: Question re. DHCP auth. draft
> 
> 
> I don't see any discussion of using public key authentication.  It'd
> be really nice to come to an IETF and be told (via the terminal room
> info sheet) what the public key is for the DHCP server, then 
> configure 
> this on your DHCP client, and know that you're getting an 
> address from 
> a legitimate server.
> 
> There was a scenario a few IETFs ago where someone in the terminal
> room was running a DHCP server on their laptop (and probably didn't
> know it, but they could have simply been malicious).  A shared secret
> doesn't help avoid this situation because anyone else attending would
> know the secret key and could easily setup a server using it.  A
> public key method would avoid this since only the true server would
> know the private key and everyone else could be given the public key.
> 
> In particular, I know there are some companies which would 
> like to use 
> wireless technology but are waiting for some useful type of DHCP
> authentication first.  I believe a shared key will simply not 
> work for 
> these companies, but a public key would.
> 
> /raj
> 



From owner-dhcp-v4@bucknell.edu  Mon Jul 31 13:33:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14833
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 13:33:11 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6VHSRi05442;
	Mon, 31 Jul 2000 13:28:27 -0400 (EDT)
Received: from kitab.cisco.com (rtp-isp-nat-pool-2.cisco.com [192.135.249.2])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6VHSEi05044
	for <dhcp-v4@bucknell.edu>; Mon, 31 Jul 2000 13:28:15 -0400 (EDT)
Received: (from raj@localhost)
	by kitab.cisco.com (8.9.3/8.9.2) id NAA00723;
	Mon, 31 Jul 2000 13:28:29 -0700 (PDT)
	(envelope-from raj)
From: Richard Johnson <raj@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14725.57707.562952.681883@kitab.cisco.com>
Date: Mon, 31 Jul 2000 13:28:27 -0700 (PDT)
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Question re. DHCP auth. draft
In-Reply-To: <716D440F8C29D311991100A0C92048748246D3@GIDGET.INCOGNITO.COM>
References: <716D440F8C29D311991100A0C92048748246D3@GIDGET.INCOGNITO.COM>
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Reply-To: raj@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Kostur, Andre writes:
 > Ummm... as I recall, it is infeasable to post the public key on an info
 > sheet since the size of the key is rather large.  I suppose one could post
 > the fingerprint of the key and use that to confirm the key on the terminal,
 > but who's to say that the terminal room info sheet hasn't been replaced?

Yes, probably the best bet would be use a publicly known and
registered key.  Same way the ietf-registrar public key is used for
paying via credit card info in an encrypted email.

I also recognize that this method only authenticates the server to the 
clients and not the other way around, but it would seem this is what
is needed in situations such as the IETF meetings and possibly other places.

I guess if enough people agree that this is needed it should simply
become another draft and follow the steps outlined already for
defining a new algorithm number.

/raj



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 17:01:27 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15422
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 17:01:27 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e6VKvGi29998;
	Mon, 31 Jul 2000 16:57:17 -0400 (EDT)
Received: from stack.hamachi.org (sommerfeld.ne.mediaone.net [24.147.212.81])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e6VKvAi32312
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 16:57:10 -0400 (EDT)
Received: from thunk.hamachi.org (orchard.hamachi.org [4.255.0.98])
	by stack.hamachi.org (Postfix) with ESMTP id AA65E26F6
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 16:57:09 -0400 (EDT)
Received: from thunk (localhost [[UNIX: localhost]])
	by thunk.hamachi.org (8.10.2/8.8.8) with ESMTP id e6VKwW704216
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 16:58:32 -0400 (EDT)
Message-Id: <200007312058.e6VKwW704216@thunk.hamachi.org>
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6, tues discussion point #5 
In-Reply-To: Message from "Michael W. Carney" <Michael.Carney@eng.sun.com> 
   of "Sun, 30 Jul 2000 21:06:55 PDT." <3984FB5F.D30EFED8@eng.sun.com> 
Reply-To: sommerfeld@orchard.arlington.ma.us
Date: Mon, 31 Jul 2000 16:58:32 -0400
Sender: owner-dhcp-v6@bucknell.edu
X-Sender: wes@orchard.arlington.ma.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> 5) The text infers that modification of DHCP messages in flight by
> relays is not permitted (other than the relay-agent field). Comments?

Permitting unlimited modifications in flight (even trivial stuff like
reordering options) will get in the way of attempts to introduce
end-to-end security into the protocol.

					- Bill



From owner-dhcp-v4@bucknell.edu  Mon Jul 31 21:17:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22609
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 21:17:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e711Afi24380;
	Mon, 31 Jul 2000 21:10:41 -0400 (EDT)
Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e711Abi24021
	for <dhcp-v4@bucknell.edu>; Mon, 31 Jul 2000 21:10:37 -0400 (EDT)
Received: from localhost (waa@localhost)
	by codex.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id e711AYL19864;
	Mon, 31 Jul 2000 21:10:34 -0400 (EDT)
Date: Mon, 31 Jul 2000 21:10:33 -0400 (EDT)
From: "William A. Arbaugh" <waa@dsl.cis.upenn.edu>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: Question re. DHCP auth. draft
In-Reply-To: <14725.47959.37256.738608@kitab.cisco.com>
Message-ID: <Pine.SOL.4.21.0007312108500.19846-100000@codex.cis.upenn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: waa@dsl.cis.upenn.edu
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I don't see any discussion of using public key authentication.  It'd
> be really nice to come to an IETF and be told (via the terminal room
> info sheet) what the public key is for the DHCP server, then configure 
> this on your DHCP client, and know that you're getting an address from 
> a legitimate server.
> 

The architecture described in the current current draft permits the use of
public key.  All someone has to do is submit a draft to support PK- I
think Olafur once said he was going to do that! :-)



From owner-dhcp-v4@bucknell.edu  Mon Jul 31 21:19:14 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22784
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 21:19:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e711DNi31795;
	Mon, 31 Jul 2000 21:13:23 -0400 (EDT)
Received: from kitab.cisco.com (wireless-133-25.ietf.marconi.com [147.73.133.25])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e711DFi30929
	for <dhcp-v4@bucknell.edu>; Mon, 31 Jul 2000 21:13:15 -0400 (EDT)
Received: (from raj@localhost)
	by kitab.cisco.com (8.9.3/8.9.2) id VAA01044;
	Mon, 31 Jul 2000 21:13:48 -0700 (PDT)
	(envelope-from raj)
From: Richard Johnson <raj@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14726.20091.321140.372140@kitab.cisco.com>
Date: Mon, 31 Jul 2000 21:13:47 -0700 (PDT)
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: Question re. DHCP auth. draft
In-Reply-To: <Pine.SOL.4.21.0007312108500.19846-100000@codex.cis.upenn.edu>
References: <14725.47959.37256.738608@kitab.cisco.com>
	<Pine.SOL.4.21.0007312108500.19846-100000@codex.cis.upenn.edu>
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Reply-To: raj@cisco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

William A. Arbaugh writes:
 > The architecture described in the current current draft permits the use of
 > public key.  All someone has to do is submit a draft to support PK- I
 > think Olafur once said he was going to do that! :-)

Thanks.  I came to that conclusion in my last post.

/raj



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 22:50:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11505
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 22:50:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e712iAi22687;
	Mon, 31 Jul 2000 22:44:10 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e712hsi04925
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 22:43:54 -0400 (EDT)
Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf])
	by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA20766
	for <dhcp-v6@bucknell.edu>; Tue, 1 Aug 2000 11:29:28 +0900 (JST)
Date: Tue, 01 Aug 2000 11:39:43 +0900
Message-ID: <y7vk8e1d7rk.wl@condor.isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6, tues discussion point #6
In-Reply-To: In your message of "Sun, 30 Jul 2000 21:07:48 -0700"
	 <3984FB94.AB19776F@eng.sun.com>
References: <3984FB94.AB19776F@eng.sun.com>
User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 980905(IM100)
Lines: 14
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>>>>> On Sun, 30 Jul 2000 21:07:48 -0700, 
>>>>> "Michael W. Carney" <Michael.Carney@eng.sun.com> said:

> 6) We have a request to clarify client behavior upon reciept of Reply
> messages w/ non-zero status. Perhaps a table showing behavior for each
> status value. Comments?

Yes, I think it is a good idea. FYI: the current KAME's implementation
just discards (and warns) packets with non-zero status.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp



From owner-dhcp-v6@bucknell.edu  Mon Jul 31 23:05:24 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13274
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 31 Jul 2000 23:05:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e7132Fi04706;
	Mon, 31 Jul 2000 23:02:15 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e7132Bi05232
	for <dhcp-v6@bucknell.edu>; Mon, 31 Jul 2000 23:02:11 -0400 (EDT)
Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf])
	by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA20812
	for <dhcp-v6@bucknell.edu>; Tue, 1 Aug 2000 11:47:48 +0900 (JST)
Date: Tue, 01 Aug 2000 11:58:03 +0900
Message-ID: <y7vittld6x0.wl@condor.isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6, tues discussion point #10
In-Reply-To: In your message of "Sun, 30 Jul 2000 21:12:14 -0700"
	 <3984FC9E.C3DA1A59@eng.sun.com>
References: <3984FC9E.C3DA1A59@eng.sun.com>
User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 980905(IM100)
Lines: 14
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>>>>> On Sun, 30 Jul 2000 21:12:14 -0700, 
>>>>> "Michael W. Carney" <Michael.Carney@eng.sun.com> said:

> 10) We've had requests for client and server implementation state
> diagrams.  Would people find these useful, or is the draft enough?

Diagrams are always useful, but I'm not sure if this is really worth
additional work for the authors. If it's too heavy, I think we can
deal with the spec without diagrams.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp