Subject: Re: complete the advanced API (rfc2292bis)

From: Tim Hartrick <[email-masked]>
Date: Fri, 29 Jun 2001 09:42:59 -0700 (PDT)

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 complete redesign,
> > and pile and piles of obsoleted code, when only tweaks are required.
> 
> I do understand the concern...but, then, do you have a concrete idea
> to realize the flexibility?
>

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 I can try and dredge the discussion
out of the archives.

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
part begins.  They also need to be able to specify where in a chain of
extension headers the stack should insert AUTH or ESP headers.

Similarly we need a mechanism which allows an application to determine
when receiving a datagram where the fragmentable part of the datagram begins
and where in the chain of extension headers an AUTH or ESP header had
been located.

Are there other areas of inflexibility that are causing real problems today
as opposed to possible problems a few years from now?

> > What I would prefer is that we take the discussion to the apifolks mailing
> > list, where we have a good focused group, so that we can actually get the
> > work done.  We aren't that far away.  It just requires cycles to be applied.
> 
> As for the place to discuss the issue, I don't mind to go to the
> apifolks list.  A possible problem of the list, though, is that it is
> not so widely common, and some people who are interested in the topic
> and are writing code may not able to join the discussion (actually,
> I've already got several e-mail messages about what the list was or howb
> an interested person could subscribe to the list).  So, unless there
> is a strong objection to being stay here, I think we should still
> discuss the issue in the list.
> 

I have sympathy for this view.  My only concern is that we have people that
write the code to implement the API driving the discussion.  People that don't
have a dog in the fight are free to propose all sorts of crazy things which
will translate into long discussions that lead nowhere but wasted time on im-
plementing things that won't work or won't be used.

We are now in the process of doing our third attempt at finishing the coding
of this API.  The first implementation was completely wasted because the
original advanced API draft was essentially thrown out.  There will soon be
a need for adding the API extensions for scoped addresses.  I don't think any
implementor has the luxury of writing anymore throw away API code.  We certainly
don't.

If we keep the discussion focused on the immediate problems then we certainly
can get this done without breaking out yet another API document.

Tim Hartrick
Mentat 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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 30 Jun 2001 03:38:24 +0900

>>>>> On Fri, 29 Jun 2001 09:42:59 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> down the path of a solution.  I guess I can try and dredge the discussion

Okay, then I'll wait for the archive.

> and where in the chain of extension headers an AUTH or ESP header had

Hmm, this approach seems to be able to keep compatibility with the
current rfc2292bis spec.  So, if this kind of approach can get a
consensus, I think I'm happy with it.

> as opposed to possible problems a few years from now?

I hope not, but just like MIP6 broke the existing recommended order
of extension headers, I'm not sure even about the near future.
However, I agree that we should try to keep the change as minimum as
possible while introducing minimum flexibility.

> plementing things that won't work or won't be used.

Right, that's exactly the reason why the api list was created.

> can get this done without breaking out yet another API document.

I agree on this point.  But as for the discussion place, I'd propose
keep the ipngwg list for now.  The important thing is, as you just
mentioned, that those who are writing code speak up about based on
their standpoints.  (Even if we can make a "reasonable" consensus, we'll
eventually have to discuss it here at the ipngwg list, and will have
a possibility of suffering from "crazy" ideas).

But I don't stick to the place.  If many implementors want to move the
place to the API list, I'm willing to follow the decision.

Thanks,

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