Popping up because my name was invoked ("poof!")
On Sat, Feb 12, 2022 at 1:06 PM MORTON JR., AL <acmorton@xxxxxxx> wrote:
Hi Mirja, Thanks for your replies.
I replied below: some concerns with assumptions about operators in a doc for operators, and TCP-f-something (use a single term) is still unresolved...
<snip>
> 4.5. Filtering Behavior
>
> [RFC4787] describes possible packet filtering behaviors that relate
> to NATs but is often also used is other scenarios where packet
> filtering is desired. Though the guidance there holds, a
> particularly unwise behavior admits a handful of UDP packets and then
> makes a decision to whether or not filter later packets in the same
> connection. QUIC applications are encouraged to fail over to TCP if
> [acm]
> is "fail over" or "fallback" the preferred term?
> (using only one will help)
[acm]
Still need to pick-one here, and everywhere...
Spencer and others had some replies/follow-up comments here.
After discussion, Spencer's comment degenerated into "pick one".
I'm not speaking for others who replied/followed up on this, but I was thinking that it would be possible to use fairly precise terms to describe what the QUIC implementation was trying to do.
After reflecting on what other people said, I'm thinking that the precision I was hoping for won't be helpful for passive observers, and (for extra credit) would be even less helpful if/when we deploy https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ and a passive observer isn't seeing all of the paths in use. 😀
So I'm thinking that anything we agree on for this document may not survive the use of QUIC for new applications.
Do The Right Thing, of course.
Best,
Spencer
p.s. 😈 I can't wait for the day someone uses QUIC datagrams for an application that can rely on DCCP as its f******* protocol, and all the network operators are still looking for TCP traffic - but let's not even go there in this document! 😈
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
