>>>>> On Mon, 02 Jul 2001 10:11:50 +0200,
>>>>> Francis Dupont <[EMAIL PROTECTED]> said:
> I believe that the core of the last discussion on this topic began with
> a message by Francis Dupont on December 15, 2000. The subject of that
> message was "destination option update".
> => in fact the discussion began some days before at the IETF meeting
> when Steve Deering said the problem I wanted to be solved was in
> the (advanced) API...
> In the discussion that followed
> there was the beginnings of a design to solve the problem, I hope.
> If so we can just jump right into the middle of that six month old
> discussion and finish off this issue.
> => I don't know if we can quickly reach a consensus. There is only one
> rough proposal... and the time is not very good (holidays, 4th July
> power down, etc). Do you believe we can do it before the cut-off?
I've just read the previous discussion. It seems to me that we've
basically reached a consensus for the receiving side; obsolete the
IPV6_RECVRTHDRDSTOPTS option, and let the kernel send all headers (if
requested) to applications in the receiving order.
For the sending side, which would be the difficult part, I think we
have two possible approaches.
1. try to realize the full flexibility about the header chain; the API
allows applications to specify any combination of headers (in any
order).
2. only loosen the restriction about destination options headers;
(e.g.) add another ancillary data type/socket option to specify the
relationship between a destination options header and a fragment
header.
If we're aiming at the 1st goal, I'm quite sure that we'll need much
time to discuss it and reach a consensus. So, in this case, I'd like
to separate this part from the "basic" part of the advanced API (as a
separate draft).
If we take the second approach, it might be possible to get a
consensus in a relatively short period. So, it would be worth trying
to keep the whole spec in a single document.
As for no.1 vs no.2, I'm inclined to support no.2. Due to less
flexibility, of course, we may see another ordering issue in the
future. However, at least at this moment, I don't see a possibility
to use an extension header (except destination options headers) in a
different way than the recommended way specified in RFC 2460. And,
with this approach, we might be able to avoid rewriting existing
applications that already use rfc2292bis for some extension headers
(except destination options ones).
Comments?
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]
--------------------------------------------------------------------
