Re: dna bof report

["James Kempf" <kempf@docomolabs-usa.com>]

Bernard,

> 2. The basic model of DNAv4 and DNAv6 are quite similar, even though the
> technologies differ. For example, in both case L2 "Hints" are processed;
> there may be reachability detection phase; and there is an address
> acquisition phase. Also in both cases there are issues with detecting
> non-determinism; in IPv4 this arises when moving between private networks
> (e.g. two gateways, each with address 192.168.0.1, on two different
networks
> -- will the host be fooled?), on IPv6 it occurs when testing reachability
to
> an IPv6 Linklocal address.
>
> On this basis, the BOF participants leaned toward handling DNAv4 and DNAv6
> in the same WG.
>

My experience has been that high level similarities between two technologies
are insufficient grounds for putting them in the same Working Group. The
real work of producing a standard has nothing to do with the high level
similarities, it has to do with the details of how the protocol works and
how it fits into the existing technology base. I can see these details as
being quite different for IPv4 and IPv6. My experience has been that WGs are
more productive when they concentrate on the details of getting a protocol
designed. If there are still some questions about metadesign, a short
requirements and problem statement phase (preferably before the WG is formed
to give the participants an incentive to agree) can help to clarify matters.

> 3. "The last WG syndrome".  In IETF there is a tendency to view a BOF as a
> once in a lifetime opportunity to get work done.  So "consensus" tends
> toward overload, on the theory that if Optimistic DAD isn't handled in the
> DNA WG, then it will drop on the floor and take years to get done.  In
> reality, the IETF is more efficient than that, when we're doing our job.
>
> My personal recommendation on DNA is as follows:
>
> 1. Try to figure out how we can address the most egregious issues in
> DHCPv4/v6 and ZEROCONF right away, via the errata and doc change route.
>
> 2.  Do a single document on L2 "hints" for DNA. Note that this is distinct
> from the "trigger" concept in that DNA must be robust against misleading
> "hints" -- where as triggers seem to imply more certainty (which of course
> doesn't exist, which is a problem).
>

Triggers was never fully developed, since it could not find a home in IETF.
Uncertainty in the delivery of a trigger is something that's been discussed
in a research context. If you prefer "hints", though, perhaps it's a better
word.

> 3.  As part of the Charter review, ask the founders to come up with a
Review
> team to look at the DNAv4 and DNAv6 documents to make sure that the
pitfalls
> (and amount of work required) is well understood.  These should be highly
> knowledgeable reviews like Robert Elz, Keith Moore, and Brian Carpenter.
> I'd suggest that this be done before a charter is written so that we avoid
> "ZEROCONF syndrome" -- a WG formed without sufficient expertise in its
core
> area. If suitable "experts" cannot be found to generate the initial and
> subseqnet reviews, then the conditions for the WG to succeed do not exist,
> and a WG should not be chartered until the resources are available.
>

Excellent idea.

> 4. Handle Optimistic DAD in a separate venue.  My recommendation would be
to
> create the equivalent of the TSVWG in the INT area -- INTWG, for the
purpose
> of handling small things that wouldn't otherwise deserve their own WG,
like
> Optimistic DAD.  The idea is to create a WG where IP experts would
> congregate so that we don't repeat the ZEROCONF fiasco, where we created a
> WG focussed on making fundamental changes to IP that was populated mostly
by
> folks interested in building smart appliances.  In other words, a
mistmatch
> between skills and the task at hand.
>

Agree.

            jak