Seongho, comments inline |
On Wed, Mar 4, 2026 at 4:57 PM 변성호 <sh.byeon@xxxxxxxxxxx> wrote:
There are some complications in the timeout calculation regarding RXTIME. There are a couple of other CIDs and at least one other document surrounding this issue, so, there will be some other modifications for this paragraph. So the issue will remain open. Do not consider the text in 319r4/r5 to be the final version. [shb] Of course! Without knowing what discussions are going on, I can only assume what I see is final :)
Sure - changed to revised in the next revision. [shb] Thanks!
I would not call it a problem of consistency or a conflict. A STA that does not follow the recommendation will end up with a failed transmission. So enforcement through a "shall" is not really required. There are a number of members who prefer to keep it as a should because there are implementations which prepare a PPDU to fit into an expected TXOP duration. If the final available time for the TXOP does not meet those expectations, then those designs are not necessarily capable of modifying the PPDU parameters in time to fit the PPDU into the time that is available. So there are objections to changing the language. [shb] All good. I agree that aligning the PPDU duration exactly to the remaining NPCA_TIMER in practice will be challenging. However, we have a Jekyll and Hyde: 1) loosely permits STAs to transmit beyond the NPCA_TIMER (though I acknowledge it will ultimately fail), AND 2) mandates STAs to return to the BSS primary channel upon NPCA_TIMER expiration.
|
--
Matthew Fischer
