Re: provisioning software, was DNS RRTYPEs, the difficulty with

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf