Jay,
Thanks for the rule dump. I’ll note the excerpt “IEEE 802 prefers that this be avoided if at all possible.” Can we avoid this? Yes, we absolutely can.
It says that it is inappropriate to use an I-D as reference material and that is EXACTLY what you’re doing. You’re not citing it as a work in progress, you’re using it directly as reference material because you’re including URLs to an I-D in your submission! What is inappropriate is this from11-26/1203r4:
It’s a URL! This is not citing it as a work in progress. You’re referring, directly and normatively, to an I-D, it is reference material. That is exactly what is deemed inappropriate. And while you say “/02”, the URL you’re pointing to, if anyone bothered to click on it, is actually the -01 version. To make this even worse, there is no 8.2.1 in the -01 version of this I-D that you’re pointing to* so this section in your submission is not coherent. Anyone who tried to follow the URL you provide would be presented with something that didn’t exist—“follow the equations in section 8.2.1 of this Internet-Draft that doesn’t have an 8.2.1 section.”
This is not “a dated, versioned reference” as you try to portray it.
Furthermore, this URL is already old! The current version is -03 and you’re referring to -01. So what do you propose? Constantly updating the TGbt draft to inappropriately refer to a URL and have the URL change as the I-D changes? And hope that nothing changes in the URL-referenced document to break things in the TGbt draft? Well sorry, your submission has already been broken (assuming it could be updated to point to -03) because the + version of the protocol behaves differently than the non-+ version in the response so your 12.17.6.2.3.2 doesn’t work using the (inappropriate) reference.
Can you give any example of this sort of thing—a URL being inserted into a proposed amendment to the IEEE 802.11 standard to specify normative behavior—being done in any other TG in 802.11?
As someone who implements 802.11 standards I can tell you this is not a realistic method of spec development. It would mean nothing could be implemented for at least 3 and probably more like 4+ years because there’s no way to implement to a moving target. We cannot wait 4+ years to have an implementable PAKE in TGbt.
You said my proposed model is “not a wise approach” but I described exactly how it works in practice and it works great. Our standard is not suffering today for practicing this model in the past. If you would like to criticize the model of spec development I’m proposing then please directly address it as I have addressed your proposal for spec development.
Dan.
* I know you’re gonna try and fix this in an update to 11-26/1203 before the Bangkok meeting (after I pointed the problem out to you here) but it won’t matter because it illustrates the problem with the scheme you are proposing. It’s broken. It doesn’t work. It’s not sustainable.
--
“the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane.” – Marcus Aurelius
Hi Dan,
Thanks for the response.
Seems there is some misunderstanding on the I-D boilerplate:
The boilerplate says it is inappropriate to cite a draft other than as work in progress. Citing it as work in progress — which is exactly what a dated, versioned reference does — is not prohibited by that text; it is the only use the boilerplate contemplates.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
Also, according to the the Cross-Referencing rule(see highlight part below) between IETF and IEEE 802 defined in RFC 7241, it's allowed to reference non-expired ID by IEEE 802. Correct?
Welcome your further insights, and feel free to correct me if I make any mistake.
3.4 Cross-Referencing
IETF and IEEE 802 each recognize the standards defined by the other
organization. Standards produced by each organization can be used as
references in standards produced by the other organization.
IETF specifications may reference IEEE 802 work in progress, but
these references should be labeled "Work in Progress". If the
references are normative, this will block publication of the
referring specification until the reference is available in a stable
form.
IEEE 802 standards may normatively reference non-expired Internet-
Drafts, but IEEE 802 prefers that this be avoided if at all possible.
Informative references in IEEE 802 standards are placed in a
bibliography, so they may point to either approved IETF standards or
IETF Internet-Drafts, if necessary.
When an IEEE 802 standard is revised, it normally retains the same
number and the date is updated. Therefore, IEEE 802 standards are
dated with the year of approval, e.g., IEEE Std 802.1Q(TM)-2011.
There are two ways of referencing IEEE 802 standards: undated and
dated references. IEEE 802 practice allows undated reference to be
used when referencing a whole standard. An undated reference
indicates that the most recent version of the standard should be
used. A dated reference refers to a specific revision of an IEEE 802
standard. Since clauses, subclauses, tables, figures, etc., may beDawkins, et al. Informational [Page 15]
RFC 7241 IEEE 802/IETF Relationship July 2014
renumbered when a standard is revised, a dated reference should be
used when citing specific items in a standard.
IETF standards may be cited by RFC number, which would also be a
dated reference. If an undated reference to an IETF Internet
Standard is desired, a number is also assigned in the "STD" series
[BCP9], and these references refer to the most recent version of an
IETF Internet Standard.
Thanks
Best Regards
Jay Yang (杨志杰)
Original
From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>;
Date: 2026年10月28日 01:39
Subject: Re: [STDS-802-11-TGBT] Fw: IEEE 802.11 liaison communication to IRTF regarding draft-vos-cfrg-pqpake
Hi Jay,
I would like to focus on just this one paragraph of yours:
The key point is that the PQC PAKE protocol is merely a tool for 802.11. Why should we duplicate the entire protocol into the 802.11 draft? In the event that a security issue arises within the Wi-Fi industry, who would be responsible for addressing it? Since the authors are part of CFRG, not 802.11, it is not a wise approach.
I’m not sure what you mean by “merely a tool” and I don’t follow how that means we shouldn’t duplicate the protocol in the TGbt draft. I have been maintaining that the CFRG draft describes a tool—in fact several tools—and not a protocol with on the wire (or over the air) specification. Therefore we can, and should, take as much of that draft as possible and incorporate it into our draft (that has over the air specification) so that we have something implementable.
I will tell you why we should not refer to the draft. First of all, the I-D itself says in its boilerplate “It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ‘work in progress.’” So it is inappropriate to refer to drafts. We need to duplicate the parts of the draft we want if we don’t want to wait 4 years to have an implementable 802.11 PQC PAKE. If we were to ignore that and refer to the draft anyway, it would not be implementable because that draft, as we have seen, is a moving target. It would not be possible to implement the TGbt draft if the draft just points to a moving target. I maintain it would be wrong for the group to not have anything implementable for 4 years, especially since we have told 2 external organizations that we’re working on a PQC PAKE. Therefore, we need something solid in the TGbt draft that can be implemented and we need it ASAP, not in 4 years.
Regarding what happens if “a security issue arises within the Wi-Fi industry”. Well, the Wi-Fi industry, by whatever definition you use, should handle it. If someone in the CFRG identifies a flaw or an issue in the CFRG draft (or even in an RFC) then the Wi-Fi industry should look at the issue, see if it applies to what we have and if so, address it in the recommended manner. There is precedence for this! Let me give you a little 802.11 history:
SAE proposed a rejection sampling method method of PWE computation (euphemistically called “hunting-and-pecking”) because the alternative, Icart’s method, was patented. In 2019, the Dragonblood attack showed that hunting-and-pecking was flawed. It could be done in constant time but it was fragile and wasteful and just about every implementation did it wrong. Serendipitously, around that time an unpatented way of hashing to an elliptic curve was being proposed in… guess where… the CFRG. But it was a draft and it was inappropriate to just refer to it. We needed something in the standard that was implementable. The draft discussed several ways to hash to a curve for different types of elliptic curves. But we only supported a few curves—the NIST ones and the brainpool ones, all Weierstrass curves—so I copied a part of the CFRG draft that did the Simplified Shallue-Woestijne-Ulas (SSWU) method with Weierstrass curves which became 11-19/1173. That eventually got put into the TGm draft. SSWU uses a constant, z, which I calculated, and it became table 12-2 “Unique Curve Parameter”. After some time, someone on the CFRG list pointed out that the formula to calculate z might be patented. So the CFRG draft changed to come up with a different formula to calculate z. So guess what we had to do? Change the formula in the the TGm draft! So I wrote 11-19/1817 which changed the formula and generated new values for z. And that’s what we have today. A copied subset of what ended up becoming an RFC. Our standard diverges from the RFC but it doesn’t matter because what we have is secure and it works and it is not patented. When an issue arose with the CFRG draft we addressed it ourselves.
This model works and we should do it in TGbt. We should take the parts of draft-vos that we need and specify a PQC PAKE in the TGbt draft. If any issue arises in draft-vos (or draft-irtf-cfrg-whatevernameitbecomes) we should analyze the issue, and if it is applicable to what is in the TGbt draft we should change the TGbt draft in the manner recommended by those who came up with the issue. This is not a problem. It works and it is a wise approach.
Regards,
Dan.
--
“the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane.” – Marcus Aurelius
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1