You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reading the API draft, I noticed that for Security parameters, the draft specifies how to set Pre-Connection Parameters (Section 5.3.1) and Connection Establishment Callbacks (Section 5.3.2).
The Pre-Connection Parameters directly correspond to what we have in the Security draft, but the rest is less clear to me:
So I wonder: Should the API draft contain more of these Security interfaces?
I don't have a strong opinion on this. I'm totally fine with having the other Security parameters/interfaces be implementation-specific, so the API draft does not become even longer and more complex.
However, I just wanted to point this out as an inconsistency among our documents.
The text was updated successfully, but these errors were encountered:
Suggestion in call is to provide some examples in an appendix of the API document. Other alternative is a future informational document to give such examples.
Reading the API draft, I noticed that for Security parameters, the draft specifies how to set Pre-Connection Parameters (Section 5.3.1) and Connection Establishment Callbacks (Section 5.3.2).
The Pre-Connection Parameters directly correspond to what we have in the Security draft, but the rest is less clear to me:
The Security draft also has Connection interfaces (see https://tools.ietf.org/html/draft-ietf-taps-transport-security-10#section-5.2) and Post-Connection Interfaces (see https://tools.ietf.org/html/draft-ietf-taps-transport-security-10#section-5.3).
The Connection Interfaces might correspond to the Connection Establishment Callbacks. But I don't think we have the Post-Connection Interfaces in the API draft, i.e., Connection Termination, Key Update, Pre-Shared Key Export, Key Expiration, and Mobility Events.
So I wonder: Should the API draft contain more of these Security interfaces?
I don't have a strong opinion on this. I'm totally fine with having the other Security parameters/interfaces be implementation-specific, so the API draft does not become even longer and more complex.
However, I just wanted to point this out as an inconsistency among our documents.
The text was updated successfully, but these errors were encountered: