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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 8 Apr 2003 13:56:29 -0400

> 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-

---

From: Joe Abley <[email-masked]>
Date: Tue, 8 Apr 2003 14:36:44 -0400

On Tuesday, Apr 8, 2003, at 13:56 Canada/Eastern, Hollenbeck, Scott 
wrote:

> [examples]

Cool, that's what I understood. That's all good.

I presume that text would slot into draft-ietf-provreg-epp-domain-06 
section 1.1 in some way (the corresponding section in 
draft-ietf-provreg-epp-host-06 could maybe stay as-is, since if you 
need the spec for host objects you're probably not running a server 
that uses host attributes on domain objects).

The domain mapping document should presumably inherit some text along 
the lines of section 2.5 in the host mapping document, to the effect 
that "When a host object is provisioned for use as a DNS name server, 
IP addresses SHOULD be required only as needed to generate DNS glue 
records."

Stronger text which says that IP addresses MUST only be present in host 
attributes if the host name is subordinate to the containing domain 
object name sounds like it is more than is required (and e.g. will not 
be compatible with the data in the NL registry, as per Jaap.

Joe

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 8 Apr 2003 21:41:09 -0300

Scott,

> implementation and server management easier.

This text is perfect for .br and solves all the problems I've tried to
explain at SF. If this moves forward we'll not need to use an
extension describing a different domain mapping or another crude hack,
so I'm all in favor of this.

>     <domain:hostName>ns1.example.com</domain:hostName>

Here there is a missing <domain:hostAttr> or I'm misunderstanding
something ?

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

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 8 Apr 2003 21:48:29 -0300

On Tue, Apr 08, 2003 at 02:36:44PM -0400, Joe Abley wrote:
...
> be compatible with the data in the NL registry, as per Jaap.

Joe,

What about the inversion on the requirement as a MUST without the only.

"... the IP addresses MUST be present in host attributes if the host
name is subordinated to the containing domain object ..."

This way it's compatible as Jaap described for .NL and solves the glue
problem were it's explicitly needed.

Fred

---

From: "Jörg Bauer/Denic" <[email-masked]>
Date: Wed, 9 Apr 2003 09:16:49 +0200

To make things even worser. 

At the .DE Registry we also registering A and MX records.

means: for these domains we don´t do delegation, we include the machines 
directly into our zone. (don´t hit us for doing this, there are historical 
reasons ...)

So, if we are going to change the protocoll I would like to have something 
like:

<domain:ns>
   <domain:hostAttr>
     <domain:hostName>myhost.example.com</domain:hostName>
     <domain:hostType>A</domain:hostAddr>
     <domain:hostRHS>192.0.2.2</domain:hostAddr>
   </domain:hostAttr>
   <domain:hostAttr>
     <domain:hostName>*.example.net</domain:hostName>
     <domain:hostType>MX</domain:hostAddr>
     <domain:hostRHS>10 mail.example.net</domain:hostAddr>
   </domain:hostAttr>
</domain:ns>

(hostRHS = host right hand side = everything which is after the type in 
the zonedata

With this solution it is possible to put everything inside a hostAttr. 
Then it is up to the registry to define a policy and to accept/reject 
these entries.

> ForwardSourceID:NT000391FE

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Apr 2003 11:27:41 -0400

Apologies to the group - I was in a "ARIN member meeting black-out" 
for a few days...

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

I've got one question about the below, and I would like to hear Jörg 
Bauer's thoughts on making the MX registration an extension as you 
(Scott) suggest.

My question - do you want these to be MUSTs or SHOULDs?  I understand 
the desire that a server (operator) be consistent, but is this vital 
to the protocol?

As far as the MX RR issue, as a protocol person, I think that I can 
see why you would limit the EPP core spec to doing just the A 
records.  IMO, the A record - and I should point out that we have to 
be IP version fair according to our requirements - or the AAAA or any 
other experimental/future address record is a special case here. 
Only address records are eligible to be glue in DNS, MX's and others 
aren't.

Using MX records and others for registry debugging is fine, but it is 
a registry policy to do so and therefore out of scope for the core of 
EPP.

So, as a chair I'm urging the group to consider the issue Jörg raised 
in the context of:
     1) From a generic protocol design perspective, there is a reason to
        treat DNS data eligible to be glue (A RR) differently from those
        that are not (MX).
Well, I was going to make other statements, but writing an ironclad 
rule would be foolish. I was going to say something about only 
including what is generic to all registry policies, but then the 
client-provided "privacy" meta-data (with apologies to EBW) would 
fail the test.  (Not all registries will want to deal with 
client-provided data...)  The difference between the 'privacy' (sorry 
EBW) and the MX issue is that the umbrella issues are different. 
'Privacy' (sorry EBW) is further reaching through the realm of 
registry operations (and registrar operations) than the use of the MX 
record for the health of registrations.  (Not all 
registries/registrars will perform such thorough testing, but all 
will deal with, sorry EBW, privacy.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

   ...as rare as a fire at a sushi bar...

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 Apr 2003 16:33:08 -0400

> Only address records are eligible to be glue in DNS, MX's and others

Some MX records might need glue just as some NS records need glue:

$ORIGIN something.

example1 NS ns1.example1
example1 NS felix.automagic.org.

ns1.example1 A 199.212.93.1

example2 MX 10 smtp.example2
example2 MX 20 felix.automagic.org.

smtp.example2 A 199.212.92.1

Is MX (and friends) vs. A really the comparison you should be making? 
Or should it be MX (and friends) vs. NS?

Joe

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Apr 2003 16:45:22 -0400

Speaking as a DNS person - you don't need glue for MX's because you 
get that from the A records sitting at the NS-named machines.  You 
need NS glue because there's nowhere else to get the A records other 
than NS-named machines.  (Speaking grossly.)

In the example below, "smtp.example2 A" isn't glue, it's part of the 
"something." zone.

At 16:33 -0400 4/10/03, Joe Abley wrote:
>Is MX (and friends) vs. A really the comparison you should be 
>making? Or should it be MX (and friends) vs. NS?
>
>
>Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 Apr 2003 16:50:28 -0400

> In the example below, "smtp.example2 A" isn't glue, it's part of the 

Sure. But I thought the case we were talking about was that where the 
"something." zone contains bare MX records, and there *is* no 
delegation (hence no NS-named machines).

I agree they're not glue, though. The idea I was trying to convey was 
that they were records whose function was to make the MX records 
useful, in the same kind of way that glue records' function is to make 
NS records useful.

I've seen more than one ccTLD zone that started off looking like that 
(indeed, that started off with NS records in the zone being a rarity, 
and A, MX and TXT records being much more common).

Joe

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Apr 2003 17:17:07 -0400

Speaking as co-chair -

Hmmm.

I have been under the assumption that we were talking about 
provisioning domain names, yes, provreg is chartered to be more 
general but in the short term we've focused on domain names, hence 
the only DNS records would be NS's and glue for the time being.

Would excluding MX's (et.al.) be too shortsighted for our 
extensibility (E of EPP)?  Would only considering NS's and glue be 
sufficient for EPP 1.0?

In an attempt to focus the discussion, however, I'd lean towards 
restricting ourselves towards concentrating on the NS & glue case and 
not on the MX case.  (MX might not be the only one that could be 
added.)  It's not that I want to suffocate new ideas in the WG, but 
it is better to meet the original goal first before expanding the 
mission.

At 16:50 -0400 4/10/03, Joe Abley wrote:
>I've seen more than one ccTLD zone that started off looking like that (indeed,
>that started off with NS records in the zone being a rarity, and A, MX and TXT
>records being much more common).

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 Apr 2003 17:26:16 -0400

On Thursday, Apr 10, 2003, at 17:17 Canada/Eastern, Edward Lewis wrote:

> extensibility (E of EPP)?

If we can add them using extensions, I would say that is plenty of 
support.

> Would only considering NS's and glue be sufficient for EPP 1.0?

I would say yes.

[My previous comment was really just a clarification of what it was I 
was talking about, and not any kind of opinion that RRs other than NS 
and glue should be supported in the base set of documents.]

Joe

---

From: "Jörg Bauer/Denic" <[email-masked]>
Date: Fri, 11 Apr 2003 08:59:42 +0200

> extensibility (E of EPP)?  Would only considering NS's and glue be 

May be it was not clear:
I don´t talk of including MX RR into the protocol, i´m talkink of the 
possibility to put "whatever you want" into the protocol.

The idea behind it is that it doesn´t forbit you to just use NS and (glue) 
A Records, it´s up to the policy, but it also alows you to store other 
records into the zone.
Just think about DS Records (for DNSSEC). Maybe it makes sence to get 
these records too.

Of cause you can develop extensions for all this kind of stuff, but i see 
a BIG problem with interoperability if al lot of Registries are going to 
have their own extensions.

I also see the  drawback of this approach: the records aren´t "well 
defined". You have a name, a type and all the rest. But to have some more 
level of flexibility inside the protocoll, i prefer also to have such kind 
of mapping.

Maybe we can put two type of mapping inside:
1. a pure DNS+Glue mapping
2. a "whatever you want, put into DNS" mapping

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Apr 2003 12:23:15 -0400

>Just think about DS Records (for DNSSEC). Maybe it makes sence to get

Under the banner of getting the first job done first without 
squelching improvements...

DS RR's are still not defined in any archived document (e.g., RFC), 
they are not even experimental, much less standards track, so I'd 
hesitate to think that far ahead.  Yes, doing whatever is necessary 
to facilitate DNSSEC is something I've been pushing for for quite 
some time, but it's not appropriate to tie EPP (version 1.0) to that 
boat anchor at this time.

Scott Hollenbeck has written a non-WG draft describing how DNSSEC 
could be accommodated in EPP extensions.  Note that this is a live 
debate, but just not one being conducted in the working group.  Nor 
is the debate, although alive, progressing anywhere rapidly, so far 
as I know, it's just there.

>have their own extensions.

This is what we are trying to avoid.  But sometimes it is hard to 
anticipate what the greatest common denominator is before folks run 
off and do (hopefully prototypes of) non-interoperable things.

I understand the dilemma, but the IETF process is built on putting 
engineering before the realities of business needs to maintain a 
revenue stream.  I'm not saying that the IETF process is necessarily 
correct in this manner, just that there is a conflict here.  This is 
what makes the job of chairing a group like this, umm, so rewarding. 
;)

