> I think were looking at this from slightly different angles. > > My example isnt intended to describe what I think operators will > do. Its intended to show what the protocol permits. > > Currently, DELEXT specifies that every future Delegation Type > inherits DELEGs interaction with NS (i.e. ignore NS) by default. > My concern is whether thats the right architectural choice for a > framework intended to support future Delegation Types. > > I also dont think the issue is specific to a hypothetical DELEG2. > It applies to any future Delegation Type that does not need DELEGs > NS replacing semantics. Under the current design, such a type either > has to require DELEG alongside it, or it has to change DELEXT. > Thats the design choice Im asking the working group to make > consciously now, rather than implicitly through DELEG.
We can split the range in two - one part is for new delegation types. The assumption is that DELEG and any future delegation type will completely replace NS. So we can optimize delegation replies and leave out NS. - the other part is for non-delegation server-side types like DS. We can assume that they complement any delegation type including NS. If we assume new types DELEG2 and DS2. Then a delegation that has both NS and DELEG2 and the query has DE=1 then only DELEG2 would be returned. A delegation with both NS and DS2 (and a DE=1 query) would get both NS and DS2. A delegation with NS, DELEG2, and DS2 (and a DE=1 query) would get DELEG2 and DS2. I think that solves the problem. Though at the cost of a bit of extra complexity. Is there any objection to splitting the range? _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
