[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
> |
> |
> |