[STDS-802-16] [NETMAN_SG] Network Management Study Group
Title: Message
All,
 
We need to get 
moving on inputs to the network management study group. The goal I put forth to 
the WG is that we do our work before and during the May meeting, so this will 
require us to work some of the issues on the reflector and maybe have a 
conference call or two, if we are to produce a PAR and five criteria during the 
interim. If we don't have a workable basis for consensus going into the May 
meeting, then I expect we will be asking for an extention in July, and that is a 
long time, given that it would then be November before the TG request would be 
approved by the EC and NesCom would add more time to the process, so maybe we 
would be looking at 2005 before we had a group for real. Finishing in May is a 
good plan.
 
I propose that email 
directed to this effort has [NETMAN_SG] in the subject line to allow appropriate 
filtering.
 
The primary thing 
that led me to suggesting a study group was the plethora of different things 
people wanted to do with respect to network management, network architectures, 
interfaces, MIBs and so on and the rapid closure of .16d as a forum in which to 
address them. My personal wish list is no secret, you will find it in the 
comment databases - security, interfaces, MIBs.
 
So as a first step, 
I would like to request that people forth their ideas for what problems 
they think network management group or groups (don't let the name 
predjudice the function) should be solving, or what features they should be 
introducing. This will give us a list of issues that we can enumerate, sort, 
sift, rejig, classify and generally argue about until we can approach consensus 
on scope and purpose. But first we need the issues out on the table for all to 
see.
 
A potential benefit 
I suggested was that items of questionable scope in .16e might find a more 
secure home in a new group. This is not my idea and I have not been in the loop 
on these discussions (although I do like the idea), so perhaps it would be 
useful input for people who are thinking along these lines to start describing 
specifics of what bits in .16e are problematic and might benefit from a 
group with a clear scope to address them.
 
I'll make my 
suggestions in a separate email..
 
DJ
(chair 802.16 
network management study group)