On 4 Sep 2023, at 23:04, Aaron Falk <aaron.f...@gmail.com> 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
<mirja.kuehlew...@ericsson.com> 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 <zahed.sarker.i...@gmail.com>
*Date: *Monday, 4. September 2023 at 17:25
*To: *"Eric Vyncke (evyncke)" <evyncke=40cisco....@dmarc.ietf.org>
*Cc: *Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>, Michael
Welzl <mich...@ifi.uio.no>, The IESG <i...@ietf.org>,
"draft-ietf-taps-a...@ietf.org" <draft-ietf-taps-a...@ietf.org>,
"taps-cha...@ietf.org" <taps-cha...@ietf.org>, "taps@ietf.org"
<taps@ietf.org>, "bev...@gmail.com" <bev...@gmail.com>
*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=40cisco....@dmarc.ietf.org> 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 <mirja.kuehlew...@ericsson.com>
*Date: *Monday, 4 September 2023 at 15:56
*To: *Michael Welzl <mich...@ifi.uio.no>, Eric Vyncke
<evyn...@cisco.com>
*Cc: *The IESG <i...@ietf.org>,
"draft-ietf-taps-a...@ietf.org"
<draft-ietf-taps-a...@ietf.org>, "taps-cha...@ietf.org"
<taps-cha...@ietf.org>, "taps@ietf.org" <taps@ietf.org>,
"bev...@gmail.com" <bev...@gmail.com>
*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 <taps-boun...@ietf.org> on behalf of Michael
Welzl <mich...@ifi.uio.no>
*Date: *Monday, 4. September 2023 at 10:19
*To: *Éric Vyncke <evyn...@cisco.com>
*Cc: *The IESG <i...@ietf.org>,
"draft-ietf-taps-a...@ietf.org"
<draft-ietf-taps-a...@ietf.org>, "taps-cha...@ietf.org"
<taps-cha...@ietf.org>, "taps@ietf.org" <taps@ietf.org>,
"bev...@gmail.com" <bev...@gmail.com>
*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
<nore...@ietf.org> 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
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
