Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 19 Feb 2003 16:15:52 -0600

Vijay:

The -28 draft says in 17.2.2. Creation and Transmission of Advertise Messages:

   The server includes options the server will return to the client in
   a subsequent Reply message.  The information in these options may
   be used by the client in the selection of a server if the client
   receives more than one Advertise message.  If the client has included
   an Option Request option in the Solicit message, the server includes
   options in the Advertise message containing configuration parameters
   for all of the options identified in the Option Request option
   that the server has been configured to return to the client.  The
   server MAY return additional options to the client if it has been
   configured to do so.  The server SHOULD limit the options returned to
   the client so that the DHCP message header and options do not cause
   fragmentation.

And, also in 18.2. Server Behavior:

   In most Reply messages, the server includes options containing
   configuration information for the client.  The server SHOULD limit
   the options returned to the client so that the DHCP message header
   and options do not cause fragmentation.  If the client included an
   Option Request option in its message, the server includes options
   in the Reply message containing configuration parameters for all of
   the options identified in the Option Request option that the server
   has been configured to return to the client.  The server MAY return
   additional options to the client if it has been configured to do so.

In neither case is your (i) implied. The text says include the ORO options
first and then send any other options specified by the server's configuration.

I don't see a need to clarify this further in -28, but perhaps you (or
others) do?

- Bernie

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Wednesday, February 19, 2003 12:00 PM
To: [email-masked]'; 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0 1.txt

I would prefer (ii). A server should not be required to also go through a packet to see what options the
client sent to send the "correct" information.

The ORO mechanism is the way for a client to request certain options and it should be the only
mechanism. It simplifies implementations.

If a client sends an option (such as NIS server info), the server should just ignore it. If that option is
in the ORO, the server should send back the configured information to the client.

NOTE: The above applies only to those options which are essentially server to client configuration
options. 

- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:[email-masked]]
Sent: Wednesday, February 19, 2003 10:39 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt

Bernie,
I agree that client sending this option is no useful to server,
we can stick to ORO. In the case if we decide not to 
prohibit client sending these options,
if the client sends these options, 
(i) do the server need
to reply back with the correct values of these options?
(or)
(ii) make the server reply only if the option number is
filled in ORO option, thus just ignoring the client sending
these options.
I beleive, (i) is better.
If we decide (ii) then there is no meaning in not prohibiting 
client to send these options. Though, there is no harm
in prohibiting the clients to send these options, because, 
it can anyway get the values using ORO.
~Vijay
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bernie Volz (EUD)
Sent: Tuesday, February 18, 2003 8:55 PM
To: [email-masked]'; 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt

Personally, I would like to see clients NOT send options to the 
server but instead just send an ORO option. I see little value in 
sending the NIS server info to the server - it just increases the 
packet size and work a server must do to ignore these. ORO is the 
mechanism to request that a server send an option; not sending the 
option to the server. 
For DHCPv4, is there any server that checks options sent by the 
client to make sure that what it send is valid? What would a server 
do if it isn't valid - just send the correct value? So, it seems to 
me ORO is the way to go. Now, of course there are options that must 
be sent by the client, such as IA options since they carry information 
from the client to the server (such as the IAID). 
I don't think we need to PROHIBIT a client from sending the option; 
but we should not encourage it. A server that receives "unknown" 
options should just ignore them. 
- Bernie 
-----Original Message----- 
From: Vijayabhaskar A K [mailto:[email-masked]] 
Sent: Tuesday, February 18, 2003 7:36 AM 
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; [email-masked] 
Subject: RE: [dhcwg] WG last call on 
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt 

Bernie, 
Thanks for your comments.... 
See my reply inline, prefixed by VJ. 
~Vijay 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bernie 
Volz (EUD) 
Sent: Tuesday, February 18, 2003 2:30 AM 
To: 'Ralph Droms'; [email-masked] 
Subject: RE: [dhcwg] WG last call on 
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt 

