Option C would probably be the best if we want to see it
being adopted.
-Raj
On 8/2/07 5:26 PM, "ext Sathya Narayanan"
<sathya njit.edu> wrote:
> I vote for (d).
>
> I don't see the point in losing all the
work/discussions that has gone
> in to creating the current document.
>
> Sathya
>
> Suresh Krishnan wrote:
>>
>> Hi Folks,
>> We have heard comments from OS vendors that the
dna protocol, as it
>> exists, is too complex to implement. We already
have one instance of an
>> OS vendor (Apple) who has shipped their own version
of DNAv6 (it is
>> pretty much a version of DNAv4 adapted to IPv6).
From talking to the
>> people who had the complexity concerns, the chairs
have inferred that
>> the following issues with the current document are
the main obstacles to
>> deployment
>>
>> * Router changes are NECESSARY
>> * Handling of corner cases adds complexity to most
likely use cases
>> * Some of the DNA Goals are not really
necessary/useful
>>
>> We have a couple of options going forward
>>
>> a) Forward the current document to the IESG on the
standardization path
>> with no hope of deployment
>> b) Simplify the current document
>> - remove some of the DNA steps
>> - spin off Tentative options to a separate
document
>> and then put it on the standardization path, and
again risk lack of
>> deploymen
>> c) Come up with a much simpler scheme which is
probabilistic but works
>> decently given a set of assumptions(however
limited they may be).
>> Then send it up on the standards track. This has
the highest
>> probability of deployment.
>> d) Do both b) and c)
>>
>> We would like to hear the opinions of the WG on
these options.
>>
>> Cheers
>> Suresh & Greg
>>
>>
>
>
|