[tsvwg] Re: support last call for User Ports for Experiments

["[e-mail]" <[e-mail]>]

Yup - fixed. 

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jan 28, 2025, at 12:34 AM, Scharf, Michael <[e-mail]> wrote:
> 
> Thanks.
>  
> Note that there are two small nits in -04:
>  
> There is a missing reference in Section 4.
> The ToC is not correct (probably for the same reason).
>  
> Michael
>  
> From: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Sent: Tuesday, January 28, 2025 5:30 AM
> To: Scharf, Michael <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: Re: [tsvwg] support last call for User Ports for Experiments
>  
> HI, Michael,
>  
> Thanks for your comments - I addressed them just now in -04.
>  
> Note that I did find that both QUIC and TLS/DTLS have mechanisms for extension negotiation, just as would TCP, but that I felt it was outside the scope of the document to request such code points.
>  
> Joe
>  
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> On Aug 6, 2024, at 6:18 AM, Scharf, Michael <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi all,
> 
> I have read this document as well. Basically, I agree that it makes sense to have an "official solution" for experiments on user ports. Section 3 of the document looks good to me.
> 
> Regarding section 4, I wonder if some additional suggestions or examples could make sense to explain how PExIDs could be used. PExIDs are optional, and experiments may or may not be able to use it. But the document could possibly discuss a bit more how this mechanism could be used in typical cases. For instance:
> 
> - How PExIDs could be used if the TCP connection uses TLS. For instance, one potential alternative design would be to send PExIDs at the beginning of the application-byte-stream encrypted by TLS. Maybe there could also be ways to encode the PExID inside TLS (I am not a TLS expert). These potential alternatives may have downsides. But, for instance, maybe sending a PExID this way could be a better alternative to not sending a PExID at all?
> 
> - A similar question is if a PExID could be embedded somewhere in the application protocol itself, but not at the beginning (say, some optional application protocol option or the like). It means to achieve this would obviously be outside the scope of this document.
> 
> - Another similar questions may apply to QUIC.
> 
> Section 6 does not discuss security implications of PExIDs. Even if the document focuses on experiments, it could be reasonable to discuss potential security and/or privacy issues, such as:
> 
> - Whether PExIDs could be used by Deep Packet Inspection (DPI), e.g., to detect protocols, and whether that differs to port numbers.
> 
> - Whether implementing PExIDs has any impact on other security protocols. For instance, are there any implications whenf PExIDs are sent before a TLS handshake? This usage pattern may be similar to STARTTLS, so maybe it just works fine? Or not? Anyway, it could make sense to expand on that, even if implementations are not required to use PExIDs.
> 
> Best regards
> 
> Michael
> 
> 
> 
> -----Original Message-----
> From: Wesley Eddy <[e-mail] <mailto:[e-mail]>>
> Sent: Monday, August 5, 2024 4:05 PM
> To: [e-mail] <mailto:[e-mail]>
> Subject: [tsvwg] support last call for User Ports for Experiments
> 
> In the last meetings, the chairs asked for inputs on next steps for
> draft-ietf-tsvwg-usr-exp (User Ports for Experiments).
> 
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-usr-exp/
> 
> I've read this.  It is ready for working group last call, in my
> opinion.  It seems useful to me to progress this, based on experiences
> serving as an IANA ports reviewer.  I think it would likely make some of
> our responses to port applicants simpler, as well as give those
> applicants a clear direction forward, in cases where it makes sense.
>