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 in RFC2460,

=> this is a concern because RFC 2460 doesn't document all useful cases
(IPCOMP was forgotten, MIP6 needs destination option at a new position, ...).

        and limiting itself from
        handling non-IPv6 headers like AH/ESP (i believe users do not want to
        manipulate AH/ESP from normal socket API.  also, how do you plan to
        handle IPsec-tunnelled packets?).

=> manipulation of AH/ESP themselves no, but manipulation of the position yes.

        by removing more limitations, we get closer and closer to BPF...
   
        i guess, if we follow the spirit of RFC2292, we first need to
        evaluate RFC2460, to see if we need to remove some of suggested header 
        ordering constraints - MIP6 seem to conflict with it, with some reasons
        (i have trouble chasing recent MIP6 discussions, so i may be wrong).

=> MIP6 conflicts with it, I tried at the San Diego IETF to solve it:
 - me: 3 different documented positions (2 in RFC, 1 in MIP6 I-D) for
       destination option headers are a real mess. Give different numbers
       (i.e. make different headers), ...
 - Steve Deering (chair): don't change RFC 2460, it is near perfect (:-).
 - me: how to solve the conflict?
 - Steve: an application can decide to use an order not documented in
          RFC 2460 (i.e. the ordering is recommended, not mandatory,
          and can be updated (change the order, add new headers) if needed).
 - me: but how to code it, the (advanced) API doesn't give the needed
       flexibility.
 - Steve: fix the API!
 - Eric Nordmark (from another room): heu... What's happened?

        then, we design 2292bis to follow the new header ordering constraint.
   
=> I agree: with a clear description of RFC 2460 flexibility we'll know
what we need for the API.

        just a meta-thought.
   
=> can you summarize what happened at San Diego (I am likely a bit biased)?

Thanks

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

Reply via email to