> On Dec 12, 2023, at 6:48 PM, Tommy Pauly <[email protected]> wrote: > > Hi Lars, > > Responses inline. > > >> On Dec 12, 2023, at 3:38 AM, Lars Eggert <[email protected]> wrote: >> >> Hi, >> >> thanks for the replies. I'll trim my response to only those items where I >> still have questions. >> >> On Nov 14, 2023, at 19:17, Tommy Pauly <[email protected]> >> wrote: >>>> On Sep 7, 2023, at 3:59 AM, Lars Eggert via Datatracker <[email protected]> >>>> wrote: >>>> ### 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.” >> >> why is this not a MUST, i.e., when would it be appropriate to not specify >> this in an IETF-stream RFC? > > Yeah, I think this could be a MUST. > > Brian, Michael, what do you think?
I dug into the issues and found this: https://github.com/ietf-tapswg/api-drafts/issues/1330 <https://github.com/ietf-tapswg/api-drafts/issues/1330> where we have closed this as “overtaken by events” - so I struggle to find the discussion that led to the specific sentence that was added. I believe we just left the SHOULD as it was, and fixed this to refer to "the RFC series after IETF review". History and github issues aside, I completely agree, a MUST would make more sense here. Let’s do this. Cheers, Michael > >> >>>> ### 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. >> >> How would a developer know what the default endpoint was? > > The “default” endpoint is the one that the application developer themselves > provided that didn’t include a protocol-specific binding. In the example > above, that’s the port 443 endpoint, while there’s a protocol-bound endpoint > that uses port 8443. > >> >>>> ### 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." >> >> I'd argue that "safer" is in the eye of the beholder. I'll certainly agree >> that TAPS is trying to provide a more principled and more abstract interface >> to transport functions (also also that the socket API's >> platform-dependendness is terrible), but at least a developer with >> sufficient motivation can concretely implement their desired behavior. I >> remain unconvinced that an abstraction like TAPS will lead to a stable >> developer experience esp. over time and across platforms. > > It’s certainly fair to have a different opinion on how the usefulness and > stableness of various transport/socket options will play out over time. > > Personally, I think the best philosophy for setting options on a connection / > socket should be to set the minimum set required, so as to not unnecessarily > constrain the behavior of the stack. If an application sets many options that > can eventually only be satisfied by a set of existing protocols, and not some > future as-yet-undesigned protocols, then indeed the connections will be > constrained to use the existing protocols that work. But apps that only set > the options they strictly need will allow for more variation. > > Are there specific changes you are thinking of for the document? > >> >> Thanks, >> Lars >> > > > Thanks, > Tommy >> >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
