>
> Does anyone have an objection to this idea? If not, the procedure
> would be:
>
> 1. remove extension header issues from the current draft.
> 2. solve (a part of) open issues except extension header ones.
> 3. based on the result of 2, issue a revised version of the rfc2292bis
> draft. The draft name would be either
> draft-ietf-ipngwg-rfc2292bis-03.txt
> or
> draft-ietf-ipv6-rfc2292bis-00.txt
> 4. solve extension header issues, and issue a new draft entitled
> (e.g.) draft-ietf-ipv6-exthdr-api-00.txt
>
Hmm.. I would say I do object for this reason. If I remember the issues
related to MIPv6 binding updates and the like and I remember the discussions
that occurred on this list regarding them I wasn't under the impression
that we were substantially far from being able to solve some of the in-
flexibility issues. I wouldn't want to see us rip all that content out of
the spec unless we are pretty sure that consensus can't be reached.
What scares me about splitting this content off is that it opens up an
opportunity for complete redesign of the entire mechanism if it is not
tightly controlled. We don't have a history of that kind of discipline
in these areas and I am concerned that we will get a complete redesign,
and pile and piles of obsoleted code, when only tweaks are required.
What I would prefer is that we take the discussion to the apifolks mailing
list, where we have a good focused group, so that we can actually get the
work done. We aren't that far away. It just requires cycles to be applied.
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
