# 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*