I fully support the approval of this document for publication. 
However, I would recommend we review the following section: 
8. Appearance of these option 
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name 
   options MUST appear only in the following messages: Solicit, 
   Advertise, Request, Confirm, Renew, Rebind, Information-Request, 
   Reply. 
VJ> Basically, sending these options in messages originating from the 
VJ> client is for asking the server to provide these information. 
VJ> Its the alternative way of sending ORO with the option number for these 
options. 
VJ> We may want to make a decision here that these options can occur 
VJ> ONLY in messages originating from server and the client can 
VJ> indicate the server that it want any of these options by sending ONLY 
VJ> ORO option, because, client sending these options is of 
VJ> no interest in the server side, since, its not going to make 
VJ> any major decision based on the content of this option. 
VJ> But, it SHOULD be made consistent with ALL service addresses/parameters 
options. 
Based on earlier text, these options are for the server to convey 
information 
to clients and therefore perhaps text as follows is more appropriate: 
   The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name 
   options MUST appear only in the Advertise and Reply messages. The 
   option numbers for these options may appear in the Option Request 
   Option [2] in Solicit, Request, Renew, Rebind, Information-Request, 
   and Reconfigure messages. 
VJ> I will add. 
Or, we want a client to send these options in Request, Renew, Rebind to 
a server as well? 
In any case, there is little need for this option itself in Solicit and 
Confirm (based on the original text). And, some mention of use of the 
ORO option (at least in Reconfigure) may be appropriate? 
VJ> OK. I will add. 
- Bernie 
-----Original Message----- 
From: Ralph Droms [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2003 3:25 PM 
To: [email-masked] 
Subject: [dhcwg] WG last call on 
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt 

This message announces a WG last call on "NIS Configuration Options 
for DHCPv6" <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>.  The last call 
will conclude on Friday, 2/28. 
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt specifies four DHCPv6 options 
for configuration information related to Network Information Service 
(NIS).  This draft is available as 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.t 
xt 
- Ralph Droms 

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

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Thu, 20 Feb 2003 18:00:58 +0530

Bernie,
I agree that it doesn't imply that.
But this will make the server to ignore an option, for which it
has a valid information and supports it. It doesn't make sense.
If we are going to ignore the option in server side, then
whats the point to "allowing" (Note: i didn't mean "encouraging")
the client to send this option to the server? Its just
going to eatup some bytes of packet.
We have to make decision on either of the following two
i) prohibit the clients to send these options and ignore these
options in the server (to cope up with non RFC conformant clients)
ii) allow client to send these options and let server reply
with the correct values, as if these option numbers were
present in ORO option that client has sent
It doesn't make sense on keeping combination of the both, with
server allowing the clients to send these options and ignoring
it.
~Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bernie
Volz (EUD)
Sent: Thursday, February 20, 2003 3:46 AM
To: [email-masked]'; 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0
1.txt

Vijay:
The -28 draft says in 17.2.2. Creation and Transmission of Advertise
Messages:
first and then send any other options specified by the server's
configuration.
-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Wednesday, February 19, 2003 12:00 PM
To: [email-masked]'; 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-nisconfig-0
1.txt

I would prefer (ii). A server should not be required to also go through a
packet to see what options the
client sent to send the "correct" information.
The ORO mechanism is the way for a client to request certain options and it
should be the only
mechanism. It simplifies implementations.
If a client sends an option (such as NIS server info), the server should
just ignore it. If that option is
in the ORO, the server should send back the configured information to the
client.
NOTE: The above applies only to those options which are essentially server
to client configuration
options.
- Bernie
-----Original Message-----
From: Vijayabhaskar A K [mailto:[email-masked]]
Sent: Wednesday, February 19, 2003 10:39 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] WG last call on

Bernie,

-----Original Message-----
From: Vijayabhaskar A K [mailto:[email-masked]]
Sent: Tuesday, February 18, 2003 7:36 AM
To: 'Bernie Volz (EUD)'; 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] WG last call on

Bernie,