Notes from Wye River

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

my collected wisdom of what we actually talked about at Wye River appended 
below - web version at 
<http://www.alvestrand.no/ietf/iesg/retreat-2003/notes.html>

This is based on what was left in my brain (not much), my paper notes and 
the flipover charts. Lots of stuff missing.

For the stuff that's broken, missing or needs fleshing out - PLEASE send 
replacement text!

                Harald

--------------------------------------------------------------------

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.

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>

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.

  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.

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?

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

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

Support: What can the secretariat do for us?

  Presentation of plans - thoughts on priorities / feedback

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?

Specific topic: Certificates and LDAP

  Result: General orientation, specific advice

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?

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:

  - More time for "informal" discussions
  - Stronger coffee!