Jinmei,
>
> > 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.
>
> I do understand the concern...but, then, do you have a concrete idea
> to realize the flexibility?
>
I was pretty sure that I and others made some proposals during the last
discussion of this topic that were close to working for at least the receiving
and sending of ancillary data. It has been a while but I am sure we started
down the path of a solution. I guess I can try and dredge the discussion
out of the archives.
As I understand the issues, applications may want to be able to specify
where the non-fragmentable part of the datagram ends and where the fragmentable
part begins. They also need to be able to specify where in a chain of
extension headers the stack should insert AUTH or ESP headers.
Similarly we need a mechanism which allows an application to determine
when receiving a datagram where the fragmentable part of the datagram begins
and where in the chain of extension headers an AUTH or ESP header had
been located.
Are there other areas of inflexibility that are causing real problems today
as opposed to possible problems a few years from now?
> > 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.
>
> As for the place to discuss the issue, I don't mind to go to the
> apifolks list. A possible problem of the list, though, is that it is
> not so widely common, and some people who are interested in the topic
> and are writing code may not able to join the discussion (actually,
> I've already got several e-mail messages about what the list was or howb
> an interested person could subscribe to the list). So, unless there
> is a strong objection to being stay here, I think we should still
> discuss the issue in the list.
>
I have sympathy for this view. My only concern is that we have people that
write the code to implement the API driving the discussion. People that don't
have a dog in the fight are free to propose all sorts of crazy things which
will translate into long discussions that lead nowhere but wasted time on im-
plementing things that won't work or won't be used.
We are now in the process of doing our third attempt at finishing the coding
of this API. The first implementation was completely wasted because the
original advanced API draft was essentially thrown out. There will soon be
a need for adding the API extensions for scoped addresses. I don't think any
implementor has the luxury of writing anymore throw away API code. We certainly
don't.
If we keep the discussion focused on the immediate problems then we certainly
can get this done without breaking out yet another API document.
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]
--------------------------------------------------------------------
