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