Index: [Article Count Order] [Thread]

Date: Fri, 15 Jun 2007 09:52:02 +0900
From: <Hideshi.Enokihara@jp.yokogawa.com>
Subject: [dhcptest:00182] Re: FW:  Re: Tests that check for DNS and Domain Search Options
To: <slangley@tadboise.com>
Cc: <dhcptest@tahi.org>
Message-Id: <0260031F55435342859BFB2CCA6773D81B898B6F@EXCHANGE03.jp.ykgw.net>
In-Reply-To: <04654E52DE5D8D47906217E3D32FA976073C6D@sbserver.tadboise.com>
X-Mail-Count: 00182

Hello Scott, I'm sorry for my delay response.  Do you mean that both of these tests was PASS when your product included the both Domain Recursive Name Server optionand Domain Search List option.         C_RFC3646_5_InvDecDnsSchLstOpt.seq         C_RFC3646_5_InvDecDnsSvrOpt.seq I would like to know detailed situation. Could you send me the logo, please?#You can use contact@tahi.org in such report. Thank you for your cooperation. regards, ________________________________	From: Scott Langley [mailto:slangley@tadboise.com] 	Sent: Wednesday, June 06, 2007 11:53 AM	To: Enokihara, Hideshi (Hideshi.Enokihara@jp.yokogawa.com)	Cc: dhcptest@tahi.org	Subject: RE: FW: [dhcptest:00173] Re: Tests that check for DNSand Domain Search Options			Hi Hideshi,		I think I agree with your thoughts about what the tests shoulddo. 		The problem is that our client device does include options 23and 24 in its Decline packets - and yet the Tahi Tests reports that they"PASS" these tests.  I would expect our product to fail these tests.		Regards,		Scott		-----Original Message-----	From: Hideshi.Enokihara@jp.yokogawa.com[mailto:Hideshi.Enokihara@jp.yokogawa.com]	Sent: Tue 6/5/2007 7:07 PM	To: Scott Langley	Cc: dhcptest@tahi.org	Subject: RE: FW: [dhcptest:00173] Re: Tests that check for DNSand Domain Search Options		Hello Scott,		Thank you for your report.		But, these tests that you mentioned are correct, I think.		These tests focus on following statements in RFC 3646.		----------------------------	5.  Appearance of these options		   The DNS Recursive Name Server option MUST NOT appear in anyother	   than the following messages: Solicit, Advertise, Request,Renew,	   Rebind, Information-Request, and Reply.		   The Domain Search List option MUST NOT appear in any otherthan the	   following messages: Solicit, Advertise, Request, Renew,Rebind,	   Information-Request, and Reply.	----------------------------		So, these tests really expect that the message does not includeDNS	Recursive Name Server option/Domain Search List option.		regards,	...Hideshi	________________________________		        From: Scott Langley [mailto:slangley@tadboise.com]	        Sent: Wednesday, June 06, 2007 2:17 AM	        To: Enokihara, Hideshi(Hideshi.Enokihara@jp.yokogawa.com)	        Cc: dhcptest@tahi.org	        Subject: RE: FW: [dhcptest:00173] Re: Tests that checkfor DNS	and Domain Search Options	       	       		        Hi Hideshi,	       	        The revised files you sent do appear to work properly.	       	        However, I think there are a few more tests that haveproblems.	       	        These two test pass, even though our DECLINE messagesinclude	both options 23 and 24:	       	         C_RFC3646_5_InvDecDnsSchLstOpt.seq	         C_RFC3646_5_InvDecDnsSvrOpt.seq	       	        I suspect that the options_exist() method ofDHCPv6_common.pm	may be flawed.	       	        These four other tests, below, are similarly written,but I	can't say if there is anything wrong with them because ourproduct	doesn't yet send CONFIRM and RELEASE messages when it should:	       	         C_RFC3646_5_InvCnfDnsSchLstOpt.seq	         C_RFC3646_5_InvCnfDnsSvrOpt.seq	         C_RFC3646_5_InvRelDnsSchLstOpt.seq	         C_RFC3646_5_InvRelDnsSvrOpt.seq	       	        Thanks.	       	        --	        Scott Langley	        Adecco Technical	        slangley@tadboise.com	       	       	        -----Original Message-----	        From: Hideshi Enokihara	[mailto:Hideshi.Enokihara@jp.yokogawa.com]	        Sent: Mon 6/4/2007 7:15 PM	        To: Scott Langley	        Cc: dhcptest@tahi.org	        Subject: Re: FW: [dhcptest:00173] Re: Tests that checkfor DNS	and Domain Search Options	       	        Hello Scott,	       	        Thank you for your report.	       	        Please use attached files instead of original files.	        Then, could you let me know that these scripts work wellor not,	please?	       	        Thank you for your cooperation.	       	        Regards,	        ...Hideshi	       	        On Tue, 5 Jun 2007 09:48:46 +0900	        <Hideshi.Enokihara@jp.yokogawa.com> wrote:	       	        >	        >	        > -----Original Message-----	        > From: Scott Langley [mailto:slangley@tadboise.com]	        > Sent: Tuesday, June 05, 2007 9:44 AM	        > To: dhcptest@tahi.org	        > Subject: RE: [dhcptest:00173] Re: Tests that check forDNS and	Domain	        > Search Options	        >	        > Hi Hideshi,	        >	        > These are probably the test that would fail due tothis	reason, from the	        > results of doing a grep search:	        >	        > PCBSD# grep '!= 23' *.seq	        >	        > C_RFC3646_3_DnsSvrOpt.seq:if($sol{$optionCode} != 23){	        > C_RFC3646_3_DnsSvrOpt_Reb.seq:if($reb{$optionCode} !=23){	        > C_RFC3646_3_DnsSvrOpt_Ren.seq:if($ren{$optionCode} !=23){	        > C_RFC3646_3_DnsSvrOpt_Req.seq:if($req{$optionCode} !=23){	        > C_RFC3646_3_DnsSvrOpt_Sol.seq:if($sol{$optionCode} !=23){	        >	        > PCBSD# grep '!= 24' *.seq	        >	        > C_RFC3646_3_DnsSchLstOpt_Reb.seq:if($reb{$optionCode}!= 24){	        > C_RFC3646_3_DnsSchLstOpt_Ren.seq:if($ren{$optionCode}!= 24){	        > C_RFC3646_3_DnsSchLstOpt_Req.seq:if($req{$optionCode}!= 24){	        > C_RFC3646_3_DnsSchLstOpt_Sol.seq:if($sol{$optionCode}!= 24){	        > C_RFC3646_4_DnsSchLstOpt.seq:if($sol{$optionCode} !=24){	        >	        >	        > -----Original Message-----	        > From: Hideshi.Enokihara@jp.yokogawa.com	        > [mailto:Hideshi.Enokihara@jp.yokogawa.com]	        > Sent: Mon 6/4/2007 6:14 PM	        > To: dhcptest@tahi.org	        > Subject: [dhcptest:00173] Re: Tests that check for DNSand	Domain Search	        > Options	        >	        > Hello Scott,	        >	        > Yes, we have to fix these bugs as soon as possible.	        > Could you let me know the numbers (or titles) of thetests, if	you have	        > time, please?	        > It will help us to fix the bugs.	        >	        > regards,	        > ...Hideshi	        >	        >	        > ________________________________	        >	        >       From: Bernie Volz (volz) [mailto:volz@cisco.com]	        >       Sent: Tuesday, June 05, 2007 5:33 AM	        >       To: dhcptest@tahi.org	        >       Subject: [dhcptest:00172] Re: Tests that checkfor DNS	and	        > Domain Search Options	        >     	        >     	        >       Order of the options should not matter (eitherin the	ORO or in	        > the Advertise/Reply). So, if the test code is orderdependent,	it should	        > be fixed.	        >      	        >       - Bernie	        >	        > ________________________________	        >	        >       From: Scott Langley[mailto:slangley@tadboise.com]	        >       Sent: Monday, June 04, 2007 3:56 PM	        >       To: dhcptest@tahi.org	        >       Subject: [dhcptest:00171] Tests that check forDNS and	Domain	        > Search Options	        >     	        >     	        >	        >       Hello,	        >     	        >       Many of the tests in the RFC 3646 and RFC 3736sections	of the	        > DHCPv6 Self Test Suite 1.01 (and earlier) are failingfor us	for the	        > wrong reason.	        >     	        >       The way our (client) product is currentlybehaving it	requests	        > these options:	        >     	        >       13 OPTION_STATUS_CODE	        >       12 OPTION_UNICAST	        >       23 OPTION_DNS_SERVERS	        >       24 OPTION_DOMAIN_LIST	        >        7 OPTION_PREFERENCE	        >     	        >       Many tests, for example, RFC 3646 - Test	DHCP_CONF.4.1.1: Option	        > Request option Format	        >       PartA: Option request Option Format(DNSRecursive Name	Server	        > option)	        >     	        >       fail because option 13 is not option 23,according to	the code:	        >     	        >       if($sol($optionCode != 23) {	        >         # Logging of failure message.	        >       }	        >     	        >       Shouldn't the test be re-written to checkwhether or not	option	        > 23 is among the options requested	        >       rather than whether or not it is the firstoption	requested?	        >     	        >       Also, I know our client shouldn't be requestingoption	12,	        > Server Unicast, as that option should only appear inReply	messages	        > coming from a server.  I don't think you have anytests yet	that check	        > for the appearance of options in different messagetypes as	described in	        > Appendix A of RFC3315.	        >     	        >       http://tools.ietf.org/html/rfc3315#page-98	        >     	        >       Thanks.	        >     	        >       Scott Langley	        >       Adecco Technical	        >       slangley@tadboise.com	        >     	        >     	        >	        >	        >	       	       	        --	        *************************************	        Hideshi Enokihara	        IPv6 Business	        Network & Software Development Dept.	        Yokogawa Electric Corporation	       	       			
	

182_2.html (attatchment)(tag is disabled)