Re: [Taps] Normative language change in the Interface document (Re: I-D Action: draft-ietf-taps-interface-19.txt)

[Gorry Fairhurst <[e-mail]>]

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"<[e-mail] on behalf of [e-mail]>  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<[e-mail]>  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,[e-mail]  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
>      >>[e-mail]
>      >>https://www.ietf.org/mailman/listinfo/taps
>      >>
>      >
>      > _______________________________________________
>      > Taps mailing list
>      >[e-mail]
>      >https://www.ietf.org/mailman/listinfo/taps
>
>      _______________________________________________
>      Taps mailing list
>      [e-mail]
>      https://www.ietf.org/mailman/listinfo/taps
>
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps