Subject: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery?

From: Nathaniel McCallum <[email-masked]>
Date: Tue, 17 May 2016 11:49:23 -0400

https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery
-02

I'd like to propose adoption of this draft:

1. It is in the scope of the WG. This is an extension to the discovery
methods already defined in RFC 4120.

2. It is beneficial. It provides both speed improvments and additional
functionality (discovery of MS-KKDCP proxies).

3. It is small. It avoids defining new: DNS names, DNS semantics, URIs,
or transport semantics. It simply combines the existing tools in a
fairly obvious way.

Thoughts?

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 17 May 2016 12:25:10 -0400

> or transport semantics. It simply combines the existing tools in a

Having read the draft I am totally unclear how it is implemented.

  _kerberos.REALM

is not a valid DNS URI record name.  To translate the URI

  https://host[:port][path]

to an URI record requires

 _kerberos._https.host

not

 _kerberos.host

DNS URI records according to RFC 7553 work just like DNS SRV records in
that they require both a service name and a protocol name.  Switching to
URI records does not solve the problem of multiple DNS queries.

To find a KDC that supports https, use the DNS SRV record

  _kerberos._https.REALM

registering additional service types such as "kpasswd" can be done but
the fact is implementations such as Heimdal already perform SRV lookups for

 _kpasswd,_tcp.REALM and _kpasswd._udp.REALM

Can you make a case for something that DNS URI records provides that DNS
SRV records do not?

The introduction of DNS URI records will only mean that in practice that
Kerberos client libraries will need to issue the DNS URI queries in
addition to the existing DNS SRV records.

Jeffrey Altman

---

From: Rick van Rein <[email-masked]>
Date: Tue, 17 May 2016 22:26:22 +0200

Hi,

I agree mostly with Jeffrey, but have some additional remarks / thoughts.

> is not a valid DNS URI record name. To translate the URI
Yes, the RFC wants it to be of the form _server._transport, however

> to an URI record requires

where is _https defined as a transport?  RFC 7553 gives examples with
_http._tcp -- I've always wondered to deal with _https and especially
how to add semantics on top of it, so I certainly like the scheme, but
is this format defined anywhere?  For SRV, I though transports were
limited to TCP, UDP, SCTP -- so not even TLS, let alone HTTPS?

Nathaniel, I think what you are actually trying to do is to describe
HTTPS as a tunneling technique, right?  Since this type of tunnel is
designed to participate in the rope-pulling contest between application
desires and (perhaps misguided) firewall configurations, it might be
expected that new tunnels would be topped on as time passes.  Clients
would need to keep up, but keep the older solutions working as well.  So
instead, I would rather have some sort of a redirection to a somewhat
general tunnel descriptor as a general discovery outcome when looking
for a "direct" service description.  This would service many
applications in the same manner.

> Can you make a case for something that DNS URI records provides that DNS
It should outweigh having to do both forever and ever, indeed.  And
needing to add even more when other tunneling techniques arrive.

I hope this helps!

Cheers,
 -Rick

---

From: Nathaniel McCallum <[email-masked]>
Date: Tue, 17 May 2016 16:43:21 -0400

> to an URI record requires

It doesn't actually require this. It just gives examples.

> To find a KDC that supports https, use the DNS SRV record

_https isn't a thing. You'd have to do something like: _http._tls._tcp.

>  _kpasswd,_tcp.REALM and _kpasswd._udp.REALM

At the cost of one DNS query per transport. Further, administrators
have no control over the weights or priorties between transports. My
draft provides this.

> Can you make a case for something that DNS URI records provides that

Yes. MS-KKDCP requires a path. SRV records cannot provide a path.

> addition to the existing DNS SRV records.

We will need to add at least one more DNS query to support MS-KKDCP
(two if we have to treat http and https as separate queries). This is
unavoidable. While it is true that this will result in a 50% increase
in DNS queries, using my URI scheme means that a simple administrator
configuration can turn this 50% increase into a 50% decrease in queries
over the existing implementations. This is a win.

---

From: Nathaniel McCallum <[email-masked]>
Date: Tue, 17 May 2016 16:53:19 -0400

On Tue, 2016-05-17 at 22:26 +0200, Rick van Rein wrote:
> expected that new tunnels would be topped on as time passes.

