Subject: Re: complete the advanced API (rfc2292bis)

From: Tim Hartrick <[email-masked]>
Date: Mon, 2 Jul 2001 11:58:17 -0700 (PDT)

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?
>    > 
>    
>    Since I don't have any idea when the cut-off is since I won't be in London
> 
> => 13 and 20th July.
> 
>    I don't know if we can make it or not.
> 
> => this is tactics: if now we should split the document in order to have
> the easy part ready ASAP.
> 
>    If we don't try then will be right back here again six months from
>    now dredging up old discussions that should have been concluded the
>    last time.
>    
> => I agree we are not in a hurry for the header stuff.
> 

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.  The draft has
languished for two plus years I think.  Another four months won't make a
difference.  We should keep the document together in one piece and address
the existing problems, not speculative problems.

Rather than continuing with this meta discussion, why don't we move on to
the meat of getting the issues addressed.

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jul 2001 10:05:24 +0200

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* unnecessary: the header order
specified in RFC 2460 was misinterpreted as mandatory and the advanced API
has not the needed flexibility. I believed the flaw was in RFC 2460 but
Steve Deering proved it is in the advanced API:
(from proceedings of San Diego 49th IETF meeting)
> Deering asked why speaker said the destination option was a "nightmare".
> Dupont: because that the destination header can occur at different places.
> Deering answered that this is the way that IPv6 was designed. Dupont
> doesn't think that this freedom is useful.
> 
> Zill: We should design the API around the protocol, not the protocol around
> the API.
> 
> Deering: Important to keep flexibility to allow new uses as new applications
> are conceived/developed. Deering does not understand the need for this
> approach. Dupont want there to be more structure in destination header
> placement.
> 
> Bound: Also doesn't think we should change the protocol to match the API.
> 
> [Editor: ran out of time, stopped presentation/discussion, but there didn't
> see to be much support for this proposal]

   The draft has languished for two plus years I think.

=> this is a real problem we'd like to fix ASAP.

=> I agree we have to put more into the real thing than into the way to do it.

Regards

[email-masked]