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

Re: [802SEC] Fwd: [STDS-WG-CHAIRS] IEEE-SA Policy and Procedures (P&P) Changes - January 2018 - Important - Please read



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




On Jan 4, 2018, at 6:17 PM, Benjamin A. Rolfe <ben@BLINDCREEK.COM> wrote:

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

On Jan 3, 2018, at 11:17 AM, Adrian Stephens <adrian.p.stephens@ieee.org> wrote:

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 --------
Subject: [STDS-WG-CHAIRS] IEEE-SA Policy and Procedures (P&P) Changes - January 2018 - Important - Please read
Date: Tue, 2 Jan 2018 15:10:12 -0500
From: Dave Ringle <d.ringle@ieee.org>
Reply-To: Dave Ringle <d.ringle@ieee.org>
To: STDS-WG-CHAIRS@LISTSERV.IEEE.ORG


All,

The current version of the IEEE-SA Standards Board Bylaws is available at:
http://standards.ieee.org/develop/policies/bylaws/index.html (HTML version)
http://standards.ieee.org/develop/policies/bylaws/sb_bylaws.pdf (PDF version) 

The current version of the IEEE-SA Standards Board Operations Manual is available at:
http://standards.ieee.org/develop/policies/opman/index.html (HTML version)
http://standards.ieee.org/develop/policies/opman/sb_om.pdf (PDF version) 

The text of the changes made to these documents (approved by SASB/BOG in 2017) can be found at:
http://standards.ieee.org/develop/policies/policy_rev.pdf 

Please read through these changes so that you are familiar with the current P&P. 

If you have any questions, please contact me. [Please do not reply to all unless you want all to view your comments. Thank you.] 

{Please note that you may need to refresh your web browser (or clear the cache) to see the current content.} 

Regards,
Dave
******************************************************************
David L. Ringle
Director, IEEE-SA Governance
IEEE Standards Association
445 Hoes Lane                              
Piscataway, NJ  08854-4141 USA
TEL: +1 732 562 3806
FAX: +1 732 875 0524               
EMAIL: d.ringle@ieee.org
******************************************************************
---------- 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.