Subject: [DNSOP] Fwd: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Aug 2016 20:47:29 -0700

John's note...

-------- Forwarded Message --------
Subject: Re: [apps-discuss] Draft of interest in DNSOP: 
draft-ietf-dnsop-attrleaf
Date: 4 Aug 2016 01:58:40 -0000
From: John Levine <[email-masked]>
To: [email-masked]
CC: [email-masked]

>As for the second-level underscore names, I propose that they /also/ be
>registered in this one table.  In theoretical terms, one could argue for
>a separate table, or maybe many of them (one under each top-level
>underscore protocol name) but that purity-drive choice seems somewhere
>between inefficient and silly.

That doesn't seem like a great idea.  According to RFC 2782, SRV names
are:

  _service._protocol.blah.example

Name assignment was a mess due to the rather casual advice in 2782
until RFC 6335 cleaned it up five years ago.

There appear to be only four protocols that have ever been used for
SRV records: _udp, _tcp, _sctp, and _dccp.  RFC 6335 refers to them
but doesn't set up a registry.  The names are in the Assigned Internet
Protocol Numbers registry, but most of the entries in that registry
are obsolete and some have names with plus signs and other unfortunate
characters, so I think it'd be fine to put the live protocol tags into
your list.

The services, on the other hand, were thoroughly cleaned up by RFC
6335.  It collected a bunch of informal lists into one place, renamed
a few old names with unfortunate characters, and put them into a tidy
and very large Service Name and Transport Protocol Port Number
Registry.  It says in section 5.2 that the service name for a SRV
record MUST follow the syntax rules (ldh with at least one letter and
no leading or trailing or double hyphens, prefixed with an underscore)
and SHOULD be registered in the registry.

That registry is FCFS for service names and now contains over 10,000
entries, so if you are aware of any SRV service names not listed, it'd
make a lot more sense to register them than to try to define something
new that sort of mirrors one of the largest registries that IANA manages.

For URI records RFC 7553 says they're either named the same as SRV
records, or they use enumservice names from the Enumservice
Registrations registry which lists two dozen types, most of which have
specific allowed subtypes.  This registry is a lot smaller than the
service name registry, but it exists, the RFC points to it, and it
seems unwise to copy its contents somewhere else.

Other than SRV and URI records, there's a handful of two component
prefix names like _adsp._domainkey and _report._dmarc.  As far as I
tell the rest are all all one or two per main name, so listing them
shouldn't be too hard.  But please, don't duplicate registries that
already exist.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Aug 2016 20:48:06 -0700

And now, my response to John's note...

> and SHOULD be registered in the registry.

If folks agree that this adequately serves the registry function for the 
_service, second-level underscore name for SRV and URI, that's fine.  As 
of Berlin, I thought I heard that there was (still) deviations.

However this introduces a requirement for some additional changes and 
I'm not exactly sure where.  SRV maps _serve to STD 2 and explicity maps 
that to RFC 1700.  So the SRV RFC needs to be updated.

But of course with additional research, I find that the RFC John is 
cited says that it already has updated the SRV RFC.  This provide 
yet-another example why we should aggressively deprecate use of RFC 
access via

    https://www.ietf.org/rfc/

in favor of the datatracker path, since the former doesn't show errata 
or update markers, while the latter does.  So does the RFC Editor's path:

    https://www.rfc-editor.org/info/rfc2782

Interestingly, STD 2 appears to have been formally eliminated, since it 
is not listed by the RFC Editor:

    https://www.rfc-editor.org/standards

So after going through all that and then looking at RFC 6335, including 
its assorted references to support for SRV, I gather the IANA table in 
question is:

    Service Name and Transport Protocol Port Number Registry

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

> records, or they use enumservice names from the Enumservice

Declaring a namespace as the union of two, independently-maintained 
registries is a very efficient way to encourage -- actually in 
theoretical terms, it guarantees -- collisions.

> shouldn't be too hard.  But please, don't duplicate registries that

