On 14/03/2023 10:24, Mirja Kuehlewind wrote:
Hi all,
first thanks for all the work!
I reviewed the diffs below and actually have two questions on normative
language, not on the content but on the use of normative language.
In the arch doc, it's this sentence here
" An application SHOULD NOT depend on
specific caching behaviour, instead it ought to
explicitly request
any required or desired properties via the Transport
Services API."
I don't disagree with this sentence but use of normative language seems a bit awkward. I
would recommend to either use lower case should or maybe say "SHOULD NOT rely
on" instead because that seem more like an active choice.
I'm unsure that I precisely understand the diference between /rely upon/
and /depend upon/, in this sentence I'd be happy either with either word
- "rely" would be fine for me.
For interface we have this sentence:
"An Endpoint MUST NOT be configured with multiple identifiers of the
That is, an endpoint cannot have two IP addresses specified. Two
same type."
However, this is not a requirement but a matter of fact. This is how we in this
document define an endpoint - it can only have one identifier. I missed this
change on github but I don't think it's correct.
I think (if I understand your argument) that you say a design will
prevent this because that is how we define Endpoint. I'd agree a design
of system cannot allow this, but then thenis it any better to state the
design requirement as "The design of the API MUST NOT permit an Endpoint
to set multiple identifiers of the same type."
Gorry
Mirja
On 10.03.23, 12:54, "Taps on behalf of Michael Welzl"<taps-boun...@ietf.org on
behalf of mich...@ifi.uio.no> wrote:
Hi,
FWIW, I agree with all of these changes.
I’m an author of the second and third document, so for these it is
obvious, but I’m not an author of the first one.
Cheers,
Michael
> On 10 Mar 2023, at 01:26, Reese Enghardt<i...@tenghardt.net> wrote:
>
> Dear TAPS,
>
> As you may have seen, our three documents were updated to address
Zahed's AD review comments (Thank you to everyone involved!).
>
> Please note that there were normative language changes in the Interface
document.
>
> If you have any questions about or any objections to these changes,
please respond to the list within the next two weeks, i.e., by Thursday March
23rd, 5pm PT. (This is Thursday before IETF 116.)
>
> If we don't hear anything by this date, we will assume that there is WG
consensus on these changes.
>
> For your convenience, here are the diffs for all three documents:
>
>
>https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-arch-16
>
>https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-interface-19
>
>https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-impl-15
>
>
> Best,
> Reese
>
>
> On 3/9/23 10:01,internet-dra...@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>> This Internet-Draft is a work item of the Transport Services WG of the
IETF.
>>
>> Title : An Abstract Application Layer Interface to
Transport Services
>> Authors : Brian Trammell
>> Michael Welzl
>> Theresa Enghardt
>> Godred Fairhurst
>> Mirja Kuehlewind
>> Colin Perkins
>> Philipp S. Tiesel
>> Tommy Pauly
>> Filename : draft-ietf-taps-interface-19.txt
>> Pages : 91
>> Date : 2023-03-09
>>
>> Abstract:
>> This document describes an abstract application programming
>> interface, API, to the transport layer that enables the selection of
>> transport protocols and network paths dynamically at runtime. This
>> API enables faster deployment of new protocols and protocol features
>> without requiring changes to the applications. The specified API
>> follows the Transport Services architecture by providing
>> asynchronous, atomic transmission of messages. It is intended to
>> replace the BSD sockets API as the common interface to the transport
>> layer, in an environment where endpoints could select from multiple
>> interfaces and potential transport protocols.
>>
>>
>> The IETF datatracker status page for this Internet-Draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-taps-interface/
>>
>> There is also an HTML version available at:
>>https://www.ietf.org/archive/id/draft-ietf-taps-interface-19.html
>>
>> A diff from the previous version is available at:
>>https://author-tools.ietf.org/iddiff?url2=draft-ietf-taps-interface-19
>>
>>
>> Internet-Drafts are also available by rsync at
rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> Taps mailing list
>>Taps@ietf.org
>>https://www.ietf.org/mailman/listinfo/taps
>>
>
> _______________________________________________
> Taps mailing list
>Taps@ietf.org
>https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
