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.
Sure. Like I said, private arrangements don't count.
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.
As best as I can tell, MUST means you have to do this to interoperate with
strangers. SHOULD means the same thing except that if you're an expert,
there might be places you can cheat and interoperate with strangers
anyway.
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.
The natural place to put it is at the top of section 2, before the
descriptions of the different meainings of underscore names for various
rrtypes.
I don't know how philosophical to get here. As far as I can tell there
are three models of _name use.
1. The contentious one, instead of a new rrtype, _dmarc and _acme-challenge.
2. To import a different namespace into the DNS as in SRV, URI, TLSA, and
badly in SMIMEA and OPENPGPKEY.
3. To delimit a sub-namespace for _domainkey and _vouch. Think of how
foo.bar._domainkey.example.com differs from
foo._domainkey.bar.example.com.
I don't think we need to put any of that in the draft. I'd suggest adding
this at the top of section 2, before the section header 2.1:
The interpretation of an underscore label is specific to the RRTYPE that
it names, and a name such as _example might or might not be used the same
way with different RRTYPEs. The sections below describe the way that
existing underscore labels are used with the RRTYPEs that they name.
R's,
John
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
