Skip to main content

Last Call Review of draft-ietf-taps-arch-17

Request Review of draft-ietf-taps-arch
Requested revision No specific revision (document currently at 19)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2023-04-14
Requested 2023-03-30
Authors Tommy Pauly , Brian Trammell , Anna Brunstrom , Gorry Fairhurst , Colin Perkins
I-D last updated 2023-04-14
Completed reviews Opsdir Telechat review of -18 by Dhruv Dhody (diff)
Intdir Telechat review of -18 by Bernie Volz (diff)
Secdir Early review of -12 by Watson Ladd (diff)
Artart Early review of -11 by Robert Sparks (diff)
Secdir Last Call review of -17 by Watson Ladd (diff)
Opsdir Last Call review of -17 by Dhruv Dhody (diff)
Assignment Reviewer Dhruv Dhody
State Completed
Request Last Call review on draft-ietf-taps-arch by Ops Directorate Assigned
Posted at
Reviewed revision 17 (document currently at 19)
Result Has issues
Completed 2023-04-14
# 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

- ...

## Nits

- If you wish, you can avoid expanding API, it is well known as per

- 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

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



*In case of bad formatting, see this message at -*