Internet2 New Network Advisory Structure Group
Conference Call, June 29, 2006 - 4:00 p.m. EDT
In the call:
Jacqueline Brown (Univ. Washington)
James Deaton (OneNet)
Ray Ford (Univ Montana)
Mark Johnson (NCREN)
George Loftus (OSHEAN)
Ben Colley (MORENET)
Michael Krugman (Boston Univ)
Garret Yoshimi (Univ Hawaii)
Ana Preston (Internet2)
Rick Summerhill (Internet2)
Cheryl Fremon (Internet2)
New Action Items:
ACTION 1: Recommended that group members see what is in place at IETF (see
http://www.ietf.org/tao.html and ftp://ftp.isi.edu/in-notes/rfc3777.txt
ACTION 2: Rick will touch base with Paul about input received on strawman and what may need
to be changed there.
ACTION 3: Ana will also make sure that Paul has the notes in preparation for next call.
No pending action items from last call.
Notes/Minutes from call:
Rick moderated call due to Paul being on vacation. After introductions, Rick reviewed basically
tasks for this group. Read over charter of group (included at the end of the notes) noting how this
group could help Internet2 think about the new network infrastructure advisory structure: how to
organize; process(es) for involving and getting community input; how members for the group (and
hierarchical group structure) could be chosen/selected; communications with other Internet2
advisory bodies/councils and recommendations for working groups.
I. Discussion on the diagram that Paul sent last week (strawman): a first cut for hierarchy and the
organization of this group and the relationship to the wider advisory structure and processes. Rick
asked for input/comments on this.
Question: How different than the way(s) that current working groups work today?
Rick mentioned that today we have working groups in particular areas, say technical areas, ipv6;
but that there's minimum or no communication lines for transferring the advice of these groups
back to the current "advisory" group for Abilene network (Abilene TAC).
New advisory structure could encompass a structure with overall advisory group and then specific
areas that have working groups associated with it, e.g. working group on specific technical issue
relevant to New Network infrastructure. Could envision creating/chartering working groups that
could be long standing dealing with longer-term "themes" or for example, a group associated with
peering issues. Looking in fact for recommendations on what the initial working groups should be
about.
Envision that these working groups are part of and provide input to overall advisory group.
Different than what we have on the Abilene structure. New Network is much more complicated;
have a new set/new features and different kinds of services resulting in different set of issues.
One reason why envisioning needing a sort of hierarchical structure to be recommended.
Working groups could be created to be long standing (i.e. in issues that may require providing
constant information/input into Network advisory group) - or could be short-term, i.e., network
Advisory group could charter a working group with short term deliverables. Network Advisory
Group (NAG) could suggest charter, deliverables, short term groups would go away or be
discontinued once work is finished. Should be careful on the labeling of groups (i.e., should not
be confused with other working groups serving other functions within Internet2). In the case of
what we are talking about here, these are technical groups with specific tasks/charters related to
new network and where specific outcomes are expected. Should make sure that distinction of
"working groups" is made or how to characterize these groups (i.e., groups of people working on
a particular project/set of issues relevant to New Network). Perhaps call them subcommittees?
Some discussion about similar processes in place with the IETF.
ACTION 1: Recommended that group members review what is in place there: http://www.ietf.org/tao.html
Discussion around lines of "communication" to advisory groups (lines from strawman from
network advisory group to advisory councils). Should not think that all these lines need mean that
every working group (in Internet2) should have lines for the advisory structure. Notion here is
more to go with a hierarchical setup. Group discussed further that maybe the diagram could be
even further simplified.
Diagram should be made simpler - suggested that some boxes are cut; take out ideas out, take
SIG, collapse boxes for advisory councils into one (advisory councils). Want to have something
that is easy to explain to people.
ACTION 2: Rick will touch base with Paul about this before the call next week.
ACTION 3: Ana will also make sure that Paul has the notes in preparation for next call.
Discussion on what may be the process(es) in place for community input. Idea box perhaps?
What are the thoughts on how to set up groups?
Ideas included having, like in IETF, schemes like having a RFC - which works a as framework/
proposal; reviewed by the community and where input comes in many directions; community is
asked to comment. Within IETF, a RFC can go through a multitude of drafts, very formal process.
Want to envision something similar but less formal. Idea discussed was to model after the
informational RFCs
For diagram: Adding stick figure and have a different flavor of arrow pointed to different places -
arrow could be labeled as mechanism for an outsider , representing how they can approach the
groups at several layers, want to structure this. We want a process for internal
consideration/public consumption, IETF RFC mechanism that has worked - it can be seen as
maximally inclusive. Can imagine scenarios where something very formal would need to be
structured (i.e., very technical things, virtual networks); something where lot of comments would
need to be made to have this ratified. In the case of what we are talking about for new network,
we could have something not as formal as an RFC but formal enough so that community can see
what the proposal is, and to make it easy to illustrate how does it relate to New Network and so
forth. Process would be inclusive from start to finish - everyone has an opportunity to provide
input.
Formality implied here is that any idea would get a hearing. What then NAG can do is gage/triage
these and see if they/it warrant time and attention
IETF model, similar to the above, forces a mechanism to have not just a say but the ability for
people to work on things. Want to have something that is open, that communicates openness, is
objective, that says "because we believe in the value of the human capital, want to get community
involved. Collaborative that involves the best and brightest to contribute, help out
fundamentally opened to anyone and everyone". What decided (and ideas and suggestions)
should be immediately available to the community.
II. ideas for how members may be chosen for network advisory group? Should there be lengths of
terms? Rotating group?
In the Abilene TAC, Internet2 staff asked staff asked people to be on it - other people could
recommend - primarily was about internet2 staff about recruiting people to be on the group. Then
they were in it until they didn't want to be.
Group discussion advantages to rotating: new ideas, new people. Disadvantages include, for
example, getting people not involved in big picture. Terms are good, should be staggered or
rotating. Examples were brought up where continuity became a critical and good thing to have
(i.e., providing historical/policy perspective). To the extent that someone is willing to stay and
contribute - longevity could be valuable. We could Allow for two consecutive terms someone
could serve for 6 years; be off for a year and then eligible to come back/be brought back.
III. What may the nomination/selection process be/look like?
Rick asked group if as network advisory group, there were any thoughts on having representation
here from vendor partners; these could be rotated within the vendor organization but not e
individuals but not chosen by community. Current Abilene TAC has some vendor representation.
Ideas and discussion on this ensued. Looking at NAG to help Internet2 chose first set of
individuals that will serve. Then ask current people on the NAG to choose successors ?
IETF process/model was brought again as something that we should look at. Want to make sure
we have technically strong people, technical innovators. Approach should be though that it is an
open process. See how IETF does selection of area directors
ftp://ftp.isi.edu/in-notes/rfc3777.txt
Rick then added that hoping that at next Joint Techs (July 15-18, Madison, Wisconsin), in the
New Network BoF, currently planned for July 17) that via Paul or someone from this group, there
is a preliminary report on what NAG is thinking and get some community feedback. Then, only 2
weeks left until August 1st (deadline for this group's deliverables).
IV. Communication between NAG and other advisory groups and between NAG and other
working groups.
Rick mentioned that it would seem necessary that there be regularly scheduled communications
with councils and communications with long standing working groups. NPPAC as one of the
principal ones
Ideas included making sure minutes/notes are shared with other councils. Make this a routine,
e.g., NAG knows what NPPAC is talking about and vice versa.
Rick brought up how currently, as area director, he works with working groups associated with his
area; every six months he asks for a page on work, particular goals they have for next 6 months,
solutions they've come up from previous goals.
Want to have a regular process for having the working groups report on various issues and what
they are doing. In the case of NAG and New Network, could have some kind of reporting
structure that would go back to new net advisory group. Chair could/should then be able to
summarize to advisory councils what New Network working groups are doing and vice versa.
NEXT CALL: Thursday, July 6, 4 p.m. EDT.
Respectfully submitted,
Ana Preston
Scope statement
Internet2 Network Technical Advisory Structure
At the recent Community Design Workshop (June 15-16, Indianapolis, IN),
a hierarchical style advisory structure was described, where an overall
group commissions working groups that may either be long- standing to
provide advice on a regular basis or short duration with very limited
scope. We are asking that a group be formed from community
representatives, and be chaired by Paul Schopis. By August 1, this group
will provide recommendations for an appropriate advisory structure to
provide on-going technical advice on the Internet2 network. While the
advisory structure is focused on technical issues, there must be an
understanding of how the technical aspects inter-act, contribute to or
even constrain the policy aspects. The structure should allow for and
encourage community involvement, define the process(es) for community
input into this advisory structure, and include a suggestions for both
how the members of the advisory group are selected and how the technical
advisory structure fits in with and encourages regularly scheduled
communications to the Internet2 advisory councils.