clarification section 4.3

[mglt]

4.3. HHIT for DRIP Identifier Registration and Lookup

"""
Remote ID needs a deterministic lookup mechanism that rapidly
provides actionable information about the identified UA. Given the
size constraints imposed by the Bluetooth 4 broadcast media, the
Remote ID itself needs to be the inquiry input into the lookup.
"""

I believe the text can be simplified. When we mention "need", it unclear whether that refs to a specific requirements or not and if so, the requirements shoudl be mentioned.
I do not see mentioning the requirement in that place necessary as the the document is rather describing an architecture and later should shows how the requirements are addressed.
As a result, this section should limit the description of the lookup and registration.
It seems to me that the important information from these lines are that lookups are performed from the RID. I think a clearer description of how the lookup is performed, why it is trustable and what information are retrieved should be clearly explained.

[ShuaiZhao]

@mglt I can see there is a clear requirement from -req: section 4.4. https://datatracker.ietf.org/doc/html/draft-ietf-drip-reqs-15#section-4.4

you had similar comments in #28 . @bob to give a better text. Then #26 #27 #28 can be closed together

[mglt]

agree.

[cardsw]

I agree that in -arch we should not recapitulate requirements, but rather cite specific numbered requirements from -reqs and specify how the architecture will enable satisfying them.

[ShuaiZhao]

add note 12 to address #26 #27 and #28

4.3. HHIT for DRIP Identifier Registration and Lookup
`

Editor-note 12: more description regarding 1) Is that something we should address in the Arch- 2) if yes, then adding more text about how a trustable lookup is performed
`

[ShuaiZhao]

Bob proposed text:

4.3.  HHIT for DRIP Identifier Registration and Lookup

   Remote ID needs a deterministic lookup mechanism that rapidly
   provides actionable information about the identified UA.  Given the
   size constraints imposed by the Bluetooth 4 broadcast media, the
   Remote ID itself needs to be a non-spoofable inquiry input into the
   lookup.

   A DRIP registration process based on the explicit hierarchy within a
   HHIT provides manageable uniqueness of the HI for the HHIT (defense
   against a cryptographic hash second pre-image attack on the HHIT;
   e.g. multiple HIs yielding the same HHIT).  A lookup of the HHIT into
   this registration data provides the registered HI for HHIT proof.  A
   first-come-first-serve registration for a HHIT provides deterministic
   access to any other needed actionable information based on inquiry
   access authority (more details in Section 5.2).

[ShuaiZhao]

above text was implemented in -15