[DNSOP] Re: draft-ietf-dnsop-delext and early allocation of DELEG code points

[Philip Homburg <[e-mail]>]

> How about flipping it around saying that records in the range cause
> special processing in response to queries with the DE bit set, with
> the details of the processing specified in the document(s) that
> define each record.
> 
> While I don't immediately see a DELEGPLUSPLUS that has different
> or more complicated behavior than DELEG, I don't see any reason to
> assume that will never happen. Iit'd be unfortunate if we came back
> next year and said oops it'd be great if we had a DELEGPLUSPLUS
> that in addition does X, but we can't.

For a server, DE=1 tells that the client has DELEG support. DE=0 means that
the client has no DELEG support.

However, in the future we cannot use the DE bit to distinguish between DELEG
and DELEGPLUSPLUS. So the current definition of DE needs to be forward
compatible enough that we can support DELEGPLUSPLUS without changes to the
meaning of de DE bit.

For example, if a delegation has both NS and DELEG records then DE=0 means
the client will get the NS RRset. And with DE=1 the client with get a
DELEG RRset.

In the future with DELEGPLUSPLUS, DE=1 has to have the effect that
the client with get both the DELEG RRset and the DELEGPLUSPLUS RRset
(or we have to allocate yet another bit.).

We can define DELEGPLUSPLUS in any way we want. Want we can't do is use
the DE bit to distinguish between a client that understands DELEGPLUSPLUS
and one that only supports DELEG.