DRIP FQDN formatting

[kc2rxo]

There are two issues in this area.

1. At the moment the FQDN is a mix of hex and decimal notations. Stu C. has expressed at least private discontent with this declaring we should set it to one or the other. Is there a preference?
2. Serial Number FQDNs. See below.

My thoughts are not totally clear on this yet - please excuse the ramblings below. I felt they were better immortalized here instead of being forgotten.

Serial Numbers (SN) are tricky. We can easily map their format to an FQDN as described in the draft however the latter half of the FQDN has some issues.

Currently they are placed under mfr.hhit.arpa. This logically makes no sense 3/4 of the time. While we recommend that a DET is used to form a SN but it is up to a manufacturer to adopt it. The minimum we can hope for is that they decided to add the SN to DNS and use the mechanisms to point to their own server (not following our standards for endpoints to get information out).

This got me thinking: perhaps we need something more akin to *.uas.arpa. There would be two sub-domains under this: det.uas.arpa and mfr.uas.arpa. Does this mean hhit.arpa would not be needed anymore or do we still push for it?

det.uas.arpawould be a used in a PTR of in ip6.arpa. Any SN would then just have some sort of record (CNAME, DNAME, PTR?) pointing to either of these addresses from the SN FQDN. This would ONLY be the case if the SN was based on a DET.

There has been some private discussion about perhaps any HDA could register a SN from their operator. I'm not sure how to protect against multiple registrations from various HDAs (a major concern I have). An SN would point to an HDA for any information lookup - something we could guarantee via standards but what of the integrity of the information? I am torn on this as it gives control of the aircraft to its owner but causes other issues in the process.

[kc2rxo]

Let me attempt to give a concrete example.

Lets say we have the following DET: 2001:0030:00a0:0145:a3ad:1952:0ad0:a69e According the to text in Section 8 (and the domain changes) we would add, roughly, the following to ip6.arpa:

e.9.8.a.0.d.a.0.2.5.9.1.d.a.3.a.5.4.1.0.0.a.0.0.0.3.0.0.0.1.0.0.2.ip6.arpa IN HIP ... 
e.9.8.a.0.d.a.0.2.5.9.1.d.a.3.a.5.4.1.0.0.a.0.0.0.3.0.0.0.1.0.0.2.ip6.arpa IN CERT ... 
e.9.8.a.0.d.a.0.2.5.9.1.d.a.3.a.5.4.1.0.0.a.0.0.0.3.0.0.0.1.0.0.2.ip6.arpa IN TLSA ... 

maybe add:
e.9.8.a.0.d.a.0.2.5.9.1.d.a.3.a.5.4.1.0.0.a.0.0.0.3.0.0.0.1.0.0.2.ip6.arpa IN PTR a3ad19520ad0a69e.5.20.10.2001003.det.uas.arpa

This DET is also encoded as a Serial Number: 8653FZ2T7B8RA85D19LX It, per Section 8.1.2 (and the revised domains above), has the following FQDN: Z2T7B8RA85D19LX.8653.mfr.uas.arpa It would have, I think, the following in DNS:

Z2T7B8RA85D19LX.8653.mfr.uas.arpa DNAME a3ad19520ad0a69e.5.20.10.2001003.det.uas.arpa
or
Z2T7B8RA85D19LX.8653.mfr.uas.arpa DNAME e.9.8.a.0.d.a.0.2.5.9.1.d.a.3.a.5.4.1.0.0.a.0.0.0.3.0.0.0.1.0.0.2.ip6.arpa

[evyncke]

This issue is very important and should be brought to the list.

I am now really puzzled and annoyed if 3 days after I finally approved drip-rid and its very specific use of DNS in section 5, the -reg uses another FQDN scheme. What am I missing here ? I hope that I am misunderstanding something ;-)

[evyncke]

e.9.8.a.0.d.a.0.2.5.9.1.d.a.3.a.5.4.1.0.0.a.0.0.0.3.0.0.0.1.0.0.2.ip6.arpa IN HIP

There should be only one 0 between the 3 and 1.0.0.2 ;-)

[kc2rxo]

This issue is very important and should be brought to the list.

I am now really puzzled and annoyed if 3 days after I finally approved drip-rid and its very specific use of DNS in section 5, the -reg uses another FQDN scheme. What am I missing here ? I hope that I am misunderstanding something ;-)

From my understanding - and this might be a miscommunication is that the content in drip-rid was very clearly marked as examples; not the actual specification (which was punted to this document).

[evyncke]

From my understanding - and this might be a miscommunication is that the content in drip-rid was very clearly marked as examples; not the actual specification (which was punted to this document).

Correct, drip-rid section 5 marks those as examples, but this would be easier for the -rid reader/implementer to provide sensible examples like the one discussed in the registry related I-Ds. If only to be consistent.

We can probably fix this during the AUTH48 stage later.