> 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. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
