DHCP server supports BOOTP client

In RFC 1534, Section 2. BOOTP clients and DHCP servers
	In summary, a DHCP server:
	. May suppport BOOTP client

In RFC 2131, section 1.6 Design goals
	. DHCP must provide service to existing BOOTP clients.

It's confused, which one we need to follow?

--

-- 
Thanks
Shirley Ma
IBM Linux Technology Center

Minutes from interim dhc WG meeting

Attached are the minutes from two phone calls held by the dhc WG to discuss
draft-ietf-dhc-implementation-01.txt, which addresses issues identified by
implementors of RFC 2131.  The phone calls took place 2004-02-23 and
2004-02-25.

The minutes include a list of participants on each phone call.

My apologies for the late submission.  I wrote up the notes and submitted
them for review to the call participants, but neglected to follow up by
formally submitting the minutes...

- Ralph

       Minutes from conf call on RFC2131 implementation issues
			     Wed 2/25/04
       -------------------------------------------------------

Participants: Ralph Droms (rdroms <at> cisco.com)
              Barr Hibbs (rbhibbs <at> pacbell.net)
              Kim Kinnear (kkineear <at> cisco.com)
              Andre Kostur (Andre <at> incognito.com)
              Rob Stevens (robs <at> cruzio.com)

Inclusion of DHCPINFORM in specifications
-----------------------------------------

The design team affirmed the previous decision not to add DHCPINFORM
to the state machine in RFC2131.  There may be a need to revisit the
definition of when to use DHCPINFORM, based on work elsewhere on
"detecting network attachment" (DNA) and recognizing that applications

RE: DHCP server supports BOOTP client

I think the correct interpretation would be that the server MUST
be able to support BOOTP clients, but the system administrator
MUST be able to determine how BOOTP requests are handled.

If you re-read Section 2, Paragraph 1 of RFC 1534, I think you'll
see that this interpretation is implied.

There appears to be a consensus on this because most DHCP servers
do it this way.

--kan--

> -----Original Message-----
> From: dhcwg-admin <at> ietf.org [mailto:dhcwg-admin <at> ietf.org]On Behalf Of
> Shirley Ma
> Sent: Monday, 03 May, 2004 2:09 PM
> To: dhcwg <at> ietf.org
> Subject: [dhcwg] DHCP server supports BOOTP client
> 
> 
> In RFC 1534, Section 2. BOOTP clients and DHCP servers
> 	In summary, a DHCP server:
> 	. May suppport BOOTP client
> 
> In RFC 2131, section 1.6 Design goals
> 	. DHCP must provide service to existing BOOTP clients.
> 
> It's confused, which one we need to follow?
> 

Re: DHCP server supports BOOTP client

The two statements are subtly different.  The design goal from RFC 2131
(which is not particularly well-worded) is aimed at compatibility of the
DHCP specification with BOOTP clients.  The statement from RFC 1534 is
intended to allow but not require that any specific DHCP server provide
BOOTP service.

A DHCP server can be compliant with RFC 2131 without providing service
to BOOTP clients...

- Ralph

At 11:08 AM 5/3/2004 -0700, Shirley Ma wrote:
>In RFC 1534, Section 2. BOOTP clients and DHCP servers
>         In summary, a DHCP server:
>         . May suppport BOOTP client
>
>In RFC 2131, section 1.6 Design goals
>         . DHCP must provide service to existing BOOTP clients.
>
>It's confused, which one we need to follow?
>
>--
>Thanks
>Shirley Ma
>IBM Linux Technology Center
>
>_______________________________________________
>dhcwg mailing list
>dhcwg <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

About DHCP!

RE: dhc WG last call on draft-ietf-dhc-rapid-commit-opt

I have received below comments on this draft during 2nd WGLC
and modifying it.

- editorial comment: s/physical/physical subnet in Section 3.1
- word strength: s/SHOULD/MUST in Section 4
- Regarding RFC-2131 text, it still remains without change.

clear enough for moving forward ? or anything else ?

Regards.

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 

> -----Original Message-----
> From: dhcwg-admin <at> ietf.org [mailto:dhcwg-admin <at> ietf.org] On 
> Behalf Of Ralph Droms
> Sent: Wednesday, April 21, 2004 12:30 AM
> To: dhcwg <at> ietf.org
> Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt
> 
> 
> This message announces a WG last call on "Rapid Commit Option 
> for DHCPv4"
> <draft-ietf-dhc-rapid-commit-opt>.  The last call will 
> conclude at 5PM EDT
> on 4/30/2004.
> 
> Please respond to this WG last call.  If you support acceptance of the
> document without change, respond with a simple acknowledgment, so that
> support for the document can be assessed.  Note that this is a new
> last call on this document, which was revised after comment recieved
> during the WG last call that ended on 4/15/2004.
> 
> draft-ietf-dhc-rapid-commit-opt defines a new DHCPv4 option, 
> modeled on
> the DHCPv6 Rapid Commit option, for obtaining IP address and 
> configuration
> information using a 2-message exchange rather than the usual 
> 4- message
> exchange, expediting client configuration.  This draft is available as
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commi
t-opt-02.txt

- Ralph Droms 

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

Re: Minutes from interim dhc WG meeting

Ralph,

