ART-ART: Separation of architecture and interface documents

[gorryfair]

Early art-art review of draft-ietf-taps-architecture

My first observation and request is that the group rethink the separation of
the architecture and interface documents. It is a warning-sign that the
interface document is a normative reference for the architecture document. As
the documents are currently constructed, a new reader cannot grasp the
architecture without inferring some of it through reading the interface.

Consider reformulating the architecture document as an overview - introduce
principles, concepts, and terminology, but don't attempt to be normative.
(There are signs that this may already be, or have been, a path the document
was being pushed towards). If nothing else, rename it, and acknowledge that the
actual architecture is specified using the interface definition.

Note that the first sentence of the Overview in the interface document also
highlights the current structural problem.

[gorryfair]

I don't entirely agree with this ART-ART comment: I think I might well agree with moving more of the description to this Arch document, but as discussed before, I also think it useful here to set the actual requirements for the architecture, and to define the architecture. It may need to be much clearer that this architecture consists of more the API.

[mwelzl]

For completeness, this is the first statement of the interface document review:

This document reads fairly well. I have some structural concerns (see the early
review of the architecture document). In particular I think this document
contains the actual definition of the architecture and some of that is
inferential.

[britram]

Discussion at September 2021 interim:

• pass through this document with a view toward making it a high level introduction, not an architecture definition: "An Introduction to the Transport Services Architecture".
• remove normative language from this document (moving it to API, where necessary).
• move details not useful in a high level intro to API.

[tfpauly]

I disagree with this conclusion at first pass—we did a specific analysis and pass on this over a year ago, with PR #564. The normative language and the standards-track aspect was very intentional and something the WG had consensus on. The point is that the API is a specific incarnation of the TAPS architecture, but there are overarching architectural properties that go beyond a specific abstract API.

[gorryfair]

I completely agree with Tommy here, and recommend we fix this in #929. We should also of course check for any stray text or missing concepts.
I think it would also be useful to somehow better explain that in figure 3 the API function is ONE part of the system.

[gorryfair]

See linked PR first please to see if this resolves this?

[gorryfair]

A PR was merged that addressed important text issues with separation of requirements and overview, and should more clearly set out that the requirements are for the system. The question of whether the overall TAPS systems requirements belong in this ID; the API; or a separate RFC needs some discussion based on the review, before this can be closed.

[abrunstrom]

Many good text improvements in the PR @gorryfair, but I noticed two smaller updates in the PR that I think were incorrect. Fixed in #940

[gorryfair]

The review comment showed were many places where the wording of architecture can be improved. There are some high level principles that I think should remain in the architecture document. The decision in today's interim is to review the architecture to get this more into a shape that is valuable as a reference, and then check the updated draft.

[gorryfair]

I now suggest the issues are addressed and we close this issue without moving text between documents

[mwelzl]

I agree with that; closing.