[art] draft-ietf-dnsop-attrleaf

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[art] draft-ietf-dnsop-attrleaf

Tim Wicinski

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
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Levine
In article <[hidden email]> you write:
>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.

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

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Cullen Jennings-2
In reply to this post by Tim Wicinski

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 <[hidden email]> 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:
>
> 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
>
>
>
> _______________________________________________
> art mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/art

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Adam Roach-3
In reply to this post by Tim Wicinski
[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:


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
[hidden email]
https://www.ietf.org/mailman/listinfo/art



_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John C Klensin
In reply to this post by Cullen Jennings-2
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
<[hidden email]> 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".




_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Adam Roach-3
On 7/28/17 11:12 AM, John C Klensin wrote:
> 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.


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

/a

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Levine
In reply to this post by Adam Roach-3
In article <[hidden email]> you write:
>So, what I *think* this document probably wants to do is define a
>top-level registry containing things like "_tcp", "_udp", and
>"_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"
>and one for "_udp"), which register all the "_service" types that can
>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

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Adam Roach-3
On 7/28/17 1:30 PM, John Levine wrote:
... 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 
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.


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


_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Levine
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
> <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml>.

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, [hidden email], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mark Andrews-4
In reply to this post by Adam Roach-3

In message <[hidden email]>, Adam Roach writes:

>
> On 7/28/17 1:30 PM, John Levine wrote:
> >> ... 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
> > 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-numb
> ers.xhtml
> >
> > 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

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: [hidden email]

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Levine
On Mon, 31 Jul 2017, Mark Andrews wrote:
> 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.

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,
John Levine, [hidden email], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dave Crocker-2
In reply to this post by Adam Roach-3
On 7/28/2017 8:54 AM, Adam Roach wrote:

> 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




Howdy.

(Posting this on ART, since that's got the active thread on attrleaf,
for the moment.)

Thanks for the thoughtful comments on the draft.

I've been mulling over the challenges of this registration topic for
more than a decade, constantly being hoisted on the petard of
established practice...

First, underscores can be used for multiple levels of node name.  Trying
to deal with that fully, in a single spec produced an especially
confused draft, roughly 10 years ago.  More recently it became clear
that this is best handled by the described simplification the spec now
declares -- essentially distinguishing between 'top-level' underscore
names and separately deal with those below.  But, as you note, this is
not fully or adequately implemented in the latest versions of the draft.
  But I'll leave details about further fixes for that, for the moment,
because...

Second, and much worse, is that the original documentation of underscore
use created an inherently-problematic arrangement:  Attempting to
synthesize some of the registration by incorporating entries in
independent registration tables documented in SRV and URI
specifications.  The semantics therefore would mean there would be more
than one 'authority' for name registration.  This is a registration
model designed to produce collisions.

Efforts have been to retrofit an administrative model that accommodated
this, where the idea of real-time conflict detection and resolution --
by infinitely diligent and perfectly perceptive -- IANA staff is one of
the more recent suggestions.  Unfortunately, there is an essential and
practical difference between 'excellent' and 'perfect', where the latter
is an inappropriate goal for human performance.

I've come to the conclusion that "accommodating" the established
registration practices is a fundamentally wrong path.  The only way to
solve a problem of multiple registration authorities is to create a
single registration authority.

That is, the right path is to create a simple and obvious registration
model, and, separately, go back and fix the problematic documents.

Therefore I propose to:

    1. Have this document define the simple, sole, authoritative
mechanism for registering "top-level" (global scope) underscore names.

    2. Create a separate document that specifies modifications to the
SRV and URI documents, rationalizing the use of underscore names,
through the mechanism defined in -attrleaf-.


Thoughts?


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Levine
In article <[hidden email]> you write:
>    2. Create a separate document that specifies modifications to the
>SRV and URI documents, rationalizing the use of underscore names,
>through the mechanism defined in -attrleaf-.

It seems a bit late to change SRV.  Or would you only adjust the
documentation to match observed reality?

For URI, it points at other RFCs to get the protocol/service and
enumservice names.  Are you proposing to change URI to add an
extra level of name, or do you want to reach through and change
the enumservice RFCs too?

R's,
John

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dave Crocker-3
On 8/2/2017 5:35 PM, John Levine wrote:
> In article <[hidden email]> you write:
>>     2. Create a separate document that specifies modifications to the
>> SRV and URI documents, rationalizing the use of underscore names,
>> through the mechanism defined in -attrleaf-.
>
> It seems a bit late to change SRV.  Or would you only adjust the
> documentation to match observed reality?

The latter.  The change is to the registration process, not to SRV, per
se.  That is, take a snapshot of the existing SRV underscore usage and
re-specify it in terms of an underscore registry, rather than in terms
of an inheritance from another registry.


> For URI, it points at other RFCs to get the protocol/service and
> enumservice names.  Are you proposing to change URI to add an
> extra level of name, or do you want to reach through and change
> the enumservice RFCs too?

Same approach as for SRV.  Shift to use the underscore registry.  My
understanding is that URI has little adoption, so even if the result is
some usage changes, that might not be intolerable.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Levine
On Wed, 2 Aug 2017, Dave Crocker wrote:
> Same approach as for SRV.  Shift to use the underscore registry.  My
> understanding is that URI has little adoption, so even if the result is some
> usage changes, that might not be intolerable.

It is my impression that you can count the number of prtocols used in SRV
records on the fingers of one hand, and the number of enumservice types
that people actually use on the fingers of the other, so that's probably
workable.

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

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Adam Roach-3
In reply to this post by Dave Crocker-3
On 8/2/17 7:42 PM, Dave Crocker wrote:
On 8/2/2017 5:35 PM, John Levine wrote:
In article [hidden email] you write:
    2. Create a separate document that specifies modifications to the
