Hello Mike,
> this is the only location outside of Clause 12
No, as I say in the discussion it's also used in 11.23.4:
11.23.4 Service hash procedure
A service hash is generated from a service name after all single octet uppercase alphabetic characters in
the service name are converted into corresponding lowercase characters. A service name is defined in
IETF RFC 6335.
A service hash contained in the Service Hash subfield of the Service Hash element, or in the Service
Information Request ANQP-element, or in the Service Information Response ANQP-element, or a service hash
used to map into the Bloom Filter Bit Array is generated as follows:
service hash = L(SHA-256(service name), 0, 48)
For example, a service hash for the service name of “_ipp._tcp” is created as follows: The service hash
contained in the Service Hash subfield of the Service Hash element, the Service Information Request ANQP-
element, and the Service Information Response ANQP-element is “bfd39037d25c,” and the service hash used
as input to compute the Bloom Filter Bit Array field is “0xbfd39037d25c.”.
> Given that after its definition in 1.5, this is the first use of the L() function, I don't see a problem in including the reference to clause 1.5 at that location.
So I think you're arguing that the first time a function defined in
Clause 1 is used, a xref needs to be given? (Maybe you're going by
analogy with the principle that the first time an abbreviation is
used the expansion must be used too?). In that case:
1) We need to move the xref from 11.45.4 to 11.23.4.
2) We need xrefs for the first use of all the other functions defined
in Clause 1 (as I said, the reference to 1.5 in 11.45.4 is the only
reference to 1.5 in the entire document), e.g.:
From 1.5:
Floor
Ceil
Round
log2, log10, ln
Re
Im
Truncate-N
exp
int
bin[]
From 1.4:
[HMAC-]SHA-<1,256,384>[-n]
Is that the direction, then?
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Friday, 1 October 2021 19:15
To: Mark Rison <m.rison@xxxxxxxxxxx>; stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Cc: Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>; nehru.bhandaru@xxxxxxxxxxxx; mark.hamilton2152@xxxxxxxxx
Subject: Re: 11me/D0.0 CID 324 (L())
Hi Mark,
Not speaking as REVme Chair, I have an opinion on this CID. Given that after its definition in 1.5, this is the first use of the L() function, I don't see a problem in including the reference to clause 1.5 at that location. Also, this is the only location outside of Clause 12 where this function is used extensively and readers are more likely familiar with what is going on.
I have no issues with the change of SHA256 to SHA-256.
Cheers,
Mike
On Fri, Oct 1, 2021 at 12:39 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Hello,
I've come up with the following resolution for CID 324. Is it acceptable
to you?
Identifiers
Comment
Proposed change
CID 324
Mark RISON
11.45.4
2503.39
"L is defined in 1.5 (Terminology for mathematical, logical, and bit operations)" is not needed (not used elsewhere)
Delete the cited line
Discussion:
There is no need to refer back to Subclause 1.5 for operators etc. defined there, and indeed we don’t do so anywhere else in the draft. The whole point of Subclause 1.5 is to have operators etc. used all over the spec in one place, so we don’t have to keep cross-referencing to their definition.
There is nothing special about the use of L() in 11.45.4. It’s not even special in that it’s a use outside Clause 12 (where L() is most prevalent) as there is a non-xreffed use in 11.23.4. We really don’t need the spec to have unnecessary and haphazard xrefs like this.
Ironically, though, 11.45.4 does invoke a function SHA256 which is (a) not xreffed and (b) non-existent (the function name, as described in Subclause 1.4, has a hyphen).
Proposed resolution:
REVISED
Delete the cited line (~2503.39) as proposed and additionally change “SHA256” to “SHA-256” at 2503.35.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk