enrich data in ENDPOINTS document

[momorientes]

To improve public usability I'd suggest moving ENDPOINTS to a CSV file and store operationally relevant information.

Proposal:

DNS;ip4;ip6;ASN;contact
reversetraceroute.globalways.net;94.186.162.74;2a02:c98:1040:5400::6;48918;noc@globalways.net

[vhein99]

Thanks for your proposal, i think it's a good idea to provide some more information for the endpoints. I would omit the ip4 and ip6 fields though as the addresses can be queried with DNS, allowing operators to change endpoint addresses without the need to reflect those changes in the ENDPOINTS file. EDIT: It just dawned on me that some endpoints might not be named, so your proposal is good as it is. I will try to gather the necessary data for existing endpoints and close this issue once all the endpoints conform to the format in your proposal.

[vhein99]

To reduce maintenance I would propose that named endpoints omit the v4/v6 addresses (leave them blank).

DNS;ip4;ip6;ASN;contact
tr.example.com;;;64496;contact@example.com

Unnamed endpoints can omit the DNS field and fill in the v4/v6 addresses instead:

DNS;ip4;ip6;ASN;contact
;198.51.100.1;2001:db8::1;64496;contact@example.com

This approach eliminates the need to adapt the ENDPOINTS file to address changes for a named endpoint. Any thoughts on this are welcome.

[agbcix]

I'd rather use the following format:

address;ASN;contact

The first field/address can be DNS or an IP address literal.

If someone cannot provide a DNS name and has both, IPv4 and IPv6, this can be implemented by adding 2 entries. Yet, I see this a rare case and I'd expect people to provide DNS names (no-one loves typing IPv6 addresses anyway).

Having two entries in the same AS and with the same contact e-mail address is a valid use-case anyway. So why should one optimise for a rare case?

ASN and contact should be optional.

For the records: One could argue that ASN is kind of redundant as well, since it can be looked up in route registry or the routing table. Yet I believe it's helpful for quickly finding an endpoint in AS X without looking it up externally.

[pimvanpelt]

I also think address := { FQDN, ip4, ip6 }; asnumber := {16-bit ASN, 32 bit ASN }; email_contact := { valid email address }

Regarding naming, "DNS" is not a good qualifier, it describes the infrastructure system, not the records it serves. FQDN is better. For the others, LGTM. I don't mind if they are optional or mandatory, but I think that all but the "address" field should be optional. ASN can be looked up in IRRDB and if folks don't want to specify, they might say noreply@example.com or some such, or leave it empty.

To the OP: @momorientes I definitely support this type of registry to be available so that I (and others) can find nodes. I brought this up with Valentin when we met after DENOG14.

[vhein99]

@pimvanpelt to be clear, you also support the following format for an unnamed endpoint?

address;asnumber;email_contact
198.51.100.1;64496;contact@example.com
2001:db8::1;64496;contact@example.com

[pimvanpelt]

Yes, with address := { FQDN, ip4, ip6 } I meant either a DNS FQDN "host.example.com" or an ip4 192.0.2.1 or an ip6 2001:db8::1 as far as I'm concerned that captures all reasonable types of address.

Of course the tooling should accept all three as well as argument (without the need to speficy -4 or -6 for example), to simplify using the list in scripts etc. It's trivial in the client to detect which of the three types are meant, as they are uniquely distinguished.

[vhein99]

That works for me, and I also agree with @agbcix that the FQDN SHOULD be specified in favor of IPv4/IPv6 addresses. Any final thoughts from @momorientes before closing this issue?

[momorientes]

Looks good to me!

[vhein99]

Format changed by commit 98f83bcd813053b8ad9eeb8d4a93b42438e1943c.