Subject: [dhcwg] Last Call: 'DHCP Options for Broadcast and Multicast Control Servers' to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 16 Jun 2005 16:53:42 -0400

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

- 'DHCP Options for Broadcast and Multicast Control Servers '
   <draft-ietf-dhc-bcmc-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
[email-masked] or [email-masked] mailing lists by 2005-06-30.

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

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Jun 2005 14:13:07 -0700

There's a small bug in this draft; I apologize for not catching it  
earlier:

4.6  Consideration for Server Operation

    A server MAY send a client either the Broadcast Service Controller
    Domain Name List Option or the Broadcast Service Controller IPv6
    Address/IPv4 Address options if the server is configured to do so.

[...]

    The following table summarizes the server's response for DHCPv6:

       Client sends in ORO     Domain Name List        IPv6 Address List
        
__________________________________________________________________

       Neither option          SHOULD                  MAY
       Domain Name List        MUST                    MAY
       IPv6 Address            MAY                     MUST
       Both options            SHOULD                  MAY

I think the above table goes too far in specifying MUST in the cases  
where it specifies MUST, and in specifying SHOULD in the case where  
neither option is requested in the ORO.   I don't think the table is  
needed, but if it is, the two MUSTs MUST be changed to SHOULDs, and  
the top SHOULD SHOULD be changed to a MAY.   My preference would be  
to just delete the table.   My reasoning here is that the MUSTs and  
the SHOULD I'm talking about go beyond the behavior specified in  
RFC3315.   RFC3315 doesn't specify any MUSTs regarding the ORO, and  
says the server MAY include options that were not requested.

I think it's fine to *suggest* that the server implement special-case  
code here, but the table as written *requires* that the server  
implement special case code specifically for handling these two  
options with respect to the ORO.

Again, sorry for the very belated comment.   Mea maxima culpa.   :'(