Kenjiro,

> > > > Maybe I'm just more concerned about things architecturally and looking
> > > > for a good design...
> > > 
> > > Maybe, sometimes I'm just more concerned about having things done at
> > > the right time with the given constraints :)
> > 
> > What time constraints ? :)
> 
> In this particular case, OpenBSD has its release cycle, and my
> collaborators and I had limited time for the job and didn't know if we
> could do it in the next release cycle.

Ok.  Well I'll state the obvious, just in case, and that is that NetBSD
doesn't have the same release cycle pressure that OpenBSD does.  I don't
think I'm aware of anyone on the inside of NetBSD who would consider
this to be a significant or important change for the next NetBSD major
release so if the integration time was longer whilst details were nutted
out, this would not be a big problem.

In short, rushing this into NetBSD (or attempting to) will not win anyone
any friends and will more than likely make enemies, especially if there
are outstanding issues in the API design (and I, at least, believe there
are).

> > > You can provide ipf_tagname2tag() or whatever you want.
> > > Since it's not in the packet forwarding path, we can go through all
> > > the packet filters available on the system to look up the given tag.
> > 
> > What's the purpose for this?  My understanding of pf is that it turns a
> > packet tag name into a number inside the kernel to match up packets to
> > its rules.
> > 
> > So the packet is tagged as it enters the host and then altq matches up
> > its policies based on its tag configuration ?  Will defining queues,
> > etc, remain part of KAME or is it expected that this, too, is expected
> > by the packet classifier ? (pfctl has all this merged.)
> 
> As I said earlier, pf employs the unified model and merged all the stuff.
> If ipf employs the independent model, all the queue related part
> remains in altqd(8).
> If there will be no packet filter to use the independent model,
> altqd(8) will go away.

OK.  How much of KAME is a part of FreeBSD?  I believe they use dummynet
(or similar) for bandwidth shaping, but I'm trying to guess here if ipfw[2]
will support this or if it'll even be required to keep altqd.

Is a long term goal to stop supporting the independant model and altqd ?

> > You will have an interface to register (and deregister) functions that
> > resolve tag names in the altq code ?
> 
> It's one way to do that, in which one packet filter can be registered
> at a time.

FreeBSD and NetBSD support having packet filters as LKMs, so the
register/deregister thing is kind of mandatory.

> What I suggested was that altq doesn't care multiple packet filters
> tagging packets at the same time as long as tag labels are unique.

When I look through the ALTQ code for OpenBSD, I see no references to
pf_tagname2tag(), only the following:

PACKET_TAG_PF_QID
struct pf_altq
includes for net/pfvar.h

Are there further changes required to this code to support what you
are talking about ?

IMHO, all of the above direct references to pf need to disappear before
the new ALTQ work is merged with NetBSD.  People have written other
packet classifiers for NetBSD and they should not be required to use
any of the pf things if they want to interact with ALTQ.

> > > Right.  itojun imported pf into KAME today and started working on
> > > the setkey part.  I haven't had time to catch up.
> > 
> > I get the impression that itojun's email was both premature and not
> > very well worded then, if you want to achieve the goals you're after.
> 
> I haven't had much time to discuss the issues with itojun so that our
> opinions may not agree.

I see.

Well it is not good to hear that.

Can I suggest that any further discussion (and definately action) be put
on hold until KAME, at least, understands what it is doing ?  Seems like
left hand does not know what the right hand is doing...and why am I still
sending out this full email having said it ?!

Cheers,
Darren