a 6bone BOF at the San Jose IETF

[Bob Fink LBNL]

I have been asked by several folks to arrange for a 6bone BOF at the San
Jose IETF meeting in December.

In order to have a meeting at a regular time (as opposed to being jammed
into a lunch time which people have complained about) it is necessary to be
an "official BOF" which requires approval of an area director.

Also, a BOF leads to formation of a Working Group (from RFC 1603 on BOFs):

   -    All BOFs must have the approval of the appropriate Area
        Director. The Secretariat will NOT schedule or allocate time
        slots without the explicit approval of the Area Director.

   -    The purpose of a BOF is to conduct a single, brief
        discussion or to ascertain interest and establish goals for
        a working group. All BOF organizers are required to submit a
        brief written report of what transpired during the BOF
        session together with a roster of attendees to the IESG
        Secretary for inclusion in the Proceedings.


So the relevant questions seem to be:

1.  What do we have to discuss in San Jose about regular 6bone business as
we know it?

2.  Do we want to hold an "official BOF" to discuss the formation of a
Working Group (the details of what it might accomplish could be a topic for
the BOF along with 1. above)?


I'm willing to chair an initial BOF, if we chose to have one, and deal with
administrativia, if the group so wishes.


The Operational Requirements area seems to be the mostly likley one for any
6bone activity.  I have asked its co-Directors, Mike O'Dell and Scott
Bradner, if they would support having a BOF, if our "rough consensus"
discussions on the list supported it; they said yes.


As to what a 6bone Working Group might do, I looked at the new mboned
Working Group charter, as the 6bone is patterned after the mbone.  Clearly
there is a wide degree of acceptable goals for a Working Group.  We could
have goals as simple as documenting the existing 6bone structure in an
informational RFC (or at least I suspect we could).


Anyway, please comment on all the above so we can make a decision quickly
on securing the BOF time slot in San Jose.


Thanks,

Bob

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
from RFC 1603 "IETF Working Group Guidelines and Procedures"

2.4. Birds of a feather (BOF)

   Often it is not clear whether an issue merits the formation of a
   working group. To facilitate exploration of the issues the IETF
   offers the possibility of a Birds of a Feather (BOF) session, as well
   as the early formation of an email list for preliminary discussion.
   Alternatively, a BOF may serve as a forum for a single presentation
   or discussion, without any intent to form a working group.

   A BOF is a session at an IETF meeting which permits "market research"
   and technical "brainstorming".  Any individual may request permission
   to hold a BOF on a subject. The request must be filed with the
   relevant Area Director. The person who requests the BOF is usually
   appointed as Chair of the BOF.  The Chair of the BOF is also
   responsible for providing a report on the outcome of the BOF.


Huizer & Crocker                                                [Page 9]

RFC 1603             IETF Working Group Guidelines            March 1994


   The AD may require the conduct of email discussion, prior to
   authorizing a BOF.  This permits initial exchanges and sharing of
   framework, vocabulary and approaches, in order to make the time spent
   in the BOF more productive.  The AD may require that a BOF be held,
   prior to establishing a working group, and the AD may require that
   there be a draft of the WG charter prior to holding a BOF.

   Usually the outcome of a BOF will be one of the following:

   -    There was enough interest and focus in the subject to
        warrant the formation of a WG;

   -    The discussion came to a fruitful conclusion, with results
        to be written down and published, however there is no need
        to establish a WG; or

   -    There was not enough interest in the subject to warrant the
        formation of a WG.

   There is an increasing demand for BOF sessions at IETF meetings.
   Therefore the following rules apply for BOFs:

   -    All BOFs must have the approval of the appropriate Area
        Director. The Secretariat will NOT schedule or allocate time
        slots without the explicit approval of the Area Director.

   -    The purpose of a BOF is to conduct a single, brief
        discussion or to ascertain interest and establish goals for
        a working group. All BOF organizers are required to submit a
        brief written report of what transpired during the BOF
        session together with a roster of attendees to the IESG
        Secretary for inclusion in the Proceedings.

   -    A BOF may be held only once (ONE slot at one IETF Plenary
        meeting).

   -    Under unusual circumstances an Area Director may, at their
        discretion, allow a BOF to meet for a second time. Typically
        (though not a requirement) this is to develop a charter to
        be submitted to the IESG.

   -    BOFs are not permitted to meet three times.


Huizer & Crocker                                               [Page 10]

RFC 1603             IETF Working Group Guidelines            March 1994


   -    A BOF may be held for single-event discussion, or may pursue
        creation of normal IETF working groups for on-going
        interactions and discussions. When the request for a BOF
        comes from a formally-constituted group, rather than from an
        individual, the rules governing the handling of the request
        are the same as for all other BOFs and working groups.

   -    When necessary, WGs will be given priority for meeting space
        over BOFs.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
from mboned Working Group charter

Description of Working Group

The MBONE Deployment Working Group will be a forum for coordinating the
deployment, engineering, and operation of multicast routing protocols and
procedures in the global Internet. This activity will include, but not be
limited to:

- Deployment of multicast routing in the global Internet.

- Receive regular reports on the current state of the deployment of mbone
technology. Create "practice and experience" documents that capture the
experience of those who have deployed and are deploying various MBONE
technologies (e.g. PIM, DVMRP, CBT).

- Based on reports and other information, provide feedback to IDMR.

- Develop mechanisms and procedures to aid in the transition to native
multicast, where appropriate.

- Develop mechanisms and procedures for sharing operational information to
aid in operation of the global MBONE.

- Development of guidelines to improve the use of administratively scoped
multicast addresses.

- Develop mechanisms and procedures for creating and maintaining a MBONE
topology database.

This working group will initially interact closely with IDMR. It is
believed that, once hierarchical multicast routing systems are specified
and deployed, the working groups will diverge somewhat.

Goals and Milestones

will be subject to discussions within the working group.

Goals and Milestones:

Sep 96 Establish initial charter, goals, and long-term group agenda.

Sep 96 Submit Internet-Draft on inter-provider coordination of the
deployment of pruning mrouteds.

Jan 97 Submit Internet-Draft outlining requirements for the existing MBONE
infrastructure.

Apr 97 Submit Internet-Draft specifying the use of administratively scoped
multicast addresses.

Jun 97 Begin work, with RPS WG, on extensions to RPSL to describe multicast
routing policy.

Jun 97 Subnmit Internet-Draft specifying the use of aggregation for DVMRP
(and, in general where applicable). In addition, address the use of DVMRP
default.

Sep 97 Submit Internet-Draft specifying the use of native multicast where
appropriate (e.g. exchange points).

Sep 97 Begin work on document of co-existence strategies for IPv4 multicast
and IPv6 multicast.

Dec 97 Begin work on a document describing the deployment of inter-provider
hirearchical multicast routing coordination (or, when available).

- end