Feature creep avoidance [Re: on the point of mobility & multihoming]

[Brian E Carpenter <brc@zurich.ibm.com>]

It's to avoid featurism that RFC 3582 describes "goals" not "requirements"
and that Eliot's draft describes "things to think about." When we have a
complete architectural analysis, I hope we will be able to extract from
that what are the necessary and sufficient components of a solution,
and stop there.

   Brian

Dave Crocker wrote:
> 
> [ post by non-subscriber.  with the massive amount of spam, it is easy to
> miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>-owner@ops.ietf.org and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
> 
> john,
> 
> jlnc> Dave,
> 
> jlnc> I still worry about feature-creep in Multi6.  Should a multi6 be
> jlnc> a floor polish & a desert topping?
> 
> only if you want to lick the floor.
> 
> but seriously, you cannot imagine how much I share your concern for
> feature creep.
> 
> what i've discovered in this topic is an equal fear of the potential
> to have too much redundant, and possibly conflicting, mechanism,
> because related problems were not solved with common mechanism.
> 
> but, yes, the mantra of: timely, simple, useful
> is paramount.
> 
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>