On 03/02/2012 10:34, Paul Hoffman wrote:
> On Mar 2, 2012, at 10:09 AM, Doug Barton wrote:
>
>>> The point of my draft is that it's an extension language that
>>> both name servers and provisioning systems can read on the fly.
>>> Add a new stanza to /etc/rrtypes and you're done, no software
>>> upgrades needed. The risk is much lower since the worst that
>>> will happen if the new stanza is broken is that the provisioning
>>> software and name servers will ignore it, not that the whole
>>> thing will crash.
>>
>> So it seems to me that what you're proposing would also cause the
>> need for changes to be made to the provisioning systems. Or are
>> you suggesting that the same users who cannot handle anything other
>> than point and click are suddenly going to be able to enter
>> specially formatted text strings that they don't understand?
>
> Yes, that's exactly the point. If they can copy-and-paste from a tool
> that created the text string, this will be of huge benefit.
So new tools still have to be created for new RRtypes, right? This
sounds like an "elephants all the way down" situation to me.
>> And/or that the people who operate those provisioning systems are
>> going to allow end users to "Add a new stanza to /etc/rrtypes"?
>
> No, that's not what is proposed. What is proposed is that if the
> operator has added the stanza, the user can add the RRtypes.
So less difficult than a full-fledged change to the provisioning system,
but still requires operator intervention, and now you have operators
*and* users with chances to make fatal errors.
>>> Until the DNS crowd admits that provisioning systems are a major
>>> bottleneck, and telling people to hand-code more types into them
>>> isn't going to happen, there's no chance of getting more RRs
>>> deployed.
>>
>> The rest of this discussion is almost certainly more suitable for
>> dnsop, but I'll say one more time that I disagree with you on this
>> point. Provisioning systems *are* a bottleneck, no one is disputing
>> that. But our experience with new TLDs, IPv6 and DNSSEC shows that
>> when there is user demand for these changes, they get made.
>
> The purpose of the proposal is to allow protocols with less press
> oomph than "new TLDs, IPv6 and DNSSEC" to be deployed. Maybe you
> don't want that, but many of us do.
Please don't use that kind of ad-hominem-adjacent line of argument with
me. I'm already on record numerous times, including in this thread,
saying that I believe the ability to deploy new RRtypes is crucial to
the ongoing health of the Internet.
>> I'll also add one more point based on my experience with DNS
>> provisioning system UI design, most of what you are trying to
>> accomplish with your draft on the UI side can be handled with a
>> simple text field in an HTML form that allows the user to enter
>> free-form stuff that is then checked for syntax errors and loaded
>> if the name server software supports the record. I realize that we
>> disagree on right solution for the name server support side of the
>> equation, but my point is that most of what you claim to be trying
>> to achieve is already easily accomplished.
>
>
> Here, I agree with you more than I agree with John, but history has
> shown that HTML forms are not sufficient. I'm not sure why.
IME this has been because of the lack of a validation step in between
user entry and (attempted) deployment. My (simplified) work flow for
these kinds of systems has been:
User input
|
Sanity checks based on internal policy
|
named-checkzone (or equivalent)
|
Deploy to name server
|
Validate that the new zone loaded correctly
Skipping steps 2, 3, or 5 *will* cause tears, at some point.
Doug
--
If you're never wrong, you're not trying hard enough
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf