GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5434

Network Working Group T. Narten Request for Comments: 5434 IBM Category: Informational February 2009

Considerations for Having a Successful Birds-of-a-Feather (BOF) Session

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents (http://trustee.ietf.org/
 license-info) in effect on the date of publication of this document.
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.

Abstract

 This document discusses tactics and strategy for hosting a successful
 IETF Birds-of-a-Feather (BOF) session, especially one oriented at the
 formation of an IETF Working Group.  It is based on the experiences
 of having participated in numerous BOFs, both successful and
 unsuccessful.

Table of Contents

 1. Introduction ....................................................2
 2. Recommended Steps ...............................................2
 3. The Importance of Understanding the Real Problem ................7
 4. The BOF Itself ..................................................8
 5. Post-BOF Follow-Up ..............................................9
 6. Pitfalls .......................................................10
 7. Miscellaneous ..................................................12
    7.1. Chairing ..................................................12
    7.2. On the Need for a BOF .....................................13
 8. Security Considerations ........................................13
 9. Acknowledgments ................................................13
 10. Informative Reference .........................................13

Narten Informational [Page 1] RFC 5434 Successful BOF Sessions February 2009

1. Introduction

 This document provides suggestions on how to host a successful BOF at
 an IETF meeting.  It is hoped that by documenting the methodologies
 that have proven successful, as well as listing some pitfalls, BOF
 organizers will improve their chances of hosting a BOF with a
 positive outcome.
 There are many reasons for hosting a BOF.  Some BOFs are not intended
 to result in the formation of a Working Group (WG).  For example, a
 BOF might be a one-shot presentation on a particular issue, in order
 to provide information to the IETF Community.  Another example might
 be to host an open meeting to discuss specific open issues with a
 document that is not associated with an active WG, but for which
 face-to-face interaction is needed to resolve issues.  In many cases,
 however, the intent is to form a WG.  In those cases, the goal of the
 BOF is to demonstrate that the community has agreement that:
  1. there is a problem that needs solving, and the IETF is the right

group to attempt solving it.

  1. there is a critical mass of participants willing to work on the

problem (e.g., write drafts, review drafts, etc.).

  1. the scope of the problem is well defined and understood, that

