Subject: Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Feb 2018 16:03:50 -0500

To be clear, I agree that it's a small point, and I was mostly
interested for other reasons having to do with another draft (the one
I mentioned).  I didn't think this was a blocking question.

On Wed, Jan 31, 2018 at 09:44:10AM +1000, George Michaelson wrote:
> I think we're rat holing.

[…]

> On Wed, Jan 31, 2018 at 4:51 AM, Andrew Sullivan <[email-masked]> wrote:
> > On Tue, Jan 30, 2018 at 10:42:15AM -0500, Joe Abley wrote:
> >
> >> I probably missed some. Anyway, I think when people are saying "address record" here they actually mean "IP address record".
> >>
> >
> > We should probably say that, then, and also of course we should fix
> > the poor text in the teminology document to point this out.

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Feb 2018 16:20:14 -0500

Hi,

Please note that this is not about the document that started this
thread.  It's a rathole, but in a different field.

On Tue, Jan 30, 2018 at 04:58:01PM -0800, Paul Hoffman wrote:
 
> Please, no. As the originator of the original
> <letter><letter><hyphen><hyphen> hack, I think this is the wrong thing to do
> for many reasons. The biggest one is, sadly, the fact that some software now
> has <letter><letter><hyphen><hyphen> as reserved even though it should not.

I am not convince that "it should not" is true, and having thought
about this a little more it seems to me that an IANA registry should
have been created in the first place for this sort of miserable
in-label hack.  If it had been, we could have done something useful
here.  And if we don't do so now, in short order we're going to be
into the multi-level underscore-label hell that underscore labels are.

RFC 5891 explicitly says that any IDNA-handling software can't accept
a string with two hyphens in the third and fourth character positions
(that is, in a crappy regex, can't take ^..\-\-.*) as a candidate
Unicode string to be a label (see 4.2.3.1).  This causes upset in
section 5.4 of the same document, which is I suspect how Paul's "sad"
software came to be.

It seems plain therefore that a registry of in-band in-label prefixes
ought to be created, so that instead of heuristics in IDNA2008 we
could tell people to use a real rule.

Before I go to the bother of writing this up, are there at least five
people who would review it, noting that it must update RFC 5891 to be
useful?

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 01 Feb 2018 13:37:55 -0800

> people who would review it, noting that it must update RFC 5891 to be

<raises hand>

As a note, this is related to but different from 
<https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf>, which has been 
expired for four months but is still a WG document.

--Paul Hoffman

---

From: Bob Harold <[email-masked]>
Date: Fri, 2 Feb 2018 13:42:46 -0500

On Thu, Feb 1, 2018 at 4:37 PM, Paul Hoffman <[email-masked]> wrote:

> As a note, this is related to but different from <
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf>, which has been
> I will review.

-- 
Bob Harold

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 13 Feb 2018 14:46:43 -0500

> into the multi-level underscore-label hell that underscore labels are.

I recall that when I once read a sentence to the effect that, "xn-- is
defined to signal punycode, and no other label of the form ^..\-\- may
exist in the DNS," my first thought was that this was silly, and it should
simply have been defined as the first entry in a new registry.

So yes, I'll review and comment.