Ben:
A lengthy answer to what seems to be a simple question.
I think the RAC answer can be changed when doing a modified PAR though I don’t recall anyone doing so to prove that it actually works in myProject. Therefore, myProject hasn’t been tested for multiple possible cases, including if a PAR modification after opening Sponsor ballot would be sufficient to get RAC Coordination review to happen.
Just letting the RAC Administrator (or RAC Chair) know RAC Coordination review should occur would be acceptable when registry content is added. We hope MEC review will flag a draft for RAC Coordination review when the PAR didn’t answer yes. When that happens, no modified PAR is required, the MEC reviewer simply lets the RAC Administrator know they came across “registry activity” in the draft and the RAC will review. Once in Sponsor ballot, notice of the introduction of “registry activity” content could come from anyone (people in or out of the ballot group, project leadership, IEEE staff, etc.)
In my experience, the worst problems have occurred when the RAC learns of registry content late in Sponsor ballot. The changes to the rules SASB Operations Manual resulted from one such case last year, where the RAC learned about a problem after balloting and we had to tell RevCom we opposed a RevCom approval recommendation. (The SA Operations Manual makes the RAC responsible for registry activity content for both proposed and approved standards.)
That RAC position at RevCom resulted in deferral of approving the submitted draft, and an ad hoc that decided clarification of RAC coordination and registry activity in the SASB Operations Manual would be helpful (the new rules text). I think the new rules text also strengthens the point that the Sponsor is responsible to make sure RAC review of registry activity content occurs. No one believes the RAC volunteers can review all of the hundreds of drafts balloted each year, something that hasn’t changed from when the 6.1.B question was added to the PAR form more than a decade ago (to help Sponsors understand they have responsibility to engage the RAC when registry content is part of the project).
—Bob
Thanks Bob,
Related question: can
we change the "no" to a "yes" if we revise the PAR? This would
seem a good way to handle the situation where a project we did
not expect would venture into things which would require RAC
coordination ultimately does.
thanks in advance.
B
On 1/4/2018 1:51 PM, ROBERT GROW wrote:
Ben:
Your opinion agrees with my personal opinion. Many
802 projects do not include registration activity. So, I would
not go as far as Adrian did when he recommended all 802
projects answering Yes to PAR 6.1.B.
1. Certainly most 802.3 PHY projects do not include
any new registration activity. I would expect the same thing.
802.3 PHY management includes use of the OUI in PHY
implementation identification. If the draft only references
text as other PHY specifications do, then typically the term OUI
would not be in the 802.3 amendment draft, and therefore it
would not be flagged for RAC review by editorial staff, and the
draft including no new registration activity text eliminates the
requirement for the Sponsor to cause RAC coordination to occur.
A PAR 6.1.B answer of No is acceptable for most 802.3 PHY
amendments. On the other hand, if other 802 WG PHY projects end
up requiring modification of previously reviewed text on use of
the OUI, then an answer of PAR 6.1.B Yes, is expected, because
it is changing the specifications for use of a registry.
2. Some projects in 802.1
may not include registration activity, even though they exchange
frames using MAC addresses. The MAC address text is typically
in the underlying link technology (e.g., 802.11), and the RAC
would not want to review something that simply specified frame
transmission. If though, an information transmission specified
use of a Standards Group MAC Address, that is a specific and
comparatively uncommon specification for MAC addressing
necessating RAC coordination. Any text about MAC addresses
though will typically cause editorial staff to flag a draft for
RAC coordination review even if the PAR form answer was No.
3. Adrain’s
recommendation of a Yes is certainly appropriate for all
revision projects for 802 standards, though the explanation of
the No might be “No new registration activities are anticipated,
but the RAC may want to review for correct and current uses of
terms”. I agree with Ben we will have amendment projects (e.g.,
PHY amendments) that only use capabilities already specified in
the base standard which presumably have already been reviewed by
the RAC. This will certainly be true where the base standard
has done a good job of separating architectural layers. (E.g.,
if the PHY project only specifies PHY management attributes and
can reference PHY management protocols, it is unlikely to
include registration activity text, even though the referenced
capabilities do include the registration activity that requires
RAC coordination.
For either a Yes or No
answer an explanation may be required or appropriate (see the
PAR form instruction for registration activity / RAC
coordination).
—Bob
Hello Ben,
Yes, I think a PHY-only amendment could safely do
that. I haven't seen any PHY-only amendments in
802.11,
as all PHYs have their unique management requirements.
One of the things we learned from TGaq is that the group
did not set out with the intention of doing anything
with address fields. It turned out over the
multiple-year course of the project the increased
sensitivity towards maintaining privacy coupled with the
large number of packets sent meant that it needed to
talk about things
that the RAC care about. In hindsight this is
obvious, but it wasn't when the PAR was written.
Best Regards,
Adrian Stephens
IEEE 802.11 Working Group Chair
mailto: adrian.p.stephens@ieee.org
Phone: +1 (971) 203-2032
Phone: +447342178905
Skype: adrian_stephens
On 03/01/2018 18:47,
Benjamin A. Rolfe wrote:
Thanks Adrian for pointing this out.
For clarification, would it be safe to
define "non-trivial" as an amendment or revision
that does NOT alter the format or content of an
address field? For example an amendment that
added only new PHY capabilities but had no MAC
changes (which might not otherwise be considered
trivial), or a an amendment with additional MAC
features that do not alter in any way the
addressing fields (e.g. add Information Elements
but no new frame formats).?
Or should we just always assume "yes"
and let the RAC know, just to be safe?
Thanks.
Ben
On 1/3/2018 2:17 AM,
Adrian Stephens wrote:
Dear EC members,
Please be aware of the changes to the IEEE-SA
P&P's: http://standards.ieee.org/develop/policies/policy_rev.pdf.
One of the items that has been clarified in my mind
is the need for any project that cites/includes a
field whose values
are managed by the IEEE RA to indicate "yes" in its
PAR for RAC coordination. As all of our L2
protocols (AFAIK)
use MAC addresses within of the RAC-defined
namespaces, this should be "yes" for all
non-trivial amendments
and revisions.
Best Regards,
Adrian Stephens
IEEE 802.11 Working Group Chair
mailto: adrian.p.stephens@ieee.org
Phone: +1 (971) 203-2032
Phone: +447342178905
Skype: adrian_stephens
-------- Forwarded Message --------
---------- This email is sent from the 802 Executive
Committee email reflector. This list is maintained
by Listserv.
----------
This email is sent from the 802 Executive Committee email
reflector. This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email
reflector. This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.
|