is, people generally understand what the WG will work on (and

      what it won't) and what its actual deliverables will be.
  1. there is agreement that the specific deliverables (i.e.,

proposed documents) are the right set.

  1. it is believed that the WG has a reasonable probability of

having success (i.e., in completing the deliverables in its

      charter in a timely fashion).
 Additional details on WGs and BOFs can be found in [RFC2418].

2. Recommended Steps

 The following steps present a sort of "ideal" sequence for hosting a
 BOF where the goal is the formation of a working group.  The
 important observation to make here is that most of these steps
 involve planning for and engaging in significant public discussion,
 and allowing for sufficient time for iteration and broad
 participation, so that much of the work of the BOF can be done on a
 public mailing list in advance of -- rather than during -- the BOF
 itself.

Narten Informational [Page 2] RFC 5434 Successful BOF Sessions February 2009

 It is also important to recognize the timing constraints.  As
 described in detail below, the deadline for scheduling BOFs is
 approximately six weeks prior to an IETF meeting.  Working backwards
 from that date, taking into consideration the time required to write
 drafts, have public discussion, allow the ADs to evaluate the
 proposed BOF, etc., the right time to start preparing for a BOF is
 almost certainly the meeting prior to the one in which the BOF is
 desired.  By implication, starting the work aimed at leading to a BOF
 only 2 months prior to an IETF meeting is, in most cases, waiting too
 long, and will likely result in the BOF being delayed until the
 following IETF meeting.
 The recommended steps for a BOF are as follows:
 1) A small group of individuals gets together privately, discusses a
    possible problem statement, and identifies the work to be done.
    The group acts as a sort of "design team" to formulate a problem
    statement, identify possible work items, and propose an agenda for
    a BOF.
    Possible sub-steps:
    a) Consider whether the work might already fall within the scope
       of an existing Working Group, in which case a BOF might not
       even be necessary.  Individual Working Group charters can be
       found at http://www.ietf.org/html.charters/wg-dir.html and
       indicate what a group is scoped to work on.
    b) Select the area or areas in which the work most naturally fits
       by identifying WGs that most closely relate to the proposed
       work.  Note that it is not uncommon to find that a work item
       could easily fit into two (or more) different areas and that no
       one area is the obvious home.
    c) Consult with specific WGs to see whether there is interest or
       whether the work is in scope.  This can be done by posting
       messages directly to WG mailing lists, contacting the WG
       chairs, or contacting individuals known to participate in a
       particular WG (e.g., from their postings or from documents they
       have authored).
    d) Consult with an area-specific mailing list about possible
       interest.  (Most areas have their own area-specific mailing
       lists.  Follow the links under each area at
       http://www.ietf.org/html.charters/wg-dir.html to find details.)

Narten Informational [Page 3] RFC 5434 Successful BOF Sessions February 2009

    e) Produce one or more Internet Drafts, describing the problem
       and/or related work.  It cannot be emphasized enough that, for
       the BOF, drafts relating to understanding the problem space are
       much more valuable than drafts proposing specific solutions.
    Timeline: This step can easily take 1-2 months; hence, begin 3-4
    months before an IETF meeting.
 2) The group may (or may not) approach an Area Director (or other
    recognized or experienced leader) to informally float the BOF and
    get feedback on the proposed work, scope of the charter, specific
    steps that need to be taken before submitting a formal BOF
    request, etc.  By "leader", we mean persons with significant IETF
    experience who can provide helpful advice; individuals who have
    successfully hosted BOFs before, current or former WG chairs, and
    IESG or IAB members would be good candidates.
    The dividing line between steps 1) and 2) is not exact.  At some
    point, one will need to approach one or more Area Directors (ADs)
    with a specific proposal that can be commented on.  Step 1) helps
    shape an idea into something concrete enough that an AD can
    understand the purpose and provide concrete feedback.  On the
    other hand, one shouldn't spend too much time on step 1) if the
    answer at step 2) would turn out to be "oh, we had a BOF on that
    once before; have you reviewed the archives?".  Thus, there may be
    some iteration involving going back and forth between steps 1) and
    2).  Also, a quick conversation with an AD might lead them to
    suggest some specific individuals or WGs you should consult with.
    It may turn out that it is unclear in which area the proposed work
    best fits.  In such cases, when approaching multiple ADs, it is
    best to approach the ADs approximately simultaneously, state that
    you are unsure in which area the work fits, and ask for advice
    (e.g., by stating "I'm not sure which area this work best fits
    under, but it looks like it might be Internet or Security or
    both").  When contacting multiple ADs, it is strongly advised that
    you inform them of which other ADs you are conversing with.  In
    particular, it is usually counterproductive and not advisable to
    go "AD shopping", where if one AD gives you an answer you don't
    like, you go to another, without telling him/her what the first AD
    said, in the hopes of getting a more favorable answer.
    To summarize, steps 1) and 2) involve a lot of "socializing an
    idea", that is, having discussions with a number of different
    people to attempt gaining agreement on the problem and the need
    for and appropriateness of having a BOF.  How much such discussion
    is needed is very subjective, but it is critical in terms of
    getting agreement that a BOF is appropriate.  One way to tell if

Narten Informational [Page 4] RFC 5434 Successful BOF Sessions February 2009

    you are close to getting it right: when talking to someone about
    your idea for the first time, they quickly agree that a BOF seems
    in order and don't have any major concerns.
    Timeline: Steps 1-2) can easily take 1-2 months; hence, begin 3-4
    months before an IETF meeting.
 3) Create a public mailing list and post a "call for participation"
    for the proposed BOF topic on various mailing lists (e.g., the
    IETF list).  The call for participation advertises that a
    "community of interest" is being formed to gauge whether there is
    sufficient interest to host a BOF.  The goal is to draw in other
    interested potential participants, to allow them to help shape the
    BOF (e.g., by giving them time to write a draft, ask for agenda
    time, help scope the work of the proposed work, argue that a BOF
    is (or is not) needed, etc.).
    Timeline: This step can easily take 1 month or longer; it also
    needs to be started well before the Internet-Drafts cutoff (to
    allow participants to submit drafts); hence, begin 2.5-3.5 months
    before the IETF meeting.
 4) Have substantive mailing list discussion.  It is not enough for a
    handful of people to assert that they want a BOF; there needs to
    be broader community interest.  A public mailing list allows ADs
    (and others) to gauge how much interest there really is on a topic
    area, as well as gauge how well the problem statement has been
    scoped, etc.  At this phase of the BOF preparation, the emphasis
    should be on getting agreement on the problem statement;
    discussions about specific solutions tend to be distracting and
    unhelpful.
    Timeline: this step can easily take 1 month or longer; hence,
    begin 2.5 months before the IETF meeting.
 5) Submit a formal request to have a BOF.  Instructions for
    submitting a formal request can be found at
    http://www.ietf.org/instructions/MTG-SLOTS.html and
    http://www.ietf.org/ietf/1bof-procedures.txt.  Note that as part
    of making a formal request, the organizers must identify the area
    in which the BOF will be held (the Area Directors of that area
    will be required to approve the BOF), include a proposed BOF
    agenda, estimate the attendance, list conflicts with other
    sessions that should be avoided, etc.
    If the previous steps have been followed, the Area Directors (ADs)
    should be in a good position to gauge whether there is sufficient
    interest to justify approval of a BOF.

