To:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
cc:
"'Edward Lewis'" <edlewis@arin.net>, "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Thu, 06 Mar 2003 18:06:27 -0500
In-Reply-To:
Your message of "Thu, 06 Mar 2003 12:40:24 EST." <3CD14E451751BD42BA48AAA50B07BAD6033707A3@vsvapostal3.prod.netsol.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
> > At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote: > > >adding attributes to elements is either pervasive, or > > specific. As this > > >WG lost the technical/social distinction with the expiry of > > Ross' draft, > > > > What parts of the material in Ross' draft need to be added (as > > terminology definitions) in the base spec (or base spec-bis)? > > Note that section 1.1 of requirements RFC 3375 includes parenthetical > descriptions for "social" and "technical" information in the definition of a > "thick" registry. See: Subject: Is it "social" or is it "model" or is it "mechanism"? Sent to this list on 02.13.03 We simply need to seperate the thick/thin (registry model) from the publication mechanisms (1034/35), and be dns-specific (for a change), and speak er, write about the RRs we provision, without being Master File Format specific (and triggering a valid DJB criticism). The problem with where we left off (in 3375 and with Ross' -dn-), is that we were letting the RRP vs EPP (thick/thin) act as our framework. Here we need to look, not at who has the data, but at what data has what kind of function. Almost, but not quite, the same. Eric