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

[802.3_DIALOG] Comments on PARs from other WG

Colleagues:

As a prelude to our plenary meeting, I have looked over the PARs from other WGs and have the following personal comments.  Other reviews and development of comments would probably be helpful prior to the Berlin meeting to help our Chair determine if an ad hoc is justified needed for developing WG comments on these PARs.  (I have included P802.1ci, which was distributed on the EC reflector after Mr. Law sent out the 802.3 meeting announcement.)

—Bob Grow


P802<unassigned>, Recommended Practice for Information technology-- Telecommunications and information exchange between systems-- Local and metropolitan area networks: Privacy considerations for IEEE 802 Technologies


Project number — Agree with suggestion in the EC announcement email that this would fit in 802.1 and should be assigned there with assent of the 802.1 WG.

2.1 (non-substantive) — Title typically doesn’t include a period (aka, full stop).  (It is unlikely that publication editors would include one independent of the PAR.)

4.2, 4.3 — Dates need to be included — lack of dates suggests the SG does not yet understand the magnitude of the work to be done.

5.1 — Please justify the estimate of number of participants, this isn’t the number of people expected to be in the WG ballot group, but the number actively participating in the project.  For example, how many participants have 

5.2.a (non-substantive) — There is a superfluous return in the presumably pasted text.

5.4 (non-substantive) — Inappropriate capitalization of attack methods.

5.5 (non-substantive) — There are superfluous returns in the presumably pasted text.


CSD:   https://mentor.ieee.org/privecsg/dcn/15/privecsg-15-0004-02-0000-privacy-recommendation-par-csd-proposal.pptx

General — The responses are perfunctory and are generally without substance.

Managed Objects — A recommended practice can include parameters and management capability.  The response needs to be relevant to this proposed project and why the scope of work will not include management capability.

Distinct Identity — It would be appropriate to explain why existing security mechanisms (e.g., 802.1 MAC Sec, 802.11 encryption) are not sufficient and do not overlap with the scope of the proposed project.

Technical Feasibility — It would be expected for the response to address the technical feasibility of recommendations of multiple of the threats listed in the Need section of the PAR.

Economic Feasibility — Answer is non-responsive to the list of considerations.  Most security techniques have some impact on system cost (e.g., encryption hardware, software complexity), security overlays have installation costs, while features integral to implementations may have negligible installation impacts, and maintenance costs (updating capabilities for new threats) certainly have operational cost implications.




P802c, Amendment:  Local MAC Address Usage

6.1.b — Might be appropriate to indicate that because of the anticipated partitioning of the local address space, the RAC will be engaged well before Mandatory Coordination.


General — The CSD does not seem to have been updated recognizing the potential for use of the local address space for other needs like privacy.  Though not really the focus of Compatibility, the project as an addition to Std 802 will provide the architecture for compatible operation of multiple local address administration techniques / local address administration functions.  (Make it easier for other projects to be compatible with Std 802 addressing.)

Broad Market — While probably sufficient justification, there are other ephemeral devices under consideration perhaps it is considered that these things are encompassed by IoT, but the list of IoT devices are mostly longer lived than single use.  Single use examples include thinks like medication compliance devices, disposable personal sensors, etc., which should be addressed before massive numbers of globally unique addresses are consumed.

Distinct Identity — Seems to contradict citation of  T11 FC-BB-6 in Technical Feasibility.  There is not 802 standard, there also is not insufficient description for use of local addresses in Std 802 to facilitate compatibility and interoperability of emerging recommendations for local address utilization for networking technologies using 802 addressing.




P802.1Qci, Amendment:  Per-Stream Filtering and Policing

PAR:  http://www.ieee802.org/1/files/public/docs2015/new-nfinn-stream-gates-par-0115-v04.pdf

No comments.

CSD:  http://www.ieee802.org/1/files/public/docs2015/new-nfinn-input-gates-csd-0115-v02.pdf

General — It would be helpful when having multiple proposed projects to review if the document included what project the CSD was for.



P802.1Qcj, Amendment: Automatic Attachment to Provider Backbone Bridging (PBB) services


No comments.


Broad Market, a) — This is an amendment, not a revision.
 



P802.11a?, Amendment: Enhancements for Ultra High Throughput in and around the 60 GHz Band

PAR:  https://mentor.ieee.org/802.11/dcn/14/11-14-1151-05-ng60-ng60-proposed-par.docx

No comments.

CSD:  https://mentor.ieee.org/802.11/dcn/14/11-14-1152-06-ng60-ng60-proposed-csd.docx

1.2.3 — The title of the amendment is irrelevant to the CSD question and the last sentence of the first paragraph should be deleted.

1.2.4,a) — An amendment amends the base standard, not another amendment.   Something like “add refinements to” instead of “amend” in the second sentence.

1.2.4,b) — The answer is not really responsive.  This question seeks evidence that technology is sufficiently proven to allow a project to be completed in a reasonable amount of time without need for research, fundamental simulation and modeling.  The response indicates that these tasks will be done as part of standards development.  While these tasks might be appropriate to validate selected specifications, the response implies these tasks have not been done in advance of the proposed PAR to show the intended work is technically feasible leading to the conclusion that it is too early to approve a project.




P802.15.3e, Amendment for high-rate close proximity point-to-point communications


What is the revision plan for IEEE Std 802.15.3-2003?  It appears that there are two approved amendments IEEE Std 802.15.3b-2005 and IEEE Std 802.15.3c-2009, an existing amendment project P802.15.3d, and this proposed project is expected to be the 4th amendment.  This is a problem per 9.1 of the SASB Operations Manual.  It is not credible that a revision project can be completed between approval of P802.3d (RevCom submittal 5/2016) and initiating of proposed P802.15.3e (11/2016).  Turning this amendment into a revision might be the only way to get this approved on the indicated schedule; unless a revision of the base document is opened as a maintenance item at the March plenary meeting. P802.15 should note that RAC review should be requested for the required revision, whenever done.

The P802.15.3d PAR should never have been approved as submitted, as the scope for example describes the project rather than the standard.  While proposed P802.15.3e fixes this problem, it might be wise to do a modified PAR for P802.15.3d to do those fixes rather than find it a problem at RevCom.  The stacked changes certainly are difficult to figure out.  The tools certainly do not provide an easy way to show stacked changes to Scope and Purpose, but the note could be a bit more clear.  As written, the note assumes approval of P802.15.3d, yet P802.15.3e is not indicated to be dependent on its completion in 5.3.  Either 5.3 should change, or the note should change.  Fro the remote perspective of 802.3, it would appear to be the former, but the issue of a revision being required to gain approval of P802.3e (assuming P802.3d is approved) can’t be separated from the best fix for this.  

I have already communicated my concern about a revision plan to the WG Chair and Vice Chair, and a revision plan or options for selection of a future revision plan should be available by the Plenary meeting.

2.1 (non substantive) — The correct format is “Amendment:  <amendment name>”, not “Amendment for <amendment name>”.

5.1 — It would be unusual for participants to increase from 20-30 in pre-par activities (as indicated in the CSD) to the 50 indicated in the PAR.  The question is not the number of WG members (it used to be that), it is the number of people actively involved in the project.

5.6 — There is an interesting gap in the stakeholders.  I believe there is significant industry evidence of devices that include RF capability using proprietary chips (not a chip vendor) yet the product is manufactured by a contractor (so also not a manufacturer of RF equipment).

CSD:  http://ieee802.org/PARs/2015_03/15-14-0716-05-003e-sg3e-draft-csd.docx

1.2.1,b) — A nit to consider.  Both semiconductor and equipment may be manufactured by a foundry or contract manufacturer, the important thing is to get folk participating involved in semiconductor and equipment development, usually doesn’t matter who is manufacturing, more important who will be implementing it.

1.2.5,a) — The response highlights an imbalance of costs without justification for that being acceptable or expected.