Re: [Iot-directorate] [Drip] Iotdir last call review of draft-ietf-drip-rid-24

[Robert Moskowitz <[e-mail]>]

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