CRISP WG 2006/11/7

DCHK-05 meets Occam's Razor

Marcos Sanzsanz@denic.de

67th IETF, San DiegoNovember 7, 2006

CRISP WG 2006/11/7

Advancing DCHK

• Issues discovered while trying to upgrade our DCHK implementation from -04 to -05:– <domainVariant>– <status> vs <enhancedStatus>– Relevant "domain times"– Lameness– dateTime i18n– Nits: wording, coherence, examples,

references, typos

CRISP WG 2006/11/7

Issue 1: <domainVariant>

• Assimilated from DREG• maxOccurs="unbounded" is scary in a

lightweight service• Potential high amounts of domain variants

don't play well with LWZ• Conceptually well placed in DREG(2), but not

in an availability service

CRISP WG 2006/11/7

Issue 2: <status> vs <enhancedStatus>

• Both can appear in a <domain> result object• However, <enhancedStatus> is meant to be a

superset of <status>• Further, <enhancedStatus> is more extensible

and flexible• So why keeping <status>? Backwards

compatibility?

CRISP WG 2006/11/7

Issue 3: Relevant "domain times"

• Current draft:– initialDelegationDateTime– lastDelegationModificationDateTime

• That is a mistake, it should be:– initialDelegationDateTime– createdDateTime

• Plan to add expirationDateTime• Plan to add lastDatabaseUpdateDateTime

CRISP WG 2006/11/7

Issue 4: Lameness

• <enhancedStatus> includes <lame>, which is not an instance of <enhancedStatusType>

• It has been assimilated from DREG2• It is ill-defined in this context: it is an assertion

about the lameness of a name server, not of a domain

CRISP WG 2006/11/7

Issue 5: dateTime Internationalization

• Unnecessary restriction in section "Internationalization Considerations":"The [...] element contains the XML Schema data type

'dateTime'. The contents [...] MUST be specified using the 'Z' indicator for [...] UTC"

• No guidelines about that in BCP70 or RFC3076• Probably only meant to recommend "Z" vs "z"

(v RFC3339)

CRISP WG 2006/11/7

sanz@denic.de