Subject: [art] draft-ietf-dnsop-attrleaf

From: tjw ietf <[email-masked]>
Date: Tue, 25 Jul 2017 10:56:07 -0400

Application Folks

We in DNSOP have a draft that is formalizing the use of _underscore labels
in DNS, and the creation of a "DNS Global Underscore Scoped Entry
Registry".   We want the application folks to give us some comments, as we
feel we are fairly  close to Working Group Last Call.

The draft is here:

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

and I'll be glad to shepherd feedback toward the author, or bring them here
if it becomes quite contentious.

thanks

tim/suzanne
DNSOP chairs

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2017 05:03:32 -0000

>feel we are fairly  close to Working Group Last Call.

When I last talked to Dave about this, we had a problem with URI records.

They can be named _service._tranport.whatever, just like SRV, but they
can also be named with enumservice (RFC 3761 and 6117) names,
_subtype._type.whatever.  There are about 24 type names in the
enumservice registry, none of which currently collide the transport
names.  To prevent collisions in the future, we need somehow to
cross-reference the port and service name registries so any attempt
to register a name in one checks for an entry in the other.

I asked IANA and as I recall Michelle said they can do that, but Dave
was worried about the long term viability of a special case in the
registration process.

We also noted that the number of URI records in the wild is still
small, so another possibility would be to change RFC 7553 so
enumservice URIs are _subtype._type._enum.whatever, and then reserve
"enum" as a transport name.

R's,
John

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 28 Jul 2017 08:56:25 -0600

The IANA registration policy of  "or are documented by a specification published by another
   standards organization" seems very undefined to me and hard for IANA to execute. Could you give specific advice on what is a standards organization? 

I have seen previous efforts to to this and eventually it comes up looking more or less the same as our usual "specification required".

> On Jul 25, 2017, at 8:56 AM, tjw ietf <[email-masked]> wrote:
> 
> 
> Application Folks
> 
> We in DNSOP have a draft that is formalizing the use of _underscore labels in DNS, and the creation of a "DNS Global Underscore Scoped Entry Registry".   We want the application folks to give us some comments, as we feel we are fairly  close to Working Group Last Call. 
> 
> The draft is here:
> 
> and I'll be glad to shepherd feedback toward the author, or bring them here if it becomes quite contentious.
> 
> thanks
> 
> tim/suzanne
> DNSOP chairs
> 
> 
> 
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art

---

From: Adam Roach <[email-masked]>
Date: Fri, 28 Jul 2017 10:54:42 -0500

[I sent this directly to the document-related personnel a few days ago, 
but I'm re-sending it to the ART list as I think it could benefit from 
additional input from the ART community.]

I have some tiny editorial comments, but I'm leaving them aside for now 
to bring up what appears to be a major structural defect in the document.

The document is pretty clear about its intended scope, containing 
statements like:

> Only the right-most names are registered in the IANA Underscore table

and

> The current definition of a global underscore registry attends only to 
> the "upper-level" names used for these RRs, that is the "_proto" names.

But then the table includes things like "_ldap" and "_certificates". The 
only SRV records for (e.g.) LDAP will look like "_ldap._tcp...", which 
(according to the cited statements) would mean that "_ldap" doesn't get 
an entry in this table: it is not the "upper-level" name, and it is not 
the "right-most" name. It is clearly under "_tcp". On a casual check, 
the vast majority of the SRV records in the table shouldn't be in here 
by the rules I cite above.

So, what I *think* this document probably wants to do is define a 
top-level registry containing things like "_tcp", "_udp", and 
"_domainkey", and then create two additional sub-tables (one for "_tcp" 
and one for "_udp"), which register all the "_service" types that can 
appear under these two "_proto" types (e.g., "_sip", "_certificates", 
"_xmpp-client", "_crls"). You might want to also add a table for 
"_sctp", although it would appear to only have two entries at the moment 
("_diameter" and "_diameters" -- cf RFC6733).

The alternative approach to making the document internally consistent 
would be to remove almost all of the SRV entries presently in Table 1, 
and leave them to fend for themselves (which would make this document a 
kind of weak half-measure).

/a

On 7/25/17 9:56 AM, tjw ietf wrote:
>
> Application Folks
>
> We in DNSOP have a draft that is formalizing the use of _underscore 
> labels in DNS, and the creation of a "DNS Global Underscore Scoped 
> Entry Registry".   We want the application folks to give us some 
> comments, as we feel we are fairly  close to Working Group Last Call.
>
> The draft is here:
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Jul 2017 12:12:53 -0400

Cullen,

IIR, we introduced the concept of a "recognized standards
organization" (note "recognized", which is important) with media
types, deliberately left it vague, and did so for one primary
reason.  At least in the media type case, there were issues of
probably-legitimate registrations in which it was clear that the
IETF had absolutely no expertise as to the substance or subject
matter of such a request.  As an extreme example, if an
international body responsible for chemical names or plant
taxonomy wanted to establish a media type to be consistent with
the terminology rules they were setting, having amateurs (at
best) in the IETF try to second-guess their decisions was a
rather strange idea and probably an unprofessional and insulting
one.  Sadly, experience indicates that we might try, possibly
proving the value of adages such as a little knowledge being a
dangerous thing.  Our (quite explicit) assumption was that the
IESG would need to figure out who was and was not a recognized
SDO.  More on that below.

