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

[Zaheduzzaman Sarker <[e-mail]>]

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]> 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]>
> *Date: *Monday, 4 September 2023 at 15:56
> *To: *Michael Welzl <[e-mail]>, Eric Vyncke <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]"
> <[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]> on behalf of Michael Welzl <
> [e-mail]>
> *Date: *Monday, 4. September 2023 at 10:19
> *To: *Éric Vyncke <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]"
> <[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]>
> 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/ ?
>
>
>