Yes, this is possible: new tunnels may appear over time.

> Clients

How does the "general tunnel descriptor" help in the case of Kerberos
tunnelling where the tunnel protocols are Kerberos-specific?

The desire for abstraction here just adds complexity without any
benefit of reusability. OTOH, new Kerberos tunnelling protocols can
just get new URIs. In fact, this is already explicitly allowable in the
existing draft. So the system, as defined is perfectly flexible to new
situations in the future.

One advantage to the URI approach is that weights and priorities can be
used to appropriately transition between transports; something that is
not currently possible.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 17 May 2016 17:08:32 -0400

> over the existing implementations. This is a win.

As an implementer I can tell you that it would be more than a decade
before I would ever be able to remove existing lookup methods and
possibly even longer than that.

As a deployer of a realm I can tell you that I have no control over
updates of Kerberos libraries in the clients.  Clients are deployed long
after the 10 year lifetimes of the operating systems and new features
such as this are not backported into prior OS distributions.
As such I would be unable to rely upon URI as a replacement for SRV for
more than 10 years.  I would be required to publish both URI and and SRV
lookup records forever.

You have described a reason why URI lookups are necessary for MS-KKDCP.
Please restrict your draft to that case.

Sincerely,

Jeffrey Altman

---

From: Nathaniel McCallum <[email-masked]>
Date: Tue, 17 May 2016 17:26:00 -0400

> possibly even longer than that.

I'm also an implementer. And I can tell you that when you remove the
code doesn't matter. All that matters is what happens at runtime. And
if we offer admins a way to cut their Kerberos DNS requests in half,
they'll take it.

> more than 10 years.  I would be required to publish both URI and and

Agreed. But who cares? Clients that support the new method get
increased speed and functionality. Clients that don't, get the same
behavior they always had. The only cost for this on the DNS-side of the
equasion is an additional record -- one which we need anyway.

> Please restrict your draft to that case.

I've described a reason why a URI record lookup is requied for MS-
KKDCP. However, I've also described a system which presents a 50%
reduction in DNS lookups. I don't see any reason to neglect this second
feature.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 17 May 2016 20:36:04 -0400

> reduction in DNS lookups. I don't see any reason to neglect this second

And when the DNS URI record is not published or cannot be queried the
Kerberos library will have a 50% increase in the number of DNS lookups.
Not only does the library have to query for DNS URI but it still must
query for the DNS SRV records.

I will also point out that a large number of the DNS hosting providers
do not support URI records and many of the DNS proxy servers do not
support them either.   As a result there is no ability for DNS URI
records to be published and the queries are will be blocked.

Sincerely,

Jeffrey Altman

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 May 2016 01:10:06 -0400 (EDT)

> I'd like to propose adoption of this draft:

The chairs are tracking this document and expect it to eventually become a
working group document.  However, as I implied in our previous discussion
(off-list), there are a lot of existing WG documents that are not moving
very fast, and it seems unhealthy to keep a lot of documents around in
such a state.  It would be better to finish off (or formally abandon) some
existing documents before we start trying to take on new work.

I also noted that "adding [Kerberos] bits to the DNS always seems harder
than one expects", which seems borne out by the discussion triggered by
your message.

-Ben

P.S. If someone wanted to help clear out the pile of existing WG
documents, draft-ietf-kitten-gssapi-extensions-iana,
draft-ietf-kitten-rfc5653bis, or draft-ietf-kitten-krb-auth-indicator
would be fine places to start.

---

From: tom p. <[email-masked]>
Date: Wed, 18 May 2016 09:26:53 +0100

----- Original Message -----
From: "Benjamin Kaduk" <[email-masked]>
To: "Nathaniel McCallum" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 18, 2016 6:10 AM
> would be fine places to start.

P.P.S.

Perhaps you should operate a one-in one-out policy.  If an author has an
I-D gathering dust in the expired pile, then they should resolve that -
advance it, bin it - before an adoption call is made for another I-D by
them  Authors with a track record of producing RFC might be given a
bigger pile of tokens for their leaky bucket.

Just a thought.

Tom Petch

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 18 May 2016 12:34:47 -0400

> query for the DNS SRV records.

This is, indeed, the trade-off to a longer-term improvement. As I said
before, the property that makes this trade-off acceptable (IMHO) is
that the DNS administrator can solve this problem. This performance
trade-off creates an incentive for administrators to move to the new
system.