This line of concern, I think, reduces to the view that the recent 
versions of the _underscore draft espoused, which is that the primary 
concern needs to be the top-level underscore name, since it draws from a 
'global' namespace.  For any interesting top-level underscore name -- 
_proto set for SRV are /not/ sufficiently interesting (distinctive) 
which is why we need to worry about their associated _service string -- 
any underscore names at a lower level are only of interest to the 
specification defining them.  That is, the global effort can ignore them.

Anyhow, if there is community agreement that the Service Name and 
Transport Protocol Port Number Registry is sufficient for SRV (and URI?) 
_proto names, then the current draft need do no more than include a 
reminder to consult that registry.  Yes?

d/

ps.  Hmmm.  Isn't this draft supposed to be discussed in dnsop and not apps?

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 4 Aug 2016 00:05:15 -0400

> If folks agree that this [RFC6355] adequately serves the registry 
function for the 
> _service, second-level underscore name for SRV and URI, that's fine. 
> As of Berlin, I thought I heard that there was (still) deviations.

I can believe it, but as I suggested, if that's the case, register the 
rogue names in the service name registry.  It's FCFS, not a big deal.

> says that it already has updated the SRV RFC.  This provide yet-another 
> example why we should aggressively deprecate use of RFC access via

Use the rfc-index.txt that comes along with the rsync'ed RFCs.  It has 
what is supposed to be a complete list of what updates and obsoletes what.

> registries is a very efficient way to encourage -- actually in theoretical 
> terms, it guarantees -- collisions.

I suppose, but since the two registries exist and the URI RFC says to use 
both of them as _name, that horse has left the barn.  In any particular 
context a URI record will either be used to look up a regular service or 
an enumservice but not both so if there were a collision, it wouldn't 
matter since the context would tell you which one is intended.  The RFC's 
authors are Patrik and Olaf, so we could ask them if that's what they had 
in mind.  At this point there are only four live proto names and two dozen 
enumservice names, so by my eyeball inspection, there's currently no 
collisions.

> This line of concern, I think, reduces to the view that the recent versions 
> of the _underscore draft espoused, which is that the primary concern needs to 
> be the top-level underscore name, since it draws from a 'global' namespace.

So far, so good.

> For any interesting top-level underscore name -- _proto set for SRV are /not/ 
> sufficiently interesting (distinctive) which is why we need to worry about 
> their associated _service string -- any underscore names at a lower level are 
> only of interest to the specification defining them.  That is, the global 
> effort can ignore them.

Is there an extra /not/ in there?  Service names only appear as child 
names of _proto so the _proto are the only ones that can have collision 
problems.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 4 Aug 2016 09:54:16 +0100

> As of Berlin, I thought I heard that there was (still) deviations.

The one I thought was a deviation was "xmpp-client" (5222), but it turns
out that's just because my macOS /etc/services file is out of date and
still lists that as "jabber-client".

Ray

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Aug 2016 09:55:14 -0700

> still lists that as "jabber-client".

Thanks for the clarification, Ray.

Absent anyone else raising concerns, I'll change the draft to remove any 
normative specification of second-level underscore names, and add some 
informative (non-normative) language pointing to the spiffy new(ish) and 
improved IANA table.

> theoretical terms, it guarantees -- collisions.

I see this as a fundamental problem with the URI spec, for the reason 
cited.  I also think the current spec should be careful not to promote 
that problem.

Suggestions?

d/
-- 
-- 

   Dave Crocker

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 09 Aug 2016 18:06:03 +0200

On 4 Aug 2016, at 18:55, Dave Crocker wrote:

> I see this as a fundamental problem with the URI spec, for the reason cited.  I also think the current spec should be careful not to promote that problem.
>
> Suggestions?

Add text that say that to resolve conflicts (what prefixes to use for URI or SRV for "the web"?), it is encouraged to write explicit documents that say what is to be used.

I just submitted draft-faltstrom-httpbis-dns-00.txt is an example of what I am thinking of, for URI and "the web", which explicitly say what to enter into the registry that is defined by this document. My envision is to add more text on the recommended way to use DNS in the case of "the web".

TL;DR: draft-faltstrom-httpbis-dns-00.txt recommends _web._http for "the web". Regardless of the registration of both ENUM services HTTP and HTTPS, regardless of the various "names" used for port number 80 (etc) and regardless of whether TCP or UDP (and other things being part of the HTTP evolution...).

