Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
On 11/4/2018 7:08 PM, Ray Bellis wrote: On 05/11/2018 09:56, Dave Crocker wrote: So I immediately went to add it and then realized that doing this cleanly will take an entry for each RR... Why not this? ++--++ | RR Type | _NODE NAME | REFERENCE | ++--++ | * | _example | [TBD] | Well, that's two of you making close to the same suggestion (though the version Erik suggested seems a bit more complete. Absent objections, I'll add that. 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-15.txt
On 05/11/2018 09:56, Dave Crocker wrote: Clever suggestion. Seems like obvious benefit with no obvious detriment. So I immediately went to add it and then realized that doing this cleanly will take an entry for each RR... Why not this? ++--++ | RR Type| _NODE NAME | REFERENCE | ++--++ | * | _example | [TBD] | Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
On Mon, 5 Nov 2018 at 09:56, Dave Crocker wrote:
>
> On 11/4/2018 6:28 PM, Erik Kline wrote:
> > One thing I missed earlier (and please forgive me if this was already
> > discussed), was whether or not _example* should be reserved in the
> > table in draft-ietf-dnsop-attrleaf-15#section-4.3.
> >
> > Basically, is there any value in reserving _example* for future RFCs
> > to use (ones that don't care about the specific _foo label but apply
> > to all such labels in some way).
>
>
> Clever suggestion. Seems like obvious benefit with no obvious detriment.
>
> So I immediately went to add it and then realized that doing this
> cleanly will take an entry for each RR...
>
> Not so sure we want to do that?
Perhaps doable via a {see section #X.Y} e.g.:
| * | _example* {see #X.Y} | [this doc] |
X.Y Reserved _example* label
For use in RFC documentation describing behaviour applicable to
any label associate with any RR type. More awesome text also goes
here.
I'm not sure about the strictness requirements for this kind of table for IANA.
Also, this doesn't address whether it's an actually useful suggestion. :-)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
On 11/4/2018 6:28 PM, Erik Kline wrote: One thing I missed earlier (and please forgive me if this was already discussed), was whether or not _example* should be reserved in the table in draft-ietf-dnsop-attrleaf-15#section-4.3. Basically, is there any value in reserving _example* for future RFCs to use (ones that don't care about the specific _foo label but apply to all such labels in some way). Clever suggestion. Seems like obvious benefit with no obvious detriment. So I immediately went to add it and then realized that doing this cleanly will take an entry for each RR... Not so sure we want to do that? 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-15.txt
Dave (others), One thing I missed earlier (and please forgive me if this was already discussed), was whether or not _example* should be reserved in the table in draft-ietf-dnsop-attrleaf-15#section-4.3. Basically, is there any value in reserving _example* for future RFCs to use (ones that don't care about the specific _foo label but apply to all such labels in some way). Sorry for the last-minute distraction, -Erik On Sun, 4 Nov 2018 at 03:23, 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-15.txt > Pages : 14 > Date: 2018-11-03 > > Abstract: >Formally, any DNS resource record may occur under any domain name. >However some services use an operational convention for defining >specific interpretations of an RRset, by locating the records in a >DNS branch, under the parent domain to which the RRset actually >applies. The top of this subordinate branch is defined by a naming >convention that uses a reserved node name, which begins 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-15 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-15 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > 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-15.txt
On 11/3/2018 4:55 PM, Warren Kumari wrote: I'm also somewhat confused by the quoting in: "In the case of the "SRV" "RR" and "URI" "RR", distinguishing among different types" (and in "defining "RR"s that might" ) - I'm not sure if it is intentional, but it doesn't align with much of the rest of the formatting, and is (IMO) confusing around the first part.) I used spanx too liberally, because it looked nice in the html version on my machine, and I didn't realize what it did for the text version. My use matched what I'm seeing in some bibxml entries, but you are right that it doesn't look right in some of the sequences here. So I've removed most spanx occurrences in the source. Also nit (I think): Adam Roach, Petr paek, Ondej Sury This is a dilemma. The characters produce appropriate text in html, to show his actual name. The xml2rfc text rendering engine produces this silliness and I'm inclined to class it as a bug in the engine. If there is an established practice for working around that bug, to produce the proper characters in html and an 'acceptable' alternative in text, please let me know and I'll fix it. 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-15.txt
Section 4.3 claims RFC7671 reserves "_dane": " ++--++ | RR Type| _NODE NAME | REFERENCE | ++--++ .. | TLSA | _dane| [RFC7671] | " I can't see any support of this in RFC7671. I assume the misunderstanding comes from a couple of examples using a "_dane" label. But this is an arbitrary choice, and not an attempt to reserve a name. For example from RFC7671 section 5.2: " Some domains may prefer to avoid the operational complexity of publishing unique TLSA RRs for each TLS service. If the domain employs a common issuing CA to create certificates for multiple TLS services, it may be simpler to publish the issuing authority as a TA for the certificate chains of all relevant services. The TLSA query domain (TLSA base domain with port and protocol prefix labels) for each service issued by the same TA may then be set to a CNAME alias that points to a common TLSA RRset that matches the TA. For example: ; Two servers, each with its own certificate, that share ; a common issuer (TA). ; www1.example.com.IN A 192.0.2.1 www2.example.com.IN A 192.0.2.2 _443._tcp.www1.example.com. IN CNAME tlsa._dane.example.com. _443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com. tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... " It is obvious from this that "tlsa._dane.example.com." is a placeholder alias, and not reserving "tlsa" or "_dane" labels. The consistent choice of "tlsa._dane" in the RFC7671 examples might have contributed to this confusion. Something to keep in mind for future DNS label examples. Use your fantasy :-) Bjørn ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
I'm also somewhat confused by the quoting in: "In the case of the "SRV" "RR" and "URI" "RR", distinguishing among different types" (and in "defining "RR"s that might" ) - I'm not sure if it is intentional, but it doesn't align with much of the rest of the formatting, and is (IMO) confusing around the first part.) That's xml2rfc being helpful. The xml says those are verbatim strings and it added the quotes. I presume the editors can fix this. Probably nit: Section 2: "Only global underscored names are registered in the IANA Underscore Only the global underscored names "_service1", "_service2", Global table. (From the example, that would mean registering "_service3", "_service4", and "_authority" are registered in the IANA _service1, _service2, _service3, _service 4, and _authority.)" First sentence repeats. In xml it is clear that two lines of old text weren't deleted. I stared at the table of names and I think it's right, but it's the meat of the document and more people looking at it would be good. 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
[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
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-15.txt Pages : 14 Date: 2018-11-03 Abstract: Formally, any DNS resource record may occur under any domain name. However some services use an operational convention for defining specific interpretations of an RRset, by locating the records in a DNS branch, under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
