[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG next steps



Tony,

Who said the solutions are all in the routing domain?

That being said, I would rather see a roadmap developed in the IETF;
some elements of the roadmap might indeed call for IRTF work, but
we can't just declare the whole issue "research".

   Brian

Tony Li wrote:
> 
> I must disagree with my esteemed colleague.  The routing research
> group would be the appropriate place for this, and there is no
> visible progress there.
> 
> This must be driven by people who have a vested interest in seeing
> this closed.
> 
> Tony
> 
> |   -----Original Message-----
> |   From: RJ Atkinson [mailto:rja@extremenetworks.com]
> |   Sent: Wednesday, November 13, 2002 10:13 AM
> |   To: Thomas Narten
> |   Cc: multi6@ops.ietf.org
> |   Subject: Re: WG next steps
> |
> |
> |
> |   On Wednesday, Nov 13, 2002, at 12:26 America/Montreal,
> |   Thomas Narten
> |   wrote:
> |   > - Some of the proposals on the table involve fairly significant
> |   >   architectural changes to the Internet protocols. But
> |   this WG does
> |   >   not have a mandate to, for example, go modify TCP. If
> |   we are to work
> |   >   on solutions that place signficant requirements on
> |   other WGs, we'll
> |   >   need the cooperation of other areas and WGs. One of the
> |   things that
> |   >   will help getting that cooperation is that these
> |   proposals satisfy
> |   >   the multihoming needs we (as a group) believe exist
> |   today and into
> |   >   the future, and (perhaps) that proposals which do not
> |   involve these
> |   >   changes do not.  For that we likely do need a proper,
> |   reviewed reqs
> |   >   doc to make reference to.
> |
> |   A reasonable approach to the above situation would be for the IAB
> |   to create a new IRTF Research Group on the topic to permit such
> |   architectural work to be done holistically.  The output of
> |   such a group
> |   would,
> |   of course, need to be brought back to the IETF for consideration
> |   before it could become any sort of standard.
> |
> |   I believe the IAB would look favourably on such a proposal
> |   to create an
> |   IRTF RG, if a proposal were presented in a well organised manner.
> |   The proposal would have to be sufficiently different from the NSRG,
> |   which examined an overlapping set of issues, of course.
> |
> |   > - some of the possible directions need qite a bit more
> |   fleshing out,
> |   >   before folk can really begin to evaluation whether the direction
> |   >   makes sense. While early proponents surely believe it
> |   is obvious to
> |   >   produce work in a particular space, we will need signficant
> |   >   community buy-in if we are to actually succeed in deploying
> |   >   things. The more complex the proposal, or the more
> |   changes that are
> |   >   required to implementations to make them work
> |   (especially if they
> |   >   involve upgrades in *all* IPv6 devices!), the more work
> |   it will be
> |   >   convincing the relevant communities to support the
> |   changes. Thus, we
> |   >   need a way of starting work in some directions, but
> |   also have clear
> |   >   checkpoints that will allow us to assess progress and
> |   periodically
> |   >   revalidate that it continues to make sense to keep working in a
> |   >   particular direction.
> |
> |   See above.
> |
> |   Note that running code could be developed inside or outside
> |   the IETF.
> |   Having running code might help persuade folks that a
> |   proposed approach
> |   is viable.  Experimental computer science is a fine thing here.
> |
> |   Ran
> |   rja@extremenetworks.com
> |
> |
> |