An important part of the idea is that "recognized SDO" was an
alternative to another, IETF-centric process.   While I don't
think we ever documented it (perhaps deliberately --- I don't
remember), the IESG can always say "no" on the basis that the
IETF is fully qualified to evaluate a particular request or
family of requests and should do so.   At the same time, we
understood and recognized that, if some standards body out there
was well-established and more recognized in it own field and
area of expertise, IETF decisions that were inconsistent with
theirs were likely to be ignored or, worse, lead to inconsistent
and competing standards used by different sub-communities.  All
a matter of tradeoffs.   Whether the IESG can get them right or
not, we don't have any body or mechanism that would be likely to
consistently do much better.

Whether we got the principle and its expression right is another
question -- it is a bit of a subjective notion and the IETF and
IANA should probably have some input into whether the
request/application conforms to whatever we have decided is
needed for a request to be complete.   We also concluded, after
considerable discussion, that what was and was not to be
"recognized" should be left to IESG discretion on a case-by-case
basis rather than descending into the rathole of trying to lay
out criteria and cover even most of the edge cases.   Perhaps
not a perfect solution, but we had the expectation that the IESG
could do, or arrange to have done, a certain amount of due
diligence and make an acceptable (and conservative) decision.
One of the important properties of most identifiers or type
encodings is stability and we were also aware of the potential
for DoS attacks in this area.  We thought it was reasonable to
trust the IESG to distinguish between established bodies that
were likely to be around and ad hoc arrangements and between
legitimate bodies and, e.g., the Fraternal Order of Trolls or
other potentially-hostile parties and even to sort out
situations in which there were multiple claimants to be the
recognized international standards body in some particular area.
It did not appear to us that debating those issues on the IETF
list would be helpful, especially given that possibility of DoS
attacks and the ease with which conversations on the IETF list
in which there is little expertise but many opinions converse on
N/S ratios with near-infinite values.

All of these differs from "specification required" because it is
expected that some authoritative and consensus body take
responsibility for (and be accountable for) the substantive
content of that specification.   If it isn't working that way,
that is a problem with the IESG's implementation of the
principle, not the principle itself.

Whether that principle, and rules derived from it, are
appropriate for a particular case is another issue.  We used it
very recently in RFC 8141 and I don't recall significant
concerns.  I don't have an opinion as to whether it is
appropriate for this particular draft, just that we should not
abandon the concept of recognizing work by other standards
bodies in their area of expertise because of a perception that
it doesn't work.  It has worked in a number of important cases
and continues to do so.

    john

--On Friday, July 28, 2017 08:56 -0600 Cullen Jennings
<[email-masked]> wrote:

> The IANA registration policy of  "or are documented by a
> specification published by another    standards organization"
> seems very undefined to me and hard for IANA to execute. Could
> you give specific advice on what is a standards organization? 
> 
> I have seen previous efforts to to this and eventually it
> comes up looking more or less the same as our usual
> "specification required".

---

From: Adam Roach <[email-masked]>
Date: Fri, 28 Jul 2017 11:18:00 -0500

On 7/28/17 11:12 AM, John C Klensin wrote:
> I don't have an opinion as to whether it is

This would imply that an update to RFC8126 is in order.

/a

---

From: "John Levine" <[email-masked]>
Date: 28 Jul 2017 18:30:00 -0000

In article <[email-masked]> you write:
>"_domainkey", ...

Right, that's part of what this registry is.  The protocol names were casually
mentioned in RFC 2782, and a few more have been added along the way,
but have never been put in a registry other than implicitly in a column
in the service name registry.

I suggested a while ago that the table needs another column to say
what kinds of subnames are allowed if it's names out of another
registry.

> ... and then create two additional sub-tables (one for "_tcp" 
>appear under these two "_proto" types 

Please, no.  That registry has existed for decades and has upward of
10,000 entries.  See RFC 6335 and:

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

I agree that service names that appear in the registry do not belong in attrleaf.

R's,
John

---

From: Adam Roach <[email-masked]>
Date: Fri, 28 Jul 2017 15:37:29 -0500

> I agree that service names that appear in the registry do not belong in attrleaf.

Ah, yes. I'd missed that the intention of RFC2782 was to allow SRV 
records to be instantly usable for all registered services, rather than 
having each service defining specific additional procedures for SRV 
resolution. (For example, RFC3263 defines some specific rules around 
handling priorities across different transports, which goes beyond the 
handling described by RFC2782). On review, your interpretation appears 
to be correct.

In that case, it would appear that the main action here would be to 
clean up the SRV entries in Table 1 -- by my understanding, the way 
RFC2782 is written, the only registered SRV entries in the registry this 
document establishes should consist of some strict subset of 
<https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml>.

/a

---

From: "John R Levine" <[email-masked]>
Date: 29 Jul 2017 10:40:01 -0400

On Fri, 28 Jul 2017, Adam Roach wrote:
> In that case, it would appear that the main action here would be to clean up 
> the SRV entries in Table 1 -- by my understanding, the way RFC2782 is 
> written, the only registered SRV entries in the registry this document 
> establishes should consist of some strict subset of 

Right, the protocols that appear in the proto column of the services 
table, but none of the services.  This should make the draft considerably 
shorter.

There's still the URI enumservice issue.

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

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 Jul 2017 14:07:45 +1000

> <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml>.

SRV records are ONLY to be use for protocols that specify that they
be looked up.  There are generic proceedures for how to select a
server given that SRV records are permitted in the first place.

RFC2782

Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.

This was written this way so that existing protocols like SMTP, DNS, and
HTTP didn't just suddenly sprout SRV "support".

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 31 Jul 2017 20:15:36 -0400

> server given that SRV records are permitted in the first place.

Sorry, but I don't see what your point is.

I think that Adam and I agree that none of the services in the 
port/service registry should be listed here, and only the transports that 
are used for registered services.

We are not saying anything about what services use SRV.

Regards,