Moving forward

[David Kessens <david.kessens@nokia.com>]

The v6ops working group is getting closer to finishing all it's work
items. This obviously means that an old question is rightfully
surfacing again: which proposed solutions do we need for which
scenario, and the follow up question, will we standarize this
solution and where ?

All this hard work has helped to have a better understanding on which
minimum set of mechanisms need standarization. It is pretty clear that
it is now getting time that we start to move from the analysis phase
to standarization. As you all know, in general the Operations area
doesn't design new protocols. This means we cannot standarize the
solutions in the v6ops working group. However, the ADs would like to
hear officially from the working group what protocols need
standarization for which scenario. After that, the IESG can decide to
accept that work in an existing working group in another area, a new
working group can be formed or the work can proceed without
the need for a working group.

It is not going to be an easy task to reach consensus on each and
every scenario and which solution(s) is/are most appropriate. In the
interest of making progress it seems best in cases where no quick
consensus can be reached to document the disagreement with pros and
cons and move on. I expect to have results ready fairly soon after the
IETF in San Diego. This process should result in a recommendation from
the working group on which minimum set of protocols need to be
standarized and which proposals didn't reach consensus but could be
useful. Criteria used should involve (among others): simplicity, can
this problem already be solved with a different solution that can be used
in multiple cases?, security and proven to work in practise (running code).

Most likely, there will be a group of proposals for solutions that are
not going to be choosen by the working group due to lack of consensus
on the need for standarization or the fact that they are not the
preferred solution.

In such cases, I would nevertheless like to get them published
through the rfc-editor as an informational or experimental rfc.
However, if there is significant support for the document, it got
quite some review in the IETF and/or multiple implementations exist,
the ADs might decide to propose to the IESG to use a modified
to-be-developed boilerplate that takes the above in consideration.

I hope this helps,

David Kessens
---