Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
I prefer a regex and I think that Dave's "_ta-.*" makes most sense. An
explanation that it is a regex and that the exact format of the name is found
in RFC 8145 is needed.
Mats
---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/
On 2018-07-25, 21:58, "DNSOP on behalf of John Levine" wrote:
In article <9ac469b7-031a-4d8c-53d0-a82abca0d...@dcrocker.net>,
Dave Crocker wrote:
>On 7/25/2018 10:59 AM, Bob Harold wrote:
>> Dot "." has special meaning in DNS, so I would prefer:
>>
>> Â Â _ta-*
>>
>> Not regex, but a common wildcard usage.
>
>wfm.
I suppose. A plausible actual regex would be
_ta(-[0-9a-z]{4}){1,12}
which might be a bit dense. That's not quite right because the
numbers in the label have to be sorted, but there's no way to say that
in a regex other than enumerating them which would be bulky.
Whatever you do, please put include some text reminding people that it's
a conceptual glob stype wildcard, not a DNS wildcard.
R's,
John
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for
Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
In article <9ac469b7-031a-4d8c-53d0-a82abca0d...@dcrocker.net>,
Dave Crocker wrote:
>On 7/25/2018 10:59 AM, Bob Harold wrote:
>> Dot "." has special meaning in DNS, so I would prefer:
>>
>> Â Â _ta-*
>>
>> Not regex, but a common wildcard usage.
>
>wfm.
I suppose. A plausible actual regex would be
_ta(-[0-9a-z]{4}){1,12}
which might be a bit dense. That's not quite right because the
numbers in the label have to be sorted, but there's no way to say that
in a regex other than enumerating them which would be bulky.
Whatever you do, please put include some text reminding people that it's
a conceptual glob stype wildcard, not a DNS wildcard.
R's,
John
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
I like Bob's suggestion. On Wed, Jul 25, 2018 at 2:06 PM, Dave Crocker wrote: > On 7/25/2018 10:59 AM, Bob Harold wrote: > >> Dot "." has special meaning in DNS, so I would prefer: >> >> _ta-* >> >> Not regex, but a common wildcard usage. >> > > wfm. > > anyone else care to chime in? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On 7/25/2018 10:59 AM, Bob Harold wrote: Dot "." has special meaning in DNS, so I would prefer: _ta-* Not regex, but a common wildcard usage. wfm. anyone else care to chime in? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On 7/25/2018 10:59 AM, Bob Harold wrote: Dot "." has special meaning in DNS, so I would prefer: _ta-* Not regex, but a common wildcard usage. wfm. anyone else care to chime in? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On Wed, Jul 25, 2018 at 1:50 PM Dave Crocker wrote: > On 7/25/2018 2:32 AM, Mats Dufberg wrote: > > _ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf. > > > Wow. This is a unique case, since it reserves essentially all of an > even-more-subordinate namespace -- everything to the right of that dash. > > Theoretically it isn't that inclusive but in practical terms, unless we > want complex pattern-matching for sub-strings at run-time, it is. > > I'm inclined to have the notation be: > > _ta-.* > > to draw from regex, with an explicit reference to that, unless folks > agree on something else. (Yes, that's 'pattern matching' but it's in > the specification document, not the operational code.) > > Thoughts? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > Dot "." has special meaning in DNS, so I would prefer: _ta-* Not regex, but a common wildcard usage. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On 7/25/2018 2:32 AM, Mats Dufberg wrote: _ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf. Wow. This is a unique case, since it reserves essentially all of an even-more-subordinate namespace -- everything to the right of that dash. Theoretically it isn't that inclusive but in practical terms, unless we want complex pattern-matching for sub-strings at run-time, it is. I'm inclined to have the notation be: _ta-.* to draw from regex, with an explicit reference to that, unless folks agree on something else. (Yes, that's 'pattern matching' but it's in the specification document, not the operational code.) Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
/no/ changes to the spec, except to correct the typo Bob Harold spotted. Correct? On Wed, Jul 25, 2018 at 9:23 AM, Dave Crocker wrote: > > For completeness: > > Absent further discussion and agreement in the wg, I taking this > exchange as producing /no/ changes to the spec. > > d/ > > > On 7/24/2018 7:58 AM, John Levine wrote: > >> In article <9da145f4-df6a-4bfa-b3c9-56027b228...@iis.se> you write: >> >>> -=-=-=-=-=- >>> In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp >>> (SRV), but those “_node names” >>> are not even mentioned in the RFC. Are they defined elsewhere? >>> >> >> RFC 2782 says that SRV's are named with _proto where proto is is a >> protocol name. RFCs 3588 and 6733 say to do _sctp SRV lookups, but >> don't further define them, and only have 2782 as an informative >> reference. No RFC mentions _dccp. >> >> It seems to me that 2782 is the right reference for _sctp. For _dccp >> we've had arguments about whether 2782 says that a SRV can be named by >> any protocol so maybe we should put in every protocol in the IANA >> registry. That's a lot of dead protocols. A reasonable compromise >> would be to start the registry with the names that have some evidence >> of being used somewhere, so we could drop _dccp >> >> In the same table, the draft refers to RFC 7553 for a number of URI _node >>> names, but the references are quite >>> indirect. Could references to relevant IANA registries be added? >>> >> >> Since RFC 7553 is the place that says that the enumservice names turn >> into _node names, I think that's the right reference. >> > > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
For completeness: Absent further discussion and agreement in the wg, I taking this exchange as producing /no/ changes to the spec. d/ On 7/24/2018 7:58 AM, John Levine wrote: In article <9da145f4-df6a-4bfa-b3c9-56027b228...@iis.se> you write: -=-=-=-=-=- In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), but those “_node names” are not even mentioned in the RFC. Are they defined elsewhere? RFC 2782 says that SRV's are named with _proto where proto is is a protocol name. RFCs 3588 and 6733 say to do _sctp SRV lookups, but don't further define them, and only have 2782 as an informative reference. No RFC mentions _dccp. It seems to me that 2782 is the right reference for _sctp. For _dccp we've had arguments about whether 2782 says that a SRV can be named by any protocol so maybe we should put in every protocol in the IANA registry. That's a lot of dead protocols. A reasonable compromise would be to start the registry with the names that have some evidence of being used somewhere, so we could drop _dccp In the same table, the draft refers to RFC 7553 for a number of URI _node names, but the references are quite indirect. Could references to relevant IANA registries be added? Since RFC 7553 is the place that says that the enumservice names turn into _node names, I think that's the right reference. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
RFC 8145 defines the _ta- node name: A Key Tag query consists of a standard DNS query of type NULL and of class IN [RFC1035]. The first component of the query name is the string "_ta-" followed by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag values. The zone name corresponding to the trust anchor is appended to this first component. (RFC 8145, page 8) _ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf. Mats --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On 7/23/2018 2:22 PM, Tim Wicinski wrote: ooks like a typo. That has been there for a bit. ... The table on page 6 includes: "._protoB._service2" Given that it's the only one like that, yes, it should be changed. Just to bikeshed the issue, note that it's not 'wrong' to have the dot there, given the nature of this registration activity and therefore the context that the examples are going to get used in. But certainly things need to be consistent and that one isn't. Thanks for catching it, Bob. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
In article <9da145f4-df6a-4bfa-b3c9-56027b228...@iis.se> you write: >-=-=-=-=-=- >In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), >but those “_node names” >are not even mentioned in the RFC. Are they defined elsewhere? RFC 2782 says that SRV's are named with _proto where proto is is a protocol name. RFCs 3588 and 6733 say to do _sctp SRV lookups, but don't further define them, and only have 2782 as an informative reference. No RFC mentions _dccp. It seems to me that 2782 is the right reference for _sctp. For _dccp we've had arguments about whether 2782 says that a SRV can be named by any protocol so maybe we should put in every protocol in the IANA registry. That's a lot of dead protocols. A reasonable compromise would be to start the registry with the names that have some evidence of being used somewhere, so we could drop _dccp >In the same table, the draft refers to RFC 7553 for a number of URI _node >names, but the references are quite >indirect. Could references to relevant IANA registries be added? Since RFC 7553 is the place that says that the enumservice names turn into _node names, I think that's the right reference. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
Bob Looks like a typo. That has been there for a bit. Tim On Mon, Jul 23, 2018 at 4:21 PM, Bob Harold wrote: > > On Sat, Jul 21, 2018 at 12:11 PM wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations WG of the >> IETF. >> >> Title : DNS Scoped Data Through "Underscore" Naming of >> Attribute Leaves >> Author : Dave Crocker >> Filename: draft-ietf-dnsop-attrleaf-12.txt >> Pages : 13 >> Date: 2018-07-21 >> >> Abstract: >>Formally, any DNS resource record may occur under any domain name. >>However some services have defined an operational convention, which >>applies to DNS leaf nodes that are under a DNS branch having one or >>more reserved node names, each beginning with an _underscore. The >>underscored naming construct defines a semantic scope for DNS record >>types that are associated with the parent domain, above the >>underscored branch. This specification explores the nature of this >>DNS usage and defines the "DNS Global Underscore Scoped Entry >>Registry" with IANA. The purpose of the Underscore registry is to >>avoid collisions resulting from the use of the same underscore-based >>name, for different services. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-12 >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-12 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-12 >> > > The table on page 6 includes: > > "._protoB._service2" > > > Why the dot at the beginning? None of the other lines have that. > > > -- > > Bob Harold > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On Sat, Jul 21, 2018 at 12:11 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : DNS Scoped Data Through "Underscore" Naming of > Attribute Leaves > Author : Dave Crocker > Filename: draft-ietf-dnsop-attrleaf-12.txt > Pages : 13 > Date: 2018-07-21 > > Abstract: >Formally, any DNS resource record may occur under any domain name. >However some services have defined an operational convention, which >applies to DNS leaf nodes that are under a DNS branch having one or >more reserved node names, each beginning with an _underscore. The >underscored naming construct defines a semantic scope for DNS record >types that are associated with the parent domain, above the >underscored branch. This specification explores the nature of this >DNS usage and defines the "DNS Global Underscore Scoped Entry >Registry" with IANA. The purpose of the Underscore registry is to >avoid collisions resulting from the use of the same underscore-based >name, for different services. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-12 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-12 > The table on page 6 includes: "._protoB._service2" Why the dot at the beginning? None of the other lines have that. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