Narten Informational [Page 5] RFC 5434 Successful BOF Sessions February 2009

    Note: it almost goes without saying that without one or more
    Internet Drafts at this point, it is generally pointless to ask an
    AD to approve a BOF.
    Timeline: The Secretariat publishes an "important meeting dates"
    calendar along with meeting information.  There is a firm deadline
    (about six weeks prior to the meeting) for submitting a formal BOF
    scheduling request.  Note that at the time of the deadline, an AD
    will need to have sufficient information about the BOF to approve
    or reject the request, so all of the previous steps will need to
    have completed.
 6) During the 2-4 weeks before an IETF (assuming a BOF has been
    approved and scheduled), the focus (on the mailing list) should be
    on identifying areas of agreement and areas of disagreement.
    Since disagreement, or "lack of consensus", tends to be the main
    reason for not forming a WG, focusing on those specific areas
    where "lack of consensus" exists is critically important.  In
    general, only after those disagreements have been resolved will a
    WG be formed; thus, the main goal should be to find consensus and
    work through the areas of disagreement.  Alternatively, a specific
    case should be made about why the charter, as it is written, is
    the best one, in spite of the stated opposition.
 7) Prior to the BOF, it is critical to produce a proposed charter and
    iterate on it on the mailing list to attempt to get a consensus
    charter.  Ultimately, the most important question to ask during a
    BOF is: "should a WG with the following charter be formed?".  It
    goes without saying that a charter with shortcomings (no matter
    how seemingly trivial to fix) will not achieve consensus if folk
    still have issues with the specific wording.
 8) Decide what questions will be asked during the BOF itself.  Since
    the exact wording of the questions is critical (and hard to do on
    the fly), it is strongly recommended that those questions be
    floated on the mailing list and to the ADs prior to the BOF.  This
    will enable people to understand what they will be asked to
    approve and will allow the questions to be modified (prior to the
    BOF) to remove ambiguities, etc.  Likewise, discussing these
    questions in advance may lead to refinement of the charter so that
    the questions can be answered affirmatively.
 9) At the meeting, but before the BOF takes place, plan a meeting
    with all of the presenters to have them meet each other, review
    the agenda, and make sure everyone understands what is expected of
    them (e.g., what time constraints they will be under when

Narten Informational [Page 6] RFC 5434 Successful BOF Sessions February 2009

    presenting).  Use this time to also work through any disagreements
    that still remain.  Do the same "in the hallway" with other
    interested parties!
 10) Consult the tutorial schedule and consider attending relevant
     tutorial sessions ("Working Group Chair Training", "Working Group
     Leadership Training", etc.).  This is especially the case if you
     are considering being the chair of a proposed WG.  Since the role
     of the WG chair and BOF chair have a number of parallels, a
     number of the topics covered in the tutorial apply to hosting a
     BOF and developing a charter.

3. The Importance of Understanding the Real Problem

 Throughout the process of chartering new work in the IETF, a key
 issue is understanding (and finding consensus) on what the real,
 underlying problem is that the customer, operator, or deployer of a
 technology has and that the WG needs to address.  When a WG finishes
 an effort, the WG's output will only be useful if it actually solves
 a real, compelling problem faced by the actual user of the technology
 (i.e., the customer or operator).  Unfortunately, there have been
 more than a few IETF WGs whose output was not adopted, and in some of
 those cases the cause was a lack of understanding of the real problem
 the operator had.  In the end, the WG's output simply didn't address
 the right problem.
 Another issue that can happen is discussions about specific (or
 competing) solution approaches effectively stalemating the WG (or
 BOF), making it unable to make progress.  In some of those cases, the
 arguments about the appropriateness of specific technologies are
 actually proxies for the question of whether a proposed approach
 adequately addresses the problem.  If there is a lack of clarity
 about the actual underlying problem to be solved, there may well be
 unresolvable arguments about the suitability of a particular
 technical approach, depending on one's view of the actual problem and
 the constraints associated with it.  Hence, it is critical for all
 work to be guided by a clear and shared understanding of the
 underlying problem.
 The best description and understanding of an actual problem usually
 comes from the customer, operator, or deployer of a technology.  They
 are the ones that most clearly understand the difficulties they have
 (that need addressing) and they are the ones who will have to deploy
 any proposed solution.  Thus, it is critical to hear their voice when
 formulating the details of the problem statement.  Moreover, when
 evaluating the relative merits of differing solution approaches, it
 is often helpful to go back to the underlying problem statement for
 guidance in selecting the more appropriate approach.

Narten Informational [Page 7] RFC 5434 Successful BOF Sessions February 2009

4. The BOF Itself

 For the BOF itself, it is critically important to focus on the bottom
 line:
    What is it that one is attempting to achieve during the BOF?
 Or, stated differently, after the BOF is over, by what criteria will
 you decide whether or not the BOF was successful?
 A good BOF organizer keeps a firm focus on the purpose of the BOF and
 crafts an agenda in support of that goal.  Just as important,
 presentations that do not directly support the goal should be
 excluded, as they often become distractions, sow confusion, and
 otherwise take focus away from the purpose of the BOF.  If the goal
 is to form a WG, everything should lead to an (obvious) answer to the
 following question:
    Does the room agree that the IETF should form a WG with the
    following (specific) charter?
 One of the best ways to ensure a "yes" answer to the above, is by
 performing adequate preparation before the BOF to ensure that the
 community as a whole already agrees that the answer is "yes".  How
 does one do that?  One good way seems to be:
 1) Have a public discussion with sufficient time to allow iteration
    and discussion.  (Hence, start a minimum of 3 months prior to the
    IETF meeting.)
 2) Work with the community to iterate on the charter and be sure to
    address the significant concerns that are being raised.  (One can
    address the concerns in advance -- and get advance agreement -- or
    one can have those concerns be raised (again) during the BOF -- in
    which case it is likely that the proposed charter will not be good
    enough to get agreement during the actual BOF).
 3) During the BOF, keep the agenda tightly focused on supporting the
    need for the WG and otherwise making the case that the group has
    identified a clearly-scoped charter and has agreement on what the
    set of deliverables should be.
 Another important reason for holding a BOF is to establish an
 understanding of how the attendees (and the larger community) feel
 about the proposed work.  Do they understand and agree on the problem
 that needs solving?  Do they agree the problem is solvable, or that
 new protocol work is needed?  To better understand the degree of
 agreement, it is useful to ask the audience questions.

