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

From: "John Levine" <[email-masked]>
Date: 3 Aug 2016 22:05:24 -0000

>	https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

>We think the Apps area will have a vested interest in not only the 
>registry, but ensuring all current applications are documented.  We 
>welcome any and all feedback

I still think this is long overdue.  Is anyone else interested?

R's,
John

---

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

On 7/20/2016 1:59 AM, Patrik Fältström wrote:
> On 20 Jul 2016, at 7:57, Tim Wicinski wrote:
>
>> This draft is not just looking at SRV records, but TXT records which document such behavior.
>
> And URI.

URI:

I think I didn't respond to this:  URI showed up after the original 
drafting of the doc, but yes it needs to be included.  However after 
some very basic research it appears that the URI RR does not yet have 
traction.  So the current doc needs to account for its existence but I 
think it does not create additional registry entries, especially since 
it emulates SRV.

Subordindate Table(s):

More significant is the handling of the second-level underscore node 
name for the two-level naming constructs (where the upper-level is a 
protocol string, used by SRV and URI.  Ray had suggested a way to deal 
with this quite a long time ago and I promptly forgot what it was.  When 
the topic renewed during Berlin, I finally gravitated towards a model 
that luckily was along the lines he proposed...

In practical terms, the second-level underscore names need to be 
registered explicitly, although one might think the SRV doc has covered 
this by pointing to a table.  By my reading, that reference is more 
conceptual than a detailed registry reference.

The set of protocol (upper-level) names is small and should be in the 
registry explicitly.  One might argue that the reference to the separate 
protocol table suffices but this is a case that seems better handled by 
the mild redundancy.

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.

If we thought there would be lots of independent uses of the same name, 
but under different upper-level underscore (protocol) names, we'd need 
all the separate, subordinate names.  And indeed, this is what bogged me 
down originally.

But no one, including me, so far thinks this is a realistic need.  So 
finding a way to simplify this down to one table seems eminently reasonable.

Thoughts?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 4 Aug 2016 01:58:40 -0000

>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:50:04 -0700

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

Sorry folks.  I initiated a discussion about the draft on this 
apps-discuss list, when it is supposed to take place on dnsop.

I've forward my mis-posted original 'proposal' note to dnsop, along with 
John's response and my response to John...

So, please do /not/ respond on this thread, on apps-discuss.

Take it to dnsop.

d/

-- 

   Dave Crocker

---

From: Tony Finch <[email-masked]>
Date: Thu, 4 Aug 2016 10:22:07 +0100

John Levine <[email-masked]> wrote:
> SRV records: _udp, _tcp, _sctp, and _dccp.

_tls is commonly used in SIP deployments.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Wight, Portland, Plymouth: West 4 or 5, increasing 6 at times. Rough at first
in Plymouth, otherwise moderate. Showers. Good.

---

From: "John R Levine" <[email-masked]>
Date: 4 Aug 2016 09:36:01 -0400

> _tls is commonly used in SIP deployments.

Huh.  The only place I see _tls in an RFC is as an example in the DIAMETER 
spec in RFC 6733.

I believe you, but once again we have the question about what to do with 
stuff seen in the wild that's not actually defined anywhere.

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

---

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

On 4 Aug 2016, at 0:20, Dave Crocker wrote:

> So finding a way to simplify this down to one table seems eminently reasonable.

I think this is a very good goal, reachable, and NOT succeeding is something we should not decide upon lightly.

   paf

---

From: Ned Freed <[email-masked]>
Date: Thu, 04 Aug 2016 22:23:12 -0700 (PDT)

> I still think this is long overdue.

If anything, this is an understatement.

> Is anyone else interested?

Absolutely.

				Ned

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 5 Aug 2016 11:56:16 +0000

Long long overdue