Version 2: Notes from Wye River

[Harald Tveit Alvestrand <harald@alvestrand.no>]

the notes got away from me one edit cycle too early. try these.


Notes from the IESG retreat, April 29-30, 2003

  The notes follow the agenda topic. Large chunks of them are
  reconstructions from memory. The author does not guarantee that there
  is a close relation between the notes and what was actually discussed.

IESG overview - the IESG charter

  Harald Alvestrand presented the work done so far on the IESG charter,
  and the reasons why it was needed.

  The IESG discussed the shape of the world in general, but did not
  engage closely in the specifics of the charter document.
  One thing clear is that there is a need for a statement of the purpose
  of the IETF - we all know what it is, but it isn't written down
  anywhere.

  Other keywords from the conversation:
    * The IETF largely does components, not (constraining)
      architectures.
    * The place where we depart from a pure SDO (and where we often get
      into trouble) is where we deal with the things that are on the
      boundary between standardization, deployment and operations. Our
      willingness to work here is also an essential part of the IETF's
      strength.
    * Lots of our contribution to operational common sense comes from
      people with 25+ years of making things work. This is hard to
      teach, and cannot be dictated. How do we pass it on?
    * There is a large history of our community wanting to work,
      ultimately, to "make the world a better place" - our standards are
      not value-neutral, but rather are infused by (or at least want to
      default to) maximum freedom and maximum common benefit. How sure
      are we that our participants share this world-view?

The Larger Picture - the context of the IETF universe

  Leslie Daigle presented the organizations involved in the "IETF
  universe", and how they relate to each other.

  It is clear that this is a result of a long process - and that nobody
  would have designed it this way. Still, it is what we have.

  <insert link to presentation>

  The division of the IETF from the IAB caused some stir; it is clear
  that the term "IETF" is used for many subsets of the drawing, from
  "the whole thing" down to "the IESG and the working groups", with
  different people regarding different subsets as "parts" and "separate
  entities".

Strategy in dealing with others: IEEE, Radius and 802.11x

  We have had a number of interactions with the IEEE, which attempts to
  use some IETF standards in its rprotocols, not always in a way that
  the IETF community approves of. We have no formal liaison
  relationship; things seem to have worked in the past without one.

  It was observed that the IEEE process involves a systemic need to send
  liaison statements to other bodies to prove that they have coordinated
  themselves; it is not clear that they always need answers. But some of
  them do.

  It was noted that the delay in getting DIAMETER out the door as the
  "AAA next generation" has contributed to people's desire to use
  RADIUS. This is not good for the IETF; we have avoided having a
  process to deal with RADIUS extensions. We need to think here.

  The discussion branched into dealing with liaison statements in
  general - the experience from 3GPP (positive) and 3GPP2 (negative)
  show how essential it is with a personal relationship to "the one on
  the other side" - and to evaluate how well this person works with the
  rest of the organization. Some skepticism is probably a Good Thing.

  Running this, too, on personal relationships does run the risk of
  having the "hit by a truck" problem - the likely solution seems
  probably to be to aim to have more than one person on each side
  informed about what is going on, and aware of who to talk to and how,
  rather than trying to build bureaucracies and formalisms to handle the
  communication.

  Action item: <<who>> to retry contacting IEEE and coordinating more
  closely.

Strategy in dealing with ourselves: The IM story

  The IM story is a long one. And it concerns not only technology and
  standards maneuvrings, but personalities too.

  One of the things that one can see now was a mistake was not rewriting
  the charter of the IMPP working group when the IM work was split up
  into the transport subgroup and the interoperability IMPP/CPIM
  document; the current charter on file is totally irrelevant to what
  the group is doing, and that makes it hard to use the charter as a
  tool to guide the work of the group.

  Still, there was a large amount of sentiment in the room that
  attempting to search for interoperability is a Good Thing - not least
  to give an open specification of interoperable formats that the other,
  non-standard IM mechanisms could point themselves at rather than have
  the "gateway to gateway to gateway" problem that Einar Stefferud used
  to call the "3-body problem".

  No clear resolution on what to do next....

