RE: [ietf-provreg] References for Today's Host Object Discussion

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 08 April 2003 18:12 UTC

Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24531 for <provreg-archive@ietf.org>; Tue, 8 Apr 2003 14:12:37 -0400 (EDT)
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38I0BRN025719 for <ietf-provreg-outgoing@nic.cafax.se>; Tue, 8 Apr 2003 20:00:12 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h38I0Bk0025718 for ietf-provreg-outgoing; Tue, 8 Apr 2003 20:00:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38I0ARN025713 for <ietf-provreg@cafax.se>; Tue, 8 Apr 2003 20:00:11 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h38Hvpaj014264; Tue, 8 Apr 2003 13:57:51 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2HKCPTYP>; Tue, 8 Apr 2003 13:56:29 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E635@vsvapostal8>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: 'Joe Abley' <jabley@isc.org>
Cc: 'Edward Lewis' <edlewis@arin.net>, "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Date: Tue, 08 Apr 2003 13:56:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk

> This looks good. It would be helpful to see the descriptive text you 
> mentioned (and some example requests) to confirm that I'm 
> understanding 
> what you mean, exactly.

Text:

"Name server hosts for domain delegation can be specified as either
references to existing host objects or as domain attributes that describe a
host machine.  A server operator MUST use one name server specification form
consistently.  A server operator that announces support for host objects
MUST NOT allow domain attributes to describe a name server host machine.  A
server operator that does not announce support for host objects MUST allow
domain attributes to describe a name server host machine."

The idea here is that it's a bad idea to allow some domain objects in a
repository to reference host objects and others to use domain attributes
that describe a host machine.  Using one form consistently will make
implementation and server management easier.

Example host object references:

<domain:ns>
  <domain:hostObj>ns1.example.com</domain:hostObj>
  <domain:hostObj>ns1.example.net</domain:hostObj>
</domain:ns>

Example domain attributes that describe host machines:

<domain:ns>
  <domain:hostAttr>
    <domain:hostName>ns1.example.com</domain:hostName>
  </domain:hostAttr>
    <domain:hostName>ns1.example.net</domain:hostName>
    <domain:hostAddr ip="v4">192.0.2.2</domain:hostAddr>
  </domain:hostAttr>
</domain:ns>

Ed: so when can we move forward with document edits for this and the privacy
proposal?

-Scott-