Subject: Re: Underscores

From: Dave Crocker <[email-masked]>
Date: Fri, 11 May 2018 20:25:36 -0700

On 5/11/2018 9:16 AM, Ben Schwartz wrote:
> Hi Dave,
> 
> I'm working on a draft in HTTPBIS proposing a new RRTYPE that uses 
> underscores:
> https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02#section-2
> 
> Does this underscore pattern match your new recommendation?  If you 
> could send your thoughts to the HTTP mailing list [1], that would help 
> us make sure we're getting the structure right, since we're not DNS experts.
> 
> Thanks,
> Ben Schwartz
> 
> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Folks,

G'day.  Ben asked me to respond to the wg mailing list.

First, thanks to Ben for noting the parallel effort on the global 
_underscore registry and for opening a dialogue about it and his draft.

Second, unfortunately I think that draft-schwartz-httpbis-dns-alt-svc 
is, in fact, problematic with respect to its _underscore-related text, 
since it draws from whatever 'scheme' is desired, to be used as the 
global underscored name.

The SRV and URI specs introduce a imilar meta-problem for the 
_underscore registry, by drawing their global underscored DNS node name 
from other tables.  The underscore work in the dnsop wg is splitting the 
topic between a 'clean sheet' specification that defines the registry 
and creates initial entries, but does not try to fix any existing 
specifications.

A second dnsop draft:

    DNS Attrleaf Changes: Fixing Specifications with _Underscored Node 
Name Use
 
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-fix-00.txt

was just created, to offer text that updates existing documents, which 
specify _underscored DNS node name use.

The dns-alt-svc spec adds yet one more such 'external' table as a source 
of underscored name, lacking coordination with the central registry we 
are defining.

My reading of the dns-alt-svc document status within this working group 
is that there is still time to adjust its text before wg last call and I 
eagerly hope the working group will consider making that modification.

The attrleaf-fix draft contains proposals for language that should be 
used for the meta-specification of SRV and URI underscored node name 
use. I believe the template I've offered for them can be easily adapted 
to your own draft.

The world won't end if you decide not to make the change at this time, 
but gosh it would be nice to get IETF specs to start using the new 
registry...

Thanks.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Mike Bishop <[email-masked]>
Date: Sat, 12 May 2018 05:16:41 +0000

Given that the document hasn't yet been adopted, there's plenty of room for adjustments before last call.  😉

Personally, so long as there's a way to go from an HTTP origin to a DNS lookup, I'm amenable to just about any encoding that makes DNSop happy.

-----Original Message-----
From: Dave Crocker <[email-masked]>
Sent: Friday, May 11, 2018 8:26 PM
To: [email-masked]
Subject: Re: Underscores

> https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02#sect

> ion-2

Folks,

First, thanks to Ben for noting the parallel effort on the global _underscore registry and for opening a dialogue about it and his draft.

is, in fact, problematic with respect to its _underscore-related text, since it draws from whatever 'scheme' is desired, to be used as the global underscored name.

The SRV and URI specs introduce a imilar meta-problem for the _underscore registry, by drawing their global underscored DNS node name from other tables.  The underscore work in the dnsop wg is splitting the topic between a 'clean sheet' specification that defines the registry and creates initial entries, but does not try to fix any existing specifications.

A second dnsop draft:

    DNS Attrleaf Changes: Fixing Specifications with _Underscored Node Name Use

was just created, to offer text that updates existing documents, which specify _underscored DNS node name use.

The dns-alt-svc spec adds yet one more such 'external' table as a source of underscored name, lacking coordination with the central registry we are defining.

My reading of the dns-alt-svc document status within this working group is that there is still time to adjust its text before wg last call and I eagerly hope the working group will consider making that modification.

The attrleaf-fix draft contains proposals for language that should be used for the meta-specification of SRV and URI underscored node name use. I believe the template I've offered for them can be easily adapted to your own draft.

The world won't end if you decide not to make the change at this time, but gosh it would be nice to get IETF specs to start using the new registry...

Thanks.

d/

--

Dave Crocker

bbiw.net

--

Dave Crocker

bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 May 2018 11:32:31 -0700

> for adjustments before last call. 😉

Oh good...

> Personally, so long as there's a way to go from an HTTP origin to a DNS 
> lookup, I'm amenable to just about any encoding that makes DNSop happy.

Well, I'm a visitor to that working group, though I'm authoring the 
drafts.  So I can't presume to speak for the working group.  But in 
terms of pragmatics, I think adapting the type of language I've put 
forward for SRV and URI meta-specifications out to work.

The essential change in thinking, for the dns-alt-svc document, is to 
refer to the global (right-most) _underscored name conceptually as a 
'scheme', but then direct its explicit listing in the new global 
underscore node name registry.

d/

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 15 May 2018 15:33:05 -0400

> underscore node name registry.

OK.  I think there would be two relevant changes:

1. In Section 2 (the record type description), add:

The scheme SHOULD be a member of both the IANA URI Schemes Registry
[RFC7595]
and the IANA DNS Underscore Global Scoped Entry Registry [Attrleaf].  The
scheme
SHOULD be one for which Alt-Svc is defined (currently "http" or "https").

2. In the IANA considerations section, add

This draft directs IANA to add "http" and "https" to the IANA DNS
Underscore Global
Scoped Entry Registry [Attrleaf].  Any future draft that extends Alt-Svc to
additional
schemes SHOULD add those schemes to this registry as well.

Does that look right to you?

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 May 2018 12:03:34 -0700

Thanks for the ping.  Finally was able to do an update on the two 
attrleaf documents.

On 5/15/2018 12:33 PM, Ben Schwartz wrote:
> and the IANA DNS Underscore Global Scoped Entry Registry [Attrleaf].  
> The scheme

I think the paragraph should appear between the Section 2 "In the case 
of" and "The RDATA portion" paragraphs.

I'd prefer your using MUST rather than SHOULD, but that's a point of 
some debate.

Alternate wording that is probably closer to the language and 
perspective of the attrleaf documents, but still in line with what 
you've written:

    The scheme SHOULD have an entry in the IANA URI Schemes Registry 
[RFC7595].  The IANA DNS Underscore Global Scoped Entry Registry 
[Attrleaf] [SHOULD / MUST] have an entry under the ALT-SVC RRType, for 
the scheme.

> Scoped Entry Registry [Attrleaf].  Any future draft that extends Alt-Svc 
> to additional

It needs more detail and less contingent or future-looking language. 
IANA does stuff now.  Any normative text for others needs to be 
elsewhere in the document.

While the new 'fix' document provides versions of that detail, I now 
realize the base Attrleaf document needs a generic form of that 
guidance, exactly for cases like yours.

Here's the template text I'm going to suggest for the base text:

         <t><list>
                <t><spanx style="verb">Per</spanx> {RFC Attrleaf}
                   <spanx style="verb">please add the following entry to 
the DNS
                   Underscore Global Scoped Entry Registry:</spanx></t>
             </list><list hangIndent="Note to RFC Editor: ">
                <t>Please replace the above "{RFC Attrleaf}" text with a
                   reference to this document's RFC number. /d</t>
             </list></t>

          <texttable align="center" anchor="srventry"
             title="Underscore Global Registry Entry">
             <ttcol>RR Type</ttcol>
             <ttcol>_NODE NAME </ttcol>
             <ttcol>REFERENCE</ttcol>
             <!---->

             <c>{RRTYPE}</c>
             <c>_{DNS global node name}</c>
             <c> {citation for the document making the addition.}</c>
             <!---->
          </texttable>