RE: lastVerified: optional vs. extension

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> I'm not aware of any question that I left unanswered. In 
> addition, you mix up my 
> model and DENIC's current one. I once suggested a model that 
> has the flexibility 
> of DENIC (anyone can specify any name server, no separate 
> relational model for 
> in-zone and out-of-zone hosts) while having host objects. 
> Both models allow the 
> change of IP addresses of hosts used by multiple domains in a 
> single request. My 
> model additionally allows to even change the name of a host 
> used as a name 
> server in multiple domains in a single request.

Sorry, but I don't remember you suggesting anything other than the .de
model, and I don't recall you ever addressing how that model deals with bulk
updates efficiently.  If you did, would you please point me to your proposal
in the list archives?

> My model has a drawback regarding potential in-zone host name 
> resolution cycles, 
> but this problem is IMHO heavily overestimated and can be 
> handled during zone 
> file generation. A quick analyses of our domains shows that 
> nearly none of our 
> .info and .biz domains and only 2% of our .org domains fully 
> rely on in-zone 
> hosts. Even our com/net domains have a rate of less than 50%. 
> This is surely not 
> representative, and I expect that ccTLDs have a much higher 
> rate > 95%. So 
> depending on the registry, EPP's host model, where cycles 
> involving out-of-zone 
> hosts are not prevented, has little benefit to the 
> operativeness of the DNS. If 
> one takes the abilities of misconfigurations into account 
> which are fully 
> ignored by the current gTLD registries (contrary to many 
> ccTLDs), this makes 
> even less sense.

Mow I'm getting even more confused.  We've gone from the provisioning
perspective to the DNS resolution perspective, and as far as I'm concerned
those perspectives are independent.  The provisioning system just needs to
ensure that the information needed by the resolution system is available for
proper deployment.

BTW, EPP's host model does very clearly provide guidance to prevent cycles
(though I'm not sure of what you mean by "cycles") involving out-of-zone
hosts.  From section 2.5 of the current host mapping:

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

> Everything above I wrote at least once to the list and I 
> don't want to discuss 
> this in detail any longer. You said in a recent e-mail, that 
> you don't want to 
> make fundamential changes to the protocol at this point of 
> progress, which is 
> understandable to me. So if I ever have to use EPP on server 
> side, I'm going to 
> maltreat it until it fits my needs, whether it is 
> recognizable as EPP afterwards 
> or not.

No, I said I as document editor _can't_ make fundamental changes on my own
because of where we are in the document review process.  We've certainly
been over this ground many, many times in the past, but the IETF process
includes provisions to reconsider approaches if and when implementation
experience demonstrates flaws.  The process has a built-in mechanism to deal
with this situation in the way documents progress (or not) from proposed
standard to draft standard status.

I don't really care to continue discussing issues that the WG has dealt with
in the past, either, unless significant new information is somehow made
available.  I'm not the one who brought this particular topic up again in
the first place, though. ;-)

-Scott-