Re: [STDS-802-11-TGM] 11me/D0.0 CID 324 (L())

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hello Mike,

I am highly sceptical that anyone looking to understand what L() means

in 11.45.3 or Clause 12 will consult 11.23.4 Service hash procedure in the

course of doing so.

However, if we are to introduce a new editorial convention that

"uncommonly used function names" need to be cross-referenced the first

time they are used, I would suggest:

- Renaming L() to Slice(), so that it is as obvious as Truncate-N(),

obviating the call for a xref in 11.23.4

- Adding xrefs for int() and bin[], since these are rather uncommon

(the former doesn't convert a real to an int, and the latter, well,

it's just weird)

- We consider whether we need to xref the first use of HMAC-SHA-*-n,

since I'm not sure how "commonly used" this is

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 21:47
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>; Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>; nehru.bhandaru@xxxxxxxxxxxx; mark.hamilton2152@xxxxxxxxx
Subject: Re: 11me/D0.0 CID 324 (L())

Hey Mark,

Sorry, I missed that reference in my search through the draft. So yes, we could move the reference from 11.45.3 to 11.23.4.

I see L() as a different function from the others. The others are more commonly used function names. I see value in a cross-reference for this one, but not for the others quoted below.

Cheers,

Mike

On Fri, Oct 1, 2021 at 4:30 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1