Narten Informational [Page 8] RFC 5434 Successful BOF Sessions February 2009

 Whenever asking questions, it is important to ask the right ones --
 questions that show where there is agreement and questions that probe
 the details around where agreement is lacking.  Good questions
 typically focus on aspects of the problem in a piecewise fashion,
 establishing areas of consensus and identifying areas where
 additional work is needed.  Poor questions do not serve to focus
 future discussion where it is needed.  The following are examples of
 questions that are often useful to ask.
 1) Is there support to form a WG with the following charter?  (That
    is, the charter itself is ready, as shown by community support.)
 2) Does the community think that the problem statement is clear,
    well-scoped, solvable, and useful to solve?
 3) Can I see a show of hands of folk willing to review documents (or
    comment on the mailing list)?
 4) Who would be willing to serve as an editor for the following
    document(s)?  (BOF chairs should take note of individuals who
    raise their hands, but it is also a useful gauge to see if there
    is a critical mass of editors to work on all the documents that
    are to be produced.)
 5) Does the community think that given the charter revisions
    discussed during the BOF (subject to review and finalization on
    the mailing list), a WG should be formed?
 6) How many people feel that a WG should not be formed?  (If the
    number of no responses is significant, it would help to ask those
    saying no why they are opposed.)
 7) Before asking a particular question, it is sometimes very
    appropriate to ask: Do people feel like they have sufficient
    information to answer the following question or is it premature to
    even ask the question?
 Unfortunately, it is also easy to ask the wrong questions.  Some
 examples are given in a later section.

