On 5/4/22 09:23, Robert Moskowitz wrote:
Thanks for the response, Brian. This is a quick reply. I will do a
more complete one as I get more comments in to cross-compare them.
On 5/4/22 08:48, Brian Haberman via Datatracker wrote:
Reviewer: Brian Haberman
Review result: Ready with Nits
I am the IoT Directorate reviewer for this draft. Please treat these
comments
as normal last call comments.
>From an IoT perspective, I believe this draft is nearly ready and I
do not see
anything described here that would be an impact on IoT devices. I
only came
across a few nits that may be worth addressing. Please let me know if
you would
like to discuss any of these...
1. In the Introduction, it mentions a 20-character identifier and
references
ID-1 from the DRIP requirements document. That requirements document
calls out
a 19-byte identifier. Can you clarify?
I will look to see if I can do better with the text. The UA ID field
in F3411 is 20 characters. Type 4 is Session ID that uses one byte of
the 20 for who's UA ID. IETF DRIP has been assigned value '1'. So UA
ID CAN be 20, but since IETF's DET is a Session ID under UA ID, it can
only be 19 bytes...
I changed Intro to specify 19 characters as is in ID-1
I cleaned up the text in sec 4 to provide clarity on UAS Type lengths.
2. In 2.3, the definition of a HIT is indicated to be 128 bits long,
but there
is not an indicated length for HHITs. The later definition of HHIT
generation,
in section 3.5, tells me it is also 128 bits long, but it may be good to
clarify this definition.
I will see what I can do here. yes, HHITs are 128 bytes.
I change Intro para 2 to say:
This document describes (per Section 3 of [drip-architecture]) the
use of Hierarchical Host Identity Tags (HHITs) (Section 3) as self-
asserting IPv6 addresses and thereby a trustable identifier for use
as the UAS Remote ID. HHITs add explicit hierarchy to the 128-bit
HITs, enabling DNS HHIT queries (Host ID for authentication, e.g.,
[drip-authentication]) and for Extensible Provisioning Protocol (EPP)
Registrar discovery [RFC9224] for 3rd-party identification
attestation (e.g., [drip-authentication]).
3. Section 3 - similar to the comment above, the second paragraph
omits the
28-bit prefix in its description of the HHIT, which initially led me
to think
of the HHIT as being 100 bits long.
I see the reason for the confusion. I am confused how I came up with
this text!
Now to fix it:
The 128-bit HHITs represent the HI in only a 64-bit hash, rather than
the 96 bits in HITs. 4 of these 32 freed up bits expand the Suite ID
to 8 bits, and the other 28 bits are used to create a hierarchical
administration organization for HIT domains. Hierarchical HIT
construction is defined in Section 3.5. The input values for the
Encoding rules are described in Section 3.5.1.
4. The HHIT Suite ID description in section 3.2 is a bit confusing.
It appears
that the registry described is for the 8-bit enhanced Suite ID, but
it is
unclear why value 16 is marked as RESERVED.
Good catch on value 16. That I need to pull, as I was working the HIT
8-bit extended Suite ID wrong. 16 is a perfectly valid 8-bit HIT so
it is NOT reserved in HHIT Suite ID.
And confusing? Without a detailed layout of how HITs 4 and 8 bit
worked, I really struggled to not get lost in HIP weeds. 8.2 has it
right. I will see if I can pull some text from there to here.
Hopefully this new text is better:
The HHIT Suite IDs specify the HI and hash algorithms. These are a
superset of the 4/8-bit HIT Suite ID as defined in Section 5.2.10 of
[RFC7401].
The HHIT values of 1 - 15 map to the basic 4-bit HIT Suite IDs. HHIT
values of 17 - 31 map to the extended 8-bit HIT Suite IDs. HHIT
values unique to HHIT will start with value 32.
5. Section 3.2.1 - Private Use reservations in IANA registries have been
problematic in some instances. Is there a risk of "de facto
standardization" in
those two private use reservations? Would it make more sense to allow
for
provisional allocations that could be transitioned to permanent ones?
The intent here is experimentation. If it is worth doing, it is worth
asking for an Suite ID. Perhaps I need more in IANA considerations on
this? Can you point me to anything I can pull from? Historically, I
was involved in a lot of private fields in IEEE 802 work and this is a
carryover from that.
I added at the end of 3.2.1:
They should not be used to create a "de facto standardization".
Section 8.2 states that additional Suite IDs can be made through IETF
Review.
6. Section 3.3.1 - I see a few instances of lower-case "must" here
that could
be read as needing to be "MUST" (e.g., maintaining a DNS zone) for
interoperability reasons.
Workgroup debates on MUST DNS or well really here, there MIGHT be
other choices. This is aviation afterall, and they have had their own
way of doing things. Right now in ICAO we are getting pushback on
specifying DNS. We will have to show some IoT-style DOS proxying to
quell the concerns.
So I went with must rather than MUST, but I am easy to sway on this one.
So I went with MUST, but one I change to SHOULD:
It SHOULD have a public policy on what is necessary to obtain an HDA
As the RAA COULD be a private RAA (e.g. US DoD) so its policies, would
be private to its known members...
7. Section 3.3.1 - I would suggest changing "raa.bar.com" to
"raa.example.com"
to comply with the rules for using domain names in documents.
Will do. Kind of an ossified habit of mine that needs some good kicking.
8. Section 3.4.1.1 - The EdDSA Curve field is populated using the
values from
figure 2? The 16-bit field adjacent to the EdDSA Curve field is
Reserved?
Oops. First that is a typo for 7401 section. It should be 5.2.9.
then in 5.2.9 you will see the same format for ECDSA. Just copied
it. I can put something like NULL in there for those 16 bits?
NULL used for those 16 bits.
9. Section 4.2 discusses the use of DNSSEC to provide trusted
mappings and
section 5 talks about DNS-over-TLS as a viable alternative to DNSSEC.
Later in
the document, it states that this document will not make any firm
recommendations on the mapping service. I will note that DNS-over-TLS
is not a
sufficient replacement for DNSSEC as they address two different
problems.
Additionally, DNS-over-TLS does define two different profiles of
operation.
Please ensure that another document discusses the functions needed in
this
mapping service and provides MTI guidance to ensure there is always an
available mapping service in all use cases.
I will have to look into this. No quick answer.
I cut out reference to DNS-over-TLS. Leaving only DNSSEC for trusted
mappings.
10 Section 8.1 - I am not sure why "Reserved-by-Protocol" is listed as
"False?". Given that these identifiers are indistinguishable from IPv6
addresses, do you want all IPv6 implementations to handle these in a
special
way if they are seen as either a source or destination address?
Similar to
ORCHID, I would expect this value to be FALSE.
This whole section was given to me. I have not worked with this
before; we did not use this when we got the prefix for HIP. So I
welcome all guidance on getting this right.
Can anyone else confirm Brians' opinion that FALSE should be the value
here?
As said, 7343 has "False". Is this what I should use here? Someone
that understands this template please speak up???
thank you!
Bob
I think that is it!
Bob
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
