To:
=?windows-1252?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
CC:
James Gould <jgould@verisign.com>, "Hollenbeck, Scott" <shollenbeck@verisign.com>, Chris.Newman@Sun.COM, EPP Provreg <ietf-provreg@cafax.se>
From:
Eric Brunner-Williams <brunner@nic-naa.net>
Date:
Thu, 02 Apr 2009 18:40:02 -0400
In-Reply-To:
<33002F21-8354-4E8F-A23A-DC35F58E5CC4@cisco.com>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Thunderbird 2.0.0.21 (Macintosh/20090302)
Subject:
Re: [ietf-provreg] RE: Standards Track Advancement Request for EPPRFCs
> Not fun, but there are tons of similar situations (regarding > validation of attribute values) that also lack documentation (and lack > of specification in the epp spec), so "to make things work", there is > a lot of "trial and error" in the actual algorithm implemented on top > of the epp protocol. Yup. So the baggage that (modernly) goes with "standards track" and the specification experience, and the contractual regime which existed when we started are at odds, and the awkwardness isn't diminished, in my opinion, by the present changes to the contractual regime. If we were specifying something as generic as a provisioning protocol for arbitrary registries, rather than the past, or currently contemplated ICANN contracting gTLDs, augmented by some ccTLDs, to which those special cases would tastefully decorate with their special extensions, then the (modern) standards track requirements wouldn't seem so otherworldly. I'll send implementation comments separately, eventually. Remind me if I haven't by Stockholm. Eric