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...
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.
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.
Because some other HHIT prefix may be less than 28 bits, allowing for a
larger hash.
But will see about better clarity.
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.
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.
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.
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?
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.
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?
thank you!
Bob
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
