clarification section 4.1

[mglt]

4.1. UAS Remote Identifiers Problem Space

"""
crypto agility and implicit encoding rules. Similarly, a self-
attestation of the Hierarchical registration of the RID (an
attestation of a RID third-party registration "certificate") can be
done in 200 bytes. Both these are detailed in UAS RID
[I-D.ietf-drip-rid].
"""

I am wondering if the number 200 is related to the allocated authentication payload of 201 bytes. If that is the case, it seems that we are very short, and we may provide some evidences that we will not be limited to a single algorithm. I am also wondering where this 200 bytes comes from.

At a higher level I am wondering if these justifications are needed in the architecture document. I do no think so, as in my view these discussion are really much in the solution space. It is likely you will have many questions... until the drip-rid is copy/paste. I believe a high level description on how the information are handled by the parties - understandable by someone non familiar with HIP is the goal of the section. Currently, it seems we are proving the solution space works.

[ShuaiZhao]

I am wondering if the number 200 is related to the allocated authentication payload of 201 bytes. If that is the case, it seems that we are very short, and we may provide some evidences that we will not be limited to a single algorithm. I am also wondering where this 200 bytes comes from.

@mglt Yes it is , if I am not mistaken, See authentication draft https://www.ietf.org/archive/id/draft-ietf-drip-auth-01.txt
@kc2rxo may help with this section.

At a higher level I am wondering if these justifications are needed in the architecture document. I do no think so, as in my view these discussion are really much in the solution space. It is likely you will have many questions... until the drip-rid is copy/paste. I believe a high level description on how the information are handled by the parties - understandable by someone non familiar with HIP is the goal of the section. Currently, it seems we are proving the solution space works.

@mglt I know we may have provided some date point, but the detailed solutions are spread into multiple normative drafts. By listing more data points and explanations why we come out with such data may sound even more solution-oriented. But I maybe wrong. please let US know if referencing to other drafts simply don't work in your opinion.

[mglt]

I agree the numbers are not important in themselves. What is important is to show that the solution needs to fill some specific requirements here the 201 limitations, that traditional solution are unable to do. It is mostly to describe the motivation.
Ensuring we fill the requirement needs to be done today but also in the long term. More especially, with th current text I have the impression it works today with a given cryptographic algorithm, but if we have a single remaining byte, I have the impression we are tided to that algorithm. It is more important to explain why we are not tided to that algo rather than having a detailed byte description

[cardsw]

Indeed the 201 bytes comes from ASTM F3411: 17 payload bytes in the first page of a paged Authentication Message + 23 payload bytes in each of up to 8 more pages. From that 201, we lose 1 byte to identify the Specific Authentication Method (SAM). We will apply to ICAO (deputized by ASTM for an IANA-like function) for several SAM codes for different DRIP methods. Thus we have 200 at most, and that is exactly how many we use in the longest of our several message structures. Lack of margin is a concern, of course, but Adam, Bob and I have been working this for 2 years, and are confident the 200 suffices.

[ShuaiZhao]

The HHIT prefix and suiteID provide crypto agility and implicit encoding rules. Similarly, a self-attestation of the Hierarchical registration of the RID (an attestation of a RID third-party registration "certificate") can be done in 200 bytes. Both these are detailed in UAS RID {{I-D.ietf-drip-rid}}.
`

Editor-note 10: to be more specific why 200 bytes is sufficient.`

[mglt]

to me such performance are more related to the rid description than an architecture. The text is nice, but probably not in the proper document - especially if we need to reference the rid document.

[ShuaiZhao]

agreed to remove crypto-related text in this section, so the following text is removed in -15.

The HHIT prefix and suiteID provide crypto agility and implicit encoding rules. Similarly, a self-attestation of the Hierarchical registration of the RID (an attestation of a RID third-party registration "certificate") can be done in 200 bytes. Both these are detailed in UAS RID {{I-D.ietf-drip-rid}}.