Initial goals:
	test opt-in for basic functioning
	time permitting, additional testing of DNSSEC functionality

Opt-in results:
       * basically works as far as we can tell
       * specification issues
	 - draft & implementation behavior WRT NXT is different,
	 probably draft needs to change, on inclusion of negative
	 wildcard proof in the answer (draft says MUST NOT, code does
	 it, it's probably harmless, draft should say MAY)
	 - insecure delegation with opt-in NXT is semantically
	 ambiguous, useless, and doesn't work (SERVFAIL)
	 - draft should mention dynamic update behavior. It should
	 caution against dyanmic update with opt-in.
       * code bugs found in signer (VRSN) and ISC-integrated Nominum
         code, mostly minor and easily fixed during the workshop


Additional testing and observations:

KSK
       * signer shows some minor bugs, no impact on protocol seen
         (ISC) as expected. Operationally it is easy and convenient to
	 be able to tell which is the KSK from the parity of the flag
	 field. Having the signer distinguish between KSK and ZSK
	 automatically is a good feature

DS (research?)
     DS "Signaling"
       There are several identified problems with DS. They all seem to
       converge to problems with data being received that is not
       expected.

       One of the identified problems is that currently Bind 9.1/9.2
       resolvers choke on a referral from a secure to an insecure zone
       that comes with a NXT RR, which is taken to prove the
       non-existence of a delegation according to old DNSSEC
       semantics"


       Currently some people are thinking about two possible solutions
       to this problem. The workshot had code available that allowed
       us to experiment with both. The workshop realizes that these
       experiments are very preliminary, we tested for basic
       feasibility of these approaches. We believe that there is
       further analysis to be done on both the protocol implications
       and the code for either of these, or even, alternative
       approaches.

       The two approaches that were tried to circumvent the problems
       that are introduced with the current modifications of DNSSEC
       are:

         - using a signaling bit (DA) in the OPT RR and;

 	 - the use of alternative type codes and mnemonics for SIG, NXT 
           and KEY. 

       With the DA signaling the identified problems problems do
       disappear, as also with changing type codes. Both act as "Flag"
       date options, they do not inter-operate with any previous DNSSEC
       implementations with respect to DNSSEC operations. Both seem to
       meet the basic need of keeping old DNSSEC implementations from
       having to cope with new DNSSEC data. No new problems are seen
       for normal resolving.

       In our limited tests we did not identify new corner cases with
       either approach. Note more testing and analysis are needed,
       this was a preliminary effort only.

       Recommendations on approaches will need to be proposed to the
       dnsext-wg, any recommendation was deemed premature by the
       workshop. Further discussion is needed on the operational and
       protocol implications of any approach to this problem.
   
     DS 'Grand parent' problem

       The grand parent problem (what if a grand parent and child are
       authoritative for a DS and the parent lives on another server)
       was to be tested but because of an inconsistent setup we did not
       come to a conclusion.



General comment useful for other workshops or operations

     'dig +multiline' is ones friend for troubleshooting which keys
      are returned.

      For troubleshooting one needs more than just the logs from the
      verifier. A perl resolver that turns out to be useful is
      available at www.nlnetlabs.nl/dnssec/ (we know of more efforts
      to make them).

      A server to hand out preconfigured incorrect answers seems to be
      a useful tool.