Subject: [nvo3] READ ME - Agenda for IETF84

From: Benson Schliesser <[email-masked]>
Date: Thu, 26 Jul 2012 18:39:49 -0400

Dear NVO3 Participants -

In preparation for the Vancouver meeting next week, the chairs would
like to provide guidance on a few topics. PLEASE READ THIS MESSAGE
before attending the NVO3 meeting on Tuesday.

First, as background, we would like to make sure that contributors
understand the difference between a "Call for Adoption" and a "Last
Call". Adoption is the mechanism by which an individual draft becomes
a WG draft. While individual drafts reflect the authors' contribution,
a WG draft is meant to reflect the consensus of the WG. Adoption does
not require the draft to be in its final state - such a draft may
evolve, driven by WG consensus - but it should contain a good starting
point.  Later, in order to determine whether a WG draft is finished
the chairs will announce a Last Call for comments. During a Last Call,
contributors should make sure that the draft text accurately reflects
the WG consensus. In other words, the threshold for Adoption is
considerably less than a Last Call.

As further background, we would like to make sure that contributors
understand the types of documents that we anticipate. Our charter
calls for a Problem Statement (PS), Framework (FW), multiple
Requirements (Reqs) documents, and a Gap Analysis (GA). We also
anticipate one or more Applicability Statement (AS) documents in NVO3.
The chairs agree that our goal is to produce only one PS and one FW
document. Likewise, our goal is to produce one each of the Control
Plane Reqs, Data Plane Reqs, and Operational Reqs documents. All of
these should be generalized such that they are not solution-specific.
The presence of text in the PS or a Reqs document should not be
construed to imply criticism or promotion of any existing solution. In
the event that multiple conflicting use-cases are envisioned by the
WG, these documents may reflect e.g. multiple categories of
requirements or approaches. AS documents, on the other hand, should be
descriptions of how a specific solution could be applied per the
framework to satisfy the various requirements. An AS document might
reference individual drafts, the work of other WGs, and/or the work of
another SDO. We encourage AS documents to include use-case
descriptions. For each AS document we expect a companion GA document.
Ultimately, we hope that a meta-analysis of the various GA documents
will satisfy our final milestone. We encourage all contributors that
submit documents to organize their work around these categories.

In this context, during the NVO3 meeting at IETF 84 we will focus
foremost on the Adoption of a Problem Statement and a Framework
document. The agenda itself is divided into three categories, the
first of which is dedicated to this purpose. Specifically, we ask
participants to be prepared to discuss which existing documents should
be adopted and/or any open issues with these documents. Each person
that approaches the microphone should be prepared to answer these
questions. We expect all contributors to read in advance all drafts
that are referenced by the agenda - the discussion should be oriented
around making progress against our milestones.

The second category within the agenda is dedicated to presentations /
drafts that purport to fit against other milestones. Presenters in
this category will be given 10 minutes to present their material and
respond to questions, which should be an overview of how their draft
applies against one of NVO3's milestones. The third and final category
is given to other drafts that authors wish to make known and solicit
feedback.  Individual presenters in this third category will be
permitted only 1 slide and 2 minutes, with no time for questions or
discussion.

During the meeting, all presenter time-slots will be strictly
enforced.  The chairs must receive all slides by 5pm local time (PDT)
on Monday or the presenter's time-slot will be forfeit. (This is an
extension relative to
http://www.ietf.org/mail-archive/web/nvo3/current/msg00964.html in
order to give presenters time to adapt to the shorter time-slots.)

Thanks,
-Benson and Matthew