It is "just" used for rewrite of the URI before the HTTP protocol takes over.

   Patrik

---

From: Matt Larson <[email-masked]>
Date: Fri, 19 Aug 2016 10:00:08 -0400

Patrik,

> On Aug 9, 2016, at 12:06 PM, Patrik Fältström <[email-masked]> wrote:
> 

I read draft-faltstrom-httpbis-dns-01 and have some comments and questions.

There's text in Section 5.4 of RFC7553 that indicates the precedence of URI over SRV for HTTP and I suggest similar text somewhere in the draft to make it clear that SRV is not involved and URI is an alternative to the (hypothetical) use of SRV for HTTP.

I found the text hard to parse because "URI" is overloaded in the context of the draft.  It can refer to (at least) the URI causing the processing, the URI RRset looked up as a result of processing, and the URI in the RDATA of a URI RR.   In particular, I think the URI causing the processing and the URI in the RDATA should be referenced explicitly with different names: how about "input URI" and "target URI", respectively?  The specific names don't matter as long as they're clearly defined.

I think the specific algorithm should be made a bit clearer, in particular noting that multiple iterations could be required and being more explicit about the termination condition. An example would help a lot.

Speaking of examples, is this how it works?

- User types "example.com"

- "http://example.com" is the "input URI"

- Look up _web._http.example.com/URI, result is URI RR with RDATA "http://www.example.com"

- "http://www.example.com" is the "target URI", but becomes the new input URI in the next iteration.

- Look up _web._http.www.example.com/URI, result is URI RR with RDATA "http://example.cloud-o-matic.com"

- "http://example.cloud-o-matic.com" is the target URI, but becomes the new input URI in the next iteration.

- Look up _web._http.example.cloud-o-matic.com/URI, result is NXDOMAIN

- Look up example.cloud-o-matic.com/A and example.cloud-o-matic.com/AAAA, result is A and AAAA RRs

- Connect via HTTP to IPv4/IPv6 per local preference, Happy Eyeballs, etc.

A final question: where do you intend discussion of this draft to happen?  Here in dnsop?

Matt

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Aug 2016 17:04:18 -0700

Folks (including Patrik)...

Hi.

Checking on where group views are, now that some exchanges have happened 
and time has passed...

> of Berlin, I thought I heard that there was (still) deviations.

I believe I saw this resolved as a 'nevermind'.  That is, the believed 
deviations turn out not to be a concern, based on Ray's one posting.  Yes?

>    Service Name and Transport Protocol Port Number Registry

And the draft -attrleaf- needs to point to this, I believe.

> theoretical terms, it guarantees -- collisions.

Patrik's and John 's postings notwithstanding, I'm still concerned about 
the proposed way of handling this, namely to rely on IANA to do a manual 
check of the two registries the URI RR might call on.  First, it does 
not seem reasonable to me to impose that burden on the IANA staff and 
second a manual process like that is almost certain to produce errors.

On 8/3/2016 9:05 PM, John R Levine wrote:
 > I suppose, but since the two registries exist and the URI RFC says to
 > use both of them as _name, that horse has left the barn.

I think it left the theoretical barn, but not the practical one.  We've 
been told that there is not yet any uptake in the URI RR.  That makes it 
plausible to modify its spec to eliminate this problem.

Really, the burden of trying to have on-going coordination for the URI 
RR, between two different registries is worth finding a way to avoid. 
The problem is that I am not sure what to suggest that will work for URI 
usage.

Suggestions?

d/
-- 

   Dave Crocker

---

From: "John Levine" <[email-masked]>
Date: 29 Aug 2016 01:42:00 -0000

So far, so good.

>second a manual process like that is almost certain to produce errors.

Well, either you can persuade Patrik and Olaf to revise RFC 7553 to
add a _enumservice psedudo-transport to disambiguate, or you can't.
When I look at the enumservice registry, I see that it's not very big
and doesn't change very often.

