--On Wednesday, March 21, 2018 06:05 -0700 Dave Crocker
<d...@dcrocker.net> wrote:
> On 3/21/2018 4:05 AM, John R. Levine wrote:
>
>>>> Harmonization for the sake of harmonization is bad, and
>>>> very little Internet System technology gets it. Just do
>>>> new stuff better.
>>
>>> I agree completely. So please forgive my not understanding
>>> how your first and third comments are relevant to the
>>> current topic, which pertains to ensuring that new
>>> behaviors use the new model.
>
>> I'm not Paul, but I'm guessing that he is referring to
>> retroactively changing the naming rules for SRV and other RRs,
>> rather than documenting existing practice.
> Your attempt at clarification is equally confusing to me,
> since it, too, seems to have nothing to do with the current
> effort.
>
> The effort is to create a registry -- which obviously differs
> from existing practice -- and to have that registry be used,
> going forward. Both the creation and the future use deviate
> fundamentally from 'existing practice'.
I have to agree with Dave.
There is a strong case to be made that the introduction of the
underscore convention was a kludge that violated fundamental
design assumptions of the DNS and that it was added without
considering, much less acting on, what other changes would be
needed to support it smoothly. One can imagine other, better,
ways to do the same thing. I did consider including it as
another example in RFC 8324 but decided against it, which may
not have been the right decision. While I think I understand
at least some of the reasons why alternatives to the underscore
convention were not considered seriously, much less adopted, it
is much too late now to change things and this proposal, AFAICT,
has absolutely nothing to do with that or any other change to
existing protocol or operational practices anyway.
Given that one is going to have a list of keywords that are
expected to expand over time (or demonstrated to do so whether
it was initially expected or not), the absolutely minimal thing
that can be done in the interest of _future_ damage is to create
a registry of the keywords that are being used in the hope of
minimizing the risk of inadvertent use of the same string for
different purposes. As Graham points out, we recognized that
problem with mail header field names, but there are many other
examples as well and I note that we've been gradually altering
existing registry definitions to move toward "let's at least
prevent conflicts" rather than "registration indicates the IETF
needs has blessed this use" (media type and URN namespace
registries come immediately to mind).
AFAICT, the only change that is being made to existing specs is
to provide that, if new keywords are used/added, they should
probably be registered too. That is not either harmonization
for its own sake or a protocol change; it is just an
administrative adjustment in how new keywords or actions are
documented.
I think the observation that we are needing to do this again
suggests something else that I hope the IESG can consider and
adopt as part of its review procedures (e.g., maybe in the
shepherd template questions). We probably need to be much more
aggressive about asking whether new protocols or specs include,
or are creating, lists of things that might be expanded in the
future, identifying them, and just create the registries the
first time around. If FCSF is the default (as Dave suggests
here), such a requirement does not imply significant new work or
long-term commitments or, e.g., designated experts. It seems
to me that would be far preferable to having to go through these
later exercises of registry creation (including gathering old
data to seed them) that seem to almost always stir up
controversies that have little or nothing to do with the
registries themselves.
However, that suggestion, which I trust the ART ADs are reading
and able to share with their colleagues, is very much about
doing things right in the future rather than about Dave's modest
and focused proposal to, as far as I'm concerned, is just fixing
an earlier omission and thereby lowering risk of name conflicts
going forward.
best,
john
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