Working group management

  - When should we charter a WG?
  - Why do WGs stay on track? Why do they stray from it?
  - How do we deal with disruptive people?
  - What are our tools to get cross-area review/input?
  - What are the conditions under which WGs are better off closed?

  (my notes here are not extensive.....)

  one central tool in WG management is making the goals visible, and
  keeping them in the face of the WG at every opportunity. This argues
  for fairly frequent and easy charter updates.......

  while much talked about, the group felt that actively subversive
  behaviour is not in fact a great problem in the IETF - it happens, but
  is not the most common reason why groups fail to perform.

Document Review: What's the IETF process that gets the right documents done?

  (and what are the right documents, anyway?)

  How do we get documents reviewed at an early stage (input into WG)?
  How do we deal with the cases where a WG chair doesn't feel that he's
  in charge of quality control?

  What are the consequences of having the "individual via RFC Editor"
  path, and how/when should we push back on that using the "bypass"
  flag?
  Possible results:
  - Changes to procedures
  - Efforts to get more people to review on our behalf

  The group quickly converged around a place where we have been before:
  The need to get review into the WG, with cross-area expertise, at the
  time when the group has an architecture and a solution space in place
  - what Bellovin called the "boxes and arrows" stage - but before the
  group is so far down the track that they are unavoidably wedded to
  their architecture by invested effort.

  Steve Bellovin wanted to argue for doing this review at charter time;
  this fits badly with the many groups that are chartered before they
  have something that is clear enough for review.....

  SEND, PANA, OPES and DCCP all expect to be in that stage very soon;
  Erik, Thomas, Allison and Aaron were appointed as a "task team" to
  work on the details on how we can make this review a reality.

  Ted Hardie pointed out that here, as in all matters IETF, openness is
  a critical feature of the process.
  Several others felt that doing a careful review in what amounted to an
  (interim or IETF) WG meeting context would be extremely challenging;
  however, doing it in a smaller setting does set a higher bar for
  clarity of the review results - writing it down!

Documents that bypass the WG process

  - How to say NO
  - How to say NOT NOW
  - Experimental/Individual competing with Stds-Track/WG
  - Sticking the IETF to a WG charter
  Examples: ISATAP/V6Ops,  PWE3

  This discussion quickly converged into separating the set of
  "documents the IESG dislikes" into four distinct categories (although
  one document may at times belong in several!)
    * Just Plain Stupid - these are (mostly) OK to publish, with the
      appropriate (sarcastic) IESG note prominently featured.
    * Opposed to the consensus of the WG: These SHOULD be published, but
      with adequate status (Historic?) and IESG note - and AFTER the
      consensus output of the WG is finished.
    * Damaging to WG process - for instance by getting a "head start" on
      documents in WG review, thereby derailing WG attempts to gather
      consensus on documents - in this case, we want a DO NOT PUBLISH
      BEFORE note, referring to the WG event in question
    * Harmful to the Internet: Do Not Publish (see the draft-higgs
      rejection slip for an example).

  In the case of DO NOT PUBLISH BEFORE, the RFC Editor would
  (presumably) send the document back to the author, informing him/her
  that the document would not be accepted now, but that the author could
  choose to resubmit it after the relevant WG event had happened.

  It would be nice to have a tighter definition of "harmful to the
  Internet", but none but "I recognize it when I see it" immediately
  suggests itself....

  There's a class of documents that are "just not worth the time" - the
  theory du jour is that the RFC Editor's initial review takes care of
  those, and that they will never see the IESG's plate at all.

Support: What can the secretariat do for us?

  Presentation of plans - thoughts on priorities / feedback

  Barbara Fuller presented her thoughts on what the various projects at
  the secretariat could hope to achieve, and with how much effort. The
  IESG was generally happy with the presentation.

  Some items from the discussion:

  - CCing iesg-secretary on responses that do not ask them to do
  anything is a Bad Habit, and we shouldn't do it. Wastes time.

  - An interface that would permit the AD to see "what are the things I
  can and should do something about" would be nice. But requires info in
  the database on a number of items that aren't there yet before we can
  create it....


Advancing in grade: Why, How and Who?

  - What are the theoretical criteria for advancing to Draft? Full?
  - What are the criteria in practice?
  - What is the benefit of advancing? The onus of not advancing?
  - Should we reincarnate the "expire in grade" rules? Or kill them?

  The discussion uncovered the fact that the IESG is most vehemently of
  the opinion that there is real benefit to advancing - it can give
  valuable information to the community that a specification is not only
  clear enough to implement, but implemented. The benefit is greatest if
  the time between Proposed and Draft is short; after 5 years, most of
  the investment in coding that will be done has been done anyway.

  The concept of "two implementations" got a bit of a workout - all
  features must be implemented by two implementations, but not
  necessarily by the same 2 for all features.

  The greatest problem of Draft is getting someone to do the work
  (starting off by defining the "feature list"). Sometimes it seems that
  we should create a new category "Useful", for which one could move
  standards that have been at Proposed for 2 years and where people
  claim it's being used.... but that way, we have no idea whether the
  implementations actually implement the specification or not......


