Subject: Re: complete the advanced API (rfc2292bis)

From: Francis Dupont <[email-masked]>
Date: Mon, 02 Jul 2001 10:11:50 +0200

In your previous mail you wrote:

   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?

Thanks

[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 02 Jul 2001 20:02:49 +0900

>>>>> On Mon, 02 Jul 2001 10:11:50 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

   
> 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-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Mon, 02 Jul 2001 14:24:15 +0200

=> we still need a format to do that (easy but this is missing).

=> this is the only reasonnable option in the long term.

=> I believe the issue has to be solved, a quick & dirty hack shan't be
enough next time.

=> I agree. And of course we'll need time to implement and experiment
proposals.

=> the discussion about header order showed clearly that we need
some freedom. Only a major change in the API can give this.

   future.

=> I think this will happen so I don't believe in the no.2.

   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.

=> security headers...

   And, with this approach, we might be able to avoid rewriting existing
   applications that already use rfc2292bis for some extension headers

=> I know only telnet (routing header) and some specialized applications
(MLD, traceroute6, ...). This doesn't seem to be a real problem (less than
to keep the current advanced API).

Regards

---

From: Keiichi SHIMA <[email-masked]>
Date: Mon, 02 Jul 2001 23:24:23 +0900

Hi,

> => I believe the issue has to be solved, a quick & dirty hack shan't be

From the MIP's point of view, I think this approach will solve the
exthdr order problem related to MIP. Although, with respect to MIP, I
guess the advapi is not important part for implementers because MIP is
highly related to IPv6 stack, many MIP implemnters will make it in the
kernel (and I am one of them). So few of them consider using advapi to
realize MIP stack.

Beside MIP, to make the insertion logic of destopt exthdrs more
flexible sounds good for me. Destopt is a generic exthdr than other
exthdrs, the flexibility will solve some future exthdr problems.

I think most of us are thinking that the 1st approach that jinmei
proposed is the ideal way. But we are worry about we must consume a
lot of time to achive the real goal, a very flexible advapi, while we
don't have much time...

---
Keiichi SHIMA <[email-masked]>
Internet Initiative Japan 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-masked]
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Mon, 2 Jul 2001 22:40:06 +0300

> From: JINMEI Tatuya / 神明達哉 <[email-masked]>
> 

I like 1. It's simpler, easier to implement and document. Nice generic
and dumb API.

To me it seems to be more work, if you have to define, implement and
document every possible extension header separately in the API (as 2
will require).

---

From: Robert Elz <[email-masked]>
Date: Tue, 03 Jul 2001 10:52:49 +0700

Date:        Mon, 02 Jul 2001 20:02:49 +0900
    From:        JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
		 <[email-masked]>
    Message-ID:  <[email-masked]>

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

This is not the right way, though I found myself tempted to agree with it
for a while.  As long as the read interface is set, so any random application
can deal (if it wants to) with anything that is handed to it over the net,
we could perhaps defer on maying a "standard" on how to send arbitrary
sequences for some time - allow various implementors to dream up their own
ways to handle this, and try them, and just wait and see which of those is
best liked by application writers.  Since relatively few apps need the
flexibility, the costs in having to deal with multiple different methods
in the shortish term shouldn't be too great.   Or that's the way I was
thinking.

But I always knew that wasn't really a good approach, and Francis' message
convinced me that it wouldn't be the right thing to do.

So, I'd prefer to complete & document the receive case, and just leave the
send case for a later doc to define.   That is, not have any method at all
defined for inserting headers in the new doc for now (implementors can keep
implementing the current spec).

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 04 Jul 2001 02:14:55 +0900

>>>>> On Tue, 03 Jul 2001 10:52:49 +0700, 
>>>>> Robert Elz <[email-masked]> said:

> implementing the current spec).

Hmm, I'm still not convinced the idea of the full flexibility, but at
least we need to separate the header issue from the rest of the API
spec for now.

As for the I-D cutoff issue, I personally do not think the deadline
itself is so important (because I don't think we can reach a full
consensus on the API spec by the meeting even without the header
issue.)  However, it would be a good excuse to accelerate the job, so
I'd like to propose to separate the header issue from the spec,
concentrate the rest of the issues, and try to get the next revision
published by the cut-off date.

(sorry for continuing the meta-discussion.  I'll then go to the
technical ones.)

					JINMEI, Tatuya