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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 18 Feb 2003 09:24:32 -0600

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: Wed, 19 Feb 2003 21:09:14 +0530

RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txtBernie,
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

  - 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,

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Bernie
  Volz (EUD)

  VJ> Its the alternative way of sending ORO with the option number for
these
  VJ> But, it SHOULD be made consistent with ALL service
addresses/parameters
  options.

  VJ> I will add.

  VJ> OK. I will add.

  - Bernie