Specific topic: Certificates and LDAP

  Result: General orientation, specific advice

  did anyone have notes enough to make a clear summary here.....?

The Evolution of the IETF

  - What are the essential properties of the IETF we need to preserve?
  - What do we want to see changed when "the process" finishes?
  - What should we just go ahead and change off the bat?
  - What do we need to change in our external relations?

  Important points (ie they got onto the flipover):
    * Widening the structure, bringing in more people to think, is a
      Good Thing. Directorates are one tool.
    * Mentoring and training are things we need to become better at.
      Raising people rather than waiting for them to grow!
    * Level-setting is a great tool to manage expectations. This means
      spending time documenting what the process is, and showing that
      the process has been followed.....

  Work items for us:
    * Work for earlier x-area input & review - Alex, + the team noted
      under "document review" offered to help.
    * The IESG members have no alternative but to participate in the
      change process, it seems.
      We need to focus on both the problems and the good stuff that
      happens.
      And we need to focus on, and show ourselves open to, the changes
      needed.
    * We need to continue to work on openness. Including beating our own
      drum somewhat - focusing attention on the changes we've made to
      facilitate openness!


Telechat

  See separate minutes.

The AD-Nits checklist

  Classifying into "essential" and "nice to have" (if any)
  Determining that we'll stop anything on the "essential" list.
  What does using "MUST" in an Informational document mean?
  Who checks what nits? Coordination with the RFC Editor

  Results:
  - Revised checklist
  - Changes to procedures

  The format nits were mostly identified as "nice to fix, but RFC Editor
  will fix them". The IESG shouldn't waste time pushing back on them -
  but it would be nice to have automated testing available.
  The rest of the nits list was mostly confirmed, but discussion of the
  "example.com" domain names for examples led to the conclusion that
  this should be downgraded from "send it back" to "advice" - the risk
  of bad consequences is relatively small in most cases, and the
  "example.com" names tend to make examples harder to read for human
  eyes.

  The IPR boilerplate is possible to add at the RFC Editor. The
  Copyright boilerplate needs to be added by the author - so that it is
  plain that the author knows he has added it. (even if it is just by
  setting "ipr=full"). <<<not sure if this was the conclusion. Bert?>>>

  Actions:
  - Bert to talk with RFC Editor to confirm handling of format nits
  - Bert to initiate scanning all new Publication Requested docs for
  nits compliance between now and June 1 - and report back on the amount
  of time it takes him to scan for them.
  - ADs to make it a strict policy to return documents with bad nits
  evaluation
  - This policy change to be announced to the community

Consensus management

  - What do we mean by consensus?
  - How do we deal with disrupters of consensus?

  This discussion ranged over a wide range of topics, including the
  reasons why people try for consensus (they see a common advantage in
  having a standard), and why they might want another outcome (because
  they see commercial advantage, or don't want to compromise, or are
  simply wedded to their own ideas).

  The definitely most difficult situation in the IETF is the one where
  there is no clear consensus, yet it is clearly best for the Internet
  that a decision be taken - and that there will not be consensus on ANY
  decision.

  The IESG wondered aloud whether it would  be possible to try other
  metods than the consensus method to find decisions - in some cases, it
  seems like the right thing to do. But one thing is for certain: It
  would require the consensus of the involved WG to try it - and not
  only because there is absolutely nothing in our process documents that
  permits us to make IETF decisions on any other basis.

Wrapup session

  - What, at a strategy level, does the IESG need to do?
  - What specific problems do we need to solve "now"?
  - What do we need to do between now and Vienna?
  - What should we do different at the next retreat?

  A number of points, including:
    * Don't have a telechat!
    * We should look at "interesting stuff by area"
    * Work on "deep" issues of the IETF
    * More time for "informal" discussions in "unstructured" time
    * Stronger coffee
    * More neon!

  (there was no full consensus on the last point....)