Hi Lars, Thanks again for your review — just a quick reminder to please take a look at the updates, and let us know if there’s anything else that needs to be addressed to clear your DISCUSS.
Best, Tommy > On Nov 14, 2023, at 9:17 AM, Tommy Pauly <[email protected]> > wrote: > > Hi Lars, > > Thanks for your detailed review! The authors appreciate the helpful comments. > > The authors have just posted a -23 version that addresses the IESG comments, > including your DISCUSS. > https://www.ietf.org/archive/id/draft-ietf-taps-interface-23.html > > Below, I’ve added inline responses to each DISCUSS point. > > Best, > Tommy (on behalf of the authors) > >> On Sep 7, 2023, at 3:59 AM, Lars Eggert via Datatracker <[email protected]> >> wrote: >> >> Lars Eggert has entered the following ballot position for >> draft-ietf-taps-interface-22: 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-interface/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> # GEN AD review of draft-ietf-taps-interface-22 >> >> CC @larseggert >> >> Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) review >> (https://mailarchive.ietf.org/arch/msg/gen-art/Uohwi2MvOOwswMfkE5w4mt9IZKE). >> >> ## Discuss >> >> ### Section 4.1, paragraph 8 >> ``` >> * For IETF protocols, the name of a Protocol-specific Property >> SHOULD be specified in an IETF document published in the RFC >> Series. >> ``` >> For IETF protocols, i.e., protocols published on the IETF RFC stream, >> those names must IMO be also specified in IETF-stream RFCs. I see no >> reason to let other RFC streams make definitions for IETF protocols. > > This now reads: "For IETF protocols, the name of a Protocol-specific Property > SHOULD be specified in an IETF document published in the RFC Series after > IETF review.” > >> >> ### Section 6.1, paragraph 13 >> ``` >> * Interface name (string), e.g., to qualify link-local or multicast >> addresses (see Section 6.1.2 for details): >> >> LocalSpecifier.WithInterface("en0") >> ``` >> How does an application learn which interface name strings are >> allowed/available on the system? The API doesn't seem to provide this >> information. Also, based on the examples, there seem to be special >> names such as "any" - where are those defined and how are conflicts >> with names used on the system avoided? > > This is addressed with https://github.com/ietf-tapswg/api-drafts/pull/1456 > > This updates the text to allow the “Resolve” functionality for Rendezvous to > be used generically to enumerate interfaces/addresses. > >> >> ### Section 6.1.3, paragraph 6 >> ``` >> In order to scope an alias to a specific transport protocol, an >> Endpoint can specify a protocol identifier. >> >> AlternateRemoteSpecifier.WithProtocol(QUIC) >> ``` >> This is the first and only time protocol identifiers are used. What >> are they defined to be? > >> >> ### Section 6.1.3, paragraph 9 >> ``` >> The following example shows a case where example.com has a server >> running on port 443, with an alternate port of 8443 for QUIC. >> >> RemoteSpecifier := NewRemoteEndpoint() >> RemoteSpecifier.WithHostname("example.com") >> RemoteSpecifier.WithPort(443) >> >> QUICRemoteSpecifier := NewRemoteEndpoint() >> QUICRemoteSpecifier.WithHostname("example.com") >> QUICRemoteSpecifier.WithPort(8443) >> QUICRemoteSpecifier.WithProtocol(QUIC) >> >> RemoteSpecifier.AddAlias(QUICRemoteSpecifier) >> ``` >> Why does the `RemoteSpecifier` definition not contain a `WithProtocol` >> clause for TCP/TLS? And what would that look like, given that TCP/TLS >> is a protocol combination? > > These comments around protocol-specific endpoints are addressed with > https://github.com/ietf-tapswg/api-drafts/pull/1408 and > https://github.com/ietf-tapswg/api-drafts/pull/1451 > > The text now clarifies that the values for the protocol scoping here are > implementation-provided enumerations. > > "To scope an Endpoint to apply conditionally to a specific transport > protocol (such as defining an alternate port to use when QUIC > is selected, as opposed to TCP), an Endpoint can be > associated with a protocol identifier. Protocol identifiers are > objects or enumeration values provided by the Transport > Services API, which will vary based on which protocols are > implemented in a particular system." > > The reason to show one protocol being specified with an override is to show > how there’s a default endpoint that the connection should use, and it should > conditionally load an alternate when using a particular protocol. This then > doesn’t constrain the protocol stacks being used, but only customizes the > endpoint in case a particular protocol is loaded. > >> >> ### Section 6.2, paragraph 0 >> ``` >> 6.2. Specifying Transport Properties >> ``` >> This section defines a boatload of different properties, many of which >> are interacting with each other due to how our current transport >> protocols are implemented. Future interactions, due to future >> transport protocols potentially becoming available, are undefined. I >> question how a potential programmer is supposed to make informed >> choices here without needing to be aware of all of this >> background/baggage? > > Please see comments on https://github.com/ietf-tapswg/api-drafts/issues/1334 > > "Complex interactions may exist between socket options in the existing BSD > sockets API. > There are also implementations of TAPS systems available, at least one of > which is fairly comprehensive. > Future interactions of properties of future protocols are also unclear in the > BSD sockets API. > > In a sense, we offer a safer set of options than BSD sockets, as we have > constrained the generic ones to the set of properties that do not constrain > selection amongst existing protocols. Everything that is protocol-specific > goes in its own protocol namespace and only applies when this protocol is > selected. The intent is for future protocol-specific options to also be > categorized that way. We cannot guarantee that no future transport protocol > will somehow be constrained by our generic properties, but the analysis in > our prior RFCs (specifically the minset RFC) leads us to believe that we have > chosen a workable subset." > >> >> ### Section 8.1.5, paragraph 4 >> ``` >> Default: Weighted Fair Queueing (see Section 3.6 in [RFC8260]) >> >> This property specifies which scheduler should be used among >> Connections within a Connection Group, see Section 7.4. A set of >> schedulers is described in [RFC8260]. >> ``` >> What is this scheduler scheduling? 7.4 is silent on this. I'm guessing >> this is related to `connPriority`? > > Yes, thank you; we clarified this in the text by adding a reference to the > conn priority with https://github.com/ietf-tapswg/api-drafts/pull/1393 > >> >> ### Section 9.1.3, paragraph 9 >> ``` >> If a Message Property contradicts a Connection Property, and if this >> per-Message behavior can be supported, it overrides the Connection >> Property for the specific Message. For example, if reliability is >> set to Require and a protocol with configurable per-Message >> reliability is used, setting msgReliable to false for a particular >> Message will allow this Message to be sent without any reliability >> guarantees. Changing the msgReliable Message Property is only >> possible for Connections that were established enabling the Selection >> Property perMsgReliability. >> ``` >> How is this going to work in the opposite case, i.e., if an unreliable >> connection was set up and then some messages are passed in which >> require reliable transmission? At connection open, the stack may have >> chosen a transport protocol that cannot support reliable >> transmission? (Also, I think this general principle of message > >> connection has other issues for other properties.) > > This is addressed with https://github.com/ietf-tapswg/api-drafts/pull/1397, > which clarifies: > > "If the contradicting Message Property > cannot be supported by the Connection (such as requiring reliability > on a Connection that uses an unreliable protocol), the `Send` action > will result in a `SendError` event." >> > > _______________________________________________ > Taps mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
