Re: [DNA-BOF] Comment required: Goals or Requirements for DAD, DNAv4,DNAv6?

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Pekka,

Pekka Nikander wrote:
> Greg Daley wrote:
> 
>> Pekka suggested that we may want to have a DAD Optimization
>> Goals document which combines problem statements and
>> goals(requirements)?
>>
>> One of the cited reasons was the well defined nature of
>> this task.
>>
>> What do people think about this?
> 
> 
> Since I suggested that, I am apparently in favour of the
> suggestion... :-)
> 
>> I'm still guessing that DNAv4 and DNAv6 need some
>> more analysis to ensure that we cover the issues there.
>>
>> DO people think that problem statements and goals/requirements
>> should be separate there?
> 
> 
> I don't have any strong opinion on this.
> 
>> Do people think we should change the requirements documents
>> in the charter work list to goals?
> 
> 
> Personally, I don't like the word "requirements" much.  To me,
> it looks like many people take it too literally, and complain
> when one or more requirements cannot be fulfilled, or conflict
> with each other.  I've seen at least one WG (multi6) to stall
> for a long time partially because of this very reason.
> 
> Furthermore, I don't really believe in staged engineering
> where you first define a set of requirements and only then
> try to fulfil them.  The resulting systems tend to be overly
> complex and rigid.

I think that for standardization it may be necessary
to have a 'staged' engineering process.

But maybe not the staging which is traditional
for some standards groups...

What's important is that the group has a consistent
view when it comes to developing and standardizing a
protocol. By this I mean they aren't violently against
the standardization of a protocol.
Unless the group can achieve a rough consensus we can't
expect the IESG to.

In this case, even a widely acclaimed and simple technology
has to receive discussion about its aims.  We may as well
document our on-list discussion in a draft.

This not only provides a consistent list of goals within
the group, but shows other teams (IESG, other working groups)
that we've considered the situation.

> In my humble opinion, goals (or requirements) are good for
> aligning people's thinking.  Futhermore, they can be
> used as partial evaluation criteria in beauty contests.
> However, I also think that things like architectural simplicity,
> flexibility, and modularity should also be considered.
> 
> If goals are defined to be used as evaluation criteria, then
> it is somewhat unfair to allow any people that propose solutions
> to participate in defining the goals, since such participation
> may be biased.  However, as long as there are little IPR or
> other commercial interests, I don't see this as a real issue.

I think that this is where the IETF is right now.
Most participants in developing systems are part
of an organization with its own agenda.
(Often these organizations have very good intentions too).

> On the other hand, if there is real controversy on what is
> the problem, then separate problem statements and goals
> probably help.  I haven't really followed the DNA specific
> discussion so that I could make comments on that.

Perhaps the area is less clear with Attachment Detection.

The work is less self-contained (has interactions with
ND/Autoconf/DHC), and may be complicated if there are
scenarios which do not neatly fit in with existing
legacy technologies (like IPv6 Neighbour Discovery :)
or solution proposals.

In these cases, defining requirements which cover corner cases
may make the final protocol engineering work more difficult,
but initially we need to expose the problems before we define
goals.

This may be true even if we agree that the goals for the initial
solution deliberately leave out some corner cases, or make
decisions known to be inefficient in a some scenarios.

Greg