Hello Peter,
Please find my comment in lines.
> -----Original Message-----
> From: Peter Carney [mailto:pcarney@treck.com]
> Sent: Tuesday, June 19, 2007 2:29 AM
> To: Enokihara, Hideshi (Hideshi.Enokihara@jp.yokogawa.com)
> Cc: dhcptest@tahi.org
> Subject: RE: [dhcptest:00180] Re: FW: Re: Tests that check
> for DNS and Domain Search Options
>
> Hideshi,
>
> I agree with your latest patch for C_RFC3646_5_InvDecDnsSchLstOpt.seq.
>
> One last question:
>
> In RFC 3315 Section 22.7 it states:
> A client MAY include an Option Request option in a Solicit,
> Request, Renew, Rebind, Confirm or Information-request
> message to inform the server about options the client wants
> the server to send to the client. A server MAY include an
> Option Request option in a Reconfigure option to indicate
> which options the client should request from the server.
>
> Do you believe that this also stating that Option Request
> options MAY NOT be present in Decline messages?
I'm not sure about this.
But RFC3315 "does not prohibit appearance of ORO in Decline message.
Though the description of this chapter is little bit doubtful.
>
> Do you believe that there should be a specific TAHI test for
> this case?
Currently, TAHI test doesn't have such test case.
I think that this case should be clrified in kind of RFC3315bis.
> Does TAHI test for MAY and MAY NOT cases?
I think that these depend on a situation of DHCPv6 usage scenario.
Thanks,
>
>
>
> Thank you,
>
> Peter Carney
> Development Engineer
> Treck Inc.
> http://www.treck.com
>
> -----Original Message-----
> From: Hideshi.Enokihara@jp.yokogawa.com
> [mailto:Hideshi.Enokihara@jp.yokogawa.com]
> Sent: Sunday, June 17, 2007 11:30 PM
> To: Peter Carney
> Cc: dhcptest@tahi.org
> Subject: RE: [dhcptest:00180] Re: FW: Re: Tests that check
> for DNS and Domain Search Options
>
> Hello Peter,
>
> Actually, I have not added any modification to
> C_RFC3646_5_InvDecDnsSchLstOpt.seq.
>
> I have modified only for C_RFC3646_5_InvDecDnsSvrOpt.seq.
>
>
> Could you verify these behavoirs, please?
>
> Thanks,
>
>
> -----Original Message-----
> From: Peter Carney [mailto:pcarney@treck.com]
> Sent: 2007/06/15 (金) 21:17
> To: Enokihara, Hideshi (Hideshi.Enokihara@jp.yokogawa.com)
> Cc: dhcptest@tahi.org
> Subject: RE: [dhcptest:00180] Re: FW: Re: Tests that check
> for DNS and Domain Search Options
>
> Hideshi,
>
>
>
> I think your modifications are correct. Can you please email
> me the .seq files once they have been updated?
>
>
>
>
>
> Thank you,
>
>
>
> Peter Carney
>
> Development Engineer
>
> Treck Inc.
>
> http://www.treck.com <http://www.treck.com>
>
> ________________________________
>
> From: Hideshi.Enokihara@jp.yokogawa.com
> [mailto:Hideshi.Enokihara@jp.yokogawa.com]
> Sent: Thursday, June 14, 2007 7:45 PM
> To: Peter Carney
> Cc: dhcptest@tahi.org
> Subject: RE: [dhcptest:00180] Re: FW: Re: Tests that check
> for DNS and Domain Search Options
>
>
>
> Sorry, I sent this e-mail to Peter.
>
>
>
> Thank you so much Peter?
>
>
>
> I would like to hear your thought.
>
>
>
> Thanks,
>
>
>
> ________________________________
>
> From: Enokihara, Hideshi
> (Hideshi.Enokihara@jp.yokogawa.com)
> Sent: Friday, June 15, 2007 9:42 AM
> To: pcarney@treck.com
> Cc: dhcptest@tahi.org
> Subject: [dhcptest:00180] Re: FW: Re: Tests that check
> for DNS and Domain Search Options
>
> Hello Scott,
>
>
>
> Thank you for your concrete reports!
>
> I will fix these problem as soon as possible.
>
>
>
> But I think that following correction is enough for the
> test purpose.
>
>
>
> C_RFC3646_5_InvDecDnsSchLstOpt.seq:
>
> $ret = options_exist(\%dec, ($CMP_DNS_LST));
>
> if($ret == 0){
>
> vLogHTML('<FONT COLOR="#FF0000">DHCPv6 Client
> should not send Decline with Domain Search List option!</FONT><BR>');
>
> dhcpExitFail;
>
> }
>
>
>
>
>
> C_RFC3646_5_InvDecDnsSvrOpt.seq: (note the removal of $CMP_CID)
>
> $ret = options_exist(\%dec, ($CMP_DNS_SVR));
>
> if($ret == 0){
>
> vLogHTML('<FONT COLOR="#FF0000">DHCPv6 Client
> should not send Decline with DNS Recursive Name Server
> option!</FONT><BR>');
>
> dhcpExitFail;
>
> }
>
>
>
> What do you think?
>
>
>
> Best regards,
>
>
>
>
>
> ________________________________
>
> From: Peter Carney
> [mailto:pcarney@treck.com]
> Sent: Friday, June 15, 2007 6:29 AM
> To: Enokihara, Hideshi
> (Hideshi.Enokihara@jp.yokogawa.com)
> Cc: dhcptest@tahi.org
> Subject: RE: [dhcptest:00178] Re: FW: Re: Tests
> that check for DNS and Domain Search Options
>
> Hideshi,
>
>
>
> I agree with Scott.
>
>
>
> The function options_exist() that is defined in
> DHCP_common.pm has two possible return values: 0 and 1.
>
> It will return 0 if all of the options exist.
>
> It will return 1 if any of the options do not exist.
>
>
>
> Taking C_RFC3646_5_InvDecDnsSvrOpt.seq as an
> example, it calls options_exist() with ($CMP_CID|$CMP_DNS_SVR).
>
> This will return with a 0 (and therefore cause
> the test to fail) only if both of these options exist, if
> only one of the options is present then this will return with
> a 1 (and the test will still pass). I believe this to be
> incorrect. If either of these options is present the test
> should fail.
>
>
>
> Also, with C_RFC3646_5_InvDecDnsSvrOpt.seq,
> checking for the presence of a Client Identifier option is
> incorrect. From RFC3315, a Decline message MUST be discarded
> by a server if it does not include a Client Identifier option.
>
>
>
> Finally, with
> C_RFC3646_5_InvDecDnsSchLstOpt.seq, I believe that it should
> check not only for $CMP_DNS_LST but also for $CMP_DNS_SVR as well.
>
>
>
> Because testing for this is based on logic that
> requires a failure if any of the options do exist (which is
> different from the return values of options_exist() when
> called with multiple options) it is required that you call
> the options_exist() function one time for each option you are
> checking for.
>
>
>
> Here is how I believe it should look:
>
>
>
> C_RFC3646_5_InvDecDnsSchLstOpt.seq:
>
> $ret = options_exist(\%dec, ($CMP_DNS_LST));
>
> if ($ret != 0) {
>
> $ret = options_exist(\%dec, ($CMP_DNS_SVR));
>
> }
>
> if($ret == 0){
>
> vLogHTML('<FONT COLOR="#FF0000">DHCPv6
> Client should not send Decline with Domain Search List option
> and/or DNS Recursive Name Server option!</FONT><BR>');
>
> dhcpExitFail;
>
> }
>
>
>
>
>
> C_RFC3646_5_InvDecDnsSvrOpt.seq: (note the
> removal of $CMP_CID)
>
> $ret = options_exist(\%dec, ($CMP_DNS_LST));
>
> if ($ret != 0) {
>
> $ret = options_exist(\%dec, ($CMP_DNS_SVR));
>
> }
>
> if($ret == 0){
>
> vLogHTML('<FONT COLOR="#FF0000">DHCPv6
> Client should not send Decline with Domain Search List option
> and/or DNS Recursive Name Server option!</FONT><BR>');
>
> dhcpExitFail;
>
> }
>
>
>
>
>
> Please let me know your thoughts.
>
>
>
>
>
>
>
> Thank you,
>
>
>
> Peter Carney
>
> Development Engineer
>
> Treck Inc.
>
> http://www.treck.com <http://www.treck.com>
>
> ________________________________
>
> From: Scott Langley
> [mailto:slangley@tadboise.com]
> Sent: Tuesday, June 05, 2007 9:53 PM
> To: Hideshi.Enokihara@jp.yokogawa.com
> Cc: dhcptest@tahi.org
> Subject: [dhcptest:00178] Re: FW: Re: Tests
> that check for DNS and Domain Search Options
>
>
>
> Hi Hideshi,
>
> I think I agree with your thoughts about what
> the tests should do.
>
> The problem is that our client device does
> include options 23 and 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 DNS and 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 any other
> than the following messages: Solicit,
> Advertise, Request, Renew,
> Rebind, Information-Request, and Reply.
>
> The Domain Search List option MUST NOT
> appear in any other than the
> following messages: Solicit, Advertise,
> Request, Renew, Rebind,
> Information-Request, and Reply.
> ----------------------------
>
> So, these tests really expect that the message
> does not include DNS
> 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 check for 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 have problems.
>
> These two test pass, even though our
> DECLINE messages include
> both options 23 and 24:
>
> C_RFC3646_5_InvDecDnsSchLstOpt.seq
> C_RFC3646_5_InvDecDnsSvrOpt.seq
>
> I suspect that the options_exist()
> method of DHCPv6_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 our product
> 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 check for 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 well or 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 for DNS and
> Domain
> > Search Options
> >
> > Hi Hideshi,
> >
> > These are probably the test that
> would fail due to this
> 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 DNS and
> 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 the tests, 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 check for DNS
> and
> > Domain Search Options
> >
> >
> > 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.
> >
> > - 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 for DNS and
> Domain
> > Search Options
> >
> >
> >
> > Hello,
> >
> > 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.
> >
> > The way our (client) product is
> currently behaving 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(DNS Recursive 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 check whether or not
> option
> > 23 is among the options requested
> > rather than whether or not it
> is the first option
> requested?
> >
> > 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.
> >
> >
> 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
>
>
>
> Treck, Inc. - Confidentiality Notice
>
> This electronic transmission may contain
> information that is proprietary or
> confidential. You are hereby notified that any
> dissemination,
> distribution or duplication of this electronic
> transmission to some other
> entity, without the expressed written consent
> of Treck, Inc. is strictly
> prohibited, unless the contents of this
> electronic transmission
> specifically authorizes you to do so. If your
> receipt of this electronic
> transmission is in error, please notify the
> corporate offices of Treck,
> Inc. immediately by calling (513) 528-5732, or
> by reply to
> this transmission.
>
>
>
>
>