Hi folks,

Attached is a git format-patch patch that contains a proposal for an S1G header.

This proposal was created by Aaron Lee and underwent a couple of
rounds of modifications among the WFA folks.

All I have done here is to transcribe it to the format required by the
documentation web site. Hopefully I have not changed any intent.

Below is some feedback from Johannes about the proposal so he does not
have to retype it along with some comments from me.

We should try to get this finalized as quickly as possible as quite a
bit of work is going on in this area.

Those who are interested in this topic should join the mailing list
because people may forget to reply-all!

> Channel field: This is a really old field, almost certainly somebody
> somewhere uses those bits they suggest already ... but I guess if
> wireshark doesn't parse them then that doesn't really matter, so I guess
> that'd be OK. I'd probably suggest using higher bits anyway, which are
> less likely to already be used.
>
> HALOW field: Mostly looks fine.
>
> I think the NDP indication (0x10 in data1) should probably be moved out
> into the 0-length psdu field we already have, so we don't need to handle
> special cases for it this in wireshark and other dissectors. The known
> bit for that (in known field) makes no sense anyway because clearly you
> have to know whether a packet was NDP or not. Unless I'm completely
> misunderstanding the meaning of this field.

The issue may be that an NDP actually carries non-MAC data. 25 bits in
the case of 1MHz NDPs and 37 bits in the case of 2MHz NDPs. If we can
shoehorn them into the 0-length-PSDU maybe we should.

> The "NSS" field is only 2 bits and can only capture values 0-3, not 1-4,
> so they probably mean the value inside is NSS-1, or NSS==field+1. Fine,
> but needs clarification.

Yeah. I unilaterally clarified that, so Aaron will have to look at it
and correct me if I am wrong.

> Aggregation bit isn't clear - don't they do things similarly to normal
> HT/VHT/HE A-MPDU and could re-use that field for aggregation? That can
> (optionally) also hold whether it was first/last and a cookie which
> frames belong together in an aggregation, so that's useful to have. IMHO
> should be moved to A-MPDU unless somebody can really explain why they
> need something special.
>
> And with that it easily fits into 2 u16 fields rather than 3 (actually
> it fits now even) so might be something to consider, though I don't
> really think space is much of a concern.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)