SRV and URI documents, rationalizing the use of underscore names,
through the mechanism defined in -attrleaf-.

It seems a bit late to change SRV.  Or would you only adjust the
documentation to match observed reality?

The latter.  The change is to the registration process, not to SRV, per se.  That is, take a snapshot of the existing SRV underscore usage and re-specify it in terms of an underscore registry, rather than in terms of an inheritance from another registry.

That would appear to call for a slightly more narrow scope than the current document, which claims to be registering underscore usage for SRV, TXT, and URI RRs as well as (and I don't quite get this) NAPTR RRs. The reason I don't get the NAPTR treatment is: my understanding of NAPTR records doesn't include any kind of underscore-prefixed name components at all. My knowledge of NAPTR is mostly informed by SIP's usage of NAPTR; but I'm pretty sure that, in a generic sense, the overall procedure here is to feed in an underscore-free name in as your query, and to get back a giant slew of records that indicate various available services in their respective "Service" fields, along with a string transform that should be applied to the original name, the result of which is then fed back into another query for the service of interest.

I have to concede that the situation around registration of NAPTR Service values has always baffled me, and section 9 of RFC 3403 makes essentially no sense as far as I can tell. SIP solved this problem in its little corner of the NAPTR world with the registry at <https://www.iana.org/assignments/sip-table/sip-table.xhtml>. I have no idea how other protocols are supposed to deal with this situation; or, indeed, how one might hope to avoid collisions if the "MPLS-TP Shared Ring Protection" mechanism and the "Message Session Relay Protocol" both decided to use a NAPTR Service value of "MSRP+D2T".

Practically, for this document, I would recommend having a unified table for SRV and URI records, initially containing:
  1. _tcp
  2. _udp
  3. _sctp (implict in rfc6733)

There's also the odd matter of _LDAP, _HTTP, and _OCSP, used by RFC4386 in what I presume was a misunderstanding of what was meant by "Proto" in SRV's definition of that term -- I would think we want to put these in the table but mark them experimental and/or deprecated. In fact, I think we would want to stipulate that new entries in this registry cannot contain any value other than those registered at <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>.


I would recommend documenting and registering the underscore leaf nodes used by TXT records as a completely separate concern and in a different IANA table (although still as part of this document), as they mean something rather different than what's defined for SRV and URI. I believe the initial tables looks something like this at the moment (although I may have overlooked one or two):

  1. _domainkey
  2. _dmarc (rfc7489)
  3. _spf
  4. _vouch
  5. _tcp (implicit in rfc6764, rfc7808)


If you want to fix the NAPTR Service registry issue I highlight above, I would recommend doing this in a different document. It feels like a rather different problem, and the presence of the SIP registry (which would need to be subsumed into any complete registry) would seem to make it much more complicated to deal with.

/a


_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Levine
On Wed, 9 Aug 2017, Adam Roach wrote:
> That would appear to call for a slightly more narrow scope than the current
> document, which claims to be registering underscore usage for SRV, TXT, and
> URI RRs as well as (and I don't quite get this) NAPTR RRs. ...

See rfc3588 which has some _sctp names for NAPTR records.

> I would recommend documenting and registering the underscore leaf nodes used
> by TXT records as a completely separate concern and in a different IANA table

That would rather defeat the purpose here, since the goal is to identify
and ideally prevent name collisions.  Or are you saying that names for TXT
and for SRV or URI are separate namespaces?

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

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mark Andrews-4

In message <[hidden email]>, "John R Levine" writes:

> On Wed, 9 Aug 2017, Adam Roach wrote:
> > That would appear to call for a slightly more narrow scope than the current
> > document, which claims to be registering underscore usage for SRV, TXT, and
> > URI RRs as well as (and I don't quite get this) NAPTR RRs. ...
>
> See rfc3588 which has some _sctp names for NAPTR records.
>
> > I would recommend documenting and registering the underscore leaf nodes used
> > by TXT records as a completely separate concern and in a different IANA table
>
> That would rather defeat the purpose here, since the goal is to identify
> and ideally prevent name collisions.  Or are you saying that names for TXT
> and for SRV or URI are separate namespaces?

Unless you have non-overlapping syntax rules they can't be seperate
namespaces.  As long as they both have a single prefix underscore
they are both in the same namespace.

> Regards,
> John Levine, [hidden email], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> art mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/art
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [hidden email]

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Levine
On Thu, 10 Aug 2017, Mark Andrews wrote:
>> That would rather defeat the purpose here, since the goal is to identify
>> and ideally prevent name collisions.  Or are you saying that names for TXT
>> and for SRV or URI are separate namespaces?
>
> Unless you have non-overlapping syntax rules they can't be seperate
> namespaces.  As long as they both have a single prefix underscore
> they are both in the same namespace.

That's what I thought, too.

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

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dave Crocker-2
In reply to this post by Adam Roach-3
On 8/9/2017 4:25 PM, Adam Roach wrote:
> I would recommend documenting and registering the underscore leaf nodes
> used by TXT records as a completely separate concern and in a different
> IANA table


Adam,

(Leaving for later, all other comments about the note, other than to say
thanks for reading the draft, thinking about it, and commenting...)

Your above seems to be calling for two registries that assign out of the
same namespace.  (Being specified in the same document doesn't matter if
there are two tables.)

I'm hoping I've seriously misunderstood, since the entire goal of my
simplification proposal is to avoid exactly that.

Please to set me right.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
12
Loading...