Erik Nordmark wrote On 2006年03月08日 05:59,:
James Carlson wrote:
The things that need to be explained to the ARC members are why all of
the previous claims to generic hook features are unusable and why
generic hooks aren't even considered feasible. That's something I'd
hoped to do back when we were writing the filtering document, but that
essentially go no consensus and went nowhere.
Jim and Darren,
If there is a place where I can help to clarify this (in a meeting, some
slides, some text in a document), please let me know and I'll contribute.
I recall Darren actually has worked on a doc in analyzing why the
previous generic hook features are unusable.
For one, IPPF design doc specifically mentioned that the design has
NOT been consulted the firewall requirement
due to resource/time constraint. Maybe that doc should be appended to
this design doc under reviewing.
Darren?
-Kevin
Darren Reed writes:
The biggest problem I can see with combining the two is that as a
result of discussion over the design, I abandoned trying to resolve
the problem of multiple consumers for the same hook. The result
here would be not being able to use /dev/ipnet/* at the same time
as IPFilter if both used the same hook rather than their own.
Is it a problem, though, that actually needs to be solved? I think
that's the unclear part for both projects.
If we have some targeted hook somewhere which can do queuing and/or
rewriting of the headers, then I think that the order matters.
But I think this can be addressed by explicitly making such hooks single
consumer - not allowing multiple parties to register.
Should there be hooks that are for observability only, or even those
that can do pass/drop, then there isn't much of an issue with the order.
Thus such targeted hooks can potentially allow multiple registrants.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
|
_______________________________________________
networking-discuss mailing list
[email protected]
