Re: flag day for draft-ietf-dnsext-delegation-signer?

[hardie@qualcomm.com]

Ah, this one wasn't on the web agenda earlier today; I see it
there now.  A quick read through says that appearance of
the new type codes for sig, key, nxt, means that the
old resolvers won't hide anything when seeing the
nxt records in the responses,  so we don't need a
flag day per se--just a day to introduce the new type
codes.

If I got that right, that sounds like a fine answer to me.  I'll
do a review on the doc itself tomorrow, but any early
corrections are welcome.
			Ted

At 9:13 PM -0400 08/19/2003, Rob Austein wrote:
> At Tue, 19 Aug 2003 15:52:34 -0700, Ted Hardie wrote:
> >  draft-ietf-dnsext-delegation-signer notes that it is not
> >  backwards compatible with the existing DNSSEC infrastructure
> >  and will require a flag day.  Are we actually expecting to
> >  set a date for this flag day, or is this just another way
> >  of saying "not compatible"?  If so, does this date get set
> >  by DNSEXT, DNSOP, or someone else?
> where's the beer transfer protocol when we need it?
>
> see draft-ietf-dnsext-dnssec-2535typecode-change to understand the
> form that the flag day is likely to take.  in brief: if we got this
> right, old (rfc2535) implementations and new (dnssecbis)
> implementations will ignore each other.
>
> i'll leave it to thomas to decide whether to forward the conversation
> that he and i had on normative references between these two docs.