Review request: AMTRELAY RRType

Hi dnsext folks,

I'm writing to solicit feedback on a request for a new RRType in
draft-jholland-mboned-driad-amt-discovery, ahead of a formal request
to dns-rrtype-applications (as encouraged in section 3.1.1 of RFC 6895).

Here's the RRType form (also in appendix A of the draft).

<form>
A. Submission Date: [hopefully soon]

B.1 Submission Type:
 [x] New RRTYPE  [ ] Modification to RRTYPE
B.2 Kind of RR:
 [x] Data RR     [ ] Meta-RR

C. Contact Information for submitter (will be publicly posted):
 Name:  Jake Holland
 Email Address: [email protected]
 International telephone number: +1-626-486-3706
 Other contact handles: [email protected]

D. Motivation for the new RRTYPE application.
 It provides a bootstrap so AMT (RFC 7450) gateways can discover
 an AMT relay that can receive multicast traffic from a specific source,
 in order to signal multicast group membership and receive multicast
 traffic over a unicast tunnel using AMT.

E. Description of the proposed RR type.
   This description can be provided in-line in the template, as an
   attachment, or with a publicly available URL.
 Please see draft-jholland-mboned-driad-amt-discovery.

F. What existing RRTYPE or RRTYPEs come closest to filling that need
   and why are they unsatisfactory?
 Some similar concepts appear in IPSECKEY, as described in
 Section 1.2 of [RFC4025]. The IPSECKEY RRType is unsatisfactory
 because it refers to IPSec Keys instead of to AMT relays, but
 the motivating considerations for using reverse IP and for
 providing a precedence are similar--an AMT gateway often
 has access to a source address for a multicast (S,G), but does
 not have access to a relay address that can receive multicast
 traffic from the source, without administrative configuration.

 Defining a format for a TXT record could serve the need for AMT
 relay discovery semantics, but Section 5 of [RFC5507] provides a
 compelling argument for requesting a new RRType instead.

G. What mnemonic is requested for the new RRTYPE (optional)?
 AMTRELAY

H. Does the requested RRTYPE make use of any existing IANA registry
   or require the creation of a new IANA subregistry in DNS
   Parameters?
 Yes, IANA is requested to create a subregistry named "AMT Relay
 Type Field" in a "AMTRELAY Resource Record Parameters" registry.
 The field values are defined in Section 4.2.3 and Section 4.2.4,
 and a summary table is given in Section 5.

I. Does the proposal require/expect any changes in DNS
   servers/resolvers that prevent the new type from being processed
   as an unknown RRTYPE (see RFC3597)?
 No.

J. Comments:
 It may be worth noting that the gateway type field from Section 2.3 of
 [RFC4025] and Section 2.5 of [RFC4025] is very similar to the
 Relay Type field in this request.  I tentatively assume that trying to
 re-use that sub-registry is a worse idea than duplicating it, but I'll
 invite others to consider the question and voice an opinion, in case
 there is a different consensus.
    https://www.ietf.org/assignments/
        ipseckey-rr-parameters/ipseckey-rr-parameters.xml

</form>


I also have one additional request for DNS expert opinion about text that appears
in section 2.4:
https://tools.ietf.org/html/draft-jholland-mboned-driad-amt-discovery-03#section-2.4

I borrowed the language from https://tools.ietf.org/html/rfc4025#section-1.2,
but I'm not actually sure what "the fashion usual for PTR records" means,
precisely:

   When the reverse IP mapping has no AMTRELAY RR but does have a PTR
   record, the lookup is done in the fashion usual for PTR records.  The
   IP address' octets (IPv4) or nibbles (IPv6) are reversed and looked
   up with the appropriate suffix.  Any CNAMEs or DNAMEs found MUST be
   followed, and finally the AMTRELAY RR is queried with the resulting
   domain name.

Does that mean I'd do an A/AAAA query for the domain name from the PTR, follow
CNAME/DNAMEs until the A/AAAA is resolved and use the final name that
found an answer (if any) to do the AMTRELAY (or IPSECKEY) query?  (That would
work I think, but it seems like a lot of round-trips...)

Thanks in advance for any advice you can offer.

Cheers,
Jake


_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext