Re: [Drip] Comments on draft-ietf-drip-registries-09

[Robert Moskowitz <[e-mail]>]

Differentiated Access Process

No comments.

DRIP in the Domain Name System

ICAO SHOULD delegate domains beneath these apexes to national civil 
aviation authorities.

First, CAA has been defined, so use it here and anywhere else (other 
than first use) of civil aviation authorities.

Second, why is "apexes" plural.  From reading the prior para, I don't 
get it.

This ensures DRIP complies with national law and regulation since these 
are matters of national sovereignty. The HHIT has a designated field, 
the RAA, for this exact purpose and SHOULD be used instead of a ISO-3166 
entries: ie a two- or three-letter or a three digit country code.

Note that 3166 defines 3-digit numeric codes for each nation (see 
https://en.wikipedia.org/wiki/ISO_3166-1_numeric and 
https://www.iso.org/iso-3166-country-codes.htm) and drip-dki uses this 
to assign the RAAs.  So we need to bring ideas and text into alignment.  
Using the 3166 numeric codes gets us all (IETF and ICAO) out of the 
business of, for the most part, what country gets what RAA(s).  It punts 
it to the UN for first best effort.

Perhaps reference https://www.iso.org/iso-3166-country-codes.html here 
for the numeric coding.

(both DIME-level and national-level)

What is the distinction here?  what point are you making, as I am 
struggling mapping this clause to above text.

DRIP Entity Tags

An addressing plan will need to be developed.

We can easily say here that it is the RAAs and HDAs that allocate most 
DETs here.

We can at least say that there are delegation zones at each of these levels.

Reverse lookups of these IPv6 addresses will translate the address into 
a domain name in the manner defined in [rfc1816]

Will it be an HHIT RR or a URI RR or both?  Or more?

We need more flexibility here.  Definitely should mention URI RR.

And of course we need to add at least the first cut at the HHIT RR.

Serial Numbers & Other UAS ID Types

    This document specifies the creation and delegation to ICAO of the
    subdomain uas.icao.arpa.

I disagree with this structure on two grounds:

We don't have a commitment from ICAO on this.  We need to obtain it.  I 
am working on this, but we will need broader involvement by IETF to make 
it happen.

I disagree with use of "uas".  Within our architecture, we use DETs for 
things like USS, SDSP, Finders, wireless towers, and perhaps general 
aviation craft.  Maybe .aviation. to be broader.

And .sn. may NOT be ICAO.  We need to sort this out.  Is it really 
ANSI-CTA?  It is their code space, and who now admins it?


Endorsements

Here is the section that SHOULD be referenced in many places above, or 
there is a problem.  Or it is not this section???

Now as I read through this section I have SERIOUS reservations about 
feature/function creep.

I have seen too many such in the PKI world.

We need to look very closely at WHAT is an Endorsement from a DIME. 
Remember "Identity Management Architecture"???

Your statement:

Other forms of the scope could for example be a 4-dimensional volume 
definition.

has little if anything to do with Identity.  It is role at best. maybe.

Successful Identity Management Architecture stay with Identity and avoid 
attributes of Identity.

I want serious rethink and rewriting here.  Serious regrouping of the 
object model, separating Identity from roles and such.

Enough for this time on Endorsement section.  It will take a serious 
effort here.


X.509 Certificates

I owe a serious rewrite of this section.  It will come AFTER I sort a 
few things out in drip-dki and we agree what goes into which draft.

Security Considerations

At time of writing this is signing over the new key with the previous 
key in a secure fashion and it being validated by others before changing 
any links in DNS.

Something is wrong with this sentence.  What about "time of writing 
this" and "is signing".  Please clarify what your intent here is.

his attribute of the DET to have different identities could also...

I am having problems with use of "identities" here as a given DET is one 
Identity.  And it is one Identifier.  I **think** you are mixing 
concepts and perhaps need a better term than "DET" to express it. Please 
clarify.

DET Generation

The entity sends to the DIME its HI for it to be hashed and result in 
the DET.

The entity is perfectly capable of doing the DET generation and sending 
it to the DIME along with the HI.  In fact that SHOULD be the preferred 
process.

The DIME would then either accept (returning the DET to the device) or 
deny this pairing.

There is NOTHING to deny of this pairing.  It is a natural application 
of the 9374 ORCHID algorithm on the HID, SuiteID, and HI.

Rather the DIME accepts or rejects this DET/HI.  Normally as it already 
has this DET with another HI due to hash collision.

generate keypairs for the Aircraft on Operator devices

You swing from saying device hardware limitations and connectivity to 
talking about Aircraft.  That is an assumption this problem is only on 
aircraft; this is an example, there can be others.

this completes my review of draft-ietf-drip-registries-09

At least at this time.  And now time for discussions.


Bob