Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: (with DISCUSS and COMMENT)

["Brian Trammell (IETF)" <[e-mail]>]

hi Gorry, all,

inlining to switch it up a bit, I suppose...

> On 5 Sep 2023, at 12:44, Gorry Fairhurst <[e-mail]> wrote:
> 
> I also agree with what was threashed out, over quite some time, in the TAPS WG. I agree that someone can have a Transport Services system and could implement a different API to this - if that is what someone needed. The two are independent in this way, and other SDOs or companies could in future to cite the system spec aka Arch - and develop components of that API, Policy, whatever. I recall that being able to cite this spec was also important in the choice of standards track for Arch. 
> 
> I'm less sure one can have an API without a set of system components beneath, but that likely means if someone wants to implement the API, they do need to read both Arch & API, and also the examples in Implementation. If you only want to use the API, you could start with API, and just a skim of Arch.

Thanks for pointing out that the “independent utility” point I made cuts both ways. This indicates to me that both documents should be treated as normative (PS) within their own scope, on which more below.

> Last, I do see that if we think people will read the word "Architcture" and think of a particular type of document, then that might not be the best choice of word for the title. So, I'm OK with changing that, and suggest the simplest could be omitting the word "Architecture", leaving something like "The Transport Services System", or whatever, - confusion by title is the worst outcome!

FWIW if we’re wordsmithing the title I would be... okay with this, in a pinch, if perhaps a bit saddened that we’ve decided to pretend that prescriptive architecture is useful/dominant enough that we feel we need make the change. But it’s the content of the document that matters, not the color of the wrapper it comes in.

also: it's been pointed out that my last point about “labels” was perhaps a bit ambiguous: what I meant to say is I have a preference for not stuffing “requirements” into the title, but that it doesn’t really matter (cf. “color of the wrapper”). 

It could have also been taken to mean I have a preference for leaving this PS as opposed to informational with downref as opposed to informational with more editing work to move the normative bits into interface. This is also true, but was not what I intended to say. IMO re-editing the boundary between the documents at this point seems to be a negative-net-value exercise, but while I have a preference for not relitigating the deliberation the WG put into this, it also doesn’t really matter if this is informational with a downref.

> P.S. Thanks everbody for comments - we're working through these and solutions for most will soon be realised in the github, this was valuable (I also revisited some earlier area reviews - and we'll also confirm these were correctly resolved in the latest revision). 

+1 to this as well!

Cheers,

Brian

