Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

what this means is, if someone sees _TCP in use for some rr type, and they needed something like this for their own new rr type, they should be encouraged to either use _TCP if they find it's the best fit, or use something else if they find that a best fit. they should not worry either away

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

John R. Levine wrote: Catching up: ... if you view the use of _tcp by more than one rrtype as a coincidence rather than as evidence for the need for a registry, then we can simply define the global registry out of existence (where it has been until now) and ensure that every rrtype's registry

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

Catching up: Assuming we agree that the table also says where to find the registry for second level names, this removes and need for special cases. The top level names _tcp _udp _sctp _dccp all work for SRV and URI and take service names on the second level. if you view the use of _tcp by

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

On 3/29/2018 3:38 PM, Adam Roach wrote: I still don't fully understand the nature of the objections I cite above or the assertions that having separate tables for different RRTYPEs is somehow broken. Based on my (admittedly lay) understanding of how DNS is used by other protocols, I agree with

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

--On Thursday, March 29, 2018 22:00 +0100 Warren Kumari wrote: > On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker > wrote: >> On 3/29/2018 1:45 PM, Warren Kumari wrote: >>> >>> I don't want to get into if this is the*right* behavior or >>> not, but it

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

On 3/26/2018 8:18 AM, Martin Hoffmann wrote: Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and OPENPGPKEY all use underscore labels and are currently missing from the initial table in section 3.1. Added TLSA to the next version of the draft. d/ -- Dave Crocker Brandenburg

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

On 26/03/2018 20:49, John R. Levine wrote: > Assuming we agree that the table also says where to find the registry > for second level names, this removes and need for special cases.  The > top level names _tcp _udp _sctp _dccp all work for SRV and URI and take > service names on the second level.

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

John R. Levine wrote: ... Assuming we agree that the table also says where to find the registry for second level names, this removes and need for special cases. The top level names _tcp _udp _sctp _dccp all work for SRV and URI and take service names on the second level. if you view the use

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

| _spf| TXT | [RFC7208] | <- That's just a mistake. Take it out. Apropos of John K's comment about per-type names, he's right. Given that people can do whatever they want I have to agree that if people want to define names that way, we can't prohibit them. Assuming we

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

On Mon, Mar 26, 2018 at 7:38 AM, John C Klensin wrote: > > . . .Table 1 of the I-D is > > +-+-++ > | _NODE NAME | RR | REFERENCE | > +-+-++ > | _tcp| SRV | [RFC2782] | > | _udp

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

Dave Crocker wrote: > > On 3/26/2018 8:18 AM, Martin Hoffmann wrote: > > Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and > > OPENPGPKEY all use underscore labels and are currently missing > > from the initial table in section 3.1. > > > The table there is for the right-most

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

On 3/26/2018 8:18 AM, Martin Hoffmann wrote: Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and OPENPGPKEY all use underscore labels and are currently missing from the initial table in section 3.1. The table there is for the right-most underscore name, which RFC 6698 seems to