5. Post-BOF Follow-Up

 After the BOF has taken place, it is advisable to take assessment of
 how well things went and what the next steps are.  The ADs should be
 included in this assessment.  Some things to consider:

Narten Informational [Page 9] RFC 5434 Successful BOF Sessions February 2009

 1) Did the BOF go well enough that the logical next step is to focus
    on refining the charter and becoming a WG before the next IETF
    meeting?  If so, there will almost certainly be additional
    discussion on the mailing list to refine the charter and work out
    a few remaining items.
    Note that it can be difficult to determine in some cases whether a
    WG is a feasible next step.  Much will depend on details of how
    the BOF went and/or whether the contentious items can either be
    resolved on the mailing list or simply be excluded from the
    charter and dealt with later (if at all).  Much will also depend
    on the relevant AD's assessment of whether the proposed work is
    ready to move forward.  Sometimes even a seemingly contentious BOF
    can result in a WG being formed quickly -- provided the charter is
    scoped appropriately.
    If the next step is to attempt to form a WG, the charter needs to
    be finalized on the BOF-specific mailing list.  Once done, the
    IESG can be asked to formally consider the charter.  The IESG then
    (usually) posts the proposed charter to the IETF list for
    community feedback and makes a decision based in part on the
    feedback it receives.
 2) It may be the case that enough additional work still needs to take
    place that aiming for a second (and final) BOF makes more sense.
    In that case, many of the steps outlined earlier in this document
    would be repeated, though at a faster pace.
    The expectations for a second BOF are generally higher than those
    for an initial BOF.  In addition to the work done up through the
    first BOF, the first BOF will have highlighted the key areas where
    additional work is needed.  The time leading up to the second BOF
    will need to be spent working through those outstanding issues.
    Second BOFs should not be a repeat of the first BOF, with the same
    issues being raised and the same (unsatisfactory) responses
    provided.  The second BOF needs to show that all previously
    identified issues have been resolved and that formation of a WG is
    now in order.

6. Pitfalls

 Over the years, a number of pitfalls have been (repeatedly) observed:
 1) Waiting too long before getting started.  It is very difficult to
    prepare for a BOF on short notice.  Moreover, ADs are placed in a
    no-win situation when asked to approve a BOF for which the
    community has not had a chance to participate.  Steps 1-4 in
    Section 2 above are designed to show the ADs that there is

Narten Informational [Page 10] RFC 5434 Successful BOF Sessions February 2009

    community support for a particular effort.  Short-circuiting those
    steps forces an AD to make a judgment call with (usually) too
    little information.  Moreover, because the community has not been
    involved, it is much more likely that significant (and valid)
    objections will be raised.  Often, those objections could have
    been dealt with in advance -- had there been sufficient time to
    work through them in advance.
 2) Too much discussion/focus on solutions, rather than showing that
    support exists for the problem statement itself, and that the
    problem is well-understood and scoped.  The purpose of the BOF is
    almost never to show that there are already proposed solutions,
    but to demonstrate that there is a real problem that needs
    solving, a solution would be beneficial to the community, it is
    believed that a solution is achievable, and there is a critical
    mass of community support to actually put in the real work of
    developing a solution.
 3) Asking the wrong question during the BOF.  Often, BOF organizers
    feel like they need a "show of hands" on specific questions.  But,
    unless a question is clear, well scoped, focused enough to
    establish where there is agreement (and where not), etc., asking
    such a question serves little purpose.  Even worse, asking poor
    questions can frustrate the BOF participants and lead to
    additional questions at the microphone, derailing the focus of the
    BOF.
    Examples of unreasonable questions to ask:
  1. Asking folk to approve or review a charter that is put on screen

but has not been posted to the mailing list sufficiently in

      advance.  (You cannot ask folk to approve something they have
      not seen.)
  1. Asking multi-part questions in which it is not clear (in

advance) what all of the exact questions will be and which

      choices a participant needs to choose from.
 4) Poorly advertised in advance, thus, the BOF itself does not
    include the "right" participants.  This can happen for a number of
    reasons, including:
  1. giving the BOF a "cute" but unintuitive name (or acronym),

