Darren Reed writes:
> "However, during the discussions it became clear that there were
> potential problems making the Hooks Framework generic at this time
> so we will implement our own specific hooks in ip."
Yeah, that's not pleasant. From an ARC point of view, there are
several issues to contend with:
- You're right that we don't want to see multiple implementations of
the same thing. However, it's also true that we don't want to
hold a project hostage to unsolved areas elsewhere in the system.
It's a bit of a tightrope walk to make that sort of judgement
call.
- If this project is right, and the Hooks Framework is not general
enough to solve this problem, then it's certainly fair to ask why
that should be so. It seems, at least at first blush, that
anything that can filter packets ought to be also functional
enough to simply _observe_ them. If that's not true, it'd be nice
to know why. This would likely end up as advice to management.
- It's also fair to ask that the project team go off and discuss the
issues with the other teams involved. Reasonable answers this
team could come back with would include, "that project's schedule
doesn't fit with our schedule, but after they integrate, we commit
to reworking ours to fit." But it'd be good to know the answers.
As things stand today, there is no one, generally-available, generic
framework for packet inspection. Every project to date places its own
hooks into IP, sometimes labels them as yet another "generic
solution," and then drives on. That alone is worth some advice.
> Having been to PSARC a few times and got to know what they think
> about "hooks in IP", if I were PSARC reading this, it would be like
> waving a red flag in front of a bull. i.e. we need to change this
> story. It may be that the IP observability project would perhaps
> benefit more from PEF (packet event framework) to get packets than
> pfhooks. At some point in time, it is possible that pfhooks will
> use PEF as the means to provide events for some packets. But right
> now I can see one or both projects being told to go away and come
> back when you've fixed the story unless there is an impeccible
> reason for engineering it like this.
Again from the ARC perspective, I don't think I'd ask such a thing.
PEF doesn't exist. There's no ARC documentation that describes it.
We could certainly ask the project team to go off and discuss the
issue and come back, but I can't see how we could ever demand that
this project depend on something that doesn't exist.
It's the PEF project's problem to deal with the system as it is when
(and if) that project comes forward for review and then integration.
Outside of the ARC, it's management's job to make sure the projects
are aligned as best they can. If we have multiple projects all
attempting to deliver the same thing into Solaris, then that's a
management problem.
The one thing we could reasonably ask about is dependencies between
this project and the IP Filter Hooks project. But if that latter one
doesn't have the features required for this one, and can't be reworked
to have them, then we've got a bit of a misfit. The choice then comes
down to applying force (force that'll likely cause this project to
fail to deliver) or letting it go with noses held and strong advice to
management. We often do the latter (sigh), but there's no way to
predict.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