Rather than speculating about how hard this would be for IANA, why
don't you ask them.  Do they have any other groups of registries that
they have to monitor for name collisions?  How much harder is that
than the checking they have to do in a large registry like ports and
services to be sure they don't reuse a name?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Aug 2016 18:58:30 -0700

On 8/28/2016 6:42 PM, John Levine wrote:
>> atrik's and John 's postings notwithstanding, I'm still concerned about

Asking will give us a measure of 'willingness', not a measure of 
'long-term perfection'.  This difference is fundamental.  I'm worried 
about the latter, while I consider the former to be a distraction.

Simply put, specifying a smal task that requires humans to perform 
perfectly at random, very (very) infrequent times, is a plan designed to 
fail.

d/
-- 

   Dave Crocker

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 28 Aug 2016 20:15:04 -0700

On 28 Aug 2016, at 18:58, Dave Crocker wrote:

> perfectly at random, very (very) infrequent times, is a plan designed 
> to fail.

Can't this be checked by scraping IANA on a daily basis? That is, if 
IANA makes a mistake, it will be detected by the next scrape and IANA 
can be told to revert.

--Paul

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Aug 2016 20:26:44 -0700

> IANA makes a mistake, it will be detected by the next scrape and IANA

There are all sorts of theoretical prevention or recovery mechanisms one 
might postulate. The problem is that this is an existing, operational 
environment and one disturbs such on-going efforts at considerable peril.

The bottom line is that this goes beyond the normal working scope of 
those folk and imposing this kind of requirement on them is therefore 
unreasonable, absent someone (else) doing the work to bring the 
requirement down to a level that /is/ reasonable to ask of them.

d/

-- 

   Dave Crocker

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 29 Aug 2016 09:35:04 +0200

> services to be sure they don't reuse a name?

First, when creating the URI RR I felt a registry WAS needed. The mess with SRV could not be accepted.

Secondly, creating the registry while doing URI was just not something I had energy for. It was enough to get IETF accept a new RR Type at all.

Thirdly, the ENUM Registry process requires RFC for the registration of an ENUM Service requires an RFC (see RFC 6117) that have a specific IANA Considerations section.

Forth, as part of the ENUM Service Registration, Expert Review is required.

Conclusion: I think the above can resolve _future_ conflicts.

We do though have a few other issues here:

1. Merge of all sources we have, i.e. what will the initial list of prefixes look like?

2. When adding things to this table, what is really required?

To answer your question: I am perfectly happy to update the spec for URI so that it clearly says that:

A. Primary source for prefixes is this new registry created by Daves document

B. When registering an ENUM Service, according to RFC 6117, this registry created by Dave should also be updated, and how to be updated should be in the RFC that specifies the ENUM Service. The Expert Review is to ensure that is done in a proper way.

I.e. I agree we should and can not have more than one registry for prefixes, and of course we should move all references regarding prefixes to point to this new registry by IANA.

Actions for me, I guess, given consensus:

- Write a new RFC updating 6117 and 7553 so that this new registry is referenced in a correct way. Unless people think such text should go into this RFC that Dave is already writing/creating.

    paf

---

From: "John R Levine" <[email-masked]>
Date: 29 Aug 2016 11:51:17 -0400

> First, when creating the URI RR I felt a registry WAS needed. The mess with SRV could not be accepted.

RFC 6335 cleaned up the SRV mess pretty completely.

> 2. When adding things to this table, what is really required?

For URI, the prefixes are all of the enumservices, plus the four SRV 
protocols _udp _tcp _sctp _dccp.  The umpteen thousand service names only 
appear as sub-names of the four protocols so they don't matter here.

One possibility would be to add four dummy entries to the enumservices 
table to reserve the protocol names, although I think Dave has reasonable 
concerns about how you make sure to add another entry when someone defines 
another service in 2027.

For Dave's registry, I think it's adequate to point to the enumservices 
registry, and do something about the four SRV protocols, perhaps set up a 
registry for those, or have an entry type field in Dave's registry.

I haven't thought too hard about conflicts with names for other stuff, 
such as the TXT records with _domainkeys and _dmarc prefixes.  I think 
they don't matter since the RR types are different, but there could be 
interactions I haven't considered yet.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly