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

Re: [EFM] reflector usage




Howard,

In the past, within the EFM Task Force, it has been noted that one group 
does not know what is going on in another group, sometimes to the detriment 
of the project as a whole.  Perhaps it would be best to bring most of the 
work back to the TF as a whole.

For example, the issue of security has been raised time and again in the 
different subgroups, perhaps without the other subgroups being aware of it, 
or knowing what those other subgroups had made as a determination regarding 
the topic of "security".  This is an on-going issue that keeps getting 
brought up again and again in first one group and then another.  It is as 
if some one small group wants to do it, but can not find a home for it.

It would have been much better for the TF as a whole to be aware of the 
"conversations" that went on in OAM, because much of the same topic and 
issues are being repeated in P2MP.  I don't doubt that they were also 
brought up in copper.  It is my perception that in OAM it was decided that 
"security" was not part of the domain of 802.3.  Since OAM is above the 
PCS, then any security would also be above the PHY encoding, at or above 
the MAC, in which case it would not be an issue within EFM.

This continuing resurrecting the issue of "security" has me concerned.  If 
security was going to be such an issue, then it should have been part of 
the original objectives.  As late as the last meeting, the provision of any 
form of security was not part of the objectives.  If providing security is 
not part of the objectives, then why is it being "pushed" so hard to that 
we continue to have to deal with it?  Should it be made an 
objective?  Should it fail to make it as an objective, can the TF, as a 
group agree to "drop" the issue?

Personally, I am not sure what the long term 802.3 voters would be willing 
to agree to at this late date regarding adding a "security" 
objective.  Along with some of the other issues, EFM seems to be suffering 
from "feature creep".  As long as "new features" keep getting added, the TF 
will not be able to set and adhere to a schedule.  Perhaps it would be best 
to get the simple "things", that are already part of the objectives, 
resolved.  This will allow individuals within the group to make personal 
resolutions to open some of these "new features" as new study groups and 
allow the TF as a whole to get back into a schedule of some sort.

Thank you,
Roy Bynum


At 08:44 PM 8/13/2002 -0700, Howard Frazier wrote:


>Dear Members of the IEEE 802.3ah EFM Task Force,
>
>as you know, we have multiple email reflectors available
>for our use.  We have the stds-802-3-efm@ieee.org
>reflector, which is used for announcements and discussions
>of general interest.
>
>We also have reflectors for each of our sub task forces,
>such as the stds-802-3-efm-p2p@ieee.org reflector
>and the stds-802-3-efm-p2mp@ieee.org reflector for
>the optical PMD and point to multipoint protocol sub
>task forces, respectively.
>
>Some task force members find it annoying to receive
>multiple copies of email messages.  This is often caused
>by the unnecessary inclusion of multiple email reflector
>addresses on the distribution list.  As an example, there
>is no need to send a message to both stds-802-3-efm@ieee.org,
>and ANY of the sub task force reflectors, since 99% of the
>folks on a sub task force reflector are also on the primary
>task force reflector.  Please try to limit the distribution of
>messages to the extent possible.  Many of us are inundated
>with email messages, and even the simple chore of deleting
>a bunch of duplicate messages wastes time unnecessarily.
>
>Thanks for your cooperation.
>
>Howard Frazier
>Chair, IEEE 802.3ah EFM Task Force