<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Tests that check for DNS and Domain Search =
Options</TITLE>
<META http-equiv=Content-Type content="text/html; =
charset=us-ascii">
<META content="MSHTML 6.00.2900.3086" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=065313120-04062007><FONT =
face=Arial
color=#0000ff size=2>Order of the options should not matter (either =
in the ORO
or in the Advertise/Reply). So, if the test code is order dependent, it =
should
be fixed.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=065313120-04062007><FONT =
face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=065313120-04062007><FONT =
face=Arial
color=#0000ff size=2>- Bernie</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Scott Langley
[mailto:slangley@tadboise.com] <BR><B>Sent:</B> Monday, June 04, 2007 =
3:56
PM<BR><B>To:</B> dhcptest@tahi.org<BR><B>Subject:</B> [dhcptest:00171] =
Tests
that check for DNS and Domain Search Options<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/plain format -->
<P><FONT size=2>Hello,<BR><BR>Many of the tests in the RFC 3646 and =
RFC 3736
sections of the DHCPv6 Self Test Suite 1.01 (and earlier) are failing =
for us for
the wrong reason.<BR><BR>The way our (client) product is currently =
behaving it
requests these options:<BR><BR>13 OPTION_STATUS_CODE<BR>12 =
OPTION_UNICAST<BR>23
OPTION_DNS_SERVERS<BR>24 OPTION_DOMAIN_LIST<BR> 7
OPTION_PREFERENCE<BR><BR>Many tests, for example, RFC 3646 - Test
DHCP_CONF.4.1.1: Option Request option Format<BR>PartA: Option request =
Option
Format(DNS Recursive Name Server option)<BR><BR>fail because option 13 =
is not
option 23, according to the code:<BR><BR>if($sol($optionCode != 23) =
{<BR> # Logging of failure message.<BR>}<BR><BR>Shouldn't the test be =
re-written to
check whether or not option 23 is among the options requested<BR>rather =
than
whether or not it is the first option requested?<BR><BR>Also, I know our =
client
shouldn't be requesting option 12, Server Unicast, as that option should =
only
appear in Reply messages coming from a server. I don't think you =
have any
tests yet that check for the appearance of options in different message =
types as
described in Appendix A of RFC3315.<BR><BR><A
href="http://tools.ietf.org/html/rfc3315#page-98">http://tools.ietf.org=
/html/rfc3315#page-98</A><BR><BR>Thanks.<BR><BR>Scott
Langley<BR>Adecco
Technical<BR>slangley@tadboise.com<BR><BR></FONT></P></BODY></HTML>