Mark, I agree with everything you have put forth, so my questions will be to TAHI will be: 1. How do we get IPv6 Ready Logo approved under these circumstances, since apparently it is against the rules to change the perl scripts. 2. Vendors have passed Phase 1, so did they not run into timing issues, rfc should_ into must_, etc, or were they in fact allowed by TAHI to alter the scripts?
I will ask this questions because my management where I am employed is really hot to acquire the Logo. Thanks, Phil -----Original Message----- From: Mark Huth [mailto:[EMAIL PROTECTED] Sent: Friday, July 01, 2005 1:37 PM To: [EMAIL PROTECTED] Cc: Bellino, Phil; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Users-IPv6 Subject: Re: (usagi-users 03438) Re: IPv6 ready Logo program Self test (HOST only) version 1.3.6 Thank you, Mr. McFadden, We too have found that the issues of cache purge timing is not handled well by the TAHI tests. Timing constraints under 30 seconds are much too tight for implementations where the garbage collection timer has a 30 second value. Such short timings would also seem to be rather unrealistic for real configurations where these lifetimes are normally in the hours or days range. A couple of the tests also turn RFC _should_ into _must_. So you can be in compliance with the RFC and still not pass the TAHI test. So The TAHI tests are not really yet a definitive conformance test wrt the actual RFCs. They do, however, continue to improve, and I am glad to have these tests, regardless of minor problems. Mark Huth Tim McFadden wrote: > Dear Mr. Bellino and IPv6 folks, > > I am also working on passing Tahi, but for Phase 2. And I've had very > helpful replies from the Tahi group on issues about their tests and > Perl code. > > What the rules of the tests are, will become an issue for us, so I am > interested in your thread. > > My working interpretation of the rules is that all the data and timing > in the Perl code within a test are "official Tahi rules." I have > questioned the Tahi group about particular tests and gotten helpful > and reasoned replies, and still have outstanding questions about some > tests. > > It is reasonable to ask, as you have done, "does this test pass > correct results?" In one instance the Tahi reply was, "we will fix > this problem in a later version." > You could try sending this particular issue (4) to [EMAIL PROTECTED] > > I have altered Tahi Perl code that affects the system between tests. > My assumption is that I can send in my ct/ directories with results > that have been run with pure Tahi and still pass, even if the delays > between tests were under my control and I communicated from the TN to > the NUT to signal neighbor cache purges. The timing of neighbor cache > purges is left open by the RFCs, but critical for passing the tests. > > Tx, > Tim McFadden > -------------------------------------- > Interniche Technologies, Inc. > 51 East Campbell Avenue, Suite 160 > Campbell, CA 95008 > 408-540-1160x207 > [EMAIL PROTECTED] > www.iniche.com > -------------------------------------- > > > Bellino, Phil wrote: > >> Hello, >> I am executing the IPv6 Ready Logo Program Self test version 1.3.6. >> I have >> accomplished the following: >> 1. The Ipv6 Specification tests all passed. >> 2. The ICMPv6 tests all passed. >> 3. The Neighbor Discovery tests all passed. >> 4. I have an issue with the Stateless-autoconf tests. There are 26 >> tests and >> tests 1-23 all passed. Test 24-26 hang because one or the other >> "VSLEEP" >> formulas end out with a negative value for seconds to wait(which >> causes the >> hangs). >> >> My questions are: >> 1. Has anyone seen this in testing? >> >> 2. Are we allowed to change the pearl scripts with respect to the >> vsleep >> formulas to make them work as the comments read in the respective .seq >> files? RA_sameVLT.seq for test 24, RA_incVLT.seq for test 25, and >> RA_decVLT.seq for test 26. >> 3. Actually, I have done this, but isn't this also breaking the >> rules of >> the tests? >> >> Thanks, >> Phil Bellino >> >> ============================ >> Phil Bellino >> MRV Communications, Inc. >> Boston Product Division >> 295 Foster St. >> Littleton,MA 01460 >> Tel: (978)952-4807 >> Email: [EMAIL PROTECTED] >> ============================ >> >> >> > > > > --------------------------------------------------------------------- The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
