Hi Tim, On May 10, 2024, at 04:29, Tim Wicinski <tjw.i...@gmail.com> wrote:
> I wrote a note to Peter and his co-author on this discussion and we(chairs) > feel that Paul W is correct in saying _signal is too generic. > > We should not overload any underscore label for multiple purposes. If > another type of operator signalling appears, a new label can be acquired. I'm interested in where this guidance comes from. RFC 2782 to me is the grandfather of underscore labels, and it pretty much goes out of its way to encourage a hierarchy of underscore labels to anchor SRV records under, e.g. under _tcp.name and _udp.name. You could argue that those are not multiple purposes (everything under _tcp is TCP, after all) but it feels like the same argument could be made for _signal. > Being specific in this situation is a *good* thing. How is _purpose1._concept.name ... _purpose2._concept.name ... less specific than _purpose1_concept.name ... _purpose2_concept.name ... ? > Additionally in the Domain Verification Techniques document, there is a > recommended approach to use application-specific underscore prefix labels > > https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-04.html#name-scope-indication I'm struggling slightly to see how the advice in that document applies, here. I realise underscore labels are used in both cases, but in the domain validation case we are trying to avoid collisions in the absence of a registry. That's not our situation, here. I'm not really arguing with conclusion, but I find the guidance vague. If we really think it's important to make clear statements about this, perhaps we should write something down in a document and talk about it. Personally I'm not convinced it's that important, though. Joe
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
