Darren,

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

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

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

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.

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

-Kenjiro