Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)

As a note, we just pushed draft-ietf-taps-interface-24 to address the SHOULD->MUST.

Thanks,
Tommy

> On Dec 14, 2023, at 8:22 AM, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
> 
> 
> 
> 
>> On Dec 14, 2023, at 6:27 AM, Lars Eggert <lars@eggert.org> wrote:
>> 
>> Hi,
>> 
>> On Dec 14, 2023, at 16:13, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>>>>>> 
>>>>>> 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.
>>>> 
>>>> OK, but where in the example does it set that the default it TCP/TLS? The only thing specified for the "default" is port 443 - is something inferring TCP/TLS based on the port?
>>> 
>>> The default isn’t explicitly set to TCP/TLS there—it’s the endpoint address/host/port details that are set as default. So it’s saying “use this default endpoint for any protocol that’s used, except if quic is chosen because I know it uses a different port”. Theoretically if the stack could choose TLS/TCP, QUIC, and something else like SCTP, that default would apply to everything other than QUIC.
>> 
>> so *any* protocol other than QUIC would be OK on port 443? SCTP, DCCP, TCP with TLS and without?
> 
> Of the protocols that could be automatically selected, yes. However, there would not be a case where you’d be using TCP with and without TLS for one connection — the requirements for a transport security protocol aren’t optional or added or removed like that.
> 
> The most common case here is that there isn’t any protocol override, and you’re accessing the same endpoint that might be over TLS+TCP or QUIC. Note that the stack itself can learn about different ports from SVCB records, etc, as it discovers alternative transports/ALPNs as well. This is exactly what we’ve been doing in our Network.framework and it has not been a problem for developers in practice.
> 
> Thanks,
> Tommy
> 
>> 
>> This exchange - which we don't need to continue, I think we're beyond the point where progress is being made - reinforces my belief that either I don't understand something fundamental about TAPS, or it's simply not really making the developer experience clearer or easier.
>> 
>> Thanks,
>> Lars
>> 
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org <mailto:Taps@ietf.org>
> https://www.ietf.org/mailman/listinfo/taps