I need to put a choice to you about the inclusion of the interim minutes to 
the IETF-59 Proceedings.

I can either:

1.  Include the interim minutes to the DHC wg page 
(http://www.ietf.org/proceedings/04mar/135.htm ) after the slides section 
with out giving your group time to approve the contents, before the making 
of the Master CD-Rom for these proceedings.

or

2.  Make the Master CD-Rom with the existing information of the IETF 
Proceedings and include the interim minutes only on the Web-Version of the 
Proceedings.

Today is the day that I make the CD-Rom for mass production.  I'm afraid to 
delay the production, to allow your group time to give approval for the 
changes to your groups page.

Please let me know your decision ASAP today.  If you have any other 
questions, please feel free to contact me directly.

Thank you.

At 02:09 PM 5/3/2004, Ralph Droms wrote:
>Attached are the minutes from two phone calls held by the dhc WG to discuss
>draft-ietf-dhc-implementation-01.txt, which addresses issues identified by
>implementors of RFC 2131.  The phone calls took place 2004-02-23 and
>2004-02-25.
>
>The minutes include a list of participants on each phone call.
>
>My apologies for the late submission.  I wrote up the notes and submitted
>them for review to the call participants, but neglected to follow up by
>formally submitting the minutes...
>
>- Ralph
>
>

Rebecca F. Bunch

Re: Re: Minutes from interim dhc WG meeting

Rebecca - the participants in the interim meeting have already reviewed and
approved the minutes, so they should be OK for inclusion in the IETF-59
proceedings.

So, if it's not too late, please go ahead and include the minutes from the
interim meeting in the IETF 59 proceeding CD-ROM.

Thanks...

- Ralph

At 09:48 AM 5/6/2004 -0400, Rebecca Bunch wrote:

>Ralph,
>
>I need to put a choice to you about the inclusion of the interim minutes 
>to the IETF-59 Proceedings.
>
>I can either:
>
>1.  Include the interim minutes to the DHC wg page 
>(http://www.ietf.org/proceedings/04mar/135.htm ) after the slides section 
>with out giving your group time to approve the contents, before the making 
>of the Master CD-Rom for these proceedings.
>
>or
>
>2.  Make the Master CD-Rom with the existing information of the IETF 
>Proceedings and include the interim minutes only on the Web-Version of the 
>Proceedings.
>
>Today is the day that I make the CD-Rom for mass production.  I'm afraid 
>to delay the production, to allow your group time to give approval for the 
>changes to your groups page.
>
>Please let me know your decision ASAP today.  If you have any other 
>questions, please feel free to contact me directly.
>
>Thank you.
>
>
>At 02:09 PM 5/3/2004, Ralph Droms wrote:
>>Attached are the minutes from two phone calls held by the dhc WG to discuss
>>draft-ietf-dhc-implementation-01.txt, which addresses issues identified by
>>implementors of RFC 2131.  The phone calls took place 2004-02-23 and
>>2004-02-25.
>>
>>The minutes include a list of participants on each phone call.
>>
>>My apologies for the late submission.  I wrote up the notes and submitted
>>them for review to the call participants, but neglected to follow up by
>>formally submitting the minutes...
>>
>>- Ralph
>>
>
>Rebecca F. Bunch
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

Review requested: draft-daniel-dhc-ipv6in4-opt-03.txt

(co-chair hat on)

DHC WG is considering whether to adopt
draft-daniel-dhc-ipv6in4-opt-03.txt as their work item for signalling
IPv6-in-IPv4 endpoint in DHCPv4.  DHC WG has asked to get feedback
whether this would be applicable in the IPv6 transition process.

For a more generic look on the tunnel end-point discovery, please have
a look at draft-palet-v6ops-tun-auto-disc-00.txt (feedback is welcome
on that on v6ops list as well, but please use a separate thread).

So,

 (1) please review the document and send feedback on v6ops list, or 
     both v6ops and dhc lists.

 (2) please consider whether this would be applicable in the 
     transition process and send feedback to v6ops list.  In 
     particular, please consider at least:

      a. which scenario(s) would this be applicable to?
      b. which mechanism(s) would this be applicable to?
      c. if multiple mechanisms, would it be needed to distinguish 
         which mechanism's end-point this is applicable to?
      d. what more is needed to make this applicable as this 
         only solves one part of the problem (i.e., how does the 
         server end configure the tunnel, i.e., learn the client's 
         IPv4 address?)
      e. whether we have yet enough knowledge of these issues
         to go forward and specifying the option, or whether
         we should work e.g., on the mechanisms first.

Please send feedback within a week, by 17th May.

(hat off)

For what it's worth, my personal take is that this is work that may be
worth doing, but it is still too early to take it as dhc WG item,
because there are still too many unknowns on the field especially
regarding:

 - which specific mechanisms this would be applicable to (2.c), and 
 - we don't have all the pieces of the puzzle in order yet (2.d).

Last Call: 'Reclassifying DHCPv4 Options' to Proposed Standard

The IESG has received a request from the Dynamic Host Configuration WG to 
consider the following document:

- 'Reclassifying DHCPv4 Options '
   <draft-ietf-dhc-reclassify-options-01.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2004-05-24.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dhc-reclassify-options-01.txt