Last Call Review of draft-ietf-taps-arch-17
review-ietf-taps-arch-17-opsdir-lc-dhody-2023-04-14-00

# OPSDIR review of draft-ietf-taps-arch

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in the last-call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last-call comments.

The document is clear and well-written. The motivation is described well. The
architecture is clean. I have some nits and queries apart from a request to
consider adding text related to Operations.

## Operational Consideration

The document lacks any operational/manageability considerations. I am unsure
how much of the guidance from RFC 5706 would be relevant for API architecture.
I would urge authors to think if any operational/manageability considerations
need to be highlighted here or in the other documents. For instance (feel free
to disregard if they do not make sense) -

- Any guidelines to control and configure the API layer or the Implementations?
Anything on configuring System Policy?

- Any guidance on the co-existence of Socket API as well as the new Transport
API? I don't see an issue but you are the expert!

- Are there any changes in how would application locate issues with transport
sessions? In the event handling is there a need to also highlight errors for
instance?

- ...

## Nits

- If you wish, you can avoid expanding API, it is well known as per
https://www.rfc-editor.org/materials/abbrev.expansion.txt

- Unnecessary comma at "not consistent, and varies depending" (section 1)

- A comma is missing between ignore and prefer at "Preference: A preference to
prohibit, avoid, ignore prefer or require a specific Transport Feature."
(section 1.4)

- Not all abbreviations in Figure 2 are exempted from expansion on first use.
Maybe you can add and expand them in Section 1.4.

- Add suitable reference for "User Timeout Option for TCP" (section 3.2)

- Expand STUN, and ICE on first use.

- Does this needs to be MUST NOT - "A Transport Services system must not
automatically fall back from secure protocols to insecure protocols..."
(section 6)

## Queries

- Why a SHOULD here instead of MUST? In which case it would be acceptable to
race a non-identical protocol stack?

````
A Transport Services implementation SHOULD
only race Protocol Stacks where the transport
security protocols within the stacks are
identical.
````

- How long is the cached state maintained? Are there any requirements or
suggestions that need to be provided?

Thanks!
Dhruv

---

*In case of bad formatting, see this message at -
https://notes.ietf.org/draft-ietf-taps-arch?view*