I'm very open to alternative designs. But we've been having this
conversation for more than a year now and, while lots of alternatives
have been proposed, all of them were abandoned by their proposers after
due consideration.

Here is a basic summary of the ideas proposed (please remind me if I've missed any):

1. A new, Kerberos-specific RR type.
2. (Ab)using TXT; same semantics as the current draft.
3. (Ab)using TXT; same semantics as RFC4120 - KKDCP only.
4. Using SRV with a default path.

#1 was dismissed as generally having the effect of ghettoizing the discovery mechanism. Servers wouldn't implement it. Neither would administrative interfaces. It also has all the same drawbacks as the current draft.

#2 is the exact same proposal as the existing draft, just using TXT records. Its main advantage over the current draft is that we don't need to depend on the URI record type. However, using the TXT record like this is controversial (to say the least).

#3 is the simplist solution: just define a TXT record for KKDCP only. This record would work in parallel to the existing SRV records and would only indicate the location of the KKDCP proxy. The downside is that this adds an additional query just for KKDCP. Future tunnels may add more queries. Also, it doesn't allow for weights/priorities between protocols.

#4 proposes to define an SRV record for KKDCP. This would carry the understanding that the default path (/KdcProxy) would always be used. This is basically a hack and is extremely inflexible. It would mean, in many cases, that the KKDCP proxy couldn't be integrated directly into existing infrastructure.

Notice that in all of the options we require an additional DNS query.
This is unavoidable.

#3 and #4 do not provide any opportunity for speedup. This means that
KKDCP users will have to wait for two DNS timeouts in order to get
connectivity. I find this property unacceptable. #1 and #2 have the
potential for speedups, with exactly the same semantics as the current
draft. But they each have significant drawbacks as well.

The current draft seems to me the best balance of all the options.

1. It uses a standard RR type. While the use of URI may be somewhat
controversial, it seems to me less problematic than either of the
alternatives (a custom RR type or TXT).

2. It does add an additional DNS query; but this can be avoided if DNS
configuration is updated. This is the best case scenario considering an
extra query will be required in all options.

3. It provides the ability to use weights/priorities between protocols.

> records to be published and the queries are will be blocked.

On the MIT krb5 call this week, I argued this very point against #1
(above). What I argued is that it will be easier to get hosting
providers to add support for URI than for some Kerberos-specific type.
If hosting providers were the only consideration, then TXT would be a
no-brainer here. However, there are also standardization
considerations. If the general consensus is that standardizing on TXT
won't present any difficulty, I would be more than happy to switch to
this option.

If you have any alternative, more creative, solutions, I'm all ears.
If, after this explanation, you agree that our solution is the best
balance of all the concerns, I am also open to suggestions for
improvements in the implementation.

It is my hope that we can agree upon the contours of the problem and
devise a solution that is acceptable to everyone.

Nathaniel

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 18 May 2016 12:59:36 -0400

> existing documents before we start trying to take on new work.

Understandable. However, a timeline would also be helpful. This draft
is already more than a year old and has only seen minor changes.

> than one expects", which seems borne out by the discussion triggered

Well, I take this discussion as just a rehash of the conversations that
happened last year; just with new interlocutors. None of the input
variables have changed and we are, I think, ending up with exactly the
same conclusions.

> would be fine places to start.

I have requested WGLC for draft-ietf-kitten-krb-auth-indicator.

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 18 May 2016 13:02:20 -0400

On Wed, 2016-05-18 at 09:26 +0100, tom p. wrote:
> > such a state.  It would be better to finish off (or formally
> > abandon)
> some
> > than one expects", which seems borne out by the discussion
> > triggered
> by
> > your message.
> > 
> > -Ben
> > 

I'm fine with this so long as the author gets to choose the priority.
For instance, I have three drafts. Two of them are small (auth-ind,
service-discovery) and one of them is large (spake-preauth). This order
is also my priority. However, I'd hate to have spake-preauth be pulled
in first and have it block the smaller drafts for years.

Nathaniel

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 May 2016 11:10:06 -0500

> is not a valid DNS URI record name.  To translate the URI

RFC7553 is Informational.  Clearly it's the most authoritative when
describing the URI RR type's RDATA and their semantics.  But as for the
RRset names, I think it's mistaken, and anyways, it's Informational
(though it once aimed for Proposed Standard; we might want to find out
why it ended up being Informational).

> [...]

Problems with this:

a) if we're going to be pedantic, _https is not the sort of protocol
   intended to go there (protocols running over IP are, so _tcp, _udp,
   _sctp, ...);

b) plus we have *two* HTTP-based protocols, so how would we indicate
   which protocol to use?

c) every additional transport for the KDC exchanges adds a (serial, as
   implemented) DNS lookup for the clients -- this is a performance
   disaster.

(c) is fatal.  We really need _kerberos.<REALM's domainname>. as the
QName and, therefore, the RRset name.  One question, one answer set.

And if we're going to use URI, then we'll need a 'krbtgt' URI scheme by
which to express the four protocols we have (raw over TCP, raw over UDP,
HTTP MSFT-style, and HTTP Heimdal-style:

  krbtgt:<host>[:<port>]#proto=tcp
  krbtgt:<host>[:<port>]#proto=udp
  krbtgt:http[s]://<host>[:port][/path]#style=POST
  krbtgt:http[s]://<host>[:port][/path]#style=GET

Or any variant of that that you might like, such as:

  krbtgttcp:<host>[:<port>]
  krbtgtudp:<host>[:<port>]
  krbtgtpost:http[s]://<host>[:port][/path]
  krbtgtget:http[s]://<host>[:port][/path]

> Can you make a case for something that DNS URI records provides that DNS

Yes.  See above.

> addition to the existing DNS SRV records.

Yes, but they should try URI queries first so as to create an incentive
to publish those (because that will be faster, because it will be just
one query instead of three or four).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 May 2016 11:25:46 -0500

> or transport semantics. It simply combines the existing tools in a

 - If we use the URI RR type (and maybe even if we don't), we'll need a
   krbtgt URI scheme, as we have four different options to express,
   including two over HTTP: raw over TCP, raw over UDP, HTTP w/ POST,
   HTTP w/ GET.

 - We should find out why RFC7553 ended up being Informational.  There
   may be some important lessons in that.

 - Perhaps we should have our own RR type.  In principle it's easy to
   add them, but:

 - You've mentioned that many DNS hosters don't have UIs or support for
   URI RRs.  This needs more research.  If adding support for new RR
   types is impossible because of this, then the DNS community at the
   IETF should be asked to address this, and we might need to use TXT
   RRs instead.

   Using TXT RRs is frowned upon, and we'd never get an RFC on the
   Standards track using them today, but if the DNS community confirms
   that adding new RR types is much harder than previously thought, then
   TXT RRs will have to become the DNS extension mechanism to use
   instead of new RR types.

   Ideally we could get the DNS hosters to support arbitrary RR types.
   Yes, there is also a UI issue (see below), but it's manageable.

 - If new RR types are the answer, then the DNS community needs to do
   something about UIs.  For example, there could be an XML schema
   defining RR types' RDATA contents and UI elements.  Then implementors
   could automatically translate those to code to implement UIs for new
   RR types.

 - Can you research whether the DNS community at the IETF has addressed
   these issues before?

   If they have not, then we'll have to bring this up to them.

   If they have, what was the outcome?  Have conditions in the market
   changed?  Should the IETF review these issues again?

 - Can you ask some DNS hosters to inveigh as to whether they would be
   willing to add arbitrary new RR types?  (Presumably with a UI that
   requires the user to paste base64-/hex-encoded RDATA.)

   I think this research will be very valuable in reviewing this
   document, and perhaps using alternative designs (e.g., defining a new
   RR type, or using TXT, or updating RFC7553 and perhaps promoting it
   to Proposed Standard).

 - You might want to seek several ADs' input on this early.  The DNS
   issues here seem very real, and dealing with them may require help
   from the ADs.  The WG chairs might help with this.

Nico
--

---

From: Nathaniel McCallum <[email-masked]>
Date: Thu, 19 May 2016 12:28:13 -0400

> why it ended up being Informational).

I have already inquired. I was informed that the change was made simply
for the reason that all DNS RR type definitions are informational. To
avoid a downreference, I was advised to reference IANA instead of the
RFC:
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

>   krbtgtget:http[s]://<host>[:port][/path]

One reason to avoid "krbtgt" is that we are actually defining transport
mechanisms for multiple protocols: kerberos and kpasswd, at a minimum.
I suspect implementors will extract this to additional protocols.

But in general, I don't care what the actual URIs look like.

As you may have hinted, it may be worth considering implementing a URI
for Heimdal's proxy. I left it off the current draft since there is no
protocol definition; just some code.

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 May 2016 11:45:40 -0500

On Thu, May 19, 2016 at 12:28:13PM -0400, Nathaniel McCallum wrote:
> > (though it once aimed for Proposed Standard; we might want to find
> > out why it ended up being Informational).
> 

Thanks.

> > And if we're going to use URI, then we'll need a 'krbtgt' URI scheme
> > by which to express the four protocols we have (raw over TCP, raw
> > over UDP, HTTP MSFT-style, and HTTP Heimdal-style:
> 

On the contrary, that's all the more reason to want URI schemes for
Kerberos: we can then add additional URI schemes for the related
protocols (kpasswd, kadmin Heimdal flavor, kadmin MIT flavor, kadmin
Solaris flavor, admin via LDAP, and whatever else comes up).

> But in general, I don't care what the actual URIs look like.

Me either, as long as they can express the options we have to be able to
express.

> protocol definition; just some code.

Sure, but we can document it if need be.  The point is that we have more
than just three options to express, and if you include kpasswd and such,
we have more than four.  It's critical to be able to get at least the
KDCs with one DNS question (perhaps using EDNS0 or falling back on DNS
over TCP if the answers don't fit in a DNS UDP response).

Nico
--

---

From: Nathaniel McCallum <[email-masked]>
Date: Thu, 19 May 2016 12:47:17 -0400

>    including two over HTTP: raw over TCP, raw over UDP, HTTP w/ POST,

Agreed to a URI scheme.

However, HTTP w/ GET is undefined and only exists in one codebase. It
also has some real idempotency and space limitation drawbacks.

In contrast, MS-KKDCP (HTTP w/ POST) has a protocol definition and is
implemented by multiple vendors without the above drawbacks.

>    may be some important lessons in that.

The authors of RFC 7553 told me that informational should be considered
normal for RR type definitions. The authoritative record is IANA and
should be referenced instead of the informational RFC.

>    changed?  Should the IETF review these issues again?

Yes. I'm working on this now. However, I'm less sure that UX designers
will be keen to back a "generic record" interface. I do think it will
be possible to get buy-in for URI records.

>    RR type, or using TXT, or updating RFC7553 and perhaps promoting

I plan to ask some of the providers I know.

>    from the ADs.  The WG chairs might help with this.

+1

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 May 2016 11:59:14 -0500

> also has some real idempotency and space limitation drawbacks.

Idempotency is not an issue (the KDC exchanges are idempotent, with the
sole exception of account lockout on N incorrect passwords, which is and
always has been a very bad idea and which will not be relevant in any
way once we have PAKE), but the URI size limitations are real.

But this is a distraction.  The point is that we have enough options to
express, and that's why we need a URI scheme.

> > - Can you research whether the DNS community at the IETF has
> >   addressed these issues before?
> > 

That seems probable, yes.

> > - Can you ask some DNS hosters to inveigh as to whether they would
> >   be willing to add arbitrary new RR types?  (Presumably with a UI
> >   that requires the user to paste base64-/hex-encoded RDATA.)
> > 
> >   document, and perhaps using alternative designs (e.g., defining a
> >   new RR type, or using TXT, or updating RFC7553 and perhaps
> >   promoting it to Proposed Standard).
> 

Thanks,

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 May 2016 12:36:43 -0500

> Kerberos library will have a 50% increase in the number of DNS lookups.

That's a feature: the feature that will drive adoption :)

Of course, some clients might have an option to not do this, but still,
if you want fast, zero-conf discovery, you'll want to publish the URI
RRs.

Nico
--

---

From: Petr Spacek <[email-masked]>
Date: Fri, 20 May 2016 09:26:42 +0200

>>  - Perhaps we should have our own RR type.  In principle it's easy to

Any new RR type will be in worse position than URI because of reasons you
stated below.

>>    could automatically translate those to code to implement UIs for

Oh yes, this is my plan for some time already but it always gets lower
priority than something else ... I would not wait for it :-)

More importantly, there was literally no usage & demand for the URI record up
to now. Adding new RR types to UI is trivial as soon as you have justification
for the management, so the demand could simply solve the UI problem for the
URI RR type.

>> be

We have a standard for Handling of Unknown DNS RR Types:
https://tools.ietf.org/html/rfc3597

It says that RDATA for unknown types should be typed in using hexadecimal
notation:
https://tools.ietf.org/html/rfc3597#section-5

Also, some servers/services simply lack UI (e.g. Windows Server 2003) but
allow adding the record using standard DNS UPDATE protocol RFC 2136, which is
also behavior mandated by RFC 3597.

Petr Spacek  @  Red Hat

>> new

---

From: Petr Spacek <[email-masked]>
Date: Fri, 20 May 2016 09:37:36 +0200

> It doesn't actually require this. It just gives examples.

More importantly, SRV records did not have any way to specify protocol so
_proto label was only way to convey the information.

In contrary, URI can convey information about protocol/scheme and thus
artificial requirement for _proto label does not make sense.

Also, RFC 2782's Applicability Statement clearly states that SRV records
should be used only for applications which have own RFC describing its semantics.

Considering URI vs. SRV properties mentioned above and the requirement for
separate RFC, I think that Nathaniel's usage of URI records is justified and
legal.

Petr^2 Spacek

---

From: Nico Williams <[email-masked]>
Date: Fri, 20 May 2016 10:06:31 -0500

> Any new RR type will be in worse position than URI because of reasons you

Exactly.

> >>    defining RR types' RDATA contents and UI elements.  Then
> >>    implementors could automatically translate those to code to
> >>    implement UIs for new RR types.
> 

Er, OK, how do we help you implement it?  :)

> More importantly, there was literally no usage & demand for the URI
> record up to now. Adding new RR types to UI is trivial as soon as you
> have justification for the management, so the demand could simply
> solve the UI problem for the URI RR type.

Well, I hope so!  The UI for URI is going to be very similar to the UI
for SRV.

A machine-readable description of what the UI should be for each RR type
would have made this problem a non-problem, and might yet.

Thanks.

> Also, some servers/services simply lack UI (e.g. Windows Server 2003)
> but allow adding the record using standard DNS UPDATE protocol RFC
> 2136, which is also behavior mandated by RFC 3597.

That's nice, but the services that Nathaniel is concerned about probably
don't support DNS UPDATEs.

That's another thing.  Implementations that support DNS UPDATE often
don't have useful authorization models, leading enterprises often to
having to write proxies [that invariably do not themselves speak DNS
UPDATE].  I'm not sure that a standard can help there, but I think it
might.  One idea would be to associate authorization attributes to each
RR type and RRset name pattern so that the DNS server could evaluate the
DNS UPDATE client's authorization to perform a given operation.  E.g.,
the owner(s) of a given domainname (should ownership and/or ACLs be
expressible within DNS?) might get to manage associated SRV RRsets, and
maybe (subject to site-local policy) add/delete CNAMEs pointing to that
name, but maybe not modify the A/AAAA RRsets -- the "associated" bit
would be nice if it were expressed in a standard, while which operations
are allowed should be locally expressible based on simple labels for
each association, say.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 20 May 2016 10:14:02 -0500

> > It doesn't actually require this. It just gives examples.

It doesn't have any normative language about it, so I agree.  But
worryingly, section 4.1 says that "[t]he URI owner name is subject to
special conventions."  I wouldn't want to be told late in the game that
this made this section normative!  (It can't, since normative language
is used elsewhere, its non-use here seems clearly definitive to me.)

> artificial requirement for _proto label does not make sense.

Yes, this should seem obvious to all.  So why did section 4 even mention
protocols??

> Also, RFC 2782's Applicability Statement clearly states that SRV
> records should be used only for applications which have own RFC
> describing its semantics.
> 
> Considering URI vs. SRV properties mentioned above and the requirement
> for separate RFC, I think that Nathaniel's usage of URI records is
> justified and legal.

Thanks.

I'm in favor of adopting this document and the use of the URI RR type,
with one URI RRset per-realm, not one per-{realm, protocol}, and with a
URI scheme or two by which to express all those things that we need to.

Nico
--