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 11:00:11 -0600

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] <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] <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] <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 <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 <https://www1.ietf.org/mailman/listinfo/dhcwg>

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Thu, 20 Feb 2003 17:46:07 +0530

Sure, the server doesn't need to parse the value in these options,
rather it can note down the option number, skip the option
without processing it and in the reply, it sends back the
"correct" information for that option. I dont think that there is
any harm in allowing this.
~Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bernie
Volz (EUD)
Sent: Wednesday, February 19, 2003 10:30 PM
To: [email-masked]'; 'Ralph Droms'; [email-masked]
Subject: RE: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.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: [email-masked] [mailto:[email-masked]]On Behalf Of Bernie
Volz (EUD)

-----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,
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bernie
Volz (EUD)

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

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

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Feb 2003 09:08:38 -0700

> any harm in allowing this.

I agree with you that it's not too hard for the server to go through 
the options the client sent and make a list from that.   The problem is 
that you're creating additional implementation work and getting no 
additional benefit in exchange for that work, so it doesn't matter how 
easy it is.   Are you familiar with the phrase, "pecked to death by 
ducks?"   The idea is that each individual peck isn't particularly 
painful, but when you're pecked enough times, it kills you.

If a client might request the NISconfig option by sending it, then the 
server has to look to see if the client did this, and has to tweak its 
list of options to send accordingly.   Whereas if the ORO is the only 
way to request an option, then the server doesn't have to do this 
additional work.   So no duck peck.

So as Bernie has said, the right way to do this is to _only_ use the 
ORO to request options.

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

This one is okay by me.

> 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
This one is not.

> It doesn't make sense on keeping combination of the both, with
> server allowing the clients to send these options and ignoring
> it.

The only reason it would make sense to allow the client to send the 
option would be if there were some meaning to the client sending it - 
e.g., if it made sense for the client to tell the server what NIS 
server it wanted, or something like that.   Since the draft doesn't 
specify anything like that (and I don't think it should - again, it 
would add needless complexity) - it's probably fine to just forbid the 
client from sending the option.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Feb 2003 12:15:37 -0500

I think we already have definitive text in the DHCPv6 base spec, section 
17.1.1:

    The client SHOULD include an Option Request option (see section 22.7)
    to indicate the options the client is interested in receiving.  The
    client MAY additionally include instances of those options that are
    identified in the Option Request option with data values as hints
    to the server about parameter values the client would like to have
    returned.

The phrase "additionally include instances of those options that are 
identified in the Option Request option" specifically prohibits the 
inclusion of an option if that option is not identified in the Option 
Request option...

- Ralph

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 21 Feb 2003 02:35:41 +0900

>>>>> On Thu, 20 Feb 2003 12:15:37 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

> inclusion of an option if that option is not identified in the Option 

Hmm, does this also apply to IA or IA_PD options?  Section 17.1.1
explicitly says an IA option is included in Solicit (if the client
wants an address for the IA):

   The client includes IA options for any IAs to which
   it wants the server to assign addresses.

The prefix delegation draft even has a stronger sentence:

   The requesting router creates an IA_PD and assigns it an IAID.  The
   requesting router MUST include the IA_PD option in the Solicit
   message.
(Section 10.1 of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt)

Is the client also required to include an option request option
specifying an IA or IA_PD option?

FYI: Our implementation does not include an Option request option for
IA_PD option, but I've never seen any interoperability issue with
regards to this behavior.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg