Re: [Drip] Working with the proposed DET DNS RR

[Stu Card <[e-mail]>]

Specifying names in DNS (corresponding to DETs) to make them not only human readable (and _maybe_ memorable) but also usable as “abbreviations” for compact display on small screens of Observers devices AFAIK is over-specifying. Developers of client apps can “abbreviate” however they want. We should not constrain FQDNs to be _directly_ usable as “abbreviations” for display. Serial numbers (which we are deferring anyway) should be easily mapped among DET <-> FQDN <-> printed sticker on UA. Perhaps the DET registration hierarchy should likewise be easily mapped, but how to do that, given international politics at ICAO, is unclear.

From: Robert Moskowitz <[e-mail]>
Sent: Tuesday, October 17, 2023 11:53 AM
To: Stu Card <[e-mail]>; Adam Wiethuechter <[e-mail]>; [e-mail]; Nandana Krishna <[e-mail]>
Subject: Re: [Drip] Working with the proposed DET DNS RR

 I don't think I said anything about how client apps format their display.

I DID say that the client app has to be able to consistently decode the DNS record, thus we need to define the actual bits on the wire for the RR.  Something to work on at IETF with those that know how to do this.

This then advises how DNS servers format the RR in their admin interface(s).
On 10/17/23 11:41, Stu Card wrote:
I agree any DNS record we need, we must define.
I disagree we need to put, in DNS, how we want client apps to format their displays.

From: Robert Moskowitz <[e-mail]><mailto:[e-mail]>
Sent: Monday, October 9, 2023 10:45 AM
To: Stu Card <[e-mail]><mailto:[e-mail]>; Adam Wiethuechter <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Nandana Krishna <[e-mail]><mailto:[e-mail]>
Subject: Re: [Drip] Working with the proposed DET DNS RR

No.  We MUST define the actual DNS query response or have some clear way for standard DNS clients to parse the response.

We should get DNSops guidance on this one.
On 10/7/23 12:02, Stu Card wrote:
I think we are over-specifying here.
We fully specify the IPv6 address form.
We should only loosely specify the FQDN form.
Display formats are OSI Layer 6, in which IETF rarely gets involved.

From: Tm-rid <[e-mail]><mailto:[e-mail]> On Behalf Of Adam Wiethuechter
Sent: Friday, October 6, 2023 1:38 PM
To: Robert Moskowitz <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Nandana Krishna <[e-mail]><mailto:[e-mail]>
Subject: Re: [Drip] Working with the proposed DET DNS RR

To make the HID Abbreviation worthwhile for display purposes we need it to make it less characters than a full DET (32 characters) and a full Serial Number (20 characters).

On one hand this is not up to us, so any text we do place into a standard should use "MAY" and be an appendix of the document.

If we truncate to the last 4 hex-characters of the DET we have at most 16 characters to abbreviate. Do we just make the field that is null terminated (up to some reasonable length, 255?) or a max of 16 characters null padded?

We can add some recommendations of how the HID Abbreviation can be filled. For the 4x RAA selection, just do Alpha-2 + [0-3], i.e. DE2 = Germany 2. Ultimately its up to the RAA+HDA. RAA should probably mandate their HDAs use a common "Alpha-2/3 + Code" for the first part of the HID Abbreviation and the rest is up to the HDA itself.

---

Also, if we are only intending to put the Broadcast Endorsement in this RR (as discussed previously) then we can just use the binary encoded form of 136-bytes just like the RID Broadcast. No need to CBOR encode it here.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Robert Moskowitz <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, October 5, 2023 8:34 PM
To: Adam Wiethuechter <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Nandana Krishna <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Drip] Working with the proposed DET DNS RR


On 10/5/23 19:58, Adam Wiethuechter wrote:
An SN is always 20-characters long per the ANSI/CTA 2063-A Format.
So, I propose 20-bytes that is null when not in use that is ASCII encoded.

TYPE and STATUS probably only need a single byte each (256 max values) and that is a bit overkill. We could compress down to 4-bits each (16 values each, thus only a single byte encoded) but I am not sure if it is worth the trouble or if that gives us enough space.

The HID Abbreviation is a maximum of I think 13 characters, null padded and ASCII encoded.

I have previously commented about the following:

   For RAAs allocated in the ISO range Section 4.2.1, the RAA
   abbreviation MUST be set to the ISO 3166-1 country code (either
   Alpha-2 or Alpha-3).


As we are assigning 4 RAAs per 3166-1 number, I don't see how this works.





CBOR format of the Endorsement is found in the Appendix. We need to ask the question of how we make this CBOR compressed using CBOR tags and if there is an outer CBOR tag to metadata the different kinds of Endorsements we have.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Tm-rid <[e-mail]><mailto:[e-mail]> on behalf of Robert Moskowitz <[e-mail]><mailto:[e-mail]>
Sent: Wednesday, October 4, 2023 11:16 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>; Nandana Krishna <[e-mail]><mailto:[e-mail]>
Subject: [Drip] Working with the proposed DET DNS RR

I went digging into how to support proposed DNS RR in current BIND. Like
I mentioned earlier, we did this 20 years ago in HIP, and may others
have done it as well.  It was formalized in RFC 3597 using RR TYPEnnn,
where nnn is the proposed type value.

Right away, I see that drip-registries-13 is missing an IANA
Considerations for allocating the DNS RR value.  A quick look at

https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

shows 66-98 are unassigned, so this section (and 8.1.1) can propose the
value of 66 as is the common draft practice for adding to a registry.
Until DNSops (and we could ask nicely) what value to use now.

So using TYPE66, the DNS BIND entry would be:

fqdn.   IN  TYPE66 \# nnn ( hhhh....hhhh )

where

nnn is the number of bytes encoded in the RR

hhhh....hhhh is the hex string, and wrapping this so lines are short.

Now on to the encoding per 8.1.1, but first!

currently there is an optional field, SN, embedded in the middle of the
values.  How would a client decode this?  Not by length, as Endorsements
vary in size?  We need some help here, I think.  As I can't think how to
do this.  So for now, at least I will ignore the SN sub-field...

DET is 16 bytes
TYPE is how long?  AND STATUS?  I don't see them enumerated in -13? So
for now, a byte each?  But we need to add them and into IANA Considerations.

HID Abbreviation.  This sounds good in the draft, but how is it actually
represented in the RR and decoded?  And thus encoded?  We need better
content/instructions here.  No way can I build general TYPE66 content.

Endorsement in CBOR format.  Any help here with actual data in? Again,
you can write it in some text form, but in the end we need examples of
actual hex content?

So here is a start.  the 23rd is draft cut-off date, so let's see what
we can work out and then Adam can push out a new ver...

Bob



--
Tm-rid mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tm-rid





--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [e-mail]<mailto:[e-mail]>

There's no limit to what can be accomplished if it doesn't matter who gets the credit







--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [e-mail]<mailto:[e-mail]>

There's no limit to what can be accomplished if it doesn't matter who gets the credit