preventing people from realizing that it would be of interest to

      them.

Narten Informational [Page 11] RFC 5434 Successful BOF Sessions February 2009

  1. failing to advertise the BOF in advance to the community of

people that might be interested. At a minimum, the existence of

      a proposed BOF should be advertised on the IETF list as well as
      on specific WG lists that are somewhat related.
 5) Providing agenda time for the "wrong" presentations.  There is an
    (unfortunate) tendency to give anyone who requests agenda time an
    opportunity to speak.  This is often a mistake.  Presentations
    should be limited to those that address the purpose of the BOF.
    More important, presentations should not distract from the BOF's
    purpose, or open up ratholes that are a distraction to the more
    basic purpose of the BOF.  An example of problematic
    presentations:
  1. presentations on specific solutions, when the purpose of the BOF

is to get agreement on the problem statement and the need for a

      WG.  Solutions at this point are too-often "half-baked" and
      allow discussion to rathole on aspects of the solutions.
      Instead, the focus should be on getting agreement on whether to
      form a WG.
 6) Poor time management, leading to insufficient time for discussion
    of the key issues (this is often closely related to 5).  When
    presentations run over their allotted time, the end result is
    either squeezing someone else's presentation or having
    insufficient discussion time.  Neither is acceptable nor helpful.
    BOF chairs need to give presenters just enough time to make key
    points -- and no more.  It may well be helpful to go over a
    presenter's slides in advance, to ensure they are on-topic and
    will fit within the time slot.

7. Miscellaneous

7.1. Chairing

 BOF organizers often assume that they will be chairing a BOF (and the
 eventual WG).  Neither assumption is always true.  ADs need to ensure
 that a BOF runs smoothly and is productive.  For some topics, it is a
 given that the BOF will be contentious.  In such cases, ADs may want
 to have a more experienced person chairing or co-chairing the BOF.
 Also, those interested in organizing the BOF often are the most
 interested in driving a particular technology (and may have strongly
 held views about what direction an effort should take).  Working
 Groups are often more effective when passionately involved parties
 are allowed to focus on the technical work, rather than on managing
 the WG itself.  Thus, do not be surprised (or offended!) if the AD
 wants to pick one or more co-chairs for either the BOF or a follow-on
 WG.

Narten Informational [Page 12] RFC 5434 Successful BOF Sessions February 2009

7.2. On the Need for a BOF

 This document highlights the need for allowing for and actively
 engaging in a broad public discussion on the merits of forming a WG.
 It might surprise some, but there is no actual process requirement to
 have a BOF prior to forming a WG.  The actual process requirement is
 simply that the IESG (together with the AD(s) sponsoring the work)
 approve a formal charter as described in [RFC2418].  In practice,
 BOFs are used to engage the broader community on proposed work and to
 help produce an acceptable charter.
 There are two observations that can be made here.  First, BOFs are
 often held not because they are (strictly speaking) required, but
 because it is assumed they are needed or because ADs feel that a BOF
 would be beneficial in terms of getting additional public
 participation.  Hence, those interested in forming a WG should give
 serious consideration to using the steps outlined above not just for
 the purposes of creating a BOF, but to convince the IESG and the
 broader community that a BOF is not even needed, as there is already
 demonstrated, strong consensus that a WG should be formed.  Second,
 the IESG should not forget that BOFs are simply a tool, and may not
 even be the best tool in every situation.

8. Security Considerations

 This document has no known security implications.

9. Acknowledgments

 This document has benefited from specific feedback from Jari Arkko,
 Brian Carpenter, Dave Crocker, Spencer Dawkins, Lisa Dusseault, Pasi
 Eronen, John Klensin, Tim Polk, Mark Townsley, and Bert Wijnen.

10. Informative Reference

 [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
            Procedures", BCP 25, RFC 2418, September 1998.

Author's Address

 Thomas Narten
 IBM Corporation
 3039 Cornwallis Ave.
 PO Box 12195 - BRQA/502
 Research Triangle Park, NC 27709-2195
 Phone: 919-254-7798
 EMail: narten@us.ibm.com

Narten Informational [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5434.txt · Last modified: 2009/02/02 23:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki