Vlad,
>
> >
> > And, of course, either approach has impact on existing
> > implementations, and the impact depends on the spec that the
> > implementations are using. As I said in the presentation, the 02
> > approach affects RFC2292-based implementations much, and the 03
> > approach affects 02 (or earlier) based implementations much. So I'd
> > like to hear from other implementors.
> >
> > Again, though I prefer the 03 behavior, I know (and understand) some
> > other people dislike it. I'll hear from others, and will obey the
> > consensus.
>
> If we can not reach consensus (don't gasp, it happened before), may I suggest
> that we document both behaviors. We can keep a strict 2292bis-02 behavior
> (i.e
> don't return control data for SYNs, ACKs, etc), and the 2292bis-03 behavior
> with
> the limitations in section 4.1 (i.e applies only to TCP and can only be used
> with
> getsockopt).
>
> Both calls will return identical information and MUST be used exlucsively of
> each other (i.e use one or the other, not both).
>
With regard to how the -02 behavior works, it isn't at all clear to me that
the -02 behavior can't be made to return extension headers that arrive on
non-data bearing segments. That is an implementation detail. It may be that
returning such extensions is more difficult for some implementations than
others. It hasn't proven to be a showstopper for us. The negotiation of
of certain extensions is another matter.
I appreciate the desire to satisfy both sides but the above suggestion merely
guarantees that the implementation is more than twice as complicated as it
would be if we only selected one mechanism.
Given the dubious utility of this facility I far prefer no mechanism to two
mechanisms. The fact that the mechanisms are removed from this document does
not preclude implementations from making them available.
tim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
