Hi Bob, These changes all look good to me. Regards, Brian On 5/11/22 9:43 AM, Robert Moskowitz wrote:
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 NitsI am the IoT Directorate reviewer for this draft. Please treat these commentsas 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 wouldlike 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 outa 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 thinkof 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 isunclear 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 beenproblematic in some instances. Is there a risk of "de facto standardization" in those two private use reservations? Would it make more sense to allow forprovisional 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 couldbe 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 HDAAs 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 inthe document, it states that this document will not make any firmrecommendations 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 thismapping 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 IPv6addresses, 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 toORCHID, 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! BobI think that is it! Bob
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call