Index: [Article Count Order] [Thread]

Date: Mon, 16 Jan 2006 17:03:16 +0900
From: "haoda" <haoda@64translator.com>
Subject: [dhcptest:00101] Re: Release-0.3 TAHI DHCPv6 conformance test
To: <dhcptest@tahi.org>
Message-Id: <200601160803.k0G83PPs031853@bahamas.64translator.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB210118CE62@xmb-rtp-20a.amer.cisco.com>
X-Mail-Count: 00101

Hi,Mr. Volz,

Thank you very much!
The informations from you are not only its location and log,
but also including the description of them & RFC. 
They are very  helpful to me.

I have read your mail carefully and begun fixing the problem
which have been found. Please wait for the next release.
It will be done recently.

> Regarding Test 26 
> (S_RFC3315_15.4_InvalidRequestMsgWoCltID.seq), it still fails 
&
> Regarding Test 27 
Sorry I forget to add the files which have been modified in last patch.
Please change them to the new files.
By the way, I think the Test 25 is different from 27 because the goal of
Test 25 is to check whether the result is failed if the SID opiton is not
consitent in the exchangement of messages.

 
> Regarding Test 47 (./S_RFC3315_15.10_ClientIDOPMatch.seq), 
> Regarding Test 48 
> Regarding Test 51 
> Regarding Test 52 (./S_RFC3315_15.14_InvalidRelayReplyMsg.seq 
> Regarding Test 72 
> Regarding Test 75 (./S_RFC3315_18.2.2_ReceiptConfirmMsg.seq) 
> Regarding Test 78 ( 
> Regarding Test 81 
> Regarding Test 83 
> Regarding Test 86
> Regarding Test 93 (./S_RFC3315_18.2.7_ReceiptDeclineMsg.seq), 
> Regarding Test 107
> Regarding Test 108 (./S_RFC3315_22.13_StatusCodeOP.seq), 
> Regarding Test 123 (./S_RFC3633_10_MultiIAPDPreOP.seq), this
> Regarding Test 128 (./S_RFC3633_12.2_ClientInitPDRebind.seq),
> Regarding Test 130
They are now fixing, please waitting. 
Almost all of them have relation to the Status Code option. 
I still have some points which are not clear about 
Status code option,
would you like to confirm them for me?
1) If the message exchange is successful, the Status Code option
   "Success" isn't a "Must be in" option, isn't right?

2)When we received a Reply message with the "NotOnLink" status
  code option(or NotBinding), it maybe have 3 kinds of location. (showed in the 
  following list)  Can we think about all of them is acceptable?
  
  Type1: at the root of the message
   Message main 
   |             |
   IA_*       NotOnLink
  
  Type2: in the root of the IA_* optiones
  Message main
   |            
   IA_*       
   |  
NotOnLink

  Type3: in the root of the IA_Address optiones
  Message main
   |            
   IA_*    
   |  
IA_Address      
   |  
NotOnLink

3)If the Relay message with the "NotAddrAvail" status
  code option is received, It maybe have 2 kinds of location. 
  How about them?

  Type1: in the root of the IA_* optiones
  Message main
   |            
   IA_*       
   |  
NotBinding or Not

  Type2: in the root of the IA_Address optiones
  Message main
   |            
   IA_*    
   |  
IA_Address      
   |  
NotOnLink


4)If the count of IA_* option and IA_Address option are all gearter than 1,
  I think maybe the right structure should be like this?
 Is it right?
   Message main
  ----------------------------------------------
   |                                          |       
   IA_*                                  IA_*
 ---------------------                       -------------------------
   |                 |                       |                    |
IA_Address    IA_Address    IA_Address       IA_Address
   |                 |                       |                    |                    
Staus1        Status2           Status3            Status4

And please keep giving me informations of DHCPv6 test tool. 
Thank you!

Sincerely yours,
Haoda 

101_2.zip