DCHK-05 meets Occam's Razor

1

• DCHK-05 meets Occam's Razor
• Marcos Sanz
• sanz_at_denic.de
• 67th IETF, San Diego
• November 7, 2006

2
Advancing DCHK

• Issues discovered while trying to upgrade our
  DCHK implementation from -04 to -05
• ltdomainVariantgt
• ltstatusgt vs ltenhancedStatusgt
• Relevant "domain times"
• Lameness
• dateTime i18n
• Nits wording, coherence, examples, references,
  typos

3
Issue 1 ltdomainVariantgt

• 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

4
Issue 2 ltstatusgt vs ltenhancedStatusgt

• Both can appear in a ltdomaingt result object
• However, ltenhancedStatusgt is meant to be a
  superset of ltstatusgt
• Further, ltenhancedStatusgt is more extensible and
  flexible
• So why keeping ltstatusgt? Backwards compatibility?

5
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

6
Issue 4 Lameness

• ltenhancedStatusgt includes ltlamegt, which is not an
  instance of ltenhancedStatusTypegt
• 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

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)

8

• sanz_at_denic.de