"address record" should not be limited to A and AAAA

[gibson042]

The document should be defined in such a way that registration of a new address type beyond A and AAAA does not require updates to the ANAME specification. The IANA considerations section already hints at this, but I'd like to see it strengthened to a level where it is guaranteed rather than hopeful.

[fanf2]

I think this is a bad idea and I tried to remove it from the -01 draft. It looks like I forgot to update the IANA considerations section in the -02 draft to remove it properly.

Should ISDN, X25, NSAP, EID, NIMLOC, ATMA, HIP count as addresses? If not why not?

If another address type like A or AAAA is introduced then it'll be such a huge task that revising this document will be a tiny part of the job. And I can't imagine any other situation in which we would want extend the list of address types.

[gibson042]

Then let's call it e.g. "aliasable type" rather than "address type". I'm not trying to include anything other than A and AAAA right now, but I am trying to make the upgrade path easy and obvious (i.e., extending the registry) rather than requiring a new revision of an ALIAS RFC.

[fanf2]

I don't understand why it needs to be easy?

[gibson042]

For the same reason that it's easy to add new algorithms for e.g. DNSSEC and TSIG—because doing so doesn't affect the processing model, just which path to invoke at runtime.

[each]

I'm not sure why it needs to be hard?

Mind you, I don't think it's particularly likely that we'll invent a new flavor of IP within our lifetimes, but simply saying that ANAME applies to A and AAAA felt like an underspecification to me, and still feels that way now. I wanted there to be a clearly defined reason why ANAME should apply to exactly those two types and no others, and I figured that "types listed in the IANA 'address type' registry, which currently contains A and AAAA" would suffice. That way if someone, somehow, came up with a solid argument that ISDN ought to be added to the address type registry in the future, it would be immediately obvious how ANAME implementations should handle that.

[fanf2]

It's hard because

• it affects the performance of the auth / provisioning process (how does that scale with number of types?)

• it has awkward implications for additional section processing

• how do we define what addresses are in scope if it is not simply IP addresses? what are the criteria for the registry?

Why only A and AAAA?

• existing implementations are A + AAAA only

• other types are not part of the requirements or use cases we are trying to solve

I think generalizing to arbitrary types is a significant increase in complexity and operational risk without a clear benefit.

If this is contentious it should be discussed on the WG list.

[Habbie]

For the same reason that it's easy to add new algorithms for e.g. DNSSEC and TSIG—because doing so doesn't affect the processing model, just which path to invoke at runtime.

That comparison is flawed - adding AAAAAAAA to the DNS today would involve updating a -lot- of documents and implementations for it to work at all. A new DNSSEC or TSIG algo does not have that problem.

[vttale]

I don't think it's particularly likely that we'll invent a new flavor of IP within our lifetimes

So you weren't sold on IPv10, eh?

[each]

So you weren't sold on IPv10, eh?

We could use https://twitter.com/infinite_scream to generate the rrtype mnemonics.

[matje]

I am inclined to close this issue because I strongly agree with these arguments:

• existing implementations are A + AAAA only
• generalizing to arbitrary types is an increase in complexity and operational risk without a clear benefit (the perfect is the enemy of the good argument).

I also don't think it would be hard to update the ANAME specification with a new document if there is ever a new eligible address type. It should be as simple as:

The record type AAAAAAAAAAAAAAAA is considered an address type in the context of ANAME
processing.

And should be much easier to go through the IETF process than the ANAME specification itself :)

Also I made a minor PR #64 to minimize the references to "A and/or AAAA" and refer to them as address records/types/queries. The only remaining references are in the introduction, the terminology section (to define address type, and this can be updated with a simple document as mentioned above), and the "Coexistence with other types" section. In the latter it is only a clarification on that ANAME can coexist with other RR types, so not excluding types other than A and AAAA.

@gibson042 will this work for you? If so, I'll merge the PR and close this issue. If not, then I think we need to get more opinions from the dnsop mailing list.

[gibson042]

I can live with that.