>>>>> On Fri, 29 Jun 2001 09:42:59 -0700 (PDT),
>>>>> Tim Hartrick <[EMAIL PROTECTED]> said:
> 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.
Okay, then I'll wait for the archive.
> 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.
Hmm, this approach seems to be able to keep compatibility with the
current rfc2292bis spec. So, if this kind of approach can get a
consensus, I think I'm happy with it.
> Are there other areas of inflexibility that are causing real problems today
> as opposed to possible problems a few years from now?
I hope not, but just like MIP6 broke the existing recommended order
of extension headers, I'm not sure even about the near future.
However, I agree that we should try to keep the change as minimum as
possible while introducing minimum flexibility.
>> > 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.
Right, that's exactly the reason why the api list was created.
> 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.
I agree on this point. But as for the discussion place, I'd propose
keep the ipngwg list for now. The important thing is, as you just
mentioned, that those who are writing code speak up about based on
their standpoints. (Even if we can make a "reasonable" consensus, we'll
eventually have to discuss it here at the ipngwg list, and will have
a possibility of suffering from "crazy" ideas).
But I don't stick to the place. If many implementors want to move the
place to the API list, I'm willing to follow the decision.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
