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

Re: [802SEC] P802f and Wake on LAN normative annex

Thanks for your concern James,

For everyone's benefit, the background as indicated in the PAR, is that IETF requested the creation of this YANG module, to replace their RFC 8519.  Upon coordination with the RAC it was discovered that the widely used Wake on LAN EtherType was not registered.  The IEEE RA assigned it to IEEE 802.1 to allow the definition of the YANG module in P802f.

The RAC wanted to have a reference with the frame format, which resulted in the description in an informative Annex.  The WG felt that including an informative frame format for this EtherType was in scope of the P802f PAR, but any protocol definition would not be.  As a result, a PAR modification was not made before SA ballot.

An MBS SA ballot comment (I-34) asked to make Annex G normative.  The comment resolution group agreed, and D2.1 that was recirculated included this change.  There were no comments on this change.

It is my understanding that at the SA ballot stage, the comment resolution  group determines if the document is within the scope of the PAR.  As a result, I believe the process has been followed.

Cheers,
Glenn.


-----Original Message-----
From: ***** IEEE 802 Executive Committee List ***** <STDS-802-SEC@listserv.ieee.org> On Behalf Of James P. K. Gilb
Sent: July 13, 2023 2:42 AM
To: STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: [802SEC] P802f and Wake on LAN normative annex

All (Glenn, please forward this to the appropriate 802.1 list)

You may be surprised to find P802f added a normative annex with a frame format for the (undefined) Wake-on-LAN protocol.

Especially as the scope of the project is to add "YANG modules that contain the EtherType information" and "addresses errors and omissions in IEEE Std 802 description of existing functionality." (full scope below).

Glenn was kind enough to explain the reasons why the group decided to add this normative Annex.  However, the reasons why the group made this decision is not relevant to my concern.

My concern is that the project has clearly exceeded its scope.  Based on my limited understanding of the rules, when the group realized that they were going to exceed the scope, they should have either:
1) Declined to add the content, or
2) Modified the PAR scope to add "define frame formats for Wake-on-LAN".

I don't think the LMSC should forward this draft to RevCom until one of the two above actions is taken.  Modifying the PAR will mean reforming the ballot pool and restarting SA ballot.  But that is the point, as interested parties reading the title and scope would not know that the definition of frame formats for Wake-on-LAN is part of the project and so would not have joined the SA ballot pool.

At this point, I intend to vote against conditional forwarding P802f to RevCom.

James Gilb

Full scope of P802f:
This amendment specifies YANG modules that contain the EtherType information, including a compact human-readable name and description. 
The name and description for an initial set of EtherTypes are defined for inclusion in the IEEE Registration Authority EtherType public listing. This amendment also addresses errors and omissions in IEEE Std
802 description of existing functionality.

----------
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.