>2. a "whatever you want, put into DNS" mapping

Number 1 is a pretty clearly defined case.  Number 2 is not, and 
dealing with problems that are not clearly defined is a recipe for 
disaster when you are expecting to meet a deadline or a near-term 
goal of reaching a basic protocol.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 11 Apr 2003 19:41:28 -0400

...
> fail the test. 

Just for clarity, the <dcp> still is for a registry (server) mechanism for data collection
policy announcement, whether MANDITORY or OPTIONAL.

The directionality could be reversed, and a registrar (client) mechanism for data donor
policy  constructed, again, MANDITORY or OPTIONAL.

>             ... (Not all registries will want to deal with 
> client-provided data...)  

And not all registrars will want to deal with server policies either. Some will want the
current CNO rules (none, or ICANN).

>                       ... The difference between the 'privacy' (sorry 

Actually "privacy" can't apply to an MX record under the 96/46/ec framework, and it is
hard to see how anything other than "non-disclosure" could apply in the US or OECD set
of frameworks. There is no "individual" in an MX record.

> will deal with, sorry EBW, privacy.)

This is a good point, regardless of the policies associated with "privacy" (sorry EL)
or MX records (and publication via 1034/35 generally), the mechanism that provisions
an MX record to a zone file (any format) is more narrowly constrained that the mechanism
that generally provisions data, some of which will end up in a zone file, or on the floor,
to a registry.

Imagine a registry that did not publish data via 1034/35, but only via 954. Solving for
MX does not solve for the whole problem. Yes, there are registries that only publish via
1034/35, and not by 954.

I don't think I've ever seen my initials so ... exhuberently frequent in a single piece
of mail. 

	...as rare as sushi at a forest service fire fighter's bar ... 

Cheers,
Eric