> 
> On 05/09/2023 10:11, Brian Trammell (IETF) wrote:
>> Hi, all,
>> 
>> +1 to everything said in this thread by TAPS folks (and +2 thanks to Michael for the history).
>> 
>> IMO there’s a pattern of confusion in this discussion between *prescriptive* and *descriptive* architecture, which I’ve seen before, as the term “architecture” has been AIUI used in the IETF space without qualification for both purposes.
>> 
>> Prescriptive architecture: “Here are the boxes and lines you *need to have*, implementations with missing, extra, or otherwise-defined boxes are noncompliant”. These architectures are generally requirements with a different label on them (“REQUIREMENTS and architecture”, if you will). Obviously, in the absence of protocol compliance officers, prescriptive architectures are only “enforceable” in the extent to which the underlying protocols are defined with a strong assumption s.t. any violation of said boxes leads to interoperability problems or violations of security properties.
>> 
>> Descriptive architecture: “We have defined a protocol or set of protocols which foresees a potential division of responsibility between and/or within protocol actors. This architecture serves to provide a basic terminology such that the concepts in the protocol are understandable and implementable”. 
>> 
>> The TAPS architecture is of the latter form, or is at least (emphatically) intended to be; indeed, I don’t think it’s worth the time to write prescriptive arch documents in a world where the implementors don’t sit in your reporting chain. To the extent that descriptive architectures impose requirements, they are requirements that are (implicitly) imposed by the interface definition *anyway*. IIRC we did consider such a split (informational architecture, normative interface) but thought it would be less readable and understandable, as you couldn’t really stack one on top of the other neatly.
>> 
>> As for the label we stick on the document, as Mirja says I don’t think it matters much, but since the main point of the (descriptive) arch document is (descriptive) arch, I have a slight preference to leave it as is.
>> 
>> I’ll note that the architecture and interface documents have independent utility, in that there is value in a transport service layer designer/implementor reading and adopting the TAPS architecture *without* hewing to the letter of the interface document, as one (and perhaps, “the whole”) point of the TAPS effort is to change the “shape" of the application-transport interface to allow transport/internet layer implementations at the endpoint more flexibility in the fulfillment of application intent given the present and future world of transport innovation opened by e.g. QUIC. 
>> 
>> Cheers,
>> 
>> Brian
>> 
>>> On 4 Sep 2023, at 23:04, Aaron Falk <[e-mail]> <mailto:[e-mail]> wrote:
>>> 
>>> I don't have too much to add beyond Mirja's point.  The working group felt strongly that TAPS could not be correctly implemented without reading the architecture document.  Further https://www.ietf.org/standards/process/informational-vs-experimental/ says:
>>> 
>>>> An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.
>>> 
>>> Neither of which accurately describe the doc.  Like Mirja, I'm open to tweaking the title although I think something like  "An Architecture for Transport Services (Read This First)" would be more useful than adding the term "Requirements" but YMMV.
>>> 
>>> --aaron
>>> 
>>> On Mon, Sep 4, 2023 at 8:57 AM Mirja Kuehlewind <[e-mail] <mailto:[e-mail]>> wrote:
>>>> Hi Eric,
>>>> 
>>>>  
>>>> the use of normative language is separate from your discussion point (on intended status), right?
>>>> 
>>>>  
>>>> I just want to mention that there was also quite extensive discussion about this in the working group. And as you say correctly there are some requirements in this document, and we decided to use normative language to highlight that. So I don’t think simply just removing the normative language is providing anybody a service.
>>>> 
>>>>  
>>>> Therefore, I guess your question really is should this document be called “architecture and requirements”. I don’t have a strong opinion here but I also don’t think it would make the document any better. The main focus is on the architecture. Also note that these requirements are not requirements for the design of the API (as we often do for requirement doc in the IETF) but requirement for the deployment of this architecture. And therefore, fully in the scope of an architecture document (without explicitly stating this in the title).
>>>> 
>>>>  
>>>> Mirja
>>>> 
>>>>  
>>>>  
>>>>  
>>>> From: Zaheduzzaman Sarker <[e-mail] <mailto:[e-mail]>>
>>>> Date: Monday, 4. September 2023 at 17:25
>>>> To: "Eric Vyncke (evyncke)" <evyncke=[e-mail] <mailto:[e-mail]>>
>>>> Cc: Mirja Kuehlewind <[e-mail] <mailto:[e-mail]>>, Michael Welzl <[e-mail] <mailto:[e-mail]>>, The IESG <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>>> Subject: Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: (with DISCUSS and COMMENT)
>>>> 
>>>>  
>>>> Hi Eric,
>>>> 
>>>>  
>>>> Sure, lets discuss this during the telechat. In the mean time if you can provide more information on the exact separation and definition of architecture I-D vs requirements I-D, hopefully in some sort of documentation with consensus , that would be helpful.
>>>> 
>>>>  
>>>> //Zahed
>>>> 
>>>>  
>>>> On Mon, Sep 4, 2023 at 4:07 PM Eric Vyncke (evyncke) <evyncke=[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Let's have a chat (aka discussion) during the IESG telechat on Thursday with the AD (and authors/shepherd if they want to join). My own preference is to avoid normative language in an architecture I-D, else it becomes a 'requirements' I-D.
>>>> 
>>>>  
>>>> Regards,
>>>> 
>>>>  
>>>> -éric
>>>> 
>>>>  
>>>> From: Mirja Kuehlewind <[e-mail] <mailto:[e-mail]>>
>>>> Date: Monday, 4 September 2023 at 15:56
>>>> To: Michael Welzl <[e-mail] <mailto:[e-mail]>>, Eric Vyncke <[e-mail] <mailto:[e-mail]>>
>>>> Cc: The IESG <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>>> Subject: Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: (with DISCUSS and COMMENT)
>>>> 
>>>>  
>>>> Hi Eric,
>>>> 
>>>>  
>>>> Michael, thanks for digging up the minutes.
>>>> 
>>>>  
>>>> In my memory I think there was also at the end a strong sense in the room to have all doc the same intended status. In my view these docs really belong closely together and as an implementer you really need all three of them. The reason for the split up is maybe more a service for non-implementors. E.g. if you only want to understand the interface in order to use it, it’s probably enough if you read the arch and the API doc. If you only want to get a high-level idea what taps is, you might read only the arch doc.
>>>> 
>>>>  
>>>> Mirja
>>>> 
>>>>  
>>>>  
>>>>  
>>>> From: Taps <[e-mail] <mailto:[e-mail]>> on behalf of Michael Welzl <[e-mail] <mailto:[e-mail]>>
>>>> Date: Monday, 4. September 2023 at 10:19
>>>> To: Éric Vyncke <[e-mail] <mailto:[e-mail]>>
>>>> Cc: The IESG <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>>> Subject: Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: (with DISCUSS and COMMENT)
>>>> 
>>>>  
>>>> Dear Éric,
>>>> 
>>>>  
>>>> Many thanks for your thoughtful review!   Regarding the DISCUSS point, which is about the intended status of the architecture document:
>>>> 
>>>>  
>>>> First, my apologies. In my shepherd write-up, I wrote that “the charter” says that this is the intended status.  I believe I made a mistake here, by referring to the “Milestones” as a part of the “Charter”, since they appear on the same page. From the milestones, the planned status is clear:  https://datatracker.ietf.org/wg/taps/about/
>>>> 
>>>> Digging deeper, I managed to find the discussion that led to this decision. It’s here, right on the top (first meeting item):
>>>> 
>>>> https://datatracker.ietf.org/meeting/102/materials/minutes-102-taps-00
>>>> 
>>>>  
>>>> If I were to summarize this discussion, I would point out the following:
>>>> 
>>>>  
>>>> * there was a strong hum for Standards, and a light hum for Informational
>>>> 
>>>>  
>>>> * Pete Resnick’s statement is perhaps the clearest: "RFC 2026 allows Proposed Standards to be Technical Standards and Applicability statements. Proposed Standards are part of the Standards track. There is an expectation that you revise it. You can continue to make changes to it. Experimental are when you want to test something in a corner, not on the real internet. Informational is when we have not developed a protocol and we are not recommending it for something. This is Proposed Standard."
>>>> 
>>>>  
>>>> I hope this helps?
>>>> 
>>>>  
>>>> Cheers,
>>>> 
>>>> Michael
>>>> 
>>>>  
>>>> PS: JFYI, regarding your other comments - yours, and all others, become issues in our github:  https://github.com/ietf-tapswg/api-drafts/issues <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-2fc48301f7570c95&q=1&e=c189c75b-ab30-4b04-92a7-bd391b816384&u=https%3A%2F%2Fgithub.com%2Fietf-tapswg%2Fapi-drafts%2Fissues>  and we take it from there.
>>>> 
>>>>  
>>>>  
>>>> On 28 Aug 2023, at 12:47, Éric Vyncke via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>>  
>>>> Éric Vyncke has entered the following ballot position for
>>>> draft-ietf-taps-arch-18: Discuss
>>>> 
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
>>>> for more information about how to handle DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-taps-arch/
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> 
>>>> # Éric Vyncke, INT AD, comments for draft-ietf-taps-arch-18
>>>> 
>>>> Thank you for the work put into this *NEAT* document (private joke). It is easy
>>>> to read and is an important piece of work required to deploy new transports.
>>>> 
>>>> Please find below one blocking DISCUSS points (mainly to have a discussion, do
>>>> not worry too much), some non-blocking COMMENT points (but replies would be
>>>> appreciated even if only for my own education), and some nits.
>>>> 
>>>> Special thanks to Michael Welzl for the shepherd's detailed write-up including
>>>> the WG consensus and the justification of the intended status *even* if I
>>>> disagree with the intended status (see below my DISCUSS point).
>>>> 
>>>> Other thanks to Bernie Volz, the Internet directorate reviewer (at my request),
>>>> please consider this int-dir review:
>>>> https://datatracker.ietf.org/doc/review-ietf-taps-arch-18-intdir-telechat-volz-2023-08-25/
>>>> (minor nits)
>>>> 
>>>> I hope that this review helps to improve the document,
>>>> 
>>>> Regards,
>>>> 
>>>> -éric
>>>> 
>>>> # DISCUSS
>>>> 
>>>> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
>>>> DISCUSS ballot is a request to have a *discussion* on the following topics:
>>>> 
>>>> ## Intended status
>>>> 
>>>> This is only to have a public discussion (over email before the telechat or
>>>> during the IESG telechat), I intend to ballot either NoObj or Yes after this
>>>> discussion. The shepherd's write-up writes that the intended status is
>>>> "proposed standard" per TAPS WG charter and I do not see anything related to an
>>>> architecture document in the charter and even less about its intended status.
>>>> Moreover, most IETF architecture documents are 'informational'.
>>>> 
>>>> See also my comments about section 3.1
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> 
>>>> # COMMENTS
>>>> 
>>>> ## Anycast address
>>>> 
>>>> This document differentiates between unicast and multicast addresses, but
>>>> should there be a specific case of anycast addresses ?
>>>> 
>>>> ## Section 1.4
>>>> 
>>>> I am not a transport expert but I would have included the transport protocol in
>>>> `Socket: The combination of a destination IP address and a destination port
>>>> number [RFC8303].`
>>>> 
>>>> ## Section 2
>>>> 
>>>> Should 'DNS' be included in `system-provided stub resolver` ?
>>>> 
>>>> Figure 1 & 2 are nice but, please, add a references to them in the text.
>>>> 
>>>> In `it describes how implementations can use multiple IP addresses` isn't it
>>>> hidden usually to the application ?
>>>> 
>>>> ## Section 2.3
>>>> 
>>>> In `The Socket API for protocols like TCP is generally limited to connecting to
>>>> a single address over a single interface.` should there be a mention of one or
>>>> several 'source' IP addresses ? Should 'address' be qualified by 'IP' (as
>>>> opposed to a DNS name or "Internet address" aka URL)?
>>>> 
>>>> ## Section 2.4
>>>> 
>>>> How can a (nice) informational RFC 8170 "requires" in `incremental
>>>> deployability [RFC8170] requires coexistence`. Suggest to use "recommend" or
>>>> something similar to avoid confusion.
>>>> 
>>>> ## Section 3.1
>>>> 
>>>> The presence of normative BCP14 terms ("SHOULD", ...) in an architecture
>>>> document looks weird to me (see my DISCUSS point above). Is this document an
>>>> 'architecture' document or an 'architecture and requirements' one ?
>>>> 
>>>> ## Section 3.3
>>>> 
>>>> What is the exact meaning of 'safely' in `Equivalent Protocol Stacks can be
>>>> safely swapped or raced in parallel` ?
>>>> 
>>>> ## Section 4.1
>>>> 
>>>> s/Establishment (Section 4.1.4) focuses on the *actions* that an application
>>>> *takes on* the connection objects/Establishment (Section 4.1.4) focuses on the
>>>> *requests* that an application *sets to* the connection objects/ as it is not
>>>> really the application doing those actions ?
>>>> 
>>>> ## Section 4.1.1
>>>> 
>>>> Please state the obvious: a multicast endpoint can only be a destination
>>>> endpoint.
>>>> 
>>>> ## Section 4.1.3
>>>> 
>>>> Do the security parameters include DNS resolution security parameters ? E.g.,
>>>> mandatory use of DNSSEC or DoH?
>>>> 
>>>> ## Section 4.1.5
>>>> 
>>>> Unsure whether the sentence `Messages are sent in the payload of IP packet` is
>>>> really useful. Suggest to remove it.
>>>> 
>>>> ## Section 4.2.2
>>>> 
>>>> Suggest to mention RFC 7556 in the discussion about different local addresses
>>>> (interfaces?) and DNS resolvers.
>>>> 
>>>> # NITS
>>>> 
>>>> ## Section 2
>>>> 
>>>> Is a capitalised "Connections" required in `the interface for an application to
>>>> create Connections and transfer data` ? Or should there be a text in the
>>>> glossary section about the use of capitalised terms ?
>>>> 
>>>> ## Section 2.1
>>>> 
>>>> s/all interaction using the Transport Services API is expected to be
>>>> asynchronous/all interactionS using the Transport Services API ARE expected to
>>>> be asynchronous/ ?
>>>> 
>>>>  
>>> _______________________________________________
>>> Taps mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/taps
>> 
>> 
>> 
>> _______________________________________________
>> Taps mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/taps
>