Shepherd Template: 24 February 2012.
(1) What type of RFC is being requested:
Intended status: Standards Track.
(2) Document Announcement Write-Up:
Technical Summary:
This document defines an IEEE 802.11 MAC profile which specifies the
division of encryption functionality between the Wireless Transmission
Point (WTP) and the Access Controller (AC). This is to alleviate
interoperability issues, especially when the AC and WTP come from
different vendors.
Working Group Summary:
There was no drama in the WG related to this document.
OpsAWG provides a home for the CAPWAP work within the IETF, but CAPWAP is
not the primary focus of the WG. This means that only a small number
of participants had an opinion on the work, but those who did were supportive.
We also received a comment from the IEEE 802.11 Working Group Chair,
stating
that: "The IEEE 802.11 Working Group has also reviewed this document
and has no comments on its content."
Document Quality:
This document is well written, clear and concise.
Personnel:
Warren Kumari is the Document Shepherd. Benoit Claise is the Responsible Area
Director.
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. The document shepherd is not very familiar with CAPWAP, and
so has relied on the opinions of those within the WG who know are familiar with
CAPWAP for technical evaluation. The shepherd did review the document, and it
is easily understandable by those not steeped in the CAPWAP arcana.
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed? The OpsAWG group is somewhat of a
catch-all for documents that don't fit very well in other working groups. This
means that we do not have a set of dedicated participants who are passionate
about the topics / documents. The IETF works on the CAPWAP stuff together with
the IEEE. All this means that we do not have a huge set of folk with experience
in this area. That said, the participants who *do* know this stuff, and care
about it all seem to believe that the work is needed, useful and clear. The
IEEE 802.11 Working Group also reviewed this document and has no comments on
its content ( https://datatracker.ietf.org/liaison/1325/ )
(5) Do portions of the document need review from a particular or from broader
perspective? No.
(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should be
aware of? None.
(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why? Each author has confirmed.
(8) Has an IPR disclosure been filed that references this document?
Nope.
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?
The WG is not very active and only a minority of the WG participants
follow CAPWAP, so the huge majority of the WG was silent. Those who
do care were very supportive. The work was also presented in meetings,
and discussion was supportive.
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
Nope!
(11) Identify any ID nits the Document Shepherd has found in this
document.
None (all nits found have been addressed in the latest version).
(12) Describe how the document meets any required formal review criteria.
None needed.
(13) Have all references within this document been identified as either
normative or informative? Yes. There are only 2 references, both normative.
(14) Are there normative references to documents that are not ready for
advancement? No. Both references are to published RFCs.
(15) Are there downward normative references references (see RFC 3967)?
Nope.
(16) Will publication of this document change the status of any existing RFCs?
Nope.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. The IANA considerations section was a little sparse, the shepherd
provided feedback to the authors and it has now been fleshed out. It appears
acceptable now. The actions requested of the IANA align with the document
contents.
(18) List any new IANA registries that require Expert Review for future
allocations. CAPWAP IEEE 802.11 Split MAC Profile.
(19) Describe checks to validate formal language.
No formal language exists.