> On Thu, 26 Jul 2001 23:52:42 +0200 (CEST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 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
Catching up on email after some vacation...
> 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 receivi
Date:Tue, 3 Jul 2001 12:20:06 -0700 (PDT)
From:Tim Hartrick <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I believe that all that is required is the ability to designate where the
| fragmentable part the the datagram begins
Hang on a minute ... you think
>
> 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).
>
Only someone that has
>
> => explain how you can get the position of an extension header in
> the current advanced API. There is a setsockopt per header/position
> defined in RFC 2460 which gives a lot of different setsockopt (not
> a real problem but this is unnecessarily rigid) and of course gives
> no way to c
> On Tue, 03 Jul 2001 10:52:49 +0700,
> Robert Elz <[EMAIL PROTECTED]> said:
> 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 (i
In your previous mail you wrote:
I'm finding hard time trying to find a good balance between BPF, and
basic API. advanced API (ancillary data) should fit somewhere
in between. RFC2292 had a good balance by limiting the ordering of
headers to what is documented i
In your previous mail you wrote:
> 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).
This would be true if it were possible to add a new extension header type
without mod
In your previous mail you wrote:
Making to these deadlines seems like a bad idea if the consequence will
be that we split off content that will then be completely and unnecessarily
redesigned thus rendering piles of existing code obsolete.
=> unfortunately the redesign is *not* unneces
In your previous mail you wrote:
I agree with approach no.2 not only because it is the most expedient but
I don't see what other flexibility is required.
=> explain how you can get the position of an extension header in
the current advanced API. There is a setsockopt per header/position
d
Date:Mon, 02 Jul 2001 20:02:49 +0900
From:JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| If we take the second approach, it might be possible to get a
| consensus in a relatively short
Itojun,
>
> just a meta-thought.
>
And a well reasoned meta-thought it is.:-)
Tim Hartrick
Mentat Inc.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP a
Markku,
>
> If you consider dynamically loadable modules (DLL's) kernel
> extensions, then you are right. It should be possible to add support
> for a totally new extension header to an existing stack by a loadable
> module, which attaches to the stack, without touching the stack and
> API co
I'm finding hard time trying to find a good balance between BPF, and
basic API. advanced API (ancillary data) should fit somewhere
inbetween. RFC2292 had a good balance by limiting the ordering of
headers to what is documented in RFC2460, and limiting itself from
> From: Tim Hartrick <[EMAIL PROTECTED]>
> This would be true if it were possible to add a new extension header type
> without modifying the kernel. It isn't really possible in the implementations
> I have seen so there really isn't any flexibility gained by throwing out
> the existing extensio
Markku
>
> > From: JINMEI Tatuya / 神明達哉 <[EMAIL PROTECTED]>
> >
> > 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 op
> From: JINMEI Tatuya / 神明達哉 <[EMAIL PROTECTED]>
>
> 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.)
Jinmei,
>
> 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
Francis,
>
> In your previous mail you wrote:
>
>> => 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?
>>
>
>
In your previous mail you wrote:
> => 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?
>
Since I don't have any idea wh
Francis,
>
> 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 d
Hi,
Francis Dupont wrote:
>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.
>
> => I believe the issue has
In your previous mail you wrote:
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 ord
> 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
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
On Fri, Jun 29, 2001 at 09:42:59AM -0700, Tim Hartrick wrote:
>
> 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
Hmm - shouldn't the stack be able to determine this for itself? See if
ther
> On Fri, 29 Jun 2001 14:19:14 -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 ha
> On Sat, 30 Jun 2001 23:18:34 +0700,
> Robert Elz <[EMAIL PROTECTED]> said:
> | Hmm, I see. So, "the API does not prohibit the bad behavior, but the
> | underlying kernel would (or might) prevent the bad packets from beiing
> | sent on the wire." Right? Then, I'm perhaps okay w
Date:Sat, 30 Jun 2001 02:12:35 +0900
From:JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Hmm, I see. So, "the API does not prohibit the bad behavior, but the
| underlying kernel would
Jinmei,
>
> > 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
> 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
> On Fri, 29 Jun 2001 12:29:06 +0700,
> Robert Elz <[EMAIL PROTECTED]> said:
> | Please forget about this topic.
> Done... Apologies for sending lengthy comments on stuff that was
> old - I half thought I'd seen it before, but my memory just isn't that
> good...
No, that was my bad
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 c
> On Thu, 28 Jun 2001 11:54:24 -0700 (PDT),
> Tim Hartrick <[EMAIL PROTECTED]> said:
>> 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
>>
Date:Thu, 28 Jun 2001 22:15:59 +0900
From:JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Please forget about this topic.
Done... Apologies for sending lengthy comments on stuff that wa
>
> 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.
> On Wed, 27 Jun 2001 18:03:35 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> The most difficult issue would be the one for extension headers.
>> According to a recent discussion about MIP6 issues, the API should be
>> flexible enough to send/receive extension headers in any order,
> On Wed, 27 Jun 2001 22:37:05 +0700,
> Robert Elz <[EMAIL PROTECTED]> said:
> | >> - Fix Authors address wrt Rich.
> | I don't know a common sense in such a case, either. rfc2553bis has
> | the same issue, and the latest draft simply removed his address.
> I'd wait and see how
> On Wed, 27 Jun 2001 22:37:05 +0700,
> Robert Elz <[EMAIL PROTECTED]> said:
> | > 2.1.2. IPv6 Extension Headers
> | >
> | > I think it would be useful to define a generic structure to specify
> | > IPv6 extension headers, since we sometimes encounter a situation where
> | >
Date:Wed, 27 Jun 2001 22:27:07 +0900
From:JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| >> - Fix Authors address wrt Rich.
| I don't know a common sense in such a case, either. rfc
> On Tue, 26 Jun 2001 14:20:48 +0200 (CEST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> If possible, I'd like to see the next revision of the draft before the
>> next IETF meeting in London. So my question is:
>>
>> does anyone (especially in the authors) try to revise the draft now?
> On Tue, 26 Jun 2001 12:07:33 +0200,
> Francis Dupont <[EMAIL PROTECTED]> said:
>The most difficult issue would be the one for extension headers.
>According to a recent discussion about MIP6 issues, the API should be
>flexible enough to send/receive extension headers in any
> If possible, I'd like to see the next revision of the draft before the
> next IETF meeting in London. So my question is:
>
> does anyone (especially in the authors) try to revise the draft now?
I'd like to see the document finished. But I don't have any cycles
to actually drive the open issu
In your previous mail you wrote:
As an IPv6 stack/application programmer, I'd really like to fix the
advanced API. The current situation is really mess, because
rfc2292bis does not provide backward compatibility to the old RFC
2292, and some OSes has already shipped with rfc2292bis
Hello,
As an IPv6 stack/application programmer, I'd really like to fix the
advanced API. The current situation is really mess, because
rfc2292bis does not provide backward compatibility to the old RFC
2292, and some OSes has already shipped with rfc2292bis while some
other OSes still keep RFC 22
45 matches
Mail list logo
