Transferring Opportunistic Wireless Encryption to the IEEE 802.11 Working Group
draft-wkumari-rfc8110-to-ieee-02

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-wkumari-rfc8110-to-ieee and RFC 9672, changed IESG state to RFC Published)

[Ballot comment]
I assume the question of moving RFC 8110 to some appropriate “don’t use this, use that” status (Obsolete I guess) upon publication of the relevant IEEE spec has been considered by some combination of the authors, sponsoring AD, and extensive Last Call email discussion. In any case I don’t see why it would need to hold up publication of this document.

[Ballot comment]
I am always happy when opportunistic encryption is used instead of plaintext. I am glad the IEEE was convinced eventually to do this as well.

[Ballot comment]
To add to the ballot text: this draft is short but unusual as it transfers maintenance of an IETF protocol from IETF to IEEE. There are liaison statements in all directions and all parties (authors, IEEE 802.11, IETF trust, and probably the IETF community after the IETF Last Call) agree with the move.

This is somehow urgent as the IEEE is waiting for the IETF, hence the ballot on the day after the IETF Last Call. If there are critical Last Call comments, I am postponing the ballot.

Special note from the IETF Trust: "The authors of RFC8110 are Dan Harkins and Warren Kumari and are also involved in moving the maintenance of this protocol to the IEEE. As authors they hold a shared copyright with the IETF Trust and they both have the ability to give the IEEE the needed rights to use the RFC8110 material in future IEEE works without any approval from the IETF Trust." and later "The IETF Trust will continue in perpetuity to hold its currently held shared rights with the authors on RFC8110 which means that RFC8110 will remain available to the IETF to use and to create derivative works from along with everything else permitted by the TLP licensing terms."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-wkumari-rfc8110-to-ieee-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-09-04):

From: The IESG
To: IETF-Announce
CC: draft-wkumari-rfc8110-to-ieee@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Transferring Opportunistic Wireless Encryption to the IEEE 802.11 Working Group) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'Transferring Opportunistic Wireless Encryption to the
IEEE 802.11
  Working Group'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-09-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  RFC8110 describes Opportunistic Wireless Encryption (OWE), a mode
  that allows unauthenticated clients to connect to a network using
  encrypted traffic.  This document transfers the ongoing maintenance
  and further development of the protocol to the IEEE 802.11 Working
  Group.

  This document updates RFC8110 by noting that future work on the
  protocol described in RFC8110 will occur in the IEEE 802.11 Working
  Group.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-wkumari-rfc8110-to-ieee/



No IPR declarations have been submitted directly on this I-D.

Document History
Was the document considered in any WG, and if so, why was it not adopted as a work item there?

This document updates RFC 8110, which was an individual submission, i.e., not a WG document.


Was there controversy about particular points that caused the WG to not adopt the document?

No, it is basically orthogonal to any existing WG.


Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No


For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

This document does not specify any protocol. But, it refers to RFC 8110, which has been implemented notably in wpa_supplicant and hostapd (with some modifications of the HKDF).
Additional Reviews
Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Reviews will be done during the IETF Last Call in some WGs and directorates.
The IEEE has sent a Liaison Statement about this I-D:
https://datatracker.ietf.org/liaison/1929/


Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.


If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

Not applicable.


Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.
Document Shepherd Checks
Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes (notably as the shepherd is the AD ;-) ).


Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

Not applicable as this is not a specification.


What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational, meta data is correct, it updates an  informational I-D and does not contain any specification.


Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

Yes, the shepherd has checked for IPR with the authors.


Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes, the shepherd has checked with the authors.


Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No more remaining nits.


Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

References have been checked.


List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative references?

The normative reference is a freely available RFC.


Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No


Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No such references.


Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No changes (even if this was contemplated).


Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

Not applicable.


List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

Not applicable