On 5/12/2018 1:01 PM, John R Levine wrote:
The best I can guess is that there is an underlying assumption that
normative language only applies to formally published specifications,
but there's nothing in the current draft language to support that.
No, it's that standards are about interoperating with people you don't
know. That was the point of the two-implementation rule. This
particular situation is unusually squishy because we have a list of
protocol names and a list of enumservice types that aren't in the
registry but in practice it'd work fine if someone used one of them
because none of the names currently conflict.
Avoiding naming collisions is a form of interoperating. Perhaps
unfortunately, we have extensive experience that failing to coordinate
across independent efforts -- ie, failing to have a common registry --
does not cause immediate failure.
My current thought is that the draft's language should direct a MUST for
'published' specifications. This would implicitly leave private,
developmental efforts free to experiment without registration.
Note that SHOULD really is the same as MUST, except it allows for a
'unless you really know what you are doing'. That, it seems to me, is
exactly right, for this issue.
Except that in reality people violate MUST all the time, often for good
reasons. This is why I don't understand the difference any more.
Oh? They do? And it isn't because the MUST should have been a SHOULD?
And it isn't because those good reasons aren't really all that good?
And it isn't because...
You offer your summary assessment without any detail, but apparently
intend it to negate the clearly-defined semantic distinction and usage
intent behind the two normative choices.
It's entirely possible that some specification writers or working groups
have been sloppy. And there are are other possibilities. None of which
justify ignoring the meaning and purpose of the normative choices.
I suggest, instead, that the working group should consider what the
force and import of a MUST would be, versus the force and import of a
SHOULD, and that it do that on the assumption that the terms mean what
they are defined to mean and should be used as they are intended to be used.
In section 1 you might want to add a sentence or two pointing out that
every rrtype has its own _name namespace, something that took a lot of
us quite a while to figure out.
I'll urge not doing that. Yes, it's a mathematical truth, but it's
one that I believe some/many other folk will find confusing in
practical terms. (I know I certainly did...)
Then it should be more than a sentence or two, long enough to explain
it. It needs to be clear people who might register future names that if
_foo on SRV and _foo on TXT mean different things, that's not a problem.
OK, but absent your suggesting specific text, I don't know what will
satisfy.
For URIs, I'd add all of the existing enumservice type names to the
draft-ietf-dnsop-attrleaf initial name list in section 3.1, and in
I'll guess that you mean the existing entries in the 'type' column of:
https://www.iana.org/assignments/enum-services/enum-services.xhtml
which appears to be:
acct
email ...
which seems quite a lot of pre-loading, for an RR that has almost no
use, so far. I would instead suggest pre-loading only those 'type'
values we know to be already in use and press for additional entries
when they will get used.
This is what we've done for Proto, so why not the same approach for
enumservice?
I suppose that's OK. Do we have any idea of what the handful of URIs in
the wild actually use?
I don't.
Does anybody in the working group know the details of current URI RRset
usage?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
